Delegacija IPv6 prefiksa preko VPN-a od lokacije do lokacije: kontrolni popis

Podići tunel je lakša polovica. Vidio sam vezu između lokacija da ostane uspostavljena danima dok je svaki host na udaljenom LAN-u dobivao samo tišinu, jer je delegirani prefiks iza tog pristupnika bio konfiguriran na sučelju, ali nikada nije bio usmjeren u tunel. Adrese tunela odgovarale su na ping sve vrijeme, i upravo zato nitko nije pogledao prefiks. Ovo je redoslijed koji provjeravam kada delegirani IPv6 prefiks mora prijeći VPN lokacije: karta prefiksa, prometni selektori, prosljeđivanje i vatrozid, a zatim povratni put.

Napišite kartu prefiksa prije nego što dotaknete tunel

Delegacija prefiksa predaje blok usmjerivaču koji ga je zatražio. Ona ne instalira rutu na parnjaku, ne proširuje taj blok na vezu i ne govori udaljenom pristupniku što se nalazi iza usmjerivača koji je zatražio. Ta tri posla konfigurirate vi, i njihovo je mjesto u planu adresa prije nego što se promijeni ijedna konfiguracijska datoteka.

Za svaku lokaciju zabilježite delegirani prefiks, /64 koji se stvarno koristi na LAN-u, adrese tunela i vlasnika svake rute. Davatelj delegira 2001:db8:a1::/56 lokaciji A, koja poslužuje 2001:db8:a1:10::/64 na svom LAN-u; lokacija B zadržava 2001:db8:b2::/64. Ako lokacija A poslužuje samo taj jedan /64, oba kraja trebaju navesti 2001:db8:a1:10::/64 umjesto cijelog /56.

Dvije se pogreške pojavljuju gotovo svaki put. Jedna je tretirati udaljeni prefiks kao onaj na vezi, premostiti ga ili staviti na sučelje tunela kako bi pristupnik odgovarao na susjedski upit za hostove do kojih ne može doći. Druga je oglašavati cijeli /56 kada je konfiguriran samo jedan /64: tablica ruta tvrdi da je blok dostupan, a većina adresa pada u crnu rupu.

Uskladite prometne selektore obaju krajeva s rutama

IKEv2 i WireGuard oba odbijaju neusklađeni promet, dovoljno tiho da tunel i dalje izgleda zdravo.

U strongSwanu su selektori eksplicitni. 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 dvije podmreže. Kada se ne slažu, odgovarač odbija CHILD_SA s TS_UNACCEPTABLE, pa se podređeni SA nikada ne podiže iako se IKE_SA podigao. Na obje strane konfigurirana podmreža mora biti jednaka onome što lokalna jezgra usmjerava prema tunelu.

WireGuard nosi istu informaciju u AllowedIPs, s jednim obratom: AllowedIPs je filtar izvora pri primanju i ujedno ruta pri slanju. Ako zapis parnjaka lokacije B za lokaciju A izostavi 2001:db8:a1:10::/64, paketi s lokacije A dolaze na valjanom rukovanju i odbacuju se kao nedopušteni. To stvara poznati uzorak rukovanja koje se stalno obnavlja dok nikakav odgovor nikada ne izlazi. Usporedite oba kraja s wg show wg0 allowed-ips. Provjerite taj popis iznova kad god se delegacija promijeni; zastarjeli /64 drži sesiju podignutom, a novi prefiks nedostupnim.

Najprije isključite prosljeđivanje, vatrozid i MTU

Prije nego što pročitate još jednu liniju zapisa, potvrdite da pristupnici uopće prosljeđuju. sysctl net.ipv6.conf.all.forwarding mora vratiti 1 na obama, primijenjeno i na sučelja tunela i LAN-a. Uz to dolazi jedna zamka: kad je prosljeđivanje uključeno, sučelje s accept_ra=1 prestaje prihvaćati oglase usmjerivača od davatelja, pa stroj može izgubiti uzlaznu zadanu rutu dok besprijekorno usmjerava unutar tunela. Postavite accept_ra=2 gdje je RA davatelja još potreban.

Zatim pravila vatrozida moraju dopustiti prefiks u oba smjera, a ICMPv6 mora preživjeti: otkrivanje susjeda, paket-prevelik i odredište-nedostupno nisu opcionalni. Odbacite ih i otkrivanje MTU-a puta se kvari, pa dobivate veze koje se otvore i zatim zapnu na prvom velikom odgovoru. Minimalni par pravila izgleda ovako:

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 stoji iza toga. Tunel smanjuje upotrebljivi MTU ispod 1500, a IPv6 zahtijeva da svaka veza nosi najmanje 1280. Mali pingovi prolaze, SSH sesija se sledi na velikom prasnu, a /proc/net/snmp6 prikazuje poruke paket-prevelik koje se nikada ne vraćaju. Postavite MTU tunela izričito ili ograničite TCP MSS u tablici mangle i pustite ICMPv6 koji izvješćuje o manjem MTU-u da se vrati.

Testirajte povratni put, ne adresu tunela

Kvar koji troši najviše vremena jest jednosmjerno usmjeravanje. Svaki pristupnik usmjerava udaljeni prefiks u tunel, ali hostovi odgovaraju kroz svoj zadani pristupnik jer tu živi njihov /64. Dovesti paket do odredišta samo je pola puta.

Dvije naredbe rješavaju većinu toga. Na lokaciji A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 pokazuje koje bi sučelje upotrijebio odgovor iz tog izvora; provedite zrcalnu provjeru na lokaciji B. Zatim generirajte promet s hosta, a ne s pristupnika, i usporedite brojače na oba kraja.

Ako se susjedski upit za udaljeni prefiks pojavi na tunelu, taj je prefiks na vezi negdje gdje ne bi smio biti; popravite to prije prilagodbe ruta. Proxy NDP pokriva slučajeve u kojima je premošćivanje doista potrebno, a nije zamjena za rutu.

Planirajte da se prefiks promijeni pod vama

Delegacija prefiksa je najam između usmjerivača koji delegira i onoga koji traži, a obnova može vratiti drugačiji blok: drugačiji /56 nakon migracije davatelja ili kraći najam od vremena koliko je tunel podignut. Svako mjesto koje imenuje stari prefiks zastarije odjednom: rute, selektori, AllowedIPs, pravila vatrozida, DNS zapisi i svako nadziranje koje tvrdo kodira doslovne adrese. Tijek poruka nalazi se u RFC 8415.

Gdje se očekuje da se prefiks pomakne, držite unutarnji plan adresa koji o njemu ne ovisi i prevodite na granici. NPTv6 je opcija bez stanja i održava unutarnju politiku čitljivom, ali to je prijevod prefiksa, a ne čarobni sloj: granice /64 moraju se poravnati, kontrolne sume se prilagođavaju, a aplikacije koje ugrađuju doslovne adrese i dalje se lome. Ako držite adrese davatelja od početka do kraja, zabilježite ponašanje najma i postupak promjene u plan adresa.

Završite testom koji preživljava vrijeme: dopušteni host na svakom LAN-u doseže uslugu na drugom LAN-u, odgovor se vraća kroz tunel, i isti par još radi nakon ponovnog pokretanja tunela i obnove delegacije. Ako zadnji dio zakaže, dizajn ovisi o stanju koje neće preživjeti tjedan.