VM Azure tidak bisa mencapai IMDS atau WireServer setelah VPN menyala

VM menyala, klien VPN mengaku terhubung, dan beberapa menit kemudian agen Azure mulai melaporkan kondisi tidak sehat. Kadang SSH bertahan sementara Run Command dari portal tidak, yang membuat orang memeriksa agen alih-alih tabel rute. Keputusan penerusan milik tamu berubah saat terowongan naik, dan dua alamat platform biasanya menjadi korban pertama. Saya memperlakukannya sebagai gejala perutean sebelum memperlakukannya sebagai kegagalan agen.

Gejalanya tampak seperti agen rusak

Kedua alamat di bawah ini diajukan sebagai perbaikan, padahal keduanya bukan layanan yang sama. Menyalin /32 untuk satu karena berhasil untuk yang lain justru cara akal-akalan sementara menjadi konfigurasi permanen yang tak ada yang berani menghapus.

Urutan yang berhasil adalah memastikan alamat mana yang benar-benar dituju panggilan yang gagal, lalu membaca bagaimana tamu menyelesaikannya. Selain itu hanya menebak dengan langkah tambahan dan jendela perubahan yang lebih panjang.

168.63.129.16 bukan tujuan publik

168.63.129.16 adalah alamat platform virtual khusus Azure, dan salah satu perannya adalah WireServer, yang dipakai agen VM untuk berbicara dengan fabric. Microsoft mendokumentasikan bahwa lalu lintas agen ke port TCP 80 dan 32526 harus tetap tersedia. Ini bukan host internet biasa, dan bukan sesuatu yang seharusnya dibawa VPN terowongan penuh ke pintu keluar jarak jauh. Itulah sebabnya terowongan yang tampak sehat tetap bisa membuat agen kelaparan.

Dokumentasi alamat platform juga menyatakan alamat ini tidak tunduk pada rute yang ditentukan pengguna, yang merupakan sifat fabric Azure, bukan janji tentang tamu Anda. Aturan firewall lokal atau kebijakan perutean klien VPN sendiri masih bisa memutus jalur, dan keduanya tidak tinggal di tabel rute VNet.

Jika agen yang melaporkan masalah, periksa status layanan dan jalur ke alamat itu sebelum memasang ulang apa pun.

169.254.169.254 punya aturannya sendiri

169.254.169.254 adalah alamat link-local untuk Azure Instance Metadata Service. Permintaan ke alamat itu punya syaratnya sendiri: NIC primer dan IP primer, konfigurasi DHCP yang mendukung alamat tersebut, dan lewati proksi HTTP apa pun. Mengirimnya lewat pintu keluar VPN jarak jauh atau gateway internet sembarang bukan model akses yang dijelaskan Microsoft.

Klausul proksi itu menangkap orang yang sudah memperbaiki rute tetapi masih melihat kegagalan. Proksi HTTP di tamu dapat merusak IMDS sementara ip route get mengembalikan persis antarmuka yang Anda harapkan, jadi periksa pengecualian proksi selain rute.

Jangan menempelkan respons metadata ke tiket dukungan saat men-debug ini. Respons itu bisa membawa kredensial dan detail instans yang bertahan lebih lama dari insiden.

Baca perutean kebijakan tamu, bukan hanya tabel utama

Di tamu Linux, tiga perintah hanya-baca memisahkan lapisan: ip -4 rule show untuk aturan kebijakan, lalu ip -4 route get 168.63.129.16 dan ip -4 route get 169.254.169.254 untuk keputusan yang benar-benar diambil kernel. Jalankan sebelum dan sesudah VPN terhubung. Selisih kedua keluaran itulah kumpulan perubahan Anda, dan lebih berguna daripada dugaan apa pun tentang apa yang dilakukan klien.

Klien VPN yang memasang aturan kebijakan bisa membiarkan tabel utama tak tersentuh sambil tetap mengalihkan pencarian itu. Itu sebabnya perbaikan yang hanya menyentuh tabel utama tampak berhasil di satu host dan tidak melakukan apa pun di host berikutnya. Tamu dengan banyak NIC menambahkan masalah yang sama dari arah lain, karena jawabannya bergantung pada NIC dan alamat sumber yang dipilih aturan.

Lawan resep yang menambahkan kedua rute /32 lewat gateway lama. Jalur platform link-local dan lompatan berikutnya WAN umum adalah objek berbeda, dan pengecualian menyeluruh menyembunyikan konflik kebijakan yang sebenarnya.

Pisahkan administrasi dan pemulihan

Balasan SSH atau RDP Anda juga bisa ditangkap default terowongan penuh, tetapi balasan itu menyasar alamat teramati administrator, bukan salah satu titik akhir platform. Diagnosis dari pasangan permintaan-balasannya sendiri, dan pertahankan kanal pemulihan independen seperti konsol serial sebelum mengubah kebijakan VPN. Jika penerapan memulai ulang VM dan agen melaporkan tidak sehat, periksa tindakan yang tercatat dan layanan yang bertanggung jawab, bukan menganggap perubahan rute menyebabkan reboot.

Lalu verifikasi tiga aliran secara terpisah: sumber daya privat yang benar-benar Anda inginkan, komunikasi agen dan platform yang didukung, dan jalur administrasi. Memulihkan salah satunya bukan bukti dua lainnya selamat.

Tuliskan pengecualian yang disetujui atas nama pemilik jaringan tamu dan konfigurasi VPN, termasuk apa yang terjadi saat menyambung ulang dan memulai ulang. UDR Azure bukan tabel rute tamu, dan menyuntingnya tidak akan memperbaiki aturan kebijakan lokal.