Azure P2S: satu klien Windows kehilangan rute setelah perubahan VNet

Dua laptop mengautentikasi ke gateway Azure point-to-site yang sama, dan hanya satu yang mencapai VNet yang baru terhubung. Keduanya menampilkan Connected, jadi autentikasi bukan pembedanya; rute tujuan yang mereka pegang adalah pembedanya. Mulai dari klien yang gagal, bandingkan satu tujuan, dan baru setelah itu putuskan apakah paket gateway atau tabel rute lokal yang memiliki celah ini.

Mulai dari klien yang gagal, bukan dari gateway

Pastikan topologinya sebelum menyalahkan laptop. Periksa VNet mana yang terhubung ke VNet gateway dan apakah jaringan baru di-peer langsung atau dijangkau melalui tunnel site-to-site terpisah. Jika VNet baru sama sekali tidak terhubung ke VNet gateway, tidak ada paket klien yang bisa merutekan ke sana, dan laptop yang berfungsi adalah anomali yang harus dijelaskan. Catat jawabannya, karena itu menentukan apakah Anda mendebug klien atau gateway.

Setelah topologi benar, letakkan kedua laptop berdampingan. Gateway sama, kumpulan alamat sama, protokol sama, dan versi klien sama adalah perbandingan yang Anda inginkan; hal lain adalah variabel kedua yang harus Anda singkirkan nanti.

Bandingkan satu tujuan dengan route print

Pilih IP sumber daya yang diizinkan dan bandingkan kedua laptop dua kali: terputus, lalu terhubung. Di Windows, route print -4 mencantumkan rute IPv4 dengan prefiks tujuan, antarmuka, hop berikutnya, dan metrik. Catat baris yang benar-benar akan menang untuk tujuan itu alih-alih menghitung entri yang memuat kata VPN.

Pemilihan dilakukan berdasarkan prefiks terpanjang lebih dulu, lalu metrik, sehingga rute lokal yang lebih spesifik bisa mengalahkan rute tunnel tanpa terlihat salah. Jika tujuan yang dimaksud berada di dalam 10.24.0.0/16, klien sehat menampilkan rute yang cocok pada antarmuka VPN, sedangkan klien yang gagal mengirim alamat yang sama ke gateway default-nya.

Prefiks lokal yang bertentangan dapat menimbulkan gejala yang sama. Sebelum menambahkan apa pun, tentukan mana dari dua kasus yang Anda hadapi: tidak ada rute tunnel sama sekali, atau rute tunnel yang kalah dari rute yang lebih spesifik.

TTL expired bukan bug distribusi rute

Ping yang mengembalikan TTL expired in transit menyatakan paket menghabiskan jatah hop-nya, yang biasanya berarti loop penerusan, bukan driver VPN rusak. Ping Windows menerima TTL hingga 255, dan menaikkan nilai itu tidak memperbaiki loop; hanya menunda galat yang sama. Perlakukan pesan itu sebagai gejala jalur, bukan bukti tentang distribusi rute.

Gunakan tracert -4 10.24.1.10 untuk melihat di mana jalur berulang. Jika dua hop yang sama muncul terus-menerus, cari rute yang mengirim lalu lintas menuju tunnel kembali ke tunnel atau ke router lokal yang meneruskannya kembali.

Buat ulang paket di gateway yang memilikinya

Microsoft mendokumentasikan bahwa paket klien Windows harus diunduh dan dipasang ulang setelah perubahan topologi yang relevan. Ambil paket terbaru dari gateway Azure yang melayani profil ini, lalu terapkan dengan proses yang didukung untuk klien tersebut. Mengganti berkas eksekusi aplikasi VPN yang tidak terkait bukan operasi yang sama dengan membuat ulang setelan khusus gateway. Mengunduh paket lagi itu murah; menebak rute lokal tidak.

Sambungkan ulang dan baca lagi rute untuk tujuan semula. Simpan baris sebelum dan sesudah bersama catatan perubahan agar hasilnya lebih tepat daripada saya memasang ulang kliennya.

Skenario perutean Azure P2S memisahkan VNet yang di-peer langsung dari jaringan yang dijangkau melalui tunnel lain, dan paket baru tidak dapat membuat peering menjadi transitif. Beberapa skenario Windows site-to-site atau BGP juga memerlukan rute jarak jauh yang dikonfigurasi manual, jadi penyegaran paket bukan mekanisme distribusi rute yang universal.

Biarkan rute sementara tetap sementara

Rute manual dapat mengisolasi rute klien yang hilang, tetapi bangun dari desain sebenarnya: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, tanpa flag persisten, sehingga hilang saat reboot. Pilih indeks antarmuka dan hop berikutnya dari adaptor VPN yang terhubung, bukan dari tebakan.

Jangan biarkan rute eksperimental menjadi pemilik pesaing permanen. Pembaruan profil di masa depan dapat menambahkan prefiks yang sama dengan metrik berbeda, lalu entri manual diam-diam menentukan jalur mana yang menang. Catat langkah penghapusannya dalam perubahan.

Setelah rute yang benar aktif, uji aplikasi target alih-alih ping. Jika paket mencapai Azure tetapi layanan tetap gagal, periksa grup keamanan jaringan dan jalur balik, karena keduanya terpisah dari apakah laptop sudah mempelajari prefiks tersebut.