To enheter, ett Wi-Fi, ulike VPN-utganger: hva som avgjør

To bærbare datamaskiner på samme hjemmeruter kan nå internett gjennom ulike VPN-utganger, og det delte Wi-Fi-nettet har ingenting med det å gjøre. Det som avgjør resultatet, er hvor tunnelen kjører og hvilken policy som velger veien for hver forespørsel. Den motsatte oppfatningen er like vanlig og like feil: to enheter med separate 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 datamaskin har en hjemme-LAN-adresse som identifiserer den på det lokale segmentet, og den kan også ha en tunneladresse tildelt inne i VPN-en. Ingen av dem er synlige for en ekstern tjeneste. Det tjenesten registrerer, er den offentlige utgangsadressen til enheten som til slutt sender pakken, etter enhver oversettelse underveis.

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

Tell de offentlige adressene, ikke profilene. To klienter med ulike 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 enden.

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 et annet sted, fordi utgangspoolen tildeler en annen adresse, eller fordi leverandøren ruter forespørselen gjennom en annen utgang. Alle tre er policybeslutninger tatt i den fjerne enden, og ingen av dem er synlige fra hjemmeruteren.

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

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

Hvorfor separate profiler ikke er separate 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 av den fjerne enden, der ruting, adressepooler og oversettelsespolitikk bor. Å duplisere en profil på en annen maskin dupliserer klientkonfigurasjonen, ikke serverens beslutning.

Det motsatte gjelder også. Én VPN-server kan presentere mer enn én offentlig utgang når rutingen og oversettelsespolitikken er bygget slik, mens separate 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 ordningen du akter å bruke. Alt annet er slutning.

Hvor skillet skal ligge

En rutertunnel dekker hele husholdningen, 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 politikkstøtte 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 dens legitimasjon, og hvem merker når den slutter å bruke den tiltenkte veien.

Kontroller utgangen du faktisk fikk

Gjør kontrollen 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 kontrollen etter en gjenoppkobling, fordi pooltildelingen 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 feil 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 ordningen som to utganger, og husk at ulike adresser er et nettverksresultat og ikke to anonyme identiteter.