TCP atravesando NAT
En primer lugar, TCP es diferente de UDP. En sí mismo, TCP es una conexión que no es de igual a igual, por lo que resulta difícil penetrar NAT.
El método más simple:
Cliente: a, b
Servidor (público) c
a envía información a c, En el Al mismo tiempo, c obtiene el puerto IP de a y otra información, y reenvía la solicitud de a a b, que ya está conectado a c. Todo el proceso es de cliente a servidor a cliente, c actúa como un retransmisor y la conexión establecida entre a y b es en realidad la conexión establecida entre a y cy by c.
Para aplicaciones con requisitos de confiabilidad más bajos, generalmente se usa udp.
Ventajas: aplicable a todo tipo de redes, simple
Desventajas: ancho de banda ocupado, velocidad lenta.
Los primeros msn eran así.
La segunda vía: la tecnología p2p de TCP.
Este método es el más popular ahora y lo estoy investigando.
Republicar la investigación de expertos de cmu (Universidad Carnegie Mellon):
×××××××××××××××
Original texto: Gracias.
Resumen
Los firewalls y los dispositivos de traducción de direcciones de red (NAT) tienen algunos problemas con los protocolos P2P tradicionales. Algunos dispositivos intermediarios suprimen las solicitudes TCP de la red externa a la red interna. El propósito de este artículo es encontrar una manera de establecer una conexión TCP entre hosts dentro de dos dispositivos NAT. Implementamos esta funcionalidad bajo dos condiciones de hardware comunes.
1. Primeros pasos
Debido a la reducción de las direcciones IP de 32 bits, muchos dispositivos ahora pueden acceder a Internet a través de la red interna a través de un proxy de dirección de INTERNET, que es el así. -llamada tecnología NAT. Estos dispositivos son cada vez más importantes para INTERNET, pero debido a la falta de estándares, su desarrollo independiente pone en peligro los protocolos de Internet actuales.
2. Tecnología
Los dispositivos NAT y firewall típicos no permiten que direcciones externas no solicitadas accedan a la red interna. Si el programa del usuario requiere una conexión directa entre dos redes internas, entonces los dos dispositivos internos deben confiar entre sí. Si tanto A como B inicializan una conexión TCP, el dispositivo NAT supone que confían entre sí y permite la conexión entre ellos.
La Figura 1 muestra un ejemplo donde el objetivo es permitir que A y B (a través de NATA y NATB respectivamente) establezcan conexiones TCP.
Discutiremos varios casos de uso de conexión TCP junto con dispositivos NAT específicos.
Si nuestra situación es la siguiente:
1. Puerto NA aleatorio, puerto NB predecible, ruta específica con IP de origen no especificada
5. Puerto NB aleatorio, ruta específica que puede especificar la IP de origen
6 Puerto NA aleatorio, puerto NB aleatorio, ruta específica que no puede especificar la IP de origen
Debemos realizar los siguientes 4. Supuestos:
1. Ningún host está restringido por el dispositivo NAT;
2. Podemos configurar el dispositivo de red para que el host no pueda ver los paquetes ICMP de la red externa (TTL excede). el límite) porque estos paquetes ICMP interrumpen la conexión TCP ya sea que los reciba cualquiera de las partes. Algunas de las soluciones que hemos analizado se basan en establecer una conexión TCP enviando un paquete SYN con un TTL inicial pequeño.
Una vez que el enrutador descarta el paquete SYN, el paquete de tiempo de espera TTL ICMP se enviará al dispositivo NAT. No permitimos que el dispositivo NAT envíe el paquete de retorno con este tiempo de espera TTL a la red interna, aunque el NAT enviará este paquete internamente, también es necesario configurar un firewall para impedir que este paquete llegue al host;
3. Incluso si el dispositivo NAT ve el paquete de tiempo de espera ICMP, no cambiará la tabla de mapeo del propio dispositivo;
4. Este puerto no será ocupado por otros hosts en la red interna porque es posible que el puerto no esté disponible si la red está particularmente ocupada.
3.1 La primera situación
Podemos resolver el problema mediante la secuencia que se muestra en la Figura 2:
1) A y B pueden configurar LSR (encabezado IP ( una opción en ), enviando el paquete SYN a través de la ruta X.
2) X puede almacenar en caché sus paquetes y enviar SYN ACK falsos a NA y NB.
3) A y B pueden responder utilizando los datos enviados por X.
4) X descarta dos paquetes ACK porque ya puede determinar que A y B respondieron exitosamente entre sí.
Figura 2 Supongamos que A y B conocen de antemano el puerto NAT del otro, A sabe que el puerto de B es NB:5000, B sabe que el puerto de A es NA:4000 y X no está detrás de ningún NAT. dispositivo. En la práctica, estos dos puertos son predecibles y el proceso de predicción se muestra en la Figura 3:
3.2 La segunda solución
La primera solución se basa en la configuración libre del enrutamiento, pero la mayoría Los enrutadores ahora restringen el enrutamiento gratuito y descartarán dichos paquetes de solicitud de servicio. Por lo tanto, en aplicaciones prácticas, este esquema tiene una alta probabilidad de fallar. Si no es posible el enrutamiento libre, podemos transmitir paquetes que de otro modo tendrían que enrutarse a X para que X pueda verlos a través de un canal fuera de banda (una conexión TCP preconectada a X). Tenga en cuenta que en el segundo paso de la Figura 2, X ya conoce los números de secuencia TCP Q y P porque. Para inicializar la conexión, ambos hosts envían paquetes SYN iniciales, ambos saben que es imposible llegar al destino, pero ambos pueden recordar sus números SYN (opinión personal, obtener los datos enviados conectando el paquete SYN) y poder para enviarlos a X. Hay dos formas de enviar paquetes que no pueden llegar a su destino. El enfoque simple es que cada host envíe un SYN al otro host, lo que requiere que el paquete de respuesta no llegue a la red interna. Si un NAT (firewall) envía un paquete de respuesta a la red interna, generalmente envía un paquete de restablecimiento de TCP (RST). Si NAT genera paquetes RST, A y B no pueden simplemente enviarse SYN entre sí como en la Figura 2, porque si lo hacen, NA y NB no pueden crear un agujero en la red. Otra forma de enviar paquetes SYN que no pueden llegar a la red de destino es reducir el valor TTL para que no puedan llegar a la otra parte. Si el usuario no puede configurar el firewall para descartar el paquete de respuesta ICMP, o el NAT no continúa enviando el ICMP, el TCP no se cerrará inmediatamente. Esta solución no puede utilizar una simple suplantación de identidad, ya que debemos asegurarnos de que la dirección de origen del remitente del paquete SYN no deje de recibir el paquete ICMP RST, ya que esto provocaría que el dispositivo intermedio establezca una ruta incorrecta. Basándose únicamente en paquetes SYN, NAT puede establecer una ruta desde una IP y un puerto de Internet a una IP y un puerto externos. Dado que el paquete SYN falsificado es la IP de origen incorrecta (no el remitente X), la ruta no se envía a X sino a NA o NB.
Además, este escenario requiere que el TTL se establezca lo suficientemente pequeño como para que el NAT opuesto no pueda recibir el paquete SYN inicial enviado por el NAT respectivo; de lo contrario, no se podrá completar la perforación. (Figura 4)
3.3 La tercera solución
Es más simple que las dos primeras soluciones, pero X no puede predecir el puerto de NA o NB. B primero enviará un paquete SYN a X para que a X le resulte más fácil conocer el número de puerto elegido. Luego, X enviará esta información a A, y A puede enviar un SYN a esta dirección y puerto determinados. La Figura 5 muestra una variante de la primera situación:
1) X envía información a A, y luego A envía SYN a la dirección y puerto determinados:
1) X es como se muestra En la figura, el puerto se predice como en 3, pero no puede predecir el siguiente número de puerto de NA, pero puede predecir que el siguiente número de puerto de NB es 5000 y puede notificar a A y B que el nodo ha establecido una conexión. ;
2) A y B están sincronizados con el nodo X;
3) X puede engañar a A y B;
4) A y B envían ACK a entre sí;
5 ) X descarta el ACK que se le envió porque ya puede confirmar que establecieron la conexión.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Problema, porque vpn es una red virtual en la que se confía en tcp.