VPN situs-ke-situs Azure dengan peer di belakang NAT: daftar periksa

Lakukan pemeriksaan ini secara berurutan dan berhenti pada yang pertama gagal. Sebagian besar laporan bahwa Azure tidak mendukung perangkat di belakang NAT ternyata adalah alamat peer yang tidak dapat dijangkau Azure, atau terowongan yang tidak pernah dimulai dari sisi yang benar. Transportasi luar dan perutean dalam adalah dua masalah berbeda, dan mencampurnya membuang satu sore. Setiap langkah di bawah menghasilkan pengamatan yang bisa Anda serahkan kepada orang lain.

Langkah 1: pastikan peer memang berada di belakang NAT

Bandingkan alamat pada antarmuka WAN perangkat dengan alamat yang dilihat Azure untuknya. Jika berbeda, ada sesuatu yang menerjemahkan, dan penerjemah itu kini menjadi bagian dari desain VPN Anda. Tanyakan kepada penyedia apakah pemetaannya statis atau bersama, karena pemetaan bersama mengubah apa yang bisa Anda andalkan. Perangkat dengan alamat WAN privat dan tanpa penerusan adalah kasus berbeda dari perangkat di belakang NAT tingkat operator dengan pemetaan publik yang stabil.

Jika kedua alamat cocok, berhentilah di sini: NAT bukan masalah Anda dan sisa daftar ini tidak akan membantu.

Catat kedua alamat dan model penerjemah di tiket. Satu baris itu mencegah putaran pertanyaan berikutnya tentang mengapa peer yang dikonfigurasi tidak menjawab.

Langkah 2: sepakati siapa yang memulai

FAQ Azure VPN Gateway menyebutkan dukungan NAT-T dan menambahkan bahwa perangkat lokal harus memulai terowongan IPsec saat berada di belakang NAT. Itu sesuai dengan cara kerja penerjemahan stateful, karena penerjemah mempertahankan pemetaan sebab perangkat dalam mengirim paket pertama. Jika Azure diharapkan memulai dan tidak ada yang datang untuk membuat pemetaan itu, terowongan tidak pernah mulai.

Konfigurasikan peer agar kesalahan hanya-penjawab menjadi jelas, dan periksa apakah perangkat mencoba lagi sendiri atau butuh pemicu. Sebagian perangkat hanya mengangkat terowongan saat ada lalu lintas menarik, yang tidak masalah sampai lalu lintas menarik itu adalah pemeriksaan kesehatan yang tidak pernah datang.

Amati pertukaran IKE pada perangkat selama inisiasi manual; kesunyian di sana adalah jawaban perutean atau firewall, bukan jawaban Azure.

Langkah 3: dapatkan alamat peer dengan benar

Azure memerlukan alamat publik yang dapat dijangkau untuk peer pada objek gateway jaringan lokalnya, biasanya alamat publik penerjemah, bukan alamat dalam perangkat. Identitas yang dipakai perangkat untuk mengautentikasi adalah bidang terpisah dan sah-sah saja berbeda dari alamat yang dihubungi Azure. Jaga keduanya tetap terpisah, karena menukarnya menghasilkan kegagalan autentikasi yang tampak persis seperti masalah NAT.

Jika alamat publik berubah, objek itu harus berubah bersamanya. Nama yang mengarah ke alamat lama lebih buruk daripada alamat statis yang harus Anda perbarui secara manual.

Tuliskan ketiga nilai: alamat lokal perangkat, alamat publik hasil penerjemahan, identitas peer yang dikonfigurasi.

Langkah 4: buka hanya port yang dibutuhkan NAT-T

NAT-T membawa ESP di dalam UDP, dan RFC 3948 menjelaskan enkapsulasi itu dengan port 4500 yang digunakan setelah negosiasi awal pada port 500. Firewall dan penerjemah Anda keduanya harus mengizinkan pertukaran dan lalu lintas balasannya. Mengizinkan port TCP yang tidak terkait tidak membuktikan apa pun tentang jalur ini, dan aturan yang mengizinkan keluar tetapi bukan balasannya tetap akan gagal.

Penerusan port masuk statis tidak otomatis diperlukan ketika peer memulai dan penerjemah menyimpan status. Itu menjadi perlu ketika pemetaan tidak stabil atau ketika sesuatu di jalur menghapus status secara agresif.

Tangkap sekali di kedua sisi penerjemah; perbedaan enkapsulasi langsung terlihat.

Langkah 5: pisahkan transportasi luar dari perutean dalam

Terowongan yang terbentuk dan tidak membawa apa pun adalah masalah perutean, bukan masalah NAT-T. Situs masih memerlukan pemilih lalu lintas yang kompatibel, ruang alamat yang cocok, aturan akses, dan jalur balik untuk jaringan aplikasi. Tidak satu pun dari itu disediakan oleh pertukaran IKE yang berhasil.

Jika kedua situs memakai rentang privat yang tumpang tindih, penerjemahan di dalam terowongan adalah desain terpisah dengan aturannya sendiri. Jangan menomori ulang subnet hanya karena gateway luar kebetulan berada di belakang router rumah.

Klasifikasikan kegagalan menurut tahap sebelum Anda mengubah apa pun, dan simpan klasifikasi itu di tiket agar orang berikutnya mulai dari tempat Anda berhenti.