Azure P2S: vienam Windows klientui po VNet pakeitimo dingo maršrutai

Du nešiojamieji kompiuteriai autentifikuojasi tame pačiame Azure point-to-site šliuze, ir tik vienas pasiekia naujai prijungtą VNet. Abu rodo Connected, tad autentifikacija nėra skirtumas; skirtumas yra tikslo maršrutai, kuriuos jie laiko. Pradėkite nuo kliento, kuris nepavyksta, palyginkite vieną tikslą ir tik tada nuspręskite, ar spragą valdo šliuzo paketas, ar vietinė maršrutų lentelė.

Pradėkite nuo nepavykstančio kliento, o ne nuo šliuzo

Patvirtinkite topologiją prieš kaltindami nešiojamąjį kompiuterį. Patikrinkite, kurie VNet yra prijungti prie šliuzo VNet, ir ar naujasis tinklas tiesiogiai peerinamas, ar pasiekiamas per atskirą site-to-site tunelį. Jei naujasis VNet visiškai neprijungtas prie šliuzo VNet, joks kliento paketas negali ten maršrutizuoti, o veikiantis nešiojamasis kompiuteris yra anomalija, kurią reikia paaiškinti. Užsirašykite atsakymą, nes jis nusprendžia, ar derinate klientą, ar šliuzą.

Kai topologija teisinga, pastatykite abu nešiojamuosius kompiuterius greta. Tas pats šliuzas, tas pats adresų telkinys, tas pats protokolas ir ta pati kliento versija yra palyginimas, kurio norite; visa kita yra antrasis kintamasis, kurį vėliau turėsite pašalinti.

Palyginkite vieną tikslą su route print

Pasirinkite leistiną ištekliaus IP ir palyginkite abu nešiojamuosius kompiuterius du kartus: atjungtus ir tada prijungtus. Windows sistemoje route print -4 išvardija IPv4 maršrutus su tikslo priešdėliu, sąsaja, kitu šuoliu ir metrika. Užrašykite eilutę, kuri iš tikrųjų laimėtų tam tikslui, o ne skaičiuokite įrašus, kuriuose yra žodis VPN.

Pasirinkimas pirmiausia pagal ilgiausią priešdėlį, paskui pagal metriką, todėl konkretesnis vietinis maršrutas gali nugalėti tunelio maršrutą neatrokdamas neteisingai. Jei numatytas tikslas yra 10.24.0.0/16 viduje, sveikas klientas rodo atitinkantį maršrutą VPN sąsajoje, o nepavykstantis klientas tą patį adresą siunčia savo numatytajam šliuzui.

Konfliktuojantis vietinis priešdėlis gali sukelti tą patį simptomą. Prieš ką nors pridėdami nuspręskite, kuris iš dviejų atvejų jūsų: tunelio maršruto visai nėra, ar tunelio maršrutas pralaimi konkretesniam.

TTL expired nėra maršrutų platinimo klaida

Ping, kuris grąžina TTL expired in transit, sako, kad paketas išnaudojo savo šuolių kvotą, o tai paprastai reiškia persiuntimo kilpą, o ne sugedusį VPN tvarkyklę. Windows ping priima TTL iki 255, o reikšmės padidinimas kilpos nepataiso; jis tik atideda tą pačią klaidą. Traktuokite pranešimą kaip kelio simptomą, o ne kaip įrodymą apie maršrutų platinimą.

Naudokite tracert -4 10.24.1.10, kad pamatytumėte, kur kelias kartojasi. Jei tie patys du šuoliai pasirodo vėl ir vėl, ieškokite maršruto, kuris į tunelį nukreiptą srautą grąžina atgal į tunelį arba į vietinį maršrutizatorių, kuris jį persiunčia atgal.

Iš naujo sugeneruokite paketą šliuze, kuriam jis priklauso

Microsoft dokumentuoja, kad Windows klientų paketus reikia iš naujo atsisiųsti ir įdiegti po reikšmingų topologijos pakeitimų. Gaukite dabartinį paketą iš Azure šliuzo, kuris aptarnauja šį profilį, tada pritaikykite jį palaikomu procesu tam klientui. Nesusijusios VPN programos vykdomojo failo pakeitimas nėra ta pati operacija kaip šliuzui būdingų nustatymų regeneravimas. Paketą atsisiųsti iš naujo pigu; spėlioti vietinius maršrutus ne.

Prisijunkite iš naujo ir dar kartą perskaitykite pradinio tikslo maršrutą. Saugokite eilutes prieš ir po kartu su pakeitimo įrašu, kad rezultatas būtų tikslesnis nei iš naujo įdiegiau klientą.

Azure P2S maršrutizavimo scenarijai atskiria tiesiogiai peerinamus VNet nuo tinklų, pasiekiamų per kitus tunelius, o naujas paketas negali padaryti peerinimo tranzityvaus. Kai kurie Windows site-to-site ar BGP scenarijai taip pat reikalauja rankiniu būdu sukonfigūruotų nuotolinių maršrutų, todėl paketo atnaujinimas nėra universalus maršrutų platinimo mechanizmas.

Laikykite laikiną maršrutą laikinu

Rankinis maršrutas gali išskirti trūkstamą kliento maršrutą, bet kurkite jį iš tikrosios konstrukcijos: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, be nuolatinės vėliavėlės, kad jis išnyktų paleidus iš naujo. Sąsajos indeksą ir kitą šuolį rinkitės iš prijungto VPN adapterio, o ne iš spėjimo.

Nepalikite eksperimentinio maršruto kaip nuolatinio konkuruojančio savininko. Būsimi profilio atnaujinimai gali pridėti tą patį priešdėlį su kitokia metrika, ir tada rankinis įrašas tyliai nusprendžia, kuris kelias laimės. Užrašykite pašalinimo veiksmą pakeitime.

Kai teisingas maršrutas aktyvus, testuokite tikslinę programą, o ne ping. Jei paketai pasiekia Azure, bet paslauga vis tiek nepavyksta, patikrinkite tinklo saugos grupę ir grįžtamąjį kelią, nes jie nepriklauso nuo to, ar nešiojamasis kompiuteris išmoko priešdėlį.