Zelená ikona, stejná veřejná IP: kterou trasu VPN přeskočila

Ikona v oznamovací oblasti hlásí tunel, ne výchozí trasu. Čtyři dotazy ukážou, zda klient trasu nainstaloval, nebo výstup nikdy nepřeložil váš zdroj.

Připojeno, zelená ikona v oznamovací oblasti a stránka s ozvěnou adresy stále hlásí adresu poskytovatele, to ale automaticky neznamená poruchu. Klient dělá dvě oddělené práce: staví tunel a upravuje směrovací tabulku. Každá může nastat bez druhé, a selektivní směrování je konfigurace, kde se druhá záměrně přeskakuje.

Co klient skutečně nainstaloval

Ptejte se, které rozhraní by neslo paket ke skutečnému cíli, místo abyste se ptali, zda je tunel nahoře. Tunel bez trasy k tomuto cíli je soukromá cesta, po které nikdo nejezdí.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

První příkaz odpovídá na Linuxu a macOS, zbylé dva jsou ekvivalenty pro Windows, kde stačí jeden. Pokud odpověď jmenuje fyzický adaptér, tunel je nahoře a výchozí trasa se nikdy nepohnula. Dotaz zopakujte pro cíl, který má tunel používat, protože dva dotazy, jeden vzdálený a jeden běžný, řeknou, který návrh je nasazen.

Tři podoby selektivního směrování

Profil plného tunelu obvykle zapíše výchozí trasu ukazující na rozhraní, nebo zapíše dvojici polovičních prefixů, které vyhrají délkou prefixu, zatímco původní výchozí trasa zůstane v tabulce. Selektivní směrování je druhá volba a má několik podob. Jeden profil směruje jediný host, třeba server RDP, jiný směruje veřejný rozsah, k němuž je třeba se dostat z určitého místa, a třetí záměrně vylučuje jednu aplikaci. Všechny tři jsou legitimní a žádný nemění adresu, kterou vidí běžný web.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Přečtěte profil kvůli direktivě, která rozhoduje, a pak tabulku kvůli tomu, co vyprodukovala. Vtlačenou direktivu lze na klientovi také potlačit, proto se profil a tabulka musí shodovat, než obviníte server.

Druhá strana musí přepsat zdrojovou adresu

Existuje druhá porucha, která z prohlížeče vypadá stejně. Trasa vede do tunelu, server pakety přijme a pak je předá dál s neporušenou soukromou adresou klienta. Další skok nemá pro tuto adresu zpáteční cestu, takže odpovědi mizí a stránky visí. Server musí vůbec předávat a musí přeložit zdroj na něco, co internet umí směrovat zpět.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Pojmenujte rozhraní, které skutečně míří do internetu, což v moderní distribuci nebývá vždy eth0. Hostovaný server s pevnou adresou může překládat přímo na tuto adresu místo masquerade. Obě poloviny jsou důležité, protože předávání bez překladu uniká nesměrovatelné zdroje, zatímco překlad bez předávání paket nikdy nevidí.

Překlad jmen jde vlastní cestou

Provoz může vycházet tunelem, zatímco dotaz, který jméno našel, šel k resolveru v místní síti. Viditelná adresa zůstává stejná, dotazy ne, a právě tuto mezeru návrh rozděleného DNS volí.

resolvectl status | head -20
resolvectl query example.org

Všimněte si, který server odpověděl a zda se liší od výchozího stavu před tunelem. U rozděleného tunelu to bývá nastavení, které lidé chtěli změnit, když si stěžovali na adresu, a právě to, na které se nikdy nepodívali.

Čtyři pozorování, která to rozhodnou

Zachyťte výstupní adresu s tunelem dole a pak s tunelem nahoře. Proveďte dotaz na cíl v obou stavech a pokaždé si všimněte rozhraní.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Když dotaz skončí uvnitř tunelu a ozvěna stále hlásí adresu poskytovatele, překlad na výstupu chybí. Když dotaz skončí na fyzickém adaptéru, profil je selektivní a veřejná adresa nikdy nebyla v rozsahu. Nahraďte službu ozvěny takovou, které věříte, a zapište čtyři pozorování společně, protože odděleně jsou to anekdoty. Společně určí, kterou ze dvou prací klient skutečně provedl.

Související články