To apparat, eitt Wi-Fi, ulike VPN-utgangar: kva som avgjer

To berbare datamaskinar på same heimerutaren kan nå internett gjennom ulike VPN-utgangar, og det delte Wi-Fi-nettet har ingenting med det å gjere. Det som avgjer resultatet, er kvar tunnelen køyrer og kva politikk som vel vegen for kvar førespurnad. Den motsette oppfatninga er like vanleg og like feil: to apparat med separate profilar gir ikkje automatisk to offentlege adresser. Begge feila kjem av å handsame éi adresse som om ho var tre.

Tre adresser, og berre éi av dei går ut

Ein berbar datamaskin har ei heime-LAN-adresse som identifiserer han på det lokale segmentet, og han kan også ha ei tunneladresse tildelt inne i VPN-en. Ingen av dei er synlege for ein ekstern teneste. Det tenesta registrerer, er den offentlege utgangsadressa til eininga som til slutt sender pakken, etter kvar oversetjing undervegs.

RFC 3022 dreg skillet som forklarer det meste av forvirringa her. Tradisjonell NAT overset interne adresser til offentlege, medan portoversetjing lèt mange interne adresser dele éi offentleg adresse samstundes. Ein husstand med éi offentleg adresse og fleire einingar er det andre tilfellet, og det er standard nesten overalt.

Tel dei offentlege adressene, ikkje profilane. To klientar med ulike tunneladresser og same utgangspolitikk gir éi observert adresse, og éin einaste klient med ein annan ruting av utgangen kan gi ei anna. Den eine samanlikninga er heile testen. Alt anna er ei føresettning om den fjerne enden.

Kva som gjer to utgangar verkeleg ulike

Ein utgang er ulik når den siste eininga før internett brukar ei anna offentleg adresse for den trafikken. Det kan skje fordi VPN-en blir avslutta ein annan stad, fordi utgangspoolen tildeler ei anna adresse, eller fordi leverandøren rutar førespurnaden gjennom ein annan utgang. Alle tre er politiske vedtak tekne i den fjerne enden, og ingen av dei er synlege frå heimerutaren.

To apparat som kvar køyrer sin eigen klient med same profil, hamnar vanlegvis i same pool og får ofte same utgang for ei gitt økt. Det er ikkje ein feil, det er normal åtferd for ein delt pool. Å få ulike utgangar tyder vanlegvis å be tenesta om ulike tildelingar i staden for å konfigurere klienten to gonger.

Les vilkåra for samtidige tilkoplingar før du designar rundt ein garanti. Ei anna innlogging er løyve til å kople til, ikkje eit løfte om ei eksklusiv adresse. Om vilkåra er tause, spør leverandøren i staden for å føresetje. Svaret endrar designet meir enn noka klientinnstilling.

Kvifor separate profilar ikkje er separate utgangar

Ein profil skildrar korleis ein når VPN-en og korleis ein autentiserer, og han seier nesten ingenting om kva som skjer etterpå. Utgangen blir vald av den fjerne enden, der ruting, adressepoolar og oversetjingspolitikk bur. Å duplisere ein profil på ein annan maskin dupliserer klientkonfigurasjonen, ikkje avgjerda til tenaren.

Det motsette gjeld òg. Éin VPN-tenar kan presentere meir enn éin offentleg utgang når rutinga og oversetjingspolitikken er bygde slik, medan separate tenarar kan fø ei enkelt nedstraums utgang. Talet på tenarnamn i konfigurasjonen seier derfor ingenting om talet på adresser. Difor er konfigurasjonen feil stad å leite etter dette svaret.

Det einaste pålitelege svaret kjem frå ein førespurnad gjort gjennom ordninga du aktar å bruke. Alt anna er slutning.

Kvar skillet skal liggje

Ein rutertunnel dekkjer heile husstanden, noko som er praktisk og gir nøyaktig éin delt utgang for kvar eining bak han. Ein klient på kvar eining gir deg kontroll per eining, men krev at kvar eining blir klargjord og blir verande klargjord. Ein ruter med politikkstøtte sit imellom, vel ein veg per eining, og han verkar berre om han kan identifisere einingar påliteleg gjennom attoppkoplingar og DHCP-endringar.

Å opprette ein ny privat DHCP-lease på rutaren er ikkje det same som å opprette ei ny offentleg adresse. Det endrar det lokale bildet og lèt utgangen vere urørt. Skillet ligg i utgangspolitikken, anten den politikken er på rutaren eller hos VPN-tenesta.

Uansett kva form du vel, skriv ned eigarskapet: kven klargjer eit apparat, kven roterer legitimasjonen hans, og kven merkar når det sluttar å bruke den tiltenkte vegen.

Kontroller utgangen du faktisk fekk

Gjer kontrollen frå applikasjonen som betyr noko, og samanlikn same adressefamilie på begge einingane. Eit IPv4-resultat frå den eine og eit IPv6-resultat frå den andre provar ingenting om nokon av dei. Gjenta så kontrollen etter ei attoppkopling, fordi pooltildelinga kan endre seg mellom økter.

Køyr det frå ein terminal inne i tunnelpolitikken, ikkje frå eit apparat som går utanom han. Feil vert gir eit sjølvsikkert 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

Om begge einingane skriv ut same IPv4-adresse, deler dei éin utgang uansett kor mange tunnelar som er oppe. Avgjer då kva som skjer når tunnelen sviktar: ein klient som fell tilbake til den direkte vegen set begge einingane tilbake på heimeadressa, og skillet forsvinn utan feil. Stadfest den tilbakefallsåtferda før du skildrar ordninga som to utgangar, og hugs at ulike adresser er eit nettverksresultat og ikkje to anonyme identitetar.