Zelená ikona, rovnaká verejná IP: ktorú trasu VPN vynechal

Pripojené, zelená ikona v lište a stránka, ktorá zobrazuje adresu, stále hlási adresu poskytovateľa — to ešte automaticky neznamená poruchu. Klient robí dve oddelené veci: zostavuje tunel a upravuje smerovaciu tabuľku. Ktorákoľvek môže existovať bez tej druhej a selektívne smerovanie je konfigurácia, v ktorej sa druhá zámerne vynecháva.

Čo klient skutočne nainštaloval

Pýtajte sa, ktoré rozhranie prenesie paket k skutočnému cieľu, namiesto otázky, či je tunel aktívny. Tunel bez trasy k tomuto cieľu je súkromná cesta, po ktorej nikto nechodí.

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

Prvý príkaz odpovie na Linuxe a macOS, ďalšie dva sú ekvivalenty pre Windows, kde stačí jeden. Ak odpoveď pomenuje fyzický adaptér, tunel je aktívny a predvolená trasa sa nikdy nepohla. Zopakujte kontrolu pre cieľ, ktorý by mal ísť cez tunel, pretože dve kontroly, jedna vzdialená a jedna bežná, povedia, ktorý návrh je nasadený.

Tri podoby selektívneho smerovania

Profil plného tunela zvyčajne zapíše predvolenú trasu na rozhranie alebo zapíše dvojicu prefixov polovičného rozsahu, ktoré vyhrávajú na dĺžke prefixu, kým pôvodná predvolená trasa zostáva v tabuľke. Selektívne smerovanie je druhá voľba a prichádza v niekoľkých podobách. Jeden profil smeruje jedného hostiteľa, napríklad server RDP, iný smeruje verejný rozsah, ku ktorému sa treba dostať z konkrétneho miesta, a tretí zámerne vylučuje jednu aplikáciu. Všetky tri sú legitímne a žiadny nemení adresu, ktorú vidí bežná webová stránka.

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

Prečítajte profil kvôli direktíve, ktorá rozhoduje, potom prečítajte tabuľku kvôli tomu, čo vytvorila. Vtlačená direktíva sa dá potlačiť aj na klientovi, preto sa profil a tabuľka musia zhodovať, kým obviníte server.

Vzdialená strana musí prepísať zdrojovú adresu

Existuje druhá porucha, ktorá z prehliadača vyzerá rovnako. Trasa vedie do tunela, server prijme pakety a potom ich prepošle s nedotknutou súkromnou adresou klienta. Ďalší skok nemá spätnú cestu pre túto adresu, takže odpovede miznú a stránky visia. Server musí vôbec preposielať a musí preložiť zdroj na niečo, čo internet dokáže smerovať späť.

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

Pomenujte rozhranie, ktoré skutočne smeruje do internetu, a to v modernej distribúcii nie je vždy eth0. Hostovaný server s pevnou adresou môže prekladať priamo na túto adresu namiesto masquerade. Obe polovice sú dôležité, pretože preposielanie bez prekladu uniká nesmerovateľné zdroje, kým preklad bez preposielania paket nikdy nevidí.

Preklad mien ide vlastnou cestou

Premávka môže vychádzať cez tunel, kým dopyt, ktorý našiel meno, išiel na resolver v lokálnej sieti. Viditeľná adresa zostáva rovnaká, dopyty nie, a presne túto medzeru si vyberá návrh rozdeleného DNS.

resolvectl status | head -20
resolvectl query example.org

Všimnite si, ktorý server odpovedal a či sa líši od základného stavu pred tunelom. V rozdelenom tuneli je to zvyčajne nastavenie, ktoré ľudia chceli zmeniť, keď sa sťažovali na adresu, a práve to, na čo sa nikdy nepozreli.

Štyri pozorovania, ktoré to vyriešia

Zaznamenajte výstupnú adresu s vypnutým tunelom, potom so zapnutým. Spustite kontrolu cieľa v oboch stavoch a zakaždým si poznačte rozhranie.

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

Keď kontrola pristane v tuneli a ozvena stále hlási adresu poskytovateľa, preklad na výstupe chýba. Keď kontrola pristane na fyzickom adaptéri, profil je selektívny a verejná adresa nikdy nebola v rozsahu. Nahraďte službu ozveny takou, ktorej dôverujete, a zaznamenajte štyri pozorovania spolu, pretože oddelene sú len anekdoty. Spolu ukazujú, ktorú z dvoch úloh klient skutočne vykonal.