Hindi maabot ng Azure VM ang IMDS o WireServer pagkatapos magsimula ang VPN

Buhay ang VM, sinasabi ng VPN client na konektado ito, at makalipas ang ilang minuto ay nagsisimulang mag-ulat ng hindi malusog na estado ang Azure agent. Minsan nabubuhay ang SSH pero hindi ang Run Command mula sa portal, kaya tinitingnan ng mga tao ang agent sa halip na ang route table. Nagbago ang mga desisyon sa pagpapasa ng guest nang umakyat ang tunnel, at dalawang platform address ang karaniwang unang biktima. Itinuturing ko itong sintomas ng routing bago ituring na failure ng agent.

Mukhang sirang agent ang sintomas

Parehong address sa ibaba ay iminungkahi bilang pag-aayos, at hindi sila ang parehong serbisyo. Ang pagkopya ng /32 para sa isa dahil gumana ito sa isa pa ay eksaktong paraan kung paano nagiging permanenteng configuration ang pansamantalang workaround na walang nangangahas na tanggalin.

Ang gumaganang pagkakasunod-sunod ay tiyakin muna kung aling address ang talagang tinatarget ng nabigong tawag, pagkatapos ay basahin kung paano ito nireresolba ng guest. Lahat ng iba ay hula na may dagdag na hakbang at mas mahabang window ng pagbabago.

Ang 168.63.129.16 ay hindi pampublikong destinasyon

Ang 168.63.129.16 ay ang espesyal na virtual platform address ng Azure, at isa sa mga papel nito ang WireServer, na ginagamit ng VM agent para kausapin ang fabric. Dinodokumento ng Microsoft na ang trapiko ng agent patungo sa TCP port 80 at 32526 ay dapat manatiling available. Hindi ito ordinaryong internet host, at hindi ito bagay na dapat dalhin ng full-tunnel VPN sa malayong labasan. Kaya naman ang tunnel na mukhang malusog ay maaari pa ring gutumin ang agent.

Sinasabi rin ng dokumentasyon ng platform address na ang address na ito ay hindi saklaw ng mga rutang tinukoy ng user, na katangian ng Azure fabric at hindi pangako tungkol sa iyong guest. Ang lokal na firewall rule o ang sariling routing policy ng VPN client ay maaari pa ring sumira sa landas, at wala sa kanila ang nakatira sa route table ng VNet.

Kung ang agent ang nag-uulat ng problema, tingnan ang estado ng serbisyo at ang landas patungo sa address na iyon bago mag-install muli ng anuman.

May sariling mga panuntunan ang 169.254.169.254

Ang 169.254.169.254 ay ang link-local address ng Azure Instance Metadata Service. May sariling mga kinakailangan ang mga kahilingan dito: ang primary NIC at primary IP, isang DHCP configuration na sumusuporta sa address, at paglampas sa anumang HTTP proxy. Ang pagpapadala sa kanila sa malayong VPN exit o arbitraryong internet gateway ay hindi ang access model na inilalarawan ng Microsoft.

Ang sugnay na iyon tungkol sa proxy ay humuhuli sa mga nag-ayos ng ruta at nakakakita pa rin ng mga kabiguan. Ang HTTP proxy sa guest ay maaaring makasira sa IMDS habang ang ip route get ay nagbabalik ng eksaktong interface na inaasahan mo, kaya tingnan ang mga pagbubukod sa proxy kasama ng mga ruta.

Huwag i-paste ang mga tugon ng metadata sa isang support ticket habang ini-debug ito. Maaaring magdala sila ng mga kredensyal at detalye ng instance na mas matagal pa sa insidente.

Basahin ang policy routing ng guest, hindi lang ang pangunahing talahanayan

Sa isang Linux guest, tatlong read-only na utos ang naghihiwalay sa mga layer: ip -4 rule show para sa mga panuntunan ng patakaran, pagkatapos ip -4 route get 168.63.129.16 at ip -4 route get 169.254.169.254 para sa mga desisyong aktwal na ginagawa ng kernel. Patakbuhin ang mga ito bago at pagkatapos kumonekta ang VPN. Ang pagkakaiba ng dalawang output na iyon ay ang iyong set ng pagbabago, at mas kapaki-pakinabang ito kaysa sa anumang hula tungkol sa ginawa ng client.

Ang VPN client na nag-i-install ng mga panuntunan ng patakaran ay maaaring iwanang hindi ginalaw ang pangunahing talahanayan at i-redirect pa rin ang mga paghahanap na iyon. Kaya naman ang pag-aayos na pangunahing talahanayan lang ay mukhang gumagana sa isang host at walang ginagawa sa susunod. Ang mga guest na may maraming NIC ay nagdadagdag ng parehong problema mula sa kabilang panig, dahil ang sagot ay depende sa kung aling NIC at source address ang pipiliin ng panuntunan.

Labanan ang recipe na nagdadagdag ng parehong /32 ruta sa lumang gateway. Ang link-local na landas ng platform at pangkalahatang susunod na hop ng WAN ay magkaibang bagay, at ang blanket na pagbubukod ay nagtatago ng tunay na salungatan ng patakaran.

Panatilihing hiwalay ang administrasyon at pagbawi

Ang iyong SSH o RDP na tugon ay maaari ring makuha ng full-tunnel default, ngunit ito ay naka-target sa naobserbahang address ng administrador at hindi sa alinmang platform endpoint. I-diagnose ito mula sa sarili nitong pares ng kahilingan at tugon, at panatilihin ang isang independiyenteng channel ng pagbawi tulad ng serial console bago baguhin ang patakaran ng VPN. Kung ang deployment ay nag-restart ng VM at ang agent ay nag-uulat ng hindi malusog, siyasatin ang naitalang aksyon at ang responsableng serbisyo sa halip na ipagpalagay na ang pagbabago ng ruta ang naging dahilan ng restart.

Pagkatapos ay i-verify ang tatlong daloy nang hiwalay: ang pribadong resource na talagang gusto mo, ang sinusuportahang komunikasyon ng agent at platform, at ang landas ng administrasyon. Ang pagbawi ng isa ay hindi patunay na ang dalawa pa ay nakaligtas.

Isulat ang inaprubahang pagbubukod sa ilalim ng may-ari ng network ng guest at configuration ng VPN, kasama ang nangyayari sa muling pagkonekta at pag-restart. Ang mga UDR ng Azure ay hindi ang route table ng guest, at ang pag-edit sa kanila ay hindi mag-aayos ng lokal na panuntunan ng patakaran.