TCP peut-il fournir plus de 65535 ports?

Est-il possible de configurer un système Linux pour qu'il fournisse plus de 65 535 ports? L'intention serait d'avoir plus de 65 000 démons à l'écoute sur un système donné.

Il est clair que des ports sont utilisés, ce qui n’est pas possible pour ces raisons. Considérez-le comme un exercice théorique pour tenter de comprendre en quoi TCP pourrait être restrictif.

En examinant le RFC pour TCP: RFC 793 - Protocole de contrôle de transmission , la réponse semble non, car un en-tête TCP est limité à 16 bits pour le champ du port source / destination.

IPv6 améliore-t-il les choses?

Non. Même si IPv6 nous donnera un espace d'adressage IP beaucoup plus grand, 32 bits par rapport à 128 bits, il ne tente en aucun cas d'améliorer la limitation de 16 bits des paquets TCP pour les numéros de port. Il est intéressant de noter que la spécification RFC pour IPv6: protocole Internet, version 6 (IPv6) , devait élargir le champ IP.

Lorsque TCP s'exécute sur IPv6, la méthode utilisée pour calculer la somme de contrôle est modifiée, conformément à la norme RFC 2460 :

Tout transport ou autre protocole de couche supérieure qui inclut les adresses de l'en-tête IP dans son calcul de somme de contrôle doit être modifié pour être utilisé sur IPv6, afin d'inclure les adresses IPv6 à 128 bits au lieu des adresses IPv4 à 32 bits.

Alors, comment pouvez-vous obtenir plus de ports?

Une approche serait d'empiler des adresses IP supplémentaires en utilisant plus d'interfaces. Si votre système dispose de plusieurs cartes réseau c'est plus facile, mais même avec une seule carte réseau, on peut utiliser des interfaces virtuelles (aka. Des alias ) pour allouer davantage IP si nécessaire.

REMARQUE: l' utilisation d'alias a été supplantée, iproute2ce qui permet d'empiler des adresses IP sur une seule interface (c'est-à-dire eth0).

Exemple

$ 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

Source: iproute2: La vie après ifconfig

Références

• OpenWrt Wiki »Documentation» Mise en réseau »Interfaces réseau Linux
• Une commande utile avec iproute2
• HOWTO Linux sur le routage avancé et le contrôle du trafic
• Plusieurs routes par défaut / IP de passerelle publique sous Linux
• aide-mémoire iproute2 - Le site de Daniil Baturin

Est-il possible de configurer un système Linux pour qu'il fournisse plus de 65 535 ports?

Nan.

L'intention serait d'avoir plus de 65 000 démons à l'écoute sur un système donné.

Alors vous avez besoin de:

• une iptablesconfiguration qui redirige sur le contenu du trafic ou

• un "service broker" ou un "service multiplexeur" qui acceptera les connexions entrantes sur un seul port et l'acheminera vers le démon approprié "derrière lui". Si vous souhaitez que les protocoles standard soient transmis sans modification, vous devrez peut-être implémenter une reconnaissance / reconnaissance de protocole dans ce service multiplexeur, de la même manière qu'un pare-feu IDS ou un pare-feu de couche 7 serait anaylze; tout à fait possible avec la grande majorité des protocoles.

Pour le second élément, vous pouvez concevoir ce service pour gérer plus de 2 ^ 16 "ports" si vous le souhaitez vraiment. Je suis certain que l'impact sur les performances sera minime comparé à la charge de 2 ^ 16 auditeurs en cours d'exécution.

Les démons sous Linux peuvent écouter des sockets Unix qui existent dans le système de fichiers. Votre "service multiplexeur" peut donc conserver un mappage interne du port externe <-> socket Unix interne. Vous rencontrerez probablement une limite de processus du noyau (processus de 32 Ko?) Avant de manquer d’inodes sur tout système de fichiers moderne.

Juste parce qu'il n'y a pas de bonne réponse, je voulais ajouter quelque chose.

Une façon de procéder consiste à ajouter une option IP spécifiant l’extension du port. L'option doit être conçue pour s'inscrire dans la partie facultative de l'en-tête IP et être ignorée par des sauts inconnus.

Vous utiliseriez cette option et ses informations pour étendre la source, la destination ou les deux numéros de port.

Les limitations ne fonctionneront pas automatiquement dans les logiciels existants en ajoutant simplement l'option; elles devront être réécrites pour tirer parti de l'option, quelle que soit la manière dont elle est mise en œuvre. Les logiciels et les pare-feu existants ignoreront le paquet ou le traiteront comme d'habitude. en utilisant la valeur dans les champs de port source et de destination.

En bref, ce n’est pas facile à faire et serait préférable d’utiliser un seul auditeur réutilisable et les données contenues dans la charge utile du paquet.

Vous pouvez également autoriser plus facilement la réutilisation des ports dans le logiciel, ce qui peut aider à surmonter cette limitation en réutilisant les ports du serveur pour plusieurs connexions client.

Rtsp, par exemple, peut utiliser l'en-tête SessionId conjointement avec divers autres en-têtes dans la charge utile du paquet IP pour déterminer la connexion pour laquelle la demande a été émise et agir en conséquence, par exemple si le socket à partir duquel le message a été envoyé est différent de celui du socket. l’adresse distante à laquelle correspond la session, on peut alors autoriser la mise à jour d’une session avec le nouveau socket pour le traitement, nier le message ou effectuer diverses autres actions en fonction de l’application.

Un serveur HTTP peut également faire cela ou tout autre type de serveur.

Lorsque vous autorisez la réutilisation des ports, il est essentiel de garder à l'esprit l'adresse IP source.

Oui, vous pouvez !

Cela a déjà été fait auparavant, par exemple le serveur de cryptage Edgehill, qui compte plus de 25 000 000 démons fonctionnant en ligne.