VPN Bağlantı Sorunları: Hata Tespiti ve Çözüm Yöntemleri

Tarafındankomut
0 Comments

VPN bağlantısı kesildi, tünel kurulamıyor ya da bağlantı kurulup hemen düşüyor… Bu senaryoların hepsini yaşadıysanız doğru yerdesiniz. VPN sorunları sysadminlerin en çok zaman harcadığı konulardan biri çünkü sorunun kaynağı çok fazla farklı katmanda olabiliyor: ağ, kimlik doğrulama, sertifika, güvenlik duvarı, routing… Bu yazıda OpenVPN, WireGuard ve IPSec tabanlı yapılar için sistematik bir hata ayıklama yaklaşımı sunacağım.

Önce Temel Kontrolleri Yapın

Karmaşık hata ayıklama adımlarına geçmeden önce basit ama sıkça atlanan kontrolleri yapmanızı öneririm.

Servis Durumu ve Log Kontrolü

# OpenVPN servis durumu
systemctl status openvpn@server
journalctl -u openvpn@server -f --since "1 hour ago"

# WireGuard servis durumu
systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -n 100

# IPSec (StrongSwan) durumu
systemctl status strongswan
ipsec statusall

Log çıktısında ilk dikkat etmeniz gereken şeyler: zaman damgası tutarlılığı, hata kodları ve “peer” tarafından gelen mesajlar. Özellikle TLS handshake failed, AUTH_FAILED, VERIFY ERROR gibi ifadeler sizi doğrudan sorunun kaynağına götürür.

Ağ Arayüzü Kontrolü

# VPN tünel arayüzlerini listele
ip link show | grep -E "tun|tap|wg|ipsec"

# Arayüz detayları
ip addr show tun0
ip addr show wg0

# Routing tablosunu kontrol et
ip route show
ip route show table all | grep -E "tun|wg|ipsec"

Burada tun0 veya wg0 arayüzünün UP durumda olup olmadığına bakın. Arayüz yoksa VPN tüneli hiç kurulamamış demektir, varsa ama trafik akışı yoksa sorun routing veya firewall kaynaklıdır.

OpenVPN Hata Ayıklama

Verbose Log Aktifleştirme

OpenVPN’in en güçlü yanlarından biri detaylı loglama seçeneği. Sorunu reprodüce edebiliyorsanız verbose seviyesini artırın:

# Config dosyasına ekleyin veya komut satırında çalıştırın
openvpn --config /etc/openvpn/server.conf --verb 6

# Sadece log dosyasına yazmak için
openvpn --config /etc/openvpn/server.conf --verb 6 --log /tmp/openvpn_debug.log

# Gerçek zamanlı takip
tail -f /tmp/openvpn_debug.log | grep -E "ERROR|WARN|TLS|AUTH"

–verb 6: En detaylı loglama seviyesi, paket düzeyinde bilgi verir.

Verb değerlerini şöyle düşünebilirsiniz:

  • 1-2: Sadece kritik hatalar
  • 3-4: Bağlantı durumu değişiklikleri
  • 5-6: TLS handshake detayları
  • 9: Paket düzeyinde tam debug (production’da asla kullanmayın)

TLS Sertifika Sorunları

Gerçek dünya senaryosu: “Müşteri VPN’e bağlanıyor ama 10 saniye sonra düşüyor” diye bir ticket geldi. Log’a baktığımda şunu gördüm:

TLS Error: TLS key negotiation failed to occur within 60 seconds
VERIFY ERROR: depth=1, error=certificate has expired: CN=CA

Sertifika süresi dolmuş. Kontrol etmek için:

# Sertifika geçerlilik süresini kontrol et
openssl x509 -in /etc/openvpn/server.crt -noout -dates
openssl x509 -in /etc/openvpn/ca.crt -noout -dates

# İstemci sertifikasını da kontrol et
openssl x509 -in /etc/openvpn/client.crt -noout -dates

# Sertifika zincirini doğrula
openssl verify -CAfile /etc/openvpn/ca.crt /etc/openvpn/server.crt

# CRL (Certificate Revocation List) kontrolü
openssl crl -in /etc/openvpn/crl.pem -noout -text | grep -E "Next Update|Last Update"

Eğer certificate has expired hatası alıyorsanız ve EasyRSA kullanıyorsanız sertifika yenileme işlemi:

cd /etc/openvpn/easy-rsa/

# CA sertifikası yenileme (dikkatli olun, tüm istemcileri etkiler)
./easyrsa renew-ca

# Server sertifikası yenileme
./easyrsa renew server nopass

# İstemci sertifikası yenileme
./easyrsa renew client1

Kimlik Doğrulama Hataları

AUTH_FAILED hatası birden fazla şey anlamına gelebilir. Sistematik yaklaşım:

# Kullanıcı doğrulama scriptini manuel test et (auth-user-pass-verify kullanıyorsanız)
echo -e "usernamenpassword" | /etc/openvpn/auth.sh

# PAM doğrulamasını test et
pamtester openvpn kullanici_adi authenticate

# LDAP bağlantısını test et (openvpn-auth-ldap kullanıyorsanız)
ldapsearch -H ldap://ldap.sirket.local -D "cn=vpnservice,dc=sirket,dc=local" 
  -w "servis_sifresi" -b "dc=sirket,dc=local" "(uid=test_kullanici)"

WireGuard Hata Ayıklama

WireGuard’ın log mekanizması OpenVPN’den farklı çalışır. Kernel modülü olduğu için loglar kernel ring buffer’da bulunur.

WireGuard Debug Logları

# Kernel loglarını filtrele
dmesg | grep -i wireguard
journalctl -k | grep wireguard

# WireGuard debug loglamasını aktifleştir (dikkat: çok fazla log üretir)
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

# Peer durumunu kontrol et
wg show
wg show wg0 latest-handshakes
wg show wg0 transfer

# El sıkışma zamanlarını kontrol et (Unix timestamp)
wg show wg0 latest-handshakes | awk '{print $1, strftime("%Y-%m-%d %H:%M:%S", $2)}'

latest-handshakes çıktısında son el sıkışma zamanına bakın. Eğer 3 dakikadan uzun süre geçmişse veya hiç el sıkışma olmamışsa bağlantı kurulamamış demektir.

WireGuard’da Sık Karşılaşılan Sorunlar

Senaryo: İki site arasında WireGuard tüneli kurulmuş, ping gidiyor ama trafik geçmiyor.

# Her iki tarafta routing kontrolü
ip route get 10.10.20.1 # Karşı tarafın IP'si

# Hangi arayüzden çıktığını kontrol et
ip route get 10.10.20.1 | grep dev

# AllowedIPs kontrolü - bu kritik!
wg show wg0 allowed-ips

# NAT ve IP forwarding kontrolü
cat /proc/sys/net/ipv4/ip_forward
iptables -t nat -L POSTROUTING -n -v

# Paket sayacını sıfırla ve izle
wg set wg0 peer <PUBLIC_KEY> persistent-keepalive 25
watch -n 2 wg show wg0 transfer

WireGuard’da AllowedIPs ayarı hem routing hem de firewall görevi görür. Gönderilecek ve alınacak paketlerin kaynak/hedef IP’si bu listeyle eşleşmiyorsa paket düşürülür. Bunu mutlaka doğrulayın.

UDP Bağlantı Testleri

WireGuard UDP kullandığı için TCP tabanlı araçlarla test edemezsiniz:

# UDP port erişilebilirliğini test et
nc -u -v -z 203.0.113.10 51820

# Netcat ile UDP dinleme testi (server tarafında)
nc -u -l -p 51820

# Tcpdump ile WireGuard trafiğini izle
tcpdump -i eth0 udp port 51820 -n -v

# Her iki tarafta aynı anda çalıştırın
tcpdump -i eth0 'udp and (port 51820)' -n

IPSec / StrongSwan Hata Ayıklama

IPSec protokolü karmaşık yapısıyla en zorlu hata ayıklama senaryolarını sunar. IKE (Internet Key Exchange) ve ESP (Encapsulating Security Payload) olmak üzere iki ana bileşeni var.

StrongSwan Log Seviyesini Artırma

# /etc/strongswan.d/charon-logging.conf dosyasını düzenle
cat > /etc/strongswan.d/charon-logging.conf << 'EOF'
charon {
    filelog {
        /var/log/strongswan/charon.log {
            time_format = %b %e %T
            ike_name = yes
            append = no
            default = 2
            ike = 3
            knl = 3
            cfg = 3
            flush_line = yes
        }
    }
}
EOF

systemctl restart strongswan

# Gerçek zamanlı log takibi
tail -f /var/log/strongswan/charon.log

# Aktif bağlantıları listele
ipsec statusall
swanctl --list-sas
swanctl --list-conns

IKE Fazları ve Sorun Tespiti

IPSec bağlantısı iki faz üzerinden kurulur. Hata hangi fazda olduğunu anlamak çok önemli:

# IKE SA (Faz 1) durumu
ipsec statusall | grep -A5 "IKE SAs"

# CHILD SA / IPSec SA (Faz 2) durumu  
ipsec statusall | grep -A5 "CHILD SAs"

# Bağlantıyı manuel başlat ve çıktıyı izle
ipsec up vpn-baglantisi
swanctl --initiate --child vpn-baglantisi

# Kernel IPSec politikalarını görüntüle
ip xfrm policy
ip xfrm state
ip xfrm monitor

Gerçek dünya senaryosu: Şirket güvenlik duvarı değişikliğinin ardından site-to-site IPSec tüneli düştü. Log’da şunu gördüm:

received AUTHENTICATION_FAILED notify error
no shared key found for '203.0.113.10'

Bu durumda PSK (Pre-Shared Key) uyuşmazlığı veya IKE kimlik (identity) sorununa işaret eder:

# /etc/ipsec.secrets dosyasını kontrol et
cat /etc/ipsec.secrets
# Format: IP VEYA ID : PSK "anahtar_degeri"

# IKE kimliğini debug et
ipsec stroke loglevel ike 4
ipsec up baglanti_adi 2>&1 | grep -E "identity|authentication|IKE"

# Wireshark/tcpdump ile IKE trafiğini yakala
tcpdump -i eth0 -w /tmp/ipsec_debug.pcap 'udp port 500 or udp port 4500 or esp'

Güvenlik Duvarı ve NAT Sorunları

VPN sorunlarının büyük çoğunluğu aslında güvenlik duvarı veya NAT kaynaklıdır.

Firewall Kurallarını Kontrol Et

# iptables kurallarını kontrol et
iptables -L -n -v
iptables -L -n -v -t nat
iptables -L -n -v -t mangle

# Hangi paketlerin düşürüldüğünü logla
iptables -I INPUT -p udp --dport 1194 -j LOG --log-prefix "VPN-INPUT: "
iptables -I FORWARD -i tun0 -j LOG --log-prefix "VPN-FORWARD: "

# Logları izle
tail -f /var/log/kern.log | grep VPN

# nftables kullananlar için
nft list ruleset
nft monitor

NAT Traversal (NAT-T)

Eğer VPN sunucunuz veya istemciniz NAT arkasındaysa:

# NAT arkasında olup olmadığını kontrol et
curl -s https://ifconfig.me  # Dış IP
hostname -I                   # İç IP
# İkisi farklıysa NAT arkasındasınız

# OpenVPN için NAT-T genellikle otomatik çalışır
# IPSec için NAT-T aktifleştirme
grep -i "nat_traversal|nat-t" /etc/ipsec.conf
# Şu satırı ekleyin:
# nat_traversal = yes

# UDP 4500 portunun açık olduğunu kontrol et (IPSec NAT-T için)
ss -ulnp | grep 4500
netstat -ulnp | grep 4500

Routing ve DNS Sorunları

VPN bağlantısı kurulmuş ama trafik yanlış yönlendiriliyor olabilir.

Split Tunneling ve Full Tunnel Kontrolü

# VPN bağlandıktan sonra routing tablosunu kontrol et
ip route show

# Belirli bir hedefe hangi yoldan gidildiğini göster
ip route get 8.8.8.8
ip route get 192.168.1.1

# Default gateway'in VPN üzerinden mi yoksa direkt mi gittiğini kontrol et
ip route show | grep default

# Policy routing kontrolü
ip rule show
ip route show table all

VPN DNS Sorunu Giderme

# Mevcut DNS sunucularını kontrol et
cat /etc/resolv.conf
resolvectl status

# VPN'in DNS sunucusunu push ettiğini kontrol et (OpenVPN client log)
grep "dhcp-option DNS" /etc/openvpn/client.conf
grep "DNS" /var/log/openvpn-client.log

# DNS sızıntısı testi
# nslookup ile hangi DNS sunucusunun kullanıldığını göster
nslookup iç-sunucu.sirket.local
nslookup google.com | grep Server

# systemd-resolved ile DNS kurallarını yeniden yükle
resolvectl flush-caches
resolvectl dns

Bağlantı Kararlılık Sorunları

VPN bağlanıyor ama zaman zaman düşüyor veya yavaş çalışıyorsa:

MTU Sorunları

VPN tünelinin kendisi overhead eklediği için MTU değeri kritik öneme sahiptir. Yanlış MTU ayarı paket parçalanmasına ve yavaş/kararsız bağlantıya yol açar:

# Mevcut MTU değerini kontrol et
ip link show tun0 | grep mtu
ip link show wg0 | grep mtu

# MTU path discovery testi
# -M do: parçalama yapma, -s: paket boyutu
ping -M do -s 1400 8.8.8.8
ping -M do -s 1420 8.8.8.8
ping -M do -s 1450 8.8.8.8
# Hangisi geçiyorsa o değer etrafında optimum MTU'yu bulun

# OpenVPN MTU ayarı (config dosyasına ekleyin)
# tun-mtu 1400
# fragment 1300
# mssfix 1300

# WireGuard MTU ayarı
ip link set wg0 mtu 1420

# Otomatik MTU tespiti için
tracepath 8.8.8.8 | grep pmtu

Keepalive ve Timeout Ayarları

# OpenVPN keepalive kontrolü
grep -i keepalive /etc/openvpn/server.conf
# Yoksa ekleyin: keepalive 10 120

# WireGuard persistent keepalive
wg show wg0 persistent-keepalive
# NAT arkasındaysanız şöyle ayarlayın:
# PersistentKeepalive = 25

# IPSec DPD (Dead Peer Detection) ayarı
grep -i dpd /etc/ipsec.conf
# dpdaction = restart
# dpddelay = 30s
# dpdtimeout = 120s

# Aktif bağlantı sayısını ve sistem limitlerini kontrol et
ss -s
cat /proc/sys/net/core/somaxconn
ulimit -n

Sistematik Hata Ayıklama Akışı

Yukarıdaki tüm bilgileri bir araya getirerek şu sırayla ilerleyin:

  • 1. Adım – Bağlantı katmanı: Önce UDP/TCP port erişilebilirliğini doğrulayın. Güvenlik duvarı veya ISP engeli var mı?
  • 2. Adım – Kimlik doğrulama: Sertifika sürelerini, PSK değerlerini ve kullanıcı bilgilerini kontrol edin.
  • 3. Adım – Tünel kurulumu: Arayüz UP mu? Log’da TLS/IKE el sıkışması başarıyla tamamlandı mı?
  • 4. Adım – Routing: Doğru route’lar eklenmiş mi? IP forwarding aktif mi? NAT kuralları doğru mu?
  • 5. Adım – Trafik akışı: tcpdump ile her iki uçta paket akışı görünüyor mu? MTU sorunu var mı?
  • 6. Adım – DNS: VPN üzerinden DNS çözümlemesi çalışıyor mu? DNS sızıntısı var mı?

Gerçek Dünya Senaryosu: “Sabahları Bağlanıyor, Öğleden Sonra Düşüyor”

Bu tip intermittent sorunlar en sinir bozucularıdır. Bir kez yaşadığım senaryoyu paylaşayım:

Şikâyet: Kullanıcılar sabah VPN’e bağlandıktan sonra öğleden sonra bağlantı kesiliyordu ve tekrar bağlanamıyorlardı.

# Önce zaman bazlı log analizi
journalctl -u openvpn@server --since "08:00" --until "14:00" | grep -E "ERROR|WARN|Peer"

# OpenVPN bağlantı sayısını saatlik olarak izle
journalctl -u openvpn@server | grep "CLIENT_CONNECT|CLIENT_DISCONNECT" | 
  awk '{print $1, $2, $3}' | sort | uniq -c

# Sistem kaynakları - bellek ve dosya descriptor limiti
cat /proc/$(pgrep openvpn)/status | grep -E "VmRSS|Threads"
ls /proc/$(pgrep openvpn)/fd | wc -l
ulimit -n

# Sonunda bulduğum şey: max-clients limiti doluyordu
grep max-clients /etc/openvpn/server.conf

Sorun şuydu: max-clients 50 ayarı vardı ve sabah 09:00-11:00 arası tüm kullanıcılar bağlandığında limit doluyordu. Yeni bağlantılar reddediliyordu. Limiti artırıp dosya descriptor limitini de yükselterek çözdük.

Sonuç

VPN hata ayıklaması sabır ve sistematik yaklaşım gerektiren bir iştir. En önemli altın kural: her zaman log’dan başlayın. Log mesajı sizi zaten büyük ölçüde doğru yöne yönlendirir. Verbose log seviyeleri açıp TLS handshake, kimlik doğrulama ve routing aşamalarını tek tek geçin.

Sık karşılaştığım sorunları özetlersem:

  • Sertifika sorunları: Takvim kontrolü ihmal edildiğinde yıl dönümlerinde bağlantı kesilir.
  • MTU sorunları: Bağlantı kurulur ama büyük dosyalar transfer edilemez, web sayfaları yüklenmez.
  • Firewall kuralları: VPN upgrade veya sunucu migrasyonu sonrası eski kurallar bazen silinir.
  • AllowedIPs / routing hataları: WireGuard veya IPSec’te yanlış subnet tanımları tüm trafiği engeller.
  • Resource limitleri: Yüksek kullanıcı sayısında dosya descriptor veya max-clients limitleri dolabilir.

Her sorun için bir monitoring ve alerting mekanizması kurmayı da ihmal etmeyin. Prometheus + Grafana ile VPN bağlantı sayısı, handshake hataları ve tünel durumunu izlemeniz uzun vadede çok zaman kazandırır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir