IPv6 prefiks delegasiyası saytlararası VPN üzərindən: yoxlama siyahısı

Tuneli qaldırmaq asan yarısıdır. Uzaq LAN-dakı hər host səssizliklə qarşılaşdığı halda saytlararası linkin günlərlə qurulu qaldığını görmüşəm, çünki həmin şlüzün arxasındakı delegasiya edilmiş prefiks interfeysdə konfiqurasiya olunmuş, amma heç vaxt tunelə marşrutlaşdırılmamışdı. Tunel ünvanları bütün müddət pinqlərə cavab verirdi və məhz buna görə heç kim prefiksə baxmamışdı. Delegasiya edilmiş IPv6 prefiksi sayt VPN-dən keçməli olduqda yoxladığım sıra belədir: prefiks xəritəsi, trafik seçiciləri, forvardinq və firewall, sonra qayıdış yolu.

Tunelə toxunmazdan əvvəl prefiks xəritəsini yazın

Prefiks delegasiyası bloku onu tələb edən marşrutlaşdırıcıya verir. O, peer-də marşrut quraşdırmır, həmin bloku link üzərində genişləndirmir və uzaq şlüzə tələb edən marşrutlaşdırıcının arxasında nə olduğunu demir. Bu üç şey sizin konfiqurasiya etməli olduğunuz işdir və hər hansı konfiqurasiya faylı dəyişməzdən əvvəl ünvan planına aiddir.

Hər sayt üçün delegasiya edilmiş prefiksi, LAN-da faktiki istifadə olunan /64-ü, tunel ünvanlarını və hər marşrutun sahibini qeyd edin. Provayder A saytına 2001:db8:a1::/56 delegasiya edir, o da öz LAN-ında 2001:db8:a1:10::/64 xidməti göstərir; B saytı 2001:db8:b2::/64 saxlayır. Əgər A saytı yalnız həmin bir /64-ə xidmət edirsə, hər iki tərəf bütün /56 əvəzinə 2001:db8:a1:10::/64 adını çəkməlidir.

Demək olar ki, hər dəfə iki səhv görünür. Biri uzaq prefiksə link üzərindəymiş kimi yanaşmaq, onu körpüləmək və ya tunel interfeysinə qoymaqdır ki, şlüz çata bilmədiyi hostlar üçün qonşu sorğusuna cavab versin. Digəri isə yalnız bir /64 konfiqurasiya olunduğu halda bütün /56-nı elan etməkdir: marşrut cədvəli bloku əlçatan elan edir və ünvanların çoxu qara dəliyə düşür.

Hər iki tərəfin trafik seçicilərini marşrutlara uyğunlaşdırın

IKEv2 və WireGuard hər ikisi uyğunsuz trafiki rədd edir, tunelin hələ də sağlam görünəcək qədər səssizcə.

strongSwan-da seçicilər açıqdır. A saytında:

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 saytının conn-u iki subneti əks etdirir. Onlar uyğunsuz olduqda responder CHILD_SA-nı TS_UNACCEPTABLE ilə rədd edir, yəni IKE_SA qalxdığı halda child SA heç vaxt qalxmır. Hər iki tərəfdə konfiqurasiya olunmuş subnet yerli kernin tunelə doğru marşrutlaşdırdığı ilə bərabər olmalıdır.

WireGuard eyni məlumatı AllowedIPs-də daşıyır, bir fərqlə: AllowedIPs qəbulda mənbə filtri, göndərmədə isə marşrutdur. Əgər B saytının A saytı üçün peer qeydi 2001:db8:a1:10::/64 ünvanını buraxırsa, A saytından gələn paketlər etibarlı əl sıxışması ilə gəlir və icazə verilməyən kimi atılır. Bu, əl sıxışmasının davamlı yeniləndiyi, lakin heç bir cavabın çıxmadığı tanış mənzərəni yaradır. Hər iki tərəfi wg show wg0 allowed-ips ilə müqayisə edin. Delegasiya dəyişdikcə siyahını yenidən yoxlayın; köhnəlmiş /64 sessiyanı qurulu saxlayır və yeni prefiksi əlçatmaz edir.

Əvvəlcə forvardinqi, firewall-u və MTU-nu istisna edin

Növbəti log sətrini oxumazdan əvvəl şlüzlarin ümumiyyətlə forvardinq etdiyini təsdiqləyin. sysctl net.ipv6.conf.all.forwarding hər ikisində 1 qaytarmalıdır, tunel və LAN interfeyslərinə də tətbiq olunmalıdır. Bir tələ də var: forvardinq yandıqdan sonra accept_ra=1 olan interfeys provayderdən gələn marşrutlaşdırıcı elanlarını qəbul etməyi dayandırır, yəni qutu tunelin içində mükəmməl marşrutlaşdırdığı halda yuxarı axın defolt marşrutunu itirə bilər. Provayder RA-sı hələ lazım olan yerdə accept_ra=2 təyin edin.

Sonra firewall qaydaları prefiksə hər iki istiqamətdə icazə verməlidir və ICMPv6 sağ qalmalıdır: qonşu kəşfi, həddindən böyük paket və təyinat əlçatmazdır — bunlar seçim deyil. Onları atsanız, yol MTU kəşfi pozulur və ilk böyük cavabda dayanan bağlantılar alırsınız. Minimal qayda cütü belə 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 arxasındadır. Tunel istifadə oluna bilən MTU-nu 1500-dən aşağı salır və IPv6 hər linkin ən azı 1280 daşımasını tələb edir. Kiçik pinqlər keçir, SSH sessiyası böyük partlayışda donur və /proc/net/snmp6 heç vaxt qayıtmayan həddindən böyük paket mesajlarını göstərir. Tunel MTU-sunu açıq şəkildə təyin edin və ya mangle cədvəlində TCP MSS-i sıxın və daha kiçik MTU-nu bildirən ICMPv6-nın qayıtmasına icazə verin.

Tunel ünvanını deyil, qayıdış yolunu sınayın

Ən çox vaxt aparan nasazlıq birtərəfli marşrutlaşdırmadır. Hər şlüz uzaq prefiksi tunelə marşrutlaşdırır, lakin hostlar öz defolt şlüzləri vasitəsilə cavab verir, çünki onların /64-ü orada yaşayır. Paketi təyinatına çatdırmaq yolun yalnız yarısıdır.

İki əmr bunun çoxunu həll edir. A saytında ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 həmin mənbədən gələn cavabın hansı interfeysdən istifadə edəcəyini göstərir; güzgü yoxlamasını B saytında aparın. Sonra trafiki şlüzdən deyil, hostdan yaradın və hər iki tərəfdə sayğacları müqayisə edin.

Uzaq prefiks üçün qonşu sorğusu tuneldə görünürsə, həmin prefiks olmamalı olduğu yerdə link üzərindədir; marşrutları düzəltməzdən əvvəl bunu həll edin. Proxy NDP körpüləmənin həqiqətən lazım olduğu halları əhatə edir, marşrutun əvəzi deyil.

Prefiksin ayağınızın altında dəyişməsini planlaşdırın

Prefiks delegasiyası delegasiya edən və tələb edən marşrutlaşdırıcı arasında icarədir və yenilənmə fərqli blok qaytara bilər: provayder miqrasiyasından sonra fərqli /56 və ya tunelin işlədiyi müddətdən qısa icarə. Köhnə prefiksi adlandıran hər yer birdən köhnəlir: marşrutlar, seçicilər, AllowedIPs, firewall qaydaları, DNS qeydləri və hərfi ünvanları kodlaşdıran istənilən monitorinq. Mesaj axını RFC 8415.

Prefiksin dəyişməsi gözlənilən yerlərdə ondan asılı olmayan daxili ünvan planı saxlayın və sərhəddə tərcümə edin. NPTv6 vəziyyətsiz seçimdir və daxili siyasəti oxunaqlı saxlayır, lakin bu prefiks tərcüməsidir, sehrli qat deyil: /64 sərhədləri üst-üstə düşməlidir, yoxlama məbləğləri düzəldilir və hərfi ünvanları daxil edən tətbiqlər yenə də sınır. Provayder ünvanlarını başdan sona saxlayırsınızsa, icarə davranışını və dəyişiklik prosedurunu ünvan planına yazın.

Zamana davam edən bir sınaqla bitirin: hər LAN-da icazəli host digər LAN-dakı xidmətə çatır, cavab tuneldən qayıdır və eyni cüt tunel yenidən başladıldıqdan və delegasiya yeniləndikdən sonra da işləyir. Son hissə uğursuz olursa, dizayn həftəyə davam etməyəcək vəziyyətdən asılıdır.