Azure VM nær ekki IMDS eða WireServer eftir að VPN fer í gang

Vélin er í gangi, VPN-biðlarinn segist vera tengdur og nokkrum mínútum síðar byrjar Azure-umboðsmaðurinn að tilkynna óheilbrigt ástand. Stundum lifir SSH af en Run Command frá gáttinni ekki, sem beinir fólki að umboðsmanninum í stað leiðatöflunnar. Ákvarðanir gestsins um framsendingu breyttust þegar göngin fóru upp, og tvö vettvangsnetföng eru venjulega fyrstu fórnarlömbin. Ég meðhöndla það sem leiðsagnareinkenni áður en ég meðhöndla það sem bilun umboðsmannsins.

Einkennið lítur út eins og bilaður umboðsmaður

Bæði netföngin hér að neðan eru lögð til sem lagfæring, en þau eru ekki sama þjónustan. Að afrita /32 fyrir annað vegna þess að það virkaði fyrir hitt er einmitt hvernig tímabundin lausn verður varanleg stilling sem enginn þorir að fjarlægja.

Röðin sem virkar er að staðfesta fyrst hvaða netfang misheppnuða kallið beinir sér að, og lesa svo hvernig gesturinn leysir það. Allt annað er gisk með aukaskrefum og lengri breytingaglugga.

168.63.129.16 er ekki opinbert áfangastaður

168.63.129.16 er sérstakt sýndarvettvangnetfang Azure, og eitt hlutverk þess er WireServer, sem VM-umboðsmaðurinn notar til að tala við ofið. Microsoft skjalfestir að umferð umboðsmannsins að TCP-portum 80 og 32526 verði að vera tiltæk. Þetta er ekki venjulegur internetþjónn og ekki eitthvað sem VPN með heilum göngum ætti að bera að fjarlægri útgöngu. Þess vegna geta göng sem líta heilbrigð út enn svelt umboðsmanninn.

Skjölun vettvangnetfangsins segja einnig að þetta netfang sé ekki undirorpið leiðum sem notandi skilgreinir, sem er eiginleiki Azure-ofsins en ekki loforð um gestinn þinn. Staðbundin eldveggsregla eða eigin leiðsagnarstefna VPN-biðlarans geta enn brotið slóðina, og hvorugt býr í leiðatöflu VNetsins.

Ef umboðsmaðurinn er sá sem tilkynnir vandamálið, athugaðu stöðu þjónustunnar og slóðina að þessu netfangi áður en þú setur eitthvað upp aftur.

169.254.169.254 hefur sínar eigin reglur

169.254.169.254 er link-local netfang Azure Instance Metadata Service. Beiðnir til þess hafa sínar eigin kröfur: aðal-NIC og aðal-IP, DHCP-stilling sem styður netfangið og framhjáhlaup á hvaða HTTP-proxy sem er. Að senda þær um fjarlæga VPN-útgöngu eða handahófskennda internethlið er ekki aðgangslíkanið sem Microsoft lýsir.

Sú proxýklausa grípur fólk sem lagfærði leiðina og sér samt bilanir. HTTP-proxy í gestinum getur brotið IMDS á meðan ip route get skilar nákvæmlega því viðmóti sem þú átt von á, svo athugaðu proxýundanþágur jafnt sem leiðirnar.

Ekki líma lýsigagnasvör í stuðningsmiða á meðan þú villuleitar þetta. Þau geta borið skilríki og smáatriði tilviks sem lifa lengur en atvikið.

Lestu stefnuleiðsögn gestsins, ekki bara aðaltöfluna

Á Linux-gesti aðskilja þrjár lesaðeins skipanir lögin: ip -4 rule show fyrir stefnureglurnar, síðan ip -4 route get 168.63.129.16 og ip -4 route get 169.254.169.254 fyrir ákvarðanirnar sem kjarninn tekur í raun. Keyrðu þær fyrir og eftir að VPN tengist. Munurinn á þessum tveimur úttökum er breytingasettið þitt, og það er gagnlegra en hvaða giska sem er um hvað biðlarinn gerði.

VPN-biðlari sem setur upp stefnureglur getur látið aðaltöfluna ósnerta og samt vísað þessum uppflettingum annað. Þess vegna virðist lagfæring sem aðeins snertir aðaltöfluna virka á einum þjóni og gera ekkert á þeim næsta. Gestir með margar NIC bæta sama vandamálinu við frá hinni hliðinni, því svarið fer eftir því hvaða NIC og upprunanetfang reglan velur.

Andspyrnaðu uppskriftinni sem bætir báðum /32-leiðunum við um gömlu hliðið. Link-local vettvangsslóð og almenn WAN-næsta stökk eru ólík fyrirbæri, og almennt undanþága felur hið raunverulega stefnuárekstur.

Haltu stjórnun og endurheimt aðskildum

SSH- eða RDP-svarið þitt getur líka lent í sjálfgefinni heilgönguleið, en það beinist að athuguðu netfangi stjórnandans en ekki endapunkti vettvangsins. Greindu það út frá eigin beiðni-og-svari, og haltu óháðum endurheimtarleið eins og raðstjórnborðinu áður en þú breytir VPN-stefnu. Ef uppsetning endurræsir vélina og umboðsmaðurinn tilkynnir óheilbrigt ástand, skoðaðu skráða aðgerð og ábyrgu þjónustuna í stað þess að gera ráð fyrir að leiðabreytingin hafi valdið endurræsingunni.

Staðfestu síðan þrjú streymin hvert fyrir sig: einkaaðilinn sem þú vildir í raun, studda samskipti umboðsmanns og vettvangs, og stjórnunarslóðina. Endurheimt eins þeirra er ekki sönnun þess að hin tvö hafi lifað af.

Skrifaðu samþykktu undanþáguna hjá eiganda gestanetsins og VPN-stillingarinnar, þar á meðal hvað gerist við endurtengingu og endurræsingu. Azure UDR eru ekki leiðatafla gestsins, og að breyta þeim lagar ekki staðbundna stefnureglu.