IPsec di atas WAN privat: batas kebijakan SRX yang perlu diperiksa

WAN privat dapat membawa paket luar dari tunnel IPsec, sehingga alamat peer tidak harus berupa alamat internet publik. Yang berubah adalah jalur yang dilalui paket luar itu dan izin pada antarmuka yang menerimanya. Di SRX, jalur kontrol luar, pengikatan antarmuka tunnel, dan kebijakan lalu lintas yang diteruskan adalah tiga objek terpisah. Memecahkan masalah pada satu sementara dua lainnya salah adalah penyebab umum tunnel tetap down.

Catat dulu jalur IKE luar

Tuliskan empat nilai sebelum menyentuh kebijakan: alamat peer, antarmuka lokal yang menerima IKE, konteks perutean yang mencapai peer, dan rute yang memilih antarmuka itu. Paket IKE dialamatkan ke SRX itu sendiri, jadi paket tersebut memerlukan izin host-inbound pada zona penerima, bukan kebijakan lalu lintas yang diteruskan. Alamat WAN privat tidak menghapus persyaratan itu, karena paket tetap berakhir di perangkat.

Periksa status terpasang dengan show security ike sa dan konfigurasi dengan show configuration security ike. Yang pertama memberi tahu apakah fase 1 ada; yang kedua memberi tahu apa yang dianggap perangkat seharusnya dilakukan.

Ikat antarmuka tunnel ke kebijakan yang tepat

VPN berbasis rute mengikat antarmuka tunnel ke objek VPN, dan prefiks yang dilindungi dirutekan ke antarmuka itu. Catat antarmuka, rute, dan kebijakan mana yang mengizinkan aplikasi antar zona terkait. Zona bernama trust adalah wadah kebijakan, dan namanya tidak membuktikan bahwa paket kontrol atau data yang diperlukan diizinkan.

Baca pengikatan sebenarnya, bukan diagram lama: show configuration security ipsec vpn untuk pengaturan ikat-ke-antarmuka dan show configuration security policies untuk aturan yang merujuk zona tunnel.

Jika rute yang dilindungi menunjuk ke tempat lain, tunnel bisa aktif sementara lalu lintas tidak pernah masuk ke sana. Ini masalah perutean yang memakai kostum IPsec.

Pertahankan rute peer di underlay

Rute ke peer eksternal harus diselesaikan melalui underlay, bukan secara rekursif melalui tunnel yang dibentuknya. Jika rute peer menunjuk ke antarmuka tunnel, paket IKE mengejar tunnelnya sendiri dan fase 1 tidak pernah selesai. Jalur balasan untuk lalu lintas yang dilindungi memerlukan rute dan kebijakan yang benar sendiri, dan biasanya itulah separuh yang hilang saat satu arah berfungsi. Baca entri tabel rute untuk alamat peer dan pastikan antarmuka keluar adalah antarmuka WAN.

Periksa dengan show route 198.51.100.10, dengan mengganti alamat peer sebenarnya, dan pastikan hop berikutnya bukan antarmuka tunnel.

Verifikasi kontrol dan layanan secara berurutan

Bekerjalah ke atas: status fase 1, status fase 2, lalu aliran aplikasi nyata. show security ipsec sa mencantumkan asosiasi keamanan, dan show security flow session destination-prefix 10.60.0.0/16 menunjukkan apakah sesi yang diteruskan sedang dibuat untuk jaringan yang dilindungi.

Hubungan kontrol yang sehat dan jalur data yang berfungsi adalah dua hasil berbeda, dan lolosnya fase 2 tidak mengatakan apa pun tentang apakah kebijakan mengizinkan aplikasi. Uji satu aliran yang diizinkan dan satu yang seharusnya ditolak kebijakan, agar perbedaannya terlihat.

Catat bersama rute peer, izin host-inbound, pengikatan tunnel, rute internal, dan kebijakan aplikasi. Kelima catatan itu menunjukkan lapisan mana yang bertanggung jawab atas kegagalan mendatang tanpa bergantung pada label port.