Защо списъците на 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 и попитайте кое устройство превежда този адрес. Прикачете помощника там, наблюдавайте списъка с очаквания по време на един трансфер, после поправете пасивния режим на сървъра и отразете диапазона в правилото на шлюза.

Дръжте отказа по пътя на данните отделно от отказа при масов трансфер, защото те водят до различни настройки.

Подобни статии