CloudPanel'de FTP Bağlantı Sorunu ve Çözümü

CloudPanel'de FTP Bağlantı Sorunu: IP'yi Whitelist'e Eklemene Rağmen Neden Bağlanamıyorsun?

Ubuntu üzerinde CloudPanel kullanan bir sunucuda karşılaştığımız ilginç bir FTP bağlantı sorununu ve kök nedenini bu yazıda paylaşıyorum. Aynı sorunu yaşayan biri varsa, aşağıdaki adımlar zamandan kurtaracaktır.

Belirtiler

CloudPanel arayüzünden Security / Firewall Rules bölümüne girip FTP için kendi IP adresimizi whitelist'e ekledik. Buna rağmen FTP client (FileZilla) ile bağlanmaya çalıştığımızda şu hatayı alıyorduk:

Durum: 185.198.XX.XX:21 bağlantısı kuruluyor...
Hata: İşlem 20 saniye içinde yapılamadığından bağlantı kesildi
Hata: Sunucu ile bağlantı kurulamıyor

Yani TCP el sıkışması bile tamamlanmıyordu — connection refused değil, doğrudan timeout. Bu ayrım önemli: refused olsaydı sunucu paketi görüp reddediyor demektir, timeout ise paketin bir yerlerde sessizce çöpe atıldığını (DROP edildiğini) gösterir.

İlk Şüpheliler (ve neden değillerdi)

Sırayla şunları kontrol ettik:

UFW (Uncomplicated Firewall): ufw status ile baktığımızda 21 portu ve passive port aralığı (49152-65534) için kurallar zaten oradaydı, hatta bizim IP'mize özel eklenmişti. Yine de bağlantı kurulamıyordu.

ProFTPD servisi: systemctl status proftpd ile servisin sorunsuz çalıştığını, 21 portunda dinlediğini (ss -tlnp) doğruladık. /etc/vsftpd.conf değil /etc/proftpd/proftpd.conf kullanıldığını (CloudPanel bu sürümde ProFTPD kullanıyor), PassivePorts ve MasqueradeAddress ayarlarının doğru olduğunu gördük. Loglarda hiçbir bağlantı denemesi kaydı bile yoktu — paket sunucu uygulamasına hiç ulaşmıyordu.

Bu ikisi de temizdi. Sorun daha derinde bir yerdeydi.

Kanıt: Paket Geliyor, Cevap Gitmiyor

Sunucuda tcpdump ile port 21'i dinlerken FTP client'tan tekrar bağlanmayı denedik:

bash

sudo tcpdump -i any port 21 -n -c 10

Çıktı çok şey anlatıyordu:

11:05:02 IP 185.198.XX.XX.64786 > 185.198.27.205.21: Flags [S] ...
11:05:03 IP 185.198.XX.XX.64786 > 185.198.27.205.21: Flags [S] ...
11:05:05 IP 185.198.XX.XX.64786 > 185.198.27.205.21: Flags [S] ...

SYN paketleri istemciden geliyor, sunucu tarafında görülüyor (eth0 In), ama hiçbir SYN-ACK dönmüyor. Yani mesele network/routing değil — paket tam olarak sunucuya ulaşıyor ama kernel seviyesinde (iptables/firewall) sessizce düşürülüyor.

Kök Neden: Üç Katmanlı Firewall Çakışması

Sunucuda üç ayrı firewall katmanı aynı anda varmış:

1. UFW — kullanıcı dostu ön yüz, kuralları görünüyordu ama...
2. CloudPanel'in kendi güvenlik arayüzü — panelden eklediğimiz IP kuralları, arka planda clp-agent servisi tarafından iptables'a yazılması gerekiyordu. clp-agent loglarına baktığımızda tekrarlayan bir hata bulduk:

 [FATAL]: database is locked

Bu hata aylardır zaman zaman tekrarlanıyormuş. clp-agent'ı restart etsek bile, panelde eklediğimiz FTP kuralı iptables'a hiç yansımıyordu (iptables -L TALLOW -n -v her seferinde boş dönüyordu).

1. APF (Advanced Policy Firewall) — asıl kör noktamız buradaydı. systemctl status apf "inactive (dead)" gösteriyordu, bu yüzden ilk başta APF'yi devre dışı sandık. Ama /etc/cron.d/apf içinde şunu gördük:

 */10 * * * * root /etc/apf/apf --refresh 0 0 * * * root /etc/apf/apf -r

Yani APF servis olarak "durmuş" görünse de, cron her 10 dakikada bir onun iptables kurallarını yeniden yüklüyordu. Gerçek kural kaynağı APF'ydi, UFW ya da CloudPanel değil.

/etc/apf/conf.apf dosyasına baktığımızda bulmaca çözüldü:

IG_TCP_CPORTS="22,80,443,8443"

Inbound (gelen) TCP portları listesinde 21 hiç yoktu. UFW'de kural olması, CloudPanel panelinde IP whitelist'i eklenmiş olması hiçbir şey ifade etmiyordu, çünkü APF, port 21'i genel politika seviyesinde zaten kapalı tutuyordu ve bu üç sistemin en yetkilisiydi (cron ile periyodik olarak kuralları o yeniden yazıyordu).

Çözüm

IG_TCP_CPORTS listesine FTP portlarını ekleyip APF'yi yeniden yükledik:

bash

sudo cp /etc/apf/conf.apf /etc/apf/conf.apf.bak # önce yedek al
sudo sed -i 's/IG_TCP_CPORTS="22,80,443,8443"/IG_TCP_CPORTS="22,80,443,8443,20,21,49152_65534"/' /etc/apf/conf.apf
sudo /etc/apf/apf -r

(APF'de port aralığı : veya - değil _ ile yazılır — örn. 49152_65534.)

Yeniden yükleme sonrası iptables'ta beklenen ACCEPT kuralları anında oluştu:

ACCEPT tcp dpt:20
ACCEPT tcp dpt:21
ACCEPT tcp dpts:49152:65534

FTP client'tan tekrar bağlandık — sorun çözüldü.

Çıkarımlar

, bir sonraki bağlantı sorununda şu sırayı izlemek zaman kazandırır:

1. Hata mesajının tam olarak timeout mu, connection refused mu olduğuna bak — bu DROP ile REJECT arasındaki farkı, dolayısıyla nerede takıldığını gösterir.
2. Servisin (FTP/SSH/vs.) kendisinin çalışıp dinlediğini doğrula (systemctl status, ss -tlnp).
3. tcpdump ile paketin sunucuya gerçekten ulaşıp ulaşmadığını, cevap dönüp dönmediğini kontrol et.
4. iptables -L INPUT -n -v --line-numbers ile INPUT zincirinin tamamını oku — sadece kendi eklediğin kuralı değil, üstündeki tüm satırları. Sıra önemlidir; DROP kuralı senin ALLOW kuralından önce geliyorsa hiçbir zaman devreye giremezsin.
5. systemctl list-units --type=service ile sunucuda kaç farklı firewall/güvenlik servisi olduğunu gör. "inactive" görünen bir servis, cron üzerinden hâlâ aktif rol oynuyor olabilir — servis durumuna değil, gerçekte kuralları kimin yazdığına bak.
6. Panel arayüzünden yapılan bir değişikliğin gerçekten alt katmana (iptables) yansıdığını her zaman doğrula; arayüz "kural eklendi" dese de arka plan servisi (bizim örnekte clp-agent) bunu senkronize edemiyor olabilir.

Özetle: whitelist'e IP eklemek her zaman yeterli değildir — sorun bazen çok daha temel bir seviyede, portun genel politika olarak kapalı olmasında yatar.