¿Puerta de enlace o cliente reenviado? Leer la dirección de origen

El servidor web registra una dirección, y todos asumen que pertenece al proceso de la propia puerta de enlace. Puede pertenecer a un cliente reenviado cuya dirección privada desapareció en el paso de traducción. El destino ve el origen de red visible y nada más. Es una afirmación de frontera, no la pretensión de que el origen nunca pueda establecerse.

Qué ve realmente el destino

Tome un cliente en 10.20.0.7, una puerta de enlace cuya dirección exterior es 198.51.100.10 y un destino en internet. Si la puerta de enlace traduce el origen del cliente, el socket del destino registra 198.51.100.10. La dirección privada desaparece del paquete, y el destino no puede volver a leerla desde esa cabecera. Esos números son ilustrativos, no una captura de su red.

La observación sigue siendo útil: identifica el origen de red que el destino debe permitir o bloquear. Simplemente no identifica a la persona ni al proceso que hay detrás. Para el operador del destino, esa distinción decide si un bloqueo es una decisión de red o una decisión de cuenta.

El estado de traducción no es visible para el destino

La puerta de enlace mantiene la correspondencia entre la conexión traducida y el cliente original, y ese estado es exactamente lo que le falta al destino. descripción tradicional del NAT separa el registro de traducción de las cabeceras visibles después. Leer un lado no le da el otro.

Diseños distintos producen pruebas distintas. El tráfico enrutado con direcciones de origen preservadas muestra la dirección real del cliente, mientras que un proxy de aplicación termina la conexión y crea una nueva. Una ruta con origen preservado también exige que la dirección del cliente sea enrutable de vuelta desde el destino, algo que no todos los despliegues ofrecen. Pregunte qué diseño está desplegado antes de interpretar una línea de registro.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

El TTL y las huellas son pistas, no pruebas

El TTL de IPv4 depende del valor inicial elegido por el emisor y del número de saltos que cruzó el paquete. Sin ambos datos, un valor no puede demostrar que se produjo un salto de VPN. Un salto enrutado adicional conocido tampoco distingue un enrutador de LAN, una ruta de túnel u otra disposición de reenvío. Trate una diferencia de TTL como una pregunta, no como una conclusión.

Otras señales se comportan igual. Una cabecera User-Agent puede fijarla la aplicación, y la similitud de tiempos puede reflejar infraestructura compartida en lugar de una persona compartida. Varios usuarios pueden compartir una salida, y un usuario puede cambiar de ruta entre sesiones. Recogidas juntas, varias señales débiles pueden justificar una mirada más atenta a los registros de una puerta de enlace, pero no se convierten en pruebas sólidas por acumulación.

Autorice por identidad, no por dirección

Si el destino debe separar la administración de la puerta de enlace de la actividad de usuarios remotos, dé a esos roles identidades autenticadas separadas y operaciones permitidas. Un origen público compartido todavía puede servir como restricción de red, pero no sustituye la autenticación del usuario o del dispositivo.

Mantenga las pruebas etiquetadas: origen observado, cuenta autenticada, momento y la inferencia considerada. No traduzca «aquí no se ve ningún origen interno» por «no es posible ninguna atribución en ningún lugar». La etiqueta importa cuando alguien que no formó parte de la investigación lee el registro meses después.

Registre la fecha de la observación y el sistema que la produjo. Un extracto de registro sin atribución es difícil de defender más tarde.