TCP può fornire più di 65535 porte?

Guardando l'RFC per TCP:RFC 793 - Transmission Control Protocol, la risposta sembrerebbe essere no a causa del fatto che un'intestazione TCP è limitata a 16 bit per il campo della porta di origine/destinazione.

IPv6 migliora le cose?

No. Anche se IPv6 ci darà uno spazio di indirizzi IP molto più ampio, 32 bit contro 128 bit, non fa alcun tentativo di migliorare la limitazione del pacchetto TCP di 16 bit per i numeri di porta. È interessante notare che RFC per IPv6:Internet Protocol, versione 6 (IPv6) Specification, il campo IP doveva essere ampliato.

Quando TCP viene eseguito su IPv6, il metodo utilizzato per calcolare il checksum viene modificato, come da RFC 2460:

Qualsiasi trasporto o altro protocollo di livello superiore che includa gli indirizzi dell'intestazione IP nel calcolo del checksum deve essere modificato per l'utilizzo su IPv6, per includere gli indirizzi IPv6 a 128 bit anziché gli indirizzi IPv4 a 32 bit.

Quindi come puoi ottenere più porte?

Un approccio sarebbe quello di impilare ulteriori indirizzi IP utilizzando più interfacce. Se il tuo sistema ha più NIC, questo è più semplice, ma anche con una sola NIC, puoi utilizzare interfacce virtuali (ovvero alias) per allocare più IP, se necessario.

NOTA: Gli alias in uso sono stati soppiantati da iproute2 che puoi utilizzare per impilare gli indirizzi IP su una singola interfaccia (ad esempio eth0 ) invece.

Esempio

$ 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

Fonte:iproute2:Life after ifconfig

Riferimenti

• OpenWrt Wiki » Documentazione » Reti » Interfacce di rete Linux
• Qualche comando utile con iproute2
• HOWTO su Linux Advanced Routing &Traffic Control
• Più route predefinite/IP di gateway pubblici sotto Linux
• cheat sheet di iproute2 - sito web di Daniil Baturin

È possibile configurare un sistema Linux in modo che fornisca più di 65.535 porte?

No.

L'intento sarebbe quello di avere più di 65k demoni in ascolto su un dato sistema.

Allora hai bisogno di:

• un iptables configurazione che reindirizza sul contenuto del traffico o

• un "servizio di broker di servizi" o "servizio multiplexor" che accetterà connessioni in entrata su una singola porta e le instraderà al demone appropriato "dietro di essa". Se si desidera che i protocolli standard passino senza modifiche, potrebbe essere necessario implementare lo sniffing/riconoscimento del protocollo in questo servizio multiplexor, in un modo che un IDS o un firewall di livello 7 analizzerebbe; completamente possibile con la grande maggioranza dei protocolli.

Per il secondo elemento, potresti progettare questo servizio per gestire più di 2 ^ 16 "porte" se lo desideri davvero. Sono sicuro che l'impatto sulle prestazioni sarà minimo rispetto al carico di 2^16+ ascoltatori in esecuzione.

I demoni in Linux possono essere in ascolto su socket unix che esistono nel filesystem, quindi il tuo "servizio multiplexor" potrebbe mantenere una mappatura interna della porta esterna <-> socket unix interno. Probabilmente ti imbatterai in un limite di processo del kernel (processi da 32 Kbyte?) prima di esaurire gli inode su qualsiasi filesystem moderno.

Proprio perché non c'è una buona risposta, volevo intervenire.

Un modo per farlo sarebbe aggiungere un'opzione IP che specifica l'estensione della porta. L'opzione deve essere progettata per rientrare nella parte facoltativa dell'intestazione IP e verrebbe saltata da hop sconosciuti.

Utilizzeresti questa opzione e le sue informazioni per estendere i numeri di porta di origine, destinazione o entrambi.

Le limitazioni non funzioneranno automaticamente nel software esistente semplicemente aggiungendo l'opzione comunque, dovranno essere riscritte per sfruttare l'opzione indipendentemente da come è implementata, il software e i firewall esistenti ignoreranno il pacchetto o lo elaboreranno come al solito utilizzando il valore nei campi della porta di origine e di destinazione.

In breve, non è facile da fare e sarebbe meglio farlo utilizzando un singolo listener riutilizzabile e dati contenuti nel payload del pacchetto.

Puoi anche consentire più facilmente il riutilizzo delle porte nel software, che può aiutare a superare questa limitazione riutilizzando le porte del server per più connessioni client.

Rtsp, ad esempio, può utilizzare l'intestazione SessionId insieme a varie altre intestazioni nel carico utile del pacchetto IP per determinare per quale connessione è stata emessa la richiesta e agire di conseguenza, ad es. se il socket da cui è stato consegnato il messaggio non è lo stesso dell'indirizzo remoto del socket a cui corrisponde la sessione, allora si può consentire l'aggiornamento di una sessione con il nuovo socket per l'elaborazione, negare il messaggio o una varietà di altre azioni a seconda dell'applicazione.

Un server Http può anche fare questo o qualsiasi altro tipo di server.

La cosa fondamentale da ricordare quando si consente il riutilizzo delle porte è che è necessario tenere conto anche dell'indirizzo IP di origine.