VPN conectat, dar adresa IP nu s-a schimbat: de ce

Vă conectați, clientul spune conectat, iar testul de adresă arată în continuare același număr ca înainte. Indicatorul nu are nimic greșit; ceva între profil și aplicație a ținut acea cerere în afara tunelului. Decideți la care dintre trei lucruri vă uitați înainte de a atinge orice configurație: un test care nu a măsurat niciodată adresa publică, un tunel care acoperă doar o parte a traficului sau o a doua cale care câștigă decizia de rutare. Fiecare are o verificare care durează mai puțin de un minut.

Confirmați ce a măsurat de fapt testul

Adresa afișată în dialogul Wi-Fi sau Ethernet este adresa interfeței din propriul segment, nu adresa pe care o vede un site, așa că poate rămâne identică în timp ce tunelul funcționează perfect. Locația este din nou un semnal separat: o regiune de cont salvată sau o citire de geolocalizare permisă nu se mișcă atunci când schimbați ieșirea, și nici o autentificare care vă recunoaște deja.

Folosiți un ecou al adresei publice și întrebați fiecare familie separat, pentru că rezultatul unui test cu stivă dublă ascunde cazul interesant:

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

Rulați ambele înainte și după conectare. Dacă răspunsul IPv4 se schimbă în adresa de ieșire, iar răspunsul IPv6 nu, nu aveți un tunel defect; o familie călătorește în afara lui. Dacă ambele răspunsuri rămân la fel, cererea nu a ajuns niciodată la tunel și restul de aici se aplică.

Profilul poate acoperi doar o parte a traficului

Un profil cu tunel divizat este răspunsul obișnuit și nu este un defect. OpenVPN trimite totul prin tunel doar când redirect-gateway se află printre opțiunile trimise; fără el, clientul primește câteva rute specifice, iar ruta implicită rămâne pe legătura fizică. În Windows același comutator apare ca „Folosește gateway-ul implicit în rețeaua la distanță” în proprietățile IPv4 ale adaptorului, iar debifarea lui este o alegere deliberată care supraviețuiește fiecărei reconectări.

Sfera pe aplicație este al doilea strat. Setarea VPN pe aplicație din Android decide ce aplicații sunt incluse, așa că cheia VPN din bara de stare nu dovedește că browserul este înăuntru. O extensie de browser care își proxează propriul trafic creează imaginea în oglindă: browserul arată adresa de ieșire, în timp ce un client de e-mail sau un joc de pe aceeași mașină arată încă adresa dumneavoastră. Comparați aceeași cerere în două aplicații. Dacă una se schimbă și cealaltă nu, vă uitați la sferă, nu la un tunel care eșuează.

O familie de adrese poate merge în continuare direct

Majoritatea profilurilor VPN au fost scrise pentru IPv4, și multe încă sunt. Într-o rețea cu stivă dublă tunelul ia 10.8.0.x pentru IPv4, în timp ce legătura fizică păstrează o adresă IPv6 globală și o rută implicită, așa că un site compatibil IPv6 este atins direct, iar adresa pe care o raportează este a furnizorului dumneavoastră. Aceasta este o scurgere cu un tunel IPv4 funcțional și este invizibilă pentru un test care vorbește doar IPv4.

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

Citiți interfața în fiecare răspuns. Dacă căutarea IPv6 numește dispozitivul Ethernet sau Wi-Fi, iar căutarea IPv4 numește tunelul, politica pentru acea familie lipsește, nu este stricată. Oprirea IPv6 pe tot dispozitivul face simptomul să dispară și ascunde decizia; preferați să reparați acoperirea profilului sau să dezactivați familia doar pe acea conexiune și notați pe care dintre cele două ați ales-o.

O a doua cale poate câștiga căutarea

Un proxy concurent, un al doilea client VPN, un adaptor virtual dintr-un container sau dintr-un instrument de desktop la distanță, sau o rută suplimentară pentru prefixul exact pe care îl testați pot avea toate prioritate. O rută specifică bate întotdeauna o rută implicită, așa că un /24 rămas pentru site-ul pe care îl măsurați, care indică gateway-ul LAN, continuă să trimită acel trafic în afara tunelului oricât de sănătos ar fi tunelul.

Faceți un inventar înainte de a schimba ceva, cu comenzi doar pentru citire:

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

Căutați mai mult de o rută implicită cu o metrică plauzibilă și o rută specifică ce acoperă destinația. În browser, verificați și dacă o extensie proxy sau setarea proxy a sistemului deține conexiunea; o extensie poate numi propriul upstream și poate lăsa ieșirea sistemului de operare neatinsă, ceea ce produce o adresă diferită în browser față de un terminal de pe aceeași mașină.

Măsurați din nou cu o cerere proaspătă

Reconectați-vă, apoi repetați măsurătoarea din aceeași aplicație cu care ați testat prima dată, pentru că o pagină din cache sau o conexiune refolosită raportează starea veche. Urmăriți jurnalul sau vizualizarea evenimentelor clientului în timpul conectării: o eroare la aplicarea rutelor după autentificare este o dovadă mai puternică decât orice indicator și de obicei numește ruta sau adaptorul care a eșuat.

Țineți două rezultate separate. Dacă adresa se schimbă, dar un site încă vă refuză, tunelul funcționează și site-ul respinge o adresă de centru de date; aceasta este o altă problemă cu un alt răspuns. Dacă adresa nu se schimbă niciodată, parcurgeți cele patru întrebări în ordine: ce adresă a tipărit testul, care familie era, ce aplicație a făcut cererea și ce rută a urmat acea cerere. Documentația Microsoft despre deciziile de rutare VPN explică modul în care un client Windows alege între tunel și adaptorul fizic atunci când ambele au o rută.