VM Azure tidak dapat mencapai IMDS atau WireServer selepas VPN bermula

VM hidup, klien VPN berkata ia bersambung, dan beberapa minit kemudian ejen Azure mula melaporkan keadaan tidak sihat. Kadang-kadang SSH bertahan dan Run Command dari portal tidak, yang membuat orang memeriksa ejen dan bukan jadual laluan. Keputusan penghantaran tetamu sendiri berubah apabila terowong naik, dan dua alamat platform biasanya menjadi mangsa pertama. Saya menganggapnya sebagai gejala penghalaan sebelum menganggapnya kegagalan ejen.

Gejalanya kelihatan seperti ejen rosak

Kedua-dua alamat di bawah dicadangkan sebagai pembaikan, tetapi ia bukan perkhidmatan yang sama. Menyalin /32 untuk satu kerana ia berkesan untuk yang lain ialah cara penyelesaian sementara menjadi konfigurasi kekal yang tiada siapa berani buang.

Urutan yang berkesan ialah sahkan alamat mana yang sebenarnya disasarkan oleh panggilan yang gagal, kemudian baca bagaimana tetamu menyelesaikannya. Selain itu hanya tekaan dengan langkah tambahan dan tetingkap perubahan yang lebih panjang.

168.63.129.16 bukan destinasi awam

168.63.129.16 ialah alamat platform maya khas Azure, dan salah satu peranannya ialah WireServer, yang digunakan ejen VM untuk bercakap dengan fabrik. Microsoft mendokumenkan bahawa trafik ejen ke port TCP 80 dan 32526 mesti kekal tersedia. Ia bukan hos internet biasa, dan bukan sesuatu yang perlu dibawa VPN terowong penuh ke pintu keluar jauh. Itulah sebabnya terowong yang kelihatan sihat masih boleh membuat ejen kelaparan.

Dokumentasi alamat platform juga menyatakan alamat ini tidak tertakluk kepada laluan yang ditentukan pengguna, yang merupakan sifat fabrik Azure dan bukan janji tentang tetamu anda. Peraturan firewall tempatan atau dasar penghalaan klien VPN sendiri masih boleh memutuskan laluan, dan kedua-duanya tidak tinggal dalam jadual laluan VNet.

Jika ejen yang melaporkan masalah, periksa keadaan perkhidmatan dan laluan ke alamat itu sebelum memasang semula apa-apa.

169.254.169.254 mempunyai peraturannya sendiri

169.254.169.254 ialah alamat link-local untuk Azure Instance Metadata Service. Permintaan kepadanya mempunyai syaratnya sendiri: NIC primer dan IP primer, konfigurasi DHCP yang menyokong alamat itu, dan memintas mana-mana proksi HTTP. Menghantarnya melalui pintu keluar VPN jauh atau gateway internet sewenang-wenangnya bukan model akses yang diterangkan Microsoft.

Fasal proksi itu menangkap orang yang telah membaiki laluan tetapi masih melihat kegagalan. Proksi HTTP dalam tetamu boleh merosakkan IMDS sementara ip route get memulangkan tepat antara muka yang anda jangkakan, jadi periksa pengecualian proksi selain laluan.

Jangan tampal respons metadata ke dalam tiket sokongan semasa menyahpepijat ini. Ia mungkin membawa kelayakan dan butiran instans yang bertahan lebih lama daripada insiden.

Baca penghalaan dasar tetamu, bukan hanya jadual utama

Pada tetamu Linux, tiga arahan baca sahaja memisahkan lapisan: ip -4 rule show untuk peraturan dasar, kemudian ip -4 route get 168.63.129.16 dan ip -4 route get 169.254.169.254 untuk keputusan yang benar-benar dibuat kernel. Jalankannya sebelum dan selepas VPN bersambung. Perbezaan antara dua output itu ialah set perubahan anda, dan ia lebih berguna daripada sebarang tekaan tentang apa yang klien lakukan.

Klien VPN yang memasang peraturan dasar boleh membiarkan jadual utama tidak tersentuh sambil masih mengubah hala carian itu. Itulah sebabnya pembaikan yang hanya menyentuh jadual utama kelihatan berkesan pada satu hos dan tidak melakukan apa-apa pada hos seterusnya. Tetamu dengan berbilang NIC menambah masalah yang sama dari arah lain, kerana jawapannya bergantung pada NIC dan alamat sumber yang dipilih peraturan.

Bertahanlah daripada resipi yang menambah kedua-dua laluan /32 melalui gateway lama. Laluan platform link-local dan hop seterusnya WAN umum ialah objek berbeza, dan pengecualian menyeluruh menyembunyikan konflik dasar sebenar.

Asingkan pentadbiran dan pemulihan

Balasan SSH atau RDP anda juga boleh ditangkap oleh default terowong penuh, tetapi ia menyasarkan alamat yang diperhatikan pentadbir dan bukan mana-mana titik akhir platform. Diagnosisnya daripada pasangan permintaan-balasan sendiri, dan kekalkan saluran pemulihan bebas seperti konsol bersiri sebelum menukar dasar VPN. Jika penggunaan semula memulakan semula VM dan ejen melaporkan tidak sihat, periksa tindakan yang direkodkan dan perkhidmatan yang bertanggungjawab dan bukannya menganggap perubahan laluan menyebabkan but semula.

Kemudian sahkan tiga aliran secara berasingan: sumber peribadi yang benar-benar anda mahu, komunikasi ejen dan platform yang disokong, dan laluan pentadbiran. Memulihkan satu daripadanya bukan bukti dua yang lain terselamat.

Tulis pengecualian yang diluluskan di bawah pemilik rangkaian tetamu dan konfigurasi VPN, termasuk apa yang berlaku semasa menyambung semula dan memulakan semula. UDR Azure bukan jadual laluan tetamu, dan menyuntingnya tidak akan membaiki peraturan dasar tempatan.