¿Por qué necesita un servidor STUN Dos IP pública direcciones diferentes

Question

He echó un vistazo para aturdir a la configuración de servidores en openfire, y esta declaración de allí:

"Con el fin de actuar como un servidor STUN, dos direcciones IP públicas diferentes en la misma máquina son necesarios, así como dos números de puerto diferentes para cada IP ".

He investigado en google, y en general los servidores de aturdimiento necesitan dos IP públicas, ¿cuál es la razón para eso?

Answer 1

Porque en algunos casos raros, el comportamiento de la traducción NAT es una función de la dirección IP de destino. Es decir, debe 'hacer ping' dos direcciones IP diferentes para encontrar el comportamiento preciso de la NAT (¿depende o no de la dirección IP de destino?)

Si 'conectó' dos veces el mismo servidor con dos puertos distintos, eso no cubriría este caso adecuadamente (es decir, no estarías cubriendo todas tus bases).

P.S .: No es necesario que las dos direcciones IP estén en el mismo servidor, podrían ser servidores diferentes.

Answer 2

Supongo que es necesario identificar el tipo de NAT que se realiza: algunos NAT usarán la misma dirección IP de origen y codificarán la ID de sesión mediante el número de puerto (creo que se llama cono NAT pero no seguro) , algunos NAT usarán una combinación de IP de origen y puerto para codificar la ID de la sesión. La respuesta que el servidor STUN necesita dar al cliente es diferente en función del tipo de NAT.

Answer 3

Para intentar establecer la conectividad P2P, la solicitud de enlace STUN y la respuesta a/desde la dirección principal del servicio STUN (IP y puerto) es todo lo que realmente importa. La dirección mapeada devuelta en el cuerpo de respuesta de esta solicitud se pasa (a través de XMPP u otro servicio) al nodo remoto con el que el cliente local intenta establecer comunicación directa.

La segunda IP y el puerto que escucha el servicio STUN son útiles para determinar el comportamiento de la asignación de puertos NAT y el comportamiento del filtrado NAT.

Al realizar solicitudes vinculantes al IP: puerto alternativo en el servicio, un cliente puede descubrir si su NAT tiene una semántica de asignación coherente para los puertos locales. En caso de que obtenga diferentes valores de mapeo de puertos para cada prueba, el cliente puede concluir que está detrás de una "NAT simétrica", que es la más difícil de atravesar para P2P.

Al enviar una solicitud de vinculación con un atributo de "solicitud de cambio" que solicita al servicio que responda desde la otra IP o puerto, un cliente puede detectar si su NAT solo filtra datagramas de hosts remotos basados ​​en IP y puerto, o permite datagramas de puertos alternativos en hosts a los que ha enviado datagramas de salida.

El comportamiento de asignación y las pruebas de filtrado solo proporcionan información limitada para conexiones P2P subsiguientes. En el caso de determinar una NAT simétrica entre el servidor e Internet, algunas implementaciones pueden observar que el NAT tiene un valor incremental constante del valor del puerto en cada respuesta de enlace. (por ejemplo, el puerto externo observado por el servicio STUN aumenta en uno). Como tal, el cliente puede ofrecer un IP y un número de puerto adivinado para que el cliente remoto intente enviar en lugar del que se asignó desde la primera solicitud de enlace. O el cliente puede usar esta prueba de comportamiento/filtrado para el registro. O para asignar automáticamente un relevador en caso de NAT simétrica.