Prečo sa zoznamy FTP zaseknú za VPN bránou, ktorá robí NAT

Prihlásenie funguje, PWD funguje, a potom sa LIST zasekne, kým to klient nevzdá alebo neprejde do iného režimu dát. Toto rozdelenie je podpis: riadiace spojenie na port 21 je zdravé, kým dátové spojenie sa stavia z adresy alebo portu, na ktoré druhá strana nedosiahne. Za VPN bránou, ktorá tiež robí NAT, býva obvyklým vinníkom príkaz FTP, ktorého užitočné zaťaženie menuje tunelovú adresu ako 10.8.0.6. Preklad hlavičiek sa tej hodnoty nikdy nedotkne.

Nasleduje, odkiaľ sa tá hodnota berie a ktorá krabica ju smie meniť.

Rozbíja sa užitočné zaťaženie, nie tunel

FTP vkladá koncový bod dát dovnútra riadiaceho toku. V aktívnom režime klient pošle PORT so svojou vlastnou adresou a portom a server spätne volá na túto dvojicu. V pasívnom režime server odpovie 227 s dvojicou a klient namiesto toho volá túto dvojicu.

Obe podoby nesú rovnaký typ tvrdenia: pripoj sa na túto adresu, na tento port. Zariadenie, ktoré prepisuje iba hlavičky IP a TCP, nechá tvrdenie tak, takže jeden koniec sa ďalej snaží dosiahnuť adresu, ktorá existuje len na druhej strane tunela. Dátové spojenie sa zasekne potom, čo už bolo riadiace spojenie vyhlásené za zdravé.

Tri režimy, tri užitočné zaťaženia

Tabuľka nižšie ukazuje, ktorej strane sa káže volať, a čo s tým môže urobiť NAT, ktorý prepisuje iba hlavičky.

Čítajte posledný stĺpec ako vec, ktorá zlyhá prvá. V aktívnom režime volá na privátnu adresu server, v pasívnom klient, a pri FTPS je užitočné zaťaženie šifrovaný text a prostredná krabica má ešte menej, s čím pracovať.

Umiestnite pomocníka tam, kde preklad prebieha

V Linuxe prepis užitočného zaťaženia robí pomocník nf_conntrack_ftp. Sleduje riadiace spojenie, naučí sa vyjednaný port, vytvorí očakávanie pre dátový tok a na krabici s NAT prepíše adresu a port vnútri užitočného zaťaženia. Pomáha len na zariadení, ktoré prekladá adresu klienta. Načítanie na klientovi alebo na routeri, ktorý tok len ďalej posiela, na sedení nič nemení.

Tieto tri príkazy ukazujú, či je modul prítomný, či je pripojený a či počas otvoreného sedenia existuje očakávanie:

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

Načítať modul nie je to isté ako ho pripojiť. Jadrá od 4.7 ďalej prichádzajú s net.netfilter.nf_conntrack_helper=0, takže pomocník čaká na výslovné pravidlo, napríklad iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Ak zoznam očakávaní zostane prázdny, kým sa skúša prenos, kontrolovať treba pripojenie, nie modul.

Pasívny režim: povedzte serveru, čo má inzerovať

Pasívny režim sa ľahšie robí deterministickým, pretože serveru možno povedať, čo má dať do odpovede 227. Vo vsftpd je to pasv_address spolu s pasv_min_port a pasv_max_port; ProFTPD používa MasqueradeAddress a PassivePorts. Nastavte to najprv, pretože správne inzerovaná adresa odstraňuje potrebu čokoľvek na tej strane prepisovať.

Potom pusťte presne ten rozsah portov cez bránu, napríklad -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, aby pravidlo zodpovedalo tomu, čo server inzeruje.

Obe nastavenia sa musia zhodovať. Server, ktorému sa povie, aby inzeroval 30000-30100, kým brána povoľuje 40000-40100, zlyhá tým najmenej užitočným spôsobom: riadiaci rozhovor vyzerá zdravo a každé dátové spojenie zomrie. Porovnajte čísla, skôr než začnete ladiť čokoľvek iné.

Dva podpisy zlyhania a čo FTPS odstraňuje

Zaseknutie na LIST ukazuje na prvé dátové spojenie sedenia, kde musia fungovať aj prepis adresy, aj očakávanie. Zaseknutie na RETR po fungujúcom LIST ukazuje na samotný prenos, teda pasívny rozsah alebo MTU tunela. Druhý podpis nie je problém užitočného zaťaženia a nastavenia pomocníka ho nespravia.

FTP cez TLS odstraňuje užitočné zaťaženie, ktoré pomocník číta. Prostredná krabica nemôže prepísať hodnotu PORT alebo PASV, ktorú nedokáže dešifrovať, takže zostávajú proxy, ktoré ukončí TLS, server, ktorý inzeruje dostupnú adresu v obmedzenom rozsahu, alebo iný prenosový protokol.

Krátky sled kontrol

Postupujte od príznaku von. Potvrďte, že LIST zlyháva, kým PWD uspeje, zachyťte adresu vnútri zaťaženia PORT alebo 227 a spýtajte sa, ktoré zariadenie tú adresu prekladá. Pripojte tam pomocníka, sledujte zoznam očakávaní počas jedného prenosu, potom opravte pasívny režim na serveri a zrkadlite rozsah v pravidle brány.

Držte zlyhanie dátovej cesty oddelene od zlyhania hromadného prenosu, pretože vedú k iným nastaveniam.