Proč se výpisy FTP zaseknou za VPN bránou, která dělá NAT

Přihlášení a PWD projdou, zatímco LIST a RETR se zaseknou, když NAT přepisuje jen hlavičky. Podívejte se, kde musí sedět pomocník FTP a jak opravit pasivní režim.

Přihlášení funguje, PWD funguje, a pak se LIST zasekne, dokud to klient nevzdá nebo nepřejde do jiného režimu přenosu dat. Toto rozdělení je podpis: řídicí spojení na port 21 je zdravé, zatímco datové spojení se staví z adresy nebo portu, na které druhá strana nedosáhne. Za VPN bránou, která také dělá NAT, bývá obvyklým viníkem příkaz FTP, jehož užitečné zatížení jmenuje tunelovou adresu jako 10.8.0.6. Překlad hlaviček se té hodnoty nikdy nedotkne.

Následuje, odkud se ta hodnota bere a která krabice ji smí měnit.

Rozbíjí se užitečné zatížení, ne tunel

FTP vkládá koncový bod dat dovnitř řídicího toku. V aktivním režimu klient pošle PORT se svou vlastní adresou a portem a server zpět volá na tuto dvojici. V pasivním režimu server odpoví 227 s dvojicí a klient místo toho volá tuto dvojici.

Obě podoby nesou stejný typ tvrzení: připoj se na tuto adresu, na tento port. Zařízení, které přepisuje jen hlavičky IP a TCP, nechá tvrzení být, takže jeden konec se dál snaží dosáhnout adresy, která existuje jen na druhé straně tunelu. Datové spojení se zasekne poté, co už bylo řídicí spojení prohlášeno za zdravé.

Tři režimy, tři užitečná zatížení

Tabulka níže ukazuje, které straně se říká, aby volala, a co s tím může udělat NAT, který přepisuje jen hlavičky.

Čtěte poslední sloupec jako věc, která selže první. V aktivním režimu volá na privátní adresu server; v pasivním režimu klient; u FTPS je užitečné zatížení šifrovaný text a prostřední krabice má ještě méně, s čím pracovat.

ModeValue in the control streamWho dials whomHeader-only NAT leaves
Active (PORT)client address and portserver dials the clienta server dialing an unreachable tunnel address
Passive (227)server address and portclient dials the servera client dialing an address it cannot route to
FTPSthe same values, inside TLSas aboveciphertext, so no rewrite happens at all

Umístěte pomocníka tam, kde překlad probíhá

V Linuxu přepis užitečného zatížení dělá pomocník nf_conntrack_ftp. Sleduje řídicí spojení, naučí se vyjednaný port, vytvoří očekávání pro datový tok a na krabici s NAT přepíše adresu a port uvnitř užitečného zatížení. Pomáhá jen na zařízení, které překládá adresu klienta. Načtení na klientovi nebo na routeru, který tok jen předává, na sezení nic nezmění.

Tyto tři příkazy ukazují, zda je modul přítomný, zda je připojený a zda během otevřeného sezení existuje očekávání:

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

Načíst modul není totéž jako ho připojit. Jádra od 4.7 dál přicházejí s net.netfilter.nf_conntrack_helper=0, takže pomocník čeká na výslovné pravidlo, například iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Pokud seznam očekávání zůstane prázdný, zatímco se zkouší přenos, kontrolovat je třeba připojení, ne modul.

Pasivní režim: řekněte serveru, co má inzerovat

Pasivní režim se snáze dělá deterministickým, protože serveru lze říct, co má dát do odpovědi 227. Ve vsftpd je to pasv_address spolu s pasv_min_port a pasv_max_port; ProFTPD používá MasqueradeAddress a PassivePorts. Nastavte to nejdřív, protože správně inzerovaná adresa odstraňuje potřebu cokoli na té straně přepisovat.

Pak pusťte přesně ten rozsah portů přes bránu, například -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, aby pravidlo odpovídalo tomu, co server inzeruje.

Obě nastavení se musí shodovat. Server, kterému se řekne, aby inzeroval 30000-30100, zatímco brána povoluje 40000-40100, selže tím nejméně užitečným způsobem: řídicí rozhovor vypadá zdravě a každé datové spojení umře. Porovnejte čísla, než začnete ladit cokoli jiného.

Dva podpisy selhání a co FTPS odstraňuje

Zaseknutí na LIST ukazuje na první datové spojení sezení, kde musí fungovat jak přepis adresy, tak očekávání. Zaseknutí na RETR po fungujícím LIST ukazuje na samotný přenos, tedy pasivní rozsah nebo MTU tunelu. Druhý podpis není problém užitečného zatížení a nastavení pomocníka ho nespraví.

FTP přes TLS odstraňuje užitečné zatížení, které pomocník čte. Prostřední krabice nemůže přepsat hodnotu PORT nebo PASV, kterou nedokáže dešifrovat, takže zbývají proxy, které ukončí TLS, server, který inzeruje dostupnou adresu v omezeném rozsahu, nebo jiný přenosový protokol.

Krátký sled kontrol

Postupujte od příznaku ven. Potvrďte, že LIST selhává, zatímco PWD uspěje, zachyťte adresu uvnitř zatížení PORT nebo 227 a zeptejte se, které zařízení tu adresu překládá. Připojte tam pomocníka, sledujte seznam očekávání během jednoho přenosu, pak opravte pasivní režim na serveru a zrcadlete rozsah v pravidle brány.

Držte selhání datové cesty oddělené od selhání hromadného přenosu, protože vedou k jiným nastavením.

Související články