Czy protokół TCP może zapewnić więcej niż 65535 portów?

Czy można skonfigurować system Linux tak, aby zapewniał ponad 65 535 portów? Chodzi o to, aby ponad 65 000 demonów nasłuchiwało w danym systemie.

Oczywiste jest, że używane są porty, więc nie jest to możliwe z tych powodów, więc pomyśl o tym jako o teoretycznym ćwiczeniu próbującym zrozumieć, gdzie TCP byłby ograniczający w robieniu czegoś takiego.

Patrząc na RFC dla TCP: RFC 793 - Protokół kontroli transmisji , odpowiedź wydaje się być nie, ponieważ nagłówek TCP jest ograniczony do 16 bitów dla pola portu źródłowego / docelowego.

Czy IPv6 poprawia sytuację?

Nie. Mimo że IPv6 da nam znacznie większą przestrzeń adresów IP, 32-bitową w porównaniu do 128-bitowej, nie próbuje poprawić ograniczenia pakietów TCP dla 16-bitowych numerów portów. Co ciekawe, specyfikacja RFC dla IPv6: protokół internetowy, wersja 6 (IPv6) , pole IP wymagało rozszerzenia.

Gdy TCP działa na IPv6, metoda obliczania sumy kontrolnej jest zmieniana zgodnie z RFC 2460 :

Każdy protokół transportowy lub inny górny protokół, który uwzględnia adresy z nagłówka IP w obliczeniach sumy kontrolnej, musi zostać zmodyfikowany do użycia przez IPv6, aby uwzględnić 128-bitowe adresy IPv6 zamiast 32-bitowych adresów IPv4.

Jak więc zdobyć więcej portów?

Jednym z podejść byłoby zestawianie dodatkowych adresów IP za pomocą większej liczby interfejsów. Jeśli twój system ma wiele kart sieciowych, jest to łatwiejsze, ale nawet z jedną kartą sieciową, można skorzystać z interfejsów wirtualnych ( aliasów ), aby w razie potrzeby przydzielić więcej adresów IP.

UWAGA: Zastąpiono użycie aliasów, za pomocą iproute2których można eth0zamiast tego ustawiać adresy IP na jednym interfejsie .

Przykład

$ 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

Źródło: iproute2: Życie po ifconfig

Bibliografia

• OpenWrt Wiki »Dokumentacja» Sieć »Interfejsy sieciowe systemu Linux
• Przydatne polecenie w iproute2
• Linux Zaawansowane routing i kontrola ruchu HOWTO
• Wiele domyślnych tras / publicznych adresów IP bram w systemie Linux
• Ściągawka iproute2 - strona internetowa Daniil Baturin

Czy można skonfigurować system Linux tak, aby zapewniał ponad 65 535 portów?

Nie.

Chodzi o to, aby ponad 65 000 demonów nasłuchiwało w danym systemie.

Potrzebujesz:

• iptableskonfiguracja który przekierowuje na zawartość ruchu lub

• „usługa brokera usług” lub „usługa multipleksera”, która przyjmuje połączenia przychodzące na jednym porcie i kieruje je do odpowiedniego demona „za nim”. Jeśli chcesz, aby standardowe protokoły były niezmodyfikowane, być może będziesz musiał zaimplementować sniffowanie / rozpoznawanie protokołu w tej usłudze multipleksora, w sposób, w jaki zapora ogniowa IDS lub warstwa-7 byłaby anaylze; całkowicie możliwe z ogromną większością protokołów.

Jeśli chodzi o drugi element, możesz zaprojektować tę usługę tak, aby obsługiwała więcej niż 2 ^ 16 „portów”, jeśli naprawdę tego chcesz. Jestem pewien, że wpływ na wydajność będzie minimalny w porównaniu do obciążenia 2 ^ 16 + uruchomionych detektorów.

Demony w systemie Linux mogą nasłuchiwać na gniazdach unix istniejących w systemie plików, więc „usługa multipleksatora” może utrzymywać wewnętrzne mapowanie zewnętrznego portu <-> wewnętrznego gniazda unix. Prawdopodobnie spotkasz się z limitem procesu jądra (procesy 32 Kbyte?), Zanim zabraknie i-węzłów w dowolnym nowoczesnym systemie plików.

Tylko dlatego, że nie ma dobrej odpowiedzi, w którą chciałbym się włączyć.

Jednym ze sposobów na to byłoby dodanie opcji IP, która określa rozszerzenie portu. Opcja musi być zaprojektowana tak, aby pasowała do opcjonalnej części nagłówka IP i byłaby pomijana przez nieznane przeskoki.

Korzystasz z tej opcji i informacji o niej, aby rozszerzyć źródło, miejsce docelowe lub oba numery portów.

Ograniczenia nie będą działały automatycznie w istniejącym oprogramowaniu po prostu poprzez dodanie opcji, będą musiały zostać przepisane, aby skorzystać z opcji bez względu na sposób jej implementacji, istniejące oprogramowanie i zapory ogniowe zignorują pakiet lub przetworzą go jak zwykle przy użyciu wartości w polach portu źródłowego i docelowego.

Krótko mówiąc, nie jest to łatwe i lepiej byłoby to zrobić przy użyciu jednego odbiornika wielokrotnego użytku i danych zawartych w ładunku pakietu.

Możesz także łatwiej zezwolić na ponowne użycie portów w oprogramowaniu, co może pomóc przezwyciężyć to ograniczenie, ponownie wykorzystując porty serwera dla wielu połączeń klienckich.

Rtsp może na przykład używać nagłówka SessionId w połączeniu z różnymi innymi nagłówkami w pakiecie IP, aby określić, dla którego połączenia wysłano żądanie i działać odpowiednio, np. Jeśli gniazdo, z którego wiadomość została dostarczona, nie jest takie samo jak gniazdo zdalny adres, któremu odpowiada sesja, wówczas można zezwolić na aktualizację sesji z nowym gniazdem do przetwarzania, odmówić wiadomości lub szereg innych działań w zależności od aplikacji.

Serwer HTTP może również to zrobić lub dowolny inny typ serwera.

Kluczową rzeczą, o której należy pamiętać przy ponownym użyciu portów, jest to, że należy wziąć pod uwagę źródłowy adres IP.

Tak, możesz !

Dokonano tego wcześniej, na przykład na serwerze szyfrowania Edgehill, który ma ponad 25 000 000 diamonów działających online.