Groen pictogram, hetzelfde openbare IP: welke route de VPN oversloeg
Het pictogram in de systeemvak meldt een tunnel, geen standaardroute. Vier opzoekingen tonen of de client de route installeerde, of dat de uitgang je bron nooit vertaalde.
Verbonden, groen pictogram in het systeemvak en een pagina die je adres teruggeeft en nog steeds het adres van de provider toont, betekenen niet automatisch een storing. Een client doet twee aparte taken: hij bouwt een tunnel, en hij bewerkt de routetabel. Elk kan zonder het ander gebeuren, en selectief routeren is de configuratie waarbij het tweede bewust wordt overgeslagen.
Wat de client werkelijk installeerde
Vraag welke interface een pakket naar een echte bestemming zou dragen in plaats van te vragen of de tunnel omhoog is. Een tunnel zonder route naar die bestemming is een particuliere weg waar niemand rijdt.
ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4De eerste opdracht antwoordt op Linux en macOS, en de andere twee zijn de Windows-equivalenten waar één genoeg is. Als het antwoord de fysieke adapter noemt, staat de tunnel omhoog en is de standaardroute nooit verschoven. Herhaal de opzoeking voor een bestemming die de tunnel zou moeten gebruiken, want twee opzoekingen, een verre en een gewone, zeggen welk ontwerp is uitgerold.
Drie vormen van selectief routeren
Een volledig-tunnelprofiel schrijft meestal een standaardroute naar de interface, of schrijft het paar halve-bereikprefixen dat wint op prefixlengte terwijl de oorspronkelijke standaardroute in de tabel blijft. Selectief routeren is de andere keuze, en het komt in verschillende vormen. Eén profiel routeert één host zoals een RDP-server, een ander routeert een openbaar bereik dat vanaf een bepaalde plek bereikbaar moet zijn, en een derde sluit bewust één toepassing uit. Alle drie zijn legitiem, en geen ervan verandert het adres dat een gewone website ziet.
grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20Lees het profiel voor de richtlijn die beslist, en dan de tabel voor wat die heeft opgeleverd. Een richtlijn die wordt geduwd kan ook op de client worden onderdrukt, daarom moeten profiel en tabel overeenkomen voordat je de server de schuld geeft.
De andere kant moet het bronadres herschrijven
Er is een tweede storing die er vanuit de browser identiek uitziet. De route wijst de tunnel in, de server ontvangt de pakketten en stuurt ze vervolgens door met het privéadres van de client intact. De volgende hop heeft geen terugweg voor dat adres, dus antwoorden verdwijnen en pagina's blijven hangen. De server moet überhaupt doorsturen, en hij moet de bron vertalen naar iets wat het internet terug kan routeren.
sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADENoem de interface die echt naar het internet kijkt, wat op een moderne distributie niet altijd eth0 is. Een gehoste server met een vast adres kan expliciet naar dat adres vertalen in plaats van masquerade te gebruiken. Beide helften tellen, want doorsturen zonder vertaling lekt niet-routeerbare bronnen, terwijl vertaling zonder doorsturen het pakket nooit ziet.
Naamresolutie gaat zijn eigen weg
Verkeer kan via de tunnel naar buiten gaan terwijl de opzoeking die de naam vond naar een resolver op het lokale netwerk ging. Het zichtbare adres blijft hetzelfde, de opzoekingen niet, en precies die kloof kiest een gesplitst DNS-ontwerp.
resolvectl status | head -20
resolvectl query example.orgLet op welke server antwoordde en of die afwijkt van de basislijn vóór de tunnel. Op een gesplitste tunnel is dit meestal de instelling die mensen wilden wijzigen toen ze over het adres klaagden, en het is degene waar ze nooit naar keken.
Vier observaties die de kwestie beslechten
Leg het uitgangsadres vast met de tunnel omlaag, en dan met de tunnel omhoog. Voer de bestemmingsopzoeking in beide toestanden uit en noteer elke keer de interface.
curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9Wanneer de opzoeking binnen de tunnel landt en de echo nog steeds het adres van de provider toont, ontbreekt de vertaling bij de uitgang. Wanneer de opzoeking op de fysieke adapter landt, is het profiel selectief en was het openbare adres nooit in beeld. Vervang de echodienst door een die je vertrouwt en noteer de vier observaties samen, want los zijn het anekdotes. Samen wijzen ze aan welke van de twee taken de client werkelijk uitvoerde.