Dos dispositius, una Wi-Fi, sortides VPN diferents: què ho decideix

Dos portàtils al mateix router de casa poden arribar a internet per sortides VPN diferents, i la Wi-Fi compartida no hi té res a dir. El que decideix el resultat és on corre el túnel i quina política tria el camí per a cada petició. La creença contrària és igual de comuna i igual d’errònia: dos dispositius amb perfils separats no produeixen automàticament dues adreces públiques. Tots dos errors venen de tractar una adreça com si fossin tres.

Tres adreces, i només una de les quals surt

Un portàtil té una adreça a la LAN de casa que l’identifica al segment local, i també pot tenir una adreça de túnel assignada dins de la VPN. Cap de les dues no és visible per a un servei remot. El que aquell servei enregistra és l’adreça de sortida pública del dispositiu que finalment envia el paquet, després de qualsevol traducció pel camí.

L’RFC 3022 traça la distinció que explica la major part de la confusió aquí. El NAT tradicional assigna adreces internes a adreces públiques, mentre que la traducció de ports permet que moltes adreces internes comparteixin una sola adreça pública alhora. Una llar amb una adreça pública i diversos dispositius és el segon cas, i és el valor per defecte gairebé a tot arreu.

Compteu les adreces públiques, no els perfils. Dos clients amb adreces de túnel diferents i la mateixa política de sortida produeixen una adreça observada, i un sol client amb una sortida encaminada d’una altra manera en pot produir una altra. Aquesta única comparació és tota la prova. La resta és una suposició sobre l’extrem remot.

Què fa que dues sortides siguin realment diferents

Una sortida és diferent quan l’últim dispositiu abans d’internet fa servir una adreça pública diferent per a aquell trànsit. Això pot passar perquè la VPN acaba en un lloc diferent, perquè el conjunt de sortides assigna una adreça diferent o perquè el proveïdor encamina la petició per una sortida diferent. Les tres són decisions de política preses a l’extrem remot, i cap no és visible des del router de casa.

Dos dispositius que cadascun executa el seu client amb el mateix perfil solen caure al mateix conjunt i sovint reben la mateixa sortida per a una sessió donada. No és un error, és el comportament normal d’un conjunt compartit. Aconseguir sortides diferents normalment vol dir demanar al servei assignacions diferents en lloc de configurar el client dues vegades.

Llegiu les condicions del servei sobre connexions simultànies abans de dissenyar al voltant d’una garantia. Un segon inici de sessió és permís per connectar-se, no una promesa d’adreça exclusiva. Si les condicions callen, pregunteu al proveïdor en lloc de suposar. La resposta canvia el disseny més que qualsevol ajust del client.

Per què els perfils separats no són sortides separades

Un perfil descriu com arribar a la VPN i com autenticar-s’hi, i gairebé no diu res del que passa després. La sortida la tria l’extrem remot, on viuen l’encaminament, els conjunts d’adreces i la política de traducció. Duplicar un perfil en una segona màquina duplica la configuració del client, no la decisió del servidor.

El contrari també és cert. Un servidor VPN pot presentar més d’una sortida pública quan el seu encaminament i la seva política de traducció estan construïts així, mentre que servidors separats poden alimentar una sola sortida descendent. Així, el nombre de noms de servidor a la configuració no diu res sobre el nombre d’adreces. Per això la configuració és el lloc equivocat per buscar aquesta resposta.

L’única resposta fiable ve d’una petició feta a través del dispositiu que penseu utilitzar. La resta és inferència.

On posar la separació

Un túnel al router cobreix tota la llar, cosa que és convenient i produeix exactament una sortida compartida per a cada dispositiu al darrere. Un client a cada dispositiu us dona control per dispositiu, però requereix que cada dispositiu estigui proveït i que ho segueixi estant. Un router amb capacitat de polítiques se situa entremig i tria un camí per dispositiu, i només funciona si pot identificar els dispositius de manera fiable a través de reconnexions i canvis de DHCP.

Crear una altra concessió DHCP privada al router no és el mateix que crear una altra adreça pública. Canvia la vista local i deixa la sortida intacta. La separació viu a la política de sortida, tant si aquesta política és al router com al servei de VPN.

Tant se val quina forma trieu, anoteu la propietat: qui aprovisiona un dispositiu, qui rota la seva credencial i qui nota quan deixa de fer servir el camí previst.

Comproveu la sortida que heu obtingut realment

Feu la comprovació des de l’aplicació que importa i compareu la mateixa família d’adreces als dos dispositius. Un resultat IPv4 d’un i un resultat IPv6 de l’altre no demostren res de cap dels dos. Després repetiu la comprovació després d’una reconnexió, perquè l’assignació del conjunt pot canviar entre sessions.

Executeu-ho des d’un terminal dins de la política del túnel, no des d’un dispositiu que la salti. L’amfitrió equivocat produeix una resposta equivocada i segura.

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

Si tots dos dispositius mostren la mateixa adreça IPv4, comparteixen una sortida independentment de quants túnels hi hagi aixecats. Després decidiu què passa quan el túnel falla: un client que torna al camí directe posa tots dos dispositius de nou a l’adreça de casa, i la separació desapareix sense cap error. Confirmeu aquest comportament de retorn abans de descriure el dispositiu com a dues sortides, i recordeu que adreces diferents són un resultat de xarxa i no dues identitats anònimes.