Web sunucusu için IPv6: Çift yığın kurulumu ve yaygın tuzaklar

Sunucunuz IPv6'ya yanıt veriyor, içeriden ping6 ile de ping atılabiliyor, ancak IPv6 interneti olan bir kullanıcı siteyi açamadığını söylüyor. Ya da daha kötüsü: site çoğu kişi için açılıyor ve yalnızca mobil kullanıcıların bir kısmı beyaz sayfa görüyor. Bu neredeyse her zaman IPv6 zincirinin bir yerinde yarım kaldığı anlamına gelir. Zincir şudur: arayüzdeki adres, varsayılan rota, DNS'teki AAAA kaydı, servisin dinlemesi ve güvenlik duvarı. Bu beş halkadan biri eksikse, sonuç tam olarak bu çelişkili davranıştır.

İlk yapmanız gereken, sorunun sunucu tarafında mı yoksa ağ yolunda mı olduğunu anlamaktır. Sunucunun kendisinde:

ip -6 addr show dev eth0
ip -6 route show default
curl -6 -I https://example.com
ss -6 -tlnp | grep :443

Eğer ip -6 addr adres gösteriyor ama ip -6 route show default boşsa, sunucunun adresi var ama dışarıya yolu yok. Bu durum, IPv6 adresini elle eklediğiniz VPS'lerde çok yaygındır. Eğer rota varsa ama ss -6 hiçbir şey göstermiyorsa, Nginx veya Apache yalnızca IPv4 üzerinde dinliyor demektir.

Nginx neden IPv6 üzerinde dinlemiyor

Birçok eski yapılandırmanın varsayılanı şudur:

listen 443 ssl;
listen [::]:443 ssl;

İkinci satırı elle eklemeniz gerekir. Eğer yalnızca listen 443 ssl; varsa, soket 0.0.0.0 üzerinde açılır ve IPv6'nın bununla hiçbir ilgisi olmaz. Ekledikten sonra nginx -t ve ardından systemctl reload nginx. Dikkat edin: aynı anda IPv4'ü de alan bir sokete ipv6only=on yanlış şekilde koyarsanız, port yeniden bind edilemeyebilir ve address already in use hatası alırsınız.

Apache'de durum farklıdır. Yalnızca Listen 80 ile Apache IPv6 üzerinde dinlemez; Listen [::]:80 satırını ayrıca yazmanız gerekir. Daha yeni sürümlerde Listen 80 koyarsanız ve sistemde net.ipv6.bindv6only=0 varsa, tek bir soket her ikisini de alır. Dağıtımlar arasındaki bu fark, bir sunucudan diğerine kopyalanan yapılandırmanın farklı davranmasına neden olur.

AAAA kaydını nereye ve nasıl koymalı

AAAA kaydı, A kaydının IPv6 karşılığıdır ve yalnızca IPv6 adresi alır. Yanlış veya eski bir adres koyarsanız, tarayıcı ona bağlanmayı dener ve zaman aşımından sonra IPv4'e geri döner. Bu fallback modern tarayıcılarda vardır, ancak birkaç saniye gecikme ekler ve bazı istemcilerde (eski HTTP kütüphaneleri gibi) hiç yoktur.

example.com.   300   IN   AAAA   2001:db8:1::10
www.example.com. 300 IN   AAAA   2001:db8:1::10

300 sayısı TTL'dir. Test yapıyorsanız, değişikliklerin hızlı yayılması için TTL'yi düşük tutun; kararlı hale geldikten sonra 3600'e döndürebilirsiniz. Pratik bir nokta: sunucunuzda IPv6 varsa ama servis onun üzerinde dinlemiyorsa, AAAA kaydını koymayın. AAAA kaydının olmaması, yanlış kaydın olmasından daha iyidir, çünkü istemci hızla IPv4'e yönelir.

Kaydın doğru şekilde yayıldığını kontrol etmek için ServerNet ağ araçları gibi ağ araçlarını veya dig AAAA example.com @1.1.1.1 komutunu kullanın. Yanıt farklı çözümleyicilerden farklıysa, eski önbellek henüz temizlenmemiştir.

Unuttuğunuz güvenlik duvarı

Burada hata yapıyorlar. Biri ufw allow 443 yazıyor, IPv4 açılıyor, test ediyor, çalışıyor ve bitti. Sonra site IPv6 kullanıcıları için açılmıyor ve saatlerce Nginx'te sorun arıyor. ufw kuralı şudur: IPv4 ve IPv6 kuralları ayrıdır ve ipv6 ile belirtilmelidir:

ufw allow proto tcp from any to any port 443
ufw allow proto tcp from any to any port 443

Aslında ufw, /etc/default/ufw içinde IPV6=yes varsa varsayılan olarak her ikisini birlikte yazar. Ancak o satır no ise yalnızca IPv4 yazılır ve hiçbir hata görmezsiniz. İşareti şudur: ufw status verbose kuralı gösterir, ama ip6tables -L -n boştur.

Ham iptables'ta da aynı hikaye geçerlidir. iptables ve ip6tables içindeki INPUT zinciri tamamen ayrı iki şeydir. Yalnızca iptables'ı çağıran bir güvenlik duvarı betiğiniz varsa, IPv6'nız açık ve korumasızdır. Bu en kötü durumdur: servis çalışır, test de geçer, ama yönetim portları IPv6 üzerinde tüm internet için açıktır.

Pratikte çift yığın: kimsenin hesaplamadığı maliyet

Çift yığın, servisin aynı anda hem IPv4 hem de IPv6 üzerinde dinlemesi demektir. Avantajı açıktır. Maliyeti ise saldırı yüzeyinin iki katına çıkması ve logların iki tür adres içermesidir. fail2ban veya rate-limit sisteminiz varsa, IPv6 adreslerini de gördüğünden emin olmalısınız. Bir IPv6 adresi tam bir /64 olabilir; rate-limit'i tek bir adrese bağlarsanız, saldırgan kolayca aynı alt ağdaki bir sonraki adresten devam eder. Nginx'te limit_req_zone'u $binary_remote_addr üzerinde dikkatlice ayarlamalısınız ve bu değişkenin IPv6 için dört değil on altı bayt olduğunu bilmelisiniz.

İkinci nokta: bir CDN arkasındaysanız, X-Forwarded-For başlığını IPv6 için de doğru şekilde ayrıştırmalısınız. Birçok hazır yapılandırmada set_real_ip_from içinde yalnızca IPv4 aralıkları vardır ve IPv6 kullanıcısının gerçek adresi logda CDN adresi olarak kaydedilir.

Hangisini seçmeliyim?

Herkese açık bir siteniz varsa ve trafik mobil ile büyük ağlardan geliyorsa, çift yığını etkinleştirin. Eğer iç servis ise ve tüm istemciler IPv4'e sahipse, IPv6'yı etkinleştirmek yalnızca saldırı yüzeyi ekler ve faydası yoktur. Ben pratikte herkese açık web sunucuları için çift yığını seçiyorum, ama yalnızca IPv6 güvenlik duvarını ve izlemeyi AAAA kaydından önce hazırladıktan sonra. Sıra önemlidir: önce güvenlik duvarı, sonra servis, sonra DNS. Ters giderseniz, servisin IPv6 üzerinde açık olduğu ve kimsenin onu korumadığı bir pencereye sahip olursunuz.

Ağ yığını üzerinde tam kontrol isteyen daha ağır iş yükleri için, fiziksel sunucu paylaşımlı bir VPS'ten daha mantıklı bir seçenektir, çünkü yönlendirme ve güvenlik duvarını platform kısıtlaması olmadan kendiniz ayarlayabilirsiniz. İş yükü daha hafifse ve hızlıca başlamak istiyorsanız, bulut sunucu özel IPv6 adresiyle aynı işi daha az yapılandırmayla yapar. İran adresli kararlı bir makineye ihtiyaç duyan projeler için, İran sanal sunucusu olağan bir başlangıç noktasıdır.

AAAA kaydını yayınlamadan önce son test

1. Sunucuda: ss -6 -tlnp 443 portunu [::] üzerinde göstermelidir.
2. Dışarıdan: curl -6 -I https://example.com zaman aşımı değil, başlık döndürmelidir.
3. Güvenlik duvarı: ip6tables -L -n sizin kurallarınızı içermelidir, boş zincir değil.
4. DNS: dig AAAA example.com +short arayüzde sahip olduğunuz adresle aynı olmalıdır.
5. SSL: sertifika aynı alan adı için geçerli olmalıdır; Let's Encrypt kullanıyorsanız, HTTP-01 challenge'ı IPv6 üzerinde de çalışmalıdır.

Bu beş maddeden herhangi biri başarısız olursa, AAAA kaydını yayınlamayın. Geçiş ve uyumluluk tartışmasını ele alan IPv6 ve modern altyapılardaki önemi hakkında tamamlayıcı bir rehberimiz de var. Belirli servislerin yapılandırma ayrıntıları için, dokümantasyon ve bilgi tabanı daha kesin bir referanstır.

Sık sorulan sorular

Site neden IPv6 ile açılmıyor ama IPv4 ile çalışıyor?

Genellikle üç şeyden biri: servis IPv6 üzerinde dinlemiyor, güvenlik duvarının IPv6 kuralı yok veya AAAA kaydı yanlış adrese işaret ediyor. ss -6 -tlnp, ip6tables -L -n ve dig AAAA ile üçünü birkaç dakikada ayırt edebilirsiniz.

AAAA kaydını silmek sorunu çözer mi?

Geçici olarak evet. AAAA kaydını kaldırırsanız, istemciler hızla IPv4'e yönelir ve site açılır. Ama bu bir çözüm değil, tedavidir; amaç IPv6'yı etkinleştirmekse, servisi ve güvenlik duvarını düzeltip sonra kaydı geri getirmelisiniz.

ufw varsayılan olarak IPv6'yı da kapatır mı?

Yalnızca /etc/default/ufw içinde IPV6=yes varsa. Aksi halde kurallarınız yalnızca IPv4 üzerinde uygulanır ve ip6tables -L -n boş kalır, oysa ufw status her şeyi normal gösterir.

Kullanıcıların gerçekten IPv6 ile bağlandığını nasıl anlarım?

Web sunucusu logunda iki nokta içeren adresleri arayın. Bir CDN arkasındaysanız, log formatına X-Forwarded-For başlığını eklemelisiniz, aksi halde yalnızca CDN'in kendi IPv4 veya IPv6 adresini görürsünüz ve kullanıcıların gerçek istatistiklerini kaybedersiniz.