Ofiste Bir Kahve, IPv6‑Only Bir Sunucu ve O Meşhur “Peki IPv4?”
Hiç başınıza geldi mi? Hızlıca bir VPS açıyorsunuz, sistem yağ gibi akıyor, fiyat da cazip. Kurulumu yaparken fark ediyorsunuz: Sunucu sadece IPv6. O an masadaki kahveye bakıp bir nefes alıyorsunuz. “Tamam, modern dünya, IPv6 güzel; ama IPv4 kullanıcıları ne olacak?” diyorsunuz. Örneğin, küçük ama yoğun ziyaret alan bir blogu yalnızca IPv6 veren bir sağlayıcıya taşımayı düşünün. İş performans ve maliyetti; ama işin görünmeyen tarafında bağlantı dünyasının iki dili vardı: IPv6 ve IPv4.
Bu örnek senaryoda ziyaretçilerin bir kısmı yalnız IPv4 kullanıyor, origin sunucu ise IPv6-only. İki ayrı bağlantı ihtiyacı vardır: IPv4 ziyaretçiler için IPv6 origin destekleyen bir CDN veya ters vekil; sunucunun IPv4 kaynaklarına çıkması için NAT64/DNS64. Rehber bu iki akışı, DNS kayıtlarını ve yönlendirme koşullarını ayrı ele alır. Uygulama kurulumu öncesinde gereken paket depolarına ve API’lere erişimi de doğrulamak gerekir.
Önce Resmi Büyütelim
IPv6‑only VPS; sağlayıcınızın size sadece IPv6 adresi verdiği, yani sunucunuzun tek dilinin IPv6 olduğu bir ortam demek. Neden tercih edilir? Genelde iki sebep ağır basıyor: Maliyet ve sadelik. Bazı sağlayıcılar IPv4 adresini ekstra ücretli veriyor. Bazen de yeni bir küme tasarlarken “önce IPv6’ı düzgün kuralım, IPv4’ü dışarıda köprüyle çözeriz” fikri pratik geliyor. Kulağa hoş geliyor, değil mi?
Burada önemli bir ayrımı baştan netleştirelim: NAT64/DNS64 esasen “IPv6 konuşan bir makinenin IPv4 dünyasına ulaşması” için harika bir yöntemdir. Yani sunucunuz dışarı çıkıp IPv4‑only bir kaynağa (mesela bir paket deposu, bir üçüncü taraf API’si) erişmek isterse, NAT64/DNS64 devreye girip tercümanlık yapar. Peki IPv4 kullanıcıları sitenize nasıl erişecek? Onun için küçük bir hilemiz var: Dışarıda bir “köprü” oluşturmak. Bu köprü bazen bir CDN’nin proxy özelliğidir, bazen de sizin kurduğunuz ufak bir ters vekil sunucu. İki dünyayı bir masada buluşturuyoruz.
Bu arada IPv6 dünyasına yumuşak geçişi merak ediyorsanız, şu yazıya bakabilirsiniz: IPv6 benimseme dalgası ne zaman sizin ağa çarpar? Bence arka plana hâkim olmak, teknik tercihleri çok daha rahat kılıyor.
Sitenizi Yayına Almak: DNS, SSL ve Nginx Tarafı
AAAA kaydını yazmadan olmaz
Doğrudan IPv6 erişimi seçiyorsanız kullanılacak her adı DNS’te yayımlayın: bu örnekte hem example.com hem www.example.com aynı origin IPv6 adresini göstermelidir; www için uygun bir CNAME de kullanılabilir. 2001:db8:abcd::f yalnız belgeleme adresidir, yerine size tahsis edilmiş adresi koyun. Aşağıdaki Nginx HTTP yönlendirmesi example.com adresine gittiğinden yalnız www kaydı eklemek yeterli değildir. Origin’in IPv4 adresi yoksa ona ait bir A kaydı uydurmayın; IPv4 erişimini seçtiğiniz CDN/proxy veya köprü adresi sağlar. CDN kullanılıyorsa kayıtları sağlayıcının yöntemiyle yapılandırın ve her iki adın dönen A/AAAA yanıtlarını doğrulayın.
SSL sertifikası: IPv6’da da aynı konfor
SSL konusunda korkulacak bir şey yok. Let’s Encrypt IPv6’da da harika çalışıyor. Eğer HTTP-01 doğrulaması için 80 numaralı porta erişim sağlamak zahmetli ise veya wildcard sertifika istiyorsanız, DNS tabanlı doğrulamayı seçin. Otomasyon şöyle kurulabilir: ACME istemcisi DNS sağlayıcısına sınırlı bir API izniyle TXT kaydını ekliyor, sertifika otomatik yenileniyor. İlgilenenler için şuradaki rehber işinizi hızlandırır: Let’s Encrypt Wildcard SSL otomasyonu.
Nginx tarafında ufak bir iskelet
Aşağıdaki örnek yalnız statik bir site içindir. /var/www/example-static dizinine sadece yayımlanması amaçlanan dosyaları koyun; WordPress veya PHP uygulaması için ayrıca doğrulanmış bir PHP-FPM/FastCGI işleyicisi gerekir. HTTPS bloğunu etkinleştirmeden önce DNS-01 gibi bağımsız bir yöntemle example.com ve www.example.com adlarını kapsayan sertifikayı alın; dosya yollarını gerçek kurulumunuza uyarlayın. HTTP-01 seçerseniz önce çalışan, yalnız HTTP challenge sunan yapılandırmayla ilk sertifikayı alın, ardından HTTPS bloğunu ekleyin. Sertifika dosyaları yokken bu tam yapılandırma yüklenmez.
server {
listen [::]:80;
server_name www.example.com example.com;
location /.well-known/acme-challenge/ {
root /var/www/letsencrypt;
}
location / {
return 301 https://example.com$request_uri;
}
}
server {
listen [::]:443 ssl;
server_name www.example.com example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/example-static;
index index.html;
location ~* \.php {
return 404;
}
location / {
try_files $uri $uri/ =404;
}
}
İleride statik dosyalar için önbellek süresi ve sıkıştırma eklenebilir. Önce nginx -t ile yapılandırmayı kontrol edin; başarılıysa kontrollü yeniden yükleyin. İki alan adını, sertifikayı, eksik dosya yanıtını ve yenileme sürecini doğrulayın.
Peki IPv4 Kullanıcıları Sitenizi Nasıl Görecek? Üç Pratik Yol
İşin kalbi burada. Sunucunuz IPv6‑only. IPv4 kullanıcıları var ve onlar sitenizi görmek istiyor. Birinin onların dilini dinleyip sizinkine çevirmesi gerekiyor. Bu rolü üstlenecek üç pratik yöntem var ve hepsi de günlük hayatta gayet işe yarıyor.
1) CDN veya Bulut Proxy: En kolayı, çoğu zaman da en akıllısı
IPv4 istemcileri ve IPv6 origin bağlantılarını destekleyen bir CDN’de alan adınız için “proxy” özelliğini açarsınız. CDN, IPv4 konuşan ziyaretçiyi karşılar; sizdeki IPv6 origin’e trafiği kendi içinde çevirip gönderir. Performans ve güvenlik kazanımları hizmete, plana ve yapılandırmaya bağlıdır. DDoS, WAF, cache… Bir taşla epey kuş. Proxy mantığını anlatan kısa bir dokümana göz atmak isterseniz, şu sayfa net özetliyor: Cloudflare’ın proxy (turuncu bulut) mantığının kısa özeti. Buradaki fikir, A/AAAA kayıtlarınızdaki trafiğin doğrudan değil, CDN üstünden akması.
2) Küçük bir “köprü” VPS: Dual‑stack bir ters vekil
CDN istemiyorsanız veya bazı özel protokoller kullanıyorsanız, minik bir dual‑stack VPS’i köprü yapabilirsiniz. Bu makinede Nginx/HAProxy dinler, IPv4’ten gelen isteği IPv6’daki asıl sunucunuza taşır. Kayıt tarafında A kaydı köprüye, AAAA ise doğrudan origin’e bakabilir. Böylelikle iki dünyanın trafiği akıllıca dağılır. Küçükten başlayıp büyüdükçe birden fazla köprüyle yükü paylaştırabilirsiniz. DNS ve TTL ayarlarken kesintisiz geçişi önemseyenler için, şu rehber yararlı olabilir: Zero‑downtime için TTL stratejileri.
3) NAT46/SIIT‑DC: Veri merkezinde protokol çeviri kapısı
Daha altyapısal bir çözüm istiyorsanız, veri merkezinde stateless çeviri (SIIT‑DC) veya NAT46 yapan bir kapı kurulur. Bu kapı, IPv4’ten gelen isteği IPv6’ya çevirdikten sonra sizin sunucunuza iletir. Kulağa biraz “network” gibi geliyor ama modern araçlarla epey basitleşti. Bu alanda Jool favorim; hem NAT64 hem de SIIT tarafını temiz çözüyor. Küçük kurulumlarla başlayıp, ihtiyaç oldukça politikaları genişletebilirsiniz.
Özet: CDN kullanırsanız en çabuk sonuca varırsınız. Köprü VPS esnektir, kontrol sizdedir. SIIT‑DC ise daha mimari, uzun ömürlü bir köprü gibidir. Hangi yolu seçerseniz seçin, fikir aynı: IPv4’ten gelen isteği bir şekilde IPv6’daki sunucunuza taşımak.
NAT64/DNS64 Ne İşe Yarar? Sunucunuzun Dış Dünyaya Erişmesi
Az önce inbound (ziyaretçi → siz) trafiği konuştuk. Şimdi outbound (siz → dış dünya) tarafına bakalım. Diyelim paket kuracaksınız; ama depo sadece IPv4’te. Veya bir API’ye istek atacaksınız, yine IPv4. İşte burada NAT64/DNS64 imdadınıza yetişir. Kısaca mantığı şöyle: DNS64, yalnızca A kaydı olan bir alan adı için yapay bir AAAA kaydı üretir; NAT64 ise bu yapay IPv6 adresini gerçekten IPv4’e çevirip iletişimi sağlar. Yani sunucunuz kendini yalnız hissetmez; IPv4 dünyasına konuşabilir.
Peki bunu kim sağlar? Bazı sağlayıcılar altyapıda NAT64/DNS64 sunar, siz fark bile etmezsiniz. Sunmuyorlarsa dert değil: Küçük bir dual‑stack makineye DNS64 çözümleyici ve NAT64 kapısı kurup, IPv6‑only VPS’inizi o DNS’e yönlendirirsiniz. Ayrıca sentezlenen IPv6 öneki için trafiğin NAT64 kapısına yönlendirilmesi ve dönüş yolunun kurulması gerekir. IPv6 soketlerini ve DNS adlarını kullanan curl, apt, hatta bazı dil paket yöneticileri bile IPv4 kaynaklara erişebilir hale gelir.
Pratik Bir Kurulum Örneği: Küçük Bir NAT64/DNS64 Kapısı
DNS64 için Unbound
Dual‑stack küçük bir VPS’te, DNS64 özelliği olan bir çözümleyici kurulur. Unbound bu iş için hafif ve güvenilir. DNS64 yapılandırmasına ek olarak NAT64 kapısına yönlendirme ve çözümleyiciye istemci erişimi gerekir. Belgelere göz atmak isterseniz: Unbound yapılandırma kılavuzu. Temel fikir, DNS64’ün NAT64 kapısıyla aynı öneki kullanarak yapay AAAA üretmesidir; bu örnekte 64:ff9b::/96 kullanılır.
Bu parça mevcut paket yapılandırmasına uyarlanmalıdır. 2001:db8:64::1 çözümleyici, 2001:db8:64::10 ise tek yetkili istemci için belgeleme adresleridir; kullanmadan önce sahip olduğunuz erişilebilir adreslerle değiştirin. Dinleme adresini ve TCP/UDP 53 güvenlik duvarı iznini yalnız güvenilen istemci yoluyla sınırlandırın. Diğer include dosyalarındaki geniş izinleri de denetleyin.
server:
interface: 127.0.0.1
interface: ::1
interface: 2001:db8:64::1
access-control: 0.0.0.0/0 refuse
access-control: ::/0 refuse
access-control: 127.0.0.1/32 allow
access-control: ::1/128 allow
access-control: 2001:db8:64::10/128 allow
do-ip4: yes
do-ip6: yes
module-config: "dns64 validator iterator"
dns64-prefix: 64:ff9b::/96
Mevcut trust-anchor ve dağıtım ayarlarını koruyun; DNS64 modül desteğini ve yapılandırmayı kontrol edin. Yetkili istemcinin cevap alabildiğini, yetkisiz kaynaktan çözümleme yapılamadığını sınayın. İstemciden sentezlenen öneke giden yol NAT64 kapısına ulaşmalıdır; sadece DNS adresini değiştirmek yeterli değildir.
IPv6‑only sunucunuzun DNS çözümleyicisi olarak bu Unbound’u kullanması, uygun AAAA sorgularında yalnızca A kaydı bulunan adlar için AAAA sentezlenmesini sağlar. Sentezlenen adreslere erişim ayrıca çalışan bir NAT64 geçidi ve ona yönlendirme gerektirir.
NAT64 için Jool
Bu örnek yalnız dışarı yönlü, stateful NAT64 içindir. Desteklenen Jool sürümünü kurun; IPv6 istemcilerin sentez önekini bu kapıya, IPv4 yanıtlarının da tahsisli havuz adresine ulaşacağı şekilde yönlendirildiğini doğrulayın. DNS64 aynı öneki kullanmalıdır. Ağ arabirimleri, rotalar ve iki IP ailesinin güvenlik duvarı kuralları kurulmadan aşağıdaki parça tek başına bağlantı sağlamaz. Yönetim konsolunu ve dönüş yolunu koruyun. SIIT için aynı makinede ikinci geniş çeviri kuralını eklemek ayrı paket seçimi/izolasyon tasarımı gerektirir.
203.0.113.10 yalnız belgeleme adresidir; tahsisli, bu kapıya yönlendirilen gerçek IPv4 adresinizle değiştirin. 61001–65535 aralığı örnektir: yerel hizmetlerle ve sistemin geçici port aralığıyla çakışmadığını kontrol edin. Paketleri kurduktan ve ağ politikasını hazırladıktan sonra geçici Jool yapılandırması:
sudo sysctl -w net.ipv4.conf.all.forwarding=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo modprobe jool
sudo jool instance add nat64 --netfilter --pool6 64:ff9b::/96
sudo jool -i nat64 pool4 add --tcp 203.0.113.10 61001-65535
sudo jool -i nat64 pool4 add --udp 203.0.113.10 61001-65535
sudo jool -i nat64 pool4 add --icmp 203.0.113.10 61001-65535
sudo jool -i nat64 pool4 display
Bu parça adres ataması, istemci rotası, DNS64 veya kalıcı açılış ayarı oluşturmaz. Temsilî bağlantıları, dönüş paketlerini, kapı kapasitesini ve izinli/izinsiz trafiği sınayın; yeniden başlatma sonrası kalıcılığı sürümün belgelerine göre ayrıca kurun.
İstemci rotası, IPv4 çıkışı, dönüş yolu ve erişim kuralları tamamlandığında IPv6 destekleyen uygulamalar, uygun DNS adları üzerinden IPv4 kaynaklarına erişebilir. Yalnız IPv4 soketi veya doğrudan IPv4 adresi kullanan uygulamalar için DNS64 tek başına yeterli değildir. Ayrıntılı kurulum ve sürüm koşulları için Jool NAT64/SIIT belgelerini izleyin; bu parça bütün bir üretim ağı tarifi değildir.
IPv4 Ziyaretçiler İçin DNS ve Akış Tasarımı
CDN yönteminde önce hizmetin IPv6 origin bağlantısını, gereken protokolleri ve plan kapsamını desteklediğini doğrulayın. Proxy etkin DNS yanıtları sağlayıcının uç adreslerini gösterebilir; DNS ekranına her zaman CDN adresini elle yazmanız gerekmez, sağlayıcının kayıt yöntemini izleyin. Origin’e HTTPS kullanıp sertifika doğrulamasını etkinleştirin. Güvenlik duvarında erişimi gereken vekil aralıklarıyla sınırlandırmak doğrudan erişimi azaltabilir; IP’yi gizlediği veya aynı CDN’nin başka müşterilerini doğruladığı anlamına gelmez. Gerekiyorsa size özgü origin kimlik doğrulaması ekleyin.
Köprü VPS yönteminde ise A kaydını köprüye, AAAA kaydını doğrudan origin’e vererek başlamak pratik oluyor. Böylece IPv6 kullanıcılar doğrudan, IPv4 kullanıcılar köprü üzerinden gelir. İleride trafiğinizi ölçtükçe kayıtları şekillendirebilirsiniz. DNS değişikliklerinde yayılım hızını artırmak için TTL’leri geçiş döneminde kısa tutmak akıllıca. Bu konuda detaylı ipuçları için tekrar bırakayım: TTL stratejileri rehberi.
CDN tarafında WAF ve oran sınırlama (rate limit) kuralları, özellikle bot trafiğini sakinleştiriyor. Bu konuyu ayrıntılı ele alan bir rehber: Cloudflare WAF kuralları ve oran sınırlama ile WordPress’i koruma. Etkiyi ve yanlış pozitifleri log’lardan izleyerek kuralları ayarlayın.
Küçük Bir Yol Haritası: Başından Sonuna
Yeni bir blog için önce yönetim ve IPv6 bağlantısını doğrulayın. Paket depoları, uygulama bağımlılıkları, DNS API’si ve sertifika hizmetlerinin erişimini kontrol edin; IPv4-only dış uçlar gerekiyorsa NAT64/DNS64 çıkışını güncelleme, paket kurulumu ve sertifika alımından önce hazırlayın. Ardından uygulamayı kurun, IPv4 ziyaretçiler için uygun CDN/ters vekil veya ayrı tasarlanmış çeviri yolunu seçin. Kullanılacak tüm alan adlarını DNS’te yayımlayın; sertifika dosyaları hazır olduktan sonra HTTPS yapılandırmasını etkinleştirin ve yolları ayrı ayrı sınayın.
Önce IPv6 origin bağlantısını destekleyen bir CDN ile başlayabilir, ihtiyaç oldukça köprü VPS veya SIIT‑DC seçeneklerini değerlendirebilirsiniz. IPv4 kaynaklarına çıkış gerekiyorsa DNS64/NAT64’ü de hazırlayın. apt, composer ve docker gibi araçların kullandığı uç noktaları ayrıca sınayın; DNS64, uygulamanın doğrudan kullandığı IPv4 adreslerini çevirmeye yetmez.
Bu arada DNS tarafında kendi ad sunucunuzu kurmayı seviyorsanız, ayrı bir keyif. Detaya girmek isteyenlere, NS ve Glue Record konularını ele alan şu rehberi bırakayım: Özel ad sunucusu ve Glue Record nasıl kurulur? Kendi DNS’inizi yönetmek, böyle geçişlerde eli epey güçlendiriyor.
Hata Ayıklama ve Küçük Testler: “Gerçekten Çalışıyor mu?”
İki ayrı erişim testi yapın: IPv6 bağlantılı bir istemciden IPv6’yı zorlayarak siteyi açın; yalnızca IPv4 kullanan bir istemciden CDN veya köprü üzerinden erişin. Çift yığınlı bir bağlantıda sayfanın açılması tek başına IPv6’nın çalıştığını kanıtlamaz. Bunlar temel erişim kontrolleridir.
Dış erişimi test ederken yalnız A kaydı bulunan denetimli bir ad için DNS64’ün sentezlediği AAAA’yı inceleyin; ardından IPv6 bağlantısını ve uygulama sonucunu doğrulayın. DNS64 ile NAT64 aynı öneki kullanmalı, istemciden bu öneke giden yol doğru çeviriciye ulaşmalıdır. 64:ff9b::/96 bu örneğin seçimidir; sağlayıcınız başka önek kullanabilir. Unbound günlükleri ve Jool sayaçlarını sonuçla eşleştirin, paket depoları ve API’leri ayrı ayrı sınayın.
Performans, Güvenlik ve Akıl Sağlığı: Dengeyi Nasıl Kurarsınız?
Konum kararında yalnız ziyaretçi ile kapı arasını değil, kapı ile origin arasındaki yolu da ölçün. Çevirici kapasitesi, bağlantı sayısı ve paket kaybı önemlidir. Statik içerikte uygun CDN önbelleği origin yükünü azaltabilir; bare NAT64/SIIT çevirici önbellek veya WAF sağlamaz. Dinamik ve kişiye özel içerikte önbellek anahtarlarını ve istisnaları doğrulayın; gecikme kazancını varsaymak yerine uçtan uca ölçün.
Güvenlik tarafında WAF ve temel oran sınırlamalarını erken eklemek, köprülerinizi de gereksiz yükten korur. CDN kullanıyorsanız, WAF kural setlerini yavaş yavaş sıkılaştırın; yanlış pozitifleri sahada gözlemleyerek ilerlemek her zaman daha sakin bir süreç sunuyor. İsterseniz Cloudflare WAF kurallarıyla ilgili adım adım rehber burada da yol gösterir.
Günün sonunda, amaç denge: Basit başlayan, ihtiyaç oldukça olgunlaşan bir yapı. Benim favorim, origin’i sade tutmak; çevresine köprü, CDN ve güvenlik katmanlarını modüller gibi eklemek. Böyle olunca taşınmalar, ölçekleme ve beklenmedik trafik artışları bile daha az stresli oluyor.
Sık Sorulan Küçük Noktalar ve “Aman Bunu da Yaz” Detayları
“Happy Eyeballs”, modern tarayıcıların IPv6 ve IPv4 bağlantı denemelerini kısa gecikmelerle yarıştırarak bir yolun başarısızlığında uzun beklemeyi azaltmasıdır. İlk başarılı bağlantı kullanılır; bu, her zaman en hızlı aktarım yolunun seçildiği anlamına gelmez. Bu, AAAA kaydı eklediğinizde çoğu ziyaretçinin “hiçbir şey fark etmeden” siteyi hızlıca görmesinin pratiğe yansıması. Sizin göreviniz, IPv4 kullanıcıları için en az bir sağlam köprü bırakmak.
Bir de log’lar… Köprü ve origin log’larını birbirine bakacak şekilde etiketlemek çok iş görüyor. X‑Forwarded‑For ve gerçek IP zincirini doğru düzenlemek, güvenlik analizinde altın değerinde. CDN veya köprü kullanıyorsanız, gerçek IP başlıklarını yalnızca güvenilir vekil adreslerinden gelen bağlantılarda kabul edin; istemcinin doğrudan gönderdiği X‑Forwarded‑For değerine güvenmeyin.
Kapanış: Bu Köprüler Sizi Yormasın
IPv6‑only bir origin için IPv4 ziyaretçi erişimini, IPv6 origin bağlantısını destekleyen bir CDN proxy’si veya dual‑stack ters vekil sağlayabilir. IPv4 kaynaklarına dış erişim ise ayrı bir ihtiyaçtır; DNS64/NAT64 bunun için kullanılabilir. Her iki yönde de DNS, yönlendirme ve güvenlik ayarlarının tamamlanması gerekir.
Önce gerekli dış uçlara bağlantıyı ve gerekiyorsa NAT64/DNS64 çıkışını kurun; sonra uygulama, tüm kullanılan alan adlarının DNS kayıtları ve sertifika adımlarını tamamlayın. IPv4 ziyaretçi yolunu ayrıca doğrulayın. TTL değişikliklerini eski önbellek sürelerini hesaba katarak önceden planlayın; köprü ve origin günlüklerini ilişkilendirin, uygun WAF kurallarının yanlış engellemelerini izleyin. Genel geçiş bağlamı için IPv6 benimsemeye bakış yazısını da inceleyebilirsiniz.
