VPN S2S Azure tersambung tetapi tanpa lalu lintas: baca log IKE

Portal menulis Connected, terowongan punya penghitung waktu aktif, dan trace dari mesin virtual Anda mati pada hop kedua. Status koneksi menjelaskan negosiasi IKE dan IPsec, bukan apakah satu paket pun selamat melewati lapisan kebijakan di kedua sisi. Dua kesalahan menjelaskan sebagian besar tiket ini, dan tidak satu pun diperbaiki dengan mengubah rute Azure. Keduanya sudah tertulis di log yang dihasilkan gateway, karena itu saya mulai dari sana, bukan dari tabel rute.

Apa yang sebenarnya disertifikasi Connected

Koneksi site-to-site yang tersambung berarti bahwa fase 1 dan fase 2 selesai dan asosiasi keamanan aktif. Itu adalah pernyataan tentang negosiasi: kedua peer menyetujui sebuah proposal, bertukar kunci, dan memasang pasangan SA. Itu tidak mengatakan apa pun tentang apakah pemilih lalu lintas cocok dengan subnet yang Anda anggap terlindungi, dan tidak juga tentang apakah sisi jauh akan merutekan paket ke suatu tempat setelah mendekripsinya. Terowongan dapat bertahan berminggu-minggu sambil membuang setiap aliran yang menarik, dan itulah pola yang membuat orang membangun ulang gateway yang sehat.

Dua kesalahan yang layak diperiksa lebih dulu adalah peer yang mengusulkan AH alih-alih ESP, dan jaringan virtual yang dinomori di ruang yang tidak akan dianggap internal oleh gateway.

Buka log yang diekspor sebelum menyentuh rute

Di portal, buka gateway jaringan virtual dan jalankan operasi VPN troubleshoot pada koneksi, lalu unduh bundel yang dihasilkannya dan ekstrak. Di dalamnya ada log IKE dengan pertukaran fase 1 dan fase 2, bertanda waktu dan dapat dibaca sebagai teks biasa. Cari baris transform di dalamnya alih-alih membaca dari atas ke bawah, karena entri yang menarik biasanya beberapa ratus baris di dalamnya. Jika Anda tidak punya akses portal, diagnostik yang sama muncul di tujuan log gateway saat pengaturan diagnostik diaktifkan.

Dua entri membawa sebagian besar nilainya. Yang pertama berbunyi kira-kira expected ESP with combined authentication and cipher, received AH. Yang kedua adalah kesalahan payload tidak valid selama pertukaran IKE, yang biasanya berarti bidang proposal salah bentuk atau tidak didukung.

Keduanya menjelaskan apa yang ditawarkan perangkat lokal, jadi keduanya pengaturan di sisi peer. Membuat ulang sisi Azure dari koneksi tidak mengubah proposal yang dikirim firewall Anda, dan tetap melakukannya adalah jam yang paling sering terbuang dalam alur kerja ini. Pada peer, atur fase 2 ke ESP dengan autentikasi dan cipher gabungan dan biarkan ia menegosiasikan algoritme, lalu periksa apakah kotak centang vendor dengan nama seperti combined mode diam-diam memilih proposal AH di bawahnya.

Konfirmasi ruang alamat jaringan virtual

Gateway mengharapkan jaringan virtual berada di rentang privat. Jaringan yang dinomori di blok publik, misalnya yang dimulai dengan 111.x, dapat menaikkan terowongan sementara Azure menolak memperlakukan ruang itu sebagai internal, sehingga koneksi terlihat sehat dan tidak ada aliran yang diterima. Konfirmasi ruang alamat sebelum Anda menghabiskan seharian dengan pemilih. Jika penomoran adalah persyaratan keras dari alokasi lama, perbaikannya adalah perubahan rencana alamat, bukan gateway lain.

Catat tumpang tindih dengan rentang lokal saat Anda berada di bilah ruang alamat, karena prefiks yang tumpang tindih menghasilkan kegagalan berbeda yang dari sisi klien terlihat serupa.

Verifikasi prefiks di kedua arah

Sumber daya gateway jaringan lokal menyimpan prefiks lokal, dan prefiks itu harus cocok dengan subnet yang benar-benar dilindungi perangkat jauh. Ringkasan yang menyertakan alamat yang dibuang perangkat akan meloloskan sebagian aliran dan gagal pada yang lain, yang terbaca sebagai kesalahan perutean berkala, bukan ketidakcocokan konfigurasi. Periksa juga sisi jauh: satu ujung mencantumkan /16 sementara ujung lain mencantumkan tiga /24 di dalamnya — itu kegagalan sebagian yang klasik. Tidak ada daftar yang otoritatif sendiri, jadi bandingkan keduanya berdampingan alih-alih memercayai yang dapat Anda lihat.

Perubahan prefiks tidak selalu diambil sendiri, jadi rencanakan untuk menyimpan ulang atau membuat ulang objek koneksi lalu konfirmasi prefiks baru muncul di kedua sisi.

Uji jalur, bukan ping

Trace yang memisahkan terowongan yang berfungsi dari rute yang berfungsi tampak seperti ini: hop pertama adalah gateway lokal, lalu beberapa hop yang tidak menjawab, lalu host jauh menjawab. Jika trace tidak pernah mencapai host, uji port TCP yang benar-benar dipakai aplikasi, karena ICMP cukup sering difilter sehingga ping yang gagal membuktikan sangat sedikit. Jalankan trace yang sama dari host jauh menuju mesin virtual di Azure. Asimetri antara kedua hasil adalah cara tercepat menemukan rute balik yang hilang atau aturan yang hanya mengizinkan satu arah.

Tulis proposal peer, kedua ruang alamat, dan waktu pembuatan koneksi ke dalam tiket, agar insinyur berikutnya tahu nilai mana yang dibangun ulang dan mana yang tidak pernah disentuh.

Jika log kembali kosong, gateway mungkin tidak menerminasi koneksi Anda sama sekali. Konfirmasi bahwa alamat peer pada gateway jaringan lokal cocok dengan perangkat tempat Anda membaca log, karena dua gateway dalam satu langganan mudah tertukar saat pembangunan ulang. Kesalahan itu memakan waktu sehari dan tidak meninggalkan jejak di log mana pun.