VPN gekoppel maar geen internet? Werk deur die vier lae
’n Groen aanwyser beteken net die tonnel het opgekom. Kontroleer eers die toegangsnetwerk, DNS, die profiel se doel en die bediener se uitgang.
Die kliënt sê gekoppel, die blaaier draai, en elke webwerf eindig in ’n tydsverloop. Daardie kombinasie is algemeen en dit is nie ’n teenstrydigheid nie: gekoppel beteken die tonnel het onderhandel, en niks meer nie. Naamresolusie, roetering en die bediener se eie uitgang faal elkeen op sy eie manier, en elkeen het ’n ander eienaar. Werk die lae in volgorde en stop by die eerste een wat faal.
Begin by die netwerk waar jy vandaan kom
Breek die tonnel met die kliënt se eie ontkoppelbeheer, en probeer dan twee onverwante HTTPS-webwerwe as beleid dit toelaat. Laat sensitiewe werk gesluit vir die duur van daardie toets. As gewone toegang ook misluk, is die VPN nie die eerste verdagte nie.
Kyk na die Wi-Fi-skakel, die roeter en enige portaalbladsy wat aanmelding eis voordat jy aan die tonnel raak. ’n Kill switch kan verkeer blokkeer terwyl jy ontkoppel is, per ontwerp, so volg sy gedokumenteerde toetsprosedure eerder as om af te lei dat die netwerk dood is. ’n Ander betroubare netwerk is ’n nuttige vergelyking, en ’n nuwe VPN-uitgang sal nie ’n vervalle hotel-aanmelding voltooi nie. As die oop netwerk werk en die tonnel nie, is die netwerk vrygespreek en die volgende laag is joune.
Bepaal of die fout naamresolusie is
Skryf die foutteks neer, want ’n resolusiefout, ’n tydsverloop en ’n sertifikaatwaarskuwing wys elkeen na iets anders. Die patroon om vroeg te vang is ’n gasheernaam wat jy nog nooit besoek het wat faal terwyl ’n toepassing met ’n oop sessie aanhou werk. Daardie patroon gaan oor nuwe opsoektogte, nie oor die tonnel wat pakkette dra nie. ’n Enkele opsoektog wys wat die resolver teruggee, en dit neem ’n sekonde om te hardloop. Probeer ook ’n tweede naam, sodat een gekasde antwoord of een gebreekte rekord nie die diagnose beslis nie.
nslookup example.com
’n Willekeurige IP in ’n HTTPS-adresbalk is nie ’n DNS-toets nie, want die sertifikaat en die virtuele gasheer hang gewoonlik van die naam af. Interne name het dalk die organisasie se resolver nodig eerder as ’n openbare plaasvervanger, en ’n blaaier met sy eie veilige resolver kan anders antwoord as die bedryfstelsel se opsoektog. Waar die twee verskil, is die blaaier se resolver die een wat die gebruiker ervaar, en daardie onderskeid hoort in die kaartjie.
Volle tonnel of net maatskappy-subnette
Sommige profiele bestaan net om ’n handvol maatskappy-subnette te bereik; ander is gebou om alles te dra en het ’n werkende uitgang agter hulle nodig. Lees die gedokumenteerde doel voordat jy aanneem die aanwyser dek elke toepassing en elke adresfamilie. ’n Privaatnetwerk-profiel kan presies werk soos ontwerp terwyl die blaaier, wat nooit bedoel was om dit te gebruik nie, steeds faal. Lees die roetetabel sonder om dit te verander, en sluit IPv6 in, want ’n werkende IPv4-roete sê niks oor die ander familie nie.
’n Meer spesifieke roete kan wen terwyl die verstekroete nog bestaan, en daarom moet die tabel gelees word eerder as aangeneem. Mededingende virtuele adapters kan ook verkeer besit wat jy elders verwag het, veral nadat ’n tweede VPN-kliënt geïnstalleer en vergeet is. Moenie die verstekroete as ’n eksperiment uitvee nie; dit verander ’n diagnose in ’n tweede onderbreking.
’n Enkele webwerf wat faal onder dié wat werk, is ’n probleem met daardie webwerf, en dit bewys ook die tonnel dra verkeer. Stilstande wat net by groot oordragte verskyn, wys na pakketgrootte eerder as na bereikbaarheid.
Wanneer die bediener nooit iets aanstuur nie
As elke bestemming op twee toestelle en twee toegangsnetwerke faal, is die tonnel op en stuur die uitgang nie aan nie. Daardie kombinasie skei ’n fout aan die bedienerkant van een toestel wat op een plek verkeerd opgestel is. Stuur die aanstuur-, NAT- en terugpad-vrae aan die operateur, nie ’n skermkiekie van die aanwyser nie.
Daardie drie dek die meeste oorsake aan die bedienerkant, en dit is die operateur se taak om te antwoord. Die OpenVPN-verbindingsprobleem-bladsy loop dieselfde vrae van die bedienerkant af, so gee dit saam met die kaartjie oor. ’n Skermkiekie van ’n groen aanwyser beantwoord nie een van hulle nie.
Skandeer die kliëntlog ná aanmelding vir foute by die toepassing van roetes, DNS-instellings of die virtuele adapter. Foute in daardie stadium wys na die toestel eerder as na die bediener. ’n Fout wat nooit in die log verskyn nie, is ewe insiggewend, want dit skuif die vermoede na die ander kant.
Kontroleer een laag op ’n slag
Sodra jy iets verander, koppel weer en herhaal die presiese toepassing wat gefaal het. Een bladsy wat laai bewys minder as ’n herhaalbare pad na die hulpbronne waarvoor die profiel gebou is. Twee opdragte skei resolusie van bereikbaarheid, en die tweede een is gasheerspesifiek. Hardloop die curl-lyn enige plek, en hardloop dan die roete-opdrag wat by die gasheer voor jou pas.
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4 # Windows
ip -4 route show # Linux
netstat -rn | head # macOS
As die numeriese versoek werk en die naam nie, bly by DNS. As nie een werk nie, vergelyk die roetetabel met die tonnel se verwagte verstek, en kyk na die familie wat jy werklik toets. As die roete reg is en die versoek sterf steeds by die uitgang, hoort die oorblywende vraag by die operateur, en die bewyse wat jy gehou het, is die kaartjie.