Pse listat FTP varin pas një portali VPN që bën NAT
Hyrja dhe PWD ia dalin, ndërsa LIST dhe RETR ndalen kur NAT rishkruan vetëm titujt. Shihni ku duhet të rrijë ndihmësi FTP dhe si të rregullohet modaliteti pasiv.
Hyrja funksionon, PWD funksionon, dhe më pas LIST varet derisa klienti të dorëzohet ose të kalojë në një modalitet tjetër të dhënash. Kjo ndarje është nënshkrimi: lidhja e kontrollit drejt portës 21 është e shëndetshme, ndërsa lidhja e të dhënave ndërtohet nga një adresë ose port që pala tjetër nuk arrin ta prekë. Pas një portali VPN që bën gjithashtu NAT, fajtori i zakonshëm është një komandë FTP, ngarkesa e së cilës përmend një adresë tuneli si 10.8.0.6. Përkthimi i titujve nuk e prek kurrë atë vlerë.
Ajo që vijon është nga vjen ajo vlerë, dhe cila kuti ka leje ta ndryshojë.
Ajo që thyhet është ngarkesa, jo tuneli
FTP e vendos pikën fundore të të dhënave brenda rrjedhës së kontrollit. Në modalitetin aktiv klienti dërgon PORT me adresën dhe portën e vet, dhe serveri kthehet me telefonatë në atë çift. Në modalitetin pasiv serveri përgjigjet 227 me një çift, dhe klienti telefonon atë në vend të kësaj.
Të dyja format mbartin të njëjtin lloj deklarate: lidhu me këtë adresë, në këtë port. Një pajisje që rishkruan vetëm titujt IP dhe TCP e lë deklaratën ashtu siç është, prandaj njëra anë vazhdon të përpiqet të arrijë një adresë që ekziston vetëm në anën tjetër të një tuneli. Lidhja e të dhënave ndalet pasi lidhja e kontrollit është shpallur tashmë e shëndetshme.
Tre modalitete, tre ngarkesa
Tabela më poshtë tregon cilës palë i thuhet të telefonojë, dhe çfarë mund të bëjë për këtë një NAT që rishkruan vetëm titujt.
Lexojeni kolonën e fundit si gjënë që dështon e para. Në modalitetin aktiv serveri është ai që telefonon një adresë private, në atë pasiv është klienti, ndërsa me FTPS ngarkesa është tekst i shifruar dhe kutia e ndërmjetme ka edhe më pak me çfarë të punojë.
| 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 |
Vendoseni ndihmësin atje ku bëhet përkthimi
Në Linux rishkrimin e ngarkesës e bën ndihmësi nf_conntrack_ftp. Ai vëzhgon lidhjen e kontrollit, mëson portën e negociuar, krijon një pritje për rrjedhën e të dhënave dhe në një kuti NAT rishkruan adresën dhe portën brenda ngarkesës. Ai ndihmon vetëm në pajisjen që përkthen adresën e klientit. Ngarkimi i tij në klient, ose në një ruter që thjesht përcjell rrjedhën, nuk ndryshon asgjë në sesion.
Këto tre komanda tregojnë nëse moduli është i pranishëm, nëse është i lidhur dhe nëse ekziston një pritje ndërsa një sesion është i hapur:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpNgarkimi i modulit nuk është e njëjta gjë me lidhjen e tij. Bërthamat nga 4.7 e tutje vijnë me net.netfilter.nf_conntrack_helper=0, prandaj ndihmësi pret një rregull të shprehur, për shembull iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Nëse lista e pritjeve mbetet bosh ndërsa provohet një transferim, ajo që duhet kontrolluar është lidhja, jo moduli.
Modaliteti pasiv: i thoni serverit çfarë të reklamojë
Modaliteti pasiv bëhet më lehtë deterministik, sepse serverit mund t'i thuhet çfarë të vendosë në përgjigjen 227. Në vsftpd kjo është pasv_address, bashkë me pasv_min_port dhe pasv_max_port; ProFTPD përdor MasqueradeAddress dhe PassivePorts. Vendosini ato së pari, sepse një adresë e reklamuar saktë heq nevojën për të rishkruar çdo gjë në atë anë.
Më pas lini pikërisht atë interval portash të kalojë nëpër portal, për shembull -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, që rregulli të përputhet me atë që reklamon serveri.
Të dy cilësimet duhet të përputhen. Një server që i thuhet të reklamojë 30000-30100 ndërsa portali lejon 40000-40100 dështon në mënyrën më pak të dobishme: biseda e kontrollit duket e shëndetshme dhe çdo lidhje e të dhënave vdes. Krahasoni numrat përpara se të korrigjoni çdo gjë tjetër.
Dy nënshkrime dështimi, dhe çfarë heq FTPS
Varja në LIST tregon lidhjen e parë të të dhënave të sesionit, ku duhet të punojnë si rishkrimi i adresës ashtu edhe pritja. Varja në RETR pas një LIST që funksionon tregon vetë transferimin, pra intervalin pasiv ose MTU-në e tunelit. Nënshkrimi i dytë nuk është problem ngarkese, dhe cilësimet e ndihmësit nuk e rregullojnë.
FTP mbi TLS heq ngarkesën që lexon ndihmësi. Një kuti e ndërmjetme nuk mund të rishkruajë një vlerë PORT ose PASV që nuk mund ta deshifrojë, prandaj mbeten një përfaqësues që përfundon TLS, një server që reklamon një adresë të arritshme brenda një intervali të kufizuar, ose një protokoll tjetër transferimi.
Një rend i shkurtër kontrollesh
Punoni nga simptoma drejt jashtë. Konfirmoni se LIST dështon ndërsa PWD ia del, kapni adresën brenda ngarkesës PORT ose 227, dhe pyesni cila pajisje e përkthen atë adresë. Lidhni ndihmësin atje, vëzhgoni listën e pritjeve gjatë një transferimi, më pas rregulloni modalitetin pasiv në server dhe pasqyroni intervalin në rregullin e portalit.
Mbajeni dështimin e rrugës së të dhënave veçmas nga dështimi i transferimit masiv, sepse të çojnë drejt cilësimeve të ndryshme.