IPv6 aurrizkiaren delegazioa gune arteko VPN baten bidez: egiaztapen-zerrenda

Tunela altxatzea errazeko erdia da. Ikusi dut gune arteko esteka egunetan zehar ezarrita mantendu dela urruneko LANeko ostalari guztiek isiltasuna jasotzen zuten bitartean, atebide haren atzeko aurrizki delegatua interfaze batean konfiguratuta zegoelako baina inoiz tunelera bideratu ez zelako. Tunelaren helbideek pinge-i erantzuten zieten denbora osoan, eta horrexegatik ez zuen inork aurrizkira begiratu. Hau da aurrizki IPv6 delegatu batek gune VPN bat zeharkatu behar duenean egiaztatzen dudan ordena: aurrizkien mapa, trafiko-hautatzaileak, birbidalketa eta suebakia, eta gero itzulera-bidea.

Idatzi aurrizkien mapa tunela ukitu aurretik

Aurrizki-delegazioak bloke bat ematen dio hura eskatu zuen bideratzaileari. Ez du ibilbiderik instalatzen parean, ez du bloke hori estekan hedatzen, eta ez dio urruneko ate-bideari esaten eskatzaile den bideratzailearen atzean zer dagoen. Hiru gauza horiek zuk konfiguratu behar dituzu, eta helbide-plan batean dute lekua konfigurazio-fitxategiren bat aldatu aurretik.

Gune bakoitzerako, idatzi aurrizki delegatua, LANean benetan erabiltzen den /64a, tunelaren helbideak eta ibilbide bakoitzaren jabea. Hornitzaileak 2001:db8:a1::/56 delegatzen dio A guneari, eta horrek 2001:db8:a1:10::/64 zerbitzatzen du bere LANean; B guneak 2001:db8:b2::/64 gordetzen du. A guneak /64 hori bakarrik zerbitzatzen badu, bi muturrek 2001:db8:a1:10::/64 izendatu beharko lukete, /56 osoa izan beharrean.

Bi akats agertzen dira ia beti. Bata urruneko aurrizkia estekakoa balitz bezala tratatzea da, zubia jarriz edo tunelaren interfazean jarriz, ate-bideak iritsi ezin dituen ostalarien bizilagun-eskaerari erantzun diezaion. Bestea /56 osoa iragartzea da, /64 bakarra konfiguratuta dagoenean: ibilbide-taulak blokea eskuragarria dela dio eta helbide gehienak zulo beltzera erortzen dira.

Bateratu bi muturren trafiko-hautatzaileak ibilbideekin

IKEv2k eta WireGuardek bat ez datorren trafikoari uko egiten diote, tunelak osasuntsu jarraituko balu bezala adina isil.

strongSwan-en hautatzaileak esplizituak dira. A gunean:

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

B gunearen conn-ak bi azpisareak islatzen ditu. Bat ez datozenean, erantzuleak CHILD_SA baztertzen du TS_UNACCEPTABLE-rekin, beraz SA alaba ez da inoiz igotzen IKE_SA igo bazen ere. Bi aldeetan konfiguratutako azpisareak tokiko nukleoak tunelera bideratzen duenaren berdina izan behar du.

WireGuardek informazio bera darama AllowedIPs-en, bihurritu batekin: AllowedIPs jasotzean iturburu-iragazkia da eta bidaltzean ibilbidea. B gunearen A gunerako pare-erregistroak 2001:db8:a1:10::/64 baztertzen badu, A guneko paketeak esku-emate baliodunarekin iristen dira eta onartu gabeko gisa botatzen dira. Horrek ezaguna den eredua sortzen du: esku-ematea etengabe berritzen da baina inoiz ez da erantzunik ateratzen. Konparatu bi muturrak wg show wg0 allowed-ips erabiliz. Egiaztatu zerrenda hori berriro delegazioa aldatzen den bakoitzean; /64 zaharkitu batek saioa martxan mantentzen du eta aurrizki berria eskuraezin.

Baztertu lehenengo birbidalketa, suebakia eta MTUa

Beste log-erren bat irakurri aurretik, egiaztatu ate-bideek batere birbidaltzen dutela. sysctl net.ipv6.conf.all.forwarding aginduak 1 itzuli behar du bietan, tunelaren eta LANaren interfazeetan ere aplikatuta. Tranpa bat dator harekin: birbidalketa piztuta dagoenean, accept_ra=1 duen interfazeak hornitzailearen bideratzaile-iragarkiak onartzeari uzten dio, beraz makinak goiko ibilbide lehenetsia gal dezake tunelaren barruan ezin hobeto bideratzen duen bitartean. Ezarri accept_ra=2 hornitzailearen RA oraindik behar den lekuan.

Gero suebakiko arauek aurrizkia bi noranzkoetan baimendu behar dute, eta ICMPv6k bizirik iraun behar du: bizilagunen aurkikuntza, pakete-handiegia eta helmuga-eskuragaitza ez dira aukerakoak. Baztertu itzazu eta bidearen MTU aurkikuntza apurtzen da, ireki eta lehen erantzun handian trabatzen diren konexioak emanez. Gutxieneko arau-pare batek itxura hau du:

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

MTUa horren atzean dago. Tunelak erabil daitekeen MTUa 1500etik behera txikitzen du, eta IPv6k eskatzen du esteka bakoitzak gutxienez 1280 eramatea. Ping txikiak pasatzen dira, SSH saio bat izoztu egiten da bolada handi batean, eta /proc/net/snmp6 fitxategiak inoiz itzultzen ez diren pakete-handiegia mezuak erakusten ditu. Ezarri tunelaren MTUa esplizituki, edo murriztu TCP MSS mangle taulan, eta utzi MTU txikiagoa jakinarazten duen ICMPv6a itzultzen.

Probatu itzulera-bidea, ez tunelaren helbidea

Denbora gehien kostatzen duen hutsegitea noranzko bakarreko bideratzea da. Ate-bide bakoitzak urruneko aurrizkia tunelera bideratzen du, baina ostalariek beren ate-bide lehenetsiaren bidez erantzuten dute, han bizi baita beren /64a. Paketea helmugara iristea bide erdia besterik ez da.

Bi komandok konpontzen dute gehiena. A gunean ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 aginduak erakusten du iturburu horretatik datorren erantzun batek zein interfaze erabiliko lukeen; egin ispilu-egiaztapena B gunean. Gero sortu trafikoa ostalari batetik, ate-bidetik beharrean, eta konparatu kontagailuak bi muturretan.

Urruneko aurrizkiaren bizilagun-eskaera tunelean agertzen bada, aurrizki hori estekan dago egon behar ez lukeen leku batean; konpondu hori ibilbideak doitu aurretik. Proxy NDPk zubia benetan behar den kasuak estaltzen ditu, eta ez da ibilbide baten ordezkoa.

Planifikatu aurrizkia zure oinen azpian aldatzea

Aurrizki-delegazioa delegatzen duen eta eskatzen duen bideratzailearen arteko errentamendua da, eta berritzeak beste bloke bat itzul diezazuke: beste /56 bat hornitzailearen migrazio baten ondoren, edo tunelak daraman denbora baino errentamendu laburragoa. Aurrizki zaharra izendatzen duen leku bakoitza zaharkituta geratzen da batera: ibilbideak, hautatzaileak, AllowedIPs, suebakiko arauak, DNS erregistroak eta helbide literalak gogor kodetzen dituen edozein monitorizazio. Mezu-fluxua hemen dago: RFC 8415.

Aurrizkia mugitzea espero den lekuetan, mantendu harengandik independentea den barne helbide-plan bat eta itzuli mugean. NPTv6 estatugabeko aukera da eta barne politika irakurgarri mantentzen du, baina aurrizki-itzulpena da, ez geruza magikoa: /64 mugak lerrokatu behar dira, kontrol-batuak doitzen dira, eta helbide literalak txertatzen dituzten aplikazioak oraindik apurtzen dira. Hornitzailearen helbideak hasieratik bukaerara mantentzen badituzu, idatzi errentamenduaren portaera eta aldaketa-prozedura bat helbide-planean.

Amaitu denborari eusten dion proba batekin: LAN bakoitzeko ostalari baimendu batek beste LANeko zerbitzu batera iristen da, erantzuna tuneletik itzultzen da, eta bikote berak funtzionatzen du tuneleko berrabiarazte baten eta delegazioaren berritze baten ondoren. Azken zatiak huts egiten badu, diseinua astea gaindituko ez duen egoeraren mende dago.