¿Cómo puedo detectar si NAT se usa en la red o no?
Sé que si tienes una dirección privada y puedes conectarte a una red pública o a Internet, entonces debe haber NAT.
Pero, ¿cómo detecto que NAT se usa en una red interna (que no está conectada a Internet pero usa NAT) o no ?
¿Hay alguna forma de que podamos verificarlo desde un paquete IP o mediante algún otro método?
Esta pregunta me trajo algunos recuerdos de cuando creé (con la ayuda de un amigo) una pequeña herramienta para detectar la presencia de NAT en las redes.
La idea es bastante simple (inspirada / robada de la técnica de NAT transversal en IPSec ): / p>
Tienes un segmento de red A y un segmento de red B, y quieres detectar la presencia de un NAT entre ellos.
Envíe un paquete TCP que contenga, en su carga útil, un resumen MD5 de su dirección IP y el puerto de origen desde un host en el segmento A a un host en el segmento B.
Escuche el paquete en el host en el segmento B. Una vez recibido, ejecute el IP de origen y el puerto de origen a través de MD5 y compare el resultado con el hash en la carga útil.
Coincidencia de elementos hash - > Sin NAT.
La herramienta consistió en dos pequeños A.exe y B.exe escritos en C ++.
Nota: Como todas las técnicas de detección de NAT, esta solución funciona mediante la verificación cruzada de los pares de puertos IP. No hay otra forma en que garantice la detección de NAT.
Mucho depende de tu escenario.
Si los dos hosts colaboran, solo uno de los dos envía su IP al otro. Opcionalmente, hash / encrypt para evitar que los filtros de reescritura de protocolo (como ftp-masq) vuelvan a escribir no solo la IP del paquete de encabezado sino también la carga útil. Luego, si las dos direcciones no coinciden, NAT debe haber estado en el trabajo.
Si solo tiene un host, que, por ejemplo, se conecta a su host y desea saber si se trata de una "IP verdadera" o una IP natada, probablemente no podrá hacerlo, si se espera la conexión de la máquina. para tener algún servicio disponible, puede intentar conectarse a su dirección y puerto correspondientes; a menos que la máquina NATting también realice una traducción enmascarada / "servidor virtual" inversa, debería poder ver si el servicio está abierto en la máquina solicitante (sin NAT) o no (NAT).
Con varios hosts, podría contar los paquetes y salir de los puertos de las conexiones entrantes. Las cajas NAT y las cajas "ordinarias" tienen diferentes esquemas de asignación de puertos. Las asimetrías de tráfico de diferentes puertos de origen también pueden ser síntomas de NAT (o alguien que mantiene varias páginas web abiertas en un proxy; la probabilidad de que eso , depende del escenario. Dos pares de puertos que tienen ambos el tráfico generalmente interactivo de un tipo muy diferente probablemente se deba a que hay dos usuarios detrás de un NAT. Y así sucesivamente).
Otro enfoque podría ser inspeccionar la sincronización de paquetes y TTL. Por lo general, las implementaciones de NAT no restablecen el contador TTL, por lo que se reducirá en uno al NATting. NAT también toma un poco de tiempo, y esto puede ser investigado estadísticamente.
Finalmente, puedes intentar ser sigiloso y responder con paquetes falsificados, nuevamente jugando con TTL. Si el cuadro NAT está regenerando el TTL para ocultar su NAT, es probable que lo haga solo para los paquetes de salida , y confíe en el código normal para el tráfico entrante. Si envía un paquete con TTL diseñado para que "expire en el momento del impacto", una máquina que no tenga NAT aún lo recibirá. La casilla NAT lo recibirá, disminuirá el contador TTL , y el paquete morirá en tránsito sin llegar a la máquina de origen. Obtendrás una gota o una respuesta ICMP superada por TTL.
A veces, se pueden emplear estrategias similares con esquemas de fragmentación de paquetes, pero esto requiere la gran suerte de tener una configuración de MTU asimétricamente favorable en las "piernas" de su máquina al supuesto cuadro NAT, y De esto a la máquina real.