La dirección que ve un sitio web después de que te conectas a una VPN corporativa no es la dirección que vio la puerta de enlace del trabajo cuando te conectaste. La puerta de enlace acepta un túnel entrante desde la red en la que esté tu portátil, y ese origen le resulta visible antes de que exista tráfico tunelizado. Que un navegador informe después de una salida corporativa no borra la observación anterior, porque son observaciones de cosas distintas. Entender cuál es cuál resuelve la mayor parte del debate sobre qué puede y qué no puede inferir un empleador.

Dos direcciones, dos observaciones distintas

El mecanismo es un socket, no una política. Cuando tu cliente abre el túnel, envía paquetes desde una dirección local a la dirección pública de la puerta de enlace, y el núcleo de esta registra el origen de ese flujo. Ese origen es el extremo de red que tu proveedor asignó a la conexión en ese momento.

Detrás de un router doméstico el origen es la dirección pública del router tras el NAT. En una red móvil puede ser una dirección NAT de nivel de operador compartida simultáneamente con muchos otros abonados, y por eso dos personas sin relación pueden parecer que vienen del mismo lugar. En una red de invitados corporativa es la salida de esa red. En todos los casos la puerta de enlace conoce una dirección, un puerto y una marca temporal, y la dirección pertenece a un operador de red y no a una persona.

Qué registra realmente la puerta de enlace

Qué se anota después es una cuestión distinta de qué es técnicamente visible. La puerta de enlace puede registrar la conexión, la identidad de autenticación y la dirección de túnel asignada, o puede no registrar casi nada más allá del estado de la sesión. La retención, la exportación a un SIEM y la correlación con una cuenta son decisiones de despliegue, y ninguna de ellas se deriva del hecho de que el origen fuera observable.

Trata la visibilidad y la retención como dos ejes. Un servicio puede verlo todo y no guardar nada, o ver poco y reenviarlo todo.

La consecuencia práctica es que no puedes razonar sobre los registros de tu empleador a partir del cliente que instalaste. Pregunta qué está configurado para recoger el servicio y durante cuánto tiempo, y espera que la respuesta sea un documento de política y no una garantía técnica. También vale la pena separar la puerta de enlace VPN de todo lo demás en un dispositivo gestionado, porque el software de extremo tiene sus propias capacidades y sus propios registros. Una VPN personal cambia una ruta; no cambia lo que puede observar el software que ya se ejecuta en la máquina.

Qué puede decir y qué no una base IP

Una base de datos de geolocalización IP toma esa dirección y devuelve campos: país, región, ciudad, código postal, latitud y longitud, más un radio de precisión cuando el proveedor lo ofrece. Esos campos son estimaciones derivadas de datos de registro, topología de red y latencia medida, y se degradan de forma distinta en cada nivel. Una respuesta de país puede ser sólida mientras la de ciudad es una conjetura.

La propia guía de precisión de MaxMind es explícita sobre la distinción que importa aquí: localizar un servidor VPN no es localizar a sus usuarios, y los datos no pueden identificar un hogar, a una persona ni una dirección postal. Lee el radio de precisión y los campos de confianza donde el producto los exponga, y trata los datos ausentes como ausentes y no como un valor por defecto. Un marcador en el mapa es una elección de representación, no una medición. Los registros de asignación y el DNS inverso son otro tipo de prueba: whois 203.0.113.5 te dice qué operador tiene la asignación y dig +short -x 203.0.113.5 te dice cómo la nombró el operador, y ninguno de los dos afirma dónde estaba una persona.

Registros que no son intercambiables

Esto corta en ambos sentidos, y por eso es una mala base para una decisión categórica. Una estimación que coincide con la región aprobada no demuestra presencia. Una discrepancia no demuestra, por sí sola, engaño.

Una revisión de trabajo remoto que se apoya en una sola consulta responde a una pregunta distinta de la que se plantea. Lo que necesita es contexto: qué ubicaciones permite el acuerdo, qué declaró la persona y si otras pruebas coinciden. Es un proceso de gestión con insumos técnicos, no un veredicto técnico.

Los demás registros que una organización puede tener no son intercambiables con una dirección de origen. La configuración de zona horaria es una preferencia del dispositivo que cualquiera puede cambiar; un evento de cuenta registra que hubo una sesión, no dónde; una lectura de ubicación del dispositivo hecha por software de extremo es otro sensor, con otros permisos y otros modos de error. Suponer que todos los empleadores los recogen todos es tan erróneo como suponer que no se recoge ninguno. La disciplina útil es nombrar el registro, su propietario y su modo de error antes de tratarlo como prueba de algo.

Qué se sigue para un acuerdo de trabajo

Para tus propios acuerdos, la pregunta que hay que hacer es qué recoge la organización y qué lugares de trabajo permite. Son dos respuestas de dos partes distintas del negocio.

Una visualización de la IP de origen no puede resolver el permiso para trabajar desde un lugar, y cambiar una ruta no sustituye al acuerdo del arreglo laboral. Si la política no está clara, el paso productivo es preguntar en lugar de optimizar la ruta de red. Las soluciones técnicas suelen producir exactamente el registro que parece una ocultación.

La afirmación técnica defendible es estrecha, y conviene mantenerla estrecha: la puerta de enlace observa el origen de red de la conexión entrante, una base de geolocalización puede estimar una ubicación para ese origen, y cualquier afirmación sobre la posición física de una persona necesita pruebas más allá de ambas. La guía de precisión de MaxMind es la referencia de lo que esas estimaciones sustentan. Todo lo que viene después es una cuestión de política disfrazada de técnica.

Artículos relacionados