Azure P2S: een Windows-kliënt kort roetes na ’n VNet-verandering

Twee skootrekenaars verifieer by dieselfde Azure point-to-site-gateway, en net een bereik die nuut gekoppelde VNet. Albei wys Connected, so verifikasie is nie die verskil nie; die bestemmingsroetes wat hulle hou, is. Begin by die kliënt wat misluk, vergelyk een enkele bestemming, en besluit eers daarna of die gateway-pakket of die plaaslike roetetabel die leemte veroorsaak.

Begin by die kliënt wat misluk, nie by die gateway nie

Bevestig die topologie voordat jy die skootrekenaar blameer. Kyk watter VNets aan die gateway-VNet gekoppel is en of die nuwe netwerk direk gepeered is of deur ’n aparte site-to-site-tonnel bereik word. As die nuwe VNet glad nie aan die gateway-VNet gekoppel is nie, kan geen kliëntpakket daarheen roeteer nie, en is die werkende skootrekenaar die anomalie wat verklaar moet word. Skryf die antwoord neer, want dit bepaal of jy ’n kliënt of ’n gateway ontfout.

Sodra die topologie klop, sit die twee skootrekenaars langs mekaar. Dieselfde gateway, dieselfde adrespoel, dieselfde protokol en dieselfde kliëntbou is die vergelyking wat jy wil hê; enigiets anders is ’n tweede veranderlike wat jy later sal moet uitskakel.

Vergelyk een bestemming met route print

Kies ’n toegelate hulpbron-IP en vergelyk albei skootrekenaars twee keer: ontkoppel, dan gekoppel. Op Windows lys route print -4 IPv4-roetes met bestemmingsvoorvoegsel, koppelvlak, volgende sprong en metriek. Teken die ry aan wat werklik vir daardie bestemming sou wen, eerder as om inskrywings te tel wat die woord VPN bevat.

Seleksie is langste voorvoegsel eerste, dan metriek, so ’n meer spesifieke plaaslike roete kan die tonnelroete klop sonder om verkeerd te lyk. As die beoogde bestemming binne 10.24.0.0/16 lê, wys ’n gesonde kliënt ’n passende roete op die VPN-koppelvlak, terwyl die mislukkende kliënt dieselfde adres na sy verstekgateway stuur.

’n Botsende plaaslike voorvoegsel kan dieselfde simptoom lewer. Voordat jy enigiets byvoeg, besluit watter van die twee gevalle jy het: geen tonnelroete hoegenaamd nie, of ’n tonnelroete wat teen ’n meer spesifieke een verloor.

TTL expired is nie ’n roeteverspreidingsfout nie

’n Ping wat TTL expired in transit teruggee, sê die pakket het sy sprongtoelae opgebruik, wat gewoonlik ’n aanstuurlus beteken eerder as ’n stukkende VPN-drywer. Windows-ping aanvaar ’n TTL tot 255, en om die waarde te verhoog herstel nie ’n lus nie; dit vertraag net dieselfde fout. Behandel die boodskap as ’n simptoom van die pad, nie as bewys oor roeteverspreiding nie.

Gebruik tracert -4 10.24.1.10 om te sien waar die pad herhaal. As dieselfde twee spronge oor en oor verskyn, soek ’n roete wat tonnelgebonde verkeer terug in die tonnel stuur of na ’n plaaslike router wat dit terugaanstuur.

Genereer die pakket weer op die gateway wat dit besit

Microsoft dokumenteer dat Windows-kliëntpakkette weer afgelaai en geïnstalleer moet word ná relevante topologieveranderings. Kry die huidige pakket by die Azure-gateway wat hierdie profiel bedien, en pas dit dan toe met die ondersteunde proses vir daardie kliënt. Om ’n onverwante VPN-toepassing se uitvoerbare lêer te vervang is nie dieselfde bewerking as om gateway-spesifieke instellings te hergenereer nie. Om die pakket weer af te laai is goedkoop; om aan plaaslike roetes te raai is nie.

Koppel weer en lees die roete vir die oorspronklike bestemming opnuut. Hou die voor- en na-rye by die veranderingsrekord sodat die resultaat noukeuriger is as het die kliënt weer geïnstalleer.

Die Azure P2S-roeteringscenario’s skei direk gepeerde VNets van netwerke wat deur ander tonnels bereik word, en ’n nuwe pakket kan nie peering transitiief maak nie. Sommige Windows site-to-site- of BGP-scenario’s het ook handmatig gekonfigureerde afstandroetes nodig, so pakketvernuwing is nie ’n universele roeteverspreidingsmeganisme nie.

Hou ’n tydelike roete tydelik

’n Handmatige roete kan ’n ontbrekende kliëntroete isoleer, maar bou dit uit die werklike ontwerp: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, sonder die persistente vlag, sodat dit by herbegin verdwyn. Kies die koppelvlakindeks en volgende sprong uit die gekoppelde VPN-adapter, nie uit ’n raaiskoot nie.

Moenie ’n eksperimentele roete as ’n permanente mededingende eienaar laat staan nie. Toekomstige profielopdaterings kan dieselfde voorvoegsel met ’n ander metriek byvoeg, en dan besluit die handmatige inskrywing stilweg watter pad wen. Teken die verwyderingsstap in die verandering aan.

Sodra die korrekte roete aktief is, toets die teikentoepassing eerder as ’n ping. As pakkette Azure bereik maar die diens steeds misluk, kyk na die netwerksekuriteitsgroep en die terugpad, want dit staan apart daarvan of die skootrekenaar die voorvoegsel geleer het.