Grønt ikon, same offentlege IP: kva rute VPN-en hoppa over

Tilkopla, grønt ikon i systemkurven og ei side som speglar adressa di og framleis viser adressa til leverandøren betyr ikkje automatisk feil. Ein klient gjer to atskilde jobbar: han byggjer ein tunnel, og han endrar rutetabellen. Kvar av dei kan skje utan den andre, og selektiv ruting er konfigurasjonen der den andre vert hoppa over med vilje.

Kva klienten faktisk installerte

Spør kva grensesnitt som ville bera ein pakke til ein ekte destinasjon i staden for å spørje om tunnelen er oppe. Ein tunnel utan rute til den destinasjonen er ein privat veg ingen brukar.

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

Den fyrste kommandoen svarar på Linux og macOS, og dei to andre er Windows-ekvivalentane der ein er nok. Viss svaret nemner den fysiske adapteren, er tunnelen oppe og standardruta flytta seg aldri. Gjenta oppslaget for ein destinasjon som burde bruke tunnelen, fordi to oppslag, eitt fjernt og eitt vanleg, fortel kva design som er teke i bruk.

Tre former for selektiv ruting

Ein fulltunnelprofil skriv vanlegvis ei standardrute mot grensesnittet, eller skriv paret med halvområdeprefiks som vinn på prefikslengd medan den opphavlege standardruta blir i tabellen. Selektiv ruting er det andre valet, og det kjem i fleire former. Éin profil rutar ein enkelt vert som ein RDP-tenar, ein annan rutar eit offentleg område som må nåast frå ein bestemd stad, og ein tredje utelukkar med vilje éin applikasjon. Alle tre er legitime, og ingen av dei endrar adressa ei vanleg nettside ser.

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

Les profilen for direktivet som avgjer, og deretter tabellen for det det produserte. Eit direktiv som vert skyvd ut kan òg undertrykkjast på klienten, difor må profilen og tabellen stemme før du klandrar tenaren.

Den andre sida må skrive om kjeldadressa

Det finst ein annan feil som ser identisk ut frå nettlesaren. Ruta peikar inn i tunnelen, tenaren tek imot pakkane og sender dei deretter vidare med den private adressa til klienten intakt. Neste hopp har ingen returveg for den adressa, så svar forsvinn og sider heng. Tenaren må senda vidare i det heile, og han må omsetje kjelda til noko internett kan rute tilbake.

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

Namngje grensesnittet som faktisk vender mot internett, noko som ikkje alltid er eth0 på ein moderne distribusjon. Ein hosta tenar med fast adresse kan omsetje eksplisitt til den adressa i staden for å bruke masquerade. Begge halvdelane tel, fordi videresending utan omsetjing lekker ikkje-rutbare kjelder, medan omsetjing utan videresending aldri ser pakken.

Namneoppslag går sin eigen veg

Trafikk kan gå ut gjennom tunnelen medan oppslaget som fann namnet gjekk til ein resolver på det lokale nettet. Den synlege adressa blir den same, oppslaga ikkje, og det gapet er nettopp det eit delt DNS-design vel.

resolvectl status | head -20
resolvectl query example.org

Legg merke til kva tenar som svara og om han skil seg frå basislina før tunnelen. På ein delt tunnel er dette vanlegvis innstillinga folk ville endre då dei klaga på adressa, og det er den dei aldri såg på.

Fire observasjonar som avgjer saka

Registrer utgangsadressa med tunnelen nede og deretter med han oppe. Køyr destinasjonsoppslaget i begge tilstandar og noter grensesnittet kvar gong.

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

Når oppslaget landar inne i tunnelen og ekkoet framleis viser adressa til leverandøren, manglar omsetjinga ved utgangen. Når oppslaget landar på den fysiske adapteren, er profilen selektiv og den offentlege adressa var aldri i spel. Bytt ut ekkotenesta med ein du stolar på og skriv ned dei fire observasjonane saman, fordi kvar for seg er dei anekdotar. Saman viser dei kva av dei to jobbane klienten faktisk utførte.