Mengapa hanya diperlukan 3 kebijakan ip xfrm untuk terowongan IPsec?

Saya memiliki terowongan IPsec situs-ke-situs dan menjalankan antara strongswaninstance (v5.2.0) (situs A) dan RouterOSrouter (situs B). Semuanya berfungsi dengan baik, host di dua pengaturan subnet pribadi untuk situs A ( 10.10.0.0/16) dan B ( 10.50.0.0/16) dapat berkomunikasi satu sama lain dengan baik.

Apa yang saya tidak mengerti adalah output berikut dari ip xfrm policyrouter situs A (IP publik dikaburkan). Kebijakan ini dibuat oleh strongswan, saya tidak menginstal atau memodifikasi secara manual:

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

Ada kebijakan masing-masing untuk input dan output, tetapi hanya satu untuk penerusan (dari situs B ke situs A). Tapi saya masih bisa berhasil melakukan ping, misalnya, 10.50.4.11dari 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

Bagian yang menarik tentang jejak rute ini adalah bahwa router situs A ( 10.10.0.2) hanya muncul di rute kembali dari target ping, sedangkan router situs B ( 10.50.0.1) hanya terdaftar untuk rute keluar.

Ini tampaknya mengkonfirmasi bahwa sebenarnya tidak ada kebijakan ke depan yang diperlukan di router situs A untuk meneruskan 10.10.0.0/16ke 10.50.0.0/16terowongan IPsec, tapi saya tidak mengerti mengapa.

Terima kasih atas penjelasannya!

The fwd kebijakan tersebut tidak secara otomatis dihasilkan oleh kernel tetapi sebaliknya bisa diinstal oleh keying daemon (strongSwan dalam hal ini).

Mereka diminta untuk memungkinkan lalu lintas diteruskan ke dan dari host di belakang gateway VPN dalam mode tunnel.

Untuk paket masuk yang merupakan alamat ke IP yang tidak diinstal pada gateway itu sendiri kebijakan fwd dicari setelah dekripsi. Untuk lalu lintas lokal pencocokan dalam kebijakan dilihat. Jika tidak ada yang ditemukan, paket dijatuhkan.

Untuk lalu lintas keluar yang tidak dihasilkan pada gateway VPN itu sendiri kebijakan fwd dicari. Jika paket itu tidak dienkripsi maka tidak ada kegagalan jika tidak ditemukan kebijakan fwd yang cocok . Dan jika lalu lintas diteruskan antara dua terowongan, kebijakan masuk fwd yang dipasang dengan satu akan bertindak sebagai kebijakan keluar fwd untuk yang lain dan sebaliknya. Setelah itu, kebijakan keluar dilihat untuk memutuskan apakah akan mengirim paket. Itu sebabnya fwd kebijakan ke arah yang keluar sering tidak diperlukan.

Namun, jika ada mis. Kebijakan drop / block fwd dengan prioritas rendah yang cocok dengan semuanya (mis. Untuk menghindari lalu lintas teks yang lebih baik dari melewati gateway jika tidak ada terowongan yang dibuat) kebijakan fwd dalam arah outbound secara eksplisit diperlukan karena kebijakan blok akan jika tidak drop semua lalu lintas yang tidak dienkripsi. Itu sebabnya strongSwan mulai menginstal kebijakan fwd di kedua arah dengan 5.5.0 .

Versi sebelumnya dari jawaban ini menyatakan bahwa kebijakan fwd tunggal (masuk) simetris (yaitu src dan dst bekerja di kedua arah). Itu tidak benar, tetapi seperti yang dijelaskan di atas dalam banyak situasi ini tidak masalah.