Zelena ikona, isti javni IP: katero pot je VPN izpustil

Povezano, zelena ikona v pladnju in stran, ki prikazuje naslov, še vedno kaže naslov ponudnika — to še ne pomeni okvare. Odjemalec opravi dve ločeni deli: zgradi tunel in uredi usmerjevalno tabelo. Vsako lahko obstaja brez drugega, selektivno usmerjanje pa je konfiguracija, kjer je drugo namerno izpuščeno.

Kaj je odjemalec dejansko namestil

Vprašajte, kateri vmesnik bi nesel paket do resničnega cilja, namesto da sprašujete, ali je tunel aktiven. Tunel brez poti do tega cilja je zasebna cesta, po kateri nihče ne hodi.

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

Prvi ukaz odgovori v Linuxu in macOS, druga dva pa sta enakovredna za Windows, kjer zadostuje eden. Če odgovor navede fizični vmesnik, je tunel aktiven in privzeta pot se nikoli ni premaknila. Preverjanje ponovite za cilj, ki bi moral iti skozi tunel, ker dve preverjanji, eno oddaljeno in eno običajno, povesta, katera zasnova je nameščena.

Tri oblike selektivnega usmerjanja

Profil celotnega tunela običajno zapiše privzeto pot na vmesnik ali zapiše par predpon polovičnega obsega, ki zmagajo po dolžini predpone, medtem ko prvotna privzeta pot ostane v tabeli. Selektivno usmerjanje je druga izbira in prihaja v več oblikah. En profil usmerja enega gostitelja, na primer strežnik RDP, drugi usmerja javni obseg, do katerega je treba priti z določenega mesta, tretji pa namerno izloči eno aplikacijo. Vse tri so legitimne in nobena ne spremeni naslova, ki ga vidi običajno spletno mesto.

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

Preberite profil zaradi direktive, ki odloči, nato preberite tabelo zaradi tega, kar je ustvarila. Potisnjeno direktivo je mogoče zadušiti tudi na odjemalcu, zato se morata profil in tabela ujemati, preden krivite strežnik.

Oddaljena stran mora prepisati izvorni naslov

Obstaja druga okvara, ki je iz brskalnika videti enako. Pot vodi v tunel, strežnik prejme pakete in jih nato posreduje z nedotaknjenim zasebnim naslovom odjemalca. Naslednji skok nima povratne poti za ta naslov, zato odgovori izginejo in strani obvisijo. Strežnik mora sploh posredovati in mora prevesti izvor v nekaj, kar lahko internet usmeri nazaj.

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

Poimenujte vmesnik, ki res gleda v internet, in to v sodobni distribuciji ni vedno eth0. Gostujoči strežnik s fiksnim naslovom lahko izrecno prevede na ta naslov, namesto da uporabi masquerade. Obe polovici sta pomembni, saj posredovanje brez prevajanja pušča neusmerljive izvore, prevajanje brez posredovanja pa paketa nikoli ne vidi.

Razreševanje imen gre po svoji poti

Promet lahko izhaja skozi tunel, medtem ko je poizvedba, ki je našla ime, šla do razreševalnika v lokalnem omrežju. Vidni naslov ostane enak, poizvedbe ne, in prav to vrzel izbere zasnova razdeljenega DNS.

resolvectl status | head -20
resolvectl query example.org

Zabeležite, kateri strežnik je odgovoril in ali se razlikuje od izhodišča pred tunelom. V razdeljenem tunelu je to običajno nastavitev, ki so jo ljudje želeli spremeniti, ko so se pritoževali zaradi naslova, in prav tista, ki si je nikoli niso ogledali.

Štiri opažanja, ki razrešijo zadevo

Zapišite izhodni naslov z izklopljenim tunelom, nato z vklopljenim. Zaženite preverjanje cilja v obeh stanjih in vsakič zabeležite vmesnik.

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

Ko preverjanje pristane znotraj tunela in odmev še vedno poroča naslov ponudnika, prevajanja na izhodu ni. Ko preverjanje pristane na fizičnem vmesniku, je profil selektiven in javni naslov nikoli ni bil v obsegu. Zamenjajte odmevno storitev s tisto, ki ji zaupate, in zapišite štiri opažanja skupaj, ker so ločeno le anekdote. Skupaj pokažejo, katero od dveh del je odjemalec dejansko opravil.