Azure VM не може да стигне до IMDS или WireServer откако ќе се вклучи VPN

ВМ работи, VPN клиентот вели дека е поврзан, а неколку минути подоцна Azure агентот почнува да пријавува нездрава состојба. Понекогаш SSH преживува, а Run Command од порталот не, што ги насочува луѓето кон агентот наместо кон табелата со рути. Одлуките за препраќање на гостинот се сменија кога се крена тунелот, и две платформски адреси обично се првите жртви. Го третирам ова како симптом на рутирање пред да го третирам како дефект на агентот.

Симптомот изгледа како расипан агент

Двете адреси подолу се предлагаат како решение, а не се иста услуга. Копирањето /32 за едната затоа што работеше за другата е токму начинот на кој привремената обиколка станува трајна конфигурација што никој не се осмелува да ја отстрани.

Редоследот што работи е прво да потврдите која адреса навистина ја таргетира неуспешниот повик, потоа да прочитате како гостинот ја решава. Сè друго е погодување со дополнителни чекори и подолг прозорец за промени.

168.63.129.16 не е јавна дестинација

168.63.129.16 е специјалната виртуелна платформска адреса на Azure, а една од нејзините улоги е WireServer, која агентот на VM ја користи за разговор со ткаенината. Microsoft документира дека сообраќајот на агентот кон TCP портите 80 и 32526 мора да остане достапен. Тоа не е обичен интернет домаќин и не е нешто што VPN со целосен тунел треба да го носи до далечен излез. Затоа тунел што изгледа здрав може сепак да го изгладни агентот.

Документацијата за платформската адреса исто така вели дека оваа адреса не подлежи на кориснички дефинирани рути, што е својство на Azure ткаенината, а не ветување за вашиот гостин. Локално правило на огнена ѕид или сопствената политика за рутирање на VPN клиентот сепак можат да го прекинат патот, и ниту едно од нив не живее во табелата со рути на VNet-от.

Ако агентот е тој што пријавува проблем, проверете ја состојбата на услугата и патот до таа адреса пред да инсталирате нешто повторно.

169.254.169.254 има свои правила

169.254.169.254 е link-local адресата за Azure Instance Metadata Service. Барањата до неа имаат свои услови: примарниот NIC и примарната IP, DHCP конфигурација што ја поддржува адресата и заобиколување на секој HTTP прокси. Нивното испраќање низ далечен VPN излез или произволна интернет порта не е моделот на пристап што го опишува Microsoft.

Таа клаузула за прокси ги фаќа оние што ја поправиле рутата и сè уште гледаат дефекти. HTTP прокси во гостинот може да го скрши IMDS додека ip route get враќа точно интерфејсот што го очекувате, затоа проверете ги исклучоците за прокси, како и рутите.

Не лепете одговори од метаподатоци во билет за поддршка додека го отстранувате проблемот. Тие можат да носат акредитиви и детали за инстанцата што го надживуваат инцидентот.

Читајте го policy routing на гостинот, не само главната табела

На 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 не се табелата со рути на гостинот, и нивното уредување нема да поправи локално правило на политиката.