IPv4 bağlantısı olmadan internet kullanmak

• Elektrik kesintisinin ardından ISP tarafında yalnızca IPv4 bağlantısının koptuğu, IPv6'nın ise çalışmaya devam ettiği bir durumda, yalnızca IPv4 destekleyen sitelere erişimi geri getirmek için hem IPv4 hem IPv6 sahibi bir Hetzner VPS ve WireGuard tüneli kullanıldı
• Arızanın, CG-NAT katmanında IPv4 paketlerinin düzgün çevrilmeyip düşürülmesinden kaynaklandığı düşünülüyordu; IPv6 destekleyen Google ve Meta gibi servisler ise erişilebilir kalmıştı
• VPS üzerinde bir WireGuard sunucusu kurup istemcinin VPS'nin IPv6 adresini endpoint olarak kullanmasıyla, IPv4 trafiği VPS üzerinden geçirerek normal web gezinmesi geri getirilebiliyor
• İş VPN'i ve Docker için ayrı işlem gerekiyordu; bu yüzden vopono tabanlı ağ namespace'leri ve unshare ile /sys bind mount geçici çözümü gibi yöntemlerle bunlar bu namespace'ler içinde çalıştırıldı
• Yalnızca bazı sitelerin yüklenmesi sorununun nedeni WireGuard MTU değerinin fazla büyük olmasıydı; değer IPv6 asgari MTU'su olan 1280'e düşürülünce sorun hemen çözüldü

---

Elektrik kesintisinden sonra yalnızca IPv4'ün koptuğu arıza

• Elektrik kesintisinden sonra sigorta geri kaldırıldı, ancak GitHub ve çeşitli web sitelerine erişilemiyordu; Google ve Meta ise normal çalışıyordu
• Yerel makinede ve yönlendiricinin tanılama sayfasında ping -6 ve traceroute kontrol edildiğinde, sorunun yalnızca IPv4 sunucularına erişimde olduğu görüldü
• ISP, teknisyen ziyareti gerekebileceğini ve bunun hafta sonundan sonra birkaç gün sürebileceğini söyledi; iş erişimi ve makale çalışması nedeniyle kesintinin düzelmesini beklemek zordu
• Mevcut Hetzner VPS üzerinde statik IPv4 ve IPv6 adresleri vardı; Hetzner web sitesi IPv6 desteklediği için konsola erişilip yapılandırma yapılabildi

NAT ve CG-NAT'ın oluşturduğu IPv4 bağımlılığı

• IPv4 adresleri 32 bittir ve ayrılmış bloklar çıkarıldığında herkese açık IPv4 adresi sayısı yalnızca yaklaşık 3,7 milyardır; bu yüzden internete bağlı her cihaza doğrudan adres verilemez
• NAT, birden çok cihazın tek bir genel IP'yi paylaşmasını sağlar
  • Ev yönlendiricisi, 192.168.1.xxx gibi yerel IP'leri kendi genel IPv4 adresine çevirir
  • Linux'taki conntrack, özgün kaynak IP ve port ile çevrilmiş portu bir eşleme olarak saklar
  • Yanıt paketleri ilgili porta geldiğinde conntrack hedefi özgün iç IP ve porta geri çevirir
  • Linux'ta kayıtlı eşlemeler conntrack-tools içindeki conntrack -L ile görülebilir
• NAT, örtük bir güvenlik duvarı gibi davranır; yönlendirici arkasındaki yerel cihazlardaki servislere, açık bir port yönlendirme olmadan dışarıdan erişmek zordur
• IPv4 kıtlığı nedeniyle ISP, içeride bir kez daha NAT uygulayabilir; buna Carrier Grade NAT (CG-NAT) denir
  • Ev yönlendiricisinin birden çok yerel cihazı NAT'laması gibi, ISP yönlendiricisi de birden çok ev yönlendiricisini NAT'lar
  • ISP'nin sahip olduğu IPv4 adres sayısına ve atama politikasına bağlı olarak bu işlem bölgesel düzey gibi birden çok katmanda tekrarlanabilir
• Bu arızada, CG-NAT katmanının bir yerinde IPv4 paketleri doğru NAT'lanmayıp düşüyor ve bu yüzden IPv4 trafiği tamamen kesilmiş gibi görünüyordu
• NAT traversal geçici çözümleri için Tailscale'ın How NAT Traversal Works yazısına bakılabilir

IPv6'nın çalışmaya devam etmesinin nedeni

• IPv6 adresleri 128 bittir ve ayrılmış bloklar hesaba katılsa bile yaklaşık 3.4E38 adres sağlar
• Ev yönlendiricilerinin /64 alt ağ alması yaygındır; bu da 1.84E19 adres anlamına gelir
• IPv6'da ev yönlendiricisinde NAT kullanmadan da her cihaz internet üzerinde doğrudan bir adrese sahip olabilir
  • Port yönlendirme sorunları azalır
  • Bunun yerine yönlendirici veya her cihaz, dışarıdan gelen rastgele yeni bağlantıları engelleyen uygun güvenlik duvarı kuralları gerektirir
• IPv6'ya CG-NAT uygulanmadığı için bu arızadan etkilenmedi
• GitHub gibi hâlâ IPv6 üzerinden erişilemeyen web sunucuları bulunduğundan, yalnızca IPv6 bağlantısıyla tüm internet doğrudan kullanılamıyordu

WireGuard ile IPv6 üzerinde IPv4 tüneli kurmak

• Çözüm, VPS'ye WireGuard kurup istemcinin VPS'nin IPv6 adresini endpoint olarak kullanacağı bir tünel oluşturmaktı
• Tünel kurulduğunda IPv4 trafiği VPS üzerinden geçerek normal çalışıyor
  • VPS üzerinden geçtiği için gecikme artıyor
  • Çalışma biçimi, elle kurulmuş bir Dual-Stack Lite çözümüne benziyor
• Sunucu, daha önce vps2arch ile Arch Linux kurulmuş bir Hetzner VPS idi ve Hetzner'in güncel Debian imajı temel alınarak kullanıldı
• WireGuard yapılandırması, ArchWiki'deki WireGuard specific VPN server example örneği temel alınarak IPv6 trafiği eklenmiş biçimde hazırlandı
• Sunucu yapılandırması şunları içeriyordu
  • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
  • IPv4, iptables içindeki MASQUERADE ile yönlendirildi
  • IPv6 ULA, ip6tables içindeki SNAT --to-source ile NAT'landı
  • IPv4/IPv6 forwarding etkinleştirildi
  • peer örnekleri, doğrudan IPv6 Global Unicast Address kullanan foo ile NAT'lanmış IPv6 ULA kullanan bar olarak ayrıldı
• wg-quick, .ini tarzı yapılandırmalardan farklı olarak PostUp ve PostDown seçeneklerini birden çok kez tanımlamaya izin verir ve komutları sırayla çalıştırır
  • İlgili uygulama wg-quick linux.bash içinde görülebilir

IPv6 NAT, SNAT ve istemci yapılandırması

• IPv6 için NAT zorunlu değildir; Hetzner gibi VPS üzerinde /64 IPv6 bloğu varsa peer'lere doğrudan Global Unicast Address (GUA) verilebilir
• Doğrudan adresleme kullanmak için peer ve arayüzün Unique Local Address (ULA) değerleri genel IPv6 adresleriyle değiştirilir ve ip6tables MASQUERADE kuralı kaldırılır
  • Böylece her peer, atanmış IPv6 adresiyle internet üzerinden doğrudan adreslenebilir hale gelir
  • Birden fazla cihazda kendi servislerini yönlendirmek gerekiyorsa bu yöntem uygundur
  • VPS güvenlik duvarının gelen trafiği doğru işlemesi gerekir
• VPS'nin IP adresinin statik olduğu ve değişmeyeceği biliniyorsa MASQUERADE yerine SNAT kullanılabilir
  • MASQUERADE, çalışma anında arayüz IP'sini sorgular
  • SNAT, adresi doğrudan belirttiği için biraz daha verimlidir
• İstemci yapılandırmasında sunucunun IPv6 adresi Endpoint = [2001:db8:abcd:1234::1]:51820 biçiminde köşeli parantez içine alınmalıdır
• AllowedIPs = 0.0.0.0/0, ::/0 ile tüm IPv4/IPv6 trafiği tünele gönderilir
• Her iki tarafta da çalıştırıldıktan sonra normal gezinme düzeldi ve sunucuya tünelin yerel IPv4 ve IPv6 adresleriyle doğrudan SSH erişimi de mümkün oldu
• Linux üzerinde eşin makinesine de WireGuard istemcisi kolayca kurulabildi

İş VPN'ini ağ namespace ile ayırmak

• WireGuard bağlantısının üzerinde iş VPN'ini doğrudan bağlamak çakışma yarattı ve kullanılamadı
• vopono kullanılarak iş VPN'i ve gerekli uygulamalar bir ağ namespace içinde çalıştırıldı
• Temel fikir, MASQUERADE kuralının trafiği gerçek ağ arayüzüne değil, çalışan WireGuard arayüzüne (foo veya bar) yönlendirmesini sağlamaktı
• Namespace içindeki trafik, host'un WireGuard nftables kurallarını doğrudan fark etmese de pratikte WireGuard tüneli üzerinden yönlendirilir
• wg-quick, mümkün olduğunda iptables yerine nftables'ı tercih eder; ancak Docker'ın standart iptables kurallarıyla çakışmayı önler
• vopono kullanım örneği şöyledir

$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh

• /etc/netns/vo_none_none/, ip netns exec tarafından /etc olarak mount edildiği için bu namespace'e özel bir resolv.conf yerleştirilebilir
• IPv4 DNS çözümlemesini öncelemek istenirse aynı yöntemle gai.conf da ayarlanabilir
  • Bu ayar, IPv6 tünel trafiği sorunlarını debug ederken kullanıldı
  • Örnek, AskUbuntu yanıtını temel alır
• İş VPN'i bağlandıktan sonra iç DNS sunucusu /etc/netns/vo_none_none/resolv.conf içine eklenirse, ardından bu namespace içinde çalışan uygulamalar normal çalışır
• Chrome gibi uygulamalar normal kullanıcı yetkisiyle namespace içinde çalıştırılabilir

$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Docker'ı aynı namespace içinde çalıştırmak

• Docker, yalnızca başka bir uygulama gibi ağ namespace içinde çalıştırıldığında çalışmaz
  • Çünkü systemd tarafından etkinleştirilmiş Docker socket'i namespace dışında oluşturulmuştur
  • İç bağlantı kurulamaz
• Dışarıdaki Docker durdurulup namespace içinde dockerd ve socket yeniden oluşturulmaya çalışılsa bile sorun hemen çözülmez
  • ip netns exec, bir mount namespace oluşturur ve /sys dosya sistemini yeniden mount eder
  • Bu yüzden host üzerindeki /sys/fs/cgroup görünmez hale gelir
• Bu durumda şu hata görülebilir

Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo

• Geçici çözüm, unshare ile /sys için bind mount oluşturup ip netns exec tarafından oluşturulan iç /sys mount'unu kaldırmaktır
  • Bu yöntem Unix StackExchange gönderisine dayanır
  • Sonrasında mount namespace içindeki /sys, host /sys'inin bind mount'u olur
• Örnek komutlar şöyledir

$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...

• dockerd ile Docker komutları aynı oturum içinde çalıştırılırsa aynı ağ namespace'ini ve mount namespace'ini paylaşırlar
• Docker DNS ayarı /etc/netns/vo_none_none/docker/daemon.json içine de konabilir
• Bu yöntem, yardımcı container'lar ve Docker ağı üzerinden bağlı container'lar gerektiren işler için yeterliydi; ancak bridge gibi daha karmaşık Docker yapılandırmalarında aynı şekilde çalışmayabilir

WireGuard MTU sorununu debug etmek

• Yeniden başlatmadan sonra WireGuard bağlantısı ayakta görünüyordu, ancak yalnızca bazı sayfalar yükleniyor ve GitHub gibi siteler açılmıyordu
• ping, ping -6, wg show normal görünüyordu; bu yüzden nedeni bulmak zordu
• Farklı boyutlarda ping ile kontrol edildiğinde büyük paketlerin başarısız olduğu görüldü

$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1

• 1400 boyutu başarısız olurken 1200 ve 800 başarılıydı; bunun MTU ayarından kaynaklandığı doğrulandı
• Yerel WireGuard arayüzünün MTU değeri düşürülürse çekirdeğin IP ağı yığını bunun üzerinde paket üretmez
  • Böylece WireGuard kapsülleme ek yükü eklenmiş son UDP paketi de yol üzerindeki küçük MTU'lu bağlantılarda düşmez
• Yol üzerindeki her yönlendiricinin kendi MTU'su vardır ve en küçük MTU'dan büyük paketler düşebilir
• Tünel trafiğinde WireGuard kapsüllemesi yaklaşık 32 baytlık ek yük getirdiği için MTU sorunu daha da belirginleşebilir
• Path MTU Discovery iletileri ara yönlendiricilerden ICMP ile gelebilir; ancak güvenlik duvarları ICMP'yi sıkça düşürdüğünden otomatik ayarlama çalışmayabilir
• IPv6 belirtiminin asgari MTU değeri 1280 olduğundan, IPv6 üzerindeki WireGuard tünellerinde bu değer her zaman çalışmalıdır

Kurtarma sonrası geriye kalan operasyonel seçenekler

• Ortaya çıkan yapılandırma şunları içeriyordu
  • Hem IPv4 hem IPv6 sahibi bir VPS üzerinde WireGuard VPN sunucusu kurulumu
  • Doğrudan IPv6 ve NAT'lanmış IPv6 trafiğinin birlikte desteklenmesi
  • İş VPN'inin ağ namespace içinde çalıştırılması
  • unshare geçici çözümüyle Docker'ın aynı ağ namespace içinde çalıştırılması
  • WireGuard MTU sorununun debug edilmesi
• Uzaktan çalışmada internet bağlantısı sorunları her zaman risk unsurudur ve bu durumda ISP yapılandırmasının düzelmesini beklemeden Linux araçlarıyla geçici çözüm üretilebildi
• Hetzner VPS, WireGuard tüneli ve yasal genel kullanım için destek sunar; ancak port tarama, trafik spoofing ve kripto para madenciliğine izin verilmez
• AirVPN, ProtonVPN ve AzireVPN gibi port yönlendirme destekli VPN'ler de ev sunucusu portlarını ISP'ye bağımlı kalmadan yönlendirmek için alternatif olabilir
• OpenWRT yönlendirici kullanıldığında yönlendirici tarafında daha fazla debug yapılabilir ve bu tür geçici çözümler her cihaza ayrı ayrı ayarlanmadan doğrudan yönlendiricide WireGuard ile uygulanabilir

[GN⁺]

Hacker News yorumları

• Başlık biraz yanlış anlaşılmaya açık. Daha doğrusu bu, bir VPS üzerinden IPv6 tüneliyle IPv4 internete erişmek; genelde 4in6 diye de adlandırılır.
  Yine de ilginç. ISS açısından bakınca, IPv4 bozulduğunda ortaya çıkan destek sorunlarının niteliği ile IPv6 bozulduğundaki oldukça farklı. IPv4 arızası çoğunlukla net bir “çökmüş” durumudur; kullanıcılar çok şikâyet eder ama durum basittir. Buna karşılık IPv6 arızaları kısmi kesinti, fallback yüzünden yavaş başlangıç, ağ geçidinin IPv6 var sandığı durumlar gibi garip biçimlerde kendini gösterir.

  • Geçen sefer IPv4 öldüğünde bunu esas olarak Github çalışmadığı için fark etmiştim. Bugünlerde tüketiciye yönelik web sitelerinin çoğu yalnızca IPv6 ile de çalışıyor.
    Ancak router’ında yalnızca IPv4 DNS sunucusu ayarlı olanlar tamamen kesinti yaşadı. Microsoft işe yaramaz bazı varlıklarını biraz temizlemiş olsaydı, en büyük kaygı muhtemelen router’a verdiğim mDNS host adını hatırlayıp giriş yapmak ve IPv4’ün geri gelip gelmediğini kontrol etmek olurdu.
  • IPv4’ün uzun bir kuyruğu olduğu kesin, ama evde IPv4 en son koptuğunda eşim bunu hiç fark etmedi. Çünkü Google, Facebook, Apple/iCloud ve CloudFlare üzerinde barındırılanların çoğu IPv6 ile çalışmaya devam etti.
  • Benim deneyimim de aynı. IPv6 sorunlarını sınıflandırmak ve yeniden üretmek sinir bozucu derecede zor; “benim bilgisayarımda çalışıyor” türü durumlar çok sık yaşanıyor.
  • Çoğu ISS hâlâ IPv6’yı tamamen engelliyor. Küçük işletmeciler IPv6’yı bir kez denedikten sonra AAAA kayıtlarını güncellemek gibi şeyleri unutabiliyor; bu da kullanıcıya, sevdiği niş bir servis başka ağlarda çalışırken para ödediği ISS’de çalışmıyormuş gibi görünüyor.
    Garip bir sorun ve IPv4’ün bir gün ortadan kalkmasını ummak dışında iyi bir çözüm var mı bilmiyorum. Happy Eyeballs’ın bu sorunu çözmesi bekleniyordu, ama sorun çoğu zaman uygulama katmanının çok daha üstünde ortaya çıkıyor; uygulamalar da her şeyi yapabildiği için, sızdıran soyutlamalar olmadan bunu genel bir protokolle çözmek zor. Ben kişisel olarak ağda IPv6’yı açık tutup tüm tarayıcılarda IPv6 DNS’i kapatmak gibi bir uzlaşma kullanıyorum; ama pek tatmin edici değil.

• IPv6 denemek istiyor ama ISS’niz sunmuyorsa, Hurricane Electric yıllardır tünel hizmeti sağlıyor.
  https://tunnelbroker.net
  https://ipv6.he.net
  Sistemde veya router’da tun aygıtını ayağa kaldırıp trafiği yönlendiren betikler de var: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

  • Bu tür tünellerle ilgili can sıkıcı bir uyarı: Streaming servisleri bunları bölge kısıtlarını aşmaya yarayan VPN gibi engellediği için, gerektiğinde tüneli nasıl kapatacağınızı bulmanız gerekir.
    Yine de iyi çalışıyor. Router HE tünelini desteklemese bile RA’nın gücüyle ağdaki tüm cihazlara IPv6 adresi verebilirsiniz. Herhangi bir cihaz /64 ilan ederse IPv6 router’ı olur. Elbette bunun için router’ın güvenlik nedeniyle RA’yı filtrelemiyor olması gerekir. Port forwarding kurallarına dokunmadan ev ağında servis barındırırken çok kullanışlıdır.
  • Hurricane Electric harika, ama ISS’nin sunduğu IPv6’yı kullananların sayısı arttıkça “normal” kullanıcılar tünelleri terk etti ve ağ servisleri he.net tünellerini kötüye kullanım olarak işaretlemeye başladı.
    Çok fazla site bariyer koyduğu ya da tamamen çalışmayı reddettiği için ağımın büyük bölümünde IPv6 kullanımını bırakmak zorunda kaldım.
  • Bilinmesi gereken nokta şu: Bildiğim kadarıyla HE tüneli yalnızca ISS size genel IPv4 atadığında çalışıyor. Taşıyıcı sınıfı NAT arkasındaysanız, ne yazık ki eve IPv6 getirmek için başka bir çözüme ihtiyacınız var.
  • Memnun bir “müşteriyim”. OpenBSD ile ücretsiz 6in4 tüneli yaklaşık 5 yıldır kullanıyorum; bahsetmeye değer bir sorun yaşamadım.
    Kurulumu yalnızca /etc/hostname.gif0 gibi OpenBSD ağ arayüzü dosyalarıyla yapıyorum: tunnel, inet6 128 alias, !route -n add -inet6 default. Bu bağlantıyı, genel IPv4 adresi olmadan bilerek yapılandırdığım AWS’deki VPS kümesine erişmek için kullanıyorum. Jeff Bezos gibiler IPv4 adres alanını agresif biçimde paraya çevirdiği için, aksi halde bu aylık maliyetin büyük bir kısmını oluştururdu.

• Gerçekten IPv6’ya özel bir ortamda hızlıca IPv4 bağlantısına ihtiyacınız varsa herkese açık bir DNS64+NAT64 ağ geçidi kullanabilirsiniz. Liste https://nat64.net/public-providers adresinde
  Genel kullanımda yalnızca DNS sunucusunu değiştirmek yeterli. DNS64, AAAA kaydı olmayan hedefler için NAT64 kutusuna giden AAAA DNS kayıtları sentezler: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 ise DNS64 nedeniyle kendisine gelen trafiği protokol dönüşümünden geçirip NAT uygular: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

  • Bunu söylemeye gelmiştim. Avrupa’da en azından https://nat64.net/ kendisi oldukça iyi. Hep iyi deneyimlerim oldu
  • Cloudflare WARP kullanırsanız çok daha hızlı olur. WARP üzerinden IPv4 adreslerine de doğrudan bağlanabilirsiniz

• Demek o efsanevi yalnızca IPv6 internet kullanıcısı gerçekten varmış :) Harika bir ağ mühendisliği
  Eskiden daha yaygın olan ters amaç için, yani yalnızca IPv4 bağlantı üzerinden IPv6 ile ilgili işler yapmak için benzer bir şeye ihtiyacım olmuştu. Sunucu üzerinde tam kontrole sahipseniz, daha sınırlı ama hızlı bir çözüm olarak ssh -D 1080 -N myserver ile bir SOCKS5 proxy oluşturup tarayıcıya ayarlamıştım. Sistemin tamamı için de ayarlanabilir gibi geliyor, ama o durumda asıl ssh bağlantısı bozulup her şey çöker mi diye merak ediyorum

• Ben de aynı durumdayım. İki haftadır sadece “bilet açık ve bir teknisyen yakında kontrol edecek” deniyor; epey sinir bozucu
  IPv6 çalıştığı için bunu tam kesinti olarak görmediklerinden önceliği düşük mü, bilmiyorum. Almanya’da bu tür durumlarda tüketici tazminatını garanti eden bir yasa var; yakında bunun bu durum için de geçerli olup olmadığını kontrol edeceğim. Bu blog yazısındaki çözümde, çeşitli uç noktaların veri merkezi IP aralıklarını toptan engellemesi veya birden fazla CAPTCHA istemesi gibi sorunlar var; sıradan VPN sağlayıcılarında da durum aynı. Tüm ev ağını düzeltmek istediğim için bunu yönlendiricide halletmem gerekiyordu; Ubiquiti EdgeRouter gibi standart dışı bir cihazım olduğundan Wireguard yönlendirmesi ve NAT kuralları ayarlamak açısından avantajlıydı. FritzBox gibi cihazlarda nasıl yapardım bilmiyorum. Dezavantajı, yönlendiricinin performansının çok sayıda bağlantıyı kaldırmaya yetmemesi; bu yüzden donanım offloading destekleyen IPSec’e geçmem gerekecek

  • FritzBox’ta da aslında VPN bağlantısı ayarlamak için GUI oldukça iyi. FritzBox’lar arası bağlantı için tasarlanmış bir özellik ama uyumlu herhangi bir VPN de olur. Statik IPv4/IPv6 rotaları da ayarlanabiliyor
    En büyük sorun muhtemelen karşı tarafın hangi IPsec şifreleme yapılandırmasını beklediğini anlamak olacaktır. Wireguard çok daha kolay olabilir, ama o zaman da donanım hızlandırma sorunu çıkabilir. Gerekirse FritzBox yapılandırma dosyasını yedekleyip dump’ı düzenleyerek VPN uç noktasını elle ayarladıktan sonra checksum’ı yeniden hesaplayıp içe aktarabilirsiniz. AVM’de kullanıcıların erişemediği pek çok ayar var ve bu şekilde değiştirilebiliyor; ancak yönlendiriciyi yanlışlıkla tuğlaya çevirmeyin diye erişimi biraz zorlaştırmışlar
  • Almanya’daki durumu bilmiyorum ama Hollanda’da aynı ISS’den hem sabit hem mobil hizmet alıyorsanız ve sabit bağlantıda arıza çıkarsa, arıza giderilene kadar ücretsiz mobil veri isteyebiliyorsunuz
    ISS’ye sormaya değer bir seçenek olabilir

• Apple’ın App Store kurallarında hoşuma giden noktalardan biri, tüm uygulamaların yalnızca IPv6 ağlarda çalışması şartı. Yıllardır var olan bir kural
  Geliştirici olarak ilk karşılaştığınızda biraz şaşırtıcı ama kullanıcı olarak iyi ki var diyorsunuz

  • Uygulama kullanınca Github’a da IPv6 üzerinden erişilebiliyor mu?
  • Ama bu, sunucunun IPv6 adresine sahip olması gerektiği anlamına gelmiyor

• Aynı şeyi yaşarsanız ssh -D 8080 user@hostname ile çok kolay şekilde bir ssh proxy oluşturabilirsiniz
  Bağlantı kurulduktan sonra tarayıcıda SOCKS proxy olarak localhost:8080 kullanmasını belirtmeniz yeterli

  • Ben de aynı tavsiyeyi verecektim. Geçici sorunlar için çok daha basit bir çözüm; proxy gerektiğinde kalıcı bir araç olarak da kullanılabilir
    Bu özelliği kullanmak için sshd_config içinde AllowTcpForwarding etkin olmalı
  • Halka açık Wi-Fi kullanırken bunu hep yapıyorum. VPN’e para ödemeye veya VPN’e güvenmeye gerek kalmadan her şeyi infomaniak sunucuma SOCKS forwarding yapıyorum

• IPv4’ü kapatırken takılınan noktalar var: Alternatif arama motorlarının çoğu IPv6 bağlantısı sunmuyor gibi görünüyor ve GitHub’da son kontrol ettiğimde IPv6 hiç yoktu
  Microsoft olduğu için iyi bir şey beklememek, hatta en kötüsünü beklemek gerekir. Son dönemde issues içinde noscript/basic (x)html’i bile bozdu. noscript/basic (x)html tarayıcısı ve kendi barındırdığınız e-postayla, mailbox@[ipv6:...] gibi IP(v6) literal’ları kullanarak hâlâ hesap oluşturulabiliyor mu onu da bilmiyorum. Steam ya da oyunları da yakın zamanda kontrol etmedim ama birçok CDN/oyun sunucusunun veya ciddi bir kısmının hâlâ yalnızca IPv4 olduğunu düşünüyorum. E-posta sunucularında da pek çoğu kendi barındırılan mail sunucularını engelliyor ve Spamhaus gibi İsviçre/Andorra merkezli şüpheli şirketlerin hazırladığı acemice ve uygunsuz engelleme listelerini kullanıyor. Ayrıca birçok ağ uygulaması IPv6’nın avantajlarından yararlanmıyor. Örneğin web gibi istemci-sunucu uygulamaları, ISP çok küçük bir prefix vermiyorsa her oturum için rastgele üretilmiş IPv6 adresleri kullanmalı. Mobil IPv6 ISP’leri prefix içinde rastgele bir IPv6/128 adresi veriyor gibi görünüyor; oysa uç cihaz uygulamalarının merkezi çevrimiçi ad çözümlemesi olmadan doğrudan ses/görüntülü arama için “sabit” bir IPv6 adresi seçebilmesi adına kararlı bir prefix, muhtemelen 96 bit civarı, sağlamaları gerekir. Kullanıcı uygulamaları arasında IPv6 adresi koordinasyonu için yeni bir kullanıcı düzeyi OS servisine de ihtiyaç var. Ancak bazı vendor ve geliştiricilerin kullanıcıları ve uygulama geliştiricilerini kendilerine bağımlı kılmak için dayatacağı aptalca karmaşıklıklara dikkat etmek gerekir

  • Mini homelab’imde yalnızca IPv6 gayet iyi çalışıyordu, ama bir nedenle GitHub’a ihtiyaç duyunca bozuldu. Bu yüzden NAT64+NAT64 kurdum
    Bunu sırf GitHub yüzünden yapmak zorunda kalmam gerçekten üzücüydü. Mail sunucusu yüzünden bir gün gerekebilirdi ama NAT64’e bu kadar erken ihtiyaç duymamın nedeni olarak bu çok kötüydü. Bence bu, insanların GitHub’ı yazılım dağıtım aracı olarak kullanmasının birçok dezavantajından biri
  • Birkaç ay önce Spamhaus ile uğraşmak zorunda kaldım. Her nedense VPS’imin IPv6 adresi Spamhaus engelleme listesine girmişti
    Bunun neden olduğunu hiç bilmiyorum. O makinede e-posta gönderebilecek hiçbir şey çalışmıyordu ve bildiğim kadarıyla Digital Ocean SMTP’yi de engelliyor, yani bu makinenin e-posta göndermesi kelimenin tam anlamıyla imkânsızdı. Spamhaus çözüm konusunda hiç yardımcı olmadı, DO da öyle
  • Birçok CDN/oyun sunucusunun hâlâ yalnızca IPv4 olması sorunu nedeniyle bir DNS proxy yaptım. Bu tür domain’lere doğru AAAA kayıtlarını ekliyor
    https://gitlab.com/miyurusankalpa/IPv6-dns-server
  • Steam’in IPv4 gerektirdiğini doğrulayabilirim. Oynamak için kimlik doğrulama gerektiren bazı oyunlar da aynı şekilde
  • VPS servisleri gibi yalnızca IPv6 çalıştırınca indirim verilen durumlar dışında, henüz kimsenin IPv4’ten çıkmayı ciddi ciddi düşündüğünü sanmıyorum
    Gerçekte bir şekilde IPv4 bağlantısına sahip olmaya devam etme olasılığınız yüksek; sadece bu bağlantının CGNAT üzerinden gerçekleşme olasılığı giderek artacak. GitHub özellikle sinir bozucu. Haftalarca test ettiler ve her şey iyi çalışıyor gibiydi, sonra yeniden yalnızca IPv4’e döndürdüler. E-posta sunucuları zaten 10-20 yıl önceki dünyada yaşıyor. E-posta sunucusunda SSL 3.0 veya TLS 1.0 desteğini kapatmak bile teslim edilebilirlik sorunlarını göze almadan zor. Microsoft Outlook’un desteği ve spam filtresi, IPv6 destekli mail sunucularını tanımıyor gibi görünüyor. Header’lara bakınca içeride uzun zamandır IPv6 kullanıyor gibi görünmesine rağmen durum böyle. IPv6’nın daha çok kullanılmasını isterdim ama az sayıda müşteride biraz daha kötü çalışabilir korkusu, teknolojiyi gerçekten kullanmaya yönelik tüm girişimleri donduruyor gibi. Mobil operatörlerde garip IP davranışları görmenizin nedeni büyük olasılıkla IP’nin mobil ağlarda çalışma biçimi. Otoyolda giderken konuşuyorsanız ya da hızlı trende oturuyorsanız telefon sürekli handover yapar ve IP adresinde belirli düzeyde kararlılık gerekir. Sınırı geçip yabancı bir ağa geçseniz bile tüm stack kesintisiz bağlantıyı korumalıdır. Hücresel ağın içinde özel routing sistemleri vardır; bunların bazıları IPv6 özelliklerinden çok iyi yararlanır ama telefona “normal” bir statik global unicast adresi vermeyi zorlaştırır. Mümkün olduğunca normal görünmesini sağlarlar, ancak kablolu ev internetindeki gibi bir kararlılığa ulaşmak kolay değildir

• İş yerinde dahili altyapıya erişim için birkaç yalnızca IPv6 VPN işletiyoruz
  Şu ana kadarki en büyük sorun, Windows ve macOS istemcilerinin IPv6 DNS sunucusuna ihtiyaç duyması. Aksi halde v6onlyhost.vpn.example.com adresini çözmeyi denemiyorlar bile. İstemci IPv6 destekli bir ağda olabilir de olmayabilir de; bu yüzden VPN içinde DNS sunucusu çalıştırıp istemciye push etmek gerekiyor. Ancak VPN koptuktan sonra Wireguard uygulaması herhangi bir nedenle DNS’i eski haline döndüremezse türlü türlü sorun çıkabiliyor

  • ISP’nin yalnızca IPv4 ağı kullanılırken bile macOS böyle bir DNS sunucusu olmadan yalnızca IPv6 erişim sağlayabiliyordu
    Ayrıntıları artık hatırlamıyorum ama birkaç yıl önce kurcaladığımda macOS’un sadece IPv6 adresi varsa bu şekilde de gayet iyi çalıştığını görmüştüm. Host’a ULA adresi eklemek yeterli. Elbette kullanıcının bu yöntemi bilmesi gerektiği varsayımı var. VPN uygulamasına bağlı olarak yalnızca IPv6 ağa girerken ULA ekleyen bir script koymak da mümkün. Ancak sahte ULA’yı sürekli bırakmak, kullanıcı IPv6 destekli bir ağa geçtiğinde sorun çıkarabilir
  • Bu bir Windows sorunu değil. Ben de rastgele hotspot’larda benzer sorun yaşadım ama hepsinde değil. Bunun, IPv6 kapalıyken AAAA kayıtlarını döndürmeyen aptal hotspot’lar yüzünden olduğunu düşünüyorum

• Aradan bu kadar zaman geçmiş olmasına rağmen, tüm makinelerimi ve homelab’imi IPv6’ya geçirmek için günlerce saç baş yolduracak kadar ikna edici bir neden hâlâ göremiyorum.
  Haftalarca her şeyi sorun gidermek, güvenlik duvarını yeniden yapılandırmak ve ağ adreslerini yeniden numaralandırmak yerine port forwarding ve güvenlik duvarı kuralları bana daha sezgisel geliyor. Neyi kaçırıyorum?

  • Kaçırdığın şey, bunun sandığın kadar zor olmadığı. Çok karmaşık bir ev ağın yoksa IPv6 kurulumu en fazla bir akşam sürer.
    Benim ağımda ve ISP’m Comcast özelinde, yönlendiricide IPv6’yı açınca ISP’den bir prefix alıyor, bunu yerelde duyuruyor; dışarıdan erişilebilir olmasını istediğin hedef için bir güvenlik duvarı kuralı ekliyorsun, hepsi bu.
  • Hiçbir şey kaçırmıyorsun. Kurumsal ortamlarda IPv6’ya geçmenin artıları eksilerinden ağır basmıyor.
    Yaklaşık 3500 cihaz, 7 bina, iki adet 10 gigabit WAN ve bir adet 4 gigabit WAN yönetiyorum; yaklaşık 26 herkese açık IPv4 adresi ve NAT kullanıyoruz. Şu anda IPv6’ya geçmek için hâlâ güçlü bir neden yok. Çift yığın yapılandırması, kayda değer bir fayda sağlamadan yalnızca gereksiz trafik ve karmaşıklık ekliyor. Statik IPv6 adres bloğu almak hâlâ zor; iki kez başvurdum ama reddedildim. Sadece kazanım alanı az değil, bloğu almak bile hâlâ zor. https://www.arin.net/resources/guide/ipv6/first_request/ adresindeki uygunluk koşulları da IPv4 tahsisine sahip olmak, hemen IPv6 multihoming planlamak, 1 yıl içinde 13 uç site, 1 yıl içinde 2.000 IPv6 adresi kullanımı, 1 yıl içinde 200 adet /64 alt ağ kullanımı gibi şeyler.
  • Şu an için büyük bir şey kaçırmıyorsun. Bir gün Google, Cloudflare gibi büyük şirketler giderek pahalanan IPv4 adres maliyetlerinden bıkıp IPv6 için teşvikler verebilir. Örneğin IPv4’ü kısıtlamaya başlayabilirler.
    İlk işaretler zaten var. AWS eskiden yalnızca kullanılmayan IPv4 Elastic IP adresleri için ücret alıyordu; artık kullanılıp kullanılmadığına bakmadan ücret alıyor. Açıkçası, bir sonraki gateway veya yönlendirici yükseltmende hazır hale getirmen yeterli olur; şu anda kaçırdığın bir şey yok. IPv4 ve IPv6’yı aynı anda da kullanabilirsin. Yönlendiricide açsan bile yalnızca IPv4 destekleyen cihazlar eskisi gibi sorunsuz çalışır. Dikkat edilmesi gereken bir nokta, IPv6 otomatik keşfinin bir dönem epey dağınık olmasıydı. SLAAC, IPv6 otomatik adresleme ve DHCPv6’nın hepsi vardı; başlangıçta otomatik adresleme DNS sunucusu almayı bile desteklemiyordu. Artık SLAAC tarafında toparlanmaya başladı, ama ISP’ler çok uzun süre DHCPv6 kullanacaktır.