Dlaczego tryb pasywny FTP korzysta z szeregu efemerycznych portów, a nie z jednego dobrze znanego portu? [Zamknięte]

W trybie pasywnym FTP przeczytałem, że serwer wysyła losowy numer portu do klienta, w którym może ustanowić kanał danych.
Następnie klient ustanawia kanał danych od losowego numeru portu do tego numeru portu przesłanego przez serwer.

Moje pytanie brzmi: dlaczego serwer wysyła losowy numer portu do klienta? Dlaczego klient nie może bezpośrednio ustanowić kanału danych do portu nr 20 po stronie serwera?

tcp

— Zefir
źródło

Myślałem, że to nie na temat.

Niestety pytania dotyczące protokołów powyżej warstwy OSI 4 są tutaj nie na temat.

— Ron Maupin

Odpowiedzi:

W ten sposób protokół FTP został zaprojektowany do pracy w trybie pasywnym. Prawdopodobnie nie był to dobry pomysł, ponieważ nie sądzę, aby ten model był kiedykolwiek powtarzany w jakimkolwiek innym protokole (i to jest tym bardziej prawdziwe w przypadku aktywnego trybu FTP).

Na porcie połączenia danych nie ma protokołu. Wszystko, co serwer wie - jedyne, co przenosi jakiekolwiek informacje w tym połączeniu - to numer portu, z którym się łączysz.

Jeśli za każdym razem łączysz się z tym samym portem, serwer nie byłby w stanie stwierdzić, z jakim plikiem się łączysz. Numer portu służy jako łącze między żądaniem transferu połączenia sterującego a połączeniem danych - numer portu jest zawarty w odpowiedzi na PASVpolecenie.

Gdyby dwóch klientów zażądało transferu w tym samym czasie, gdy serwer akceptuje połączenie na jednym porcie, serwer nie byłby w stanie powiedzieć, który plik ma zostać przesłany. Oczywiście, serwer może użyć adresu IP klienta do podjęcia decyzji (w rzeczywistości wiele serwerów FTP sprawdza, czy adres IP klienta odpowiada adresowi IP użytemu w połączeniu kontrolnym, dla bezpieczeństwa).

Ale to nie zadziała dla:

Wiele połączeń z tego samego komputera (większość klientów FTP obsługuje równoległe transfery / kolejki i można faktycznie uruchomić wiele różnych klientów FTP na jednym komputerze);
Połączenie z różnych komputerów w tej samej (korporacyjnej) sieci, ponieważ mają one ten sam zewnętrzny adres IP.

Częściowo skopiowane z mojej odpowiedzi na pytanie: Dlaczego tryb pasywny FTP wymaga zakresu portów, a nie tylko jednego portu? na błąd serwera.

— Martin Prikryl
źródło

Numer portu używany po stronie serwera może również wynosić 20, prawda? W każdej odpowiedzi numer portu po stronie serwera jest inny niż 20

— Zephyr

Moja odpowiedź wyjaśnia, dlaczego numer portu musi być unikalny dla każdego połączenia / transferu. Więc nie można go ustawić na 20.

— Martin Prikryl

Tak, nie można tego naprawić, ale jeden z nich może mieć 20, prawda?

— Zephyr

Tak, ale wszystkie pozostałe porty muszą być powyżej 1024. A z praktycznego punktu widzenia ciągły zakres portów jest lepszy. Większość zapór sieciowych / NAT obsługuje reguły oparte na zakresie. Nie chcesz dodawać specjalnej reguły dla izolowanego portu 20 - również większość serwerów FTP obsługuje tylko ciągły zakres portów.

— Martin Prikryl

@ Zac67 nie, klient otworzy nowe połączenie (oprócz połączenia sterującego), aby pobrać plik w trybie pasywnym, więc serwer nie może użyć numeru portu źródłowego (klienta) do rozróżnienia połączeń klienta. Ponadto NAT często zmienia port źródłowy klienta (i / lub adres IP), czyniąc takie podejście nieużytecznym w praktyce.

— jjmontes

Zazwyczaj serwer nie wysyła losowego portu, ale wolny z określonego (instalacyjnego) zakresu / puli - dla klienta wygląda to losowo. Ten port musi być przekazany do zapory ogniowej, która wymaga zdefiniowania zakresu.

Niestety FTP jest starożytny. Wydaje mi się, że starożytne serwery nie potrafiły rozróżnić sesji danych wielu klientów poza portem. Zasadniczo lepiej jest przejść na bardziej aktualne protokoły, w których wszystko jest starannie spakowane w ramach jednej sesji gniazda.

— Zac67
źródło

Więc może być również 20, prawda? Na każdej stronie numer portu serwera dla danych jest inny niż 20.

— Zephyr

20 to port wychodzący z serwera dla aktywnego FTP (który nie jest już zbyt często używany).

— Zac67

Nie chodziło o to, że starożytne serwery miały problemy, ale o to, że projektanci protokołów wciąż próbowali znaleźć najlepszy sposób na zrobienie rzeczy bardziej skomplikowanej niż prymitywna odpowiedź na żądanie.

— Mark