Зашто 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 и питајте који уређај преводи ту адресу. Прикључите помоћника тамо, посматрајте листу очекивања током једног преноса, затим поправите пасивни режим на серверу и пренесите опсег у правило пролаза.

Држите отказ на путу података одвојено од отказа при масовном преносу, јер воде ка различитим поставкама.

Повезани чланци