En regardant le RFC pour TCP :RFC 793 - Transmission Control Protocol, la réponse semblerait être non en raison du fait qu'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 contre 128 bits, il n'essaie pas d'améliorer la limitation des paquets TCP de 16 bits pour les numéros de port. Fait intéressant, la RFC pour IPv6 :Internet Protocol, Version 6 (IPv6) Specification, le champ IP devait être élargi.
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 RFC 2460 :
Tout protocole de 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 une utilisation 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 consisterait à empiler des adresses IP supplémentaires en utilisant davantage d'interfaces. Si votre système dispose de plusieurs cartes réseau, cela est plus facile, mais même avec une seule carte réseau, vous pouvez utiliser des interfaces virtuelles (alias. alias) pour allouer plus d'adresses IP si nécessaire.
REMARQUE : L'utilisation d'alias a été remplacée par iproute2 que vous pouvez utiliser pour empiler les adresses IP sur une seule interface (c'est-à-dire eth0 ) à la place.
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 » Réseaux » Interfaces réseau Linux
- Quelques commandes utiles avec iproute2
- Guide pratique du routage avancé et du contrôle du trafic sous Linux
- Plusieurs routes par défaut/IP de passerelle publique sous Linux
- Aide-mémoire iproute2 - Site de Daniil Baturin
Est-il possible de configurer un système Linux pour qu'il fournisse plus de 65 535 ports ?
Non.
L'intention serait d'avoir plus de 65 000 démons à l'écoute sur un système donné.
Ensuite, vous avez besoin :
-
un
iptablesconfiguration qui redirige sur le contenu du trafic ou -
un "service courtier de services" ou "service multiplexeur" qui acceptera les connexions entrantes sur un seul port et les acheminera vers le démon approprié "derrière lui". Si vous souhaitez que les protocoles standard passent sans modification, vous devrez peut-être implémenter le reniflage/la reconnaissance de protocole dans ce service de multiplexeur, d'une manière qu'un IDS ou un pare-feu de couche 7 analyserait ; tout à fait possible avec la grande majorité des protocoles.
Selon le deuxième élément, vous pouvez concevoir ce service pour gérer plus de 2 ^ 16 "ports" si vous le souhaitez vraiment. Je suis sûr que l'impact sur les performances sera minime par rapport à la charge de 2 ^ 16+ auditeurs en cours d'exécution.
Les démons sous Linux peuvent écouter sur les sockets unix qui existent dans le système de fichiers, de sorte que votre "service multiplexeur" puisse maintenir 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 n'importe quel système de fichiers moderne.
Ce n'est pas parce qu'il n'y a pas de bonne réponse que je voulais intervenir.
Une façon de faire serait d'ajouter une option IP qui spécifie l'extension du port. L'option doit être conçue pour tenir dans la partie facultative de l'en-tête IP et serait ignorée par des sauts inconnus.
Vous utiliserez cette option et ses informations d'information pour étendre la source, la destination ou les deux numéros de port.
Les limitations ne fonctionneront pas automatiquement dans les logiciels existants simplement en ajoutant l'option de toute façon, elles devront être réécrites pour tirer parti de l'option, quelle que soit la manière dont elle est implémentée, les logiciels et les pare-feu existants ignoreront le paquet ou le traiteront comme d'habitude en utilisant la valeur dans les champs du port source et de destination.
En bref, ce n'est pas facile à faire et il serait préférable d'utiliser un seul écouteur 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 ex. si la socket à partir de laquelle le message a été livré n'est pas la même que l'adresse distante de la socket à laquelle la session correspond, alors on peut soit autoriser la mise à jour d'une session avec la nouvelle socket pour traitement, soit refuser le message ou une variété d'autres actions selon l'application.
Un serveur HTTP peut également faire cela ou tout autre type de serveur.
L'élément clé à retenir lorsque vous autorisez la réutilisation des ports est que vous devez également prendre en compte l'adresse IP source.