Com registrar i verificar l’adreça de sortida VPN que heu fet servir
Les apps de client mostren un nom de lloc, no l’adreça per la qual ha sortit el vostre trànsit. Captureu la IP de sortida en connectar i compareu-la amb una referència directa.
Pregunteu a un client VPN d’escriptori quins servidors heu fet servir i la resposta honesta sol ser un nom de lloc. Aquest nom és el punt d’entrada que heu marcat, i l’adreça per la qual ha sortit el vostre trànsit pot ser una màquina completament diferent. Res a l’app no està dissenyat per conservar el segon número, així que el registre s’ha de construir en el moment de l’ús. Hi ha dos enfocaments, i només un sobreviu a un cas de suport.
Dos registres, i només un d’ells existeix
La vista del client és, com a màxim, una llista de llocs triats amb marques de temps. És una decisió de disseny i no un descuit: les adreces són detall operatiu, roten entre assignacions, i exposar la correspondència fa més difícils tant el suport com el tractament d’abusos. Els proveïdors posen instàncies al núvol davant de les seves xarxes justament perquè el punt final pugui moure’s sense avisar ningú. El que l’app us mostra és l’elecció que vau fer, no la ruta que va seguir.
El registre que podeu construir és un fitxer local amb una adreça pública i una marca de temps UTC per línia. És més petit, més lleig i molt més útil, perquè descriu exactament allò que un observador extern també pot veure.
Opció A: captureu vosaltres mateixos l’adreça de sortida
Un servei d’eco retorna l’adreça d’origen des de la qual va arribar la petició, que és per definició l’adreça de sortida. Executeu la captura després que el túnel informi de connectat, perquè un client que diu connectat abans que les rutes i el DNS s’assentin registrarà l’adreça prèvia al túnel i enverinarà el registre des de la primera línia.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"Dos detalls fan que aquest fragment sigui utilitzable i no decoratiu. La marca de temps i l’adreça comparteixen una línia, de manera que una anàlisi posterior no ha d’aparellar registres, i umask 077 manté el fitxer privat des del moment en què es crea. Executeu-lo una vegada per connexió en lloc d’una vegada per arrencada, i manteniu un fitxer per dispositiu.
El registre anota quan vau fer servir un túnel i des de quina xarxa vau aparèixer, cosa que s’acosta més a un historial de navegació que a un comptador. Trieu un període de retenció que pugueu defensar, mantingueu el fitxer fora de carpetes de sincronització compartides i purgueu-lo deliberadament.
Opció B: demaneu un historial al proveïdor
Alguns proveïdors guarden registres de connexió i respondran una pregunta de suport amb una marca de temps i un nom de servidor. Aquest registre descriu la seva infraestructura i no el vostre trànsit, i només val el que valen la seva finestra de retenció i la seva voluntat de mirar. A més, descriu una sessió, no una petició. La finestra sol ser curta, i es mesura des del costat del proveïdor del túnel.
Els proveïdors que anuncien que no registren no poden produir això a petició, i una llista de llocs recents al costat del client no és el mateix. Demanar una adreça de sortida a un proveïdor sense registres sol acabar amb una explicació de per què aquestes dades no existeixen.
Què pot provar cada registre en un cas de suport
Els dos registres responen preguntes diferents, i és a la taula on la comparació deixa de ser acadèmica.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
Només la primera columna és sota el vostre control. Un registre del proveïdor pot confirmar que un compte estava connectat en un moment donat, però no pot confirmar quines peticions van fer servir el túnel, i no nomenarà una adreça que el proveïdor tracta com a detall operatiu. Cap dels dos registres identifica una persona, perquè una adreça de sortida compartida pot portar molts clients en el mateix minut.
Compareu tots dos amb una referència abans de refiar-vos-en
Una adreça per si sola no prova res. Captureu l’adreça directa abans de connectar, l’adreça amb túnel després, i compareu-les. Valors idèntics volen dir que el túnel no transporta aquesta petició, ja sigui per un túnel dividit, per un proxy preponderant o per un client que va caure a una ruta directa.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1Repetiu la comparació per a DNS i per a IPv6, perquè un eco d’adreça prova el camí d’una sola petició HTTP i res sobre quin resolutor va respondre. Un dispositiu que té fuites en un dels dos pot semblar perfectament sa en l’altre.