Protokół FTP zakłada, że klient w trybie aktywnym nawiązuje połączenie z dowolnego portu > 1024 (np. 1500 rys.) do portu 21 serwera FTP (jest to połączenie kontrolne, służące do wymiany poleceń). Serwer FTP akceptuje połączenie i tutaj mogą przytrafić się problemy … w momencie gdy klient zażąda danych, serwer FTP inicjuje nowe połączenie z portu 20 na port o 1 wyższy (np. 1501 rys.) niż ten z którego łączył się klient. Jest to połączenie służące do wymiany danych.

Z punktu widzenia firewalla lub routera (NAT) po stronie klienta może to wyglądać to na próbę nawiązania nowego, zupełnie nie powiązanego połączenia z zewnątrz z lokalnym komputerem – takie połączenia są zwykle blokowane.

Ostatnio administrując siecią w firmie, spotkałem się z tym problemem. Klient FTP łączący się z mojej sieci (za NAT’em) w trybie aktywnym był w stanie nawiązać jedynie połączenie z zewnętrznym serwerem na port 21, ale nie był w stanie wykonać poprawnie żadnej komendy wymagającej użycia dodatkowego połączenia służącego do wymiany danych danych.

Po krótkiej analizie problem udało się rozwiązać w dość prosty sposób aktywując odpowiednie moduły w linuksowym kernel’u. Załadowanie modułów umożliwiło pracę iptables (w przypadku wykrycia połączeń FTP) jako stateful firewall. Po nawiązaniu sesji przez klienta FTP, firewall zaczął nadzorować/śledzić stan wszystkich połączeń FTP, dzięki czemu był w stanie wykryć jakie porty zostały wynegocjowane do przesyłu danych oraz umożliwić prawidłową ich transmisję. Tutaj mała uwaga, połączenia typu FTPS nadal nie będą dopuszczane ze względu na zaszyfrowanie komunikacji.

W celu przekonifugurowania systemu wydane zostały polecenia:

modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

Od tej chwili klienci FTP schowani za NAT’em mogli korzystać bez większych przeszkód z aktywnego FTP.
Polecenia z modprobe możemy dodać do pliku rc.local lub do naszego skryptu startowego z regułkami iptables, dzięki czemu moduły będą aktywne po restarcie firewalla lub systemu operacyjnego.