To enheter, én Wi-Fi, forskjellige VPN-utganger: hva som bestemmer

To bærbare PC-er på samme hjemmeruter kan nå internett gjennom forskjellige VPN-utganger, og det felles Wi-Fi-nettet spiller ingen rolle for det. Det som bestemmer utfallet, er hvor tunnelen kjører og hvilken policy som velger veien for hver forespørsel. Den motsatte forestillingen er like utbredt og like gal: to enheter med atskilte profiler gir ikke automatisk to offentlige adresser. Begge feilene kommer av å behandle én adresse som om den var tre.

Tre adresser, og bare én av dem går ut

En bærbar PC har en hjemme-LAN-adresse som identifiserer den på det lokale segmentet, og den kan i tillegg ha en tunneladresse tildelt inne i VPN-en. Ingen av disse er synlige for en ekstern tjeneste. Det tjenesten registrerer, er den offentlige utgangsadressen til enheten som til syvende og sist sender pakken, etter eventuell oversettelse underveis.

RFC 3022 trekker skillet som forklarer mesteparten av forvirringen her. Tradisjonell NAT oversetter interne adresser til offentlige, mens portoversettelse lar mange interne adresser dele én offentlig adresse samtidig. En husstand med én offentlig adresse og flere enheter er det andre tilfellet, og det er standarden nesten overalt.

Tell de offentlige adressene, ikke profilene. To klienter med forskjellige tunneladresser og samme utgangspolicy gir én observert adresse, og én enkelt klient med en annen ruting av utgangen kan gi en annen. Den ene sammenligningen er hele testen. Alt annet er en antakelse om den fjerne siden.

Hva som gjør to utganger virkelig forskjellige

En utgang er forskjellig når den siste enheten før internett bruker en annen offentlig adresse for den trafikken. Det kan skje fordi VPN-en avsluttes på et annet sted, fordi utgangsbassenget tildeler en annen adresse, eller fordi leverandøren ruter forespørselen gjennom en annen utgang. Alle tre er policybeslutninger tatt på den fjerne siden, og ingen av dem er synlige fra hjemmeruteren.

To enheter som hver kjører sin egen klient med samme profil, havner vanligvis i samme basseng og får ofte samme utgang for en gitt økt. Det er ikke en feil, det er normal oppførsel i et delt basseng. Å få forskjellige utganger betyr vanligvis å be tjenesten om forskjellige tildelinger i stedet for å konfigurere klienten to ganger.

Les vilkårene for samtidige tilkoblinger før du designer rundt en garanti. En ekstra innlogging er tillatelse til å koble til, ikke et løfte om en eksklusiv adresse. Er vilkårene tause, spør leverandøren i stedet for å anta. Svaret endrer designet mer enn noen klientinnstilling.

Hvorfor atskilte profiler ikke er atskilte utganger

En profil beskriver hvordan man når VPN-en og hvordan man autentiserer, og den sier nesten ingenting om hva som skjer etterpå. Utgangen velges på den fjerne siden, der ruting, adressebasseng og oversettelsespolitikk holder til. Å duplisere en profil på en annen maskin dupliserer klientkonfigurasjonen, ikke serverens beslutning.

Det omvendte gjelder også. Én VPN-server kan presentere mer enn én offentlig utgang når rutingen og oversettelsespolitikken er bygget slik, mens atskilte servere kan mate én enkelt nedstrøms utgang. Antall servernavn i konfigurasjonen sier derfor ingenting om antall adresser. Derfor er konfigurasjonen feil sted å lete etter dette svaret.

Det eneste pålitelige svaret kommer fra en forespørsel gjort gjennom oppsettet du har tenkt å bruke. Alt annet er slutning.

Hvor skillet skal ligge

En rutertunnel dekker hele husstanden, noe som er praktisk og gir nøyaktig én delt utgang for hver enhet bak den. En klient på hver enhet gir deg kontroll per enhet, men krever at hver enhet klargjøres og forblir klargjort. En ruter med støtte for policyer sitter imellom, velger en vei per enhet, og den virker bare hvis den kan identifisere enheter pålitelig gjennom gjenoppkoblinger og DHCP-endringer.

Å opprette en ny privat DHCP-lease på ruteren er ikke det samme som å opprette en ny offentlig adresse. Det endrer det lokale bildet og lar utgangen være urørt. Skillet ligger i utgangspolicyen, enten den policyen er på ruteren eller hos VPN-tjenesten.

Uansett hvilken form du velger, skriv ned eierskapet: hvem klargjør en enhet, hvem roterer legitimasjonen dens, og hvem merker det når den slutter å bruke den tiltenkte veien.

Sjekk utgangen du faktisk fikk

Gjør sjekken fra applikasjonen som betyr noe, og sammenlign samme adressefamilie på begge enhetene. Et IPv4-resultat fra den ene og et IPv6-resultat fra den andre beviser ingenting om noen av dem. Gjenta deretter sjekken etter en gjenoppkobling, fordi bassengtildelingen kan endre seg mellom økter.

Kjør det fra en terminal inne i tunnelpolicyen, ikke fra en enhet som omgår den. Feil vert gir et selvsikkert galt svar.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

Hvis begge enhetene skriver ut samme IPv4-adresse, deler de én utgang uansett hvor mange tunneler som er oppe. Bestem deretter hva som skjer når tunnelen svikter: en klient som faller tilbake til den direkte veien setter begge enhetene tilbake på hjemmeadressen, og skillet forsvinner uten feil. Bekreft den tilbakefallsatferden før du beskriver oppsettet som to utganger, og husk at forskjellige adresser er et nettverksresultat og ikke to anonyme identiteter.