OpenVPN Log Analizi ve Bağlantı Sorunlarını Giderme

OpenVPN sunucunuz çalışıyor, tünel kurulmuş görünüyor ama istemciler bağlanamıyor. Ya da bağlanıyorlar ama birkaç dakika sonra düşüyorlar. Belki de sadece belirli kullanıcılar sorun yaşıyor. Bu senaryoların hepsi sysadmin hayatının kaçınılmaz bir parçası ve çözüm her zaman aynı yerde saklı: loglarda.

OpenVPN log analizi, ilk bakışta karmaşık görünen bir konu ama bir kez temel kalıpları öğrendiğinizde sorunları dakikalar içinde tespit edebilirsiniz. Bu yazıda gerçek dünya senaryolarından yola çıkarak OpenVPN loglarını nasıl okuyacağınızı, hangi hata mesajlarının neye işaret ettiğini ve sorunları sistematik olarak nasıl gidereceğinizi ele alacağız.

Log Dosyalarının Konumu ve Temel Yapılandırma

Önce logların nerede olduğunu bilmek gerekiyor. Dağıtıma ve kurulum yöntemine göre bu değişebiliyor.

# Systemd tabanlı sistemlerde
journalctl -u openvpn@server -f
journalctl -u openvpn-server@server -f

# Geleneksel log dosyası
tail -f /var/log/openvpn/openvpn.log

# Bazı sistemlerde syslog'a düşer
grep openvpn /var/log/syslog | tail -50
grep openvpn /var/log/messages | tail -50

Eğer log dosyanız yok veya çok az bilgi içeriyorsa, önce OpenVPN yapılandırmanızdaki log seviyesini artırmanız gerekiyor. server.conf dosyasına şunu ekleyin:

# /etc/openvpn/server.conf
verb 4          # 0-9 arası, 4 günlük kullanım için ideal
log-append /var/log/openvpn/openvpn.log
status /var/log/openvpn/openvpn-status.log
status-version 2

verb parametresi kritik. Değerler şöyle işliyor:

  • verb 0: Sadece kritik hatalar
  • verb 1-2: Bağlantı olayları
  • verb 3: Normal operasyon, TLS el sıkışmaları
  • verb 4: Orta düzey debug
  • verb 6: Paket başlıkları dahil detaylı bilgi
  • verb 9: Her şey, production’da kullanmayın

Sorun giderme sırasında verb 4 veya 5 genellikle yeterli oluyor. verb 9 ile sistemi log spam’e boğabilirsiniz.

Log Yapısını Anlamak

Bir OpenVPN log satırı genellikle şu yapıda geliyor:

Wed Jan 15 14:23:45 2025 192.168.1.100:52341 TLS: Initial packet from [AF_INET]192.168.1.100:52341, sid=a8f3c219 b4d72e01
Wed Jan 15 14:23:46 2025 192.168.1.100:52341 VERIFY OK: depth=1, CN=MyCA
Wed Jan 15 14:23:46 2025 192.168.1.100:52341 VERIFY OK: depth=0, CN=client1
Wed Jan 15 14:23:46 2025 192.168.1.100:52341 peer info: IV_VER=2.5.1
Wed Jan 15 14:23:47 2025 192.168.1.100:52341 [client1] Peer Connection Initiated with [AF_INET]192.168.1.100:52341

Başarılı bir bağlantı şu adımlardan geçiyor: TLS el sıkışması, sertifika doğrulama, peer bilgisi alışverişi ve son olarak bağlantı kurulumu. Bu akıştan sapan her şey potansiyel bir sorun.

Yaygın Hata Mesajları ve Çözümleri

TLS El Sıkışma Hataları

Bu kategori muhtemelen en sık karşılaşılan sorunlar. Birkaç tipik mesaj:

TLS Error: TLS key negotiation failed to occur within 60 seconds
TLS Error: TLS handshake failed

Bu hatayı görüyorsanız akla gelen ilk şey firewall veya NAT sorunu. İstemci paketi gönderiyor ama sunucu cevap veremiyor ya da tam tersi.

# Sunucu tarafında UDP port dinleniyor mu kontrol edin
ss -ulnp | grep 1194
netstat -ulnp | grep 1194

# Firewall kurallarını kontrol edin
iptables -L INPUT -n -v | grep 1194
ufw status verbose

# Gerçek zamanlı trafik var mı?
tcpdump -i eth0 port 1194 -n

Eğer tcpdump ile paketler geliyorsa ama TLS hatası alıyorsanız, büyük ihtimalle sertifika veya şifreleme uyumsuzluğu var.

Sertifika Doğrulama Hataları

VERIFY ERROR: depth=0, error=certificate has expired: CN=client1
VERIFY ERROR: depth=1, error=unable to get local issuer certificate

İlk hata basit: istemci sertifikası süresi dolmuş. İkinci hata ise CA zincirinde kopukluk var demek.

# Sertifika süresini kontrol edin
openssl x509 -in /etc/openvpn/easy-rsa/pki/issued/client1.crt -text -noout | grep -A2 "Validity"

# CA sertifikasını doğrulayın
openssl verify -CAfile /etc/openvpn/ca.crt /etc/openvpn/easy-rsa/pki/issued/client1.crt

# CRL (Certificate Revocation List) güncel mi?
openssl crl -in /etc/openvpn/crl.pem -text -noout | grep "Next Update"

Eğer CRL süresi dolmuşsa tüm bağlantılar kesilir. Bunu sıkça gözden kaçırıyorlar:

# CRL'yi yenileyin (easy-rsa kullanıyorsanız)
cd /etc/openvpn/easy-rsa
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/
systemctl restart openvpn@server

“AUTH_FAILED” Hataları

AUTH: Received control message: AUTH_FAILED

Bu mesajı görüyorsanız birkaç farklı sebebi olabilir. Username/password doğrulama kullanıyorsanız önce onu kontrol edin. Ama sertifika tabanlı auth’ta bu mesaj genellikle tls-auth veya tls-crypt anahtar uyumsuzluğuna işaret ediyor.

# ta.key veya tls-crypt.key her iki tarafta da aynı mı?
md5sum /etc/openvpn/ta.key
# İstemci üzerinde aynı dosyanın MD5'ini karşılaştırın

# Server conf'ta hangi yöntemi kullanıyorsunuz?
grep -E "tls-auth|tls-crypt" /etc/openvpn/server.conf

Bir diğer yaygın senaryo: sunucuda tls-auth ta.key 0, istemcide tls-auth ta.key 1 olması gerekiyor. Yönü karıştırmak bu hataya yol açıyor.

Yönlendirme ve IP Sorunları

Bağlantı kuruluyor ama trafik akmıyor. Bu durumda genellikle log’da açık bir hata yok, sorun routing’de.

# OpenVPN status dosyasını inceleyin
cat /var/log/openvpn/openvpn-status.log

# Örnek çıktı:
# CLIENT_LIST,client1,192.168.1.100:52341,10.8.0.2,10.8.0.1,,12345,54321,Wed Jan 15 14:23:47 2025
# ROUTING_TABLE,10.8.0.2,client1,192.168.1.100:52341,Wed Jan 15 14:23:47 2025

# IP forwarding aktif mi?
cat /proc/sys/net/ipv4/ip_forward
# 1 olması gerekiyor, 0 ise:
echo 1 > /proc/sys/net/ipv4/ip_forward
# Kalıcı hale getirmek için:
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

NAT kuralı eksikse internet erişimi olmaz:

# Mevcut NAT kurallarını görün
iptables -t nat -L POSTROUTING -n -v

# Eksikse ekleyin (eth0 yerine gerçek interface adınızı yazın)
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

# iptables-persistent ile kaydedin
netfilter-persistent save

Gerçek Dünya Senaryosu 1: Aralıklı Bağlantı Düşmeleri

Klasik bir sorun: kullanıcılar bağlanıyor, 10-15 dakika sonra bağlantı düşüyor. Sabah geliyorlar “VPN düşüyor” diyorlar.

Log’da şuna benzer mesajlar görüyorsunuz:

client1/192.168.1.100:52341 SIGTERM[soft,ping-restart] received, client-instance restarting

Bu keepalive sorununa işaret ediyor. Her iki taraftaki keepalive ayarları uyumsuz veya çok agresif olabilir.

# server.conf'u kontrol edin
grep keepalive /etc/openvpn/server.conf
# Önerilen değer: keepalive 10 120
# 10 saniyede bir ping, 120 saniye cevap gelmezse yeniden bağlan

# client.conf veya .ovpn dosyasında da olabilir
grep -E "keepalive|ping" /etc/openvpn/client.conf

Ama asıl sorun çoğunlukla ortadaki bir firewall veya NAT cihazı. Şirket firewall’ları UDP bağlantılarını belirli bir süre inaktif kalınca kesiyor.

# server.conf'a ekleyin
keepalive 10 60
# veya daha agresif:
ping 10
ping-restart 60
ping-timer-rem
persist-tun
persist-key

İstemci tarafında da aynı ayarların olması gerekiyor. Bazı kurumsal networkler UDP’yi kesiyor, bu durumda TCP’ye geçmek gerekebiliyor:

# server.conf için TCP alternatif yapılandırma
proto tcp
port 443  # 443 portu genellikle geçiyor

# Yeni server instance başlatın, mevcut UDP'yi kapatmayın

Gerçek Dünya Senaryosu 2: Belirli Kullanıcılar Bağlanamıyor

Bazı kullanıcılar VPN’e bağlanabiliyor, bazıları bağlanamıyor. İlk bakışta sertifika sorunu gibi görünse de bazen farklı bir şey çıkıyor.

# Bağlanamayan kullanıcının log'unu filtreleyin
grep "client2" /var/log/openvpn/openvpn.log | tail -30

# Duplicate CN sorunu var mı?
grep "duplicate CN" /var/log/openvpn/openvpn.log

Eğer şöyle bir mesaj görüyorsanız:

client2/10.0.0.5:44231 MULTI: new connection by client 'client2' -- existing connection disconnected

Bu, aynı sertifika ile iki farklı yerden bağlanma girişimi. duplicate-cn direktifi sunucuda izin vermiyorsa bir önceki bağlantı kesiliyor.

# server.conf'a ekleyerek birden fazla bağlantıya izin verebilirsiniz
# (güvenlik değerlendirmesi yaparak)
duplicate-cn

# Veya kullanıcı bazlı IP atayarak takip edebilirsiniz
# /etc/openvpn/ccd/client2 dosyası oluşturun:
echo "ifconfig-push 10.8.0.10 255.255.255.0" > /etc/openvpn/ccd/client2

Log Analizi İçin Script’ler

Manuel log okumak yorucu. Birkaç pratik script işinizi kolaylaştırır:

#!/bin/bash
# openvpn-log-summary.sh
# Günlük bağlantı özeti

LOG="/var/log/openvpn/openvpn.log"
TODAY=$(date +"%b %d")

echo "=== OpenVPN Günlük Özeti - $TODAY ==="
echo ""
echo "Başarılı Bağlantılar:"
grep "$TODAY" "$LOG" | grep "Peer Connection Initiated" | awk '{print $6}' | sort | uniq -c | sort -rn

echo ""
echo "Başarısız Bağlantılar:"
grep "$TODAY" "$LOG" | grep -E "VERIFY ERROR|AUTH_FAILED|TLS Error" | awk '{print $1,$2,$3,$4}' | tail -20

echo ""
echo "Şu An Bağlı Kullanıcılar:"
grep "^CLIENT_LIST" /var/log/openvpn/openvpn-status.log | awk -F',' '{print $2, $4, $8}' | column -t

Daha ileri gidelim, hata tespiti için başka bir script:

#!/bin/bash
# openvpn-error-monitor.sh
# Son 1 saatteki hataları analiz et

LOG="/var/log/openvpn/openvpn.log"
THRESHOLD=5  # 5'ten fazla hata varsa uyar

# journalctl kullanıyorsanız
ERRORS=$(journalctl -u openvpn@server --since "1 hour ago" | grep -cE "TLS Error|VERIFY ERROR|AUTH_FAILED")

if [ "$ERRORS" -gt "$THRESHOLD" ]; then
    echo "UYARI: Son 1 saatte $ERRORS hata tespit edildi!"
    journalctl -u openvpn@server --since "1 hour ago" | grep -E "TLS Error|VERIFY ERROR|AUTH_FAILED" | tail -10
fi

Management Interface Kullanımı

OpenVPN’in gömülü yönetim arayüzü gerçek zamanlı sorun gidermede çok işe yarıyor:

# server.conf'a ekleyin
management 127.0.0.1 7505
management-hold

Sonra telnet ile bağlanın:

telnet 127.0.0.1 7505

# Komutlar:
status          # Bağlı istemciler
log 20          # Son 20 log satırı
kill client1    # İstemciyi kes
bytecount 5     # 5 saniyede bir trafik istatistiği
verb 5          # Log verbosity'yi anlık değiştir

Bu arayüz özellikle production sunucularda servisi yeniden başlatmadan debug yapmanıza olanak tanıyor.

Performans Sorunlarını Teşhis Etmek

Bağlantı var ama hız düşük. Log’da doğrudan bir hata yok ama kullanıcılar şikayet ediyor.

# OpenVPN status'tan trafik istatistikleri
watch -n 5 'grep "^CLIENT_LIST" /var/log/openvpn/openvpn-status.log | awk -F"," "{print $2, $5, $6}"'

# CPU kullanımı yüksek mi? (şifreleme CPU yiyor)
top -p $(pgrep openvpn)

# AES-NI donanım hızlandırma var mı?
grep -m1 "aes" /proc/cpuinfo

# Cipher değişikliği düşünün
# server.conf'ta:
cipher AES-256-GCM     # Modern, hızlı
# Eski:
# cipher AES-256-CBC   # Daha yavaş

MTU sorunları da sık görülen performans düşüşü nedeni:

# server.conf'a ekleyin
tun-mtu 1500
fragment 1300
mssfix 1300

# Veya istemci tarafında test edin
ping -M do -s 1400 10.8.0.1  # VPN üzerinden ping, parçalanıyor mu?

Güvenlik Loglarını İzlemek

Sadece sorun giderme değil, güvenlik açısından da loglar kritik. Kaba kuvvet saldırıları, yetkisiz erişim girişimleri bunlar logda görünüyor.

# Başarısız bağlantı girişimlerini izleyin
grep "TLS Error|VERIFY ERROR|AUTH_FAILED" /var/log/openvpn/openvpn.log | 
  awk '{print $4}' | sort | uniq -c | sort -rn | head -20

# Fail2ban ile OpenVPN için kural ekleyin
# /etc/fail2ban/filter.d/openvpn.conf
cat > /etc/fail2ban/filter.d/openvpn.conf << 'EOF'
[Definition]
failregex = <HOST>:d+ TLS Error: TLS key negotiation failed
            <HOST>:d+ VERIFY ERROR
            <HOST>:d+ AUTH_FAILED
ignoreregex =
EOF

# /etc/fail2ban/jail.d/openvpn.conf
cat > /etc/fail2ban/jail.d/openvpn.conf << 'EOF'
[openvpn]
enabled = true
port = 1194
protocol = udp
filter = openvpn
logpath = /var/log/openvpn/openvpn.log
maxretry = 5
bantime = 3600
EOF

systemctl restart fail2ban

Sorun Giderme Kontrol Listesi

Bir sorunla karşılaştığınızda sistematik yaklaşım için sıralı kontroller:

# 1. Servis çalışıyor mu?
systemctl status openvpn@server

# 2. Port açık mı?
ss -ulnp | grep 1194

# 3. Son log hataları neler?
journalctl -u openvpn@server -n 50 --no-pager | grep -E "ERROR|WARN|failed"

# 4. Sertifika süreleri?
for cert in /etc/openvpn/easy-rsa/pki/issued/*.crt; do
    echo -n "$cert: "
    openssl x509 -enddate -noout -in "$cert"
done

# 5. CRL geçerli mi?
openssl crl -in /etc/openvpn/crl.pem -text -noout | grep -E "Last|Next"

# 6. Routing tablosu doğru mu?
ip route show table main | grep "10.8"

# 7. IP forwarding aktif mi?
sysctl net.ipv4.ip_forward

Logrotate Yapılandırması

Log dosyaları zamanla devleşiyor. Logrotate ile düzenli temizlik yapın:

# /etc/logrotate.d/openvpn
cat > /etc/logrotate.d/openvpn << 'EOF'
/var/log/openvpn/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl reload openvpn@server > /dev/null 2>&1 || true
    endscript
}
EOF

Sonuç

OpenVPN log analizi, ilk bakışta korkutucu görünse de birkaç temel prensibi kavradıktan sonra çok sistematik bir hal alıyor. Önce log verbosity’nizi ihtiyaca göre ayarlayın, ikinci adımda hangi aşamada hata olduğunu tespit edin: TLS el sıkışması mı, sertifika doğrulama mı, yoksa bağlantı sonrası routing mi?

Gerçek dünya sorunlarının büyük çoğunluğu şu beş kategoriye giriyor: sertifika sorunları, TLS yapılandırma uyumsuzlukları, firewall ve NAT engelleri, routing eksiklikleri ve keepalive ayarları. Bu kategorileri aklınızda tutarak herhangi bir log mesajına yaklaştığınızda çözüme çok daha hızlı ulaşırsınız.

Management interface’i ve özelleştirilmiş log analiz script’lerini rutininize katmak uzun vadede büyük zaman tasarrufu sağlıyor. Proaktif monitoring ile kullanıcılar sizi aramadan önce siz sorunları tespit edebilirsiniz.

Son olarak, production ortamınızda verb 4 seviyesinde loglama tutun, güvenlik loglarını düzenli inceleyin ve sertifika sürelerini takvime koyun. Bu üç basit alışkanlık, OpenVPN kaynaklı gece mesailerinin büyük bölümünü ortadan kaldırır.

Yorum yapın