Delegiranje predpone IPv6 pre VPN med lokacijami: kontrolni seznam

Dvigniti tunel je lažja polovica. Videl sem povezavo med lokacijama, ki je dneve ostala vzpostavljena, medtem ko je vsak gostitelj v oddaljenem LAN prejemal le tišino, ker je bila delegirana predpona za tem prehodom nastavljena na vmesniku, a ni bila nikoli usmerjena v tunel. Naslovi tunela so ves čas odgovarjali na ping, in prav zato nihče ni pogledal predpone. Tu je vrstni red, ki ga preverjam, ko mora delegirana predpona IPv6 prečkati VPN lokacije: zemljevid predpon, izbirniki prometa, posredovanje in požarni zid, nato povratna pot.

Najprej napiši zemljevid predpon, šele nato se dotakni tunela

Delegiranje predpone da blok tistemu usmerjevalniku, ki ga je zahteval. Ne namesti poti na partnerju, ne razširi bloka on-link in ne pove oddaljenemu prehodu, kaj je za usmerjevalnikom, ki zahteva. Te tri stvari morate nastaviti sami, in spadajo v načrt naslovov, preden se spremeni katera koli konfiguracijska datoteka.

Za vsako lokacijo zapišite delegirano predpono, /64, ki se dejansko uporablja v LAN, naslove tunela in lastnika vsake poti. Ponudnik delegira 2001:db8:a1::/56 lokaciji A, ki v svojem LAN streže 2001:db8:a1:10::/64; lokacija B obdrži 2001:db8:b2::/64. Če lokacija A streže samo tisto /64, morata oba konca navesti 2001:db8:a1:10::/64 namesto celotne /56.

Skoraj vedno se pojavita dve napaki. Ena je obravnavati oddaljeno predpono kot on-link, jo mostiti ali postaviti na vmesnik tunela, tako da prehod odgovarja na sosedske zahteve za gostitelje, ki jih ne doseže. Druga je oglaševati celotno /56, ko je nastavljena samo ena /64: tabela poti trdi, da je blok dosegljiv, in večina naslovov pade v črno luknjo.

Uskladi izbirnike prometa obeh koncev s potmi

IKEv2 in WireGuard oba zavračata neustrezni promet, dovolj tiho, da je tunel videti še vedno zdrav.

V strongSwan so izbirniki izrecni. Na lokaciji 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 lokacije B zrcali obe podomrežji. Ko se ne ujemata, odzivnik zavrne CHILD_SA s TS_UNACCEPTABLE, zato child SA nikoli ne vstane, čeprav je IKE_SA vstal. Na obeh straneh mora nastavljeno podomrežje ustrezati tistemu, kar lokalno jedro usmerja proti tunelu.

WireGuard nosi iste informacije v AllowedIPs, z enim zasukom: AllowedIPs je filter vira pri sprejemanju in pot pri pošiljanju. Če vnos peer lokacije B za lokacijo A izpušča 2001:db8:a1:10::/64, paketi z lokacije A prispejo ob veljavnem handshake in so zavrnjeni kot nedovoljeni. Tako nastane znani vzorec handshake, ki se nenehno obnavlja, medtem ko noben odgovor nikoli ne odide. Primerjajte oba konca z wg show wg0 allowed-ips. Seznam znova preverite vsakič, ko se delegiranje spremeni; zastarela /64 ohranja sejo živo in novi predponi onemogoča dosegljivost.

Najprej izključi posredovanje, požarni zid in MTU

Preden preberete še eno vrstico dnevnika, potrdite, da prehodi sploh posredujejo. sysctl net.ipv6.conf.all.forwarding mora vrniti 1 na obeh, uporabljeno tudi na vmesnikih tunela in LAN. Priložena je past: ko je posredovanje vklopljeno, vmesnik z accept_ra=1 preneha sprejemati najave usmerjevalnika od ponudnika, zato lahko stroj izgubi nadrejeno privzeto pot, čeprav v tunelu usmerja brezhibno. Nastavite accept_ra=2 tam, kjer je najava ponudnika še vedno potrebna.

Nato morajo pravila požarnega zidu dovoliti predpono v obe smeri, ICMPv6 pa mora preživeti: odkrivanje sosedov, packet-too-big in destination-unreachable niso izbirni. Če jih zavržete, se odkrivanje MTU poti pokvari in dobite povezave, ki se odprejo in nato obstanejo pri prvem velikem odgovoru. Najmanjši par pravil je videti takole:

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 tem. Tunel zmanjša uporabno MTU pod 1500, IPv6 pa zahteva, da vsaka povezava prenese vsaj 1280. Majhni pingi gredo skozi, seja SSH se ustavi pri velikem izbruhu in /proc/net/snmp6 prikazuje sporočila packet-too-big, ki se nikoli ne vrnejo. Nastavite MTU tunela izrecno ali omejite TCP MSS v tabeli mangle in pustite ICMPv6, ki sporoča manjši MTU, da se vrne.

Preizkusi povratno pot, ne naslova tunela

Napaka, ki vzame največ časa, je enosmerno usmerjanje. Vsak prehod usmerja oddaljeno predpono v tunel, toda gostitelji odgovarjajo prek svojega privzetega prehoda, ker tam živi njihova /64. Pripeljati paket do cilja je polovica poti.

Dva ukaza rešita večino. Na lokaciji A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 pokaže, kateri vmesnik bi uporabil odgovor iz tega vira; izvedite zrcalni pregled na lokaciji B. Nato ustvarite promet z gostitelja, ne s prehoda, in primerjajte števce na obeh koncih.

Če se sosedska zahteva za oddaljeno predpono pojavi na tunelu, je ta predpona on-link nekje, kjer ne bi smela biti; popravite to, preden prilagodite poti. Proxy NDP pokriva primere, ko je mostenje res potrebno, ni nadomestilo za pot.

Načrtuj spremembo predpone pod sabo

Delegiranje predpone je najem med usmerjevalnikom, ki delegira, in tistim, ki zahteva, in obnova lahko vrne drug blok: drugo /56 po selitvi ponudnika ali krajši najem, kot je tunel vzpostavljen. Vsako mesto, ki imenuje staro predpono, postane zastarelo naenkrat: poti, izbirniki, AllowedIPs, pravila požarnega zidu, zapisi DNS in vsako spremljanje, ki vgrajuje dobesedne naslove. Tok sporočil je v RFC 8415.

Kjer pričakujete, da se bo predpona premaknila, ohranite notranji načrt naslovov, ki od nje ni odvisen, in prevajajte na meji. NPTv6 je brezstanje možnost in ohranja notranjo politiko berljivo, vendar je prevajanje predpone, ne čarobna plast: meje /64 se morajo ujemati, kontrolne vsote se prilagajajo, aplikacije z dobesednimi naslovi pa se še vedno lomijo. Če ohranite naslove ponudnika od konca do konca, zapišite vedenje najema in postopek sprememb v načrt naslovov.

Končajte s preizkusom, ki preživi čas: dovoljeni gostitelj v vsakem LAN doseže storitev v drugem LAN, odgovor se vrne skozi tunel in isti par še vedno deluje po ponovnem zagonu tunela in obnovitvi delegiranja. Če zadnji del ne uspe, je zasnova odvisna od stanja, ki ne bo preživelo tedna.