İki uplink fe80::1 ünvanını paylaşdıqda IPv6 siyasət marşrutlaşdırması

İki uplinkiniz var və ip -6 route show hər ikisində eyni növbəti hoppu göstərir: default via fe80::1 dev uplink0 və default via fe80::1 dev uplink1. Bu, təkrarlanan ünvan konflikti deyil və çılpaq növbəti hoppu, yəni fe80::1 ünvanını siyasət cədvəlinə köçürmək nüvəyə hansı kanalı nəzərdə tutduğunuzu demir. Əsl sual simptomun təklif etdiyindən daha dardır: ikinci cədvələ bir kanal lazımdır, yoxsa hər ikisi, və yenidən başladıqdan sonra bu marşrutları nə həyatda saxlayır. Sıra ilə yoxlanılan üç şərt bunun çoxunu həll edir.

Eyni fe80::1 iki fərqli qonşudur

Link-local ünvanlar tək bir kanalla məhdudlaşır, ona görə fe80::1 iki dəfə çap olunmuş bir ünvan deyil; sadəcə eyni sonluğu paylaşan iki qonşudur. Zona indeksi hostun hansını nəzərdə tutduğunu bildirmə üsuludur, ona görə fe80::1%uplink0 və fe80::1%uplink1 nüvə üçün fərqli təyinat nöqtələridir və bu sonluq heç vaxt uzaq marşrutlaşdırıcıya getmir. RFC 4007 bunun arxasındakı zona modelini təsvir edir və buna görə siyasət cədvəli hər link-local növbəti hoppla birlikdə cihaz da daşımalıdır.

Bir hostdan rəqəmsal zona ID-sini şablona köçürən VPN konfiqurasiya generatoru yerli konteksti ünvanın bir hissəsi kimi qəbul edir və yazdığı fayl interfeys adları və ya indeksləri fərqli olan hər maşında səhvdir. Siyasət cədvəli də iki kanalı birinə birləşdirmir: marşrutlaşdırılmış VPN paketləri şəbəkələr arasında ötürür, lakin uzaq Ethernet qonşusunun link-local kimliyini tuneldən keçirmir, ona görə link-local trafik öz kanalında qalır.

Cihazı çıxarın və marşrut yazıla bilməz hala gəlir. ip -6 route add default via fe80::1 table 200 şlüzü həll edə bilmir və iproute2 onu Error: Nexthop has invalid gateway. ilə rədd edərək dayanır; dev uplink0 əlavə edin və əmr uğurla işləyir, çünki növbəti hoppu həmin iki qonşudan birinə bağlayan cihazdır. Cihazın sizə deyə bilmədiyi şey uplink0-in bu cədvəl üçün doğru kanal olub-olmadığıdır və başqa hostdan köçürülmüş marşrut həmin hostun interfeys adlarını da gətirir; əsl səhvlər buradan qaynaqlanır.

Birinci şərt: cədvəldə bir kanal, yoxsa iki

İkinci uplinkin nə üçün olduğu ilə başlayın. Əgər hər iki kanal eyni trafiki daşıyırsa və biri ehtiyatdırsa, alternativ cədvəl hər iki şlüzü fərqli metrikalarla saxlamalıdır: eyni təyinatlar, bir üstün yol, bir aydın ikinci seçim. Əgər uplinklər ona görə varsa ki, fərqli trafik fərqli provayderlərdən çıxmalıdır, ya da bu, bəzi trafikin VPN-i keçdiyi, qalanının isə içəridə qaldığı parçalanmış tuneldirsə, iki kanal ümumiyyətlə bir cədvələ aid deyil. Onlar iki cədvələ aiddir və qayda seçir, qayda tuneli deyil, cədvəli seçir: keçən trafik marşrutlaşdırmadan əvvəl işarələnir və ikinci cədvələ onu işarə göndərir.

Bu ikinci halda qayda cədvəlin nə vaxt soruşulacağına, marşrut isə paketin sonra hara getdiyinə qərar verir:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Heç bir obyekt digərini əvəz etmir və yalnız default saxlayan cədvəl belə şlüzünü həll edə bilməyə bilər. Əgər əlavə rədd edilərsə və ya marşrut mövcuddur, lakin istifadəyə yararsızdırsa, həmin interfeys üçün qoşulmuş prefiksi eyni cədvələ qoyun və ya prefiks başqa yerdə marşrutlaşdırıldıqda hoppu onlink kimi işarələyin. Yuxarıdakı blokda 2001:db8:100::/48 uplink1-də həmin qoşulmuş prefiksi təmsil edir, ixtiyari təyinatı deyil. fwmark qaydası yalnız başqa bir şeyin qoymalı olduğu işarəni istehlak edir: ötürmə yolundakı nftables və ya iptables qaydasından və ya soketdəki SO_MARK vasitəsilə, ona görə işarə mənbəyi olmadan köçürülmüş blok heç nəyə uyğun gəlmir.

İkinci şərt: metrikalar ölü provayderi aşkar etmir

Metrika mövcud marşrutlar arasında üstünlükdür, sağlamlıq yoxlaması deyil. Daşıyıcı düşəndə nüvə həmin cihazdakı marşrutları silir və ikinci default yerini tutur. Kabel yerində qalıb arxasındakı provayder öləndə cədvəldə heç nə dəyişmir: üstün marşrut quraşdırılıb, qonşu 2-ci layda əlçatandır və paketlər qara dəliyə çıxır. Əgər bu fərq sizin quruluşunuz üçün vacibdirsə, failover yolu yoxlayan və marşrutu silən bir şeydən gəlməlidir: marşrutlaşdırma demonu və ya girişi silib yenidən quraşdıran kiçik skript.

Cədvəl qurulduqdan sonra seçimi yoxlayın və nüvənin görəcəyi şəkildə yoxlayın. ip -6 route get 2001:db8:100::1 istifadə olunacaq marşrutu, o cümlədən cihazı və seçilmiş mənbə ünvanını çap edir və siyasət qaydalarına riayət edir. Yanlış uplinkə aid mənbə ünvanı, qaydanın gözlədiyinizdən əvvəl uyğunlaşdığının adi əlamətidir.

Üçüncü şərt: davamlılığın sahibini müəyyən edin

ip -6 route add ilə əlavə edilmiş marşrut yenidən başladılana və ya nə isə onu təmizləyənə qədər qalır. Router reklamlarından öyrənilmiş default ömür daşıyır və router tərəfindən geri çəkilə bilər, əl ilə əlavə edilmiş default isə öz-özünə heç vaxt bitmir. İkisini bir cədvəldə qarışdırmaq, köhnəlmiş daimi marşrutun təzə reklam edilmiş marşrutu üstələməsinin yoludur, həmin uplink artıq mövcud olmadıqdan çox sonra.

Hər cədvəl üçün bir sahib seçin. Əgər şəbəkə meneceri və ya marşrutlaşdırma demonu interfeysi artıq idarə edirsə, siyasət marşrutunu orada təsvir edin və nüvəyə toxunmayın. Əgər skriptlə edirsinizsə, skripti idempotent edin və sökməni də eyni vaxtda yazın, çünki ilk pis dəyişiklik zamanı ona ehtiyacınız olacaq:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Digər hostlar üçün ötürmə edən routerdə cədvəli günahlandırmadan əvvəl net.ipv6.conf.all.forwarding yoxlayın. Ötürmə söndürüldükdə başqa şəbəkəyə ünvanlanmış paketlər, 201 cədvəli nə qədər düzgün olsa da, atılır.

Dizaynı qeyd edin ki, növbəti şəxs onu audit edə bilsin

Yalnız fe80::1 saxlayan inventar vacib sahələri atır. Təyinatı, növbəti hoppu, cihazı, cədvəli və metrikanı birlikdə qeyd edin, üstəlik hər marşrutun haradan gəldiyini: reklam edilib, menecer tərəfindən yaradılıb, yoxsa statikdir. Sonradan kimsə ikinci uplinkin həqiqətən trafik daşıyıb-daşımadığını soruşanda bu qeyd sualı təxmin etmədən cavablandırır.

Cədvəli bitmiş adlandırmadan əvvəl qonşunu ip -6 neigh show dev uplink0 ilə təsdiqləyin, sıralama qəzaları üçün ip -6 rule show çıxışını yenidən oxuyun və default marşrutu götürən ping əvəzinə qaydaya uyğun trafiklə sınaqdan keçirin. Sonra bir uplinki qəsdən söndürün və nüvənin hansı marşruta qayıtdığına baxın; cavab yazdığınızla uyğun gəlməlidir.