IPv6’ya geçişin teoride harika, pratikte ise tam bir mayın tarlası olduğunu biliyoruz. Hele ki işi bir adım öteye taşıyıp hem IPv4 hem de IPv6 trafiğini aynı VPN tünelinden geçirmeye (yani dual-stack yapmaya) karar verdiyseniz, tebrikler; kendinize çözmesi haftalar sürecek yepyeni problemler satın aldınız demektir. Ben son 15 yılda kurduğum, yönettiğim veya debug ettiğim hiçbir dual-stack VPN altyapısının ilk seferde “sorunsuz” çalıştığını görmedim.
Bu yazıda, kurumsal ağlarda ve kendi geliştirdiğim yan ürünlerin altyapılarında dual-stack VPN koştururken canımı sıkan, tüneli sürekli düşüren veya paketleri sessizce yutan o sinsi teknik detayları masaya yatırıyorum. Teorik RFC tanımlarını bir kenara bırakıp, sahada karşılaştığım gerçek senaryolar üzerinden neden bu yapının sürekli patladığını ve bu durumla nasıl başa çıktığımı anlatacağım.
## MTU ve MSS Mismatch Kabusu (Header Farkının Bedeli)
Dual-stack VPN’lerin en büyük ve en sessiz katili Maximum Transmission Unit (MTU) uyumsuzluğudur. Standart bir Ethernet çerçevesi 1500 byte veri taşır. Ancak tünele girdiğimizde işler değişir; IPv4 başlığı 20 byte iken, IPv6 başlığı sabit olarak 40 byte yer kaplar. Üzerine bir de VPN protokolünün (IPsec, OpenVPN veya WireGuard) şifreleme ve tünelleme yükü (overhead) bindiğinde, kullanılabilir alan iyice daralır.
Bir müşteri projesinde, kullanıcıların IPv4 sitelerine sorunsuz erişirken, IPv6 üzerinden çalışan bazı kurumsal web uygulamalarında sayfa yükleme esnasında donup kaldığını fark ettik. Trafiği tcpdump ile izlediğimde, IPv6 paketlerinin tünel sınırında parçalandığını (fragmentation) ve tünel yolundaki bazı router’ların ICMPv6 “Packet Too Big” mesajlarını güvenlik gerekçesiyle engellediğini gördüm. Bu durum, meşhur Path MTU Discovery (PMTUD) mekanizmasını tamamen işlevsiz hale getiriyordu.
Aşağıdaki tabloda, farklı VPN protokollerinde IPv4 ve IPv6 için kalan maksimum MSS (Maximum Segment Size) değerlerinin nasıl değiştiğini görebilirsiniz:
| Protokol | IPv4 MTU | IPv4 MSS | IPv6 MTU | IPv6 MSS |
|---|---|---|---|---|
| Standart Ethernet | 1500 | 1460 | 1500 | 1440 |
| WireGuard (Standart) | 1420 | 1380 | 1420 | 1360 |
| IPsec (AES-GCM-256) | 1400 | 1360 | 1400 | 1340 |
| OpenVPN (UDP + AES) | 1360 | 1320 | 1360 | 1300 |
Bu sorunu çözmek için tünel arayüzlerinde MSS clamping uygulamak şarttır. Ben genellikle Linux tabanlı VPN gateway sunucularında nftables veya iptables kullanarak MSS değerini IPv6 için agresif bir şekilde aşağıya çekiyorum.
# IPv4 için MSS Clamping (PMTUD çalışmadığında hayat kurtarır)
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# IPv6 için MSS Clamping (En az 40 byte daha düşük olmalı)
ip6tables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1340Eğer bu ayarı yapmazsanız, küçük boyutlu ping paketleri tünelden geçerken, büyük boyutlu HTTP POST istekleri veya veritabanı sorguları tünelin ortasında kaybolur. Daha önce yazdığım network segmentasyonu makalesinde de belirttiğim gibi, paket boyutlarını optimize etmeden stabil bir WAN kurmak imkansızdır.
## DNS Sızıntıları (DNS Leak) ve IPv6 Bypassing Sıkıntısı
Dual-stack VPN yapılandırmalarında en sık yapılan hata, istemciye sadece IPv4 DNS sunucusu dağıtıp IPv6 DNS adreslerini boş bırakmaktır. Modern işletim sistemleri (Windows 10/11, macOS ve güncel Linux dağıtımları), eğer ağda bir IPv6 çıkışı varsa, DNS sorgularında öncelikli olarak IPv6’yı tercih eder.
Bir bankanın iç platformu için uzaktan erişim altyapısı kurarken, test kullanıcılarının VPN aktifken bile şirketin iç alan adlarını (internal domains) çözemediğini, onun yerine internet servis sağlayıcılarının (ISP) genel DNS sunucularına gittiklerini gördük. Sebebi basitti: VPN tüneli sadece IPv4 DNS’i (10.0.0.5 gibi) push ediyordu. Ancak kullanıcının evindeki router, bilgisayara bir IPv6 DNS adresi de atamıştı. Bilgisayar, IPv6 DNS’i yerel (ve güvensiz) hattan sorguluyor, şirket içi alan adları dışarıya sızıyor ve çözülemiyordu.
Bu sızıntıyı doğrulamak için tünel etkinken terminalden şu komutu çalıştırıp hangi DNS sunucularının yanıt verdiğini kontrol ederim:
# Windows tarafında aktif DNS sunucularını listeleme
Get-DnsClientServerAddress -AddressFamily IPv6
# Linux tarafında resolve durumunu kontrol etme
resolvectl status tun0Çözüm, VPN sunucu konfigürasyonunda hem IPv4 hem de IPv6 DNS adreslerini açıkça tanımlamak ve istemciye “tüm trafiği (0.0.0.0/0 ve ::/0) tünelden geçir” (Full Tunnel) kuralını dayatmaktır. Eğer Split Tunnel yapıyorsanız, IPv6 routing tablonuzun şirket içi IPv6 bloklarını eksiksiz kapsadığından emin olmalısınız.
## Happy Eyeballs Protokolü (RFC 8305) ve Tüneldeki Kararsızlık
İşletim sistemleri ve tarayıcılar, bir web sitesine bağlanırken IPv4 ve IPv6 adreslerinden hangisinin daha hızlı yanıt vereceğini test etmek için “Happy Eyeballs” (RFC 8305) algoritmasını kullanır. Bu algoritma, her iki adrese de neredeyse eş zamanlı bağlantı istekleri gönderir. Hangisinden milisaniyeler mertebesinde daha hızlı cevap gelirse, tüm trafiği o IP ailesi üzerinden akıtır.
VPN tüneli işin içine girdiğinde bu mekanizma kararsızlığa neden olur. Genellikle IPv4 trafiği VPN ağ geçidinde NAT (Network Address Translation) işlemine tabi tutulurken, IPv6 trafiği uçtan uca yönlendirilir (routing). NAT işlemi az da olsa bir gecikme (latency) yaratır. Bu durum, Happy Eyeballs algoritmasının sürekli IPv6’yı seçmesine yol açar. Ancak VPN üzerindeki IPv6 tüneli stabil değilse veya paket kaybı yaşıyorsa, bağlantı sürekli kopup tekrar kurulur.
İstemci (Dual-Stack)
│
├───[ Happy Eyeballs Testi ]
│ ├─── IPv4 SYN (VPN Tüneli + NAT) ───> Daha yavaş yanıt
│ └─── IPv6 SYN (Doğrudan Tünel) ───> Daha hızlı yanıt (Kazanan!)
│
└───> Tüm session IPv6 üzerinden kurulur.
└───> IPv6 tünelinde MTU sorunu varsa bağlantı donar!Mobil istemcilerin API’ye bazen anında bağlanıp bazen uzun uzun beklediği bir durumda, kök sebep tam olarak budur: operatörlerin IPv6 tünellerindeki dengesiz gecikme süreleri yüzünden Happy Eyeballs stabil olmayan IPv6 yolunu seçer ve kullanıcılar drop yer.
Bu kararsızlığı engellemek için VPN sunucusunun çıkışındaki yönlendirme metriklerini (metric/distance) çok hassas ayarlamak gerekir. IPv6 rotalarının metriğini, IPv4 rotalarına göre biraz daha yüksek (yani daha az tercih edilir) tanımlamak, bu yapay yarışın önüne geçebilir.
## İşletim Sistemlerinin Routing Öncelikleri (Windows vs. Linux/macOS)
VPN tüneli kurulduğunda, işletim sisteminin routing tablosuna yeni rotalar eklenir. Ancak her işletim sistemi bu rotaların önceliğini (metric) farklı hesaplar. Windows, arayüz hızına göre otomatik metrik ataması yaparken (Automatic Metric), Linux ip route tablosundaki spesifik kuralları takip eder.
Özellikle Windows 11 üzerinde dual-stack VPN kullanırken, fiziksel Wi-Fi arayüzünün IPv6 metriği, VPN sanal arayüzünün (TAP/TUN) IPv6 metriğinden daha düşük (yani daha öncelikli) kalabiliyor. Bu durumda Windows, “nasıl olsa dışarıda da IPv6 var” diyerek VPN tünelini tamamen bypass ediyor ve trafiği doğrudan evdeki router üzerinden internete gönderiyor.
Bunu çözmek için VPN istemci profilinde arayüz metriklerini elle (manual metric) ezmek zorundayız. Linux tarafında bu işi iproute2 ile tünel ayağa kalktığında çalışan bir script ile çözüyorum:
#!/bin/bash
# tünel arayüzü: tun0
# Fiziksel arayüzün IPv6 rotasını ezmek için metric değerini yükseltiyoruz
ip -6 route add default dev tun0 metric 50
ip -6 route append default dev wlan0 metric 1000Windows tarafında ise OpenVPN veya WireGuard config dosyasına route-metric parametresini eklemek veya PowerShell üzerinden arayüz metriğini sabitlemek gerekiyor. Aksi takdirde, işletim sistemi kendi kafasına göre en hızlı gördüğü yolu seçip tünel dışına çıkacaktır.
## Güvenlik Duvarı Politikalarındaki Asimetri ve Unutulan Kurallar
Gözlemlediğim en büyük güvenlik açıkları ve erişim sorunları genellikle asimetrik firewall kurallarından kaynaklanıyor. Sistem yöneticileri (ben dahil bir dönem) IPv4 tarafındaki iptables, nftables veya kurumsal firewall kurallarını satır satır yazar, test eder ve sıkılaştırır. Ancak iş IPv6’ya geldiğinde, “nasıl olsa kimse kullanmıyor” veya “henüz test aşamasındayız” denilerek IPv6 kuralları ya es geçilir ya da tamamen kapatılır.
Tipik senaryo şudur: kritik bir subnet’i sadece belirli IPv4 IP’lerine izin verecek şekilde izole edersiniz, ama sisteme dual-stack VPN entegre edildiğinde IPv6 havuzundan IP alan bir istemci, ip6tables kuralları yazılmadığı için aynı subnet’e doğrudan erişebilir. IPv4 tarafında özenle kapattığınız kapı, IPv6 tarafında ardına kadar açık kalır.
Aşağıda, dual-stack bir Linux VPN gateway üzerinde hem IPv4 hem de IPv6 için paralel işletilmesi gereken temel firewall kurallarına bir örnek veriyorum:
# IPv4 Kuralları (iptables)
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP
# IPv6 Kuralları (ip6tables) - Birebir eşleşmeli!
ip6tables -A FORWARD -i tun0 -o eth0 -s fd00:db8:a::/64 -d fd00:db8:b::/64 -j ACCEPT
ip6tables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -P FORWARD DROPEğer altyapınızda IPv6 için ayrı bir güvenlik politikası işletmiyorsanız, dual-stack VPN’i aktif ettiğiniz an ağınızda devasa bir arka kapı açmış olursunuz. Her IPv4 kuralının, IPv6 tarafında da bir karşılığı olmak zorundadır.
## Çözüm Ne? Pragmatik Bir Yaklaşım ve Geçici Çözümler
Eğer tüm bu anlattıklarım gözünüzü korkuttuysa, haklısınız. Gerçekten de kurumsal bir ortamda dual-stack VPN yönetmek, harcadığınız efora değmeyen bir operasyonel yük getirebilir. Peki ben ne yapıyorum? İşte sahada uyguladığım ve hayat kurtaran pragmatik yaklaşımlar:
- Gerekmedikçe IPv6’yı Tünelde Taşımayın: Eğer şirket içi uygulamalarınızın (ERP, veritabanları, dosya sunucuları) IPv6 desteğine hayati bir ihtiyacı yoksa, VPN tünelini sadece IPv4-only olarak yapılandırın. İstemcinin IPv6 trafiğini ise tünel dışında (local breakout) bırakın.
- NAT64 ve DNS64 Kullanımı: Eğer istemcileriniz sadece IPv6 ağlarında bulunuyorsa (örneğin bazı mobil operatörler sadece IPv6 IP veriyor), VPN sunucusu tarafında NAT64 ve DNS64 kurarak, istemcinin IPv6 üzerinden gelmesini sağlayıp iç ağda onu tekrar IPv4’e çevirebilirsiniz. Bu sayede tünelin içi temiz kalır.
- WireGuard Tercihi: Eğer mutlaka dual-stack yapacaksanız, OpenVPN veya IPsec yerine WireGuard kullanın. WireGuard, yapısı gereği dual-stack trafiği çok daha hafif ve stabil bir şekilde taşır; MTU uyumsuzluklarına karşı daha toleranslıdır.
Daha önce ele aldığım fail2ban yapılandırması gibi konularda da değindiğim üzere, sistem yönetiminde en iyi kural, karmaşıklığı en aza indirmektir. Dual-stack VPN, doğası gereği karmaşıklığı iki katına çıkarır. Eğer bu yolu seçecekseniz, yukarıda bahsettiğim MTU, DNS ve routing detaylarına hakim olmalı ve her adımı monitör etmelisiniz.
Net pozisyonum şudur: Altyapınız uçtan uca tamamen IPv6’ya hazır olmadıkça, VPN üzerinde dual-stack fantezisine girmeyin. IPv4 hala çalışıyor ve uzunca bir süre daha çalışmaya devam edecek. Kendinize gereksiz gece nöbetleri yaratmayın.