De ce listele FTP se blochează în spatele unui gateway VPN care face NAT

Autentificarea și PWD reușesc, dar LIST și RETR se opresc atunci când NAT rescrie doar anteturile. Vedeți unde trebuie să stea ajutorul FTP și cum se repară modul pasiv.

Autentificarea funcționează, PWD funcționează, apoi LIST se blochează până când clientul renunță sau trece la alt mod de date. Această separare este semnătura: conexiunea de control către portul 21 este sănătoasă, în timp ce conexiunea de date este construită dintr-o adresă sau un port pe care cealaltă parte nu îl poate atinge. În spatele unui gateway VPN care face și NAT, vinovatul obișnuit este o comandă FTP al cărei payload numește o adresă de tunel precum 10.8.0.6. Traducerea anteturilor nu atinge niciodată acea valoare.

Urmează de unde vine acea valoare și care cutie are voie să o schimbe.

Se rupe payloadul, nu tunelul

FTP pune punctul final al datelor în interiorul fluxului de control. În modul activ clientul trimite PORT cu propria adresă și propriul port, iar serverul sună înapoi la acea pereche. În modul pasiv serverul răspunde 227 cu o pereche, iar clientul sună acea pereche în schimb.

Ambele forme poartă același tip de afirmație: conectează-te la această adresă, pe acest port. Un dispozitiv care rescrie doar anteturile IP și TCP lasă afirmația neatinsă, așa că o parte continuă să încerce să atingă o adresă care există doar de cealaltă parte a unui tunel. Conexiunea de date se oprește după ce conexiunea de control a fost deja declarată sănătoasă.

Trei moduri, trei payloaduri

Tabelul de mai jos arată cărei părți i se spune să sune și ce poate face un NAT care rescrie doar anteturi în privința asta.

Citiți ultima coloană ca fiind lucrul care eșuează primul. În modul activ serverul este cel care sună o adresă privată; în modul pasiv este clientul; cu FTPS payloadul este text cifrat și cutia intermediară are și mai puțin cu ce lucra.

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

Puneți ajutorul acolo unde se întâmplă traducerea

Pe Linux rescrierea payloadului este făcută de ajutorul nf_conntrack_ftp. Acesta supraveghează conexiunea de control, învață portul negociat, creează o așteptare pentru fluxul de date și, pe o cutie NAT, rescrie adresa și portul din interiorul payloadului. Ajută doar pe dispozitivul care traduce adresa clientului. Încărcarea lui pe client, sau pe un router care doar redirecționează fluxul, nu schimbă nimic în sesiune.

Aceste trei comenzi arată dacă modulul este prezent, dacă este atașat și dacă există o așteptare în timp ce o sesiune este deschisă:

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

Încărcarea modulului nu este același lucru cu atașarea lui. Kernelurile de la 4.7 încoace vin cu net.netfilter.nf_conntrack_helper=0, așa că ajutorul așteaptă o regulă explicită, de exemplu iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Dacă lista de așteptări rămâne goală în timp ce se încearcă un transfer, atașarea este ce trebuie verificat, nu modulul.

Modul pasiv: spuneți serverului ce să anunțe

Modul pasiv este mai ușor de făcut determinist pentru că i se poate spune serverului ce să pună în răspunsul 227. În vsftpd aceasta este pasv_address, împreună cu pasv_min_port și pasv_max_port; ProFTPD folosește MasqueradeAddress și PassivePorts. Setați-le mai întâi, pentru că o adresă anunțată corect elimină nevoia de a rescrie ceva pe partea aceea.

Apoi lăsați exact acel interval de porturi să treacă prin gateway, de exemplu -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, astfel încât regula să corespundă cu ce anunță serverul.

Cele două setări trebuie să fie de acord. Un server căruia i se spune să anunțe 30000-30100 în timp ce gateway-ul permite 40000-40100 eșuează în cel mai nefolositor mod: conversația de control pare sănătoasă și fiecare conexiune de date moare. Comparați numerele înainte de a depana orice altceva.

Două semnături de eșec și ce elimină FTPS

O blocare la LIST indică prima conexiune de date a sesiunii, unde trebuie să funcționeze atât rescrierea adresei, cât și așteptarea. O blocare la RETR după un LIST funcțional indică transferul în sine, adică intervalul pasiv sau MTU-ul tunelului. Acea a doua semnătură nu este o problemă de payload, iar setările ajutorului nu o vor repara.

FTP peste TLS elimină payloadul pe care îl citește ajutorul. O cutie intermediară nu poate rescrie o valoare PORT sau PASV pe care nu o poate decripta, așa că rămân un proxy care termină TLS, un server care anunță o adresă accesibilă într-un interval limitat, sau un alt protocol de transfer.

O ordine scurtă de verificări

Lucrați de la simptom spre exterior. Confirmați că LIST eșuează în timp ce PWD reușește, capturați adresa din interiorul payloadului PORT sau 227 și întrebați ce dispozitiv traduce acea adresă. Atașați ajutorul acolo, urmăriți lista de așteptări în timpul unui transfer, apoi reparați modul pasiv pe server și reflectați intervalul în regula gateway-ului.

Țineți eșecul căii de date separat de eșecul transferului masiv, pentru că duc la setări diferite.

Articole similare