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