Azure P2S: satu klien Windows kehilangan laluan selepas perubahan VNet

Dua komputer riba mengesahkan identiti pada gateway Azure point-to-site yang sama, dan hanya satu mencapai VNet yang baru disambungkan. Kedua-duanya menunjukkan Connected, jadi pengesahan bukan perbezaannya; laluan destinasi yang dipegangnya ialah perbezaannya. Mulakan dengan klien yang gagal, bandingkan satu destinasi, dan hanya selepas itu tentukan sama ada pakej gateway atau jadual laluan setempat memiliki jurang itu.

Mulakan dengan klien yang gagal, bukan gateway

Sahkan topologi sebelum menyalahkan komputer riba. Periksa VNet mana yang disambungkan ke VNet gateway dan sama ada rangkaian baharu di-peer secara langsung atau dicapai melalui terowong site-to-site berasingan. Jika VNet baharu tidak disambungkan sama sekali ke VNet gateway, tiada pakej klien boleh menghalakan ke sana, dan komputer riba yang berfungsi ialah anomali yang perlu dijelaskan. Catat jawapannya, kerana ia menentukan sama ada anda nyahpepijat klien atau gateway.

Sebaik topologi betul, letakkan kedua-dua komputer riba bersebelahan. Gateway sama, kolam alamat sama, protokol sama dan binaan klien sama ialah perbandingan yang anda mahu; apa-apa lagi ialah pemboleh ubah kedua yang perlu dihapuskan kemudian.

Bandingkan satu destinasi dengan route print

Pilih IP sumber yang dibenarkan dan bandingkan kedua-dua komputer riba dua kali: terputus, kemudian bersambung. Dalam Windows, route print -4 menyenaraikan laluan IPv4 dengan awalan destinasi, antara muka, hop seterusnya dan metrik. Rekod baris yang benar-benar akan menang untuk destinasi itu dan bukannya mengira entri yang mengandungi perkataan VPN.

Pemilihan ialah awalan terpanjang dahulu, kemudian metrik, jadi laluan setempat yang lebih khusus boleh mengalahkan laluan terowong tanpa kelihatan salah. Jika destinasi yang dimaksudkan berada dalam 10.24.0.0/16, klien sihat menunjukkan laluan yang sepadan pada antara muka VPN, manakala klien yang gagal menghantar alamat yang sama ke gateway lalainya.

Awalan setempat yang bercanggah boleh menghasilkan gejala yang sama. Sebelum menambah apa-apa, tentukan yang mana antara dua kes yang anda hadapi: tiada langsung laluan terowong, atau laluan terowong yang kalah kepada yang lebih khusus.

TTL expired bukan pepijat pengagihan laluan

Ping yang mengembalikan TTL expired in transit menyatakan paket telah menghabiskan kuota hopnya, yang biasanya bermaksud gelung penghantaran dan bukan pemacu VPN rosak. Ping Windows menerima TTL sehingga 255, dan menaikkan nilai itu tidak membaiki gelung; ia hanya melengahkan ralat yang sama. Anggap mesej itu sebagai gejala laluan, bukan bukti tentang pengagihan laluan.

Gunakan tracert -4 10.24.1.10 untuk melihat di mana laluan berulang. Jika dua hop yang sama muncul berulang kali, cari laluan yang menghantar trafik menuju terowong kembali ke terowong atau ke penghala setempat yang menghantarnya balik.

Jana semula pakej pada gateway yang memilikinya

Microsoft mendokumenkan bahawa pakej klien Windows mesti dimuat turun dan dipasang semula selepas perubahan topologi yang berkaitan. Dapatkan pakej semasa daripada gateway Azure yang menyediakan profil ini, kemudian gunakannya dengan proses yang disokong untuk klien itu. Menggantikan fail boleh laku aplikasi VPN yang tidak berkaitan bukan operasi yang sama seperti menjana semula tetapan khusus gateway. Memuat turun pakej semula itu murah; meneka laluan setempat tidak.

Sambung semula dan baca semula laluan untuk destinasi asal. Simpan baris sebelum dan selepas bersama rekod perubahan supaya hasilnya lebih tepat daripada saya memasang semula klien.

Senario penghalaan Azure P2S memisahkan VNet yang di-peer secara langsung daripada rangkaian yang dicapai melalui terowong lain, dan pakej baharu tidak boleh menjadikan peering transitif. Sesetengah senario Windows site-to-site atau BGP juga memerlukan laluan jauh yang dikonfigurasikan secara manual, jadi penyegaran pakej bukan mekanisme pengagihan laluan sejagat.

Kekalkan laluan sementara sebagai sementara

Laluan manual boleh mengasingkan laluan klien yang hilang, tetapi binanya daripada reka bentuk sebenar: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, tanpa bendera berterusan, supaya ia hilang semasa but semula. Pilih indeks antara muka dan hop seterusnya daripada penyesuai VPN yang bersambung, bukan daripada tekaan.

Jangan tinggalkan laluan eksperimen sebagai pemilik pesaing kekal. Kemas kini profil masa depan mungkin menambah awalan yang sama dengan metrik berbeza, dan kemudian entri manual secara senyap menentukan laluan mana yang menang. Catat langkah penyingkiran dalam perubahan.

Sebaik laluan yang betul aktif, uji aplikasi sasaran dan bukan ping. Jika paket sampai ke Azure tetapi perkhidmatan masih gagal, periksa kumpulan keselamatan rangkaian dan laluan pulang, kerana kedua-duanya berasingan daripada sama ada komputer riba telah mempelajari awalan itu.