VPN қосылғаннан кейін Azure VM IMDS немесе WireServer-ге жетпейді

VM жұмыс істеп тұр, VPN клиенті қосылғанын айтады, ал бірнеше минуттан кейін Azure агенті денсаулығы нашар екенін хабарлай бастайды. Кейде SSH тұрады, порталдық Run Command тұрмайды, бұл адамдарды маршрут кестесіне емес, агентке қарауға итермелейді. Туннель көтерілгенде қонақтың өз жіберу шешімдері өзгерді, және әдетте алғашқы құрбандар — платформаның екі мекенжайы. Мен мұны агент ақауы деп санамас бұрын маршруттау симптомы деп қараймын.

Симптом сынған агентке ұқсайды

Төмендегі екі мекенжай да шешім ретінде ұсынылады, бірақ олар бір қызмет емес. Біреуі үшін /32 көшіру, өйткені ол екіншісі үшін жарады, — уақытша айналып өту жолының ешкім жоюға батылы бармайтын тұрақты конфигурацияға айналуының дәл осы жолы.

Жұмыс істейтін тәртіп: әуелі сәтсіз шақыру шынымен қай мекенжайға бағытталғанын растау, содан кейін қонақ оны қалай шешетінін оқу. Қалғанының бәрі қосымша қадамдармен болжау және ұзағырақ өзгеріс терезесі.

168.63.129.16 — жария мақсат емес

168.63.129.16 — Azure платформасының арнайы виртуалды мекенжайы, оның бір рөлі WireServer, оны VM агенті фабрикамен сөйлесу үшін пайдаланады. Microsoft агенттің TCP 80 және 32526 порттарына трафигі қолжетімді болып қалуы керек екенін құжаттайды. Бұл қарапайым интернет хост емес және толық туннельді VPN оны алыс шығысқа тасымалдауға тиіс емес. Сондықтан сау көрінетін туннель де агентті аш қалдыруы мүмкін.

Платформа мекенжайының құжаттамасы бұл мекенжай пайдаланушы анықтаған маршруттарға бағынбайтынын да айтады; бұл Azure фабрикасының қасиеті, қонағыңыз туралы уәде емес. Жергілікті firewall ережесі немесе VPN клиентінің өз маршруттау саясаты жолды әлі де бұзуы мүмкін, және олардың ешқайсысы VNet маршрут кестесінде өмір сүрмейді.

Егер мәселені агент хабарласа, бірдеңені қайта орнатпас бұрын қызмет күйі мен сол мекенжайға барар жолды тексеріңіз.

169.254.169.254-тің өз ережелері бар

169.254.169.254 — Azure Instance Metadata Service-тің link-local мекенжайы. Оған сұраныстардың өз талаптары бар: негізгі NIC және негізгі IP, мекенжайды қолдайтын DHCP конфигурациясы және кез келген HTTP проксиді айналып өту. Оларды алыс VPN шығысынан немесе ерікті интернет шлюзінен жіберу Microsoft сипаттаған қатынау моделі емес.

Бұл прокси тармағы маршрутты түзетіп, әлі де ақау көретіндерді ұстайды. Қонақтағы HTTP прокси IMDS-ті бұзуы мүмкін, ал ip route get күткен интерфейсті дәл қайтарады, сондықтан маршруттармен қатар прокси ерекшеліктерін де тексеріңіз.

Мұны жөндеп жатқанда метадеректер жауаптарын қолдау билетіне қыстырмаңыз. Олар оқиғадан ұзақ өмір сүретін тіркелгі деректері мен дана мәліметтерін алып жүруі мүмкін.

Қонақтың саяси маршруттауын оқыңыз, тек негізгі кестені емес

Linux қонағында үш тек-оқу командасы қабаттарды ажыратады: саясат ережелері үшін ip -4 rule show, содан кейін ядро шынымен қабылдайтын шешімдер үшін ip -4 route get 168.63.129.16 және ip -4 route get 169.254.169.254. Оларды VPN қосылмас бұрын және кейін іске қосыңыз. Осы екі шығыстың айырмашылығы — сіздің өзгерістер жиынтығы, және клиент не істегені туралы кез келген болжамнан пайдалырақ.

Саясат ережелерін орнататын VPN клиенті негізгі кестені тимей қалдырып, сол іздеулерді бұруы мүмкін. Сондықтан тек негізгі кестені түзететін шешім бір хостта жұмыс істеп, келесісінде ештеңе істемейтін сияқты көрінеді. Көп NIC-ті қонақтар сол мәселені екінші жақтан қосады, өйткені жауап ереженің қай NIC мен бастапқы мекенжайды таңдауына байланысты.

Ескі шлюз арқылы екі /32 маршрутын да қосатын рецептке қарсы тұрыңыз. link-local платформа жолы мен жалпы WAN келесі секірісі әртүрлі нысандар, ал жалпы ерекшелік нақты саяси қақтығысты жасырады.

Әкімшілік пен қалпына келтіруді бөлек ұстаңыз

Сіздің SSH немесе RDP жауабын толық туннельдің әдепкісі де ұстауы мүмкін, бірақ ол платформаның шеткі нүктесін емес, әкімшінің байқалған мекенжайын нысана етеді. Оны өз сұраныс-жауап жұбынан диагностикалаңыз және VPN саясатын өзгертуден бұрын сериялық консоль сияқты тәуелсіз қалпына келтіру арнасын ұстаңыз. Егер орналастыру VM-ді қайта іске қосса және агент нашар денсаулықты хабарласа, маршрут өзгерісі қайта жүктеуге себеп болды деп болжаудың орнына жазылған әрекетті және жауапты қызметті тексеріңіз.

Содан кейін үш ағынды бөлек тексеріңіз: шынымен қажет жеке ресурс, қолдау көрсетілетін агент пен платформа байланысы және әкімшілік жол. Біреуін қалпына келтіру қалған екеуі аман қалғанының дәлелі емес.

Бекітілген ерекшелікті қонақ желісі мен VPN конфигурациясының иесінің атына жазыңыз, оның ішінде қайта қосылу мен қайта жүктеу кезінде не болатынын да. Azure UDR-тері қонақтың маршрут кестесі емес, оларды өңдеу жергілікті саясат ережесін түзетпейді.