Azure P2S: yhdeltä Windows-asiakkaalta puuttuvat reitit VNet-muutoksen jälkeen

Kaksi kannettavaa todentaa samaan Azure point-to-site -yhdyskäytävään, ja vain toinen tavoittaa äskettäin liitetyn VNetin. Molemmat näyttävät Connected, joten todennus ei ole ero; ero on niiden pitämissä kohdereiteissä. Aloita asiakkaasta, joka epäonnistuu, vertaa yhtä kohdetta ja päätä vasta sitten, kuuluuko puute yhdyskäytäväpakettiin vai paikalliseen reititystauluun.

Aloita epäonnistuvasta asiakkaasta, älä yhdyskäytävästä

Vahvista topologia ennen kuin syytät kannettavaa. Tarkista, mitkä VNetit on liitetty yhdyskäytävän VNetiin ja onko uusi verkko suoraan peerattu vai tavoitetaanko se erillisen site-to-site-tunnelin kautta. Jos uutta VNetiä ei ole liitetty yhdyskäytävän VNetiin lainkaan, mikään asiakaspaketti ei voi reitittää sinne, ja toimiva kannettava on poikkeus, joka on selitettävä. Kirjoita vastaus muistiin, sillä se ratkaisee, viritätkö asiakasta vai yhdyskäytävää.

Kun topologia on kunnossa, aseta kaksi kannettavaa vierekkäin. Sama yhdyskäytävä, sama osoitepooli, sama protokolla ja sama asiakasversio ovat vertailu, jonka haluat; kaikki muu on toinen muuttuja, joka sinun on myöhemmin suljettava pois.

Vertaa yhtä kohdetta route print -komennolla

Valitse sallittu resurssi-IP ja vertaa molempia kannettavia kahdesti: irrotettuna ja sitten yhdistettynä. Windowsissa route print -4 luettelee IPv4-reitit kohdeprefiksillä, rajapinnalla, seuraavalla hypyllä ja metrikalla. Kirjaa rivi, joka todella voittaisi kyseiselle kohteelle, sen sijaan että laskisit merkintöjä, jotka sisältävät sanan VPN.

Valinta tehdään ensin pisimmän prefiksin ja sitten metrikkan mukaan, joten tarkempi paikallinen reitti voi voittaa tunnelireitin näyttämättä väärältä. Jos aiottu kohde on alueella 10.24.0.0/16, terve asiakas näyttää vastaavan reitin VPN-rajapinnalla, kun taas epäonnistuva asiakas lähettää saman osoitteen oletusyhdyskäytävälleen.

Ristiriitainen paikallinen prefiksi voi tuottaa saman oireen. Ennen kuin lisäät mitään, päätä kumpi kahdesta tapauksesta sinulla on: ei tunnelireittiä lainkaan, vai tunnelireitti, joka häviää tarkemmalle.

TTL expired ei ole reittien jakelun bugi

Ping, joka palauttaa TTL expired in transit, kertoo, että paketti kulutti hyppykiintiönsä, mikä yleensä tarkoittaa edelleenlähetyssilmukkaa eikä rikkinäistä VPN-ajuria. Windowsin ping hyväksyy TTL-arvon 255 asti, eikä arvon nostaminen korjaa silmukkaa; se vain viivästyttää samaa virhettä. Käsittele viestiä polun oireena, älä todisteena reittien jakelusta.

Käytä tracert -4 10.24.1.10 nähdäksesi, missä polku toistuu. Jos samat kaksi hyppyä ilmestyvät yhä uudelleen, etsi reitti, joka lähettää tunneliin menevän liikenteen takaisin tunneliin tai paikalliseen reitittimeen, joka välittää sen takaisin.

Luo paketti uudelleen yhdyskäytävässä, joka sen omistaa

Microsoft dokumentoi, että Windows-asiakaspaketit on ladattava ja asennettava uudelleen merkittävien topologiamuutosten jälkeen. Hae nykyinen paketti Azure-yhdyskäytävästä, joka palvelee tätä profiilia, ja ota se käyttöön kyseiselle asiakkaalle tuetulla menettelyllä. Riippumattoman VPN-sovelluksen suoritettavan tiedoston korvaaminen ei ole sama toimenpide kuin yhdyskäytäväkohtaisten asetusten uudelleen luominen. Paketin lataaminen uudelleen on halpaa; paikallisten reittien arvaaminen ei ole.

Yhdistä uudelleen ja lue alkuperäisen kohteen reitti uudelleen. Säilytä ennen ja jälkeen -rivit muutostietueen kanssa, jotta tulos on tarkempi kuin asensin asiakkaan uudelleen.

Azure P2S -reititysskenaariot erottavat suoraan peeratut VNetit verkoista, joihin päästään muiden tunnelien kautta, eikä uusi paketti voi tehdä peeringistä transitiivista. Jotkin Windows site-to-site- tai BGP-skenaariot vaativat myös käsin määritettyjä etäreittejä, joten paketin päivitys ei ole yleinen reittien jakelumekanismi.

Pidä tilapäinen reitti tilapäisenä

Manuaalinen reitti voi eristää puuttuvan asiakasreitin, mutta rakenna se todellisesta suunnittelusta: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, ilman pysyvää lippua, jotta se katoaa uudelleenkäynnistyksessä. Valitse rajapintaindeksi ja seuraava hyppy yhdistetystä VPN-sovittimesta, ei arvauksesta.

Älä jätä kokeellista reittiä pysyväksi kilpailevaksi omistajaksi. Tulevat profiilipäivitykset voivat lisätä saman prefiksin eri metrikalla, ja silloin manuaalinen merkintä päättää hiljaa, mikä polku voittaa. Kirjaa poistovaihe muutokseen.

Kun oikea reitti on aktiivinen, testaa kohdesovellusta pingin sijaan. Jos paketit saapuvat Azureen mutta palvelu epäonnistuu edelleen, tarkista verkon suojausryhmä ja paluupolku, sillä ne ovat erillisiä siitä, oppiko kannettava prefiksin.