Zergatik geratzen diren FTP zerrendak zintzilik NAT egiten duen VPN ate baten atzean
Saio-hasiera eta PWD ondo doaz, LIST eta RETR trabatzen diren bitartean NAT-ak goiburuak soilik berridazten dituenean. Ikusi non egon behar duen FTP laguntzaileak eta nola konpondu modu pasiboa.
Saio-hasierak funtzionatzen du, PWD-k funtzionatzen du, eta orduan LIST zintzilik geratzen da bezeroak amore eman edo beste datu modu batera pasatzen duen arte. Bereizketa hori da sinadura: 21 porturako kontrol konexioa osasuntsu dago, datu konexioa berriz urruneko alderdia iritsi ezin den helbide edo portutik eraikitzen da. NAT ere egiten duen VPN ate baten atzean, errudun ohikoa FTP komando bat izaten da, zeinaren karga erabilgarriak 10.8.0.6 bezalako tunel helbide bat izendatzen duen. Goiburuen itzulpenak ez dio balio horri inoiz ukitzen.
Ondoren dator balio hori nondik datorren eta zein kutxak duen aldatzen duen baimena.
Karga erabilgarria hausten da, ez tunela
FTP-k datuen amaiera puntua kontrol fluxuaren barruan jartzen du. Modu aktiboan bezeroak PORT bidaltzen du bere helbide eta portu propioekin, eta zerbitzariak bikote horri deitzen dio berriz. Modu pasiboan zerbitzariak 227 erantzuten du bikote batekin, eta bezeroak hura deitzen du horren ordez.
Bi formek adierazpen mota bera daramate: konektatu helbide honetara, portu honetan. IP eta TCP goiburuak soilik berridazten dituen gailu batek adierazpena ukitu gabe uzten du, beraz alde batek tunel baten beste aldetik soilik existitzen den helbide batera iristen saiatzen jarraitzen du. Datu konexioa trabatzen da kontrol konexioa osasuntsu deklaratu ondoren.
Hiru modu, hiru karga erabilgarri
Beheko taulak erakusten du zein alderi esaten zaion deitzen, eta zer egin dezakeen goiburuak soilik berridazten dituen NAT batek horren inguruan.
Irakurri azken zutabea lehenengo huts egiten duen gauza bezala. Modu aktiboan zerbitzaria da helbide pribatu batera deitzen duena; modu pasiboan bezeroa da; FTPS-rekin karga erabilgarria testu zifratua da eta tarteko kutxak are gutxiago du lan egiteko.
| 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 |
Jarri laguntzailea itzulpena gertatzen den tokian
Linuxen karga erabilgarriaren berridazketa nf_conntrack_ftp laguntzaileak egiten du. Kontrol konexioa zaintzen du, negoziatu den portua ikasten du, datu fluxurako itxaropen bat sortzen du eta NAT kutxa batean karga erabilgarriaren barruko helbidea eta portua berridazten ditu. Bakarrik laguntzen du bezeroaren helbidea itzultzen duen gailuan. Bezeroan edo fluxua soilik birbidaltzen duen bideratzaile batean kargatzeak ez du ezer aldatzen saioan.
Hiru komando hauek erakusten dute modulua badagoen, erantsita dagoen eta itxaropenik badagoen saio bat irekita dagoen bitartean:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpModulua kargatzea ez da hura erastea bezalakoa. 4.7tik aurrerako nukleoek net.netfilter.nf_conntrack_helper=0 dakarte, beraz laguntzaileak arau esplizitu baten zain egoten da, adibidez iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Itxaropen zerrenda hutsik geratzen bada transferentzia bat saiatzen den bitartean, erasketa da aztertu beharrekoa, ez modulua.
Modu pasiboa: esan zerbitzariari zer iragarri
Modu pasiboa errazagoa da determinista egiten, zerbitzariari esan baitaiteke zer jarri 227 erantzunean. vsftpd-n hori pasv_address da, pasv_min_port eta pasv_max_port-ekin batera; ProFTPD-k MasqueradeAddress eta PassivePorts erabiltzen ditu. Ezarri horiek lehenengo, behar bezala iragarritako helbide batek alde horretan ezer berridazteko beharra kentzen baitu.
Ondoren utzi portu tarte zehatz hori atetatik pasatzen, adibidez -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, arauak zerbitzariak iragartzen duenarekin bat egin dezan.
Bi ezarpenek bat etorri behar dute. 30000-30100 iragartzeko esan zaion zerbitzari batek, atetzak 40000-40100 uzten dituen bitartean, gutxien laguntzen duen moduan huts egiten du: kontrol elkarrizketa osasuntsu dirudi eta datu konexio bakoitza hiltzen da. Konparatu zenbakiak beste ezer araztu aurretik.
Huts egiteko bi sinadura, eta FTPS-k zer kentzen duen
LIST-en zintzilik geratzeak saioko lehen datu konexioari begira jartzen du, non helbidearen berridazketak eta itxaropenak biak lan egin behar duten. LIST funtzionatu ondoren RETR-en zintzilik geratzeak transferentziari berari begira jartzen du, hau da, tarte pasiboari edo tunelaren MTU-ari. Bigarren sinadura hori ez da karga erabilgarriaren arazoa, eta laguntzailearen ezarpenek ez dute konponduko.
TLS gaineko FTP-k laguntzaileak irakurtzen duen karga erabilgarria kentzen du. Tarteko kutxa batek ezin du deszifratu ezin duen PORT edo PASV balio bat berridatzi, beraz geratzen diren aukerak TLS amaitzen duen proxy bat, tarte mugatu batean helbide irisgarri bat iragartzen duen zerbitzari bat edo beste transferentzia protokolo bat dira.
Egiaztapenen ordena laburra
Lan egin sintomaren kanporantz. Egiaztatu LIST-ek huts egiten duela PWD-k arrakasta duen bitartean, harrapatu PORT edo 227 kargaren barruko helbidea, eta galdetu zein gailuk itzultzen duen helbide hori. Erantsi laguntzailea han, begiratu itxaropen zerrenda transferentzia batean zehar, gero konpondu modu pasiboa zerbitzarian eta islatu tartea atetzaren arauan.
Eduki datu bideko hutsa transferentzia masiboko hutsetik bereizita, ezarpen desberdinetara eramaten baitzaituzte.