Vihreä kuvake, sama julkinen IP: minkä reitin VPN jätti väliin

Yhdistetty, vihreä kuvake ilmoitusalueella ja sivusto, joka kaikuu osoitteesi ja näyttää yhä palveluntarjoajan osoitteen, eivät tarkoita automaattisesti vikaa. Asiakas tekee kaksi erillistä työtä: se rakentaa tunnelin ja muokkaa reititystaulukkoa. Kumpi tahansa voi tapahtua ilman toista, ja valikoiva reititys on se kokoonpano, jossa toinen jätetään tarkoituksella väliin.

Mitä asiakas oikeastaan asensi

Kysy, mikä liitäntä kuljettaisi paketin todelliseen kohteeseen, sen sijaan että kysyisit, onko tunneli pystyssä. Tunneli ilman reittiä siihen kohteeseen on yksityistie, jota kukaan ei käytä.

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

Ensimmäinen komento vastaa Linuxissa ja macOS:ssä, ja kaksi muuta ovat Windowsin vastineet, joissa yksi riittää. Jos vastaus nimeää fyysisen sovittimen, tunneli on pystyssä eikä oletusreitti koskaan liikkunut. Toista kysely kohteelle, jonka pitäisi käyttää tunnelia, koska kaksi kyselyä, yksi etäinen ja yksi tavallinen, kertovat, mikä rakenne on käytössä.

Valikoivan reitityksen kolme muotoa

Koko tunnelin profiili kirjoittaa yleensä oletusreitin liitäntään tai kirjoittaa puolikkaan kantaman etuliiteparin, joka voittaa etuliitteen pituudella, kun taas alkuperäinen oletus jää taulukkoon. Valikoiva reititys on toinen valinta, ja sitä on useita muotoja. Yksi profiili reitittää yhden isännän kuten RDP-palvelimen, toinen reitittää julkisen alueen, johon on päästävä tietystä paikasta, ja kolmas jättää yhden sovelluksen tarkoituksella pois. Kaikki kolme ovat laillisia, eikä mikään niistä muuta osoitetta, jonka tavallinen verkkosivusto näkee.

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

Lue profiilista ratkaiseva direktiivi ja sitten taulukosta, mitä se tuotti. Työnnetyn direktiivin voi myös vaimentaa asiakkaassa, siksi profiilin ja taulukon on oltava yhtä mieltä ennen kuin syytät palvelinta.

Vastapuolen on kirjoitettava lähdeosoite uudelleen

On toinen vika, joka näyttää selaimesta identtiseltä. Reitti osoittaa tunneliin, palvelin vastaanottaa paketit ja välittää ne sitten eteenpäin asiakkaan yksityinen osoite muuttumattomana. Seuraavalla hypyllä ei ole paluureittiä sille osoitteelle, joten vastaukset katoavat ja sivut jumittuvat. Palvelimen on ylipäänsä välitettävä, ja sen on käännettävä lähde joksikin, jonka internet voi reitittää takaisin.

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

Nimeä liitäntä, joka todella osoittaa internettiin, mikä nykyaikaisessa jakelussa ei aina ole eth0. Kiinteän osoitteen palvelin voi kääntää nimenomaan siihen osoitteeseen masqueraden sijaan. Molemmat puolet merkitsevät, koska välitys ilman käännöstä vuotaa reitittämättömiä lähteitä, kun taas käännös ilman välitystä ei näe pakettia koskaan.

Nimien selvitys kulkee omaa tietään

Liikenne voi poistua tunnelin kautta, kun nimen löytänyt kysely meni paikallisverkon selvittimelle. Näkyvä osoite pysyy samana, kyselyt eivät, ja juuri tuon eron jakautunut DNS-suunnittelu valitsee.

resolvectl status | head -20
resolvectl query example.org

Huomaa, mikä palvelin vastasi ja eroaako se tunnelia edeltävästä lähtötasosta. Jaetussa tunnelissa se on yleensä se asetus, jota ihmiset halusivat muuttaa valittaessaan osoitteesta, ja juuri se, jota he eivät koskaan katsoneet.

Neljä havaintoa, jotka ratkaisevat asian

Tallenna lähtöosoite tunnelin ollessa alhaalla ja sitten ylhäällä. Aja kohdekysely molemmissa tiloissa ja kirjaa liitäntä joka kerta.

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

Kun kysely osuu tunnelin sisään ja kaiku näyttää yhä palveluntarjoajan osoitteen, käännös puuttuu ulostulosta. Kun kysely osuu fyysiseen sovittimeen, profiili on valikoiva eikä julkinen osoite ollut koskaan mukana. Korvaa kaikupalvelu sellaisella, johon luotat, ja kirjaa neljä havaintoa yhteen, koska erikseen ne ovat anekdootteja. Yhdessä ne kertovat, kumman kahdesta työstä asiakas todella teki.