Mirando el RFC para TCP:RFC 793 - Protocolo de control de transmisión, la respuesta parecería ser no debido al hecho de que un encabezado TCP está limitado a 16 bits para el campo de 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, la RFC para IPv6:Protocolo de Internet, Versión 6 (IPv6) Especificación, el campo IP necesitaba expandirse.
Cuando TCP se ejecuta sobre IPv6, el método utilizado para calcular la suma de comprobació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 en 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 utilizando más interfaces. Si su sistema tiene varias NIC, esto es más fácil, pero incluso con una sola NIC, se pueden usar interfaces virtuales (también conocidas como alias) para asignar más IP si es necesario.
iproute2 que puede usar para apilar direcciones IP en una sola interfaz (es decir, eth0 ) en su lugar.
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 de Linux
- Algún comando útil con iproute2
- CÓMO de control de tráfico y enrutamiento avanzado de Linux
- Múltiples rutas predeterminadas / IP de puerta de enlace pública en Linux
- hoja de trucos de 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 65 000 demonios escuchando en un sistema determinado.
Entonces necesitas:
-
un
iptablesconfiguración que redirige en contenido de tráfico o -
un "servicio de agente de servicios" o "servicio multiplexor" que aceptará conexiones entrantes en un solo puerto y las enrutará al demonio apropiado "detrás de él". Si desea que los protocolos estándar pasen sin modificarse, es posible que deba implementar la detección/reconocimiento de protocolos en este servicio multiplexor, de una manera que analizaría un IDS o un firewall de capa 7; completamente posible con la gran mayoría de protocolos.
Según el segundo elemento, podría diseñar este servicio para manejar más de 2^16 "puertos" si realmente quisiera. Estoy seguro de que el impacto en el rendimiento será mínimo en comparación con la carga de más de 2^16 oyentes en ejecución.
Los demonios en Linux pueden estar escuchando en los sockets de Unix que existen en el sistema de archivos, por lo que su "servicio multiplexor" podría mantener un mapeo interno del puerto externo <-> socket interno de Unix. Es probable que se encuentre con un límite de procesos del núcleo (¿procesos de 32 Kbytes?) 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 encajar dentro de la parte opcional del encabezado de IP y sería 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 funcionarán automáticamente en el software existente simplemente agregando la opción de todos modos, deberán reescribirse para aprovechar la opción sin importar cómo se implemente, el software existente y los firewalls ignorarán el paquete o lo procesarán como de costumbre. usando el valor en los campos de puerto de origen y destino.
En resumen, no es fácil de hacer y sería mejor hacerlo usando un solo 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 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, p. si el socket desde el que se entregó el mensaje no es el mismo que la dirección remota del socket a la que corresponde la sesión, entonces se puede permitir que una sesión se actualice con el nuevo socket para su procesamiento, denegar el mensaje o una variedad de otras acciones dependiendo de la aplicación.
Un servidor Http también puede hacer esto o cualquier otro tipo de servidor.
Lo más importante que debe recordar al permitir la reutilización de puertos es que también debe tener en cuenta la dirección IP de origen.