VPN ferbûn mar gjin ynternet? Wurkje de fjouwer lagen ôf
In griene yndikator betsjut allinnich dat de tunnel oankaam. Kontrolearje earst it tagongsnetwurk, DNS, it doel fan it profyl en de útgong fan de tsjinner.
De klant seit ferbûn, de browser draait, en elke side einiget yn in tiidferrin. Dy kombinaasje is gewoan en it is gjin tsjinstelling: ferbûn betsjut dat de tunnel ûnderhannele hat, en net mear. Namme-oplossing, rûteleasing en de eigen útgong fan de tsjinner mislearje elk op har eigen manier, en elk hat in oare eigner. Wurkje de lagen yn folchoarder ôf en stopje by de earste dy't mislearret.
Begjin by it netwurk dêr't jo wei kamen
Lûk de tunnel del mei de eigen ôfskiedingskontrôle fan de klant, en besykje dan twa ûnôfhinklike HTTPS-siden as belied it tastiet. Lit gefoelich wurk sletten wêze foar de doer fan dy test. As gewoane tagong ek mislearret, is de VPN net de earste fertochte.
Sjoch nei de Wi-Fi-ferbining, de router en elke portal-side dy't oanmelding freget foar't jo de tunnel oanreitsje. In kill switch kin ferkear blokkearje wylst jo ôfskieden binne neffens it ûntwerp, folgje dus de dokumintearre testproseduere derfan ynstee fan te konkludearjen dat it netwurk dea is. In oar fertroud netwurk is in nuttige ferliking, en in nije VPN-útgong sil in ferrûne hotel-oanmelding net foltôgje. As it iepen netwurk wurket en de tunnel net, is it netwurk frijsprutsen en is de folgjende laach fan jo.
Bepale oft de flater namme-oplossing is
Skriuw de flatertekst op, want in oplossingsflater, in tiidferrin en in sertifikaatswarskôging wize elk earne oars hinne. It patroan om betiid te fangen is in hostnamme dy't jo nea besocht hawwe dy't mislearret wylst in applikaasje mei in iepen sesje trochgiet. Dat patroan giet oer nije opfragen, net oer oft de tunnel pakketten draacht. Ien opfraach lit sjen wat de resolver weromjout, en it kostet in sekonde. Besykje ek in twadde namme, sadat ien cache-antwurd of ien brutsen record de diagnose net beslút.
nslookup example.com
In willekeurige IP yn in HTTPS-adresbalke is gjin DNS-test, want it sertifikaat en de firtuele host hingje meastentiids fan de namme ôf. Ynterne nammen kinne de resolver fan de organisaasje nedich hawwe ynstee fan in iepenbiere ferfanging, en in browser mei in eigen feilige resolver kin oars antwurdzje as de opfraach fan it bestjoeringssysteem. Wêr't de twa faninoar ferskille, is de resolver fan de browser dejinge dy't de brûker ûnderfynt, en dat ûnderskied heart yn it ticket.
Folle tunnel of allinnich bedriuws-subnetten
Guon profilen besteane allinnich om in hantsjefol bedriuws-subnetten te berikken; oare binne boud om alles te dragen en hawwe in wurkjende útgong efter har. Lês it dokumintearre doel foar't jo oannimme dat de yndikator elke applikaasje en elke adresfamylje dekt. In partikulier-netwurkprofyl kin krekt wurkje sa't it ûntwurpen is, wylst de browser, dy't it nea brûke moatten hie, noch altyd mislearret. Lês de rûte-tabel sûnder dy te feroarjen, en nim IPv6 mei, want in wurkjende IPv4-rûte seit neat oer de oare famylje.
In mear spesifike rûte kin winne wylst de standertrûte noch bestiet, dêrom moat de tabel lêzen wurde en net oannommen. Konkurrearjende firtuele adapters kinne ek ferkear besitte dat jo earne oars ferwachte, benammen nei't in twadde VPN-klant ynstallearre en fergetten is. Wiskje de standertrûte net as eksperimint; dat makket in diagnose ta in twadde útfal.
Ien mislearjende side mank wurkjende is in probleem fan dy side, en it bewiist ek dat de tunnel ferkear draacht. Stilstannen dy't allinnich by grutte oerdrachten ferskine wize op pakketgrutte en net op berikberens.
As de tsjinner nea wat trochstjoert
As elke bestimming mislearret op twa apparaten en twa tagongsnetwurken, is de tunnel omheech en stjoert de útgong net troch. Dy pearring skiedt in flater oan de tsjinnerkant fan ien apparaat dat op ien plak ferkeard konfigurearre is. Stjoer de operator de fragen oer trochstjoeren, NAT en weromwei, net in skermprint fan de yndikator.
Dy trije dekke de measte oarsaken oan de tsjinnerkant, en it is oan de operator om se te beantwurdzjen. De OpenVPN-side oer ferbiningsproblemen rint deselde fragen fan de tsjinnerkant ôf, jou se dus mei it ticket mei. In skermprint fan in griene yndikator beantwurdet gjin ien fan har.
Skandeer it klantlog nei de oanmelding foar flaters by it tapassen fan rûtes, DNS-ynstellings of de firtuele adapter. Flaters yn dy faze wize op it apparaat en net op de tsjinner. In flater dy't nea yn it log ferskynt is like ynformtyf, want it ferpleatst it fermoeden nei de oare kant.
Kontrolearje ien laach tagelyk
Sadree't jo wat feroarje, ferbynje opnij en werhelje krekt de applikaasje dy't mislearre. Ien side dy't lade bewist minder as in werhelbere wei nei de boarnen dêr't it profyl foar boud is. Twa opdrachten skiede oplossing fan berikberens, en de twadde is hostspesifyk. Rin de curl-rigel oeral, en rin dan it rûte-opdracht dat by de host foar jo past.
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 it numerike fersyk wurket en de namme net, bliuw by DNS. As gjin fan beide wurket, fergelykje de rûte-tabel mei de ferwachte standert fan de tunnel, en kontrolearje de famylje dy't jo echt testen. As de rûte goed is en it fersyk noch altyd by de útgong stjert, heart de oerbleaune fraach by de operator, en it bewiis dat jo bewarre hawwe is it ticket.