IPv6'yı iki saha arasında mevcut bir VPN üzerinden yönlendirme

Yalnızca IPv4 olan bir WAN yine de iç IPv6 taşıyabilir. Seçicileri, çekirdek yollarını, iletmeyi ve yanıtları sessizce düşüren dönüş önekini izleyin.

Sahalar arası bir tünele IPv6 öneki eklediğinizde, paket şemanın önerdiği gibi yol almaz. Yerel ağ geçidi tüm IPv6 paketini alır, şifreler ve önüne, içindekine değil, uç noktaların adreslerine göre belirlenen bir dış IP başlığı koyar. Uzak ağ geçidi bu dış başlığı söker ve özgün paketi kendi LAN'ına iletir; orada paket yeniden sıradan bir IPv6 paketidir. Dış tünel ile iç trafik, bir anahtarı, bir uç nokta çiftini paylaşan ve başka hiçbir şeyi paylaşmayan iki ayrı konuşmadır.

İki başlık, iki adres ailesi

IPsec tünel modunda iç IPv6 paketi ESP başlığının arkasındaki yük haline gelir. Bu ESP paketini taşıyan dış başlık IPv4 ya da IPv6 olabilir ve local_addrs ile remote_addrs'i izler. WireGuard aynı şeyi daha az törenle yapar: iç paket, eşin uç noktasına giden bir UDP veri biriminin yüküdür. İkisi de iç başlığı dokunulmadan bırakır; uzak taraf bu yüzden paketi çözümlemeden sonra yönlendirebilir.

Sahalar arasındaki yol yalnızca UDP 4500'i görür — IPsec NAT geçişi kullandığında, ya da varsayılan bir WireGuard dinleyicisi için UDP 51820. Yoldaki herhangi bir yönlendirici yalnızca IPv4 olabilir ve IPv6 trafiği yine de geçer, çünkü o yolda hiçbir zaman IPv6 paketi olarak görünmez. Bu temiz bir ilk ayrım verir: tcpdump -ni eth0 udp port 51820 şifreli yolu, tcpdump -ni wg0 ip6 iç trafiği gösterir. Dış kayıt yoğun, iç kayıt sessizse çekirdek IPv6'yı tünele koymuyor demektir; bu yönlendirme ya da politikadır, bağlantı durumu değil.

Ağ geçidi iletirken iç Hop Limit'i de düşürür, bu yüzden uç noktalar IPv6 yolunda yönlendirici sayılır. Dış atlama sayısı ile iç Hop Limit bağımsız hareket eder ve uzak ağ geçidinde ölen paket iletmede öldü, şifrelemede değil.

Seçiciler ve AllowedIPs izin listesidir

IKEv2, child SA'nın hangi iç önekleri taşıyabileceğini görüşür. strongSwan 5.9 ve sonrasında onları swanctl.conf içinde yazmak şöyle görünür:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

local_ts ve remote_ts'i atlarsanız strongSwan bunları seçtiği arayüzün alt ağlarından türetir. Çift yığınlı bir ana bilgisayarda bu kısa yol genellikle yalnızca IPv4 çifti verir: SA ayağa kalkar ve IPv6, ESP koduna ulaşmadan reddedilir. İki öneki de yazmak SA'yı onları taşımaya uygun kılar ve start_action = trap onu ilk eşleşen pakette kaldırır.

WireGuard'ın iki iş yapan tek bir listesi vardır. Eş bloğunda AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 hem gönderirken kurulan yol hem de alırken uygulanan süzgeçtir: iç kaynağı o eşin listesinin dışına düşen çözülmüş paket sessizce atılır. wg-quick her girdi için bir yol ekler, bu yüzden aşağıdaki eş bloğu ayrı bir ip -6 route komutuna ihtiyaç duymaz.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

İki liste de aynalanmalı: saha B, saha A'nın önekini uzak seçici olarak kabul eder ve geri yönlendirir; tünel ancak iki yön anlaşırsa çalışır. Asimetrik liste en çok zaman kaybettiren belirtiyi verir — sağlıklı bir el sıkışma, tek tarafta ilerleyen sayaçlar ve A'dan B'ye başarıyla geçen bir ping, oysa B'den hiçbir şey A'ya ulaşmaz.

İletme, yollar ve dönüş öneki

Linux siz söylemeden IPv6 iletmez ve ayar arayüz başına değil, ad alanı başınadır:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

İkinci satır, yol tabanlı tasarımlarda insanların unuttuğu satırdır. İlke tabanlı IPsec, öneklere uyan bir XFRM ilkesi kurar, ancak vti6 ya da WireGuard ile yol tabanlı bir kurulumun o cihaza işaret eden gerçek bir IPv6 yoluna ihtiyacı vardır. sysctl'i /etc/sysctl.d/ altında kalıcı yapın; yoksa yeniden başlatma iletmeyi sessizce kapalı duruma döndürür.

İletmenin bilinmeye değer bir yan etkisi vardır: çekirdek o zaman yönlendirici duyurularını yok sayar, net.ipv6.conf.<wan>.accept_ra 2 olmadıkça; bu yüzden WAN adresi SLAAC ile gelen bir ağ geçidi, iletmeyi etkinleştirdiğiniz anda varsayılan yolunu kaybedebilir. Aynı dosyada o arayüzde accept_ra = 2 ayarlayın ve yol yaşar. B sahasının çekirdeği de tünel ağ geçidinden 2001:db8:aa::/48 öğrenmelidir — statik yol ya da tünel üzerinden bir yönlendirme protokolüyle, yoksa yanıt B'nin kendi ağında ölür.

Kırılmayı yerelleştiren dört adımlı bir denetim

Bu sırayla çalışın ve başarısız olan ilk adımda durun, çünkü her sonraki adım öncekilere bağlıdır.

  1. Seçiciler: swanctl --list-sas child SA üzerinde IPv6 önek çiftini göstermeli, ya da wg show wg0 allowed-ips uzak öneki yeni bir latest-handshakes ile göstermeli.
  2. Çekirdek yolu: ip -6 route get 2001:db8:bb::10 tünel aygıtıyla yanıt vermeli, WAN arayüzüyle değil.
  3. İç kayıt: tcpdump -ni wg0 ip6 gerçek LAN ana bilgisayarları arasında ping atarken. Çıkıp da hiçbiri geri dönmeyen paketler B'nin yoluna ya da güvenlik duvarına işaret eder; hiç paket olmaması 1 ya da 2 adıma işaret eder.
  4. Hedef: B ana bilgisayarında ss -6 -ltn hizmetin IPv6 üzerinde dinlediğini doğrular ve yerel güvenlik duvarı sayaçları paketin kabul mü edildiğini yoksa düşürüldüğünü gösterir.

MTU aynı geçişe aittir. IPv6 yönlendiricileri parçalamaz, bu yüzden fazla büyük paket düşürülür ve Packet Too Big gönderene geri döner. El sıkışmalar ve küçük ping'ler çalışıyor ama bir dosya aktarımı tıkanıyorsa, yükü geçene kadar küçültün: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard arayüzleri varsayılan olarak 1420 bayt MTU'ya sahiptir ve IPv4 üzerindeki IPsec daha fazlasını çıkarır, bu yüzden iç MTU'yu ayarlamak, ICMPv6'yı düşüren bir güvenlik duvarı üzerinden yol MTU keşfini ummaktan iyidir.

Güvenlik duvarı sorunlarına benzeyen arıza kipleri

En yaygın olanı hiç de güvenlik duvarı değildir: hizmet :: yerine 0.0.0.0'e bağlanır, AAAA kaydı vardır ve istemci IPv6 üzerinden hızlı bir ret alır; çift yığınlı bir tarayıcı IPv4'e düşerek bunu gizler. Yalnızca bazı uygulamalar başarısız oluyorsa, kural kümesine dokunmadan önce dinleme ailesini denetleyin.

İkincisi ICMPv6 süzmesidir. Neighbor Discovery ve Packet Too Big normal işleyişin parçasıdır, tanılama değil; tüm ICMPv6'yı düşüren bir ilke, bağlanan, kimlik doğrulayan ve sonra küçük bir paketten büyük her şeyde tıkanan bir tünel üretir. Yolun bağlı olduğu tiplere izin verin ve sayaçları açık bırakın ki bir düşürme görünür olsun.

Üçüncüsü tünele eklenen ama sahibi olan sahanın adres planına hiç eklenmeyen bir önektir; bu yüzden hiçbir yönlendirici onu duyurmaz ve hiçbir ana bilgisayar ondan yanıt veremez. Tek bir önek ve tek bir ana bilgisayar çiftiyle başlayın, iki yönü dört adımla kanıtlayın, sonra gerisini ekleyin; bozuk bir önek yeniden tasarım yerine yapılandırmada tek satır olarak kalır. Açık tutmaya değer tek resmî başvuru RFC 8200 olup tünelin taşıdığı başlığı tanımlar.

İlgili makaleler