Perché sono necessari solo 3 criteri xfrm per un tunnel IPsec?

Ho un tunnel IPsec da sito a sito attivo e funzionante tra strongswanun'istanza (v5.2.0) (sito A) e un RouterOSrouter (sito B). Tutto funziona bene, gli host nelle due sottoreti private configurate per il sito A ( 10.10.0.0/16) e B ( 10.50.0.0/16) possono comunicare tra loro bene.

Quello che non capisco però è il seguente output del ip xfrm policyrouter del sito A (IP pubblici offuscato). Queste politiche sono state create da strongswan, non le ho installate o modificate 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

C'è una politica ciascuno per input e output, ma solo una per l'inoltro (dal sito B al sito A). Ma posso ancora eseguire correttamente il ping, ad esempio, 10.50.4.11da 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 parte interessante di questa traccia del percorso è che il router del sito A ( 10.10.0.2) viene visualizzato sul percorso di ritorno dal target ping, mentre il router del sito B ( 10.50.0.1) è elencato solo per il percorso in uscita.

Ciò sembra confermare che non ci sia in realtà la politica non in avanti necessari sul router sito di A per inoltrare 10.10.0.0/16al 10.50.0.0/16sopra il tunnel IPsec, ma io non capisco perché.

Grazie per eventuali spiegazioni!

I criteri fwd non vengono generati automaticamente dal kernel ma vengono invece installati dal daemon di keying (strongSwan in questo caso).

Sono necessari per consentire il traffico da e verso gli host dietro il gateway VPN in modalità tunnel.

Per un pacchetto in entrata che è indirizzato a un IP che non è installato sul gateway stesso , viene cercata una politica fwd dopo la decodifica. Per il traffico locale viene cercata una corrispondenza nella politica. Se non viene trovato nessuno, il pacchetto viene eliminato.

Per il traffico in uscita che non è stato generato sul gateway VPN stesso viene ricercata una politica fwd . Se il pacchetto non è stato crittografato, non è un errore se non viene trovata alcuna politica fwd corrispondente . E se il traffico viene inoltrato tra due tunnel, la politica fwd in entrata installata con una fungerà da politica fwd in uscita per l'altra e viceversa. Successivamente, viene esaminata una politica di uscita per decidere se eseguire il tunneling del pacchetto. Ecco perché spesso non è richiesta una politica FWD in direzione di uscita.

Tuttavia, se esiste ad es. Una politica fwd drop / block con bassa priorità che corrisponde a tutto (ad es. Per evitare che il traffico in testo in chiaro passi dal gateway se non sono stati stabiliti tunnel), una politica fwd nella direzione di uscita è esplicitamente richiesta poiché la politica di blocco lo farà altrimenti rilascia tutto il traffico non crittografato. Ecco perché strongSwan ha iniziato a installare i criteri fwd in entrambe le direzioni con 5.5.0 .

Una versione precedente di questa risposta affermava che la singola politica fwd (in entrata) è simmetrica (ovvero che src e dst funzionano in entrambe le direzioni). Questo non è vero, ma come spiegato sopra in molte situazioni questo non ha importanza.