Como rexistrar e verificar o enderezo de saída VPN que usou
As apps de cliente amosan un nome de localización, non o enderezo polo que saíu o seu tráfico. Capture o IP de saída ao conectar e compáreo cunha referencia directa.
Pregunte a un cliente VPN de escritorio que servidores usou e a resposta honesta adoita ser un nome de localización. Ese nome é o punto de entrada que marcou, e o enderezo polo que saíu o seu tráfico pode ser unha máquina completamente distinta. Nada na app está deseñado para conservar o segundo número, así que o rexistro ten que construírse no momento do uso. Existen dous enfoques, e só un deles sobrevive a un caso de soporte.
Dous rexistros, e só un deles existe
A vista do propio cliente é, no mellor dos casos, unha lista de localizacións escollidas con marcas de tempo. É unha decisión de deseño e non un descoido: os enderezos son detalle operativo, rotan entre asignacións, e expor a correspondencia dificulta tanto o soporte como o tratamento de abusos. Os provedores poñen instancias na nube diante das súas redes precisamente para que o punto final poida moverse sen avisar a ninguén. O que a app lle amosa é a escolla que fixo, non a ruta que tomou.
O rexistro que vostede pode construír é un ficheiro local cun enderezo público e unha marca de tempo UTC por liña. É máis pequeno, máis feo e moito máis útil, porque describe exactamente o que un observador externo tamén pode ver.
Opción A: capture vostede mesmo o enderezo de saída
Un servizo de eco devolve o enderezo de orixe desde o que chegou a petición, que é por definición o enderezo de saída. Execute a captura despois de que o túnel informe de conectado, porque un cliente que di conectado antes de que as rutas e o DNS asenten rexistrará o enderezo previo ao túnel e envenenará o rexistro desde a primeira liña.
#!/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"Dous detalles fan que ese fragmento sexa utilizábel e non decorativo. A marca de tempo e o enderezo comparten unha liña, de xeito que unha análise posterior non ten que emparellar rexistros, e umask 077 mantén o ficheiro privado desde o momento en que se crea. Execúteo unha vez por conexión en lugar de unha vez por arranque, e manteña un ficheiro por dispositivo.
O rexistro anota cando usou un túnel e desde que rede apareceu, o que está máis preto dun historial de navegación que dun contador. Escolla un período de retención que poida defender, manteña o ficheiro fóra de cartafoles de sincronización compartidos e bórreo deliberadamente.
Opción B: pida un historial ao provedor
Algúns provedores gardan rexistros de conexión e responderán a unha pregunta de soporte cunha marca de tempo e un nome de servidor. Ese rexistro describe a súa infraestrutura e non o seu tráfico, e só vale o que valen a súa fiestra de retención e a súa vontade de mirar. Ademais describe unha sesión, non unha petición. A fiestra adoita ser curta, e mídese desde o lado do provedor do túnel.
Os provedores que anuncian que non rexistran non poden producir isto a petición, e unha lista de localizacións recentes do lado do cliente non é o mesmo. Pedir un enderezo de saída a un provedor sen rexistros adoita rematar cunha explicación de por que eses datos non existen.
Que pode probar cada rexistro nun caso de soporte
Os dous rexistros responden preguntas distintas, e é na táboa onde a comparación 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 |
Só a primeira columna está baixo o seu control. Un rexistro do provedor pode confirmar que unha conta estaba conectada nun momento dado, pero non pode confirmar que peticións usaron o túnel, e non nomeará un enderezo que o provedor trata como detalle operativo. Ningún dos dous rexistros identifica unha persoa, porque un enderezo de saída compartido pode levar moitos clientes no mesmo minuto.
Compare ambos cunha referencia antes de confiar en calquera deles
Un enderezo por si só non proba nada. Capture o enderezo directo antes de conectar, o enderezo tunelizado despois, e compáreos. Valores idénticos significan que o túnel non transporta esa petición, xa sexa por un túnel dividido, por un proxy preponderante ou por un cliente que caeu a unha 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.1Repita a comparación para DNS e para IPv6, porque un eco de enderezo proba a ruta dunha soa petición HTTP e nada sobre que resolvedor respondeu. Un dispositivo que ten fugas nun dos dous pode verse perfectamente san no outro.