VPN is verbind maar die IP-adres het nie verander nie: hoekom

Jy maak verbinding, die kliënt sê verbind, en die adrestoets wys nog dieselfde nommer as vantevore. Niks is fout met die aanduiding nie; iets tussen die profiel en die toepassing het daardie versoek buite die tonnel gehou. Besluit by watter van drie dinge jy kyk voordat jy enige instelling aanraak: 'n toets wat nooit die openbare adres gemeet het nie, 'n tonnel wat net 'n deel van die verkeer dek, of 'n tweede pad wat die roetebesluit wen. Elk het een kontrole wat minder as 'n minuut neem.

Bevestig wat die toets werklik gemeet het

Die adres in die Wi-Fi- of Ethernet-dialoogvenster is die koppelvlakadres op jou eie segment, nie die adres wat 'n webwerf sien nie, so dit kan dieselfde bly terwyl die tonnel perfek werk. Ligging is weer 'n aparte sein: 'n gestoorde rekeningstreek of 'n toegelate geoleesing beweeg nie wanneer jy die uitgang verander nie, en 'n aanmelding wat jou reeds herken ook nie.

Gebruik 'n weerklank van die openbare adres en vra elke familie afsonderlik, want 'n toetsresultaat met dubbele stapel verberg die interessante geval:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Voer albei voor en ná die verbinding uit. As die IPv4-antwoord na die uitgangadres verander en die IPv6-antwoord nie, het jy nie 'n stukkende tonnel nie; jy het een familie wat buite dit beweeg. As albei antwoorde dieselfde bly, het die versoek nooit die tonnel bereik nie en geld die res hiervan.

Die profiel dek miskien net 'n deel van die verkeer

'n Profiel met 'n gesplete tonnel is die algemene antwoord, en dit is nie 'n fout nie. OpenVPN stuur alles deur die tonnel net wanneer redirect-gateway in die gestuurde opsies is; sonder dit kry die kliënt 'n handvol spesifieke roetes en bly jou verstekroete op die fisiese skakel. Op Windows verskyn dieselfde skakelaar as "Gebruik verstekgateway op afgeleë netwerk" in die koppelvlak se IPv4-eienskappe, en om dit te skrap is 'n doelbewuste keuse wat elke herverbinding oorleef.

Omvang per toepassing is die tweede laag. Android se VPN-instelling per toepassing bepaal watter toepassings ingesluit is, so die VPN-sleutel in die statusbalk bewys nie dat die blaaier binne dit is nie. 'n Blaaieruitbreiding wat sy eie verkeer deurstuur, skep die spieëlbeeld: die blaaier wys die uitgangadres terwyl 'n e-poskliënt of speletjie op dieselfde masjien nog joune wys. Vergelyk dieselfde versoek in twee toepassings. As een verander en die ander nie, kyk jy na omvang, nie na 'n falende tonnel nie.

Een adresfamilie kan steeds direk gaan

Die meeste VPN-profiele is vir IPv4 geskryf, en baie is dit nog. Op 'n netwerk met dubbele stapel neem die tonnel 10.8.0.x vir IPv4 terwyl die fisiese skakel 'n globale IPv6-adres en 'n verstekroete hou, so 'n werf met IPv6-ondersteuning word direk bereik en die adres wat dit rapporteer, is dié van jou verskaffer. Dit is 'n lek met 'n werkende IPv4-tonnel, en dit is onsigbaar vir 'n toets wat net IPv4 praat.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Lees die koppelvlak in elke antwoord. As die IPv6-soektog jou Ethernet- of Wi-Fi-toestel noem terwyl die IPv4-soektog die tonnel noem, ontbreek die beleid vir daardie familie eerder as dat dit stukkend is. Om IPv6 toestelwyd af te skakel, laat die simptoom verdwyn en verberg die besluit; verkies om die profiel se dekking reg te maak of die familie op daardie een verbinding te deaktiveer, en teken aan watter van die twee jy gekies het.

'n Tweede pad kan die soektog wen

'n Mededingende instaanbediener, 'n tweede VPN-kliënt, 'n virtuele koppelvlak van 'n houer of afgeleë-lessenaar-gereedskap, of 'n ekstra roete vir die presiese voorvoegsel wat jy toets, kan almal voorrang kry. 'n Spesifieke roete klop altyd 'n verstekroete, so 'n oorblywende /24 vir die werf wat jy meet, wat na jou LAN-poort wys, hou daardie verkeer buite die tonnel ongeag hoe gesond die tonnel is.

Neem 'n inventaris voordat jy enigiets verander, met lees-alleen-opdragte:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Soek na meer as een verstekroete met 'n geloofwaardige maatstaf, en na 'n spesifieke roete wat die bestemming dek. Kyk in 'n blaaier ook of 'n instaan-uitbreiding of die stelsel se instaaninstelling die verbinding besit; 'n uitbreiding kan sy eie opstroom noem en die bedryfstelsel se uitgang onaangeraak laat, wat 'n ander adres in die blaaier as in 'n terminaal op dieselfde masjien lewer.

Meet weer met 'n vars versoek

Verbind weer en herhaal dan die meting vanuit dieselfde toepassing wat jy die eerste keer getoets het, want 'n gekaste bladsy of 'n hergebruikte verbinding rapporteer die ou toestand. Dophou die kliënt se log of gebeurtenisaansig tydens die verbinding: 'n fout by die toepassing van roetes ná verifikasie is sterker bewyse as enige aanduiding, en dit noem gewoonlik die roete of die koppelvlak wat gefaal het.

Hou twee uitkomste apart. As die adres verander maar een werf weier jou steeds, werk die tonnel en verwerp die werf 'n adres van 'n datasentrum; dit is 'n ander probleem met 'n ander antwoord. As die adres nooit verander nie, werk die vier vrae in volgorde deur: watter adres het die toets gedruk, watter familie was dit, watter toepassing het die versoek gemaak, en watter roete het daardie versoek gevolg. Die Microsoft-dokumentasie oor VPN-roetebesluite verduidelik hoe 'n Windows-kliënt tussen die tonnel en die fisiese koppelvlak kies wanneer albei 'n roete het.