Sunucunuzda IPv6 var, AAAA kaydını da tanımladınız, ancak aynı makinede curl -6 https://example.com ya zaman aşımına uğruyor ya da hemen Connection refused döndürüyor. Bu arada sitenin IPv4 sürümü tam hızda çalışıyor. İşte bu, çoğu sunucu yöneticisinin takıldığı noktadır: IPv6 adresi arayüze oturduğu için her şeyin bittiğini varsayarlar. Bitmemiştir. Üç ayrı katmanın hizalanması gerekir ve biri eksik kalırsa aynı yanıltıcı belirtileri görürsünüz.
Önce sunucudaki IPv6'nın gerçekten etkin mi yoksa yalnızca atanmış mı olduğunu anlayın
Herhangi bir değişiklikten önce mevcut durumu okuyun. ip -6 addr show scope global komutu yalnızca genel IPv6 adreslerini gösterir ve fe80:: ile başlayan link-local adresleri filtreler. Çıktı boşsa sorun web sunucusunda değil, ağ katmanındadır.
ip -6 addr show scope global
ip -6 route show default
sysctl net.ipv6.conf.all.disable_ipv6Son satır 0 değerini döndürmelidir. Eğer 1 ise, IPv6 çekirdek düzeyinde kapalıdır ve başka hiçbir yapılandırma işe yaramaz. Bu durum bazı eski imajlarda ve bazı varsayılan güvenlik şablonlarında görülür. Geçici olarak açmak için:
sysctl -w net.ipv6.conf.all.disable_ipv6=0
sysctl -w net.ipv6.conf.default.disable_ipv6=0Kalıcı hale getirmek için bu iki satırı /etc/sysctl.d/99-ipv6.conf dosyasına koyun ve sysctl --system çalıştırın. Çoğu kişinin gözden kaçırdığı nokta: disable_ipv6 değerini all üzerinde sıfırlasanız bile belirli bir arayüzde açık bir 1 değeri kalmışsa, o arayüz kapalı kalır. Arayüz değeri genel değere göre önceliklidir.
Adresi elle mi ayarlayacaksınız yoksa SLAAC'tan mı alacaksınız
Bulut sunucularda genellikle adres ağ tarafından duyurulur ve siz yalnızca kabul etmeniz gerekir. Ancak size IPv6 bloğu teslim edilen özel sunucuda adresleme elle yapılır. systemd-networkd tabanlı dağıtımlarda /etc/systemd/network/10-static.network dosyasını şöyle yazın:
[Network]
Address=2001:db8:1::10/64
Gateway=2001:db8:1::1
DNS=2001:4860:4860::8888Netplan kullanan Ubuntu'da karşılığı /etc/netplan/01-netcfg.yaml içinde addresses ve routes anahtarları altında gelir. netplan apply sonrasında SSH bağlantınız kesilirse korkmayın; konsoldan veya rescue modundan geri dönüp yapılandırmayı düzeltin. Bu senaryo o kadar yaygındır ki, sunucuyu yeniden kurma ve rescue moduyla çalışma; erişimi kaybettiğinizde verileri kurtarma konusunun nasıl işlediğini önceden bilmeye değer.
AAAA kaydını doğru tanımlayın, sadece tanımlamakla kalmayın
AAAA kaydı tam olarak A gibi çalışır, yalnızca değeri 128 bitlik bir adrestir. BIND zone dosyasındaki sözdizimi şöyledir:
www IN AAAA 2001:db8:1::10
@ IN AAAA 2001:db8:1::10Üçü de aynı belirtileri üreten üç yaygın hata. Birincisi, adresi sıkıştırılmamış biçimde veya büyük harflerle yazarlar ve bazı DNS panelleri bunu reddeder. İkincisi, bir adreste :: işaretini iki kez kullanırlar ki bu sözdizimsel olarak geçersizdir. Üçüncüsü, link-local yani fe80:: adresini AAAA kaydına koyarlar. Bu adres dışarıdan yönlendirilemez ve istemciler ona ulaşamaz.
Kontrol etmek için dig kullanın ve açıkça AAAA türünü isteyin:
dig +short AAAA example.com @1.1.1.1
dig +trace AAAA example.comdig yanıt veriyor ama tarayıcı vermiyorsa, sorun DNS değildir. Sorun dönüş yolu veya güvenlik duvarıdır.
İşte burada hata yapıyorlar: IPv6 güvenlik duvarını ayrı görüyorlar
Bu, biletlerde en sık gördüğüm hatadır. Sunucu yöneticisi iptables içinde 443 portunu açar, sitenin IPv4 sürümü ayağa kalkar ve işin bittiğini varsayar. Ancak iptables yalnızca IPv4 paketlerini görür. IPv6 trafiği ip6tables üzerinden veya nftables'taki inet tablosundan geçer. Sonuç? Site IPv4 üzerinden açılır, IPv6 üzerinden zaman aşımına uğrar ve tarayıcılarda Happy Eyeballs olduğu için kullanıcı genellikle tuhaf bir şey görmez; ta ki IPv6-only bir ağa sahip bir ziyaretçi gelip sayfa hiç açılmayana kadar.
Tanı işareti şudur: ss -6 -tlnp servisin :::443 üzerinde dinlediğini gösterir, ancak dışarıdan curl -6 zaman aşımına uğrar. Yani servis sağlıklıdır ve güvenlik duvarı önünü kesmiştir. Mevcut kuralları görmek için:
nft list ruleset
ip6tables -L -n -v --line-numbersSisteminizde nftables varsa, iptables ve ip6tables yalnızca uyumluluk katmanıdır ve gerçek kuralları göstermeyebilir. Bu üçü arasında kafanızın karışmaması için tam komut referansını Linux güvenlik duvarı komutları: iptables, nftables ve ufw için hızlı referans sayfasında görebilirsiniz.
Servisi IPv6 üzerinde dinlemeye zorlayın
Birçok servis varsayılan olarak yalnızca IPv4 üzerinde dinler. Nginx'te server bloğunun içine şu satırı koyun:
listen [::]:443 ssl http2;
listen [::]:80;Köşeli parantezler zorunludur; onlar olmadan Nginx hata verir çünkü IPv6 adresindeki : işaretinin kendisi ayırıcıdır. Apache'de Listen [::]:443 eklemeniz yeterlidir. MySQL ve PostgreSQL için de bind-address parametresini :: olarak değiştirin, ancak bunu yalnızca gerçekten IPv6 üzerinden uzaktan erişime ihtiyacınız varsa yapın. Veritabanını güvenlik duvarı olmadan :: üzerinde açmak, IPv4'teki aynı felaketi tekrarlar. Asla açık olmaması gereken portların listesi Yaygın servis portları ve açık olmaması gereken portlar referansı sayfasında yer alıyor.
Değişiklikten sonra servisi yeniden başlatın ve gerçekten IPv6 üzerinde dinlediğini kontrol edin:
ss -6 -tlnp | grep -E ':(80|443)'
curl -6 -I https://example.com
curl -6 -v telnet://[2001:db8:1::10]:443Servis ayağa kalkmıyorsa ve logda hiçbir şey yoksa, muhtemelen unit dosyasını elle düzenlediniz ve systemd onu okumadı. Doğru yapı ve güvenli yeniden başlatma yöntemi systemd'de unit dosyası: bölümler, yeniden başlatma ve bağımlılık sayfasında açıklanmıştır.
Çift yığın IPv6 ile IPv6-only arasında seçim
Önünüzde iki gerçek yol var ve seçim zevke değil kullanım durumuna bağlıdır.
| Ölçüt | Çift yığın yapılandırma (Dual-Stack) | Yalnızca IPv6 |
|---|---|---|
| Mevcut kullanıcılarla uyumluluk | Tam | NAT64 veya proxy gerektirir |
| Güvenlik duvarı karmaşıklığı | İki kural kümesi | Tek kural kümesi |
| Yapılandırma hatası riski | Yüksek | Düşük |
| Uygun olduğu durum | Genel site, mağaza | Dahili servis, arka uç API |
Anonim kullanıcısı olan her site için çift yığını seçerim. Nedeni basit: Kurumsal ağların ve yerel ISP'lerin hâlâ önemli bir kısmında IPv6 yolu yok ve yalnızca IPv6 hizmet verirseniz onları kaybedersiniz. Ancak mikroservisler arasındaki dahili API için IPv6-only doğru seçimdir. Tek kural kümesi, NAT yok, çevrilmiş adres karmaşası yok. Bedeli, her izleme aracının ve her eski betiğin IPv6'yı anlaması gerektiğidir; bazı Python betikleri socket.AF_INET ile sabit kodlanmıştır ve sessizce başarısız olur.
Çok az kişinin önceden bildiği bir kısıtlama
Sunucunuz NAT64 arkasındaysa veya bir 6to4 tüneli arkasındaysa, servisinizin gördüğü kaynak adres istemcinin gerçek adresiyle aynı değildir. Bu durumda IP'ye dayalı her rate-limit veya engelleme mantığı boşa çıkar. Devreye almadan önce tcpdump -i eth0 -n ip6 ile birkaç dakika trafiği izleyin ve kaynak adreslerin nasıl göründüğüne bakın. Hepsi belirli bir önekten geliyorsa, muhtemelen bir çevirici arkasındasınız.
Dışarıdan son test için çevrimiçi IPv6 test servislerini kullanın veya farklı bir ağa sahip bir makineden curl -6 çalıştırın. Sunucunun kendisinden yapılan test dönüş yolunu asla kanıtlamaz. Bulut altyapısı üzerinde çalışıyorsanız, bu ayarların bir kısmı ağ düzeyinde yapılmış olabilir ve yalnızca işletim sisteminde doğrulanması gerekir; bulut sunucu üzerinde genellikle adres önceden yönlendirilmiştir ve işiniz daha azdır. Özel donanımda ise tüm bu adımları kendiniz geçersiniz.
Sık sorulan sorular
Site neden IPv4 üzerinden açılıyor da IPv6 üzerinden açılmıyor?
Neredeyse her zaman güvenlik duvarıdır. iptables kuralları IPv6 trafiğine uygulanmaz ve ip6tables veya nftables'taki inet tablosunu ayrıca yapılandırmanız gerekir. Test edin: ss -6 -tlnp servisin :::443 üzerinde dinlediğini gösteriyor ama dışarıdan curl -6 zaman aşımına uğruyorsa, servis sağlıklıdır ve güvenlik duvarı önünü kesmiştir.
AAAA kaydını silmek sorunu çözer mi?
Geçici olarak evet, ama çözüm değildir. AAAA'yı silmekle IPv6-only kullanıcıları tamamen kaybedersiniz ve bazı tarayıcılar DNS önbelleği nedeniyle saatlerce tuhaf davranış sergiler. Aceleniz varsa ve site hemen ayağa kalkmalıysa, AAAA kaydını silmek kabul edilebilir geçici bir önlemdir; ancak TTL'yi 300 saniyeye ayarlayın ki sonradan hızlıca geri döndürebilesiniz.
IPv6 adresini nereden almalıyım?
Bulut sunucularda genellikle ağ tarafından duyurulur ve siz yalnızca kabul etmeniz gerekir. Özel sunucuda, IPv6 bloğu servisle birlikte size teslim edilir ve adresleme elle yapılır. Her iki durumda da her şeyden önce ip -6 addr show scope global ile adresin gerçekten arayüze oturup oturmadığını kontrol edin.
Güvenlik duvarının mı yoksa servisin kendisinin mi suçlu olduğunu nasıl anlarım?
Sunucunun kendisinde curl -6 http://[::1]:443 ile loopback'e bağlanın. Yanıt verirse servis sağlıklıdır ve sorun ağ yolunda veya güvenlik duvarındadır. Yanıt vermezse servis IPv6 üzerinde dinlemiyordur ve yapılandırmaya listen [::] satırını eklemeniz gerekir.
Sonraki adım belli: hemen şimdi ip -6 addr show scope global ve nft list ruleset komutlarını çalıştırın ve hangi katmanın boş olduğunu görün. Vakaların yüzde doksanında cevap bu iki çıktıda bulunur.