Twee laptops op dezelfde thuisrouter kunnen via verschillende VPN-uitgangen het internet bereiken, en het gedeelde Wi-Fi heeft daar niets over te zeggen. Wat de uitkomst bepaalt, is waar de tunnel draait en welk beleid het pad voor elk verzoek kiest. De tegenovergestelde overtuiging is even gangbaar en even onjuist: twee apparaten met aparte profielen leveren niet automatisch twee publieke adressen op. Beide fouten komen voort uit het behandelen van één adres alsof het er drie zijn.

Drie adressen, en slechts één ervan gaat naar buiten

Een laptop heeft een thuis-LAN-adres dat hem op het lokale segment identificeert, en hij kan ook een tunneladres hebben dat binnen de VPN is toegewezen. Geen van beide is zichtbaar voor een externe dienst. Wat die dienst vastlegt, is het publieke uitgangsadres van het apparaat dat het pakket uiteindelijk verstuurt, na elke vertaling onderweg.

RFC 3022 trekt het onderscheid dat het meeste van de verwarring hier verklaart. Traditionele NAT vertaalt interne adressen naar publieke, terwijl poortvertaling veel interne adressen tegelijk één publiek adres laat delen. Een huishouden met één publiek adres en meerdere apparaten is het tweede geval, en dat is bijna overal de standaard.

Tel de publieke adressen, niet de profielen. Twee clients met verschillende tunneladressen en hetzelfde uitgangsbeleid leveren één waargenomen adres op, en één client met een anders gerouteerde uitgang kan een ander opleveren. Die ene vergelijking is de hele test. Al het andere is een aanname over de verre kant.

Wat twee uitgangen werkelijk verschillend maakt

Een uitgang is verschillend wanneer het laatste apparaat voor het internet voor dat verkeer een ander publiek adres gebruikt. Dat kan gebeuren doordat de VPN op een andere locatie eindigt, doordat de uitgangspool een ander adres toewijst, of doordat de provider het verzoek via een andere uitgang routeert. Alle drie zijn beleidsbeslissingen aan de verre kant, en geen ervan is zichtbaar vanaf de thuisrouter.

Twee apparaten die elk hun eigen client met hetzelfde profiel draaien, belanden meestal in dezelfde pool en krijgen vaak dezelfde uitgang voor een gegeven sessie. Dat is geen fout, het is het normale gedrag van een gedeelde pool. Aparte uitgangen krijgen betekent meestal de dienst om aparte toewijzingen vragen in plaats van de client twee keer te configureren.

Lees de servicevoorwaarden over gelijktijdige verbindingen voordat je rond een garantie ontwerpt. Een tweede login is toestemming om te verbinden, geen belofte van een exclusief adres. Zwijgen de voorwaarden, vraag het de provider in plaats van aan te nemen. Het antwoord verandert het ontwerp meer dan enige clientinstelling.

Waarom aparte profielen geen aparte uitgangen zijn

Een profiel beschrijft hoe je de VPN bereikt en hoe je authenticeert, en het zegt bijna niets over wat daarna gebeurt. De uitgang wordt gekozen aan de verre kant, waar routing, adrespoelen en vertaalbeleid leven. Een profiel op een tweede machine dupliceren dupliceert de clientconfiguratie, niet de beslissing van de server.

Het omgekeerde geldt ook. Eén VPN-server kan meer dan één publieke uitgang presenteren wanneer de routing en het vertaalbeleid zo zijn gebouwd, terwijl aparte servers één enkele stroomafwaartse uitgang kunnen voeden. Het aantal servernamen in je configuratie zegt dus niets over het aantal adressen. Daarom is de configuratie de verkeerde plek om dit antwoord te zoeken.

Het enige betrouwbare antwoord komt uit een verzoek via de opstelling die je van plan bent te gebruiken. Al het andere is gevolgtrekking.

Waar de scheiding hoort

Een routertunnel dekt het hele huishouden, wat handig is en precies één gedeelde uitgang oplevert voor elk apparaat erachter. Een client op elk apparaat geeft je controle per apparaat, maar vereist dat elk apparaat wordt ingericht en ingericht blijft. Een router met beleidsondersteuning zit ertussenin, kiest een pad per apparaat, en werkt alleen als hij apparaten betrouwbaar kan identificeren over herverbindingen en DHCP-wijzigingen heen.

Nog een private DHCP-lease op de router aanmaken is niet hetzelfde als nog een publiek adres aanmaken. Het verandert het lokale beeld en laat de uitgang ongemoeid. De scheiding zit in het uitgangsbeleid, of dat beleid nu op de router of bij de VPN-dienst staat.

Welke vorm je ook kiest, schrijf het eigenaarschap op: wie richt een apparaat in, wie roteert de inloggegevens ervan, en wie merkt het wanneer het ophoudt het bedoelde pad te gebruiken.

Controleer de uitgang die je daadwerkelijk kreeg

Doe de controle vanuit de toepassing die ertoe doet, en vergelijk dezelfde adresfamilie op beide apparaten. Een IPv4-resultaat van de één en een IPv6-resultaat van de ander bewijzen niets over geen van beide. Herhaal daarna de controle na een herverbinding, omdat de pooltoewijzing tussen sessies kan veranderen.

Voer het uit vanuit een terminal binnen het tunnelbeleid, niet vanaf een apparaat dat het omzeilt. De verkeerde host levert een zelfverzekerd verkeerd antwoord op.

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

Als beide apparaten hetzelfde IPv4-adres afdrukken, delen ze één uitgang ongeacht hoeveel tunnels er actief zijn. Bepaal dan wat er gebeurt als de tunnel uitvalt: een client die terugvalt op het directe pad zet beide apparaten weer op het thuisadres, en de scheiding verdwijnt zonder fout. Bevestig dat terugvalgedrag voordat je de opstelling als twee uitgangen beschrijft, en onthoud dat verschillende adressen een netwerkresultaat zijn en niet twee anonieme identiteiten.

Gerelateerde artikelen