Güvenlik Duvarı Kaynaklı Bağlantı Sorunlarını Giderme
Üretim ortamında bir uygulama aniden bağlantı kabul etmeyi durursa, ilk bakışta ağ altyapısı, uygulama yapılandırması veya sunucu kaynakları akla gelir. Ancak çoğu zaman suçlu, sessiz sedasız çalışan güvenlik duvarı kurallarıdır. Firewall kaynaklı sorunlar sinir bozucudur çünkü genellikle hiçbir hata mesajı üretmezler, bağlantı sadece sessizce zaman aşımına uğrar. Bu yazıda hem Linux (iptables/nftables/firewalld) hem de Windows Firewall üzerindeki güvenlik duvarı sorunlarını nasıl tespit edeceğinizi ve çözeceğinizi gerçek dünya senaryolarıyla anlatacağım.
Güvenlik Duvarı Sorunlarının Belirtileri
Firewall kaynaklı bir sorunu diğer ağ sorunlarından ayırt etmek için birkaç tipik belirti vardır:
- Bağlantı zaman aşımı (Connection Timeout): Bağlantı reddedilmiyor, sadece yanıt gelmiyor. Bu genellikle paketin DROP edildiğinin işaretidir.
- Connection Refused: Port açık değil veya firewall REJECT kuralı uyguluyor. Burada hemen hata dönüyor.
- Tek yönlü iletişim: Ping çalışıyor ama belirli bir port üzerinden bağlantı kurulamıyor.
- Aynı sunucudaki bazı portlar çalışırken diğerleri çalışmıyor: Port bazlı kural problemi.
- Belirli IP’lerden erişim çalışırken diğerlerinden çalışmıyor: IP bazlı kural problemi.
Linux Tarafında Temel Araçlar
iptables ile Durum Kontrolü
Önce mevcut firewall kurallarını görmek gerekiyor. En temel kontrol şu:
# Tüm zincirleri ve kuralları listele
sudo iptables -L -v -n
# Sadece belirli bir zinciri listele
sudo iptables -L INPUT -v -n
# Satır numaralarıyla birlikte göster (kural silmek için gerekli)
sudo iptables -L INPUT -v -n --line-numbers
# NAT tablosunu kontrol et
sudo iptables -t nat -L -v -nBuradaki -v detaylı çıktı, -n DNS çözümlemesi yapmadan sayısal IP gösterimi, -L listeleme anlamına gelir. DNS çözümlemesi olmadan çalışmak önemlidir çünkü büyük kural setlerinde her IP için DNS sorgusu yapılırsa komut dakikalarca sürebilir.
Paket sayaçlarına dikkat edin. Eğer bir DROP kuralının paketi sayacı sürekli artıyorsa, o kural aktif olarak paket düşürüyor demektir. Bu, sorununuzun kaynağını hızlıca bulmanızı sağlar.
firewalld ile Çalışıyorsanız
CentOS/RHEL 7+ ve Fedora sistemlerde genellikle firewalld kullanılır. iptables komutları çalışsa da firewalld’ı kendi araçlarıyla yönetmek daha doğrudur:
# Firewalld durumu
sudo firewall-cmd --state
# Aktif zone'ları ve üzerlerindeki arayüzleri gör
sudo firewall-cmd --get-active-zones
# Belirli bir zone'daki açık portları listele
sudo firewall-cmd --zone=public --list-all
# Tüm zone'ları detaylıca listele
sudo firewall-cmd --list-all-zones
# Belirli bir portu geçici olarak aç (reboot'a kadar)
sudo firewall-cmd --zone=public --add-port=8080/tcp
# Kalıcı olarak aç
sudo firewall-cmd --zone=public --add-port=8080/tcp --permanent
sudo firewall-cmd --reloadnftables Kullanıcıları için
Yeni nesil Linux sistemlerinde (Debian 10+, Ubuntu 20.04+, RHEL 8+) nftables iptables’ın yerini almaya başladı:
# Tüm kuralları listele
sudo nft list ruleset
# Belirli bir tabloyu listele
sudo nft list table inet filter
# Belirli bir zinciri listele
sudo nft list chain inet filter input
# Kural sayaçlarını göster
sudo nft list ruleset -aGerçek Dünya Senaryosu 1: Web Sunucusu 80 Portuna Dışarıdan Erişilemiyor
Klasik bir senaryo: Nginx kuruldu, servis çalışıyor, localhost’tan erişim var ama dışarıdan hiçbir şekilde bağlantı kurulamıyor.
Önce durumu doğrulayalım:
# Sunucu üzerinde portu dinleyen process var mı?
sudo ss -tlnp | grep :80
# Sunucu içinden erişim çalışıyor mu?
curl -I http://localhost
# Firewall kurallarına bakalım
sudo iptables -L INPUT -v -n --line-numbers
# Eğer firewalld kullanılıyorsa
sudo firewall-cmd --zone=public --list-ports
sudo firewall-cmd --zone=public --list-servicesDiyelim ki iptables çıktısında şunu görüyoruz:
Chain INPUT (policy DROP)
num pkts bytes target prot opt in out source destination
1 1234 89K ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
2 456 32K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
3 0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443Policy DROP, yani varsayılan olarak tüm paketler düşürülüyor. 80 portu için hiçbir kural yok. Çözüm:
# 80 portunu aç
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Değişikliği kalıcı yap (Debian/Ubuntu)
sudo apt install iptables-persistent
sudo netfilter-persistent save
# Değişikliği kalıcı yap (RHEL/CentOS - eski yöntem)
sudo service iptables saveGerçek Dünya Senaryosu 2: Mikro Servisler Arası İletişim Kesildi
Bu senaryo daha karmaşık. Docker veya Kubernetes olmayan bir ortamda, aynı sunucuda çalışan iki servis birbirine bağlanamıyor. Uygulama A, uygulama B’nin 3000 portuna bağlanmaya çalışıyor ama zaman aşımı alıyor.
# Önce portun dinlenip dinlenmediğini kontrol et
sudo ss -tlnp | grep :3000
# Hangi arayüzde dinleniyor? Sadece 127.0.0.1 mi?
# Eğer output şöyle ise sorun var:
# LISTEN 0 128 127.0.0.1:3000 0.0.0.0:*
# Uygulama B sadece localhost'u dinliyorsa, 0.0.0.0'ı dinlemesi gerekiyor
# ya da uygulama A, localhost üzerinden bağlanmalı
# Docker kullanılıyorsa container network'ünü kontrol et
docker network inspect bridge
# iptables FORWARD chain'ini kontrol et (container'lar arası trafik için)
sudo iptables -L FORWARD -v -nBir de şunu test edin: Firewall geçici olarak kapatıldığında sorun çözülüyor mu?
# DİKKAT: Sadece test ortamında ve SSH bağlantısını kaybetmeyeceğinizden eminseniz
sudo iptables -P INPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -F
# Test ettikten sonra kuralları geri yükleyin!
sudo netfilter-persistent reload
# veya
sudo iptables-restore < /etc/iptables/rules.v4Eğer firewall kapatıldığında sorun çözüldüyse, kesinlikle firewall kaynaklı bir sorunla karşı karşıyasınız demektir.
tcpdump ile Paket Düzeyinde İnceleme
Bazen iptables çıktısı yeterli bilgi vermez. Paketlerin gerçekten sunucuya ulaşıp ulaşmadığını görmek için tcpdump kullanın:
# Belirli bir port üzerindeki trafiği izle
sudo tcpdump -i eth0 port 80 -n
# Hem gelen hem giden, daha detaylı
sudo tcpdump -i any port 3306 -n -v
# Belirli bir IP'den gelen trafiği izle
sudo tcpdump -i eth0 src 192.168.1.100 -n
# Paketleri dosyaya kaydet ve Wireshark ile analiz et
sudo tcpdump -i eth0 port 443 -w /tmp/capture.pcapEğer tcpdump ile paketin sunucuya ulaştığını görüyorsunuz ama uygulama cevap vermiyorsa sorun firewall’dan önce bir yerde. Eğer paket hiç görünmüyorsa, sorun sunucuya ulaşmadan önce (upstream firewall, router, vs.) yaşanıyor demektir.
Windows Firewall Sorunları
PowerShell ile Durum Kontrolü
Windows tarafında da benzer sorunlar yaşanır. Windows Server’da uzak masaüstü veya belirli uygulama portları aniden kapanabilir:
# PowerShell - Firewall profillerinin durumu
Get-NetFirewallProfile | Select-Object Name, Enabled
# Belirli bir porta ait kuralları listele
Get-NetFirewallRule | Where-Object {$_.LocalPort -eq "8080"} | Select-Object DisplayName, Direction, Action, Enabled
# Port 443 üzerindeki tüm kuralları gör
Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq "443"} | Get-NetFirewallRule | Select-Object DisplayName, Direction, Action
# Yeni inbound kural ekle
New-NetFirewallRule -DisplayName "Allow 8080 Inbound" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow
# Kural sil
Remove-NetFirewallRule -DisplayName "Allow 8080 Inbound"netsh ile Klasik Yöntem
Eski alışkanlıklardan kurtulamayanlar veya eski Windows Server sürümleriyle çalışanlar için:
# Firewall durumunu göster
netsh advfirewall show allprofiles
# Tüm kuralları listele
netsh advfirewall firewall show rule name=all
# Belirli bir port için kural ekle
netsh advfirewall firewall add rule name="Allow Port 8080" protocol=TCP dir=in localport=8080 action=allow
# Kural sil
netsh advfirewall firewall delete rule name="Allow Port 8080"
# Firewall'ı geçici olarak kapat (test için)
netsh advfirewall set allprofiles state off
# Tekrar aç
netsh advfirewall set allprofiles state onGelişmiş Hata Ayıklama: iptables LOG Hedefi
Hangi paketlerin DROP edildiğini görmek istiyorsanız, LOG hedefini kullanabilirsiniz. Bu özellikle zor sorunları çözerken çok işe yarar:
# INPUT zincirinin sonuna LOG kuralı ekle (DROP'tan önce olmalı)
sudo iptables -A INPUT -j LOG --log-prefix "IPT-DROP: " --log-level 4
# /var/log/kern.log veya /var/log/messages'ta logları izle
sudo tail -f /var/log/kern.log | grep "IPT-DROP"
# Veya journalctl ile
sudo journalctl -f -k | grep "IPT-DROP"
# Test sonrası LOG kuralını temizle (çok fazla log üretir)
sudo iptables -D INPUT -j LOG --log-prefix "IPT-DROP: " --log-level 4Bu yöntemle hangi kaynak IP’nin, hangi porta, hangi protokolle bağlanmaya çalıştığını ve neden düşürüldüğünü görebilirsiniz. Üretim ortamında dikkatli kullanın, disk I/O’yu ciddi şekilde artırabilir.
Bağlantı Durumunu (Stateful) Anlama
Modern güvenlik duvarları stateful çalışır, yani bağlantı durumunu takip eder. Bu bazen kafa karıştırıcı durumlar yaratır:
# Mevcut bağlantı izleme tablosunu gör
sudo conntrack -L
# Belirli bir IP için bağlantı durumlarını gör
sudo conntrack -L | grep 192.168.1.100
# Bağlantı izleme limitini kontrol et (dolar mı?)
cat /proc/sys/net/netfilter/nf_conntrack_max
cat /proc/sys/net/netfilter/nf_conntrack_count
# Eğer count, max'a yaklaşıyorsa sorun bu olabilir
# Geçici çözüm - limiti artır
echo 131072 | sudo tee /proc/sys/net/netfilter/nf_conntrack_maxConntrack tablosunun dolması kritik bir sorundur. Bu durumda yeni bağlantılar kurulamaz ama mevcut bağlantılar çalışmaya devam eder. Belirtisi: Yüksek trafikli sistemlerde intermittent bağlantı sorunları.
Gerçek Dünya Senaryosu 3: VPN Sonrası Erişim Sorunları
Çok yaygın bir senaryo: VPN bağlandıktan sonra bazı sunuculara erişim çalışmıyor veya VPN üzerinden gelen trafiğe sunucu cevap vermiyor.
Sorun genellikle şuradan kaynaklanır: Sunucuya VPN ağından gelen paket geliyor, sunucu cevabı kendi default gateway’inden (VPN değil, normal internet) gönderiyor. Bu durumda istemci, farklı bir IP’den cevap aldığı için bağlantıyı reddediyor.
# Sunucudaki routing tablosunu kontrol et
ip route show
# VPN arayüzü var mı?
ip addr show
# VPN ağından gelen paketler için özel route var mı?
ip route show table all | grep vpn
# VPN subnet için route ekle (örnek: 10.8.0.0/24 VPN ağı)
sudo ip route add 10.8.0.0/24 via 10.8.0.1 dev tun0
# Kalıcı hale getirmek için /etc/network/interfaces veya NetworkManager kullanAyrıca iptables FORWARD kurallarını kontrol edin. VPN trafiğinin yönlendirilmesine izin verilmeli:
# IP forwarding aktif mi?
cat /proc/sys/net/ipv4/ip_forward
# Aktif değilse:
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Kalıcı için /etc/sysctl.conf'a ekle:
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -pKural Sıralaması ve Öncelik Sorunları
iptables kuralları sırayla işlenir ve ilk eşleşen kural uygulanır. Bu sıralama hataları ciddi sorunlara yol açabilir:
# Mevcut kural sırasını gör
sudo iptables -L INPUT -v -n --line-numbers
# Kural sonuna değil başına eklemek için -I kullan
sudo iptables -I INPUT 1 -s 10.0.0.0/8 -j ACCEPT
# Belirli bir satıra ekle (2. sıraya)
sudo iptables -I INPUT 2 -p tcp --dport 8080 -j ACCEPT
# Satır numarasıyla kural sil
sudo iptables -D INPUT 3Örnek sorun: Tüm trafiği engelleyen bir DROP kuralı, ACCEPT kuralından önce geliyorsa ACCEPT kuralı hiç işlenmez. Kural sıralamasını her zaman kontrol edin.
Güvenlik Grubu ve Cloud Firewall’ları
AWS, Azure veya GCP kullanıyorsanız, sadece sunucu üzerindeki firewall’ı değil, cloud tarafındaki güvenlik gruplarını da kontrol etmelisiniz. Bu sıklıkla gözden kaçan bir noktadır.
- AWS: Security Group kuralları hem inbound hem outbound için kontrol edilmeli. Ayrıca Network ACL (NACL) kuralları stateless çalışır, yani her iki yön için ayrı kural gerekir.
- Azure: Network Security Group (NSG) hem subnet hem NIC düzeyinde uygulanabilir. İkisi çakışıyorsa sorun çıkar.
- GCP: Firewall kuralları VPC düzeyinde tanımlanır, tag bazlı filtreleme yapılır.
Cloud ortamında sorun giderirken şu sırayı takip edin:
- Sunucu üzerindeki OS firewall’ı kontrol et
- Cloud güvenlik grubu/NSG kurallarını kontrol et
- VPC/VNET seviyesindeki ACL kurallarını kontrol et
- Load balancer sağlık kontrolü kurallarını kontrol et
Sorun Giderme Metodolojisi
Sistematik bir yaklaşım için şu adımları takip edin:
- Katman katman ilerle: İlk önce sorunun tam olarak nerede yaşandığını belirle. Sunucu içinden erişim çalışıyor mu? Aynı subnet’ten? Farklı subnet’ten?
- İzole et: Geçici olarak firewall’ı devre dışı bırakarak sorunun firewall kaynaklı olup olmadığını doğrula.
- Logları kullan: iptables LOG hedefini veya firewalld log ayarlarını aktif et, hangi paketlerin düşürüldüğünü gör.
- Birer birer test et: Kural değişikliklerini birer birer yapın ve her adımda test edin. Toplu değişiklikler hata bulmayı zorlaştırır.
- Değişiklikleri belgele: Yaptığınız değişiklikleri mutlaka belgeleyin. Özellikle geçici test kurallarını not alın ve test sonrası temizleyin.
Sonuç
Güvenlik duvarı kaynaklı bağlantı sorunları, sessiz doğaları nedeniyle uzun zaman harcatabilir. Ancak doğru araçları ve metodolojik bir yaklaşımı kullandığınızda genellikle birkaç dakika içinde kaynağı bulabilirsiniz. Kritik nokta, panik yapmadan katman katman ilerlemek ve her adımı doğrulamaktır.
Şunu unutmayın: Üretim ortamında firewall değişikliklerini yaparken her zaman önce mevcut kuralları yedekleyin (iptables-save > /tmp/iptables-backup.txt), değişiklikleri önce test ortamında uygulayın ve kritik sistemlerde değişiklik yapmadan önce bir geri dönüş planınız olsun. Özellikle uzak sunucularda çalışırken SSH erişimini kesen bir kural eklemekten kaçının. Bu, gece yarısı data center kapısını çalmak zorunda kalmanızla sonuçlanabilir ve inanın, bu deneyimi yaşayan sysadmin sayısı hiç de az değil.