Pourquoi seulement 3 stratégies ip xfrm sont-elles nécessaires pour un tunnel IPsec?

J'ai un tunnel IPsec de site à site opérationnel entre une strongswaninstance (v5.2.0) (site A) et un RouterOSrouteur (site B). Tout fonctionne bien, les hôtes des deux sous-réseaux privés configurés pour le site A ( 10.10.0.0/16) et B ( 10.50.0.0/16) peuvent très bien communiquer entre eux.

Ce que je ne comprends pas cependant, c'est la sortie suivante ip xfrm policydu routeur du site A (adresses IP publiques obscurcies). Ces politiques ont été créées par strongswan, je ne les ai pas installées ou modifiées manuellement:

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

Il existe une stratégie pour l'entrée et la sortie, mais une seule pour le transfert (du site B au site A). Mais je peux toujours cingler avec succès, par exemple, à 10.50.4.11partir 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

La partie intéressante de cette trace de route est que le routeur du site A ( 10.10.0.2) apparaît uniquement sur la route de retour de la cible ping, tandis que le routeur du site B ( 10.50.0.1) n'est répertorié que pour la route sortante.

Cela semble confirmer qu'il n'y a effectivement pas politique nécessaire avant sur le routeur de votre site A à transmettre 10.10.0.0/16au - 10.50.0.0/16dessus du tunnel IPsec, mais je ne comprends pas pourquoi.

Merci pour toutes explications!

Les politiques fwd ne sont pas générées automatiquement par le noyau mais sont à la place installées par le démon de saisie (strongSwan dans ce cas).

Ils sont nécessaires pour permettre au trafic d'être transféré vers et depuis les hôtes derrière la passerelle VPN en mode tunnel.

Pour un paquet entrant qui correspond à une adresse IP qui n'est pas installée sur la passerelle elle-même, une stratégie de transfert est recherchée après le déchiffrement. Pour le trafic local une correspondance en est regardé la politique en place. Si aucun n'est trouvé, le paquet est abandonné.

Pour le trafic sortant qui n'a pas été généré sur la passerelle VPN elle-même, une stratégie de transfert avant est recherchée. Si le paquet n'a pas été chiffré, il n'y a pas d'échec si aucune politique de transfert correspondante n'est trouvée. Et si le trafic est acheminé entre deux tunnels, la stratégie de transfert entrant installée avec l'un agira comme stratégie de transfert sortant pour l'autre et vice versa. Ensuite, une politique de sortie est recherchée pour décider s'il faut tunneler le paquet. C'est pourquoi une politique FWD dans le sens sortant n'est souvent pas nécessaire.

Cependant, s'il existe, par exemple, une politique de transfert avant / arrière à faible priorité qui correspond à tout (par exemple, pour éviter que le trafic en texte clair ne passe par la passerelle si aucun tunnel n'est établi), une stratégie de transfert avant dans le sens sortant est explicitement requise car la politique de blocage sinon, supprimez tout le trafic non chiffré. Voilà pourquoi strongSwan a commencé à installer fwd politiques dans les deux sens avec 5.5.0 .

Une version précédente de cette réponse indiquait que la politique de transmission unique (entrante) est symétrique (c'est-à-dire que src et dst fonctionnent dans les deux sens). Ce n'est pas vrai, mais comme expliqué ci-dessus dans de nombreuses situations, cela n'a pas d'importance.