Azure-VM ei tavoita IMDS:ää tai WireServeriä VPN:n käynnistyttyä

VM on käynnissä, VPN-asiakas kertoo olevansa yhteydessä, ja muutamaa minuuttia myöhemmin Azure-agentti alkaa raportoida huonoa tilaa. Joskus SSH säilyy ja portaalin Run Command ei, mikä ohjaa ihmiset agentin eikä reititystaulun pariin. Vieraan omat edelleenlähetyspäätökset muuttuivat, kun tunneli nousi, ja kaksi alustan osoitetta ovat yleensä ensimmäiset uhrit. Käsittelen sitä reititysoireena ennen kuin käsittelen sitä agentin vikana.

Oire näyttää rikkinäiseltä agentilta

Molempia alla olevia osoitteita ehdotetaan korjaukseksi, eivätkä ne ole sama palvelu. /32:n kopioiminen toiselle siksi, että se toimi toiselle, on juuri se tapa, jolla väliaikainen kiertotie muuttuu pysyväksi asetukseksi, jota kukaan ei uskalla poistaa.

Toimiva järjestys on vahvistaa ensin, mitä osoitetta epäonnistuva kutsu todella tavoittelee, ja lukea sitten, miten vieras sen ratkaisee. Kaikki muu on arvailua ylimääräisillä vaiheilla ja pidemmällä muutosikkunalla.

168.63.129.16 ei ole julkinen kohde

168.63.129.16 on Azuren erityinen virtuaalinen alustaosoite, ja yksi sen rooleista on WireServer, jota VM-agentti käyttää puhuakseen fabricin kanssa. Microsoft dokumentoi, että agentin liikenteen TCP-portteihin 80 ja 32526 on pysyttävä saatavilla. Se ei ole tavallinen internet-isäntä, eikä se ole jotain, mitä täystunnelin VPN:n pitäisi kuljettaa etäiseen ulostuloon. Siksi terveeltä näyttävä tunneli voi silti näännyttää agentin.

Alustaosoitteen dokumentaatio sanoo myös, että tämä osoite ei ole käyttäjän määrittämien reittien alainen, mikä on Azuren fabricin ominaisuus eikä lupaus vieraastasi. Paikallinen palomuurisääntö tai VPN-asiakkaan oma reitityskäytäntö voi silti rikkoa polun, eikä kumpikaan niistä elä VNetin reititystaulussa.

Jos agentti on se, joka ilmoittaa ongelmasta, tarkista palvelun tila ja polku kyseiseen osoitteeseen ennen kuin asennat mitään uudelleen.

169.254.169.254:llä on omat sääntönsä

169.254.169.254 on Azure Instance Metadata Servicen link-local-osoite. Siihen kohdistuvilla pyynnöillä on omat vaatimuksensa: ensisijainen NIC ja ensisijainen IP, osoitetta tukeva DHCP-kokoonpano sekä minkä tahansa HTTP-välityspalvelimen ohitus. Niiden lähettäminen etäisen VPN-ulostulon tai mielivaltaisen internetyhdyskäytävän kautta ei ole se käyttömalli, jonka Microsoft kuvaa.

Kyseinen välityspalvelulauseke nappaa ihmiset, jotka korjasivat reitin ja näkevät silti virheitä. Vieraan HTTP-välityspalvelin voi rikkoa IMDS:n, vaikka ip route get palauttaa täsmälleen odottamasi liitännän, joten tarkista välityspalvelun poikkeukset reittien lisäksi.

Älä liitä metatietovastauksia tukipyyntöön, kun selvität tätä. Ne voivat sisältää tunnistetietoja ja instanssin yksityiskohtia, jotka elävät tapauksen yli.

Lue vieraan policy routing, älä vain päätaulua

Linux-vieraassa kolme vain luku -komentoa erottavat kerrokset: ip -4 rule show käytäntösäännöille ja sitten ip -4 route get 168.63.129.16 ja ip -4 route get 169.254.169.254 päätöksille, jotka ydin todella tekee. Aja ne ennen VPN:n yhdistämistä ja sen jälkeen. Näiden tulosteiden ero on muutosjoukkosi, ja se on hyödyllisempi kuin mikään arvaus siitä, mitä asiakas teki.

Käytäntösääntöjä asentava VPN-asiakas voi jättää päätaulun koskemattomaksi ja silti ohjata nuo haut uudelleen. Siksi vain päätaulun korjaava ratkaisu näyttää toimivan yhdellä isännällä eikä tee mitään seuraavalla. Monen NIC:n vieraat lisäävät saman ongelman toisesta suunnasta, koska vastaus riippuu siitä, minkä NIC:n ja lähdeosoitteen sääntö valitsee.

Vastusta reseptiä, joka lisää molemmat /32-reitit vanhan yhdyskäytävän kautta. Link-local-alustapolku ja yleinen WAN-seuraava hyppäys ovat eri objekteja, ja yleinen poikkeus piilottaa todellisen käytäntöristiriidan.

Pidä ylläpito ja palautuminen erillään

Myös SSH- tai RDP-vastauksesi voi jäädä täystunnelin oletusreitin sieppaamaksi, mutta se kohdistuu järjestelmänvalvojan havaittuun osoitteeseen eikä kumpaankaan alustan päätepisteeseen. Diagnosoi se oman pyyntö-vastaus-parinsa perusteella ja pidä riippumaton palautuskanava, kuten sarjakonsoli, ennen kuin muutat VPN-käytäntöä. Jos käyttöönotto käynnistää VM:n uudelleen ja agentti ilmoittaa huonosta tilasta, tarkista kirjattu toiminto ja vastuullinen palvelu sen sijaan, että olettaisit reittimuutoksen aiheuttaneen uudelleenkäynnistyksen.

Tarkista sitten kolme virtaa erikseen: yksityinen resurssi, jonka todella halusit, tuettu agentin ja alustan välinen viestintä sekä ylläpitopolku. Yhden palauttaminen ei todista, että kaksi muuta selvisivät.

Kirjaa hyväksytty poikkeus vierasverkon ja VPN-kokoonpanon omistajan alle, mukaan lukien mitä tapahtuu uudelleenyhdistämisessä ja uudelleenkäynnistyksessä. Azure UDR:t eivät ole vieraan reititystaulu, eikä niiden muokkaaminen korjaa paikallista käytäntösääntöä.