NAT yapan bir VPN geçidinin arkasında FTP listeleri neden askıda kalır
Oturum açma ve PWD başarılı olurken, NAT yalnızca başlıkları yeniden yazdığında LIST ve RETR durur. FTP yardımcısının nerede durması gerektiğini ve pasif modun nasıl düzeltileceğini görün.
Oturum açma çalışıyor, PWD çalışıyor, sonra LIST istemci pes edene veya başka bir veri moduna geçene kadar askıda kalıyor. Bu ayrım imzadır: 21 numaralı bağlantı noktasına giden denetim bağlantısı sağlıklıyken veri bağlantısı, karşı tarafın ulaşamadığı bir adresten veya bağlantı noktasından kuruluyor. Ayrıca NAT yapan bir VPN geçidinin arkasında olağan suçlu, yükünde 10.8.0.6 gibi bir tünel adresi adlandıran FTP komutudur. Başlık çevirisi o değere hiçbir zaman dokunmaz.
Ardından, bu değerin nereden geldiği ve hangi kutunun onu değiştirme yetkisi olduğu gelir.
Bozulan şey tünel değil, yüktür
FTP, verinin uç noktasını denetim akışının içine koyar. Etkin modda istemci kendi adresini ve bağlantı noktasını içeren PORT gönderir, sunucu da o çifte geri arar. Pasif modda sunucu bir çiftle 227 yanıtı verir, istemci ise bunun yerine o çifti arar.
İki biçim de aynı türden bir ifade taşır: bu adrese, bu bağlantı noktasından bağlan. Yalnızca IP ve TCP başlıklarını yeniden yazan bir aygıt ifadeyi öyle bırakır, bu yüzden bir uç yalnızca tünelin karşı tarafında var olan bir adrese ulaşmayı sürdürür. Denetim bağlantısı sağlıklı ilan edildikten sonra veri bağlantısı durur.
Üç mod, üç yük
Aşağıdaki tablo hangi tarafa arama yapmasının söylendiğini ve yalnızca başlıkları yeniden yazan bir NAT'ın bu konuda ne yapabileceğini gösterir.
Son sütunu ilk başarısız olan şey olarak okuyun. Etkin modda özel bir adresi arayan sunucudur; pasif modda istemcidir; FTPS'te yük şifreli metindir ve aradaki kutu için işleyecek daha da az şey vardır.
| 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 |
Yardımcıyı çevirinin gerçekleştiği yere koyun
Linux'ta yükün yeniden yazılmasını yardımcı nf_conntrack_ftp yapar. Denetim bağlantısını izler, görüşülen bağlantı noktasını öğrenir, veri akışı için bir beklenti oluşturur ve bir NAT kutusunda yükün içindeki adresi ve bağlantı noktasını yeniden yazar. Yalnızca istemcinin adresini çeviren aygıtta yardımcı olur. Onu istemciye ya da akışı yalnızca ileten bir yönlendiriciye yüklemek oturumda hiçbir şeyi değiştirmez.
Bu üç komut modülün var olup olmadığını, bağlı olup olmadığını ve oturum açıkken bir beklenti bulunup bulunmadığını gösterir:
modprobe nf_conntrack_ftp
lsmod | grep nf_conntrack_ftp
conntrack -L expect | grep ftpModülü yüklemek onu bağlamakla aynı şey değildir. 4.7 ve sonrası çekirdekler net.netfilter.nf_conntrack_helper=0 ile gelir, bu yüzden yardımcı açık bir kural bekler, örneğin iptables -t raw -A PREROUTING -p tcp --dport 21 -j CT --helper ftp. Bir aktarım denenirken beklenti listesi boş kalıyorsa denetlenmesi gereken modül değil, bağlamadır.
Pasif mod: sunucuya ne duyuracağını söyleyin
Pasif modu belirlenimli kılmak daha kolaydır çünkü sunucuya 227 yanıtına ne koyacağı söylenebilir. vsftpd'de bu pasv_address ile birlikte pasv_min_port ve pasv_max_port'tur; ProFTPD MasqueradeAddress ve PassivePorts kullanır. Önce bunları ayarlayın, çünkü doğru duyurulan bir adres o tarafta herhangi bir şeyi yeniden yazma gereğini ortadan kaldırır.
Sonra tam olarak o bağlantı noktası aralığını geçitten geçirin, örneğin -A FORWARD -i tun0 -p tcp --dport 30000:30100 -j ACCEPT, böylece kural sunucunun duyurduğuyla eşleşsin.
İki ayar birbiriyle uyuşmalıdır. 30000-30100 duyurması söylenen sunucu, geçit 40000-40100'e izin verirken en az yardımcı olacak şekilde başarısız olur: denetim konuşması sağlıklı görünür ve her veri bağlantısı ölür. Başka bir şeyde hata ayıklamadan önce sayıları karşılaştırın.
İki arıza imzası ve FTPS'in ortadan kaldırdığı şey
LIST'te askıda kalma oturumun ilk veri bağlantısına işaret eder; orada hem adresin yeniden yazılması hem de beklenti çalışmalıdır. Çalışan bir LIST'ten sonra RETR'de askıda kalma aktarımın kendisine, yani pasif aralığa veya tünelin MTU'suna işaret eder. Bu ikinci imza bir yük sorunu değildir ve yardımcı ayarları onu düzeltmez.
TLS üzerinden FTP, yardımcının okuduğu yükü ortadan kaldırır. Aradaki kutu şifresini çözemediği PORT veya PASV değerini yeniden yazamaz, bu yüzden geriye TLS'i sonlandıran bir vekil, sınırlı bir aralıkta erişilebilir adres duyuran bir sunucu ya da başka bir aktarım protokolü kalır.
Kısa bir denetim sırası
Belirtiden dışarı doğru çalışın. PWD başarılı olurken LIST'in başarısız olduğunu doğrulayın, PORT veya 227 yükünün içindeki adresi yakalayın ve o adresi hangi aygıtın çevirdiğini sorun. Yardımcıyı oraya bağlayın, bir aktarım sırasında beklenti listesini izleyin, ardından sunucudaki pasif modu düzeltin ve aralığı geçit kuralına yansıtın.
Veri yolu arızasını toplu aktarım arızasından ayrı tutun, çünkü farklı ayarlara götürürler.