VPN ishga tushgandan so'ng Azure VM IMDS yoki WireServer'ga yetib bormaydi

VM ishlayapti, VPN mijozi ulanganini aytadi, va bir necha daqiqadan so'ng Azure agenti nosog'lom holat haqida xabar bera boshlaydi. Ba'zan SSH tirik qoladi, portaldan Run Command ishlamaydi, bu odamlarni marshrut jadvali o'rniga agentga qarashga majbur qiladi. Tunnel ko'tarilganda mehmonning o'z yo'naltirish qarorlari o'zgardi va odatda ikkita platforma manzili birinchi qurbon bo'ladi. Men buni agent nosozligi deb emas, avvalo marshrutlash belgisi deb qabul qilaman.

Belgi buzilgan agentga o'xshaydi

Quyidagi ikkala manzil ham yechim sifatida taklif qilinadi, ammo ular bir xizmat emas. Biriga /32 nusxalash, chunki u boshqasiga ishlagan, vaqtinchalik yechimning hech kim o'chirishga jur'at etmaydigan doimiy konfiguratsiyaga aylanish yo'lidir.

Ishlaydigan tartib: avval muvaffaqiyatsiz chaqiruv aslida qaysi manzilga qaratilganini tasdiqlash, keyin mehmon uni qanday hal qilishini o'qish. Qolgani qo'shimcha qadamlar bilan taxmin va uzoqroq o'zgartirish oynasi.

168.63.129.16 ommaviy manzil emas

168.63.129.16 — Azure'ning maxsus virtual platforma manzili, va uning rollaridan biri WireServer bo'lib, VM agenti undan fabric bilan gaplashish uchun foydalanadi. Microsoft agentning TCP 80 va 32526 portlariga trafigi mavjud bo'lib qolishi kerakligini hujjatlashtiradi. Bu oddiy internet hosti emas va to'liq tunnel VPN uni uzoq chiqishga olib borishi kerak emas. Shuning uchun sog'lom ko'rinadigan tunnel ham agentni och qoldirishi mumkin.

Platforma manzili hujjati ham bu manzil foydalanuvchi belgilagan marshrutlarga bo'ysunmasligini aytadi; bu Azure fabric xususiyati, mehmoningiz haqida va'da emas. Mahalliy firewall qoidasi yoki VPN mijozining o'z marshrutlash siyosati yo'lni buzishi mumkin va ularning hech biri VNet marshrut jadvalida yashamaydi.

Agar muammoni agent xabar qilsa, biror narsani qayta o'rnatishdan oldin xizmat holati va o'sha manzilga yo'lni tekshiring.

169.254.169.254 ning o'z qoidalari bor

169.254.169.254 — Azure Instance Metadata Service uchun link-local manzil. Unga yuborilgan so'rovlarning o'z talablari bor: asosiy NIC va asosiy IP, manzilni qo'llab-quvvatlaydigan DHCP konfiguratsiyasi va har qanday HTTP proksini chetlab o'tish. Ularni uzoq VPN chiqishi yoki ixtiyoriy internet shlyuzi orqali yuborish Microsoft ta'riflagan kirish modeli emas.

Bu proksi bandi marshrutni tuzatib, hali ham xatoliklarni ko'rayotganlarni ushlaydi. Mehmondagi HTTP proksi IMDSni buzishi mumkin, ip route get esa aynan kutgan interfeysni qaytaradi, shuning uchun marshrutlar bilan birga proksi istisnolarini ham tekshiring.

Buni tuzatayotganda metadata javoblarini qo'llab-quvvatlash chiptasiga yopishtirmang. Ular hodisadan uzoqroq yashaydigan hisob ma'lumotlari va instans tafsilotlarini olib yurishi mumkin.

Mehmonning siyosat marshrutlashini o'qing, faqat asosiy jadvalni emas

Linux mehmonida uchta faqat-o'qish buyrug'i qatlamlarni ajratadi: siyosat qoidalari uchun ip -4 rule show, so'ng yadro haqiqatda qabul qiladigan qarorlar uchun ip -4 route get 168.63.129.16 va ip -4 route get 169.254.169.254. Ularni VPN ulanmasidan oldin va keyin ishga tushiring. Bu ikki chiqish orasidagi farq sizning o'zgarishlar to'plamingiz va mijoz nima qilgani haqidagi har qanday taxmindan foydaliroq.

Siyosat qoidalarini o'rnatadigan VPN mijozi asosiy jadvalni tegmasdan qoldirib, o'sha qidiruvlarni baribir yo'naltirishi mumkin. Shuning uchun faqat asosiy jadvalni tuzatuvchi yechim bir hostda ishlayotgandek ko'rinadi, keyingisida hech narsa qilmaydi. Bir nechta NICli mehmonlar xuddi shu muammoni boshqa tomondan qo'shadi, chunki javob qoida qaysi NIC va manba manzilini tanlashiga bog'liq.

Ikkala /32 marshrutni eski shlyuz orqali qo'shadigan retseptga qarshi turing. Link-local platforma yo'li va umumiy WAN keyingi sakrashi boshqa obyektlar, umumiy istisno esa haqiqiy siyosat ziddiyatini yashiradi.

Boshqaruv va tiklashni alohida saqlang

Sizning SSH yoki RDP javobingiz ham to'liq tunnel standart yo'li bilan ushlanishi mumkin, lekin u platforma oxirgi nuqtasiga emas, administratorning kuzatilgan manziliga qaratilgan. Uni o'z so'rov-javob juftidan diagnostika qiling va VPN siyosatini o'zgartirishdan oldin ketma-ket konsol kabi mustaqil tiklash kanalini saqlang. Agar joylashtirish VMni qayta ishga tushirsa va agent nosog'lomlikni xabar qilsa, marshrut o'zgarishi qayta ishga tushishga sabab bo'lgan deb taxmin qilish o'rniga yozilgan amalni va mas'ul xizmatni tekshiring.

So'ng uchta oqimni alohida tekshiring: siz haqiqatan xohlagan xususiy resurs, qo'llab-quvvatlanadigan agent va platforma aloqasi, va boshqaruv yo'li. Birini tiklash qolgan ikkisi omon qolganining dalili emas.

Tasdiqlangan istisnoni mehmon tarmog'i va VPN konfiguratsiyasi egasi nomiga yozing, qayta ulanish va qayta ishga tushishda nima bo'lishini ham qo'shing. Azure UDRlari mehmonning marshrut jadvali emas va ularni tahrirlash mahalliy siyosat qoidasini tuzatmaydi.