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

Ikona u traci prijavljuje tunel, a ne zadanu rutu. Četiri provjere pokazuju je li klijent ugradio rutu ili izlaz nikad nije preveo vaš izvor.

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

Što je klijent zapravo ugradio

Pitajte koje bi sučelje nosilo paket do stvarnog odredišta, umjesto da pitate je li tunel podignut. Tunel bez rute do tog odredišta je privatni put kojim nitko ne ide.

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

Prva naredba 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 pomaknula. 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 usmjeravanja

Profil punog tunela obično upisuje zadanu rutu prema sučelju ili upisuje par poludosežnih prefiksa koji pobjeđuju po duljini prefiksa dok izvorna zadana ruta ostaje u tablici. Selektivno usmjeravanje je drugi izbor i dolazi u nekoliko oblika. Jedan profil usmjerava jedan host poput RDP poslužitelja, drugi usmjerava javni raspon 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čno web mjesto.

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 tablicu zbog onoga što je proizvela. Potisnuta direktiva može se i ugušiti na klijentu, zato se profil i tablica moraju slagati prije nego okrivite poslužitelj.

Druga strana mora prepisati adresu izvora

Postoji drugi kvar koji iz preglednika izgleda identično. Ruta vodi u tunel, poslužitelj 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. Poslužitelj uopće 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 sučelje koje zaista gleda u internet, a to nije uvijek eth0 na modernoj distribuciji. Hostani poslužitelj s fiksnom adresom može eksplicitno prevesti na tu adresu umjesto masquerade. Obje polovice su važne, jer prosljeđivanje bez prevođenja curi adrese koje se ne mogu rutati, a prevođenje bez prosljeđivanja nikad ne vidi paket.

Razrješavanje imena ide svojim putem

Promet 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 poslužitelj 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 sučelje.

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

Kada provjera padne unutar tunela, a odraz i dalje prikazuje adresu davatelja, 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.

Povezani članci