FortiGate di belakang NAT: local-gw, localid dan IP awam
FortiGate di belakang NAT mempunyai alamat tempatan, titik akhir awam yang diterjemah dan identiti IKE. FortiOS menyimpannya dalam medan yang tidak boleh ditukar ganti.
FortiGate di belakang NAT boleh memiliki 10.0.0.2 pada antara muka WAN-nya sementara internet menunjukkannya sebagai 198.51.100.40, dan kedua-dua nombor itu nyata. Alamat yang diikat oleh peranti dan identiti yang dihantarnya semasa pengesahan IKE ialah pilihan berasingan, dibuat dalam medan berasingan, untuk khalayak berasingan. NAT menulis semula pengalamatan luar di laluan; ia tidak menulis semula identiti yang disahkan kepada apa yang dijangka oleh rakan jauh. Kebanyakan kegagalan fasa 1 dalam bentuk ini datang daripada meletakkan nilai yang betul dalam medan yang salah.
Tiga nilai, tiga pemilik
Mulakan dengan menamakan tiga nilai dan siapa memiliki setiap satu. local-gw ialah alamat yang digunakan oleh FortiGate sebagai sumber IKE pada antara muka luarnya, dan ia mesti alamat yang benar-benar dimiliki oleh peranti. Titik akhir awam ialah alamat peranti NAT, dimiliki oleh sesiapa yang melakukan terjemahan. Identiti IKE ialah rentetan yang dipadankan oleh rakan dengan konfigurasinya sendiri, dan ia tidak semestinya alamat IP langsung.
Nama medan cukup dekat untuk mengundang penggantian, dan itulah perangkapnya. localid dan localid-type menerangkan pengenalan; local-gw menerangkan ikatan tempatan.
Contoh menjadikan perbezaan itu konkrit. Pada FortiGate, buka config vpn ipsec phase1-interface, kemudian set interface "wan1" dan set local-gw 10.0.0.2 — alamat yang dimiliki oleh kotak itu, dan itulah yang membolehkan soket IKE mengikat dengan jayanya. Biarkan local-gw pada 0.0.0.0 dan alamat antara muka digunakan, yang biasanya sama tetapi kurang jelas. Jangan tetapkan local-gw kepada 198.51.100.40, kerana peranti tidak memiliki alamat itu dan soket tidak akan mengikat kepadanya. Menjadikan dua nilai kelihatan sama di atas kertas bukanlah konfigurasi.
Langkah 1: pilih identiti yang akan diterima oleh rakan
Kini identiti, yang merupakan keputusan berbeza. set localid mengambil nilai yang akan dibandingkan oleh rakan, dan set localid-type memberitahu FortiGate cara mentafsirnya: alamat, FQDN, FQDN pengguna atau ID kunci. Dengan auto peranti memperolehnya, biasanya daripada alamat antara muka keluar, yang tepat nilai yang akan diubah oleh peranti NAT.
Perolehan itulah sebabnya identiti eksplisit penting dalam topologi ini. Jika rakan menjangka identiti alamat, tetapkan localid-type address dan localid kepada alamat awam yang akan dilihat oleh rakan, kemudian pastikan rakan menerima nilai itu sebagai identiti dan bukan sebagai sasaran penghalaan. Jika rakan menjangka FQDN, gunakan localid-type fqdn dan nama yang digunakan semasa ia dikonfigurasikan. Sahkan apa yang benar-benar dihantar dengan diagnose vpn ike gateway list, yang menunjukkan keadaan gateway dan pengecam yang digunakan, bukan apa yang anda niatkan untuk taip. Jangan andaikan pilihan jenis identiti menerima alamat bukan tempatan sewenang-wenangnya; semak dahulu semantik terdokumentasi keluaran itu.
Langkah 2: teruskan UDP 500 dan 4500 ke peranti
Nilai ketiga milik peranti NAT, dan itulah yang orang lupa periksa. Titik akhir awam mesti meneruskan UDP 500 dan UDP 4500 ke FortiGate, kerana pengesanan NAT-T dan ESP berkapsul yang menyusul kedua-duanya bergantung pada ketibaan port tersebut. Reka bentuk ini menganggap pemetaan satu-ke-satu; perkongsian satu alamat awam mengikut port antara beberapa rakan ialah topologi berbeza dengan had berbeza.
Sahkan penghantaran dengan tangkapan, bukan dengan harapan: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 menunjukkan sama ada paket tiba dan sama ada balasan keluar.
Google Cloud VPN mendokumenkan NAT satu-ke-satu dengan NAT-T sebagai susunan yang disokong untuk rakan di belakang NAT, dan itulah kekangan yang perlu direka bentuk jika hujung jauh ialah gateway Cloud VPN. Perkongsian satu-ke-banyak atau mengikut port bukanlah topologi disokong yang sama, dan tiada penalaan identiti tempatan mengubahnya. Jika pihak jauh ialah peranti lain, dokumentasinya sendiri menentukan apa yang akan diterimanya sebagai identiti dan sama ada ia bertolak ansur dengan alamat rakan yang diterjemah. Bacalah sebelum menukar medan tempatan, kerana pihak tempatan tidak boleh merundingkan peraturan yang tidak dilaksanakan oleh pihak jauh.
Langkah 3: periksa apa yang tidak diselesaikan oleh fasa 1
Lintasan NAT menaikkan terowong, persetujuan identiti menentukan sama ada rakan menerimanya, dan penghalaan awalan dalaman menentukan apa yang sebenarnya melintas. ID tempatan yang betul tidak boleh menyediakan laluan statik yang hilang atau pemilih trafik yang hilang.
Jadi sahkan mengikut lapisan. get vpn ipsec tunnel details menunjukkan sama ada terowong naik dan pemilih mana yang dirundingkan, dan ketidakpadanan antara subnet jauh yang dikonfigurasikan dan pemilih yang dirundingkan ialah masalah penghalaan dalam kostum fasa 2. execute vpn ike gateway clear memaksa rundingan semula, jadi anda menguji konfigurasi semasa dan bukan sesi yang dibina sebelum perubahan terakhir anda. Kemudian hantar trafik ke hos dalam awalan jauh dan sahkan kaunter bergerak, kerana terowong yang naik dan tidak melepaskan apa-apa kelihatan sama seperti yang berfungsi sehingga anda memeriksanya.
Simpan ketiga-tiga nilai di satu tempat dalam nota anda: alamat tempatan yang dimiliki peranti, titik akhir awam yang ditunjukkan oleh peranti NAT, dan rentetan identiti yang dijangka oleh rakan. Ia berubah atas sebab berbeza dan pada masa berbeza.
Penomboran semula peranti NAT bukan sebab untuk menyentuh local-gw milik FortiGate, dan perubahan identiti bukan sebab untuk menomborkan semula apa-apa. Mencampurkan kedua-duanya ialah cara terowong yang berfungsi dibina semula semasa tetingkap penyelenggaraan yang tidak berkaitan. Panduan NAT Cloud VPN ialah rujukan untuk topologi yang disokong di sebelah itu.
Ujian yang menyelesaikannya membosankan dan pantas: tangkap pada antara muka luaran, sahkan UDP 500 dan 4500 tiba dari rakan, sahkan identiti dalam pertukaran IKE sepadan dengan apa yang dikonfigurasikan untuk dijangka oleh rakan, kemudian sahkan pemilih yang dirundingkan meliputi subnet yang anda pedulikan. Jika pemeriksaan pertama gagal, peranti NAT ialah suspek. Jika yang kedua gagal, medan identiti. Jika yang ketiga gagal, NAT mahupun identiti tidak pernah menjadi masalah.