Roheline ikoon, sama avalik IP: millise marsruudi VPN vahele jättis

Ühendatud, roheline ikoon salves ja leht, mis kuvab sinu aadressi, näitab endiselt teenusepakkuja aadressi, kuid see ei tähenda automaatselt riket. Klient teeb kahte eraldi tööd: ehitab tunneli ja muudab marsruutimistabelit. Kumbki võib juhtuda ilma teiseta, ja valiv marsruutimine on see seadistus, kus teine jäetakse teadlikult vahele.

Mida klient tegelikult paigaldas

Küsi, milline liides viiks paketi päris sihtkohta, selle asemel et küsida, kas tunnel on üleval. Tunnel, millel pole selle sihtkoha jaoks marsruuti, on eratee, mida keegi ei kasuta.

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

Esimene käsk vastab Linuxis ja macOS-is ning ülejäänud kaks on Windowsi vaste, kus ühest piisab. Kui vastus nimetab füüsilist adapterit, on tunnel üleval ja vaikimisi marsruut ei liikunud kunagi. Korda päringut sihtkoha jaoks, mis peaks tunnelit kasutama, sest kaks päringut, üks kauge ja üks tavaline, ütlevad, milline lahendus on juurutatud.

Valiva marsruutimise kolm kuju

Täistunneli profiil kirjutab tavaliselt liidesele osutava vaikimisi marsruudi või kirjutab poole ulatuse prefiksite paari, mis võidab prefiksi pikkuse järgi, samal ajal kui algne vaikimisi marsruut jääb tabelisse. Valiv marsruutimine on teine valik ja seda esineb mitmel kujul. Üks profiil marsruudib ühte hosti, näiteks RDP-serverit, teine marsruudib avalikku vahemikku, kuhu tuleb jõuda kindlast kohast, ja kolmas jätab ühe rakenduse teadlikult välja. Kõik kolm on legitiimsed ja ükski ei muuda aadressi, mida tavaline veebileht näeb.

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

Loe profiilist otsustav direktiiv ja seejärel tabelist, mida see tootis. Lükataud direktiivi saab ka kliendis maha suruda, seetõttu peavad profiil ja tabel ühtima, enne kui serverit süüdistad.

Teine pool peab lähteaadressi ümber kirjutama

On teine rike, mis näeb brauserist identne välja. Marsruut osutab tunnelisse, server saab paketid kätte ja edastab need siis kliendi privaatse aadressiga muutmata kujul. Järgmisel hüppel pole selle aadressi jaoks tagasiteed, seega vastused kaovad ja lehed jäävad rippuma. Server peab üldse edastama ja peab tõlkima allika millekski, mida internet saab tagasi marsruutida.

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

Nimeta liides, mis tegelikult internetti vaatab, mis kaasaegses distributsioonis pole alati eth0. Kindla aadressiga majutatud server saab masquerade'i asemel tõlkida otse sellele aadressile. Mõlemad pooled loevad, sest edastamine ilma tõlkimiseta lekitab marsruutimatuid allikaid, samas kui tõlkimine ilma edastamiseta ei näe paketti kunagi.

Nimede lahendamine käib oma teed

Liiklus võib väljuda tunneli kaudu, samal ajal kui päring, mis nime leidis, läks kohaliku võrgu resolverisse. Nähtav aadress jääb samaks, päringud mitte, ja just selle vahe valib jagatud DNS-i lahendus.

resolvectl status | head -20
resolvectl query example.org

Pane tähele, milline server vastas ja kas see erineb enne tunnelit mõõdetud baasist. Jagatud tunneli puhul on see tavaliselt seade, mida inimesed tahtsid muuta, kui nad aadressi üle kurtisid, ja just see, mille peale nad kunagi ei vaadanud.

Neli tähelepanekut, mis asja otsustavad

Fikseeri väljumisaadress tunneliga väljas ja seejärel sees. Käivita sihtkoha päring mõlemas olekus ja märgi iga kord liides.

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

Kui päring maandub tunnelis ja kaja näitab endiselt teenusepakkuja aadressi, puudub väljumisel tõlkimine. Kui päring maandub füüsilisel adapteril, on profiil valiv ja avalik aadress polnud kunagi mängus. Asenda kaja teenus sellisega, mida usaldad, ja kirjuta neli tähelepanekut koos üles, sest eraldi on need anekdoodid. Koos näitavad need, kumba kahest tööst klient tegelikult tegi.