IPv6 Dağıtımı, Dual-Stack ve CDN’den Son Kullanıcıya Sorun Giderme

IPv6 dağıtımı artık yalnızca “ek protokol” değildir; CDN, web uygulaması, güvenlik duvarı ve DNS birlikte çalışmadığında kullanıcı tarafında hatalar hızlı şekilde görünür hale gelir. Bu rehberde, modern hosting mimarisinde IPv6 dual-stack (aynı anda IPv4+IPv6) kurulumunu, CDN’den son kullanıcıya giden trafiğin nasıl doğrulanacağını ve tipik sorunların nasıl giderileceğini net bir akışla ele alacağız. Amaç; dağıtım yaptığınız anda “neden bazı kullanıcılar hata görüyor?” sorusuna ölçülebilir kanıtlarla cevap vermenizi sağlamaktır.

IPv6 dual-stack hedefi: Ne kuruyorsunuz, neyi test ediyorsunuz?

Dual-stack yaklaşımında web siteniz iki farklı IP ailesinden erişilebilir olur:

• IPv4: Kullanıcıların büyük kısmı hâlâ bu yolla gelir.
• IPv6: Daha geniş adresleme ve daha iyi yönlendirme ile gecikme/rota kalitesi hedeflenir.

Modern hosting’te tipik akış şudur: 1. Sunucuda (VPS/VDS/dedicated) ağ arayüzüne IPv6 adresi tanımlanır. 2. Reverse proxy / web sunucusu (Nginx/Apache) IPv6 dinler. 3. Güvenlik kuralları (firewall, security group) IPv6 trafiğe izin verir. 4. DNS kayıtları (AAAA) ile alan adı IPv6’ya bağlanır. 5. CDN üzerinden gelen istekler origin’e giderken CDN–origin arası bağlantı IPv4/IPv6 seçimine göre davranır. 6. Son kullanıcı tarafında tarayıcı, CDN edge ve origin zinciri test edilir.

Buradaki kritik nokta: Sadece “sunucuda IPv6 var” demek yetmez. CDN edge’den origin’e giden bağlantı, origin’in IPv6 dinleyip dinlemediği ve DNS’in AAAA kaydının doğru çalışıp çalışmadığı aynı anda kontrol edilmelidir.

Dual-stack karar matrisi: Hangi protokol varsayılır?

Aşağıdaki tablo, pratikte hangi bileşenin hangi IP ailelerini “tercih ettiği”nin sorun çıkarma ihtimalini gösterir:

IPv6 dağıtım adımları: Sunucu, web sunucusu ve DNS

Aşağıda “kesintisiz” ilerlemek için izlenebilecek net sıralama var.

1) Sunucuda IPv6 adresini ve yönlendirmeyi doğrulayın

Önce sunucunuzun gerçekten IPv6 aldığını doğrulayın.

• Arayüzlerde IPv6 adres var mı?
• ip -6 addr show
• IPv6 ile temel iletişim var mı? (kendi networkünüz içinde)
• ping -6 -c 3 <yerel-gateway-veya-uygun-hedef>

Ek olarak, kernel yönlendirme ayarlarına bakın: - IPv6 forwarding gerekiyorsa (ör. reverse proxy/masquerade senaryoları): - sysctl net.ipv6.conf.all.forwarding

Beklenen: forwarding gerekiyorsa 1, gerekmiyorsa 0 ve buna uygun firewall kural seti.

2) Web sunucusunun IPv6 dinlediğini kontrol edin

Nginx örneği için: - Nginx site konfigünde listen [::]:443 ssl; ve/veya listen [::]:80; bulunmalıdır.

Hızlı doğrulama: - ss -ltnp | grep -E '(:80|:443).*\[::\]|\[::\]:'

Apache için de benzer şekilde Listen/VirtualHost içinde IPv6 tanımları gerekir.

3) Firewall (iptables/nftables) IPv6 kuralı içeriyor mu?

En yaygın dual-stack hatası: IPv4 kuralı vardır ama IPv6 kuralı yoktur.

• UFW kullanıyorsanız tipik kontrol:
• ufw status verbose
• nftables/iptables ise kuralların IPv6 tablosuna uygulandığından emin olun.

Hedef: 80/443 (ve gerekiyorsa 25/53 gibi ek portlar) IPv6 üzerinden de kabul edilmelidir.

4) DNS’te AAAA kaydını doğru yayına alın

IPv6 dağıtımında DNS’in rolü net: AAAA kaydı, son kullanıcıdan CDN’e (veya doğrudan origin’e) giden yolun başlangıcıdır.

Önce kayıtları kontrol edin: - dig AAAA example.com +short - dig A example.com +short

Yayına almadan önce şu iki noktayı belirleyin: 1. AAAA kaydı doğru hedefi gösteriyor mu? 2. TTL değeri nedir? (zorunlu değişiklikte hızlı geri dönüş için düşük TTL işe yarar)

CDN ile IPv6: Edge’den origin’e gidişin teşhisi

CDN kullandığınızda iki ayrı bağlantı zinciri oluşur: - Son kullanıcı -> CDN edge - CDN edge -> origin (sunucu)

IPv6 sorunlarının çoğu, ilk zincirin çalışıp ikinci zincirin çalışmamasından doğar. Bu yüzden CDN konfigürasyonu ve origin erişimi aynı anda incelenmelidir.

CDN’de IPv6 ile ilgili temel ayarlar

CDN panelinde genellikle şu başlıklar bulunur: - Origin protokol seçimi: HTTP/HTTPS - Origin IP kullanımı: “hostname çözümlemesi” veya “hard-coded IP” - “IPv6 support” / “dual stack” seçenekleri (servise göre değişir) - Cache davranışı (bazı CDN’lerde varyant/accept header etkisi)

Net hedef: CDN’in origin’e giderken IPv6 üzerinden bağlanma seçimi yapmasını kontrol edin.

Uçtan uca test: Son kullanıcı gibi bakın

Tarayıcı yerine komut satırı ile test etmek daha hızlı teşhis sağlar.

Örnek yaklaşım: 1. CDN edge’den origin’e çıkışın gerçekten IPv6 üzerinden gidip gitmediğini gözlemleyin. 2. Origin’in loglarında IPv6 kaynak/IP veya IPv6 bağlantı görüldüğünden emin olun.

Origin tarafında log formatı yeterli değilse geçici olarak şu kontroller yapılır: - Web sunucusu access loglarında client adresi IPv6 geliyor mu? - Reverse proxy kullananlarda real_ip/X-Forwarded-For zinciri IPv6 taşınıyor mu?

CDN’den kaynaklanan tipik hata türleri

Aşağıdaki belirtiler doğrudan “nereye bakmalıyım?” sorusunu daraltır.

• IPv6 kullanıcılarında 5xx, IPv4’te her şey iyi
• En olası sebepler: origin IPv6 dinlemiyor, firewall IPv6’ı drop ediyor, CDN edge origin’e IPv6 ile bağlanamıyor.
• Sadece bazı ülkelerde IPv6 bozuk
• Rota/peering farklılıkları veya CDN edge seçimi farklı olabilir; origin erişimi yine kontrol edilmelidir.
• 404/301 döngüsü sadece IPv6’da
• Uygulama URL’lerini üretirken IPv4/IPv6 tabanlı redirect hatası, yanlış scheme/host hesabı olabilir.

Sorun giderme akışı: Hata aldığınız anda doğru sırayla kontrol

Bu bölüm, “CDN + dual-stack + IPv6 dağıtımı” karmaşasında en çok zaman kaybettiren kısmı düzenler: kontrol sırası.

Adım 1: DNS katmanı

1) AAAA kaydı doğru mu? - dig AAAA example.com +short

2) Yayılım (propagation) tamam mı? - Farklı resolver’lardan test edin (local cache yanıltabilir).

Adım 2: CDN edge katmanı

1) Edge üzerinden erişimde IPv6 gerçekten kullanılıyor mu? - CDN servisinizin sağladığı rapor/diagnostic araçlarını kullanın (varsa). - Yoksa; kullanıcıdan bağımsız doğrulama için IPv6 testlerini komut satırından yapın.

Örnek: IPv6 ile zorlayarak deneme (Linux): - curl -6 -I https://example.com

Beklenen: 200/301 gibi doğru yanıt; 5xx görürsen origin tarafına geçin.

Adım 3: Origin katmanı (sunucu + web sunucusu + firewall)

1) Origin IPv6 dinliyor mu? - ss -ltnp | grep ':443' - :::443 veya [::]:443 görmelisiniz.

2) Firewall IPv6’a izin veriyor mu? - nft list ruleset veya ufw status verbose (kullandığınız araca göre)

3) Origin loglarında IPv6 bağlantı var mı? - Access log son istekleri kontrol edin.

Adım 4: Reverse proxy ve üst başlıklar (X-Forwarded-For)

CDN, client IP bilgisini X-Forwarded-For ile taşır. Bazı sistemlerde IPv6 formatı beklenenden farklı olduğunda uygulama istemci IP’yi yanlış okuyabilir.

Net kontrol: - Reverse proxy konfigünde real_ip_header doğru mu? - Loglarda “client IP” olarak doğru değer geliyor mu?

Dual-stack sorunları için net çözüm kalıpları

Aşağıdaki çözümler, teşhis adımlarında çıkan bulgulara göre doğrudan uygulanabilir.

Çözüm 1: Origin IPv6 dinlemiyor

Belirti: - curl -6 başarısız, origin loglarına IPv6 istekleri hiç düşmüyor.

Uygulama: - Nginx’te listen [::]:80; ve listen [::]:443 ssl; ekleyin. - Apache’te VirtualHost ve Listen ayarlarını IPv6’yı kapsayacak şekilde güncelleyin.

Çözüm 2: Firewall IPv6 drop ediyor

Belirti: - Nginx/Apache dinliyor ama curl -6 zaman aşımına gidiyor.

Uygulama: - IPv6 için 80/443 kuralını ekleyin. - Değişiklik sonrası curl -6 -I ile doğrulayın.

Çözüm 3: CDN origin’e IPv6 ile bağlanamıyor

Belirti: - CDN IPv4’te çalışıyor, IPv6’da 5xx/timeout.

Uygulama: - CDN panelinde origin bağlantı ayarını kontrol edin: - Origin’i “hostname” ile çözümleyip AAAA’yı kullanıyor mu? - Origin IP’yi statik giriyorsanız IPv6 adresi girildi mi? - Origin DNS/AAAA kayıtlarının CDN çözümlemesinde doğru görünmesi gerekir.

Çözüm 4: Uygulama redirect döngüsü yapıyor

Belirti: - Sadece IPv6’da 301/302 döngüsü veya yanlış host/scheme.

Uygulama: - Uygulamanın “client scheme/host” değerlerini CDN header’larından doğru okuduğunu doğrulayın. - X-Forwarded-Proto, X-Forwarded-Host ve X-Real-IP zincirini kontrol edin.

Performans ve kalite: IPv6 dağıtımında ölçüm kriterleri

IPv6’ı devreye aldığınızda yalnız “çalışıyor mu” değil “iyi mi” sorusu da önemlidir. Aşağıdaki ölçümler kararınızı hızlandırır.

Ölçüm 1: Yanıt süresi (TTFB) ve hata oranı

• IPv4 ve IPv6 isteklerini ayrı ayrı karşılaştırın.
• Uygulama katmanında 5xx artışı var mı?

Pratik kontrol: - Loglardan HTTP durum kodlarını ayırın. - CDN analitiklerinde “status dağılımı”nı IPv6 varyantında inceleyin.

Ölçüm 2: Cache isabet oranı

IPv6’da farklı cache anahtarı oluşursa (ör. varyant/headers farklıysa) cache Miss artar.

Kontrol: - CDN cache anahtarı ayarlarında gereksiz varyant ekleniyor mu? - Response header’lar (vary) IPv6 ve IPv4’te farklı mı?

Son kontrol listesi: Dual-stack yayından önce net doğrulama

Dağıtımı “tamam” saymadan önce şu maddeleri sırayla geçin:

• [ ] dig AAAA example.com doğru IPv6 adresini dönüyor.
• [ ] Origin web sunucusu IPv6’da dinliyor (ss -ltnp kontrolü).
• [ ] Firewall IPv6’ta 80/443 izin veriyor.
• [ ] curl -6 -I https://example.com beklenen HTTP durum kodunu veriyor.
• [ ] CDN panelinde origin bağlantı tipi IPv6/dual-stack ile uyumlu.
• [ ] Origin access loglarında CDN’den gelen istekler ve doğru IP/forward header akıyor.
• [ ] IPv4 ve IPv6 hata oranı kıyaslaması yapılmış (5xx/timeout).

Ne yapmalısınız? (Aksiyon önerisi)

NetKıyas mantığıyla ilerleyin: “IPv6 açtım” yerine DNS AAAA + origin IPv6 dinleme + firewall IPv6 + CDN origin bağlantısı dörtlemesini aynı anda doğrulayın. İlk aşamada TTL’i düşük tutarak AAAA değişikliklerini kontrollü yapın; ardından curl -6 testleri ve origin log doğrulamasıyla sorun çıkarsa hızlı geri dönüş sağlayın. Bu rehberi uyguladığınızda dual-stack dağıtımındaki belirsizlik yerini ölçülebilir teşhise bırakır ve CDN–origin zincirinde nerede kırıldığını net olarak belirlersiniz.