Geen internet op 'n Windows-VPN? Die adrespoel is die verdagte

Windows wys die tonnel as gekoppel en noem dit Geen internettoegang, wat mense as 'n Windows-eienaardigheid lees. Dit sê iets oor wat die kliënt ontvang het: geen bruikbare verstekdeurgang nie, geen werkende oplosser nie, of geen pad terug vir die adresse binne die tonnel nie. Wanneer die bediener 'n Windows Inkomende Verbinding is, verduidelik een enkele instelling die meeste van hierdie verslae. Die etiket is nie 'n diagnose nie, maar dit vernou die soektog na drie plekke.

Lees die toekenning voordat jy dit verander

Voer ipconfig /all op die kliënt uit en vind die VPN-adapter onder die inskrywings. Die adres, die verstekdeurgang en die DNS-bediener wat dit lys, is die feite wat jy nodig het, en hulle verskil dikwels van wat die administrateur aanneem uitgedeel is.

Drie patrone stem ooreen met drie foute. 'n Adres in 169.254.0.0/16 beteken die kliënt het glad niks ontvang nie en het homself 'n skakel-plaaslike adres gegee. 'n Geloofwaardige adres sonder 'n deurgang beteken die poel is bedien sonder die opsie wat die kliënt 'n verstekroete gee. 'n Volledige toekenning wat steeds niks bereik nie, dui op aanstuur of vertaling aan die bedienerkant.

Skryf die waardes neer voordat jy aan die bediener raak. Die volgende stap vergelyk hulle met die reeks wat die bediener dink hy deel uit, en geheue is 'n swak plaasvervanger vir 'n toekenning.

Waarom outomatiese toewysing geen deurgang kan laat

Die inskrywing Inkomende Verbindings het sy eie IPv4-eienskappe, apart van die fisiese adapter. Die verstek daar bied aan om adresse outomaties toe te wys, wat op die verbinding se ingeboude toewyser staatmaak om 'n adres, 'n masker, 'n deurgang en DNS te verskaf.

Op 'n alleenstaande werkstasie het daardie toewyser geen omvang om uit te put nie, tensy iets anders op die masjien een verskaf, so die kliënt kan met 'n skakel-plaaslike adres eindig of met 'n adres maar geen deurgang nie. Die verbinding lyk gevestig omdat die skakel opgekom het, terwyl die konfigurasie daaronder onvolledig is.

Dit is hoekom die oorskakeling na 'n gespesifiseerde reeks so baie van hierdie verslae regstel. Jy hou op om 'n diens wat dalk nie loop nie te vra om 'n toekenning te versin, en begin om die toekenning self te stel.

Dieselfde verwarring kom voor wanneer iemand verwag dat die LAN-router se DHCP-bediener tonnelkliënte moet bedien. Uitsaaiontdekking steek nie 'n gerouteerde tonnel oor nie, so daardie bediener sien nooit die versoek nie. Om anders aan te neem is die algemeenste rede waarom 'n poel geblameer word vir 'n kliënt wat dit nooit iets gevra het nie.

Stel 'n eksplisiete reeks wat die bediener kan routeer

Kies 'n klein blok binne 'n subnet wat die bediener kan bereik, buite die reeks wat die LAN-router uitdeel, en buite enige ander poel op die netwerk. As die bediener op 172.20.10.0/24 sit en die router hou 172.20.10.1, hou 'n kort blok naby die bokant van daardie subnet, sê 172.20.10.201 tot 172.20.10.209, tonneltoekennings weg van die uitdeel wat die router reeds bestuur.

Voer dit in die IPv4-eienskappe van die Inkomende Verbinding in, koppel die kliënt weer, en lees die adapter weer voordat jy enigiets anders verander. 'n Tweede lesing is wat jou vertel of die poel die fout was of bloot een fout onder verskeie.

Hierdie opdragte druk die resulterende konfigurasie en die roetes wat die kliënt nou het:

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

Die deurgang in die toekenning moet 'n adres wees wat die bediener hou, en die kliënt se verstekroete moet daarheen wys. As die toekenning volledig is maar geen roete bestaan nie, het die bediener toegewys sonder om 'n deurgang te stoot, en die poelinstellings is steeds die plek om te kyk.

'n Adres is nie 'n internetpad nie

Om 'n toekenning te ontvang skuif net pakkette van die kliënt na die bediener. Vir internettoegang moet die bediener daardie pakkette aanstuur en na sy eie opvoer vertaal, en dit is 'n aparte konfigurasie met sy eie foutmodusse.

Internet Connection Sharing is die kortpad. Dit verander die internetgerigte adapter in 'n gedeelde deurgang en dryf sy eie adressering, wat daardie adapter se adres kan herskryf en 'n bestaande NAT-reël kan laat wys na 'n waarde wat nie meer bestaan nie. Teken die oorspronklike instellings aan voordat jy dit aktiveer.

Die gerouteerde alternatief hou die adressering stabiel en vra jou om aanstuur en vertaling eksplisiet op te stel. Nie een benadering is verkeerd nie; om hulle halfpad te meng lewer 'n tonnel met 'n toekenning en geen uitgang, wat presies die simptoom is waarmee jy begin het. Kies een model en maak dit klaar voordat jy die ander byvoeg.

Sluit eers die buitenste pad uit

Geen poel kan help as die tonnel nooit vorm nie. Die protokol bepaal wat die pad moet dra: PPTP wil TCP 1723 en GRE, wat IP-protokol 47 is eerder as 'n poort; L2TP/IPsec wil UDP 1701 plus 500 en 4500; SSTP wil TCP 443.

'n Router wat die poort aanstuur maar nie die protokol nie, lewer 'n verbindingspoging wat nooit verifieer nie. Dit is 'n ander fout as 'n tonnel wat vorm en dan niks bereik, en die twee moet nie saam ontfout word nie.

Toets van dieselfde LAN en van die afgeleë netwerk. As die LAN-poging werk en die afgeleë een nooit verifikasie bereik nie, is die buitenste pad die probleem. As albei verifieer en net die afgeleë kliënt het geen internet nie, gaan terug na die poel en die uitgang.