Делегирање на IPv6 префикс преку VPN меѓу локации: контролна листа

Подигнувањето на тунелот е полесната половина. Сум видел врска меѓу локации која со денови останувала воспоставена, додека секој домаќин на далечната LAN добивал само тишина, затоа што делегираниот префикс зад таа порта бил конфигуриран на интерфејс, но никогаш не бил рутиран во тунелот. Адресите на тунелот одговараа на пинг цело време, и токму затоа никој не го гледал префиксот. Еве го редоследот што го проверувам кога делегиран IPv6 префикс треба да помине низ локациски VPN: картата на префикси, селекторите на сообраќај, проследувањето и огнениот ѕид, потоа повратниот пат.

Напиши ја картата на префикси пред да го допреш тунелот

Делегирањето на префикс му дава блок на рутерот што го побарал. Тоа не инсталира рута кај партнерот, не го проширува тој блок on-link и не му кажува на далечната порта што стои зад барателот. Овие три работи треба сами да ги конфигурирате, и тие припаѓаат на планот за адреси пред да се смени која било конфигурациска датотека.

За секоја локација запишете го делегираниот префикс, /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.

Речиси секогаш се појавуваат две грешки. Едната е далечниот префикс да се третира како on-link, да се премости или да се стави на интерфејсот на тунелот, така што портата одговара на соседното барање за домаќини што не може да ги достигне. Другата е да се рекламира целиот /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=start

conn на локацијата B ги огледува двете подмрежи. Кога не се согласуваат, одговорниот го одбива CHILD_SA со TS_UNACCEPTABLE, така што child SA никогаш не се крева, иако IKE_SA се крена. Од двете страни конфигурираната подмрежа мора да биде еднаква на она што локалното јадро го рутира кон тунелот.

WireGuard ги носи истите информации во AllowedIPs, со еден пресврт: AllowedIPs е изворен филтер при примање и рута при испраќање. Ако peer записот на локацијата B за локацијата A го испушти 2001:db8:a1:10::/64, пакетите од локацијата A пристигнуваат со валиден handshake и се отфрлаат како недозволени. Така се добива познатиот образец на handshake што постојано се обновува, додека никаков одговор никогаш не излегува. Споредете ги двата краја со wg show wg0 allowed-ips. Проверете ја таа листа повторно секогаш кога делегирањето ќе се смени; застарениот /64 ја држи сесијата жива и новиот префикс го прави недостапен.

Прво исклучи ги проследувањето, огнениот ѕид и MTU

Пред да прочитате уште една линија од дневникот, потврдете дека портите воопшто проследуваат. sysctl net.ipv6.conf.all.forwarding мора да врати 1 на двете, применето и на интерфејсите на тунелот и LAN. Придружува една стапица: кога проследувањето е вклучено, интерфејсот со accept_ra=1 престанува да прима реклами од рутерот на провајдерот, па машината може да ја загуби нагорната стандардна рута, иако во тунелот рутира беспрекорно. Поставете accept_ra=2 таму каде што RA од провајдерот сѐ уште е потребен.

Потоа правилата на огнениот ѕид мора да го дозволат префиксот во двете насоки, а ICMPv6 мора да преживее: откривањето соседи, packet-too-big и destination-unreachable не се опционални. Ако ги отфрлите, откривањето на патеката 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 } accept

MTU стои зад тоа. Тунелот ја намалува употребливата MTU под 1500, а IPv6 бара секоја врска да носи најмалку 1280. Малите пинг поминуваат, SSH сесијата замрзнува на голем налет, а /proc/net/snmp6 покажува packet-too-big пораки што никогаш не се враќаат. Поставете ја MTU на тунелот експлицитно или ограничете TCP MSS во табелата mangle и дозволете ICMPv6 што известува за помала MTU да се врати.

Тестирај го повратниот пат, не адресата на тунелот

Дефектот што троши најмногу време е еднонасочно рутирање. Секоја порта го рутира далечниот префикс во тунелот, но домаќините одговараат преку својата стандардна порта затоа што таму живее нивниот /64. Да се донесе пакет до целта е половина пат.

Две команди го решаваат поголемиот дел. На локацијата A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 покажува кој интерфејс би го користел одговорот од тој извор; извршете го огледалното проверување на локацијата B. Потоа генерирајте сообраќај од домаќин, а не од портата, и споредете ги бројачите на двата краја.

Ако соседното барање за далечниот префикс се појави на тунелот, тој префикс е on-link некаде каде што не треба да биде; поправете го тоа пред да ги прилагодите рутите. Proxy NDP ги покрива случаите каде премостувањето навистина е потребно, а не е замена за рута.

Планирај го менувањето на префиксот под тебе

Делегирањето на префикс е закуп меѓу рутерот што делегира и барателот, а обновувањето може да врати друг блок: друг /56 по миграција на провајдерот или пократок закуп отколку што тунелот е кренат. Секое место што го именува стариот префикс застарува одеднаш: рути, селектори, AllowedIPs, правила на огнениот ѕид, DNS записи и секакво набљудување што вградува буквални адреси. Текот на пораки е во RFC 8415.

Каде што се очекува префиксот да се премести, одржувајте внатрешен план за адреси што не зависи од него и преведувајте на границата. NPTv6 е безсостојбена опција и ја држи внатрешната политика читлива, но тоа е превод на префикс, не магичен слој: границите /64 мора да се совпаѓаат, контролните суми се прилагодуваат, а апликациите што вградуваат буквални адреси сѐ уште се кршат. Ако ги чувате адресите на провајдерот од крај до крај, запишете го однесувањето на закупот и постапката за промена во планот за адреси.

Завршете со тест што го преживува времето: дозволен домаќин на секој LAN достигнува услуга на другиот LAN, одговорот се враќа низ тунелот, и истиот пар сѐ уште работи по рестарт на тунелот и обновување на делегирањето. Ако последниот дел не успее, дизајнот зависи од состојба што нема да ја преживее неделата.