To enheder, ét Wi-Fi, forskellige VPN-udgange: hvad der afgør det

To bærbare computere på samme hjemmerouter kan nå internettet gennem forskellige VPN-udgange, og det delte Wi-Fi har intet at sige om det. Det, der afgør resultatet, er hvor tunnelen kører, og hvilken politik der vælger vejen for hver anmodning. Den modsatte overbevisning er lige så udbredt og lige så forkert: to enheder med separate profiler giver ikke automatisk to offentlige adresser. Begge fejl kommer af at behandle én adresse, som om den var tre.

Tre adresser, og kun én af dem går ud

En bærbar computer har en hjemme-LAN-adresse, der identificerer den på det lokale segment, og den kan også have en tunneladresse tildelt inde i VPN'en. Ingen af dem er synlige for en ekstern tjeneste. Det, tjenesten registrerer, er den offentlige udgangsadresse for den enhed, der til sidst sender pakken, efter enhver oversættelse undervejs.

RFC 3022 drager den skelnen, der forklarer det meste af forvirringen her. Traditionel NAT oversætter interne adresser til offentlige, mens portoversættelse lader mange interne adresser dele én offentlig adresse på samme tid. En husstand med én offentlig adresse og flere enheder er det andet tilfælde, og det er standard næsten overalt.

Tæl de offentlige adresser, ikke profilerne. To klienter med forskellige tunneladresser og samme udgangspolitik giver én observeret adresse, og en enkelt klient med en anderledes rutet udgang kan give en anden. Den ene sammenligning er hele testen. Alt andet er en antagelse om den fjerne ende.

Hvad gør to udgange virkelig forskellige

En udgang er forskellig, når den sidste enhed før internettet bruger en anden offentlig adresse til den trafik. Det kan ske, fordi VPN'en afsluttes et andet sted, fordi udgangspuljen tildeler en anden adresse, eller fordi udbyderen ruter anmodningen gennem en anden udgang. Alle tre er politiske beslutninger truffet i den fjerne ende, og ingen af dem er synlige fra hjemmerouteren.

To enheder, der hver kører deres egen klient med samme profil, lander normalt i den samme pulje og får ofte den samme udgang for en given session. Det er ikke en fejl, det er normal adfærd for en delt pulje. At få forskellige udgange betyder normalt at bede tjenesten om forskellige tildelinger i stedet for at konfigurere klienten to gange.

Læs tjenestevilkårene om samtidige forbindelser, før du designer ud fra en garanti. Et andet login er tilladelse til at forbinde, ikke et løfte om en eksklusiv adresse. Hvis vilkårene er tavse, så spørg udbyderen i stedet for at antage. Svaret ændrer designet mere end nogen klientindstilling.

Hvorfor separate profiler ikke er separate udgange

En profil beskriver, hvordan man når VPN'en, og hvordan man godkender, og den siger næsten intet om, hvad der sker bagefter. Udgangen vælges af den fjerne ende, hvor routing, adressepuljer og oversættelsespolitik bor. At kopiere en profil til en anden maskine kopierer klientkonfigurationen, ikke serverens beslutning.

Det omvendte gælder også. Én VPN-server kan præsentere mere end én offentlig udgang, når dens routing og oversættelsespolitik er bygget sådan, mens separate servere kan føde en enkelt nedstrøms udgang. Så antallet af servernavne i din konfiguration siger intet om antallet af adresser. Derfor er konfigurationen det forkerte sted at lede efter dette svar.

Det eneste pålidelige svar kommer fra en anmodning gjort gennem den ordning, du agter at bruge. Alt andet er slutning.

Hvor adskillelsen skal ligge

En routertunnel dækker hele husstanden, hvilket er bekvemt og giver præcis én delt udgang for hver enhed bag den. En klient på hver enhed giver dig kontrol pr. enhed, men kræver, at hver enhed klargøres og forbliver klargjort. En router med politikstøtte sidder imellem, vælger en vej pr. enhed, og den virker kun, hvis den kan identificere enheder pålideligt på tværs af genopkoblinger og DHCP-ændringer.

At oprette en ny privat DHCP-lease på routeren er ikke det samme som at oprette en ny offentlig adresse. Det ændrer det lokale billede og lader udgangen være urørt. Adskillelsen ligger i udgangspolitikken, uanset om den politik er på routeren eller hos VPN-tjenesten.

Uanset hvilken form du vælger, så skriv ejerskabet ned: hvem klargør en enhed, hvem roterer dens legitimationsoplysninger, og hvem opdager, når den holder op med at bruge den tilsigtede vej.

Kontrollér den udgang, du faktisk fik

Foretag kontrollen fra det program, der betyder noget, og sammenlign samme adressefamilie på begge enheder. Et IPv4-resultat fra den ene og et IPv6-resultat fra den anden beviser intet om nogen af dem. Gentag derefter kontrollen efter en genopkobling, fordi puljetildelingen kan ændre sig mellem sessioner.

Kør det fra en terminal inde i tunnelpolitikken, ikke fra en enhed, der omgår den. Den forkerte vært giver et selvsikkert forkert 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 enheder udskriver den samme IPv4-adresse, deler de en udgang, uanset hvor mange tunneler der er oppe. Beslut derefter, hvad der sker, når tunnelen svigter: en klient, der falder tilbage til den direkte vej, sætter begge enheder tilbage på hjemmeadressen, og adskillelsen forsvinder uden en fejl. Bekræft den tilbagefaldsadfærd, før du beskriver ordningen som to udgange, og husk, at forskellige adresser er et netværksresultat og ikke to anonyme identiteter.