NAT хийдэг VPN гарцын ард FTP жагсаалт яагаад гацдаг вэ
Нэвтрэлт болон PWD амжилттай болдог ч NAT зөвхөн толгойг дахин бичих үед LIST болон RETR зогсдог. FTP туслах хаана байх ёстой, идэвхгүй горимыг хэрхэн засахыг үзээрэй.
Нэвтрэлт ажиллана, PWD ажиллана, дараа нь LIST клиент бууж өгөх эсвэл өөр өгөгдлийн горимд шилжих хүртэл гацдаг. Энэ салалт нь яг тэмдэг: 21 порт руу чиглэсэн удирдлагын холболт эрүүл, харин өгөгдлийн холболт нөгөө тал хүрч чадахгүй хаяг эсвэл портоос баригдаж байна. NAT мөн хийдэг VPN гарцын ард ердийн буруутан нь ачаалалдаа 10.8.0.6 шиг туннелийн хаяг нэрлэсэн FTP команд юм. Толгойн орчуулга тэр утгыг хэзээ ч хүрдэггүй.
Дараах нь тэр утга хаанаас ирдэг, аль хайрцаг түүнийг өөрчлөх эрхтэй вэ гэдэг юм.
Эвдрэх нь ачаалал, туннель биш
FTP өгөгдлийн төгсгөлийн цэгийг удирдлагын урсгал дотор байрлуулна. Идэвхтэй горимд клиент өөрийн хаяг, порттой PORT илгээж, сервер тэр хос руу буцаж дуудна. Идэвхгүй горимд сервер хосын хамт 227 хариулж, клиент оронд нь түүнийг дуудна.
Хоёр хэлбэр ижил төрлийн мэдэгдэл агуулна: энэ хаяг руу, энэ портоор холбогдоорой. Зөвхөн IP болон TCP толгойг дахин бичдэг төхөөрөмж мэдэгдлийг хэвээр үлдээдэг тул нэг тал туннелийн нөгөө талд л байдаг хаяг руу хүрэх гэж үргэлжлүүлэн оролддог. Удирдлагын холболтыг эрүүл гэж аль хэдийн зарласны дараа өгөгдлийн холболт зогсдог.
Гурван горим, гурван ачаалал
Доорх хүснэгт аль талд дуудахыг хэлж байгаа, зөвхөн толгойг дахин бичдэг NAT үүнд юу хийж чадахыг харуулна.
Сүүлийн баганыг хамгийн түрүүнд бүтэлгүйтдэг зүйл гэж уншаарай. Идэвхтэй горимд хувийн хаяг руу дуудах нь сервер, идэвхгүй горимд клиент, харин FTPS-д ачаалал нь шифрлэсэн текст тул завсрын хайрцагт ажиллах зүйл улам бага байна.
| 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 |
Туслахыг орчуулга болж буй газарт байрлуул
Linux дээр ачааллыг дахин бичихийг nf_conntrack_ftp туслах хийдэг. Тэр удирдлагын холболтыг ажиглаж, тохиролцсон портыг сурч, өгөгдлийн урсгалд хүлээлт үүсгэж, NAT хайрцаг дээр ачааллын доторх хаяг болон портыг дахин бичдэг. Тэр зөвхөн клиентийн хаягийг орчуулдаг төхөөрөмж дээр тусална. Түүнийг клиент дээр эсвэл урсгалыг зөвхөн дамжуулдаг маршрутлагч дээр ачаалах нь сессэд юу ч өөрчлөхгүй.
Эдгээр гурван команд модуль байгаа эсэх, холбогдсон эсэх, сесс нээлттэй үед хүлээлт байгаа эсэхийг харуулна:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpМодулийг ачаалах нь түүнийг холбохтой ижил биш. 4.7-гоос хойш цөмүүд net.netfilter.nf_conntrack_helper=0-тэй ирдэг тул туслах тодорхой дүрмийг хүлээдэг, жишээ нь iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Шилжүүлэг хийхийг оролдох үед хүлээлтийн жагсаалт хоосон хэвээр байвал шалгах зүйл нь холболт, модуль биш.
Идэвхгүй горим: серверт юу зарлахыг хэлээрэй
Идэвхгүй горимыг детерминатив болгох нь илүү хялбар, учир нь серверт 227 хариултад юу хийхийг хэлж болно. vsftpd-д энэ нь pasv_address бөгөөд pasv_min_port болон pasv_max_port-той хамт; ProFTPD нь MasqueradeAddress болон PassivePorts ашигладаг. Эдгээрийг эхлээд тохируулаарай, учир нь зөв зарласан хаяг тэр талд ямар нэг зүйлийг дахин бичих шаардлагыг арилгана.
Дараа нь яг тэр портын мужийг гарцаар нэвтрүүлээрэй, жишээ нь -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, дүрэм серверийн зарласантай тохирохын тулд.
Хоёр тохиргоо санал нийлэх ёстой. 30000-30100 зарлахыг хэлсэн сервер, гарц 40000-40100-г зөвшөөрвөл хамгийн бага тус болох байдлаар бүтэлгүйтнэ: удирдлагын яриа эрүүл харагдана, бүх өгөгдлийн холболт үхнэ. Өөр юу ч дибаг хийхээс өмнө тоонуудыг харьцуулаарай.
Хоёр бүтэлгүйтлийн тэмдэг, FTPS юуг арилгадаг
LIST дээр гацах нь сессийн эхний өгөгдлийн холболтыг заана, тэнд хаягийн дахин бичилт болон хүлээлт хоёулаа ажиллах ёстой. Ажиллаж буй LIST-ийн дараа RETR дээр гацах нь шилжүүлэг өөрт нь, өөрөөр хэлбэл идэвхгүй муж эсвэл туннелийн MTU-д заана. Тэр хоёр дахь тэмдэг нь ачааллын асуудал биш бөгөөд туслахын тохиргоо үүнийг засахгүй.
TLS дээрх FTP нь туслахын уншдаг ачааллыг арилгана. Завсрын хайрцаг тайлж чадахгүй PORT эсвэл PASV утгыг дахин бичиж чадахгүй тул үлдэх сонголтууд нь TLS-ийг дуусгадаг прокси, хязгаарлагдмал мужид хүрч болох хаяг зарладаг сервер, эсвэл өөр шилжүүлгийн протокол юм.
Шалгалтын товч дараалал
Шинж тэмдгээс гадагш ажиллаарай. PWD амжилттай байхад LIST бүтэлгүйтдэгийг баталж, PORT эсвэл 227 ачааллын доторх хаягийг барьж аваад, аль төхөөрөмж тэр хаягийг орчуулдагийг асуугаарай. Туслахыг тэнд холбоод, нэг шилжүүлгийн үеэр хүлээлтийн жагсаалтыг ажиглаад, дараа нь сервер дээр идэвхгүй горимыг засаж, мужийг гарцын дүрэмд тусгаарай.
Өгөгдлийн замын бүтэлгүйтлийг бөөн шилжүүлгийн бүтэлгүйтлээс тусгаар байлгаарай, учир нь тэд өөр өөр тохиргоо руу хөтөлдөг.