IPv6‑Only VPS Üzerinde Web Sitesi Yayınlamak: NAT64/DNS64 ile IPv4’e Nasıl Köprü Kurulur?

Ofiste Bir Kahve, IPv6‑Only Bir Sunucu ve O Meşhur “Peki IPv4 Kullanıcıları?” Sorusu

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. Benim başıma geldi. Bir müşterinin küçük ama yoğun ziyaret alan blogunu, sadece IPv6 veren bir sağlayıcıya taşıyorduk. İş performans ve maliyetti; ama işin görünmeyen tarafında bağlantı dünyasının iki dili vardı: IPv6 ve IPv4.

Sonra düşünmeye başladım. Ziyaretçilerin bir kısmı hâlâ IPv4 ile geliyor. Sunucum IPv6‑only. Taraflardan biri diğerini anlamıyorsa, bir çevirmen gerekir. İşte bu yazı, o çevirmenin hikâyesi. NAT64/DNS64 tam bu noktada devreye giriyor. Bazı yerlerde bir CDN proxy’si kadar pratik, bazı yerlerde küçük bir “köprü” sunucu kadar gerekli. Adım adım konuşacağız: IPv6‑only VPS’te siteyi nasıl ayağa kaldırırız, dış dünyadaki IPv4 kaynaklarına nasıl erişiriz ve IPv4 kullanıcıları bu siteyi nasıl görür? Hepsini doğal bir akışla, örneklerle anlatacağım.

Önce Resmi Büyütelim: IPv6‑Only VPS Nedir ve Neden İşimize Yarayabilir?

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, ben de sıkça dönüp okurum: 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

İlk durak, DNS. Alan adınız için bir AAAA kaydı ekleyerek sitenizin IPv6 adresini duyurun. Diyelim sunucunuzun IPv6’sı 2a03:abcd:1234::f. Alan adınız www alt alanıyla kullanılıyorsa, www.example.com → 2a03:abcd:1234::f şeklinde AAAA ekleyin. A kaydı (IPv4) eklemezsiniz, çünkü sunucunuzda bu yok. Bu noktada çoğu modern tarayıcı ve ağ, IPv6’yı gayet ustaca seçer. Ama hâlâ sadece IPv4 konuşan kullanıcılar var; onlara birazdan döneceğiz.

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 doğrulaması yapmak (80/443) zahmetli ise veya wildcard sertifika istiyorsanız, DNS tabanlı doğrulamayı seçin. Ben çoğu projede otomasyonu şöyle kuruyorum: acme istemcisi DNS sağlayıcısına kısa 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

İlk yayına çıkış için Nginx üzerinde basit bir yapı yeterli. Ben bu iskeleti seviyorum çünkü sonra cache, WAF, rate limit gibi parçaları kolayca ekliyorum:

server {
    listen [::]:80;
    server_name www.example.com example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen [::]:443 ssl http2;
    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/html;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Bu kadarla bile yayına çıkan çok proje gördüm. İleride statik dosya süresi, sıkıştırma ve HTTP/2 push gibi tatlandırıcılar eklenebilir. Ama önce bağlantıyı garanti altına alalım.

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ı

Alan adınızı bir CDN’e yönlendirip “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. Güzel tarafı, hem performans hem güvenlik kazanırsınız. 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, ben şu rehbere sık başvuruyorum: 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. Bundan sonrası sihir gibi: 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. Yapılandırma dosyasında DNS64’ü açmanız kâfi. Belgelere göz atmak isterseniz: Unbound yapılandırma kılavuzu. Temel fikir, DNS64’ün iyi bilinen prefix’iyle yapay AAAA üretmesidir.

# /etc/unbound/unbound.conf içinden fikir vermesi için
server:
    interface: 0.0.0.0
    interface: ::0
    access-control: 0.0.0.0/0 allow
    access-control: ::0/0 allow
    do-ip4: yes
    do-ip6: yes
    module-config: "dns64 validator iterator"

# DNS64 bloğu: Sadece A kaydı olan alanlar için AAAA üret
server:
    dns64-prefix: 64:ff9b::/96

Bu ayardan sonra IPv6‑only sunucunuzun resolv.conf veya systemd-resolved ayarında DNS olarak bu Unbound’u göstermeniz yeterli. Bundan sonra “sadece A kaydı” olan bir adrese istek gittiğinde, arka planda AAAA sentezlenir.

NAT64 için Jool

NAT64 cephesinde Jool’u seviyorum, çünkü hem esnek hem de dokümantasyonu temiz. Basit bir kurulumda, 64:ff9b::/96 prefix’iyle gelen trafiği dıştaki bir IPv4 havuzundan çevirtiyoruz. Jool’u köprü VPS’inize kurup aşağıdaki gibi başlatabilirsiniz:

# Debian/Ubuntu örneği
sudo apt update
sudo apt install jool-dkms jool-tools

# Çeviri modülünü yükle
sudo modprobe jool

# Basit NAT64 kuralı (örnek):
# 64:ff9b::/96 üzerinden gelen IPv6 istekleri, belirtilen IPv4 havuzundan çıksın
sudo jool instance add --netfilter --pool6 64:ff9b::/96
sudo jool -i "netfilter" nat64 add --pool4 203.0.113.10-203.0.113.20

# Netfilter tarafında da IPv6→IPv4 yönlendirmesini açmayı unutmayın (nftables/ip6tables)

Bundan sonra IPv6‑only sunucunuz, Unbound DNS64’ü kullanarak IPv4’teki kaynaklara doğrudan ulaşabilir. İsterseniz Jool’un sitesinde daha derin örnekler var: Jool ile NAT64/SIIT kullanımı için kaynaklar. Burada önemli olan mantığı anlamak; komutlar dağıtımlara göre küçük farklar gösterebilir.

IPv4 Ziyaretçiler İçin DNS ve Akış Tasarımı

Gelelim “insanlar sitenize nasıl gelecek?” meselesinin DNS ayağına. Eğer CDN proxy kullanıyorsanız, A ve AAAA kayıtlarınız CDN’in size verdiği uç noktalara bakar. Proxy açıksa, IPv4 kullanıcı zaten CDN’de sonlanır ve origin’e IPv6 üzerinden geçer. Origin’inizi gizli tutmak istiyorsanız, sadece CDN’in erişebileceği bir güvenlik kuralı da koyabilirsiniz. Örneğin güvenlik duvarında sadece CDN ağ aralığına izin vermek sık yaptığım bir hamle.

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 mevzuyu uzun uzadıya anlattığım bir yazı var, meraklısına iyi gider: Cloudflare WAF kuralları ve oran sınırlama ile WordPress’i koruma. Uyguladığınız anda log’larda adeta gün aydınlanıyor.

Küçük Bir Yol Haritası: Başından Sonuna

Mesela şöyle düşünün: Yeni bir blogu IPv6‑only bir VPS’e kuracaksınız. Önce sunucuyu güncelleyin, Nginx/PHP veya Node’u kurun, uygulamayı ayağa kaldırın. AAAA kaydını ekleyip Let’s Encrypt ile sertifikanızı alın. Ardından “IPv4 kullanıcıları” meselesi için karar verin: Kolay yol olan bir CDN proxy’si mi, yoksa kendi ters vekil köprünüz mü?

Ben çoğu projede şu sıralamayı seviyorum. İlk gün CDN ile başlarım; çünkü iki dakikada bir sonuç görürüm. Ardından içerik trafiği oturdukça, köprü VPS veya SIIT‑DC gibi daha esnek çözümler kurarım. Bu aradaki zamanda sunucuyu dış dünyaya açma tarafında DNS64/NAT64’ü de hazırlarım ki apt, composer, docker gibi araçlar takılmadan çalışsın. Hepsinin sonunda elimde şunlar olur: IPv6‑only tertemiz bir origin, IPv4 kullanıcıları için akıllı bir köprü ve dış dünyaya konuşabilen mutlu bir sunucu.

Bu arada DNS tarafında kendi ad sunucunuzu kurmayı seviyorsanız, ayrı bir keyif. Detaya girmek isteyenlere, NS ve Glue Record dünyasını derli toplu anlattığım ş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?”

İşler çalışıyor gibi görünür ama ben her zaman iki basit teste başvururum. Birincisi, IPv6’dan gerçekten cevap veriyor muyuz? Evde ya da mobil veriyle IPv6 açık bir bağlantıdan siteye girerim. İkincisi, yalnızca IPv4 olan bir cihazdan, CDN veya köprüye bakarak sayfayı yüklerim. İkisi de akıcıysa tamamdır.

Sunucunun dışarıya erişimini test etmek de önemli. DNS64 üzerinden “yalnızca A kaydı” olan alanlara curl atıp cevap alabiliyor musunuz? Paket yöneticileri takılmadan çalışıyor mu? Eğer sorun yaşarsanız, Unbound logları ve Jool istatistikleri çok şey söyler. DNS64 prefix’inin 64:ff9b::/96 olduğundan, bu aralıktan görünen trafiğin doğru NAT’tan çıktığından emin olun. Küçük bir not: Bazı kurumsal ağlar, DNS üzerinde ara davranışlar sergileyebiliyor; DNS’i önce köprüde doğrulayıp, sonra origin’e uygulamak işleri hızlandırır.

Performans, Güvenlik ve Akıl Sağlığı: Dengeyi Nasıl Kurarsınız?

Performans tarafında iki şeye dikkat ediyorum. İlki, köprü/Proxy’nin bulunduğu yer. Ziyaretçinin çoğunluğu neredeyse, kapıyı oraya yakın konumlandırmak iyi sonuç veriyor. İkincisi, içerik türünüz. Statik içerik ağırlıklıysa CDN önbelleği harikalar yaratıyor. Dinamikse, cache ve hızlandırma katmanlarını daha naif ayarlamak gerekiyor. Bu tarafı WordPress gibi bir CMS’de derinlemesine ele aldığım yazılar var; ama bu yazıda amacımız hatları çizmek.

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” denilen bir yaklaşım, modern tarayıcıların aynı anda hem IPv6 hem IPv4 denemesi demek. Yani kullanıcı çoğu zaman en hızlı yolu otomatik buluyor. 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 kullanıyorsanız, gerçek IP başlıklarını tanıyacak şekilde Nginx/uygulama ayarlarını yapmayı unutmayın.

Kapanış: Bu Köprüler Sizi Yormasın

Bir gün ofiste kahvemi içerken “Sadece IPv6 veren bu VPS ile siteyi nasıl açarız?” sorusu bana uzaktan göz kırpıyordu. Şimdi dönüp bakınca, çözümün ne kadar akıcı olduğunu görüyorum. Origin’i IPv6‑only tutmak hiç korkutucu değilmiş. IPv4 ziyaretçiler için ya bir CDN proxy’si ya da minik bir ters vekil köprüsü kurarsınız; hepsi bu. Dış dünyaya erişim için NAT64/DNS64 ile küçük bir kapı açarsınız. Geri kalan ayrıntılar, pratik ayarlardan ibaret.

Pratik tavsiyem şu: Basit başlayın. Önce AAAA, sonra SSL, ardından bir CDN veya köprü. Eşzamanlı olarak DNS64/NAT64’ü hazır edin ki paket, API ve diğer dış servislerde hiç takılmayın. DNS kayıtlarını taşırken TTL’leri kısa tutun, köprülerinizi log’layın, WAF’ı erken devreye alın. İsterseniz bir de şu yazıyı saklayın; IPv6 dalgasına hazırlıkta zihin açıcıdır: IPv6 benimsemeye bakış. Umarım bu yazı size somut bir yol haritası vermiştir. Bir dahaki yazıda görüşmek üzere; köprüleriniz her daim sağlam kalsın.