Zelena ikona, ista javna IP: koju je rutu VPN preskočio

Povezano, zelena ikona u traci i stranica koja odražava adresu, a i dalje prikazuje adresu provajdera, ne znače automatski kvar. Klijent obavlja dva odvojena posla: gradi tunel i mijenja tabelu rutiranja. Bilo koje može nastupiti bez onog drugog, a selektivno rutiranje je konfiguracija u kojoj se drugo svjesno preskače.

Šta je klijent zapravo ugradio

Pitajte koji bi interfejs nosio paket do stvarnog odredišta, umjesto da pitate je li tunel podignut. Tunel bez rute do tog odredišta je privatni put kojim niko ne ide.

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

Prva komanda odgovara na Linuxu i macOS-u, a druge dvije su Windows ekvivalenti gdje je jedna dovoljna. Ako odgovor navede fizički adapter, tunel je podignut i zadana ruta se nikad nije pomjerila. Ponovite provjeru za odredište koje bi trebalo koristiti tunel, jer dvije provjere, jedna udaljena i jedna obična, kažu koji je dizajn primijenjen.

Tri oblika selektivnog rutiranja

Profil punog tunela obično upisuje zadanu rutu prema interfejsu ili upisuje par poluopsežnih prefiksa koji pobeđuju po dužini prefiksa dok originalna zadana ruta ostaje u tabeli. Selektivno rutiranje je drugi izbor i dolazi u nekoliko oblika. Jedan profil rutira jedan host kao što je RDP server, drugi rutira javni opseg do kojeg se mora stići s određenog mjesta, a treći svjesno isključuje jednu aplikaciju. Sva tri su legitimna i nijedan ne mijenja adresu koju vidi obična web stranica.

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

Pročitajte profil zbog direktive koja odlučuje, a zatim tabelu zbog onoga što je proizvela. Potisnuta direktiva može se i ugušiti na klijentu, zato se profil i tabela moraju slagati prije nego okrivite server.

Druga strana mora prepisati adresu izvora

Postoji drugi kvar koji iz preglednika izgleda identično. Ruta vodi u tunel, server prima pakete, a zatim ih prosljeđuje s netaknutom privatnom adresom klijenta. Sljedeći hop nema povratni put za tu adresu, pa odgovori nestaju i stranice vise. Server uopšte mora prosljeđivati i mora prevesti izvor u nešto što internet može usmjeriti natrag.

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

Imenujte interfejs koji zaista gleda u internet, a to nije uvijek eth0 na modernoj distribuciji. Hostovani server s fiksnom adresom može eksplicitno prevesti na tu adresu umjesto masquerade. Obje polovine su važne, jer prosljeđivanje bez prevođenja curi adrese koje se ne mogu rutirati, a prevođenje bez prosljeđivanja nikad ne vidi paket.

Razrješavanje imena ide svojim putem

Saobraćaj može izaći kroz tunel dok je provjera koja je našla ime otišla do razrješivača na lokalnoj mreži. Vidljiva adresa ostaje ista, provjere ne, a ta praznina je upravo ono što dizajn podijeljenog DNS-a bira.

resolvectl status | head -20
resolvectl query example.org

Zabilježite koji je server odgovorio i razlikuje li se od osnovice prije tunela. Na podijeljenom tunelu to je obično postavka koju su ljudi htjeli promijeniti kada su se žalili na adresu, i upravo ona u koju nikad nisu pogledali.

Četiri zapažanja koja rješavaju stvar

Zabilježite izlaznu adresu s isključenim tunelom, pa s uključenim. Pokrenite provjeru odredišta u oba stanja i svaki put zabilježite interfejs.

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

Kada provjera padne unutar tunela, a odraz i dalje prikazuje adresu provajdera, prevođenje na izlazu nedostaje. Kada provjera padne na fizički adapter, profil je selektivan i javna adresa nikad nije bila u opsegu. Zamijenite uslugu odraza onom kojoj vjerujete i zapišite četiri zapažanja zajedno, jer su odvojeno anegdote. Zajedno pokazuju koji je od dva posla klijent zapravo obavio.