seguridad que puedo programa podria permitir para internet estar esta configuracion conexion conecte como caracteristicas bloqueo bloquear bloqueando avast aplicacion algunas activar java networking hole-punching stun

java - que - no puedo activar firewall de windows 10



Ejemplo de perforación con orificios UDP de Java: conexión a través del cortafuegos (4)

Digamos que tengo dos computadoras.

Conocen los IPs públicos y privados de los ice4j través de ice4j .

Un cliente escuchando y el otro enviando una cadena.

Me gustaría ver que esto suceda a través de perforación UPD:

Let A be the client requesting the connection Let B be the client that is responding to the request Let S be the ice4j STUN server that they contact to initiate the connection -- A sends a connection request to S S responds with B''s IP and port info, and sends A''s IP and port info to B A sends a UDP packet to B, which B''s router firewall drops but it still punches a hole in A''s own firewall where B can connect B sends a UDP packet to A, that both punches a hole in their own firewall, and reaches A through the hole that they punched in their own firewall A and B can now communicate through their established connection without the help of S

¿Podría alguien publicar pseudo ejemplos de cómo hacer perforaciones a través de NAT simétrica? Suponiendo que habrá un servidor S que ayudará a adivinar los números de puerto y establecer la conexión entre el cliente A y B.

Sería bueno si también cuentas por doble NAT.

NOTA:

Puede usar STUN para descubrir la IP y el Puerto, pero debe escribir su propio código que envíe el IP: Puerto a su servidor a través de la técnica keepalive .

Una vez que un cliente identifica al otro a través de una identificación única en el servidor, se le proporcionará el IP del cliente del otro: información del puerto para perforar UDP los datos que necesita enviar y recibir.

Pequeña actualización:

Hay una biblioteca que se muestra en el horizonte para que java la vea:
https://github.com/htwg/UCE#readme

Este ejemplo está en C #, no en Java, pero los conceptos de NAT transversal son independientes del lenguaje.

Consulte la biblioteca de red de Michael Lidgren, que tiene incorporado NAT transversal.

Enlace: http://code.google.com/p/lidgren-network-gen3/ Archivo específico de C # que trata con NAT Traversal: http://code.google.com/p/lidgren-network-gen3/source/browse/trunk/Lidgren.Network/NetNatIntroduction.cs

El proceso que has publicado es correcto. Funcionará, solo para 3 de 4 tipos generales de dispositivos NAT (digo general porque el comportamiento NAT no está realmente estandarizado): NAT de cono completo, NAT de cono restringido y NAT de cono de puerto restringido. El cruce de NAT no funcionará con NAT simétricos, que se encuentran principalmente en redes corporativas para una mayor seguridad. Si una de las partes usa una NAT simétrica y la otra no, es posible atravesar la NAT pero requiere más conjeturas. Un cruce de NAT simétrico a NAT simétrico es extremadamente difícil. Puede leer un artículo al respecto aquí .

Pero realmente, el proceso que describió funciona exactamente. Lo he implementado para mi propio programa de pantalla compartida remota (también en C #, por desgracia). Solo asegúrate de haber desactivado el firewall de Windows (si estás usando Windows) y los firewalls de terceros. Pero sí, puedo confirmar felizmente que funcionará.

Aclarando el proceso de NAT Traversal

Estoy escribiendo esta actualización para aclarar el proceso de NAT transversal para usted y los futuros lectores. Con suerte, esto puede ser un resumen claro de la historia y el proceso.

Algunas fuentes de referencia: http://think-like-a-computer.com/2011/09/16/types-of-nat/ , y http://en.wikipedia.org/wiki/Network_address_translation , http://en.wikipedia.org/wiki/IPv4 , http://en.wikipedia.org/wiki/IPv4_address_exhaustion .

Las direcciones IPv4, con la capacidad de nombrar de forma exclusiva aproximadamente 4.300 millones de computadoras, se han agotado. Las personas inteligentes previeron este problema y, entre otras razones, inventaron enrutadores para combatir el agotamiento de direcciones IPv4, al asignar una red de computadoras conectadas a sí mismas 1 dirección IP compartida.

Hay LAN IPs. Y luego hay IP WAN. Las direcciones IP de LAN son IP de red de área local que identifican de forma exclusiva las computadoras en una red local, por ejemplo, los equipos de escritorio, portátiles, impresoras y teléfonos inteligentes conectados a un enrutador doméstico. Las direcciones IP de WAN identifican de manera única las computadoras que se encuentran fuera de la red de área local en una red de área amplia, lo que comúnmente se entiende como Internet. Entonces estos enrutadores asignan un grupo de computadoras con 1 WAN IP. Cada computadora todavía tiene su propia IP LAN. Las IP de LAN son lo que ves cuando ipconfig en tu Símbolo del sistema y obtienes la IPv4 Address . . . . . . . . 192.168.1.101 IPv4 Address . . . . . . . . 192.168.1.101 IPv4 Address . . . . . . . . 192.168.1.101 . IP de WAN es lo que ves cuando te conectas a cmyip.com y obtienes 128.120.196.204 .

Del mismo modo que se compra el espectro de radio , las agencias y organizaciones, así como los números de puerto, compran y reservan rangos de IP completos. El mensaje corto es, una vez más, que no tenemos más direcciones IPv4 de sobra.

¿Qué tiene esto que ver con NAT transversal? Bueno, desde que se inventaron los enrutadores, las conexiones directas (conectividad de extremo a extremo ) han sido un tanto ... imposibles, sin algunos ataques. Si tiene una red de 2 computadoras (Computadora A y Computadora B) ambas compartiendo la IP WAN de 128.120.196.204 , ¿a qué computadora conecta? Estoy hablando de una computadora externa (digamos google.com) que inicia una conexión a 128.120.196.204 . La respuesta es: nadie lo sabe , y tampoco el enrutador, por lo que el enrutador desconecta la conexión. Si el Equipo A inicia una conexión a, digamos, google.com , entonces esa es una historia diferente. El enrutador luego recuerda que el Equipo A con LAN IP 192.168.1.101 inició una conexión a 74.125.227.64 (google.com). A medida que el paquete de solicitud de la Computadora A abandona el enrutador, el enrutador realmente vuelve a escribir LAN IP 192.168.1.101 en la IP WAN del enrutador de 128.120.196.204 . Entonces, cuando google.com recibe el paquete de solicitud del Equipo A, ve el IP del remitente que el enrutador volvió a escribir, no el IP de LAN del Equipo A (google.com ve el IP 128.120.196.204 como respuesta). Cuando google.com finalmente responde, el paquete llega al enrutador, el enrutador recuerda (tiene una tabla de estado) que esperaba una respuesta de google.com, y reenvía el paquete apropiadamente a la Computadora A.

En otras palabras, su enrutador no tiene problemas cuando inicia la conexión: su enrutador recordará reenviar el paquete de respuesta a su computadora (a través de todo el proceso descrito anteriormente). Pero, cuando un servidor externo inicia una conexión contigo , el enrutador no puede saber para qué computadora está destinada la conexión, ya que el Equipo A y el Equipo B comparten la IP WAN de 128.120.196.204 ... a menos que exista una regla clara que ordena al enrutador reenviar todos los paquetes que van originalmente al puerto de destino X , ahora para ir a la Computadora A, puerto de destino Y Esto se conoce como reenvío de puertos . Desafortunadamente, si está pensando en usar el reenvío de puertos para sus aplicaciones de red, no es práctico, ya que sus usuarios pueden no entender cómo habilitarlo, y puede ser reacio a habilitarlo si creen que es un riesgo de seguridad. UPnP simplemente se refiere a la tecnología que le permite habilitar programáticamente el reenvío de puertos . Desafortunadamente, si está pensando en usar UPnP para reenviar sus aplicaciones de red, tampoco es práctico, ya que UPnP no siempre está disponible y, cuando lo está, puede que no esté activado de manera predeterminada.

Entonces, ¿cuál es la solución? La solución es controlar por proxy todo su tráfico en su propia computadora (que ha preconfigurado cuidadosamente para que sea accesible a nivel mundial) o crear una forma de vencer al sistema. La primera solución es (creo) llamada TURN , y mágicamente resuelve todos los problemas de conectividad a costa de proporcionar una granja de servidores con el ancho de banda disponible. La segunda solución se llama NAT transversal, y es lo que exploraremos a continuación.

Anteriormente, describí el proceso de un servidor externo (digamos google.com) iniciando una conexión a 128.120.196.204 . Dije que, sin el enrutador que tiene reglas específicas para entender a qué computadora reenviar la solicitud de conexión de google, el enrutador simplemente soltará la conexión. Este fue un escenario generalizado y no es preciso porque hay diferentes tipos de NAT. (Nota: Un enrutador es el dispositivo físico real que puede colocar en el suelo. NAT (Traducción de direcciones de red) es un proceso de software programado en el enrutador que ayuda a guardar direcciones IPv4 como árboles). Entonces, dependiendo de qué NAT emplea el enrutador, los escenarios de conexión varían. Un enrutador incluso puede combinar procesos NAT.

Hay cuatro tipos de NAT con comportamiento estandarizado: NAT de cono completo, NAT de cono restringido, NAT de cono con puerto restringido y NAT simétricos. Aparte de estos tipos, puede haber otros tipos de NAT con comportamiento no estandarizado, pero es más raro.

Nota: No estoy muy familiarizado con los NAT ... parece que hay muchas formas de ver los enrutadores, y la información en Internet está muy extendida sobre este tema. Clasificar NATs por conos completos, restringidos y restringidos por el puerto ha sido algo obsoleto, dice Wikipedia. Hay algo que se llama NAT estáticos y dinámicos ... solo un conjunto de varios conceptos que no puedo conciliar juntos. Sin embargo, el siguiente modelo funcionó para mi propia aplicación. Puede obtener más información acerca de los NAT leyendo los enlaces a continuación y más abajo y a lo largo de esta publicación. No puedo publicar más sobre ellos porque realmente no entiendo mucho sobre ellos.

Esperando que algunos gurús de la red corrijan / añadan información, para que todos podamos aprender más sobre este misterioso proceso.

Para responder a su pregunta sobre la recopilación de la IP externa y el puerto de cada cliente:

Los encabezados de todos los paquetes UDP están estructurados de la misma manera con una fuente IP y un puerto fuente. Los encabezados de paquetes UDP no contienen una IP fuente "interna" y una IP fuente "externa". Los encabezados de paquetes UDP solo contienen una dirección IP de origen. Si desea obtener una IP de origen "interna" y "externa", debe enviar la IP de origen interna como parte de su carga útil. Pero no parece que necesite una fuente interna de IP y puerto. Parece que solo necesita una IP y un puerto externos, como indicó su pregunta. Lo que significa que su solución es simplemente leer la IP de origen y el puerto del paquete como los campos que son.

Dos escenarios a continuación (realmente no explican nada más):

Comunicación LAN

La computadora A tiene una LAN IP de 192.168.1.101. La computadora B tiene una LAN IP de 192.168.1.102. La computadora A envía un paquete, desde el puerto 3000, a la computadora B en el puerto 6000. La fuente IP en el paquete UDP será 192.168.1.101. Y esa será la única IP. "Externo" no tiene contexto aquí, porque la red es puramente una red de área local. En este ejemplo, una red de área amplia (como Internet) no existe. Sin embargo, sobre los puertos, porque no estoy seguro acerca de los NAT, no estoy seguro si el puerto inscrito en el paquete será 3000. El dispositivo NAT puede volver a escribir el puerto del paquete de 3000 a algo aleatorio como 49826. De cualquier manera, usted debe usar cualquier puerto inscrito en el paquete para responder, es lo que se supone que debe usar para responder. Por lo tanto, en este ejemplo de comunicación LAN, debe enviar solo una IP: la IP de la LAN, porque eso es todo lo que importa. No tiene que preocuparse por el puerto; el enrutador se ocupa de eso por usted. Cuando recibe el paquete, reúne el único IP y puerto simplemente leyéndolo del paquete.

Comunicación WAN

La computadora A tiene una LAN IP, nuevamente, de 192.168.1.101. La computadora B tiene una LAN IP, nuevamente, de 192.168.1.102. Tanto la Computadora A como la Computadora B compartirán una IP WAN de 128.120.196.204. El servidor S es un servidor, una computadora accesible a nivel mundial en, por ejemplo, un servidor Amazon EC2, con una IP WAN de 1.1.1.1. El servidor S puede tener una IP de LAN, pero es irrelevante. La computadora B también es irrelevante.

La Computadora A envía un paquete, desde el puerto 3000, al Servidor S. Al salir del enrutador, la IP LAN de origen del paquete desde la Computadora A se vuelve a escribir en la IP WAN del enrutador. El enrutador también vuelve a escribir el puerto de origen de 300 a 32981. ¿Qué ve el Servidor S, en términos de la IP y el puerto externos? El servidor S ve 128.120.196.204 como IP, no 192.168.1.101, y el servidor S ve 32981 como el puerto, no 3000. Aunque estos no son los puertos IP y puertos originales que el equipo A usó para enviar el paquete, estas son las direcciones IP correctas y puertos a los que responder Cuando recibe el paquete, solo puede conocer la IP WAN y el puerto reescrito. Si eso es lo que quiere (estaba pidiendo solo la IP y el puerto externos ), entonces está listo. De lo contrario, si también desea la IP interna del remitente, deberá haberla transmitido como datos normales separados de su encabezado.

Código:

Como se indicó anteriormente (a continuación, para responder a su pregunta sobre la recopilación de la IP externa), para recopilar la IP externa y el puerto de cada cliente, simplemente los leyó del paquete. Cada datagrama enviado siempre tiene la fuente IP y el puerto de origen del remitente; ni siquiera necesita un protocolo personalizado sofisticado porque estos dos campos siempre están incluidos; cada paquete UDP debe, por definición, tener estos dos campos.

// Java language // Buffer for receiving incoming data byte[] inboundDatagramBuffer = new byte[1024]; DatagramPacket inboundDatagram = new DatagramPacket(inboundDatagramBuffer, inboundDatagramBuffer.length); // Source IP address InetAddress sourceAddress = inboundDatagram.getAddress(); // Source port int sourcePort = inboundDatagram.getPort(); // Actually receive the datagram socket.receive(inboundDatagram);

Debido a que getAddress() y getPort() pueden devolver el puerto de origen o de destino, dependiendo de lo que establezca que sea, en el equipo cliente (envío), llame a setAddress() y setPort() al servidor (receptor), y en la máquina del servidor (recepción), llame a setAddress() y setPort() vuelta a la máquina del cliente (envío). Debe haber una manera de hacer esto en receive() . Por favor explique si esto ( getAddress() y getPort() no devuelven la IP de origen y el puerto que espera) es su control de ruta real. Esto supone que el servidor es un servidor UDP "estándar" (no es un servidor STUN).

Actualización adicional:

Leí su actualización sobre " cómo usar STUN para tomar la IP y el puerto de un cliente y dárselos a la otra ". Un servidor STUN no está diseñado para intercambiar puntos finales o realizar un cruce de NAT. Un servidor STUN está diseñado para indicarle su IP pública, puerto público y tipo de dispositivo NAT (ya sea un NAT de cono completo, NAT de cono restringido o NAT de cono con puerto restringido). Llamaría al servidor intermediario responsable de intercambiar puntos finales y realizar el recorrido transversal de NAT el "introductor". En mi proyecto personal , en realidad no necesito usar STUN para realizar NAT transversal. Mi "introductor" (el servidor intermediario que presenta los clientes A y B) es un servidor estándar que escucha datagramas UDP. A medida que ambos clientes, A y B, se registran con el introductor, el introductor lee su IP pública, su puerto y su IP privada (en caso de que estén en una LAN). La IP pública se lee del encabezado de datagrama, como para todos los datagramas UDP estándar. La IP privada se escribe como parte de la carga útil del datagrama, y ​​el introductor simplemente la lee como parte de la carga útil. Por lo tanto, sobre la utilidad de STUN, no necesita confiar en STUN para obtener la IP pública y el puerto público de cada uno de sus clientes; cualquier conexión conectada puede indicarle esto. Yo diría que STUN es útil solo para determinar en qué tipo de dispositivo NAT está tu cliente para saber si realizar NAT transversal (si el tipo de dispositivo NAT es Full-Cone, Restricted o Port-Restricted), o para realizar proxying de tráfico TURN total (si el tipo de dispositivo NAT es simétrico).

Explique su bloqueo de ruta: si desea asesoramiento sobre las mejores prácticas para diseñar un protocolo de mensajería de aplicaciones y consejos sobre cómo leer los campos de los mensajes recibidos de forma ordenada y sistemática (según el comentario que publicó a continuación), ¿podría compartir su actual ¿método?

STUN básicamente funciona de la siguiente manera: su cliente detrás del firewall se conecta a un servidor STUN fuera del firewall. El servidor STUN inspecciona el paquete recibido del cliente y envía al cliente una respuesta que contiene la IP del cliente y el puerto tal como aparecen en el servidor STUN.

Así es como el cliente detrás del firewall descubre su propia IP externa y puerto. Por lo que sé, un servidor STUN normalmente no pasa información de dirección de un cliente a otro.

Normalmente STUN se usa para configurar flujos de medios a través de firewalls, cuando el firewall ya está abierto al tráfico de señalización, por ejemplo, en VoIP: el cliente contacta con un servidor STUN para descubrir su propia IP externa y puerto para tráfico UDP, luego envía su solicitud de señalización SIP INVITE o lo que sea) al otro cliente en un puerto abierto bien conocido, incluida su información de dirección UDP externa en la carga útil (SDP o lo que sea). Por lo tanto, en general, un cliente debe ser accesible a través de un puerto abierto para la señalización de comunicación entre pares.

Su pregunta es muy amplia: no puedo ofrecer un ejemplo, pero los siguientes enlaces pueden ser útiles (especificaciones, bibliotecas, muestras, etc.):

Tu problema no está relacionado con Java. Si sabes cómo abrir una conexión UDP, eso es suficiente. Lea el contenido del siguiente link . No tengas miedo por el título, también cubre UDP. El resto es solo codificación Java.

PD : En su escenario, hay un paso que falta. Tanto A como B deben tener una conexión abierta a S, porque S necesita decirle a B que A está intentando alcanzarlo. Si B no tiene una conexión abierta a S, no hay manera de que A y B puedan comenzar a comunicarse entre sí.

ACTUALIZAR

La respuesta hecha por Jason contiene errores y especulaciones alocadas sobre NAT transversal. Uno debe leer el trabajo realizado por Saikat Guha (mpi-sws.org/~francis/imc05-tcpnat.pdf) para comprender realmente este asunto. La clasificación del cono de Wikipedia es completamente obsoleta y engañosa.