Azure P2S: vienam Windows klientam pēc VNet maiņas zūd maršruti

Divi klēpjdatori autentificējas vienā Azure point-to-site vārtejā, un tikai viens sasniedz tikko pievienoto VNet. Abi rāda Connected, tāpēc autentifikācija nav atšķirība; atšķirība ir galamērķa maršruti, ko tie tur. Sāciet ar klientu, kuram neizdodas, salīdziniet vienu galamērķi un tikai pēc tam izlemiet, vai trūkums pieder vārtejas pakotnei vai vietējai maršrutu tabulai.

Sāciet ar klientu, kuram neizdodas, nevis ar vārteju

Apstipriniet topoloģiju, pirms vainot klēpjdatoru. Pārbaudiet, kuri VNet ir savienoti ar vārtejas VNet un vai jaunais tīkls ir tieši peerots vai sasniedzams caur atsevišķu site-to-site tuneli. Ja jaunais VNet vispār nav savienots ar vārtejas VNet, neviena klienta pakotne nevar uz turieni maršrutēt, un strādājošais klēpjdators ir anomālija, kas jāizskaidro. Pierakstiet atbildi, jo tā nosaka, vai atkļūdojat klientu vai vārteju.

Kad topoloģija ir pareiza, novietojiet abus klēpjdatorus blakus. Viena un tā pati vārteja, viens adrešu pūls, viens protokols un viena klienta versija ir salīdzinājums, ko vēlaties; viss pārējais ir otrs mainīgais, kas vēlāk būs jāizslēdz.

Salīdziniet vienu galamērķi ar route print

Izvēlieties atļautu resursa IP un salīdziniet abus klēpjdatorus divreiz: atvienotus un pēc tam savienotus. Windows route print -4 uzskaita IPv4 maršrutus ar galamērķa prefiksu, saskarni, nākamo lēcienu un metriku. Pierakstiet rindu, kas šim galamērķim patiešām uzvarētu, nevis skaitiet ierakstus, kuros ir vārds VPN.

Atlase vispirms notiek pēc garākā prefiksa, pēc tam pēc metrikas, tāpēc konkrētāks vietējais maršruts var pārspēt tuneļa maršrutu, neizskatoties nepareizi. Ja paredzētais galamērķis ir 10.24.0.0/16 iekšienē, vesels klients rāda atbilstošu maršrutu VPN saskarnē, bet klients, kuram neizdodas, to pašu adresi sūta uz noklusējuma vārteju.

Konfliktējošs vietējais prefikss var radīt to pašu simptomu. Pirms kaut ko pievienot, izlemiet, kurš no diviem gadījumiem jums ir: tuneļa maršruta vispār nav, vai tuneļa maršruts zaudē konkrētākam.

TTL expired nav maršrutu izplatīšanas kļūda

Ping, kas atgriež TTL expired in transit, norāda, ka pakotne ir iztērējusi savu lēcienu kvotu, kas parasti nozīmē pārsūtīšanas cilpu, nevis salauztu VPN draiveri. Windows ping pieņem TTL līdz 255, un vērtības palielināšana cilpu nelabo; tā tikai aizkavē to pašu kļūdu. Uztveriet ziņojumu kā ceļa simptomu, nevis kā pierādījumu par maršrutu izplatīšanu.

Izmantojiet tracert -4 10.24.1.10, lai redzētu, kur ceļš atkārtojas. Ja tie paši divi lēcieni parādās atkal un atkal, meklējiet maršrutu, kas tunelim paredzēto trafiku sūta atpakaļ tunelī vai vietējā maršrutētājā, kas to pārsūta atpakaļ.

Ģenerējiet pakotni no jauna vārtejā, kurai tā pieder

Microsoft dokumentē, ka Windows klientu pakotnes pēc būtiskām topoloģijas izmaiņām ir jālejupielādē un jāinstalē no jauna. Iegūstiet pašreizējo pakotni no Azure vārtejas, kas apkalpo šo profilu, un pēc tam piemērojiet to ar atbalstīto procesu šim klientam. Nesaistītas VPN lietotnes izpildāmā faila aizstāšana nav tā pati darbība kā vārtejai raksturīgu iestatījumu atkārtota ģenerēšana. Pakotnes atkārtota lejupielāde ir lēta; minēt vietējos maršrutus nav.

Pieslēdzieties no jauna un vēlreiz nolasiet sākotnējā galamērķa maršrutu. Saglabājiet rindas pirms un pēc kopā ar izmaiņu ierakstu, lai rezultāts būtu precīzāks par reinstalēju klientu.

Azure P2S maršrutēšanas scenāriji atdala tieši peerotus VNet no tīkliem, kas sasniedzami caur citiem tuneļiem, un jauna pakotne nevar padarīt peerings transitīvu. Dažiem Windows site-to-site vai BGP scenārijiem ir vajadzīgi arī manuāli konfigurēti attālināti maršruti, tāpēc pakotnes atsvaidzināšana nav universāls maršrutu izplatīšanas mehānisms.

Turiet pagaidu maršrutu pagaidu

Manuāls maršruts var izolēt trūkstošu klienta maršrutu, bet veidojiet to no reālās konstrukcijas: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, bez pastāvīgā karoga, lai tas pēc pārstartēšanas pazustu. Saskarnes indeksu un nākamo lēcienu izvēlieties no pievienotā VPN adaptera, nevis no minējuma.

Neatstājiet eksperimentālu maršrutu kā pastāvīgu konkurējošu īpašnieku. Turpmāki profila atjauninājumi var pievienot to pašu prefiksu ar citu metriku, un tad manuālais ieraksts klusi izlemj, kurš ceļš uzvar. Ierakstiet noņemšanas soli izmaiņās.

Kad pareizais maršruts ir aktīvs, testējiet mērķa lietotni, nevis ping. Ja pakotnes sasniedz Azure, bet pakalpojums joprojām neizdodas, pārbaudiet tīkla drošības grupu un atgriešanās ceļu, jo tie ir neatkarīgi no tā, vai klēpjdators ir iemācījies prefiksu.