ВМ Azure не дасягае IMDS ці WireServer пасля запуску VPN

ВМ працуе, кліент VPN паведамляе пра злучэнне, а праз некалькі хвілін агент Azure пачынае паведамляць пра няспраўнасць. Часам SSH жыве, а Run Command з партала не, і гэта адпраўляе людзей да агляду агента замест табліцы маршрутаў. Уласныя рашэнні гасцявой сістэмы аб перадачы змяніліся, калі ўзняўся тунель, і два адрасы платформы звычайна становяцца першымі ахвярамі. Я разглядаю гэта як сімптом маршрутызацыі, а не як збой агента.

Сімптом выглядае як зламаны агент

Абодва адрасы ніжэй прапануюць як рашэнне, але гэта не адзін і той жа сэрвіс. Капіраванне /32 для аднаго з іх таму, што ён спрацаваў для другога, — менавіта так часовы абыход ператвараецца ў пастаянную канфігурацыю, якую ніхто не адважваецца выдаліць.

Парадак, які працуе: спачатку пацвердзіце, на які адрас насамрэч накіраваны збойны выклік, потым прачытайце, як гасцявая сістэма яго вырашае. Усё астатняе — здагадкі з дадатковымі крокамі і даўжэйшым акном змен.

168.63.129.16 — не публічны пункт прызначэння

168.63.129.16 — спецыяльны віртуальны адрас платформы Azure, і адна з яго роляў — WireServer, які агент ВМ выкарыстоўвае для сувязі з фабрыкай. 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 вяртае менавіта той інтэрфейс, які вы чакаеце, таму правярайце выключэнні проксі разам з маршрутамі.

Не ўстаўляйце адказы метададзеных у заяўку ў падтрымку, пакуль адладжваеце. Яны могуць несці ўліковыя даныя і дэталі інстанса, якія перажывуць інцыдэнт.

Чытайце палітыку маршрутызацыі гасцявой сістэмы, а не толькі асноўную табліцу

На 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 таксама можа быць перахоплены default поўнага тунеля, але ён накіраваны на назіраны адрас адміністратара, а не на канечны пункт платформы. Дыягнастуйце яго па ўласнай пары запыт-адказ і трымайце незалежны канал аднаўлення, напрыклад паслядоўную кансоль, перад зменай палітыкі VPN. Калі разгортванне перазапускае ВМ і агент паведамляе пра няспраўнасць, праверце запісанае дзеянне і адказны сэрвіс, а не мяркуйце, што перазапуск выклікала змена маршруту.

Затым праверце тры патоку асобна: прыватны рэсурс, які вы насамрэч хацелі, падтрымоўваную сувязь агента і платформы, і адміністрацыйны шлях. Аднаўленне аднаго з іх не з'яўляецца доказам, што два іншыя выжылі.

Запішыце ўзгодненае выключэнне на ўладальніка гасцявой сеткі і канфігурацыі VPN, уключна з тым, што адбываецца пры перападключэнні і перазапуску. UDR Azure — гэта не табліца маршрутаў госця, і іх праўка не выправіць лакальнае палітычнае правіла.