Hay un programa de servidor ejecutándose detrás de un módem / enrutador ADSL doméstico, en una premisa que llamaré C ; el programa escucha en el puerto TCP 29401 y acepta conexiones utilizando un protocolo binario personalizado, no HTTP para intercambiar datos. El enrutador doméstico tiene una función de reenvío de puerto que se ha configurado para permitir la comunicación de Internet con dicho programa (además de HTTP y SSH):

Outer port: TCP 29401
Inner port: TCP 29401
Server address: 192.168.1.196

El módem / enrutador ADSL doméstico tiene una IP pública dinámica en la interfaz externa, y utiliza el rango habitual de 192.168.1.X / 24 de direcciones privadas para la LAN. El servidor está ejecutando un cliente dinámico de actualización automática de IP que mantiene actualizado el registro del Host DNS (A). La IP privada del servidor es 192.168.1.196. Deje que dyn.example.com sea el nombre del dominio DNS dinámico.

Me centraré en un escenario que incluya dos premisas adicionales, a las que llamaré A y B . Estas 3 premisas no están relacionadas y están conectadas de forma independiente a Internet.

Premisa A

Desde la premisa A es posible:

• Navegue por el sitio web correspondiente a dyn.example.com del host virtual en Apache.
• SSH en el servidor utilizando el nombre de host para establecer la conexión
• Un programa cliente para el servidor binario personalizado puede conectarse a dyn.example.com:29401 e intercambiar datos.
• Skype y otro software de VOIP (que utiliza perforaciones de agujeros) funciona correctamente.
• Conéctese a enlace y reciba la página correspondiente.

Premisa B

Desde la premisa B es posible:

• Navegue por el sitio web correspondiente a dyn.example.com del host virtual en Apache.
• No se puede probar SSH, ya que no hay un cliente SSH disponible en la premisa B .
• El mismo programa cliente se bloquea, informando que la conexión fue cerrada por la fuerza por el host remoto. El servidor personalizado no muestra ninguna evidencia de que se haya establecido una conexión en ningún momento.
• Skype y otro software de VOIP (que utiliza perforaciones de agujeros) funciona correctamente.
• Conéctese a enlace y reciba la página correspondiente.

La elección de otros puertos TCP produce el mismo comportamiento.

Pregunta

¿La evidencia sugiere que en la premisa B el tráfico saliente se analiza a nivel de la aplicación en todos los puertos TCP? Todos los puertos pueden salir, pero si intentan hablar utilizando un protocolo diferente al HTTP, el firewall termina la conexión. Para mí esto es sorprendente porque escuché que primero un administrador bloquearía todos los puertos y luego analizaría el tráfico en el puerto 80 para evitar que las aplicaciones usen las técnicas de tunelización HTTP .