Zašto FTP liste vise iza VPN pristupnika koji radi NAT
Prijava i PWD prolaze, a LIST i RETR staju kada NAT prepisuje samo zaglavlja. Pogledajte gdje mora stajati FTP pomoćnik i kako popraviti pasivni način.
Prijava radi, PWD radi, a zatim LIST visi dok klijent ne odustane ili ne pređe u drugi način rada s podacima. Ta podjela je potpis: kontrolna veza prema portu 21 je zdrava, dok se veza za podatke gradi s adrese ili porta do kojeg druga strana ne može doći. Iza VPN pristupnika koji također radi NAT, uobičajeni krivac je FTP naredba čiji korisni teret imenuje tunelsku adresu poput 10.8.0.6. Prevod zaglavlja nikada ne dira tu vrijednost.
Slijedi odakle ta vrijednost dolazi i koja je kutija smije mijenjati.
Ono što se kvari je korisni teret, a ne tunel
FTP stavlja odredište podataka unutar kontrolnog toka. U aktivnom načinu klijent šalje PORT s vlastitom adresom i portom, a poslužitelj uzvraća poziv na taj par. U pasivnom načinu poslužitelj odgovara 227 s parom, a klijent umjesto toga poziva taj par.
Oba oblika nose istu vrstu izjave: spoji se na ovu adresu, na ovaj port. Uređaj koji prepisuje samo IP i TCP zaglavlja ostavlja izjavu na miru, pa jedan kraj stalno pokušava doći do adrese koja postoji samo s druge strane tunela. Veza za podatke staje nakon što je kontrolna veza već proglašena zdravom.
Tri načina, tri korisna tereta
Tabela ispod pokazuje kojoj se strani nalaže da poziva i šta NAT koji prepisuje samo zaglavlja može učiniti u vezi s tim.
Zadnju kolonu čitajte kao stvar koja prva zakaže. U aktivnom načinu poslužitelj je taj koji poziva privatnu adresu; u pasivnom načinu to je klijent; kod FTPS-a korisni teret je šifrirani tekst i posredni uređaj ima još manje s čime raditi.
| 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 |
Postavite pomoćnik tamo gdje se prevod događa
Na Linuxu prepisivanje korisnog tereta radi pomoćnik nf_conntrack_ftp. On nadgleda kontrolnu vezu, nauči port koji je dogovoren, stvori očekivanje za tok podataka i na NAT kutiji prepisuje adresu i port unutar korisnog tereta. On pomaže samo na uređaju koji prevodi adresu klijenta. Učitavanje na klijentu ili na usmjerivaču koji samo prosljeđuje tok ne mijenja ništa u sesiji.
Ove tri naredbe pokazuju je li modul prisutan, je li priključen i postoji li očekivanje dok je sesija otvorena:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpUčitati modul nije isto što i priključiti ga. Jezgre od 4.7 nadalje dolaze s net.netfilter.nf_conntrack_helper=0, pa pomoćnik čeka izričito pravilo, na primjer iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Ako lista očekivanja ostane prazna dok se pokušava prijenos, priključak je ono što treba provjeriti, a ne modul.
Pasivni način: recite poslužitelju šta da oglašava
Pasivni način je lakše učiniti determinističkim jer se poslužitelju može reći šta da stavi u odgovor 227. U vsftpd to je pasv_address, zajedno s pasv_min_port i pasv_max_port; ProFTPD koristi MasqueradeAddress i PassivePorts. Postavite to prvo, jer ispravna oglašena adresa uklanja potrebu da se bilo šta prepisuje na toj strani.
Zatim pustite točno taj raspon portova kroz pristupnik, na primjer -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, da se pravilo poklopi s onim što poslužitelj oglašava.
Dvije postavke moraju se slagati. Poslužitelj kojem se kaže da oglašava 30000-30100 dok pristupnik dopušta 40000-40100 zakaže na najnekorisniji način: kontrolni razgovor izgleda zdravo i svaka veza za podatke umire. Uporedite brojeve prije nego što išta drugo budete otklanjali.
Dva potpisa kvara i šta FTPS uklanja
Visanje na LIST upućuje na prvu vezu za podatke u sesiji, gdje i prepisivanje adrese i očekivanje moraju raditi. Visanje na RETR nakon radnog LIST-a upućuje na sam prijenos, što znači pasivni raspon ili MTU tunela. Taj drugi potpis nije problem korisnog tereta i postavke pomoćnika ga neće popraviti.
FTP preko TLS-a uklanja korisni teret koji pomoćnik čita. Posredni uređaj ne može prepisati PORT ili PASV vrijednost koju ne može dešifrirati, pa ostaju proxy koji prekida TLS, poslužitelj koji oglašava dostupnu adresu u ograničenom rasponu, ili drugi protokol prijenosa.
Kratak redoslijed provjera
Radite od simptoma prema van. Potvrdite da LIST zakaže dok PWD uspijeva, uhvatite adresu unutar PORT ili 227 tereta i pitajte koji uređaj prevodi tu adresu. Priključite pomoćnik tamo, gledajte listu očekivanja tijekom jednog prijenosa, zatim popravite pasivni način na poslužitelju i preslikajte raspon u pravilu pristupnika.
Držite kvar na putu podataka odvojeno od kvara masovnog prijenosa, jer vas vode na različite postavke.