VPN konektita sed la IP-adreso ne ŝanĝiĝis: kial

Vi konektiĝas, la kliento diras konektita, kaj la adresa testo ankoraŭ montras la saman numeron, kiun vi havis antaŭe. La indikilo ne havas difekton; io inter la profilo kaj la aplikaĵo tenis tiun peton ekster la tunelo. Decidu, kiun el tri aferoj vi rigardas, antaŭ ol tuŝi ajnan agordon: testo, kiu neniam mezuris la publikan adreson, tunelo, kiu kovras nur parton de la trafiko, aŭ dua vojo, kiu gajnas la enkursigan decidon. Ĉiu havas unu kontrolon, kiu daŭras malpli ol minuton.

Konfirmu, kion la testo efektive mezuris

La adreso montrata en la dialogujo de Wi-Fi aŭ Ethernet estas la interfaca adreso en via propra segmento, ne la adreso, kiun vidas retejo, do ĝi povas resti identa dum la tunelo funkcias perfekte. Loko denove estas aparta signalo: konservita konta regiono aŭ permesita geoloka legado ne moviĝas, kiam vi ŝanĝas la eliron, kaj nek ensaluto, kiu jam rekonas vin.

Uzu eĥon de la publika adreso kaj demandu ĉiun familion aparte, ĉar rezulto de duobla-staka testo kaŝas la interesan kazon:

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

Rulu ambaŭ antaŭ kaj post konektiĝo. Se la IPv4-respondo ŝanĝiĝas al la elira adreso kaj la IPv6-respondo ne, vi ne havas rompitan tunelon; vi havas unu familion vojaĝantan ekster ĝi. Se ambaŭ respondoj restas la samaj, la peto tute ne atingis la tunelon kaj la cetero ĉi tie validas.

La profilo eble kovras nur parton de la trafiko

Fendita-tunela profilo estas la kutima respondo, kaj ĝi ne estas difekto. OpenVPN sendas ĉion tra la tunelo nur kiam redirect-gateway estas inter la senditaj opcioj; sen ĝi la kliento ricevas manplenon da specifaj vojoj kaj via defaŭlta vojo restas sur la fizika ligo. En Windows la sama ŝaltilo aperas kiel „Uzi defaŭltan enirejon en malproksima reto“ en la IPv4-ecoj de la adaptilo, kaj malmarki ĝin estas intenca elekto, kiu postvivas ĉiun rekonekton.

Aplikaĵa amplekso estas la dua tavolo. La agordo de VPN por aplikaĵo en Android decidas, kiuj aplikaĵoj estas inkluzivitaj, do la VPN-ŝlosilo en la statobreto ne pruvas, ke la retumilo estas ene. Retumila etendaĵo, kiu prokuras sian propran trafikon, kreas la spegulan bildon: la retumilo montras la eliran adreson dum retpoŝta kliento aŭ ludo sur la sama maŝino ankoraŭ montras vian. Komparu la saman peton en du aplikaĵoj. Se unu ŝanĝiĝas kaj la alia ne, vi rigardas amplekson, ne malsukcesan tunelon.

Unu adresa familio ankoraŭ povas iri rekte

Plej multaj VPN-profiloj estis verkitaj por IPv4, kaj multaj ankoraŭ estas tiaj. En duobla-staka reto la tunelo prenas 10.8.0.x por IPv4 dum la fizika ligo tenas tutmondan IPv6-adreson kaj defaŭltan vojon, do retejo kun IPv6-subteno atingiĝas rekte kaj la adreso, kiun ĝi raportas, estas tiu de via provizanto. Tio estas liko kun funkcianta IPv4-tunelo, kaj ĝi estas nevidebla por testo, kiu parolas nur IPv4.

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

Legu la interfacon en ĉiu respondo. Se la IPv6-serĉo nomas vian Ethernet- aŭ Wi-Fi-aparaton dum la IPv4-serĉo nomas la tunelon, la politiko por tiu familio mankas anstataŭ esti rompita. Malŝalti IPv6 por la tuta aparato igas la simptomon malaperi kaj kaŝas la decidon; prefere riparu la kovradon de la profilo aŭ malŝaltu la familion nur sur tiu unu konekto, kaj notu, kiun el la du vi elektis.

Dua vojo povas gajni la serĉon

Konkurenca prokuro, dua VPN-kliento, virtuala adaptilo el ujo aŭ fora labortabla ilo, aŭ plia vojo por la ĝusta prefikso, kiun vi testas, ĉiuj povas akiri prioritaton. Specifa vojo ĉiam venkas defaŭltan vojon, do restanta /24 por la retejo, kiun vi mezuras, montranta al via LAN-enirejo, daŭre sendas tiun trafikon ekster la tunelo, kiom sana ajn la tunelo estas.

Faru inventaron antaŭ ol ŝanĝi ion ajn, per leg-nuraj komandoj:

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

Serĉu pli ol unu defaŭltan vojon kun kredinda metriko, kaj specifan vojon kovrantan la celon. En retumilo, ankaŭ kontrolu, ĉu prokura etendaĵo aŭ la sistema prokura agordo posedas la konekton; etendaĵo povas nomi sian propran suprenfluon kaj lasi la eliron de la operaciumo netuŝita, kio produktas alian adreson en la retumilo ol en terminalo sur la sama maŝino.

Remezuru per freŝa peto

Rekonektiĝu, poste ripetu la mezuradon el la sama aplikaĵo, kiun vi testis la unuan fojon, ĉar kaŝmemorita paĝo aŭ reuzita konekto raportas la malnovan staton. Observu la protokolon aŭ eventan vidon de la kliento dum la konekto: eraro aplikante vojojn post aŭtentigo estas pli forta pruvo ol iu ajn indikilo, kaj ĝi kutime nomas la vojon aŭ la adaptilon, kiu malsukcesis.

Tenu du rezultojn aparte. Se la adreso ŝanĝiĝas sed unu retejo ankoraŭ rifuzas vin, la tunelo funkcias kaj la retejo rifuzas datumcentran adreson; tio estas alia problemo kun alia respondo. Se la adreso neniam ŝanĝiĝas, trairu la kvar demandojn laŭorde: kiun adreson la testo presis, kiu familio ĝi estis, kiu aplikaĵo faris la peton, kaj kiun vojon tiu peto sekvis. La dokumentaro de Microsoft pri VPN-enkursigaj decidoj klarigas, kiel Windows-kliento elektas inter la tunelo kaj la fizika adaptilo, kiam ambaŭ havas vojon.