Siteden Siteye VPN Üzerinden IPv6 Önek Yetkilendirmesi: Kontrol Listesi

Tüneli ayağa kaldırmak işin kolay yarısı. Siteden siteye bir bağlantının günlerce kurulu kalıp uzak LAN'daki her ana bilgisayarın yalnızca sessizlik aldığını gördüm, çünkü o ağ geçidinin arkasındaki yetkilendirilmiş önek bir arayüze yapılandırılmış ama hiçbir zaman tünele yönlendirilmemişti. Tünel adresleri bunca zaman ping'e yanıt veriyordu ve tam da bu yüzden kimse öneğe bakmadı. Yetkilendirilmiş bir IPv6 önekinin site VPN'inden geçmesi gerektiğinde kontrol ettiğim sıra şudur: önek haritası, trafik seçicileri, yönlendirme ve güvenlik duvarı, ardından dönüş yolu.

Tünele dokunmadan önce önek haritasını yazın

Önek yetkilendirmesi, bloğu talep eden yönlendiriciye verir. Eşe bir rota kurmaz, o bloğu on-link olarak genişletmez ve uzak ağ geçidine talep eden yönlendiricinin arkasında ne olduğunu söylemez. Bu üçünü sizin yapılandırmanız gerekir ve herhangi bir yapılandırma dosyası değişmeden önce bir adres planında yer almaları gerekir.

Her site için yetkilendirilmiş öneği, LAN'da gerçekten kullanılan /64'ü, tünel adreslerini ve her rotanın sahibini kaydedin. Sağlayıcı, 2001:db8:a1::/56 bloğunu A sitesine yetkilendirir; A sitesi kendi LAN'ında 2001:db8:a1:10::/64'ü sunar, B sitesi 2001:db8:b2::/64'ü korur. A sitesi yalnızca o tek /64'ü sunuyorsa, iki uç da tüm /56 yerine 2001:db8:a1:10::/64 belirtmelidir.

Neredeyse her zaman iki hata ortaya çıkar. Biri uzak öneği on-link sayıp köprülemek veya tünel arayüzüne koymak, böylece ağ geçidinin ulaşamadığı ana bilgisayarlar için komşu isteklerine yanıt vermesidir. Diğeri, yalnızca bir /64 yapılandırılmışken tüm /56'yı duyurmaktır: yönlendirme tablosu bloğun erişilebilir olduğunu iddia eder ve adreslerin çoğu kara deliğe düşer.

İki ucun trafik seçicilerini rotalarla eşleştirin

IKEv2 ve WireGuard ikisi de uyuşmayan trafiği reddeder, tünel hâlâ sağlıklı görünecek kadar sessizce.

strongSwan'da seçiciler açıktır. A sitesinde:

conn a-to-b
    left=2001:db8:ff::1
    leftsubnet=2001:db8:a1:10::/64
    right=2001:db8:ff::2
    rightsubnet=2001:db8:b2::/64
    auto=start

B sitesinin conn kaydı iki alt ağı yansıtır. Uyuşmadıklarında yanıtlayıcı CHILD_SA'yı TS_UNACCEPTABLE ile reddeder, böylece IKE_SA kurulmuş olsa da child SA hiç kurulmaz. Her iki tarafta yapılandırılan alt ağ, yerel çekirdeğin tünele doğru yönlendirdiğiyle eşit olmalıdır.

WireGuard aynı bilgiyi AllowedIPs içinde taşır, bir incelikle: AllowedIPs alırken kaynak filtresi, gönderirken rotadır. B sitesinin A sitesi için peer kaydı 2001:db8:a1:10::/64'ü atlarsa, A sitesinden gelen paketler geçerli bir handshake ile ulaşır ve izin verilmediği için düşürülür. Bu, handshake'in sürekli yenilendiği ama hiçbir yanıtın çıkmadığı tanıdık deseni üretir. İki ucu wg show wg0 allowed-ips ile karşılaştırın. Yetkilendirme her değiştiğinde o listeyi yeniden kontrol edin; eski bir /64 oturumu ayakta tutar ve yeni öneği erişilemez kılar.

Önce yönlendirmeyi, güvenlik duvarını ve MTU'yu eleyin

Bir log satırı daha okumadan önce ağ geçitlerinin gerçekten yönlendirdiğini doğrulayın. sysctl net.ipv6.conf.all.forwarding her ikisinde de 1 döndürmeli, tünel ve LAN arayüzlerine de uygulanmalıdır. Bir tuzak da beraberinde gelir: yönlendirme açıldığında accept_ra=1 olan bir arayüz sağlayıcıdan yönlendirici duyurularını almayı bırakır, böylece makine tünelin içinde kusursuz yönlendirse de yukarı akış varsayılan rotasını kaybedebilir. Sağlayıcı RA'sının hâlâ gerektiği yerlerde accept_ra=2 ayarlayın.

Ardından güvenlik duvarı kuralları öneği iki yönde de izin vermeli ve ICMPv6 hayatta kalmalıdır: komşu keşfi, packet-too-big ve destination-unreachable isteğe bağlı değildir. Bunları düşürürseniz yol MTU keşfi bozulur ve açılıp ilk büyük yanıtta takılan bağlantılar elde edersiniz. Asgari kural çifti şöyle görünür:

nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } accept

MTU bunun arkasındadır. Tünel kullanılabilir MTU'yu 1500'ün altına indirir ve IPv6 her bağlantının en az 1280 taşımasını şart koşar. Küçük ping'ler geçer, bir SSH oturumu büyük bir patlamada donar ve /proc/net/snmp6 hiç geri dönmeyen packet-too-big iletileri gösterir. Tünelin MTU'sunu açıkça ayarlayın ya da mangle tablosunda TCP MSS'yi sınırlayın ve daha küçük MTU'yu bildiren ICMPv6'nın geri dönmesine izin verin.

Tünel adresini değil dönüş yolunu test edin

En çok zaman kaybettiren arıza tek yönlü yönlendirmedir. Her ağ geçidi uzak öneği tünele yönlendirir ama ana bilgisayarlar kendi varsayılan ağ geçitleri üzerinden yanıt verir çünkü /64'leri orada yaşar. Bir paketi hedefe ulaştırmak yolun yarısıdır.

İki komut çoğunu çözer. A sitesinde ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5, o kaynaktan gelen yanıtın hangi arayüzü kullanacağını gösterir; B sitesinde ayna kontrolünü yapın. Sonra trafiği ağ geçidinden değil bir ana bilgisayardan üretin ve iki uçtaki sayaçları karşılaştırın.

Uzak önek için komşu isteği tünelde görünüyorsa, o önek olmaması gereken bir yerde on-link; rotaları ayarlamadan önce bunu düzeltin. Proxy NDP, köprülemenin gerçekten gerekli olduğu durumları kapsar, rotanın yerine geçmez.

Öneğin altınızdan değişmesini planlayın

Önek yetkilendirmesi, yetkilendiren ile talep eden yönlendirici arasında bir kiralamadır ve yenileme farklı bir blok döndürebilir: sağlayıcı taşımasından sonra başka bir /56 ya da tünelin ayakta olduğu süreden daha kısa bir kiralama. Eski öneği adlandıran her yer aynı anda eskir: rotalar, seçiciler, AllowedIPs, güvenlik duvarı kuralları, DNS kayıtları ve değişmez adresleri sabit kodlayan her izleme. İleti akışı RFC 8415 içindedir.

Öneğin hareket etmesi beklenen yerlerde ona bağlı olmayan bir iç adres planı tutun ve sınırda çevirin. NPTv6 durumsuz seçenektir ve iç politikayı okunur tutar, ama bu önek çeviridir, sihirli bir katman değildir: /64 sınırları hizalanmalı, sağlama toplamları ayarlanmalı ve değişmez adresleri gömülü tutan uygulamalar yine de bozulur. Sağlayıcı adreslerini uçtan uca koruyorsanız kiralama davranışını ve değişiklik prosedürünü adres planına kaydedin.

Zamana dayanan bir testle bitirin: her LAN'daki izinli bir ana bilgisayar diğer LAN'daki bir hizmete ulaşır, yanıt tünelden geri döner ve aynı çift tünel yeniden başlatıldıktan ve yetkilendirme yenilendikten sonra da çalışır. Son bölüm başarısız olursa tasarım haftayı çıkarmayacak bir duruma bağlıdır.