Routing polityki IPv6, gdy dwa uplinki współdzielą fe80::1

Masz dwa uplinki, a ip -6 route show wypisuje ten sam następny skok na obu: default via fe80::1 dev uplink0 i default via fe80::1 dev uplink1. To nie jest konflikt zduplikowanego adresu, a skopiowanie samego następnego skoku fe80::1 do tabeli polityki nie mówi jądru, które łącze masz na myśli. Prawdziwe pytanie jest węższe, niż sugeruje objaw: czy druga tabela potrzebuje jednego łącza, czy obu, i co utrzymuje te trasy przy życiu po ponownym rozruchu. Trzy warunki, sprawdzane po kolei, rozstrzygają większość.

Ten sam fe80::1 to dwóch różnych sąsiadów

Adresy lokalne łącza mają zasięg jednego łącza, więc fe80::1 nie jest jednym adresem wypisanym dwa razy; to dwóch sąsiadów, którzy przypadkiem dzielą sufiks. Indeks strefy to sposób, w jaki host mówi, o który mu chodzi, więc fe80::1%uplink0 i fe80::1%uplink1 to dla jądra różne cele, a ten sufiks nigdy nie wędruje do zdalnego routera. RFC 4007 opisuje stojący za tym model strefy i dlatego tabela polityki musi nieść urządzenie przy każdym lokalnym następnym skoku.

Generator konfiguracji VPN, który kopiuje numeryczny identyfikator strefy z jednego hosta do szablonu, traktuje kontekst lokalny tak, jakby był częścią adresu, a plik, który zapisuje, jest błędny na każdej maszynie o innych nazwach lub indeksach interfejsów. Tabela polityki nie scala też dwóch łącz w jedno: trasowany VPN przekazuje pakiety między sieciami, ale nie przenosi lokalnej tożsamości zdalnego sąsiada Ethernet przez tunel, więc ruch lokalny łącza zostaje na swoim łączu.

Usuń urządzenie, a trasa staje się niezapisywalna. ip -6 route add default via fe80::1 table 200 nie potrafi rozwiązać bramy, a iproute2 odrzuca to z Error: Nexthop has invalid gateway. błędem. Dodaj dev uplink0 i polecenie się udaje, bo to urządzenie przypina następny skok do jednego z tych dwóch sąsiadów. Czego urządzenie nie powie, to czy uplink0 jest właściwym łączem dla tej tabeli, a trasa skopiowana z innego hosta przynosi ze sobą nazwy interfejsów tego hosta, i stąd biorą się prawdziwe błędy.

Warunek pierwszy: jedno łącze czy dwa w tabeli

Zacznij od tego, do czego służy drugi uplink. Jeśli oba łącza niosą ten sam ruch, a jedno jest zapasowe, tabela alternatywna powinna trzymać obie bramy z różnymi metrykami: te same cele, jedna preferowana ścieżka, jeden oczywisty drugi wybór. Jeśli uplinki istnieją dlatego, że różny ruch musi wychodzić przez różnych dostawców, albo dlatego, że to tunel dzielony, w którym część ruchu omija VPN, a reszta zostaje w środku, te dwa łącza wcale nie należą do jednej tabeli. Należą do dwóch tabel, wybieranych przez regułę, a reguła wybiera tabelę, nie tunel: ruch omijający jest oznaczany przed trasowaniem i to oznaczenie wysyła go do drugiej tabeli.

W drugim przypadku reguła decyduje, kiedy konsultowana jest tabela, a trasa decyduje, dokąd pakiet trafia po jej wybraniu:

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

Żaden obiekt nie zastępuje drugiego, a tabela trzymająca tylko trasę domyślną nadal może nie rozwiązać swojej bramy. Jeśli dodanie jest odrzucane albo trasa istnieje, ale jest bezużyteczna, umieść podłączony prefiks tego interfejsu w tej samej tabeli albo oznacz skok jako onlink , gdy ten prefiks jest trasowany gdzie indziej. W bloku powyżej 2001:db8:100::/48 oznacza ten podłączony prefiks na uplink1, a nie dowolny cel. Reguła fwmark zużywa tylko oznaczenie, które musi ustawić coś innego, z reguły nftables lub iptables na ścieżce przekazywania albo z SO_MARK w gnieździe, więc skopiowany blok bez źródła oznaczenia niczego nie dopasowuje.

Warunek drugi: metryki nie wykrywają martwego dostawcy

Metryka to preferencja wśród istniejących tras, nie kontrola stanu. Gdy operator pada, jądro usuwa trasy na tym urządzeniu i przejmuje druga domyślna. Gdy kabel pozostaje włączony, a dostawca za nim umiera, w tabeli nic się nie zmienia: preferowana trasa jest zainstalowana, sąsiad jest osiągalny w warstwie 2, a pakiety wychodzą w czarną dziurę. Jeśli ta różnica ma znaczenie w twojej konfiguracji, przełączanie awaryjne musi pochodzić od czegoś, co sonduje ścieżkę i usuwa trasę, czy to demon routingu, czy mały skrypt, który usuwa i ponownie instaluje wpis.

Zweryfikuj wybór po zbudowaniu tabeli i zweryfikuj go tak, jak zobaczy to jądro. ip -6 route get 2001:db8:100::1 wypisuje trasę, która zostałaby użyta, wraz z urządzeniem i wybranym adresem źródłowym, i respektuje reguły polityki. Adres źródłowy należący do niewłaściwego uplinku to zwykły znak, że reguła dopasowała się wcześniej, niż oczekiwałeś.

Warunek trzeci: zdecyduj, kto odpowiada za trwałość

Trasa dodana przez ip -6 route add przetrwa do restartu albo do momentu, gdy coś ją wyczyści. Trasa domyślna poznana z ogłoszeń routera ma czas życia i router może ją wycofać, natomiast domyślna dodana ręcznie nigdy nie wygasa sama. Mieszanie obu w jednej tabeli to sposób, w jaki przestarzała trwała trasa zaczyna przewyższać świeżo ogłoszoną, długo po tym, jak opisany przez nią uplink przestał istnieć.

Wybierz jednego właściciela na tabelę. Jeśli menedżer sieci lub demon routingu już zarządza interfejsem, opisz tam trasę polityki i zostaw jądro w spokoju. Jeśli robisz to skryptem, uczyń go idempotentnym i napisz demontaż w tym samym czasie, bo będzie potrzebny przy pierwszej złej zmianie:

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

Na routerze, który przekazuje ruch innym hostom, przed obwinianiem tabeli sprawdź net.ipv6.conf.all.forwarding . Gdy przekazywanie jest wyłączone, pakiety adresowane do innej sieci są odrzucane, niezależnie od tego, jak poprawna jest tabela 201.

Zapisz projekt, aby następna osoba mogła go zaudytować

Inwentarz, który przechowuje tylko fe80::1 , wyrzuca pola, które mają znaczenie. Zapisuj cel, następny skok, urządzenie, tabelę i metrykę razem, a także skąd pochodzi każda trasa: ogłoszona, wygenerowana przez menedżera czy statyczna. Gdy ktoś później spyta, czy drugi uplink faktycznie niesie ruch, ten zapis odpowie bez zgadywania.

Zanim uznasz tabelę za gotową, potwierdź sąsiada przez ip -6 neigh show dev uplink0 , przeczytaj ponownie ip -6 rule show pod kątem wypadków kolejności i przetestuj ruchem zgodnym z regułą, a nie pingiem, który bierze trasę domyślną. Potem celowo wyłącz jeden uplink i obserwuj, na którą trasę jądro się cofa; odpowiedź powinna zgadzać się z zapisaną.