VPN tapak-ke-tapak Azure dengan rakan di belakang NAT: senarai semak

Lakukan semakan ini mengikut urutan dan berhenti pada yang pertama gagal. Kebanyakan laporan bahawa Azure tidak menyokong peranti di belakang NAT sebenarnya ialah alamat rakan yang tidak dapat dicapai oleh Azure, atau terowong yang tidak pernah dimulakan dari sisi yang betul. Pengangkutan luar dan penghalaan dalam ialah dua masalah berbeza, dan mencampurkannya membazirkan satu petang. Setiap langkah di bawah menghasilkan pemerhatian yang boleh anda serahkan kepada orang lain.

Langkah 1: sahkan rakan memang berada di belakang NAT

Bandingkan alamat pada antara muka WAN peranti dengan alamat yang dilihat Azure untuknya. Jika berbeza, ada sesuatu yang menterjemah, dan penterjemah itu kini sebahagian daripada reka bentuk VPN anda. Tanya penyedia sama ada pemetaan itu statik atau dikongsi, kerana pemetaan dikongsi mengubah apa yang boleh anda harapkan. Peranti dengan alamat WAN peribadi dan tanpa pemajuan ialah kes berbeza daripada peranti di belakang NAT gred pembawa dengan pemetaan awam yang stabil.

Jika kedua-dua alamat sepadan, berhenti di sini: NAT bukan masalah anda dan selebihnya senarai ini tidak akan membantu.

Catat kedua-dua alamat dan model penterjemah dalam tiket. Satu baris itu menghalang pusingan soalan seterusnya tentang mengapa rakan yang dikonfigurasi tidak menjawab.

Langkah 2: sepakat siapa yang memulakan

Soalan Lazim Azure VPN Gateway menyatakan sokongan NAT-T dan menambah bahawa peranti tempatan harus memulakan terowong IPsec apabila ia berada di belakang NAT. Itu sepadan dengan cara terjemahan berkeadaan berfungsi, kerana penterjemah menyimpan pemetaan kerana peranti dalam menghantar paket pertama. Jika Azure dijangka memulakan dan tiada apa datang untuk mencipta pemetaan itu, terowong tidak pernah bermula.

Konfigurasikan rakan supaya kesilapan hanya-penjawab menjadi jelas, dan semak sama ada peranti mencuba semula sendiri atau memerlukan pencetus. Sesetengah peranti hanya menaikkan terowong apabila trafik menarik muncul, yang baik sehingga trafik menarik itu ialah pemeriksaan kesihatan yang tidak pernah datang.

Perhatikan pertukaran IKE pada peranti semasa permulaan manual; kesunyian di situ ialah jawapan penghalaan atau tembok api, bukan jawapan Azure.

Langkah 3: dapatkan alamat rakan dengan betul

Azure memerlukan alamat awam yang boleh dicapai untuk rakan dalam objek gerbang rangkaian tempatannya, biasanya alamat awam penterjemah dan bukan alamat dalam peranti. Identiti yang digunakan peranti untuk mengesahkan dirinya ialah medan berasingan dan boleh berbeza secara sah daripada alamat yang didail Azure. Jaga kedua-duanya berasingan, kerana menukarnya menghasilkan kegagalan pengesahan yang kelihatan sama seperti masalah NAT.

Jika alamat awam berubah, objek itu mesti berubah bersamanya. Nama yang menyelesaikan kepada alamat lama lebih buruk daripada alamat statik yang perlu anda kemas kini secara manual.

Tuliskan ketiga-tiga nilai: alamat tempatan peranti, alamat awam yang diterjemah, identiti rakan yang dikonfigurasi.

Langkah 4: buka hanya port yang diperlukan NAT-T

NAT-T membawa ESP di dalam UDP, dan RFC 3948 menerangkan enkapsulasi itu dengan port 4500 digunakan selepas rundingan awal pada port 500. Tembok api dan penterjemah anda kedua-duanya mesti membenarkan pertukaran itu dan trafik balasnya. Membenarkan port TCP yang tidak berkaitan tidak membuktikan apa-apa tentang laluan ini, dan peraturan yang membenarkan keluar tetapi bukan balasan tetap akan gagal.

Pemajuan port masuk statik tidak semestinya diperlukan apabila rakan memulakan dan penterjemah menyimpan keadaan. Ia menjadi perlu apabila pemetaan tidak stabil atau apabila sesuatu di laluan itu menghabiskan keadaan secara agresif.

Tangkap sekali pada kedua-dua belah penterjemah; perbezaan enkapsulasi segera kelihatan.

Langkah 5: pisahkan pengangkutan luar daripada penghalaan dalam

Terowong yang terbentuk dan tidak membawa apa-apa ialah masalah penghalaan, bukan masalah NAT-T. Tapak masih memerlukan pemilih trafik yang serasi, ruang alamat yang sepadan, peraturan akses dan laluan balik untuk rangkaian aplikasi. Tiada satu pun daripada itu disediakan oleh pertukaran IKE yang berjaya.

Jika kedua-dua tapak menggunakan julat peribadi yang bertindih, terjemahan di dalam terowong ialah reka bentuk berasingan dengan peraturannya sendiri. Jangan menomborkan semula subrangkaian hanya kerana gerbang luar kebetulan berada di belakang penghala rumah.

Kelaskan kegagalan mengikut peringkat sebelum anda mengubah apa-apa, dan simpan klasifikasi itu dalam tiket supaya orang seterusnya bermula di tempat anda berhenti.