Чаму спісы FTP завісаюць за VPN-шлюзам, які робіць NAT

Уваход і PWD працуюць, а LIST і RETR спыняюцца, калі NAT перапісвае толькі загалоўкі. Паглядзіце, дзе мусіць стаяць памочнік FTP і як выправіць пасіўны рэжым.

Уваход працуе, PWD працуе, а потым LIST завісае, пакуль кліент не здасца або не перайдзе ў іншы рэжым даных. Гэтае раздзяленне і ёсць подпіс: кантрольнае злучэнне да порта 21 здаровае, а злучэнне даных будуецца з адраса або порта, да якога той бок не можа дабрацца. За VPN-шлюзам, які таксама робіць NAT, звычайны вінаваты — каманда FTP, у карыснай нагрузцы якой названы тунельны адрас накшталт 10.8.0.6. Пераклад загалоўкаў ніколі не кранае гэтае значэнне.

Далей — адкуль бярэцца гэтае значэнне і якая прылада мае права яго змяніць.

Ламаецца карысная нагрузка, а не тунель

FTP змяшчае канчатковы пункт даных усярэдзіне кантрольнага патоку. У актыўным рэжыме кліент адпраўляе PORT са сваім адрасам і портам, а сервер звяртаецца назад да гэтай пары. У пасіўным рэжыме сервер адказвае 227 з парай, і кліент звяртаецца ўжо да яе.

Абедзве формы нясуць адно і тое ж сцверджанне: злучыся з гэтым адрасам на гэтым порце. Прылада, якая перапісвае толькі загалоўкі IP і TCP, пакідае сцверджанне без змен, таму адзін бок працягвае спрабаваць дабрацца да адраса, які існуе толькі па іншы бок тунеля. Злучэнне даных завісае пасля таго, як кантрольнае злучэнне ўжо абвешчана здаровым.

Тры рэжымы, тры карысныя нагрузкі

Табліца ніжэй паказвае, які бок просяць звяртацца і што можа зрабіць з гэтым NAT, які перапісвае толькі загалоўкі.

Чытайце апошні слупок як тое, што адмаўляе першым. У актыўным рэжыме менавіта сервер звяртаецца да прыватнага адраса; у пасіўным — кліент; а пры FTPS карысная нагрузка — шыфратэкст, і прамежкавай прыладзе застаецца яшчэ менш.

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

Пастаўце памочнік там, дзе адбываецца пераклад

У Linux перапісванне карыснай нагрузкі робіць памочнік nf_conntrack_ftp. Ён назірае за кантрольным злучэннем, вывучае ўзгоднены порт, стварае чаканне для патоку даных і на машыне з NAT перапісвае адрас і порт унутры карыснай нагрузкі. Ён дапамагае толькі на прыладзе, якая перакладае адрас кліента. Загрузка яго на кліенце або на маршрутызатары, які толькі перасылае паток, не змяняе ў сесіі нічога.

Гэтыя тры каманды паказваюць, ці ёсць модуль, ці падключаны ён і ці існуе чаканне, пакуль сесія адкрытая:

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

Загрузіць модуль — не тое ж самае, што падключыць яго. Ядры з 4.7 і далей пастаўляюцца з net.netfilter.nf_conntrack_helper=0, таму памочнік чакае яўнага правіла, напрыклад iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Калі спіс чаканняў застаецца пустым падчас спробы перадачы, правяраць трэба падключэнне, а не модуль.

Пасіўны рэжым: скажыце серверу, што абвяшчаць

Пасіўны рэжым прасцей зрабіць дэтэрмінаваным, бо серверу можна сказаць, што змясціць у адказ 227. У vsftpd гэта pasv_address разам з pasv_min_port і pasv_max_port; ProFTPD выкарыстоўвае MasqueradeAddress і PassivePorts. Задайце гэта першым, бо правільны абвешчаны адрас здымае патрэбу нешта перапісваць на тым баку.

Затым прапусціце менавіта гэты дыяпазон портаў праз шлюз, напрыклад -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, каб правіла адпавядала таму, што абвяшчае сервер.

Дзве налады мусіць узгадняцца. Сервер, якому сказана абвяшчаць 30000-30100, пакуль шлюз дазваляе 40000-40100, адмаўляе самым некарэсным чынам: размова кантролю выглядае здаровай, а кожнае злучэнне даных памірае. Параўнайце лікі, перш чым адладжваць што-небудзь яшчэ.

Два подпісы адмовы і што прыбірае FTPS

Завісанне на LIST паказвае на першае злучэнне даных у сесіі, дзе павінны працаваць і перапісванне адраса, і чаканне. Завісанне на RETR пасля працоўнага LIST паказвае на саму перадачу, гэта значыць пасіўны дыяпазон або MTU тунеля. Гэты другі подпіс — не праблема карыснай нагрузкі, і налады памочніка яго не выправяць.

FTP праз TLS прыбірае карысную нагрузку, якую чытае памочнік. Прамежкавая прылада не можа перапісаць значэнне PORT або PASV, якое не можа расшыфраваць, таму застаюцца проксі, што завяршае TLS, сервер, які абвяшчае дасяжны адрас у абмежаваным дыяпазоне, або іншы пратакол перадачы.

Кароткі парадак праверкі

Ідзіце ад сімптому вонкі. Пацвердзіце, што LIST адмаўляе, пакуль PWD паспявае, злавіце адрас унутры карыснай нагрузкі PORT або 227 і спытайце, якая прылада перакладае гэты адрас. Падключыце памочнік там, назірайце за спісам чаканняў падчас адной перадачы, потым выпраўце пасіўны рэжым на серверы і адлюструйце дыяпазон у правіле шлюза.

Трымайце адмову шляху даных асобна ад адмовы масавай перадачы, бо яны вядуць да розных налад.

Падобныя артыкулы