Grønt ikon, samme offentlige IP: hvilken rute VPN-en hoppet over

Tilkoblet, grønt ikon i systemkurven og en side som speiler adressen din og fortsatt viser leverandørens adresse betyr ikke automatisk feil. En klient gjør to atskilte jobber: den bygger en tunnel, og den redigerer rutetabellen. Begge kan skje uten den andre, og selektiv ruting er konfigurasjonen der den andre hoppes bevisst over.

Hva klienten faktisk installerte

Spør hvilket grensesnitt som ville bære en pakke til en ekte destinasjon i stedet for å spørre om tunnelen er oppe. En tunnel uten rute til den destinasjonen er en privat vei ingen bruker.

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

Den første kommandoen svarer på Linux og macOS, og de to andre er Windows-ekvivalentene der én er nok. Hvis svaret navngir den fysiske adapteren, er tunnelen oppe og standardruten flyttet seg aldri. Gjenta oppslaget for en destinasjon som burde bruke tunnelen, fordi to oppslag, ett fjernt og ett vanlig, forteller hvilket design som er tatt i bruk.

Tre former for selektiv ruting

En fulltunnelprofil skriver vanligvis en standardrute mot grensesnittet, eller skriver paret med halvområdeprefikser som vinner på prefikslengde mens den opprinnelige standardruten blir i tabellen. Selektiv ruting er det andre valget, og det kommer i flere former. Én profil ruter en enkelt vert som en RDP-tjener, en annen ruter et offentlig område som må nås fra et bestemt sted, og en tredje utelukker bevisst én applikasjon. Alle tre er legitime, og ingen av dem endrer adressen en vanlig 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 avgjør, og deretter tabellen for det det produserte. Et direktiv som skyves ut kan også undertrykkes på klienten, derfor må profilen og tabellen stemme før du klandrer tjeneren.

Den andre siden må skrive om kildeadressen

Det finnes en annen feil som ser identisk ut fra nettleseren. Ruten peker inn i tunnelen, tjeneren mottar pakkene og videresender dem deretter med klientens private adresse intakt. Neste hopp har ingen returvei for den adressen, så svar forsvinner og sider henger. Tjeneren må videresende i det hele tatt, og den må oversette kilden til noe internett kan rute tilbake.

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

Navngi grensesnittet som faktisk vender mot internett, noe som ikke alltid er eth0 på en moderne distribusjon. En hostet tjener med fast adresse kan oversette eksplisitt til den adressen i stedet for å bruke masquerade. Begge halvdeler teller, fordi videresending uten oversettelse lekker ikke-rutbare kilder, mens oversettelse uten videresending aldri ser pakken.

Navneoppslag går sin egen vei

Trafikk kan gå ut gjennom tunnelen mens oppslaget som fant navnet gikk til en resolver på det lokale nettet. Den synlige adressen forblir den samme, oppslagene ikke, og det gapet er nettopp det et delt DNS-design velger.

resolvectl status | head -20
resolvectl query example.org

Legg merke til hvilken tjener som svarte og om den avviker fra basislinjen før tunnelen. På en delt tunnel er dette vanligvis innstillingen folk ville endre da de klaget på adressen, og det er den de aldri så på.

Fire observasjoner som avgjør saken

Registrer utgangsadressen med tunnelen nede og deretter med den oppe. Kjør destinasjonsoppslaget i begge tilstander og noter grensesnittet hver gang.

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

Når oppslaget lander inne i tunnelen og ekkoet fortsatt viser leverandørens adresse, mangler oversettelsen ved utgangen. Når oppslaget lander på den fysiske adapteren, er profilen selektiv og den offentlige adressen var aldri i spill. Bytt ut ekkotjenesten med en du stoler på og skriv ned de fire observasjonene sammen, fordi hver for seg er de anekdoter. Sammen viser de hvilken av de to jobbene klienten faktisk utførte.