VPN i lidhur, por adresa IP nuk ka ndryshuar: pse

Lidheni, klienti thotë i lidhur, dhe testi i adresës ende tregon të njëjtin numër që kishit më parë. Treguesi nuk ka asgjë të gabuar; diçka midis profilit dhe aplikacionit e mbajti atë kërkesë jashtë tunelit. Vendosni se cilën nga tri gjërat po shikoni përpara se të prekni çdo konfigurim: një test që nuk mati kurrë adresën publike, një tunel që mbulon vetëm një pjesë të trafikut, ose një rrugë të dytë që fiton vendimin e rrugëtimit. Secili ka një kontroll që zgjat më pak se një minutë.

Konfirmoni çfarë mati në të vërtetë testi

Adresa e treguar në dialogun Wi-Fi ose Ethernet është adresa e ndërfaqes në segmentin tuaj, jo adresa që sheh një faqe interneti, kështu që mund të mbetet e njëjtë ndërsa tuneli funksionon në mënyrë të përsosur. Vendndodhja është përsëri një sinjal i veçantë: një rajon llogarie i ruajtur ose një lexim i lejuar i gjeolokacionit nuk lëvizin kur ndryshoni daljen, dhe as një hyrje që ju njeh tashmë.

Përdorni një jehonë të adresës publike dhe pyesni çdo familje veçmas, sepse rezultati i një testi me dy shtresa fsheh rastin interesant:

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

Ekzekutoni të dyja para dhe pas lidhjes. Nëse përgjigjja IPv4 ndryshon në adresën e daljes dhe përgjigjja IPv6 jo, nuk keni një tunel të prishur; një familje po udhëton jashtë tij. Nëse të dyja përgjigjet mbeten të njëjta, kërkesa nuk arriti kurrë tunelin dhe pjesa tjetër këtu vlen.

Profili mund të mbulojë vetëm një pjesë të trafikut

Një profil me tunel të ndarë është përgjigjja e zakonshme dhe nuk është defekt. OpenVPN dërgon gjithçka përmes tunelit vetëm kur redirect-gateway është ndër opsionet e shtyra; pa të, klienti merr disa rrugë specifike dhe rruga juaj e paracaktuar mbetet në lidhjen fizike. Në Windows i njëjti çelës shfaqet si „Përdor portën e paracaktuar në rrjetin e largët” në vetitë IPv4 të përshtatësit, dhe heqja e tij është një zgjedhje e qëllimshme që mbijeton çdo rilidhje.

Shtrirja për aplikacion është shtresa e dytë. Cilësimi i VPN për aplikacion në Android vendos se cilat aplikacione përfshihen, kështu që çelësi VPN në shiritin e statusit nuk provon që shfletuesi është brenda. Një shtesë shfletuesi që proxy-on trafikun e vet krijon imazhin pasqyrë: shfletuesi tregon adresën e daljes ndërsa një klient poste ose një lojë në të njëjtën makinë tregon ende tuajën. Krahasoni të njëjtën kërkesë në dy aplikacione. Nëse njëra ndryshon dhe tjetra jo, po shikoni shtrirjen, jo një tunel që dështon.

Një familje adresash mund të shkojë ende drejtpërdrejt

Shumica e profileve VPN janë shkruar për IPv4, dhe shumë janë ende të tillë. Në një rrjet me dy shtresa tuneli merr 10.8.0.x për IPv4 ndërsa lidhja fizike mban një adresë globale IPv6 dhe një rrugë të paracaktuar, kështu që një faqe që mbështet IPv6 arrihet drejtpërdrejt dhe adresa që raporton është e ofruesit tuaj. Kjo është një rrjedhje me një tunel IPv4 që funksionon, dhe është e padukshme për një test që flet vetëm IPv4.

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

Lexoni ndërfaqen në çdo përgjigje. Nëse kërkimi IPv6 emërton pajisjen tuaj Ethernet ose Wi-Fi ndërsa kërkimi IPv4 emërton tunelin, politika për atë familje mungon, nuk është e prishur. Fikja e IPv6 në të gjithë pajisjen e bën simptomën të zhduket dhe fsheh vendimin; preferoni të rregulloni mbulimin e profilit ose të çaktivizoni familjen vetëm në atë lidhje, dhe shënoni cilën nga të dyja zgjodhët.

Një rrugë e dytë mund të fitojë kërkimin

Një proxy konkurrues, një klient i dytë VPN, një përshtatës virtual nga një konteiner ose mjet desktopi në distancë, ose një rrugë shtesë për prefiksin e saktë që testoni mund të marrin të gjithë përparësi. Një rrugë specifike gjithmonë mposht një rrugë të paracaktuar, kështu që një /24 i mbetur për faqen që matni, që tregon portën tuaj LAN, vazhdon ta dërgojë atë trafik jashtë tunelit, sado i shëndetshëm që të jetë tuneli.

Bëni një inventar përpara se të ndryshoni gjë, me komanda vetëm për lexim:

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

Kërkoni më shumë se një rrugë të paracaktuar me një metrikë të besueshme, dhe një rrugë specifike që mbulon destinacionin. Në shfletues, kontrolloni gjithashtu nëse një shtesë proxy ose cilësimi i proxy-t të sistemit zotëron lidhjen; një shtesë mund të emërtojë rrjedhën e vet të sipërme dhe ta lërë daljen e sistemit operativ të paprekur, gjë që prodhon një adresë të ndryshme në shfletues sesa në një terminal në të njëjtën makinë.

Matni përsëri me një kërkesë të freskët

Rilidhuni, pastaj përsëritni matjen nga i njëjti aplikacion me të cilin testuat herën e parë, sepse një faqe e ruajtur në cache ose një lidhje e ripërdorur raporton gjendjen e vjetër. Vëzhgoni regjistrin ose pamjen e ngjarjeve të klientit gjatë lidhjes: një gabim në zbatimin e rrugëve pas vërtetimit është provë më e fortë se çdo tregues, dhe zakonisht emërton rrugën ose përshtatësin që dështoi.

Mbani dy rezultate veçmas. Nëse adresa ndryshon por një faqe ende ju refuzon, tuneli funksionon dhe faqja refuzon një adresë qendre të dhënash; ky është një problem tjetër me një përgjigje tjetër. Nëse adresa nuk ndryshon kurrë, kaloni nëpër katër pyetjet me radhë: cilën adresë shtypi testi, cila familje ishte, cili aplikacion e bëri kërkesën dhe cilën rrugë ndoqi ajo kërkesë. Dokumentacioni i Microsoft për vendimet e rrugëtimit të VPN shpjegon se si një klient Windows zgjedh midis tunelit dhe përshtatësit fizik kur të dy kanë një rrugë.