Delegacja prefiksu IPv6 przez VPN między lokacjami: lista kontrolna

Podniesienie tunelu to łatwiejsza połowa. Widziałem łącze między lokacjami utrzymane przez dni, podczas gdy każdy host w zdalnej sieci LAN dostawał tylko ciszę, bo delegowany prefiks za tą bramą był skonfigurowany na interfejsie, ale nigdy nie był routowany do tunelu. Adresy tunelu odpowiadały na pingi przez cały czas i właśnie dlatego nikt nie patrzył na prefiks. Oto kolejność, którą sprawdzam, gdy delegowany prefiks IPv6 ma przejść przez VPN lokacji: mapa prefiksów, selektory ruchu, przekazywanie i firewall, a potem ścieżka powrotna.

Napisz mapę prefiksów, zanim dotkniesz tunelu

Delegacja prefiksu daje blok routerowi, który o niego poprosił. Nie instaluje trasy na peera, nie rozszerza tego bloku on-link i nie mówi zdalnej bramie, co znajduje się za routerem żądającym. Te trzy rzeczy musisz skonfigurować sam, a należą one do planu adresacji, zanim zmieni się jakikolwiek plik konfiguracyjny.

Dla każdej lokacji zapisz delegowany prefiks, /64 faktycznie używany w sieci LAN, adresy tunelu i właściciela każdej trasy. Dostawca deleguje 2001:db8:a1::/56 do lokacji A, która obsługuje 2001:db8:a1:10::/64 w swojej sieci LAN; lokacja B zachowuje 2001:db8:b2::/64. Jeśli lokacja A obsługuje tylko ten jeden /64, oba końce powinny wskazać 2001:db8:a1:10::/64, a nie cały /56.

Dwa błędy pojawiają się prawie zawsze. Pierwszy to traktowanie zdalnego prefiksu jako on-link, mostkowanie go lub umieszczanie na interfejsie tunelu, przez co brama odpowiada na zapytania sąsiedztwa dla hostów, do których nie dociera. Drugi to ogłaszanie całego /56, gdy skonfigurowany jest tylko jeden /64: tabela routingu twierdzi, że blok jest osiągalny, a większość adresów wpada w czarną dziurę.

Dopasuj selektory ruchu obu końców do tras

IKEv2 i WireGuard oba odrzucają niedopasowany ruch, wystarczająco cicho, by tunel wciąż wyglądał zdrowo.

W strongSwan selektory są jawne. W lokacji A:

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

conn lokacji B odzwierciedla obie podsieci. Gdy się nie zgadzają, responder odrzuca CHILD_SA z TS_UNACCEPTABLE, więc child SA nigdy nie wstaje, choć IKE_SA wstał. Po obu stronach skonfigurowana podsieć musi być równa temu, co lokalne jądro routuje w stronę tunelu.

WireGuard przenosi te same informacje w AllowedIPs, z jednym zwrotem: AllowedIPs to filtr źródła przy odbiorze i trasa przy wysyłaniu. Jeśli wpis peera lokacji B dla lokacji A pomija 2001:db8:a1:10::/64, pakiety z lokacji A przychodzą na ważnym handshake i są odrzucane jako niedozwolone. Daje to znany wzorzec handshake, który ciągle się odnawia, podczas gdy odpowiedź nigdy nie wychodzi. Porównaj oba końce za pomocą wg show wg0 allowed-ips. Sprawdzaj tę listę za każdym razem, gdy delegacja się zmienia; nieaktualny /64 utrzymuje sesję i czyni nowy prefiks nieosiągalnym.

Najpierw wyklucz przekazywanie, firewall i MTU

Zanim przeczytasz kolejny wiersz logu, potwierdź, że bramy w ogóle przekazują. sysctl net.ipv6.conf.all.forwarding musi zwrócić 1 na obu, zastosowane także na interfejsach tunelu i LAN. Jest z tym jedna pułapka: po włączeniu przekazywania interfejs z accept_ra=1 przestaje przyjmować ogłoszenia routera od dostawcy, więc maszyna może stracić górną trasę domyślną, mimo że w tunelu routuje bezbłędnie. Ustaw accept_ra=2 tam, gdzie ogłoszenie dostawcy jest nadal potrzebne.

Reguły firewalla muszą potem przepuszczać prefiks w obu kierunkach, a ICMPv6 musi przetrwać: odkrywanie sąsiadów, packet-too-big i destination-unreachable nie są opcjonalne. Odrzucenie ich psuje odkrywanie MTU ścieżki i daje połączenia, które się otwierają, a potem zatrzymują na pierwszej dużej odpowiedzi. Minimalna para reguł wygląda tak:

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 stoi za tym. Tunel zmniejsza użyteczne MTU poniżej 1500, a IPv6 wymaga, by każde łącze przenosiło co najmniej 1280. Małe pingi przechodzą, sesja SSH zamiera przy dużym wybuchu, a /proc/net/snmp6 pokazuje komunikaty packet-too-big, które nigdy nie wracają. Ustaw MTU tunelu jawnie albo ogranicz MSS TCP w tabeli mangle i pozwól wrócić ICMPv6 zgłaszającemu mniejsze MTU.

Testuj ścieżkę powrotną, nie adres tunelu

Awaria, która kosztuje najwięcej czasu, to routing jednokierunkowy. Każda brama routuje zdalny prefiks do tunelu, ale hosty odpowiadają przez własną bramę domyślną, bo tam mieszka ich /64. Dowiezienie pakietu do celu to połowa drogi.

Dwie komendy załatwiają większość. W lokacji A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 pokazuje, którego interfejsu użyłaby odpowiedź z tego źródła; wykonaj lustrzane sprawdzenie w lokacji B. Potem generuj ruch z hosta, a nie z bramy, i porównaj liczniki na obu końcach.

Jeśli zapytanie sąsiedztwa dla zdalnego prefiksu pojawia się na tunelu, ten prefiks jest on-link tam, gdzie nie powinien; napraw to, zanim dostroisz trasy. Proxy NDP obejmuje przypadki, w których mostkowanie jest naprawdę konieczne, a nie zastępuje trasy.

Zaplanuj zmianę prefiksu pod sobą

Delegacja prefiksu to dzierżawa między routerem delegującym a żądającym, a odnowienie może zwrócić inny blok: inny /56 po migracji dostawcy albo krótszą dzierżawę, niż tunel jest podniesiony. Każde miejsce nazywające stary prefiks starzeje się naraz: trasy, selektory, AllowedIPs, reguły firewalla, rekordy DNS i każdy monitoring zakodowujący dosłowne adresy. Przepływ komunikatów jest w RFC 8415.

Gdzie prefiks ma się przesuwać, utrzymuj wewnętrzny plan adresacji, który od niego nie zależy, i tłumacz na granicy. NPTv6 to opcja bezstanowa i utrzymuje czytelność polityki wewnętrznej, ale to tłumaczenie prefiksu, nie magiczna warstwa: granice /64 muszą się zgadzać, sumy kontrolne są korygowane, a aplikacje osadzające dosłowne adresy nadal się psują. Jeśli zachowujesz adresy dostawcy od końca do końca, zapisz zachowanie dzierżawy i procedurę zmian w planie adresacji.

Zakończ testem, który przetrwa czas: dozwolony host w każdej sieci LAN dociera do usługi w drugiej sieci LAN, odpowiedź wraca przez tunel, a ta sama para nadal działa po restarcie tunelu i odnowieniu delegacji. Jeśli ostatnia część zawiedzie, projekt zależy od stanu, który nie przetrwa tygodnia.