Miért akadnak meg az FTP-listák egy NAT-ot végző VPN-átjáró mögött
A bejelentkezés és a PWD sikerül, a LIST és a RETR viszont megakad, amikor a NAT csak a fejléceket írja át. Nézze meg, hol kell lennie az FTP-segédnek, és hogyan javítható a passzív mód.
A bejelentkezés működik, a PWD működik, majd a LIST megakad, amíg a kliens fel nem adja, vagy át nem vált egy másik adatmódra. Ez a szétválás az ujjlenyomat: a 21-es port felé menő vezérlőkapcsolat egészséges, miközben az adatkapcsolat olyan címről vagy portról épül, amelyet a másik fél nem ér el. Egy NAT-ot is végző VPN-átjáró mögött a szokásos bűnös egy FTP-parancs, amelynek hasznos terhelése olyan alagútcímet nevez meg, mint a 10.8.0.6. A fejlécfordítás soha nem nyúl ehhez az értékhez.
A következők arról szólnak, honnan jön ez az érték, és melyik doboz jogosult megváltoztatni.
A hasznos terhelés törik el, nem az alagút
Az FTP a vezérlőfolyamon belülre teszi az adatok végpontját. Aktív módban a kliens elküldi a PORT-ot a saját címével és portjával, a kiszolgáló pedig visszahívja ezt a párost. Passzív módban a kiszolgáló 227-tel válaszol egy párossal, a kliens pedig helyette azt hívja.
Mindkét forma ugyanolyan állítást hordoz: csatlakozz erre a címre, ezen a porton. Egy eszköz, amely csak az IP- és TCP-fejléceket írja át, érintetlenül hagyja az állítást, így az egyik vég tovább próbál elérni egy címet, amely csak az alagút másik oldalán létezik. Az adatkapcsolat megakad, miután a vezérlőkapcsolatot már egészségesnek nyilvánították.
Három mód, három hasznos terhelés
Az alábbi táblázat megmutatja, melyik felet kérik hívásra, és mit tehet ezzel egy csak fejléceket átíró NAT.
Az utolsó oszlopot úgy olvassa, mint azt, ami először hibázik. Aktív módban a kiszolgáló hív egy privát címet; passzív módban a kliens; FTPS esetén a hasznos terhelés titkosított szöveg, és a köztes doboznak még kevesebb jut.
| Mode | Value in the control stream | Who dials whom | Header-only NAT leaves |
|---|---|---|---|
| Active (PORT) | client address and port | server dials the client | a server dialing an unreachable tunnel address |
| Passive (227) | server address and port | client dials the server | a client dialing an address it cannot route to |
| FTPS | the same values, inside TLS | as above | ciphertext, so no rewrite happens at all |
Tegye a segédet oda, ahol a fordítás történik
Linuxon a hasznos terhelés átírását az nf_conntrack_ftp segéd végzi. Figyeli a vezérlőkapcsolatot, megtanulja a kialkudott portot, várakozást hoz létre az adatfolyamhoz, és NAT-dobozon átírja a hasznos terhelésen belüli címet és portot. Csak azon az eszközön segít, amely a kliens címét fordítja. A kliensre vagy egy csak továbbító útválasztóra betölteni semmit sem változtat a munkameneten.
Ez a három parancs megmutatja, jelen van-e a modul, csatolva van-e, és létezik-e várakozás, miközben egy munkamenet nyitva van:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpA modul betöltése nem ugyanaz, mint csatolása. A 4.7-es és újabb kernelek net.netfilter.nf_conntrack_helper=0 beállítással jönnek, így a segéd kifejezett szabályra vár, például iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Ha a várakozások listája üresen marad egy átvitel kísérlete közben, akkor a csatolást kell vizsgálni, nem a modult.
Passzív mód: mondja meg a kiszolgálónak, mit hirdessen
A passzív módot könnyebb determinisztikussá tenni, mert meg lehet mondani a kiszolgálónak, mit tegyen a 227-es válaszba. A vsftpd-ben ez a pasv_address, a pasv_min_port és pasv_max_port mellett; a ProFTPD a MasqueradeAddress és a PassivePorts beállítást használja. Ezeket először állítsa be, mert egy helyesen hirdetett cím feleslegessé teszi bármi átírását azon az oldalon.
Ezután engedje át pontosan azt a porttartományt az átjárón, például -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, hogy a szabály egyezzen azzal, amit a kiszolgáló hirdet.
A két beállításnak egyeznie kell. Egy kiszolgáló, amelynek azt mondják, hirdessen 30000-30100-at, miközben az átjáró 40000-40100-at engedélyez, a legkevésbé hasznos módon hibázik: a vezérlőbeszélgetés egészségesnek látszik, és minden adatkapcsolat meghal. Hasonlítsa össze a számokat, mielőtt bármi mást hibakeresne.
Két hiba-ujjlenyomat, és mit szüntet meg az FTPS
A LIST megakadása a munkamenet első adatkapcsolatára mutat, ahol a címátírásnak és a várakozásnak is működnie kell. A RETR megakadása egy működő LIST után magára az átvitelre mutat, vagyis a passzív tartományra vagy az alagút MTU-jára. Az a második ujjlenyomat nem hasznos terhelési probléma, és a segéd beállításai nem javítják meg.
Az FTP TLS felett megszünteti a hasznos terhelést, amelyet a segéd olvas. A köztes doboz nem tudja átírni azt a PORT vagy PASV értéket, amelyet nem tud visszafejteni, így marad a TLS-t lezáró proxy, a korlátozott tartományban elérhető címet hirdető kiszolgáló, vagy egy másik átviteli protokoll.
A vizsgálatok rövid sorrendje
A tünettől kifelé haladjon. Erősítse meg, hogy a LIST sikertelen, miközben a PWD sikeres, fogja meg a címet a PORT vagy 227 hasznos terhelésén belül, és kérdezze meg, melyik eszköz fordítja ezt a címet. Csatolja oda a segédet, figyelje a várakozások listáját egy átvitel alatt, majd javítsa a passzív módot a kiszolgálón, és tükrözze a tartományt az átjáró szabályában.
Tartsa külön az adatút hibáját a tömeges átvitel hibájától, mert különböző beállításokhoz vezetnek.