VPN Wi-Fi'da Çalışmıyor ya da Yavaş

Neden VPN, kablosuz ağda kabloludan daha hassas?

VPN, zaten var olan bir IP paketinin içine yeni bir başlık (header) ve şifreleme katmanı ekleyerek onu başka bir paketin içine kapsüller (encapsulation). Bu işlem her paketin boyutunu büyütür. Yolun herhangi bir noktasındaki 1500 baytlık MTU sınırı, büyüyen paketi taşıyamayabilir. Burada önemli bir ayrıntı var: 802.11 çerçevesinin ve WPA2/WPA3 şifrelemesinin başlıkları IP MTU'sundan pay almaz; Wi-Fi standart olarak 1500 baytlık IP paketini sorunsuz taşır. Asıl ek yük, VPN tünelinin kendisinden ve kablolu tarafta AP ile kontrolcü arasındaki tünellerden (CAPWAP, GRE, VXLAN gibi) gelir.

Sonuç olarak VPN paketi, yol üzerindeki bir bağlantıda MTU sınırını aşabilir. Bu durumda paket ya parçalanır (fragmentation) ya da 'Don't Fragment' bayrağı set edilmişse sessizce düşürülür. Kullanıcı açısından bu, VPN bağlantısının kurulmasına rağmen hiçbir verinin geçmemesi, sayfaların sonsuz yüklenmesi veya bağlantının birkaç dakikada bir kopması olarak görünür.

İkinci büyük fark, Wi-Fi'ın değişken bir ortam olmasıdır. Kablolu bağlantıda gecikme ve paket kaybı neredeyse sabittir; Wi-Fi'da ise RF girişimi, mesafe, roaming ve kanal yoğunluğu nedeniyle gecikme sürekli dalgalanır. VPN tünelleri, özellikle TCP tabanlı olanlar, bu dalgalanmaya karşı çok toleranslı değildir ve küçük paket kayıpları büyük verim (throughput) düşüşlerine dönüşür.

MTU/MSS problemi: 'Black Hole' etkisi

En sık karşılaşılan VPN-Wi-Fi sorunu, MTU uyuşmazlığının yarattığı 'kara delik' (black hole) etkisidir. İstemci bir SYN paketi gönderir, sunucu cevap verir, el sıkışma tamamlanır; ama gerçek veri taşıyan büyük paketler sessizce kaybolur çünkü bir yerdeki cihaz ICMP 'Fragmentation Needed' mesajını güvenlik duvarı kuralı nedeniyle engellemektedir. Kullanıcı bağlantının 'yarı çalıştığını' (DNS çözülüyor ama sayfa açılmıyor) bildirir — bu MTU sorununun klasik belirtisidir.

Çözüm, TCP MSS (Maximum Segment Size) değerini VPN tüneli üzerinden geçen trafik için düşürmektir. Tipik Ethernet MTU'su 1500 bayttır; bir IPsec veya OpenVPN tüneli bu değerden 40-80 bayt arası ek yük ekler. Pratikte VPN arabirimi için MTU'yu 1400 veya daha düşük bir değere, MSS clamping kuralını ise genellikle 1360 civarına ayarlamak sorunu kalıcı olarak çözer.

Kurumsal ortamlarda bu ayar genellikle VPN concentrator veya firewall üzerinde merkezi olarak yapılır, ancak AP'lerin veya kablosuz kontrolcünün kendi tünelleme mekanizmaları (örn. CAPWAP, merkezi anahtarlama) da ekstra bir kapsülleme katmanı eklediği için Wi-Fi tarafında ayrıca MTU payı bırakmak gerekir.

UDP mi TCP mi: tünelleme protokolünün etkisi

VPN istemcisi genellikle UDP ve TCP üzerinden tünel kurma seçeneği sunar. UDP tabanlı tünel (örn. OpenVPN UDP, WireGuard, IPsec/IKEv2), Wi-Fi'ın değişken gecikme ve ara sıra paket kaybı koşullarında TCP tabanlı tünelden belirgin şekilde daha iyi performans gösterir. Bunun nedeni 'TCP üzerinde TCP' sorunudur: Eğer hem dış taşıma hem iç uygulama trafiği TCP kullanıyorsa, bir paket kaybında iki ayrı TCP katmanı aynı anda yeniden gönderim (retransmission) tetikler ve bu durum verimi katlanarak düşürür, bazen bağlantıyı tamamen tıkar.

Pratik öneri: Kurumsal VPN istemcilerinde mümkünse UDP taşıma modu tercih edilmeli, yalnızca 443 portunun açık olduğu kısıtlı ağlarda (örn. otel, havaalanı Wi-Fi'ı) TCP fallback kullanılmalıdır. Ancak bu fallback senaryosu kalıcı günlük kullanım için değil, yalnızca kısıtlı ağlarda geçici erişim için düşünülmelidir.

Split tunneling (bölünmüş tünelleme) ayarı da performansı doğrudan etkiler. Tüm trafiği zorla VPN'den geçiren 'full tunnel' yapılandırmalar, özellikle video konferans ve bulut uygulamaları gibi gecikmeye duyarlı trafiği gereksiz yere şirket merkezine yönlendirerek hem VPN gateway'ini hem de Wi-Fi WAN bağlantısını gereksiz yere yorar. Split tunneling ile yalnızca kurumsal kaynaklara giden trafiğin tünelden geçmesi sağlanırsa, hem VPN üzerindeki yük azalır hem de kullanıcı deneyimi iyileşir.

• UDP tabanlı tüneller Wi-Fi'ın değişken gecikmesine karşı daha dayanıklıdır
• TCP-over-TCP durumu, paket kaybında performansı katlanarak düşürür
• Split tunneling, VPN üzerinden yalnızca gerekli trafiği göndererek yükü azaltır
• 443 portu üzerinden TCP fallback yalnızca kısıtlı ağlarda geçici çözüm olmalı

Captive portal ve roaming kaynaklı kesintiler

Otel, kafe veya misafir ağlarında sık görülen bir senaryo: VPN istemcisi otomatik olarak bağlanmaya çalışır, ama ağ önce bir captive portal (web tabanlı giriş sayfası) ister. VPN tüneli captive portal'ın DNS yönlendirmesini ve HTTP yakalamasını engellediği için kullanıcı giriş sayfasını hiç göremez ve internet erişimi tamamen kesilmiş gibi görünür. Doğru sıralama şudur: önce VPN istemcisi kapatılmalı veya 'trusted network detection' özelliğiyle captive portal algılanana kadar VPN devre dışı bırakılmalı, portal üzerinden giriş tamamlandıktan sonra VPN yeniden etkinleştirilmelidir.

Kurumsal Wi-Fi tarafında ikinci büyük sorun roaming sırasında VPN oturumunun kopmasıdır. İstemci bir AP'den diğerine geçerken IP adresi aynı kalsa bile (aynı VLAN/subnet içinde) kısa bir kesinti (50-150 ms) yaşanır. Bu kesinti IPsec veya SSL VPN'in 'dead peer detection' zaman aşımını tetikleyebilir ve tünel tamamen yeniden kurulur — bu da kullanıcıya birkaç saniyelik tam kopma olarak yansır.

802.11r (Fast Transition) ve 802.11k/v desteği olan bir altyapıda roaming süresi 20-50 ms'ye iner ve VPN oturumu neredeyse hiç fark edilmeden korunur. Bu nedenle VPN kullanımının yoğun olduğu kurumsal ortamlarda roaming standartlarının (k/v/r) doğru yapılandırılması, VPN istemci ayarları kadar kritik bir parametre olarak değerlendirilmelidir.

F2 sahada nasıl çözüyor?

F2 mühendisleri VPN şikayetlerinde önce Wireshark ile uçtan uca paket yakalama yaparak MTU/MSS kaynaklı kara delik etkisini saptar, ardından Ekahau ile roaming performansını ölçüp 802.11k/v/r yapılandırmasını kontrol eder. Çoğu vakada tek başına MSS clamping ve doğru roaming ayarı, VPN şikayetlerinin büyük kısmını kalıcı olarak ortadan kaldırmaktadır; kalan vakalarda ise split tunneling politikası ve captive portal sıralaması yeniden tasarlanarak sorun köklü biçimde çözülür.