Kāpēc FTP saraksti karājas aiz VPN vārtejas, kas veic NAT
Pieteikšanās un PWD izdodas, bet LIST un RETR apstājas, kad NAT pārraksta tikai galvenes. Uzziniet, kur jāatrodas FTP palīgam un kā salabot pasīvo režīmu.
Pieteikšanās strādā, PWD strādā, un tad LIST karājas, līdz klients padodas vai pāriet citā datu režīmā. Šī šķelšanās ir pazīme: vadības savienojums uz portu 21 ir vesels, bet datu savienojums tiek būvēts no adreses vai porta, kuru otra puse nevar sasniegt. Aiz VPN vārtejas, kas veic arī NAT, parastais vaininieks ir FTP komanda, kuras lietderīgā slodze nosauc tuneļa adresi, piemēram, 10.8.0.6. Galveņu tulkošana nekad neaizskar šo vērtību.
Turpinājumā – no kurienes šī vērtība nāk un kura kaste drīkst to mainīt.
Lūzt lietderīgā slodze, nevis tunelis
FTP ievieto datu galapunktu vadības plūsmā. Aktīvajā režīmā klients sūta PORT ar savu adresi un portu, un serveris atzvana uz šo pāri. Pasīvajā režīmā serveris atbild ar 227 un pāri, un klients tā vietā zvana uz to.
Abas formas nes to pašu veida apgalvojumu: pievienojies šai adresei, uz šo portu. Ierīce, kas pārraksta tikai IP un TCP galvenes, atstāj apgalvojumu neskartu, tāpēc viena puse turpina mēģināt sasniegt adresi, kas pastāv tikai tuneļa otrā pusē. Datu savienojums apstājas pēc tam, kad vadības savienojums jau pasludināts par veselu.
Trīs režīmi, trīs lietderīgās slodzes
Zemāk esošā tabula parāda, kurai pusei liek zvanīt, un ko ar to var darīt NAT, kas pārraksta tikai galvenes.
Pēdējo kolonnu lasiet kā to, kas sabrūk pirmais. Aktīvajā režīmā uz privātu adresi zvana serveris, pasīvajā – klients, bet FTPS gadījumā lietderīgā slodze ir šifrēts teksts un starpkastei ir vēl mazāk, ar ko strādāt.
| 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 |
Novietojiet palīgu tur, kur notiek tulkošana
Linux sistēmā lietderīgās slodzes pārrakstīšanu veic palīgs nf_conntrack_ftp. Tas uzrauga vadības savienojumu, iemācās saskaņoto portu, izveido gaidījumu datu plūsmai un uz NAT kastes pārraksta adresi un portu lietderīgās slodzes iekšienē. Tas palīdz tikai tajā ierīcē, kas tulko klienta adresi. Ielādēt to klientā vai maršrutētājā, kas tikai pārsūta plūsmu, sesijā neko nemaina.
Šīs trīs komandas parāda, vai modulis ir, vai tas ir piesaistīts un vai gaidījums pastāv, kamēr sesija ir atvērta:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpIelādēt moduli nav tas pats, kas to piesaistīt. Kodoli no 4.7 nāk ar net.netfilter.nf_conntrack_helper=0, tāpēc palīgs gaida skaidru noteikumu, piemēram, iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Ja gaidījumu saraksts paliek tukšs, kamēr tiek mēģināta pārsūtīšana, pārbaudāma ir piesaiste, nevis modulis.
Pasīvais režīms: pasakiet serverim, ko reklamēt
Pasīvo režīmu ir vieglāk padarīt deterministisku, jo serverim var pateikt, ko likt 227 atbildē. vsftpd tas ir pasv_address kopā ar pasv_min_port un pasv_max_port; ProFTPD izmanto MasqueradeAddress un PassivePorts. Iestatiet tos vispirms, jo pareizi reklamēta adrese novērš vajadzību tajā pusē kaut ko pārrakstīt.
Pēc tam laidiet tieši šo portu diapazonu cauri vārtejai, piemēram, -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, lai noteikums atbilstu tam, ko serveris reklamē.
Abiem iestatījumiem jāsaskan. Serveris, kuram likts reklamēt 30000-30100, kamēr vārteja atļauj 40000-40100, sabrūk vismazāk noderīgajā veidā: vadības saruna izskatās vesela un katrs datu savienojums mirst. Salīdziniet skaitļus, pirms labojat ko citu.
Divas kļūmes pazīmes un ko FTPS novērš
Iekāršanās pie LIST norāda uz sesijas pirmo datu savienojumu, kur jāstrādā gan adreses pārrakstīšanai, gan gaidījumam. Iekāršanās pie RETR pēc strādājoša LIST norāda uz pašu pārsūtīšanu, proti, pasīvo diapazonu vai tuneļa MTU. Šī otrā pazīme nav lietderīgās slodzes problēma, un palīga iestatījumi to nesalabos.
FTP virs TLS novērš lietderīgo slodzi, ko lasa palīgs. Starpkaste nevar pārrakstīt PORT vai PASV vērtību, ko tā nevar atšifrēt, tāpēc paliek TLS pabeidzošs starpniekserveris, serveris, kas reklamē sasniedzamu adresi ierobežotā diapazonā, vai cits pārsūtīšanas protokols.
Īsa pārbaužu secība
Strādājiet no simptoma uz āru. Pārliecinieties, ka LIST neizdodas, kamēr PWD izdodas, noķeriet adresi PORT vai 227 lietderīgajā slodzē un pajautājiet, kura ierīce tulko šo adresi. Piesaistiet tur palīgu, vērojiet gaidījumu sarakstu vienas pārsūtīšanas laikā, pēc tam salabojiet pasīvo režīmu serverī un atspoguļojiet diapazonu vārtejas noteikumā.
Turiet datu ceļa kļūmi atsevišķi no masveida pārsūtīšanas kļūmes, jo tās ved pie atšķirīgiem iestatījumiem.