FortiGate di belakang NAT: local-gw, localid, dan IP publik
FortiGate di belakang NAT memiliki alamat lokal, titik akhir publik yang diterjemahkan, dan identitas IKE. FortiOS menyimpannya di kolom yang tidak dapat dipertukarkan.
FortiGate di belakang NAT dapat memiliki 10.0.0.2 pada antarmuka WAN-nya sementara internet menampilkannya sebagai 198.51.100.40, dan kedua angka itu nyata. Alamat tempat perangkat mengikat dan identitas yang dikirimnya selama autentikasi IKE adalah pilihan terpisah, dibuat di kolom terpisah, untuk audiens terpisah. NAT menulis ulang pengalamatan luar saat lewat; NAT tidak menulis ulang identitas yang terautentikasi menjadi apa yang diharapkan peer jauh. Sebagian besar kegagalan fase 1 dalam bentuk ini berasal dari menaruh nilai yang benar di kolom yang salah.
Tiga nilai, tiga pemilik
Mulailah dengan menamai ketiga nilai dan siapa pemilik masing-masing. local-gw adalah alamat yang digunakan FortiGate sebagai sumber IKE pada antarmuka eksternalnya, dan itu harus berupa alamat yang benar-benar dimiliki perangkat. Titik akhir publik adalah alamat perangkat NAT, dimiliki oleh siapa pun yang melakukan penerjemahan. Identitas IKE adalah string yang dicocokkan peer dengan konfigurasinya sendiri, dan sama sekali tidak harus berupa alamat IP.
Nama kolomnya cukup mirip untuk mengundang penggantian, dan itulah jebakannya. localid dan localid-type menjelaskan identifikasi; local-gw menjelaskan pengikatan lokal.
Contoh membuat perbedaannya konkret. Di FortiGate, buka config vpn ipsec phase1-interface, lalu set interface "wan1" dan set local-gw 10.0.0.2 — alamat yang dimiliki kotak itu, dan itulah yang membuat soket IKE berhasil mengikat. Biarkan local-gw pada 0.0.0.0 dan alamat antarmuka yang dipakai, yang biasanya sama tetapi kurang eksplisit. Jangan setel local-gw ke 198.51.100.40, karena perangkat tidak memiliki alamat itu dan soket tidak akan mengikat ke sana. Membuat dua nilai tampak sama di atas kertas bukanlah konfigurasi.
Langkah 1: pilih identitas yang akan diterima peer
Sekarang identitas, yang merupakan keputusan berbeda. set localid mengambil nilai yang akan dibandingkan peer, dan set localid-type memberi tahu FortiGate cara menafsirkannya: alamat, FQDN, FQDN pengguna, atau ID kunci. Dengan auto perangkat menurunkannya, biasanya dari alamat antarmuka keluar, yang persis nilai yang akan diubah perangkat NAT.
Penurunan itulah sebabnya identitas eksplisit penting dalam topologi ini. Jika peer mengharapkan identitas alamat, setel localid-type address dan localid ke alamat publik yang akan dilihat peer, lalu pastikan peer menerima nilai itu sebagai identitas, bukan sebagai target perutean. Jika peer mengharapkan FQDN, gunakan localid-type fqdn dan nama yang dipakai saat dikonfigurasi. Verifikasi apa yang benar-benar dikirim dengan diagnose vpn ike gateway list, yang menampilkan status gateway dan pengenal yang digunakan, bukan apa yang ingin Anda ketik. Jangan berasumsi bahwa opsi tipe identitas menerima alamat non-lokal sembarang; periksa dulu semantik terdokumentasi dari rilis tersebut.
Langkah 2: teruskan UDP 500 dan 4500 ke perangkat
Nilai ketiga milik perangkat NAT, dan itulah yang orang lupakan untuk diperiksa. Titik akhir publik harus meneruskan UDP 500 dan UDP 4500 ke FortiGate, karena deteksi NAT-T dan ESP terenkapsulasi yang menyusul keduanya bergantung pada tibanya port tersebut. Desain ini mengasumsikan pemetaan satu-ke-satu; berbagi satu alamat publik berbasis port di antara beberapa peer adalah topologi berbeda dengan batas berbeda.
Pastikan penerusan dengan tangkapan, bukan harapan: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 menunjukkan apakah paket datang dan apakah balasan keluar.
Google Cloud VPN mendokumentasikan NAT satu-ke-satu dengan NAT-T sebagai susunan yang didukung untuk peer di belakang NAT, dan itulah batasan yang harus menjadi acuan jika ujung jauh adalah gateway Cloud VPN. Berbagi satu-ke-banyak atau berbasis port bukan topologi yang didukung yang sama, dan tidak ada penyetelan identitas lokal yang mengubahnya. Jika sisi jauh adalah perangkat lain, dokumentasinya sendiri menentukan apa yang akan diterimanya sebagai identitas dan apakah ia menoleransi alamat peer yang diterjemahkan. Bacalah itu sebelum mengubah kolom lokal, karena sisi lokal tidak dapat menegosiasikan aturan yang tidak diterapkan sisi jauh.
Langkah 3: periksa apa yang tidak diselesaikan fase 1
Traversal NAT menaikkan terowongan, kesepakatan identitas menentukan apakah peer menerimanya, dan perutean prefiks dalam menentukan apa yang benar-benar lewat. ID lokal yang benar tidak dapat menyediakan rute statis yang hilang atau pemilih lalu lintas yang hilang.
Jadi verifikasi berlapis. get vpn ipsec tunnel details menunjukkan apakah terowongan naik dan pemilih mana yang dinegosiasikan, dan ketidakcocokan antara subnet jauh yang dikonfigurasi dan pemilih yang dinegosiasikan adalah masalah perutean berkostum fase 2. execute vpn ike gateway clear memaksa negosiasi ulang, jadi Anda menguji konfigurasi saat ini, bukan sesi yang dibangun sebelum perubahan terakhir Anda. Lalu kirim lalu lintas ke host di prefiks jauh dan pastikan penghitung bergerak, karena terowongan yang naik dan tidak melewatkan apa pun terlihat identik dengan yang berfungsi sampai Anda memeriksanya.
Simpan ketiga nilai di satu tempat dalam catatan Anda: alamat lokal yang dimiliki perangkat, titik akhir publik yang ditampilkan perangkat NAT, dan string identitas yang diharapkan peer. Ketiganya berubah karena alasan berbeda dan pada waktu berbeda.
Penomoran ulang perangkat NAT bukan alasan untuk menyentuh local-gw milik FortiGate, dan perubahan identitas bukan alasan untuk menomori ulang apa pun. Mencampur keduanya adalah cara terowongan yang berfungsi dibangun ulang selama jendela pemeliharaan yang tidak terkait. Panduan NAT Cloud VPN adalah rujukan untuk topologi yang didukung di sisi itu.
Uji yang menyelesaikannya membosankan dan cepat: tangkap di antarmuka eksternal, pastikan UDP 500 dan 4500 datang dari peer, pastikan identitas dalam pertukaran IKE cocok dengan yang dikonfigurasi untuk diharapkan peer, lalu pastikan pemilih yang dinegosiasikan mencakup subnet yang Anda pedulikan. Jika pemeriksaan pertama gagal, perangkat NAT adalah tersangkanya. Jika yang kedua gagal, kolom identitaslah penyebabnya. Jika yang ketiga gagal, NAT maupun identitas tidak pernah menjadi masalah.