network programming - ¿Sigue pwnat trabajando?

network-programming rdp

Question

Necesito una solución para NAT transversal para transmitir datos RDP a través de Internet. Encontré la siguiente herramienta y es realmente increíble: pwnat .

Lo he intentado con dos máquinas diferentes detrás de un enrutador diferente, pero no puedo hacer que funcione como se explica en el enlace anterior. Entonces, ¿el pwnat sigue funcionando y si es así, qué podría haber hecho mal? Sería muy útil para mí.

Nota: Estoy usando Windows Machine para probar y descargué la versión de Windows del siguiente enlace.

http://www.sumitgupta.net/pwnat-windows-complied-version/

Cualquier ayuda por favor ..

Answer 1

No.
Supongo que sabes cómo funcionó:
el servidor envió paquetes de solicitud de eco ICMP a la dirección fija (por ejemplo, 1.2.3.4) desde donde no se devolverían las respuestas de eco, el cliente, que simulaba ser un salto en Internet, envió un paquete de tiempo excedido ICMP al servidor, esperaba que el NAT en la parte frontal del servidor reenviara el mensaje de tiempo excedido de ICMP al servidor.

La imagen de arriba es de la pwnat , se pwnat en la premisa de que el cliente no está detrás de NAT y el mensaje de la carga útil original en el tiempo excedido no suele ser verificado por las implementaciones de NAT. Si tanto el cliente como el servidor están detrás de NAT como este,

=========================================================================================
| CLIENT  | <---> |  NAT-C  | <---> { internet } <---> |  NAT-S  | <---> | SERVER |
=========================================================================================

Rara vez funciona hoy en día principalmente por 2 razones a continuación:

1. Cuando el servidor envía paquetes de solicitud de eco ICMP a la dirección fija, de acuerdo con RFC 3022 , el campo identificador en el encabezado de solicitud de eco ICMP se asignará de manera única a un identificador de consulta de la dirección IP registrada por NAT-S para que pueda enrutar el ICMP futuro. Eco responde con el mismo ID de consulta al remitente, por lo que el encabezado ICMP en los paquetes de consulta ICMP debe modificarse para reemplazar el ID de consulta y la suma de comprobación del encabezado ICMP . RFC 3022 ICMP sección de modificaciones del paquete de error :

   En una configuración NAPT, si el mensaje IP incrustado en ICMP es un paquete de consulta TCP, UDP o ICMP, también deberá modificar el número de puerto TU apropiado dentro del encabezado TCP / UDP o el campo Identificador de consulta en la consulta ICMP encabezamiento.

   Pero el cliente no conoce el ID de consulta externa (el código en pwnat usa 0 como el identificador de la solicitud original), envía un paquete de Tiempo Excedido ICMP al servidor, incluso si el paquete puede alcanzar NAT-S delante del servidor, NAT-S no puede encontrar la asignación activa para el paquete incorporado, la mayoría de las implementaciones de NAT lo eliminarán.

2. Además, según rfc 5508 , cuando el NAT-C recibe el paquete de error de ICMP del dominio privado, NAT-C usa el paquete incorporado dentro del mensaje de error de ICMP (es decir, el paquete de IP del cliente al servidor) para buscar la sesión NAT a la que pertenece el paquete incorporado. Si NAT-C no tiene una asignación activa para el paquete incorporado, el NAT-C DEBE soltar el paquete de error ICMP. Significa que el paquete de tiempo excedido de ICMP del cliente no llegaría a NAT-S.

Por lo tanto, pwnat solo funciona con dispositivos NAT básicos ( rfc 1631 describe) que hacen una traducción simple de direcciones, no funcionarán con ningún dispositivo NAPT que tenga una implementación robusta de NAPT. Y este papel menciona este problema.