IPv6-nı iki sayt arasında mövcud VPN ilə marşrutlaşdırmaq

Saytlararası tunelə IPv6 prefiksi əlavə etdikdə paket diaqramın təklif etdiyi kimi hərəkət etmir. Yerli şlüz bütün IPv6 paketini götürür, şifrələyir və qarşısına içəridəkinə deyil, son nöqtələrin ünvanları ilə müəyyən edilən xarici IP başlığı qoyur. Uzaq şlüz həmin xarici başlığı çıxarır və orijinal paketi öz LAN-na ötürür, orada o yenidən adi IPv6 paketidir. Xarici tunel və daxili trafik bir açarı, bir son nöqtə cütünü bölüşən və başqa heç nə bölüşməyən iki ayrı söhbətdir.

İki başlıq, iki ünvan ailəsi

IPsec tunel rejimində daxili IPv6 paketi ESP başlığının arxasındakı yükə çevrilir. Həmin ESP paketini daşıyan xarici başlıq IPv4 və ya IPv6 ola bilər və local_addrs ilə remote_addrs-i izləyir. WireGuard eyni şeyi daha az mərasimlə edir: daxili paket tərəfdaşın son nöqtəsinə gedən UDP dataqramının yüküdür. Hər ikisi daxili başlığı toxunulmaz qoyur, buna görə uzaq tərəf dekapsulyasiyadan sonra onu marşrutlaşdıra bilər.

Saytlar arasındakı yol yalnız UDP 4500 görür — IPsec NAT keçidindən istifadə etdikdə, və ya WireGuard-ın standart dinləyicisi üçün UDP 51820. Yoldakı hər hansı marşrutlaşdırıcı yalnız IPv4 ola bilər, IPv6 trafiki isə yenə keçir, çünki o bu yolda heç vaxt IPv6 paketi kimi görünmür. Bu təmiz ilk bölgü verir: tcpdump -ni eth0 udp port 51820 şifrələnmiş yolu, tcpdump -ni wg0 ip6 daxili trafiki göstərir. Xarici tutma məşğul, daxili isə səssizdirsə, nüvə IPv6-nı tunelə qoymur; bu marşrutlaşdırma və ya siyasətdir, keçid vəziyyəti deyil.

Şlüz ötürərkən daxili Hop Limit-i də azaldır, buna görə son nöqtələr IPv6 yolunda marşrutlaşdırıcı sayılır. Xarici atlama sayı və daxili Hop Limit bir-birindən asılı olmayaraq hərəkət edir, uzaq şlüzdə ölən paket isə ötürmədə öldü, şifrələmədə deyil.

Selektorlar və AllowedIPs icazə siyahısıdır

IKEv2 child SA-nın hansı daxili prefiksləri daşıya biləcəyini razılaşdırır. strongSwan 5.9 və daha yenisində onları swanctl.conf-də yazmaq belə 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
  }
}

Əgər local_ts və remote_ts-i buraxsaq, strongSwan onları seçdiyi interfeysin alt şəbəkələrindən çıxarır. Dual-stack hostda bu qısa yol çox vaxt yalnız IPv4 cütü verir: SA qalxır, IPv6 isə ESP koduna çatmadan rədd edilir. Hər iki prefiksi yazmaq SA-nı onları daşımağa qadir edir və start_action = trap onu ilk uyğun paketdə qaldırır.

WireGuard-ın iki iş görən bir siyahısı var. Tərəfdaş blokunda AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 həm göndərmə zamanı quraşdırılan marşrut, həm də qəbul zamanı tətbiq edilən filtrdir: daxili mənbəyi həmin tərəfdaşın siyahısından kənara düşən deşifrə olunmuş paket səssizcə atılır. wg-quick hər qeyd üçün marşrut əlavə edir, buna görə aşağıdakı tərəfdaş blokuna ayrıca ip -6 route əmri lazım deyil.

[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

Hər iki siyahı güzgü kimi olmalıdır: B saytı A saytının prefiksini uzaq selektor kimi qəbul edir və geri marşrutlaşdırır, tunel isə yalnız iki istiqamət razılaşdıqda işləyir. Asimmetrik siyahı ən çox vaxt aparan simptomu verir — sağlam əl sıxma, bir tərəfdə hərəkət edən sayğaclar və A-dan B-yə uğurla gedən ping, halbuki B-dən heç nə A-ya çatmır.

Ötürmə, marşrutlar və qayıdış prefiksi

Linux siz deməyincə IPv6-nı ötürmür və parametr interfeysə deyil, namespace-ə aiddir:

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 sətir marşruta əsaslanan layihələrdə insanların unutduğu sətirdir. Siyasətə əsaslanan IPsec prefikslərə uyğun XFRM siyasəti quraşdırır, amma vti6 və ya WireGuard ilə marşruta əsaslanan konfiqurasiya həmin cihaza yönəlmiş real IPv6 marşrutu tələb edir. sysctl-i /etc/sysctl.d/ altında saxlayın; əks halda yenidən yükləmə ötürməni səssizcə söndürülmüş vəziyyətə qaytarır.

Ötürmənin bilməyə dəyər yan təsiri var: nüvə bundan sonra marşrutlaşdırıcı elanlarını saymaz, əgər net.ipv6.conf.<wan>.accept_ra 2 deyilsə, buna görə WAN ünvanı SLAAC ilə gələn şlüz ötürməni yandırdığınız anda standart marşrutunu itirə bilər. Həmin interfeysdə accept_ra = 2-i eyni faylda qurun və marşrut sağ qalır. B saytının nüvəsi də tunel şlüzündən 2001:db8:aa::/48-u öyrənməlidir — statik marşrut və ya tunel üzərində marşrutlaşdırma protokolu ilə, əks halda cavab B-nin öz şəbəkəsində ölür.

Qırılmanı lokallaşdıran dörd addımlı yoxlama

Bu ardıcıllıqla işləyin və uğursuz olan ilk addımda dayanın, çünki hər sonrakı addım əvvəlkilərdən asılıdır.

1. Selektorlar: swanctl --list-sas child SA-da IPv6 prefiks cütünü, ya da wg show wg0 allowed-ips uzaq prefiksi təzə latest-handshakes ilə göstərməlidir.
2. Nüvə marşrutu: ip -6 route get 2001:db8:bb::10 tunel cihazı ilə cavab verməlidir, WAN interfeysi ilə deyil.
3. Daxili tutma: tcpdump -ni wg0 ip6 real LAN hostları arasında ping edərkən. Çıxan, amma heç biri qayıtmayan paketlər B-nin marşrutunu və ya firewall-u göstərir; heç paket olmaması 1 və ya 2-ci addıma işarə edir.
4. Təyinat: B hostunda ss -6 -ltn xidmətin IPv6-da dinlədiyini təsdiqləyir, yerli firewall sayğacları isə paketin qəbul və ya atıldığını göstərir.

MTU eyni keçidə aiddir. IPv6 marşrutlaşdırıcıları fraqmentasiya etmir, buna görə həddindən böyük paket atılır və Packet Too Big göndərənə qayıdır. Əgər əl sıxmalar və kiçik ping-lər işləyir, amma fayl ötürməsi dayanırsa, yükü kiçildin, keçənə qədər: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard interfeysləri standart olaraq 1420 bayt MTU-ya malikdir, IPv4 üzərindəki IPsec isə daha çox çıxır, buna görə daxili MTU-nu qurmaq ICMPv6-nı atan firewall-dan keçən yol MTU-nun aşkarlanmasına ümid etməkdən yaxşıdır.

Firewall probleminə bənzəyən nasazlıq rejimləri

Ən çox yayılanı heç firewall deyil: xidmət :: əvəzinə 0.0.0.0-ə bağlanır, AAAA qeydi mövcuddur və müştəri IPv6 üzərindən sürətli imtina alır, onu dual-stack brauzer IPv4-ə qayıdaraq gizlədir. Yalnız bəzi tətbiqlər uğursuz olursa, qaydalar dəstinə toxunmazdan əvvəl dinləyən ailəni yoxlayın.

İkincisi ICMPv6 filtrləməsidir. Neighbor Discovery və Packet Too Big normal işin hissəsidir, diaqnostika deyil, və bütün ICMPv6-nı atan siyasət qoşulan, autentifikasiya olunan və sonra kiçik paketdən böyük hər şeydə dayanan tunel yaradır. Yolun asılı olduğu tiplərə icazə verin və sayğacları yandırılmış saxlayın ki, atılma görünsün.

Üçüncüsü tunelə əlavə edilən, amma ona sahib olan saytın ünvan planına heç vaxt əlavə edilməyən prefiksdır, buna görə heç bir marşrutlaşdırıcı onu elan etmir və heç bir host ondan cavab verə bilməz. Bir prefiks və bir host cütü ilə başlayın, iki istiqaməti dörd addımla sübut edin, sonra qalanı əlavə edin; pozulmuş prefiks yenidən qurulmanın əvəzinə konfiqurasiyada bir sətir olaraq qalır. Açıq saxlamağa dəyər yeganə rəsmi mənbə RFC 8200-dir və tunelin daşıdığı başlığı müəyyən edir.