Por que apenas 3 políticas xfrm ip são necessárias para um túnel IPsec?

Question

Eu tenho um túnel IPsec site-a-site em funcionamento entre uma instância strongswan (v5.2.0) (site A) e um RouterOS router (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 muito bem.

O que eu não entendo é a seguinte saída de ip xfrm policy no roteador do site A (IPs públicos ofuscados). Essas políticas foram criadas por strongswan , 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

Existe uma política para entrada e saída, mas apenas uma para encaminhamento (do site B para o site A). Mas ainda posso ping com sucesso, por exemplo, 10.50.4.11 de 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 desse rastreio 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. / p>

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

Obrigado por qualquer explicação!

    

Answer 1

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

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

Para um pacote de entrada 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 política in correspondente é pesquisada. Se nenhum for encontrado, o pacote é descartado.

Para o tráfego de saída que não foi gerado no próprio gateway da VPN, uma política fwd é pesquisada. Se o pacote não foi criptografado, não haverá falha se nenhuma política fwd for encontrada. E se o tráfego for encaminhado entre dois túneis, a política de entrada fwd instalada com uma diretiva atuará como política de saída fwd para a outra e vice-versa. Depois, uma política out é procurada para decidir se o pacote será encapsulado. É por isso que uma política fwd na direção de saída geralmente não é necessária.

No entanto, se houver, e. uma política de drop / block fwd com prioridade baixa que corresponde a tudo (por exemplo, para evitar que o tráfego de texto não criptografado passe no gateway se não houver túneis estabelecidos) uma política fwd na direção de saída é explicitamente exigido, pois a política block cancelará todo o tráfego não criptografado. É por isso que o strongSwan começou a instalar as políticas do fwd em ambas as direções com 5.5.0 .

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