OpenVPN Performans Optimizasyonu ve Şifreleme Seçimi

VPN tünelinden geçen her paket için ödenen performans bedeli, çoğu sysadmin’in göz ardı ettiği kritik bir konudur. Yanlış yapılandırılmış bir OpenVPN sunucusu, teorik bant genişliğinin yüzde otuzuna bile ulaşamayabilir. Bu yazıda hem güvenlikten ödün vermeden hem de makul bir performans elde etmek için yapmanız gereken optimizasyonları, gerçek dünya senaryolarıyla birlikte ele alacağız.

Performans Sorunlarının Temeli: Şifreleme ve Protokol Seçimi

OpenVPN’in yavaş çalışmasının arkasında çoğunlukla iki temel neden yatar: yanlış şifreleme algoritması seçimi ve optimize edilmemiş tünel parametreleri. AES-256-CBC ile AES-128-GCM arasındaki fark, modern bir donanımda gece ile gündüz kadar farklı olabilir.

Modern işlemcilerin büyük çoğunluğu AES-NI (Hardware Accelerated AES) desteğiyle geliyor. Bu özelliği kullanmadan yazılım tabanlı şifreleme yapmak, adeta bir Formula 1 aracını birinci viteste sürmek gibidir.

Önce donanımınızın AES-NI destekleyip desteklemediğini kontrol edelim:

# AES-NI desteğini kontrol et
grep -o 'aes' /proc/cpuinfo | head -1

# Daha detaylı kontrol
cpuid | grep -i aes

# OpenSSL ile hız testi
openssl speed aes-128-cbc aes-256-cbc aes-128-gcm aes-256-gcm

Eğer openssl speed çıktısında GCM modları CBC’den belirgin şekilde hızlıysa AES-NI aktiftir. Bu test sonuçlarına göre şifreleme seçiminizi yapmanız gerekir.

Şifreleme Algoritması Seçimi

Eski Düzen: CBC Modu

Eskiden standart olan AES-256-CBC, bugün hem performans hem de güvenlik açısından daha iyi alternatiflere sahip. HMAC ile birlikte kullanılması gerektiğinden ek yük yaratır.

Yeni Standart: GCM Modu

AES-128-GCM ve AES-256-GCM, authenticated encryption sağlar. HMAC’e gerek kalmaz, bu da hem güvenlik hem performans anlamına gelir. OpenVPN 2.4 ve üzeri için AES-128-GCM genellikle optimal seçimdir.

Neden 256 yerine 128? AES-128’e yönelik bilinen herhangi bir pratik saldırı yok. 256-bit, 128-bit’e kıyasla yüzde on beş ile yüzde yirmi arasında ek işlemci yükü getirir ama güvenlik farkı teorik düzeyde kalır.

# Server tarafı şifreleme yapılandırması
# /etc/openvpn/server.conf

cipher AES-128-GCM
auth SHA256
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256

# TLS 1.3 için (OpenVPN 2.5+)
tls-version-min 1.3
tls-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384

TLS Kontrol Kanalı Optimizasyonu

Veri kanalından farklı olarak TLS kontrol kanalı da önemli. Her yeni bağlantıda yapılan TLS el sıkışması (handshake) maliyetlidir. Burada ECDHE tabanlı anahtar değişimi, klasik RSA’ya göre çok daha hızlı çalışır.

# Sertifika yapılandırması - ECDSA kullanın
# RSA 2048 yerine ECDSA P-256 tercih edin

# EasyRSA ile ECDSA sertifikası oluşturma
cd /etc/openvpn/easy-rsa
./easyrsa --curve=secp256r1 gen-req server nopass
./easyrsa --curve=secp256r1 sign-req server server

# Diffie-Hellman yerine ECDH kullan
# server.conf'a ekle:
dh none
ecdh-curve secp256r1

Bu değişiklik, hem başlangıç bağlantı süresini hem de periyodik anahtar yenileme maliyetini ciddi ölçüde azaltır.

MTU ve Tünel Parametreleri

MTU ayarları, OpenVPN performansını etkileyen en kritik ama en çok göz ardı edilen parametrelerdir. Yanlış MTU değeri, paket parçalanmasına (fragmentation) yol açar ve bu durum tünelin efektif bant genişliğini yarı yarıya düşürebilir.

MTU Değerlerini Doğru Hesaplamak

Fiziksel ağ arayüzünüzün MTU değeri genellikle 1500 bayttır. OpenVPN başlıkları ve şifreleme yükü bu değerden düşürülmesi gereken alanı oluşturur:

UDP ile IPv4 kullanımında OpenVPN başlık yükü yaklaşık 40-60 bayttır
GCM modunda ek yük daha az, CBC modunda biraz daha fazladır

# Optimal MTU değerini test et
# Önce mevcut arayüz MTU'sunu kontrol et
ip link show eth0

# Ping ile MTU keşfet (DF bit set, farklı boyutlar dene)
ping -M do -s 1400 hedef_sunucu_ip
ping -M do -s 1420 hedef_sunucu_ip
ping -M do -s 1450 hedef_sunucu_ip

# Fragmentasyon olmadan geçen son boyutu bul
# Bu değeri baz alarak tun-mtu hesapla

Pratikte şöyle bir senaryo düşünelim: Bir müşterinin uzak ofis bağlantısı, sabahları yavaş, öğleden sonra daha hızlı çalışıyordu. Sorun, ISP’nin peak saatlerinde bazı paketleri drop etmesiydi. MTU düşürülerek problem çözüldü.

# /etc/openvpn/server.conf MTU optimizasyonu
tun-mtu 1420
mssfix 1380
fragment 1300

# Alternatif: Otomatik MTU keşfi (OpenVPN 2.6+)
# tun-mtu-extra 32

UDP vs TCP Seçimi

OpenVPN’de UDP her zaman TCP’den önce gelir. TCP üzerinden TCP tünellemek (TCP-over-TCP problemi) ciddi performans sorunlarına yol açar: retransmit mekanizmaları çakışır ve bağlantı özellikle paket kaybının olduğu hatlarda felç olur.

# Server UDP yapılandırması (önerilen)
proto udp
port 1194

# Eğer UDP bloklanıyorsa TCP alternatifi
# Ayrı bir instance olarak çalıştır
proto tcp-server
port 443

# Multi-home setup: hem UDP hem TCP
# İki ayrı server.conf dosyası

Eğer kurumsal ortamda UDP bloklanmışsa, TCP yerine OpenVPN + stunnel kombinasyonunu veya port 443 üzerinden TCP’yi düşünebilirsiniz. UDP’nin mümkün olmadığı durumlarda Wireguard’a geçmek de makul bir alternatiftir.

Çok Çekirdekli CPU Kullanımı

OpenVPN tek thread ile çalışır ve bu önemli bir darboğazdır. Birden fazla CPU çekirdeğinden faydalanmak için birkaç yaklaşım var.

Birden Fazla OpenVPN Instance

# Her port/instance için ayrı conf dosyası
# /etc/openvpn/server1.conf - CPU core 0
# /etc/openvpn/server2.conf - CPU core 1

# Systemd ile multiple instance
systemctl start openvpn@server1
systemctl start openvpn@server2

# taskset ile CPU affinity ayarla
taskset -c 0 openvpn --config /etc/openvpn/server1.conf &
taskset -c 1 openvpn --config /etc/openvpn/server2.conf &

# Kalıcı CPU affinity için systemd override
mkdir -p /etc/systemd/system/[email protected]/
cat > /etc/systemd/system/[email protected]/affinity.conf << EOF
[Service]
CPUAffinity=0
EOF

Kernel ve Network Stack Optimizasyonu

# /etc/sysctl.conf - Network performans optimizasyonu
# Buffer boyutlarını artır
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

# UDP buffer
net.core.netdev_max_backlog = 5000
net.core.optmem_max = 40960

# IP forwarding (OpenVPN için şart)
net.ipv4.ip_forward = 1

# Ayarları uygula
sysctl -p

TLS Auth ve Control Plane Güvenliği

Performans optimizasyonu yaparken güvenlikten taviz vermemek gerekir. tls-auth veya daha modern olan tls-crypt, UDP flood ve DoS saldırılarına karşı ilk savunma hattıdır.

# tls-crypt anahtarı oluştur (tls-auth yerine önerilen)
openvpn --genkey secret /etc/openvpn/ta.key

# server.conf
tls-crypt /etc/openvpn/ta.key

# tls-crypt-v2 (OpenVPN 2.5+, client'a özel anahtarlar)
# Her client için benzersiz anahtar
openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc2-server.key
openvpn --tls-crypt-v2 /etc/openvpn/tc2-server.key --genkey tls-crypt-v2-client client1.key

tls-crypt olmadan, herhangi biri sunucunuza UDP paketleri göndererek TLS handshake başlatabilir. Bu hem CPU’nuzu yorar hem de potansiyel DoS vektörü oluşturur.

Compression: Kullanmayın

Eski alışkanlıkla comp-lzo veya compress direktiflerini ekleyen çok kişi var. Bunların büyük çoğunluğu için tavsiyem: kaldırın.

Neden? İki temel sebep var:

Şifrelenmiş veri sıkıştırılamaz. Günümüzde transfer edilen verinin büyük kısmı zaten sıkıştırılmış format (HTTPS, JPEG, MP4). Sıkıştırma denemek sadece CPU harcar.
VORACLE saldırısı: VPN sıkıştırması, şifrelenmiş trafik üzerinden side-channel bilgi sızdırabilir.

# server.conf - sıkıştırmayı kapat
compress
# veya eski syntax:
comp-lzo no

# Eğer eski client'larla uyumluluk gerekiyorsa:
# push "compress stub-v2"

Eğer gerçekten bant genişliği çok kısıtlıysa (örneğin satellite bağlantısı), sadece kontrol kanalı için sıkıştırma düşünülebilir ama veri kanalı için kesinlikle hayır.

Gerçek Dünya Senaryosu: 50 Kullanıcılı Kurumsal VPN

Bir e-ticaret firması için kurduğumuz VPN yapılandırmasında karşılaştığımız durumu paylaşayım. Başlangıçta mevcut yapılandırma şöyleydi:

cipher AES-256-CBC
comp-lzo yes
proto tcp
MTU ayarı yok
Tek instance, 8 çekirdekli sunucunun sadece birini kullanıyor

Sonuç: Ortalama throughput 45 Mbps, CPU tek çekirdekte yüzde doksanın üzerinde.

Yeni yapılandırma sonrası:

cipher AES-128-GCM
Sıkıştırma kapalı
proto udp
Optimize MTU değerleri
4 ayrı instance, load balancing ile

# HAProxy ile OpenVPN load balancing (UDP)
# /etc/haproxy/haproxy.cfg
frontend openvpn_front
    bind *:1194 udp
    default_backend openvpn_back

backend openvpn_back
    balance leastconn
    server vpn1 127.0.0.1:11941 check
    server vpn2 127.0.0.1:11942 check
    server vpn3 127.0.0.1:11943 check
    server vpn4 127.0.0.1:11944 check

Throughput 180 Mbps’ye çıktı, CPU yükü dört çekirdeğe dengeli dağıldı.

Keepalive ve Bağlantı Kararlılığı

Performans sadece hız değil, kararlılık da demek. Gereksiz yeniden bağlanmalar hem kullanıcı deneyimini hem de sunucu yükünü olumsuz etkiler.

# server.conf
# Her 10 saniyede ping, 120 saniye cevap gelmezse yeniden bağlan
keepalive 10 120

# Client'ların reconnect davranışı için
reneg-sec 0

# Eğer client'lar çok sık kopuyorsa
# tun-mtu ve mssfix değerlerini kontrol et
# Ayrıca explicit-exit-notify ekle
explicit-exit-notify 2

# Client tarafı /etc/openvpn/client.conf optimizasyonu
cipher AES-128-GCM
auth SHA256
tls-version-min 1.2
remote-cert-tls server
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3

# Reconnect davranışı
connect-retry 5 30
connect-retry-max 6

Log ve Monitoring ile Performans Takibi

Yapılandırmanızı optimize ettikten sonra etkinliğini izlemeniz şart. OpenVPN’in yerleşik durum dosyası bu konuda faydalıdır.

# server.conf
status /var/log/openvpn/status.log 10
log-append /var/log/openvpn/openvpn.log
verb 4
mute 10

# Status dosyasını izle
tail -f /var/log/openvpn/status.log

# Bağlı client'ları ve transfer istatistiklerini gör
cat /var/log/openvpn/status.log | grep "CLIENT_LIST"

# iftop ile tünel trafiğini gerçek zamanlı izle
iftop -i tun0

# Şifreleme performansını ölç
openssl speed -evp aes-128-gcm

# OpenVPN throughput testi için iperf3
# Server tarafında tünel içinde:
iperf3 -s -B 10.8.0.1

# Client tarafında:
iperf3 -c 10.8.0.1 -t 30 -P 4

Firewall ve Routing Optimizasyonu

# iptables - optimize edilmiş VPN kuralları
# FORWARD chain için conntrack kullan
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT

# NAT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

# UDP için özel optimizasyon
iptables -A INPUT -p udp --dport 1194 -j ACCEPT

# Conntrack tablosunu büyüt (çok sayıda bağlantı için)
echo 524288 > /proc/sys/net/netfilter/nf_conntrack_max
echo 'net.netfilter.nf_conntrack_max = 524288' >> /etc/sysctl.conf

# nftables kullanıyorsanız (modern yaklaşım)
cat > /etc/nftables-vpn.conf << 'EOF'
table inet filter {
    chain forward {
        type filter hook forward priority 0;
        ct state established,related accept
        iifname "tun0" accept
        oifname "tun0" ct state new accept
    }
}
EOF

Sertifika Yönetimi ve Yenileme Optimizasyonu

Performanslı bir VPN kurulumu, iyi bir sertifika yönetimi altyapısını da kapsar. Süresi dolmuş sertifikalar bağlantı sorunlarına, büyük CRL listeleri ise bellek ve CPU sorunlarına yol açar.

# Sertifika geçerlilik süresini makul tut
# /etc/openvpn/easy-rsa/vars
set_var EASYRSA_CERT_EXPIRE 365
set_var EASYRSA_CA_EXPIRE 3650

# CRL güncelleme scripti
cat > /usr/local/bin/update-vpn-crl.sh << 'EOF'
#!/bin/bash
cd /etc/openvpn/easy-rsa
./easyrsa gen-crl
cp pki/crl.pem /etc/openvpn/crl.pem
chmod 644 /etc/openvpn/crl.pem
systemctl reload openvpn@server
EOF
chmod +x /usr/local/bin/update-vpn-crl.sh

# Crontab ile otomatik CRL yenileme
echo "0 3 * * 0 /usr/local/bin/update-vpn-crl.sh" | crontab -

Sonuç

OpenVPN performans optimizasyonu, birbirini destekleyen birkaç katmanın bir arada doğru yapılandırılmasıyla mümkün oluyor. Öncelik sırasına göre yapmanız gerekenleri özetleyeyim:

İlk adım olarak AES-128-GCM veya AES-256-GCM’e geçin, CBC’yi bırakın. AES-NI desteği olan herhangi bir modern sunucuda bu tek adım bile büyük fark yaratır.

İkinci adım olarak proto UDP kullanın, zorunlu değilse TCP’den kaçının. TCP-over-TCP problemi gerçek ve ciddidir.

Üçüncü adım olarak MTU değerlerini test ederek optimize edin. tun-mtu 1420 ve mssfix 1380 çoğu ortam için iyi bir başlangıç noktasıdır.

Dördüncü adım olarak sıkıştırmayı tamamen kapatın. Hem performans hem güvenlik için doğru seçimdir.

Beşinci adım olarak çok çekirdekli sistemlerde birden fazla instance çalıştırın ve CPU affinity ile yük dağılımını manuel kontrol edin.

Son olarak tls-crypt kullanın, ECDSA sertifikalarına geçin ve düzenli olarak iperf3 ile throughput ölçümü yapın.

OpenVPN, doğru yapılandırıldığında kurumsal ağlar için hala güçlü ve güvenilir bir seçenektir. Wireguard daha hızlı olabilir, ama OpenVPN’in olgunluğu, geniş platform desteği ve derin yapılandırma seçenekleri onu özellikle karmaşık ağ topolojileri için vazgeçilmez kılıyor. Performans sorunlarınızın büyük çoğunluğu yazılım sınırlarından değil, yapılandırma hatalarından kaynaklanıyor. Bu adımları uygulayarak teorik kapasitenizin çok daha yakınına ulaşabilirsiniz.