¿TCP puede proporcionar más de 65535 puertos?

¿Es posible configurar un sistema Linux para que proporcione más de 65.535 puertos? La intención sería tener más de 65k daemons escuchando en un sistema dado.

Claramente, se están utilizando puertos, por lo que esto no es posible por esas razones, así que piense en esto como un ejercicio teórico para tratar de entender dónde TCP sería restrictivo al hacer algo como esto.

Mirando el RFC para TCP: RFC 793 - Protocolo de control de transmisión , la respuesta parecería no debido al hecho de que un encabezado TCP está limitado a 16 bits para el campo del puerto de origen / destino.

¿IPv6 mejora las cosas?

No. Aunque IPv6 nos dará un espacio de direcciones IP mucho más grande, 32 bits frente a 128 bits, no intenta mejorar la limitación de paquetes TCP de 16 bits para los números de puerto. Curiosamente, el RFC para IPv6: Protocolo de Internet, Especificación de la Versión 6 (IPv6) , el campo de IP necesitaba ser ampliado.

Cuando TCP se ejecuta sobre IPv6, el método utilizado para calcular la suma de verificación cambia, según RFC 2460 :

Cualquier transporte u otro protocolo de capa superior que incluya las direcciones del encabezado IP en su cálculo de suma de verificación debe modificarse para su uso sobre IPv6, para incluir las direcciones IPv6 de 128 bits en lugar de las direcciones IPv4 de 32 bits.

Entonces, ¿cómo puedes obtener más puertos?

Un enfoque sería apilar direcciones IP adicionales usando más interfaces. Si su sistema tiene varias NIC, esto es más fácil, pero incluso con una sola NIC, uno puede utilizar interfaces virtuales (también conocidos como alias ) para asignar más IP si es necesario.

NOTA: El uso de alias ha sido reemplazado por el iproute2cual puede usar para apilar direcciones IP en una sola interfaz (es decir eth0).

Ejemplo

$ sudo ip link set eth0 up
$ sudo ip addr add 192.0.2.1/24 dev eth0
$ sudo ip addr add 192.0.2.2/24 dev eth0
$ ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Fuente: iproute2: Vida después de ifconfig

Referencias

• OpenWrt Wiki »Documentación» Redes »Interfaces de red Linux
• Algún comando útil con iproute2
• COMO de enrutamiento avanzado de Linux y control de tráfico
• Múltiples rutas predeterminadas / IP de puerta de enlace pública en Linux
• hoja de trucos iproute2 - sitio web de Daniil Baturin

¿Es posible configurar un sistema Linux para que proporcione más de 65.535 puertos?

No.

La intención sería tener más de 65k daemons escuchando en un sistema dado.

Entonces necesitas:

• una iptablesconfiguración que redirige en el contenido del tráfico o

• un "servicio de intermediario de servicios" o "servicio multiplexor" que aceptará conexiones entrantes en un solo puerto y lo enrutará al demonio apropiado "detrás de él". Si desea que los protocolos estándar pasen sin modificaciones, es posible que tenga que implementar la detección / reconocimiento de protocolos en este servicio multiplexor, de manera que un IDS o un firewall de capa 7 lo analizarían; completamente posible con la gran mayoría de los protocolos.

Según el segundo elemento, puede diseñar este servicio para manejar más de 2 ^ 16 "puertos" si realmente lo desea. Estoy seguro de que el impacto en el rendimiento será mínimo en comparación con la carga de 2 ^ 16 + oyentes en ejecución.

Los demonios en Linux pueden estar escuchando en sockets unix que existen en el sistema de archivos, por lo que su "servicio multiplexor" podría mantener una asignación interna del puerto externo <-> socket unix interno. Es probable que se encuentre con un límite de proceso de kernel (¿procesos de 32 KB?) Antes de quedarse sin inodos en cualquier sistema de archivos moderno.

Solo porque no hay una buena respuesta, quería intervenir.

Una forma de hacerlo sería agregar una opción de IP que especifique la extensión del puerto. La opción debe estar diseñada para caber dentro de la porción opcional del encabezado IP y debería ser saltada por saltos desconocidos.

Usaría esta opción y su información de información para ampliar el origen, el destino o ambos números de puerto.

Las limitaciones no van a funcionar automáticamente en el software existente simplemente agregando la opción de todos modos, tendrán que reescribirse para aprovechar la opción sin importar cómo se implemente, el software y los firewalls existentes ignorarán el paquete o lo procesarán como de costumbre. utilizando el valor en los campos de puerto de origen y destino.

En resumen, no es fácil de hacer y sería mejor hacerlo utilizando un único oyente reutilizable y los datos contenidos en la carga útil del paquete.

También puede permitir más fácilmente la reutilización de puertos en el software, lo que puede ayudar a superar esta limitación al reutilizar los puertos del servidor para múltiples conexiones de clientes.

Rtsp, por ejemplo, puede usar el encabezado SessionId junto con varios otros encabezados en la carga útil del paquete IP para determinar para qué conexión se emitió la solicitud y actuar en consecuencia, por ejemplo, si el socket desde el que se entregó el mensaje no es el mismo que el del socket dirección remota a la que corresponde la sesión, entonces uno puede permitir que una sesión se actualice con el nuevo socket para procesar, negar el mensaje o una variedad de otras acciones dependiendo de la aplicación.

Un servidor Http también puede hacer este o cualquier otro tipo de servidor.

La clave para recordar al permitir la reutilización de puertos es que también debe tener en cuenta la dirección IP de origen.

Sí tu puedes !

Se ha hecho antes, por ejemplo, el servidor de cifrado Edgehill, que tiene> 25,000,000 deamones ejecutándose en línea.