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

Povezano, ikona u traci je zelena, a stranica koja prikazuje adresu i dalje pokazuje adresu pružatelja — to još ne znači kvar. Klijent obavlja dva odvojena posla: gradi tunel i uređuje tablicu usmjeravanja. Bilo koji može postojati bez drugoga, a selektivno usmjeravanje je konfiguracija u kojoj se drugi namjerno preskače.

Što je klijent zapravo ugradio

Pitajte koje bi sučelje odnijelo paket do stvarnog odredišta, umjesto da pitate je li tunel podignut. Tunel bez rute za to odredište je privatna cesta kojom 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 ekvivalenti za Windows, gdje je jedna dovoljna. Ako odgovor imenuje fizički adapter, tunel je podignut i zadana ruta se nikada nije pomaknula. Ponovite provjeru za odredište koje bi trebalo ići kroz tunel, jer dvije provjere, jedna udaljena i jedna obična, pokazuju koje je rješenje primijenjeno.

Tri oblika selektivnog usmjeravanja

Profil punog tunela obično upisuje zadanu rutu prema sučelju ili upisuje par prefiksa polovičnog raspona 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 jedno računalo, poput RDP poslužitelja, drugi usmjerava javni raspon do kojeg se mora doći s određenog mjesta, a treći namjerno 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, zatim pročitajte tablicu zbog onoga što je proizvela. Gurnuta direktiva može se potisnuti i na klijentu, zato se profil i tablica moraju slagati prije nego okrivite poslužitelj.

Suprotna strana mora prepisati izvornu adresu

Postoji drugi kvar koji iz preglednika izgleda jednako. Ruta vodi u tunel, poslužitelj prima pakete i zatim ih prosljeđuje s netaknutom privatnom adresom klijenta. Sljedeći skok nema povratni put za tu adresu, pa odgovori nestaju i stranice se smrzavaju. Poslužitelj mora uopće 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 stvarno gleda u internet, a to na suvremenoj distribuciji nije uvijek eth0. Hostani poslužitelj s fiksnom adresom može izričito prevesti na tu adresu umjesto da koristi masquerade. Obje polovice su važne, jer prosljeđivanje bez prijevoda curi neusmjerive izvore, dok prijevod bez prosljeđivanja nikada ne vidi paket.

Razrješavanje imena ide svojim putem

Promet može izlaziti kroz tunel dok je upit koji je pronašao ime otišao na razrješivač u lokalnoj mreži. Vidljiva adresa ostaje ista, upiti ne, a ta praznina je upravo ono što odabire dizajn podijeljenog DNS-a.

resolvectl status | head -20
resolvectl query example.org

Zabilježite koji je poslužitelj odgovorio i razlikuje li se od početnog stanja prije tunela. Na podijeljenom tunelu to je obično postavka koju su ljudi htjeli promijeniti kada su se žalili na adresu, a ona koju nikada 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 odjek i dalje prijavljuje adresu pružatelja, prijevod na izlazu nedostaje. Kada provjera padne na fizički adapter, profil je selektivan i javna adresa nikada nije bila u opsegu. Zamijenite uslugu odjeka onom kojoj vjerujete i zabilježite četiri zapažanja zajedno, jer su odvojeno samo anegdote. Zajedno pokazuju koji je od dva posla klijent stvarno obavio.