Por que são necessárias apenas três diretivas xfrm ip para um túnel IPsec?

Eu tenho um túnel IPsec site a site em funcionamento entre uma strongswaninstância (v5.2.0) (site A) e um RouterOSroteador (site B). Tudo funciona bem, os hosts nas duas sub-redes privadas configuradas para o site A ( 10.10.0.0/16) e B ( 10.50.0.0/16) podem se comunicar bem.

O que eu não entendo é a seguinte saída ip xfrm policydo roteador do site A (IPs públicos ofuscados). Essas políticas foram criadas por strongswaneu não as instalei ou modifiquei manualmente:

ip xfrm policy 
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir fwd priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.50.0.0/16 dst 10.10.0.0/16 
    dir in priority 2947 ptype main 
    tmpl src <PUBLIC_IP_B> dst <PUBLIC_IP_A>
        proto esp reqid 1 mode tunnel
src 10.10.0.0/16 dst 10.50.0.0/16 
    dir out priority 2947 ptype main 
    tmpl src <PUBLIC_IP_A> dst <PUBLIC_IP_B>
        proto esp reqid 1 mode tunnel

Há uma política para entrada e saída, mas apenas uma para encaminhamento (do site B para o site A). Mas eu ainda pode ping com sucesso, por exemplo, 10.50.4.11de 10.10.0.89:

ping -R 10.50.4.11
PING 10.50.4.11 (10.50.4.11): 56 data bytes
64 bytes from 10.50.4.11: icmp_seq=0 ttl=62 time=10.872 ms
RR:     10.10.0.89
    10.50.0.1
    10.50.4.11
    10.50.4.11
    10.50.4.11
    10.10.0.2
    10.10.0.89

A parte interessante sobre esse rastreamento de rota é que o roteador do site A ( 10.10.0.2) só aparece na rota de volta do destino de ping, enquanto o roteador do site B ( 10.50.0.1) é listado apenas para a rota de saída.

Isso parece confirmar que não há realmente nenhuma política de encaminhamento necessária no roteador do site A para encaminhar 10.10.0.0/16para 10.50.0.0/16o túnel IPsec, mas não entendo o motivo.

Obrigado por todas as explicações!

As políticas fwd não são geradas automaticamente pelo kernel, mas são instaladas pelo daemon de chaves (strongSwan neste caso).

Eles são necessários para permitir que o tráfego seja encaminhado de e para hosts atrás do gateway VPN no modo de túnel.

Para um pacote de entrada que é endereçado a um IP que não está instalado no próprio gateway, uma política fwd é pesquisada após a descriptografia. Para o tráfego local, uma correspondência na política é pesquisada. Se nenhum for encontrado, o pacote será descartado.

Para o tráfego de saída que não foi gerado no próprio gateway VPN , é pesquisada uma política fwd . Se o pacote não foi criptografado, não ocorrerá falha se nenhuma política fwd correspondente for encontrada. E se o tráfego é encaminhado entre dois túneis da entrada FWD política instalada com um irá atuar como saída fwd política para o outro e vice-versa. Posteriormente, uma política de saída é pesquisada para decidir se o túnel é o pacote. É por isso que uma política de envio na direção de saída geralmente não é necessária.

No entanto, se houver, por exemplo, uma política de remoção / bloqueio de aves com baixa prioridade que corresponda a tudo (por exemplo, para evitar que o tráfego de texto não criptografado passe pelo gateway se não houver túneis estabelecidos), uma política de aves na direção de saída é explicitamente necessária, pois a política de bloqueio será caso contrário, descarte todo o tráfego não criptografado. É por isso que o strongSwan começou a instalar políticas fwd em ambas as direções com o 5.5.0 .

Uma versão anterior desta resposta afirmou que a política fwd única (de entrada) é simétrica (ou seja, que src e dst funcionam em qualquer direção). Isso não é verdade, mas, como explicado acima, em muitas situações, isso não importa.