Azure'i VM ei jõua pärast VPN-i käivitumist IMDS-i ega WireServerini

VM töötab, VPN-klient teatab ühendusest ja mõne minuti pärast hakkab Azure'i agent teatama, et see pole terve. Mõnikord jääb SSH püsti ja portaalist Run Command ei tööta, mis suunab inimesed agenti, mitte marsruutimistabeli juurde. Külalise enda edastusotsused muutusid, kui tunnel üles tuli, ja kaks platvormiaadressi on tavaliselt esimesed ohvrid. Käsitlen seda marsruutimissümptomina enne, kui käsitlen seda agendi rikkena.

Sümptom näeb välja nagu katkine agent

Mõlemat allolevat aadressi pakutakse lahendusena, kuigi need pole sama teenus. /32 kopeerimine ühe jaoks, sest see töötas teise jaoks, on täpselt see, kuidas ajutine lahendus muutub püsivaks konfiguratsiooniks, mida keegi ei julge eemaldada.

Toimiv järjekord on esmalt kinnitada, millist aadressi ebaõnnestunud kutse tegelikult sihib, ja seejärel lugeda, kuidas külaline selle lahendab. Kõik muu on oletamine lisasammude ja pikema muudatusaknaga.

168.63.129.16 ei ole avalik sihtkoht

168.63.129.16 on Azure'i eriline virtuaalne platvormiaadress ja üks selle roll on WireServer, mida VM-i agent kasutab kangaga suhtlemiseks. Microsoft dokumenteerib, et agendi liiklus TCP-portidele 80 ja 32526 peab jääma kättesaadavaks. See pole tavaline internetihost ega midagi, mida täistunneliga VPN peaks kandma kaugesse väljapääsu. Seetõttu võib terve välimusega tunnel agendi ikkagi näljutada.

Platvormiaadressi dokumentatsioon ütleb ka, et see aadress ei allu kasutaja määratud marsruutidele, mis on Azure'i kanga omadus, mitte lubadus teie külalise kohta. Kohalik tulemüürireegel või VPN-kliendi enda marsruutimispoliitika võib tee ikkagi katki teha, ja kumbki neist ei ela VNeti marsruutimistabelis.

Kui agent on see, kes probleemist teatab, kontrollige teenuse olekut ja teed selle aadressini enne, kui midagi uuesti installite.

169.254.169.254-l on omad reeglid

169.254.169.254 on Azure Instance Metadata Service'i link-local aadress. Päringutel selle poole on omad nõuded: esmane NIC ja esmane IP, aadressi toetav DHCP-konfiguratsioon ning mis tahes HTTP-proxy vahelejätmine. Nende saatmine kaugesse VPN-väljapääsu või suvalisse internetilüüsi kaudu ei ole juurdepääsumudel, mida Microsoft kirjeldab.

See proxy-klausel püüab inimesi, kes on marsruudi parandanud ja näevad ikkagi tõrkeid. Külalise HTTP-proxy võib IMDS-i katki teha, samal ajal kui ip route get tagastab täpselt ootatud liidese, seega kontrollige lisaks marsruutidele ka proxy erandeid.

Ärge kleepige metaandmete vastuseid tugipiletisse, kui seda silute. Need võivad kanda volitusi ja eksemplari üksikasju, mis elavad juhtumist kauem.

Lugege külalise poliitikapõhist marsruutimist, mitte ainult pearakendust

Linuxi külalisel eraldavad kolm ainult lugemise käsku kihid: ip -4 rule show poliitikareeglite jaoks, seejärel ip -4 route get 168.63.129.16 ja ip -4 route get 169.254.169.254 otsuste jaoks, mida tuum tegelikult teeb. Käivitage need enne ja pärast VPN-i ühendumist. Nende kahe väljundi erinevus on teie muudatuste kogum ja see on kasulikum kui mis tahes oletus selle kohta, mida klient tegi.

Poliitikareegleid installiv VPN-klient võib jätta pearakenduse puutumata ja ikkagi neid otsinguid ümber suunata. Seetõttu näib ainult pearakendust parandav lahendus ühel hostil töötavat ja järgmisel mitte midagi tegevat. Mitme NIC-iga külalised lisavad sama probleemi teisest küljest, sest vastus sõltub sellest, millise NIC-i ja lähteaadressi reegel valib.

Vastu pidage retseptile, mis lisab mõlemad /32-marsruudid läbi vana lüüsi. Link-local platvormitee ja üldine WAN-i järgmine hüpe on erinevad objektid ning üldine erand varjab tegelikku poliitikakonflikti.

Hoidke haldamine ja taastamine eraldi

Teie SSH- või RDP-vastuse võib samuti kinni püüda täistunneli default, kuid see sihib administraatori vaadeldud aadressi, mitte ühtegi platvormi lõpp-punkti. Diagnoosige seda selle enda päringu-vastuse paari põhjal ja hoidke enne VPN-poliitika muutmist alles sõltumatu taastamiskanal, näiteks jadakonsool. Kui juurutus taaskäivitab VM-i ja agent teatab, et see pole terve, uurige salvestatud toimingut ja vastutavat teenust, selle asemel et eeldada, et marsruudimuudatus põhjustas taaskäivituse.

Seejärel kontrollige kolme voogu eraldi: eraviisilist ressurssi, mida te tegelikult soovisite, toetatud agendi- ja platvormisuhtlust ning haldusteed. Ühe taastamine ei ole tõestus, et teised kaks jäid ellu.

Kirjutage kinnitatud erand külalisvõrgu ja VPN-konfiguratsiooni omaniku alla, sealhulgas see, mis juhtub uuesti ühendamisel ja taaskäivitamisel. Azure'i UDR-id ei ole külalise marsruutimistabel ja nende muutmine ei paranda kohalikku poliitikareeglit.