Nėra interneto „Windows VPN“? Įtariamasis – adresų telkinys

Windows rodo tunelį kaip prijungtą ir žymi jį Nėra interneto prieigos, ką žmonės skaito kaip Windows ypatumą. Tai teiginys apie tai, ką gavo klientas: nėra naudojamos numatytosios šliuzo, nėra veikiančio sprendiklio arba nėra grįžimo kelio adresams tunelio viduje. Kai serveris yra Windows Incoming Connection, vienas nustatymas paaiškina daugumą tokių pranešimų. Žymė nėra diagnozė, bet susiaurina paiešką iki trijų vietų.

Perskaitykite rezervavimą prieš jį keisdami

Paleiskite ipconfig /all kliente ir raskite VPN adapterį tarp įrašų. Jame nurodyti adresas, numatytasis šliuzas ir DNS serveris yra faktai, kurių jums reikia, ir jie dažnai skiriasi nuo to, ką administratorius mano buvus išduotus.

Trys modeliai atitinka tris gedimus. Adresas 169.254.0.0/16 reiškia, kad klientas negavo nieko ir priskyrė sau sąsajos-vietinį adresą. Tikėtinas adresas be šliuzo reiškia, kad telkinys buvo aptarnautas be parinkties, kuri klientui suteikia numatytąjį maršrutą. Visiškas rezervavimas, kuris vis tiek nieko nepasiekia, rodo serverio pusės persiuntimą arba vertimą.

Užsirašykite reikšmes prieš liesdami serverį. Kitas žingsnis lygina jas su diapazonu, kurį serveris mano skirstantis, o atmintis yra prasta rezervavimo pakaitalas.

Kodėl automatinis priskyrimas gali palikti be šliuzo

Įrašas Incoming Connections turi savo IPv4 ypatybes, atskiras nuo fizinio adapterio. Ten numatytasis siūlo priskirti adresus automatiškai, o tai remiasi įtaisytuoju jungties skirstytuvu, kuris pateikia adresą, kaukę, šliuzą ir DNS.

Atskiroje darbo stotyje tas skirstytuvas neturi diapazono, iš kurio semtų, nebent kažkas kita mašinoje pateikia vieną, todėl klientas gali likti su sąsajos-vietiniu adresu arba su adresu, bet be šliuzo. Ryšys atrodo užmegztas, nes sąsaja pakilo, o konfigūracija už jo yra nepilna.

Štai kodėl perėjimas prie nurodyto diapazono ištaiso tiek daug šių pranešimų. Nustojate prašyti paslaugos, kuri galbūt neveikia, sugalvoti rezervavimą ir pradedate patys jį deklaruoti.

Tas pats sumišimas atsiranda, kai kas nors tikisi, kad LAN maršrutizatoriaus DHCP serveris aptarnaus tunelio klientus. Transliacinis aptikimas neperžengia maršrutizuoto tunelio, todėl tas serveris niekada nemato užklausos. Manyti priešingai yra dažniausia priežastis, kodėl telkinys kaltinamas dėl kliento, kuris jo niekada nieko neprašė.

Nustatykite aiškų diapazoną, kurį serveris gali maršrutizuoti

Pasirinkite mažą bloką potinklyje, kurį serveris pasiekia, už LAN maršrutizatoriaus skirstomo diapazono ir už bet kurio kito telkinio tinkle. Jei serveris yra 172.20.10.0/24, o maršrutizatorius turi 172.20.10.1, trumpas blokas prie to potinklio viršaus, tarkime nuo 172.20.10.201 iki 172.20.10.209, laiko tunelio rezervavimus atokiai nuo paskirstymo, kurį maršrutizatorius jau valdo.

Įveskite jį Incoming Connection IPv4 ypatybėse, iš naujo prijunkite klientą ir dar kartą perskaitykite adapterį prieš ką nors keisdami. Antrasis skaitymas pasako, ar telkinys buvo gedimas, ar tik vienas iš kelių.

Šios komandos išspausdina gautą konfigūraciją ir maršrutus, kuriuos klientas dabar turi:

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

Šliuzas rezervavime turėtų būti adresas, kurį turi serveris, o kliento numatytasis maršrutas turėtų rodyti į jį. Jei rezervavimas pilnas, bet maršruto nėra, serveris priskyrė nestumdamas šliuzo, o telkinio nustatymai vis dar yra vieta, kur žiūrėti.

Adresas nėra interneto kelias

Rezervavimo gavimas tik perkelia paketus iš kliento į serverį. Norint prieigos prie interneto, serveris turi persiųsti tuos paketus ir išversti juos savo uplink link, ir tai yra atskira konfigūracija su savais gedimo režimais.

Internet Connection Sharing yra trumpiausias kelias. Jis paverčia į internetą atsuktą adapterį bendru šliuzu ir vykdo savo adresaciją, kuri gali perrašyti to adapterio adresą ir palikti esamą NAT taisyklę nurodančią reikšmę, kurios nebėra. Užsirašykite pradinius nustatymus prieš jį įjungdami.

Maršrutizuota alternatyva išlaiko adresaciją stabilią ir prašo jūsų aiškiai sukonfigūruoti persiuntimą ir vertimą. Nė vienas požiūris nėra neteisingas; sumaišius juos pusiau gaunamas tunelis su rezervavimu ir be išėjimo, o tai būtent simptomas, nuo kurio pradėjote. Pasirinkite vieną modelį ir užbaikite jį prieš pridėdami kitą.

Pirmiausia pašalinkite išorinį kelią

Joks telkinys nepadės, jei tunelis niekada nesusidaro. Protokolas nusprendžia, ką kelias turi nešti: PPTP nori TCP 1723 ir GRE, o tai IP protokolas 47, ne prievadas; L2TP/IPsec nori UDP 1701 plius 500 ir 4500; SSTP nori TCP 443.

Maršrutizatorius, kuris persiunčia prievadą, bet ne protokolą, sukuria prisijungimo bandymą, kuris niekada neautentifikuojamas. Tai kitas gedimas nei tunelis, kuris susidaro ir tada nieko nepasiekia, ir abiejų nereikėtų derinti kartu.

Išbandykite iš to paties LAN ir iš nuotolinio tinklo. Jei LAN bandymas veikia, o nuotolinis niekada nepasiekia autentifikacijos, išorinis kelias yra problema. Jei abu autentifikuojasi ir tik nuotolinis klientas neturi interneto, grįžkite prie telkinio ir išėjimo.