NAT edən VPN şlüzü arxasında FTP siyahıları niyə asılır
Giriş və PWD işləyir, LIST və RETR isə NAT yalnız başlıqları yenidən yazanda dayanır. FTP köməkçisinin harada durmalı olduğunu və passiv rejimin necə düzəldiləcəyini görün.
Giriş işləyir, PWD işləyir, sonra LIST müştəri əl çəkənə və ya başqa məlumat rejiminə keçənə qədər asılır. Bu ayrılma imzadır: 21 portuna nəzarət bağlantısı sağlamdır, məlumat bağlantısı isə qarşı tərəfin çata bilmədiyi ünvandan və ya portdan qurulur. NAT da edən VPN şlüzü arxasında adi səbəb yükü 10.8.0.6 kimi tunel ünvanı adlandıran FTP əmridir. Başlıq tərcüməsi o dəyərə heç vaxt toxunmur.
Bundan sonra o dəyərin haradan gəldiyi və hansı qutunun onu dəyişməyə icazəsi olduğu gəlir.
Qırılan şey yükdür, tunel deyil
FTP məlumat son nöqtəsini nəzarət axınının içərisinə qoyur. Aktiv rejimdə müştəri öz ünvanı və portu ilə PORT göndərir, server də həmin cütlüyə zəng edir. Passiv rejimdə server 227 ilə cütlük cavabı verir, müştəri isə əvəzində ona zəng edir.
Hər iki forma eyni tipli ifadə daşıyır: bu ünvana, bu portdan qoşul. Yalnız IP və TCP başlıqlarını yenidən yazan cihaz ifadəni olduğu kimi buraxır, ona görə bir tərəf yalnız tunelin o biri tərəfində mövcud olan ünvana çatmağa çalışır. Məlumat bağlantısı nəzarət bağlantısı artıq sağlam elan edildikdən sonra dayanır.
Üç rejim, üç yük
Aşağıdakı cədvəl hansı tərəfin zəng etməyə yönəldildiyini və yalnız başlıqları dəyişən NAT-ın buna nə edə bildiyini göstərir.
Son sütunu ilk uğursuz olan şey kimi oxuyun. Aktiv rejimdə şəxsi ünvana zəng edən serverdir; passiv rejimdə müştəridir; FTPS-də isə yük şifrəli mətndir və ara qatın işləyəcəyi daha az şey var.
| 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 |
Köməkçini tərcümənin baş verdiyi yerə qoyun
Linuxda yükün yenidən yazılmasını nf_conntrack_ftp köməkçisi edir. O, nəzarət bağlantısını izləyir, razılaşdırılmış portu öyrənir, məlumat axını üçün gözlənti yaradır və NAT qutusunda yükün içindəki ünvanı və portu yenidən yazır. O yalnız müştəri ünvanını tərcümə edən cihazda kömək edir. Onu müştəridə və ya sadəcə axını ötürən marşrutlaşdırıcıda yükləmək sessiya ilə bağlı heç nəyi dəyişmir.
Bu üç əmr modulun mövcud olub-olmadığını, ona qoşulub-qoşulmadığını və sessiya açıq ikən gözləntinin olub-olmadığını göstərir:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpModulu yükləmək onu qoşmaqla eyni şey deyil. 4.7-dən sonrakı nüvələr net.netfilter.nf_conntrack_helper=0 ilə gəlir, ona görə köməkçi açıq qayda gözləyir, məsələn iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Əgər köçürmə cəhdi zamanı gözləntilər siyahısı boş qalırsa, yoxlanmalı olan modul deyil, qoşulmadır.
Passiv rejim: serverə nəyi elan edəcəyini deyin
Passiv rejimi deterministik etmək daha asandır, çünki serverə 227 cavabına nə qoyacağı deyilə bilər. vsftpd-də bu, pasv_min_port və pasv_max_port ilə birlikdə pasv_address-dir; ProFTPD isə MasqueradeAddress və PassivePorts istifadə edir. Bunları əvvəlcə qurun, çünki düzgün elan edilmiş ünvan o tərəfdə heç nəyi yenidən yazmaq ehtiyacını aradan qaldırır.
Sonra məhz həmin port aralığını şlüzdən keçirin, məsələn -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, ki qayda serverin elan etdiyi ilə uyğun olsun.
İki parametr razılaşmalıdır. 30000-30100 elan etməsi deyilən serverlə 40000-40100 aralığına icazə verən şlüz ən faydasız şəkildə uğursuz olur: nəzarət söhbəti sağlam görünür və hər məlumat bağlantısı ölür. Başqa bir şeyi sazlamadan əvvəl rəqəmləri müqayisə edin.
İki uğursuzluq imzası və FTPS-in aradan qaldırdığı şey
LIST-də asılma sessiyanın ilk məlumat bağlantısına işarə edir, yəni ünvanın yenidən yazılması və gözləntinin hər ikisinin işləməli olduğu yerə. İşləyən LIST-dən sonra RETR-də asılma köçürmənin özünə, yəni passiv aralığa və ya tunel MTU-suna işarə edir. Bu ikinci imza yük problemi deyil və köməkçi parametrləri onu düzəltməyəcək.
TLS üzərindən FTP köməkçinin oxuduğu yükü aradan qaldırır. Ara qat şifrəsini aça bilmədiyi PORT və ya PASV dəyərini yenidən yaza bilməz, ona görə qalan seçimlər TLS-i sonlandıran proksi, məhdud aralıqda çatıla bilən ünvanı elan edən server və ya fərqli ötürmə protokoludur.
Qısa yoxlama sırası
Simptomdan xaricə doğru işləyin. PWD işləyərkən LIST-in uğursuz olduğunu təsdiqləyin, PORT və ya 227 yükünün içindəki ünvanı ələ keçirin və hansı cihazın o ünvanı tərcümə etdiyini soruşun. Köməkçini orada qoşun, bir köçürmə zamanı gözləntilər siyahısını izləyin, sonra serverdə passiv rejimi düzəldin və aralığı şlüz qaydasında əks etdirin.
Məlumat yolu nasazlığını toplu köçürmə nasazlığından ayrı saxlayın, çünki onlar sizi fərqli parametrlərə yönəldir.