Делегиране на IPv6 префикс през VPN между сайтове: контролен списък
Проверки за маршрутизиране на делегиран IPv6 префикс през VPN между сайтове: карта на префиксите, селектори на трафик, препращане, MTU, обратен път и преномериране.
Вдигането на тунела е лесната половина. Виждал съм връзка между сайтове да стои вдигната с дни, докато всеки хост в далечната LAN получаваше мълчание в отговор, защото делегираният префикс зад онзи шлюз беше конфигуриран на интерфейс, но така и не беше маршрутизиран в тунела. Адресите на тунела отговаряха на ping през цялото време и точно затова никой не погледна префикса. Ето реда, който проверявам, когато делегиран IPv6 префикс трябва да прекоси VPN между сайтове: картата на префиксите, селекторите на трафик, препращането и защитната стена, после обратния път.
Запишете картата на префиксите, преди да пипате тунела
Делегирането на префикс дава блок на маршрутизатора, който го е поискал. То не инсталира маршрут на партньора, не разширява този блок върху връзката и не казва на далечния шлюз какво живее зад заявяващия маршрутизатор. Тези три неща са ваша работа и им е мястото в план за адресиране, преди да се промени който и да е конфигурационен файл.
За всеки сайт запишете делегирания префикс, /64, който реално се използва в LAN, адресите на тунела и собственика на всеки маршрут. Доставчикът делегира 2001:db8:a1::/56 на сайт A, който обслужва 2001:db8:a1:10::/64 в своята LAN; сайт B запазва 2001:db8:b2::/64. Ако сайт A обслужва само тази една /64, двата края трябва да сочат 2001:db8:a1:10::/64, а не целия /56.
Две грешки се появяват почти всеки път. Едната е да се третира далечният префикс като на връзката — да се мостова или да се сложи на интерфейса на тунела, така че шлюзът да отговаря на съседски запитвания за хостове, които не може да достигне. Другата е да се анонсира целият /56, когато е конфигурирана само една /64: таблицата с маршрути твърди, че блокът е достъпен, а повечето адреси пропадат в черна дупка.
Съгласувайте селекторите на трафик на двата края с маршрутите
IKEv2 и WireGuard и двата отказват несъответстващ трафик, достатъчно тихо, че тунелът да изглежда здрав.
В strongSwan селекторите са явни. На сайт 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=startconn на сайт B огледално повтаря двете подмрежи. Когато те се разминават, отговарящият отхвърля CHILD_SA с TS_UNACCEPTABLE, така че дъщерната SA така и не се вдига, въпреки че IKE_SA се вдигна. От двете страни конфигурираната подмрежа трябва да е равна на това, което локалното ядро маршрутизира към тунела.
WireGuard носи същата информация в AllowedIPs, с една особеност: AllowedIPs е филтър за източник при приемане и едновременно маршрут при изпращане. Ако записът за партньора на сайт B за сайт A пропуска 2001:db8:a1:10::/64, пакетите от сайт A пристигат при валидно ръкостискане и се изхвърлят като неразрешени. Това дава познатия модел на ръкостискане, което постоянно се подновява, докато никога не излиза отговор. Сравнете двата края с wg show wg0 allowed-ips. Проверявайте отново този списък при всяка промяна на делегирането; остаряла /64 държи сесията вдигната, а новият префикс — недостъпен.
Първо изключете препращането, защитната стена и MTU
Преди да прочетете още един ред от журнала, потвърдете, че шлюзовете изобщо препращат. sysctl net.ipv6.conf.all.forwarding трябва да върне 1 на двата, приложено и към интерфейсите на тунела и LAN. Един капан идва в комплект: щом препращането е включено, интерфейс с accept_ra=1 спира да приема обявления на маршрутизатор от доставчика, така че машината може да загуби маршрута си по подразбиране нагоре, докато маршрутизира безупречно вътре в тунела. Задайте accept_ra=2 там, където RA от доставчика все още е нужен.
След това правилата на защитната стена трябва да разрешават префикса в двете посоки, а ICMPv6 трябва да оцелее: откриването на съседи, пакет-твърде-голям и недостижима дестинация не са по избор. Изхвърлете ги и откриването на MTU по пътя се чупи, давайки ви връзки, които се отварят и после заклещват при първия голям отговор. Минимална двойка правила изглежда така:
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 } acceptMTU стои зад това. Тунелът свива използваемото MTU под 1500, а IPv6 изисква всяка връзка да носи поне 1280. Малките ping-ове минават, SSH сесия замръзва при голям сплеск, а /proc/net/snmp6 показва съобщения пакет-твърде-голям, които никога не се връщат. Задайте MTU на тунела явно или ограничете TCP MSS в таблицата mangle и оставете ICMPv6, който съобщава по-малкото MTU, да се върне.
Тествайте обратния път, не адреса на тунела
Отказът, който коства най-много време, е еднопосочното маршрутизиране. Всеки шлюз маршрутизира далечния префикс в тунела, но хостовете отговарят през собствения си шлюз по подразбиране, защото там живее тяхната /64. Да доставиш пакет до дестинацията е половината път.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
Две команди решават повечето от това. На сайт A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 показва кой интерфейс би използвал отговор от този източник; направете огледалната проверка на сайт B. После генерирайте трафик от хост, а не от шлюза, и сравнете броячите от двата края.
Ако съседско запитване за далечния префикс се появи в тунела, този префикс е на връзката някъде, където не би трябвало да бъде; оправете това, преди да коригирате маршрути. Proxy NDP покрива случаите, в които мостът наистина е нужен, а не е заместител на маршрут.
Планирайте префиксът да се смени под вас
Делегирането на префикс е наем между делегиращия и заявяващия маршрутизатор и подновяването може да върне различен блок: различен /56 след миграция на доставчика или по-кратък наем от времето, в което тунелът е вдигнат. Всяко място, което назовава стария префикс, остарява наведнъж: маршрути, селектори, AllowedIPs, правила на защитната стена, DNS записи и всеки мониторинг, който твърдо кодира буквални адреси. Потокът от съобщения е в RFC 8415.
Където се очаква префиксът да се мести, дръжте вътрешен план за адресиране, който не зависи от него, и превеждайте на границата. NPTv6 е опцията без състояние и запазва вътрешната политика четима, но това е транслация на префикс, не магически слой: границите на /64 трябва да съвпадат, контролните суми се коригират, а приложенията, които вграждат буквални адреси, пак се чупят. Ако пазите адресите на доставчика от край до край, запишете поведението на наема и процедура за промяна в плана за адресиране.
Завършете с тест, който издържа на времето: разрешен хост във всяка LAN достига услуга в другата LAN, отговорът се връща през тунела и същата двойка още работи след рестарт на тунела и подновяване на делегирането. Ако последната част се провали, дизайнът зависи от състояние, което няма да издържи седмица.