Delegácia prefixu IPv6 cez VPN medzi lokalitami: kontrolný zoznam

Zdvíhanie tunela je tá ľahšia polovica. Videl som spojenie medzi lokalitami zostať nadviazané celé dni, kým každý host vo vzdialenej LAN dostával len ticho, pretože delegovaný prefix za tou bránou bol nakonfigurovaný na rozhraní, ale nikdy nebol smerovaný do tunela. Adresy tunela celý čas odpovedali na pingy, a práve preto sa nikto nepozeral na prefix. Tu je poradie, ktoré kontrolujem, keď delegovaný prefix IPv6 musí prejsť cez VPN lokality: mapa prefixov, selektory prevádzky, preposielanie a firewall, a potom spätná cesta.

Najprv napíš mapu prefixov, až potom sa dotkni tunela

Delegácia prefixu odovzdáva blok tomu smerovaču, ktorý oň požiadal. Neinštaluje trasu na partnera, nerozširuje ten blok on-link a nehovorí vzdialenej bráne, čo je za žiadajúcim smerovačom. Tieto tri veci musíte nakonfigurovať sami a patria do plánu adries skôr, než sa zmení akýkoľvek konfiguračný súbor.

Pre každú lokalitu zaznamenajte delegovaný prefix, /64 skutočne používanú v LAN, adresy tunela a vlastníka každej trasy. Poskytovateľ deleguje 2001:db8:a1::/56 lokalite A, ktorá obsluhuje 2001:db8:a1:10::/64 vo svojej LAN; lokalita B si ponecháva 2001:db8:b2::/64. Ak lokalita A obsluhuje len tú jednu /64, oba konce by mali uvádzať 2001:db8:a1:10::/64 namiesto celej /56.

Takmer vždy sa objavia dve chyby. Jedna je považovať vzdialený prefix za on-link, mostíkovať ho alebo ho dať na rozhranie tunela, takže brána odpovedá na susedské požiadavky za hosty, ku ktorým sa nedostane. Druhá je ohlasovať celú /56, keď je nakonfigurovaná len jedna /64: tabuľka trás tvrdí, že blok je dostupný, a väčšina adries padá do čiernej diery.

Zlaď selektory prevádzky oboch koncov s trasami

IKEv2 aj WireGuard odmietajú nezhodnú prevádzku, dosť potichu na to, aby tunel stále vyzeral zdravý.

V strongSwan sú selektory explicitné. Na lokalite 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 lokality B zrkadlí obe podsiete. Keď sa nezhodujú, respodér odmietne CHILD_SA s TS_UNACCEPTABLE, takže child SA nikdy nevznikne, hoci IKE_SA vznikla. Na oboch stranách musí nakonfigurovaná podsieť zodpovedať tomu, čo lokálne jadro smeruje k tunelu.

WireGuard nesie rovnaké informácie v AllowedIPs, s jednou špecialitou: AllowedIPs je filter zdroja pri príjme a trasa pri odosielaní. Ak peer záznam lokality B pre lokalitu A vynechá 2001:db8:a1:10::/64, pakety z lokality A prichádzajú na platnom handshake a sú zahodené ako nepovolené. To vytvára známy vzor handshake, ktorý sa stále obnovuje, kým žiadna odpoveď nikdy neodchádza. Porovnajte oba konce pomocou wg show wg0 allowed-ips. Zoznam znova skontrolujte pri každej zmene delegácie; zastaraná /64 drží reláciu živú a nový prefix robí nedostupným.

Najprv vylúč preposielanie, firewall a MTU

Skôr než prečítate ďalší riadok logu, potvrďte, že brány vôbec preposielajú. sysctl net.ipv6.conf.all.forwarding musí vrátiť 1 na oboch, aplikované aj na rozhrania tunela a LAN. Je s tým jedna pasca: po zapnutí preposielania rozhranie s accept_ra=1 prestane prijímať inzeráty smerovača od poskytovateľa, takže stroj môže stratiť nadradenú predvolenú trasu, hoci v tuneli smeruje bezchybne. Nastavte accept_ra=2 tam, kde je inzerát poskytovateľa ešte potrebný.

Pravidlá firewallu potom musia priepustiť prefix v oboch smeroch a ICMPv6 musí prežiť: objavovanie susedov, packet-too-big a destination-unreachable nie sú voliteľné. Ak ich zahodíte, objavovanie MTU cesty sa pokazí a dostanete spojenia, ktoré sa otvoria a potom sa zaseknú na prvej veľkej odpovedi. Minimálna dvojica pravidiel vyzerá takto:

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 je za tým. Tunel zmenšuje použiteľnú MTU pod 1500 a IPv6 vyžaduje, aby každé spojenie prenášalo aspoň 1280. Malé pingy prechádzajú, relácia SSH zamrzne pri veľkom náraze a /proc/net/snmp6 ukazuje správy packet-too-big, ktoré sa nikdy nevrátia. Nastavte MTU tunela explicitne alebo obmedzte TCP MSS v tabuľke mangle a nechajte ICMPv6, ktorý hlási menšiu MTU, vrátiť sa.

Testuj spätnú cestu, nie adresu tunela

Porucha, ktorá stojí najviac času, je jednosmerné smerovanie. Každá brána smeruje vzdialený prefix do tunela, ale hosty odpovedajú cez vlastnú predvolenú bránu, pretože tam žije ich /64. Dostať paket k cieľu je polovica cesty.

Dva príkazy vyriešia väčšinu. Na lokalite A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ukáže, ktoré rozhranie by použila odpoveď z tohto zdroja; vykonajte zrkadlovú kontrolu na lokalite B. Potom generujte prevádzku z hosta, nie z brány, a porovnajte počítadlá na oboch koncoch.

Ak sa susedská požiadavka pre vzdialený prefix objaví na tuneli, ten prefix je on-link niekde, kde by nemal byť; opravte to skôr, než upravíte trasy. Proxy NDP pokrýva prípady, keď je mostenie skutočne potrebné, nie je náhradou trasy.

Naplánuj zmenu prefixu pod sebou

Delegácia prefixu je nájom medzi delegujúcim a žiadajúcim smerovačom a obnovenie môže vrátiť iný blok: inú /56 po migrácii poskytovateľa alebo kratší nájom, než ako dlho je tunel hore. Každé miesto, ktoré uvádza starý prefix, zostarne naraz: trasy, selektory, AllowedIPs, pravidlá firewallu, DNS záznamy a akékoľvek monitorovanie, ktoré zakóduje doslovné adresy. Tok správ je v RFC 8415.

Kde sa očakáva pohyb prefixu, udržiavajte vnútorný plán adries, ktorý od neho nezávisí, a prekladajte na hranici. NPTv6 je bezstavová možnosť a udržiava vnútornú politiku čitateľnou, ale je to preklad prefixu, nie magická vrstva: hranice /64 musia sedieť, kontrolné súčty sa upravujú a aplikácie s doslovnými adresami sa stále lámu. Ak zachovávate adresy poskytovateľa od konca do konca, zaznamenajte správanie nájmu a postup zmien do plánu adries.

Ukončite testom, ktorý prežije čas: povolený host v každej LAN dosiahne službu v druhej LAN, odpoveď sa vráti cez tunel a ten istý pár funguje aj po reštarte tunela a obnovení delegácie. Ak posledná časť zlyhá, návrh závisí od stavu, ktorý neprežije týždeň.