Bakit nag-hang ang mga listahan ng FTP sa likod ng VPN gateway na gumagawa ng NAT
Nagtutugma ang pag-login at PWD habang natigil ang LIST at RETR kapag hinihimay lamang ng NAT ang mga header. Tingnan kung saan dapat umupo ang helper ng FTP at kung paano ayusin ang passive mode.
Gumagana ang pag-login, gumagana ang PWD, at pagkatapos ay nag-hang ang LIST hanggang sumuko ang kliyente o lumipat sa ibang data mode. Ang paghihiwalay na iyon ang pirma: malusog ang koneksyon ng kontrol sa port 21, habang ang koneksyon ng datos ay itinatayo mula sa address o port na hindi kayang maabot ng kabilang panig. Sa likod ng VPN gateway na gumagawa rin ng NAT, ang karaniwang salarin ay isang utos ng FTP na ang payload ay nagbabanggit ng tunnel address tulad ng 10.8.0.6. Hindi kailanman hinahawakan ng pagsasalin ng header ang halagang iyon.
Ang sumusunod ay kung saan nagmumula ang halagang iyon, at kung aling kahon ang pinapayagang baguhin ito.
Ang nasisira ay ang payload, hindi ang tunnel
Inilalagay ng FTP ang dulong punto ng datos sa loob ng daloy ng kontrol. Sa active mode, nagpapadala ang kliyente ng PORT kasama ang sarili nitong address at port, at tinatawagan ng server ang pares na iyon. Sa passive mode, sumasagot ang server ng 227 na may pares, at ang kliyente ang tumatawag doon sa halip.
Parehong may dalang gayong pahayag ang dalawang anyo: kumonekta sa address na ito, sa port na ito. Ang aparatong naghihimay lamang ng header ng IP at TCP ay iniiwan ang pahayag, kaya patuloy na sinusubukan ng isang panig na maabot ang address na umiiral lamang sa kabilang panig ng tunnel. Natigil ang koneksyon ng datos matapos nang ideklarang malusog ang koneksyon ng kontrol.
Tatlong mode, tatlong payload
Ipinapakita ng talahanayan sa ibaba kung aling panig ang inuutusang tumawag, at kung ano ang magagawa ng NAT na naghihimay lamang ng header tungkol doon.
Basahin ang huling hanay bilang ang bagay na unang nabibigo. Sa active mode, ang server ang tumatawag sa pribadong address; sa passive mode, ang kliyente; sa FTPS, ang payload ay sifradong teksto at mas kakaunti ang maaaring gawin ng gitnang kahon.
| 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 |
Ilagay ang helper kung saan nangyayari ang pagsasalin
Sa Linux, ang helper na nf_conntrack_ftp ang gumagawa ng paghihimay ng payload. Sinusubaybayan nito ang koneksyon ng kontrol, natututuhan ang port na napagkasunduan, gumagawa ng inaasahan para sa daloy ng datos, at sa kahon ng NAT ay hinihimay nito ang address at port sa loob ng payload. Ito ay tumutulong lamang sa aparatong nagsasalin ng address ng kliyente. Ang ikarga ito sa kliyente, o sa router na nagpapasa lamang ng daloy, ay walang binabago sa sesyon.
Ipinapakita ng tatlong utos na ito kung mayroon ang module, kung nakakabit ito, at kung may inaasahan habang bukas ang isang sesyon:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpAng ikarga ang module ay hindi katulad ng pagkabit nito. Ang mga kernel mula 4.7 pataas ay may net.netfilter.nf_conntrack_helper=0, kaya naghihintay ang helper ng malinaw na tuntunin, halimbawa iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Kung nananatiling walang laman ang listahan ng inaasahan habang sinusubukan ang isang paglilipat, ang pagkabit ang dapat suriin, hindi ang module.
Passive mode: sabihin sa server kung ano ang ianunsyo
Mas madaling gawing deterministiko ang passive mode dahil masasabihan ang server kung ano ang ilalagay sa tugon na 227. Sa vsftpd, iyon ay pasv_address, kasama ang pasv_min_port at pasv_max_port; gumagamit ang ProFTPD ng MasqueradeAddress at PassivePorts. Itakda muna ang mga iyon, dahil ang tamang inanunsyong address ay nag-aalis ng pangangailangang himayin ang anuman sa panig na iyon.
Pagkatapos ay hayaang dumaan nang eksakto ang hanay ng port na iyon sa gateway, halimbawa -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, upang tumugma ang tuntunin sa inaanunsyo ng server.
Dapat magkasundo ang dalawang setting. Ang server na inutusang mag-anunsyo ng 30000-30100 habang pinapayagan ng gateway ang 40000-40100 ay nabibigo sa pinaka-walang-tulong paraan: mukhang malusog ang usapan sa kontrol at namamatay ang bawat koneksyon ng datos. Ihambing ang mga numero bago i-debug ang anupaman.
Dalawang pirma ng pagpalya, at ang inaalis ng FTPS
Ang pag-hang sa LIST ay tumutukoy sa unang koneksyon ng datos ng sesyon, kung saan dapat gumana ang parehong paghihimay ng address at ang inaasahan. Ang pag-hang sa RETR pagkatapos ng gumaganang LIST ay tumutukoy sa paglilipat mismo, ibig sabihin ang passive range o ang MTU ng tunnel. Ang ikalawang pirmang iyon ay hindi problema sa payload, at hindi ito maayos ng mga setting ng helper.
Inaalis ng FTP sa ibabaw ng TLS ang payload na binabasa ng helper. Hindi kayang himayin ng gitnang kahon ang halaga ng PORT o PASV na hindi nito kayang i-decrypt, kaya ang natitirang pagpipilian ay isang proxy na nagtatapos ng TLS, isang server na nag-aanunsyo ng maabot na address sa loob ng limitadong hanay, o ibang protocol ng paglilipat.
Isang maikling pagkakasunod-sunod ng mga pagsusuri
Magtrabaho mula sa sintomas pakanluran. Tiyakin na nabibigo ang LIST habang nagtatagumpay ang PWD, hulihin ang address sa loob ng payload ng PORT o 227, at itanong kung aling aparato ang nagsasalin ng address na iyon. Ikabit ang helper doon, obserbahan ang listahan ng inaasahan sa isang paglilipat, pagkatapos ay ayusin ang passive mode sa server at ipamalas ang hanay sa tuntunin ng gateway.
Panatilihing hiwalay ang pagpalya sa landas ng datos mula sa pagpalya sa malawakang paglilipat, dahil dinadala ka nila sa magkaibang setting.