Dlaczego listy FTP zawieszają się za bramą VPN, która robi NAT

Logowanie działa, PWD działa, a potem LIST wisi, dopóki klient się nie podda albo nie przejdzie na inny tryb danych. Ten podział jest sygnaturą: połączenie sterujące do portu 21 jest zdrowe, a połączenie danych jest budowane z adresu lub portu, którego druga strona nie może osiągnąć. Za bramą VPN, która też robi NAT, zwykłym winowajcą jest polecenie FTP, którego ładunek wymienia adres tunelu, na przykład 10.8.0.6. Tłumaczenie nagłówków nigdy nie dotyka tej wartości.

Dalej jest to, skąd ta wartość pochodzi i które pudełko może ją zmienić.

Psuje się ładunek, a nie tunel

FTP umieszcza punkt końcowy danych wewnątrz strumienia sterującego. W trybie aktywnym klient wysyła PORT ze swoim adresem i portem, a serwer oddzwania do tej pary. W trybie pasywnym serwer odpowiada 227 z parą, a klient dzwoni do niej zamiast tego.

Obie formy niosą ten sam rodzaj stwierdzenia: połącz się z tym adresem, na tym porcie. Urządzenie, które przepisuje tylko nagłówki IP i TCP, zostawia to stwierdzenie w spokoju, więc jedna strona nadal próbuje dotrzeć do adresu, który istnieje tylko po drugiej stronie tunelu. Połączenie danych staje po tym, jak połączenie sterujące zostało już uznane za zdrowe.

Trzy tryby, trzy ładunki

Tabela poniżej pokazuje, której stronie każe się dzwonić, i co może z tym zrobić NAT przepisujący tylko nagłówki.

Ostatnią kolumnę czytaj jako to, co zawodzi pierwsze. W trybie aktywnym to serwer dzwoni na adres prywatny, w pasywnym robi to klient, a przy FTPS ładunek jest zaszyfrowanym tekstem i pośrednie pudełko ma jeszcze mniej, z czym pracować.

Umieść pomocnika tam, gdzie dzieje się tłumaczenie

W Linuksie przepisywanie ładunku wykonuje pomocnik nf_conntrack_ftp. Obserwuje połączenie sterujące, uczy się wynegocjowanego portu, tworzy oczekiwanie dla przepływu danych i na pudełku NAT przepisuje adres i port wewnątrz ładunku. Pomaga tylko na urządzeniu, które tłumaczy adres klienta. Załadowanie go na kliencie albo na routerze, który jedynie przekazuje przepływ, niczego w sesji nie zmienia.

Te trzy polecenia pokazują, czy moduł jest obecny, czy jest doczepiony i czy istnieje oczekiwanie, gdy sesja jest otwarta:

modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftp

Załadowanie modułu to nie to samo co doczepienie go. Jądra od 4.7 wzwyż przychodzą z net.netfilter.nf_conntrack_helper=0, więc pomocnik czeka na wyraźną regułę, na przykład iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Jeśli lista oczekiwań pozostaje pusta podczas próby transferu, sprawdzić trzeba doczepienie, a nie moduł.

Tryb pasywny: powiedz serwerowi, co ma reklamować

Tryb pasywny łatwiej uczynić deterministycznym, bo serwerowi można powiedzieć, co ma wstawić do odpowiedzi 227. W vsftpd to pasv_address wraz z pasv_min_port i pasv_max_port; ProFTPD używa MasqueradeAddress i PassivePorts. Ustaw je najpierw, bo poprawnie reklamowany adres usuwa potrzebę przepisywania czegokolwiek po tej stronie.

Potem przepuść przez bramę dokładnie ten zakres portów, na przykład -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, żeby reguła zgadzała się z tym, co reklamuje serwer.

Oba ustawienia muszą się zgadzać. Serwer, któremu każe się reklamować 30000-30100, gdy brama pozwala na 40000-40100, zawodzi w najmniej pomocny sposób: rozmowa sterująca wygląda zdrowo i każde połączenie danych umiera. Porównaj liczby, zanim zaczniesz debugować cokolwiek innego.

Dwie sygnatury awarii i co usuwa FTPS

Zawieszenie na LIST wskazuje na pierwsze połączenie danych w sesji, gdzie muszą działać zarówno przepisywanie adresu, jak i oczekiwanie. Zawieszenie na RETR po działającym LIST wskazuje na sam transfer, czyli zakres pasywny lub MTU tunelu. Ta druga sygnatura nie jest problemem ładunku, a ustawienia pomocnika jej nie naprawią.

FTP przez TLS usuwa ładunek, który czyta pomocnik. Pośrednie pudełko nie może przepisać wartości PORT lub PASV, której nie potrafi odszyfrować, więc zostają serwer proxy kończący TLS, serwer reklamujący osiągalny adres w ograniczonym zakresie albo inny protokół transferu.

Krótka kolejność sprawdzeń

Pracuj od objawu na zewnątrz. Potwierdź, że LIST zawodzi, gdy PWD się udaje, przechwyć adres wewnątrz ładunku PORT lub 227 i zapytaj, które urządzenie tłumaczy ten adres. Doczep tam pomocnika, obserwuj listę oczekiwań podczas jednego transferu, potem napraw tryb pasywny na serwerze i odzwierciedl zakres w regule bramy.

Trzymaj awarię ścieżki danych osobno od awarii transferu masowego, bo prowadzą do różnych ustawień.