De tunnel omheech bringe is de maklike helte. Ik haw sjoen dat in side-oan-side-ferbining dagenlang oerein bleau wylst elke host op 'e fiere LAN stilte werom krige, omdat de delegearre prefiks efter dy gateway op in ynterface konfigurearre wie mar nea yn 'e tunnel rûte waard. De tunneladressen antwurden de hiele tiid op pings, en krekt dêrom seach nimmen nei de prefiks. Hjir is de folchoarder dy't ik kontrolearje as in delegearre IPv6-prefiks in side-VPN passearje moat: de prefiksmap, de ferkiersselekteurs, trochstjoeren en brânmuorre, en dan de weromwei.

Skriuw de prefiksmap foardat jo de tunnel oanreitsje

Prefiksdelegaasje jout in blok oan 'e router dy't it oanfrege hat. It ynstallearret gjin rûte op 'e peer, wreidet dat blok net op 'e keppeling út, en fertelt de fiere gateway net wat efter de oanfreegjende router sit. Dy trije dingen konfigurearje jo sels, en se hearre yn in adresplan foardat hokker konfiguraasjebestân dan ek feroaret.

Skriuw foar elke side de delegearre prefiks op, de /64 dy't feitlik op 'e LAN brûkt wurdt, de tunneladressen en de eigner fan elke rûte. De provider delegearret 2001:db8:a1::/56 oan side A, dy't 2001:db8:a1:10::/64 op syn LAN tsjinnet; side B hâldt 2001:db8:b2::/64. As side A allinnich dy iene /64 tsjinnet, moatte beide einen 2001:db8:a1:10::/64 neame ynstee fan 'e hiele /56.

Twa flaters komme hast elke kear foar. De iene is de fiere prefiks as op 'e keppeling behannelje, him brêgje of op 'e tunnelinterface sette sadat de gateway antwurdet op 'e buormanbefragging foar hosts dy't er net berikke kin. De oare is de hiele /56 oankundigje wylst mar ien /64 konfigurearre is: de rûtetabel beweart dat it blok berikber is en de measte adressen falle yn in swart gat.

Lês de ferkiersselekteurs fan beide einen op 'e rûtes ôf

IKEv2 en WireGuard wegerje beide net-passende ferkear, stil genôch dat de tunnel noch sûn liket.

Yn strongSwan binne de selekteurs eksplisyt. Op side 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

De conn fan side B spegelet de twa subnetten. As se net oerienkomme, wiist de responder de CHILD_SA ôf mei TS_UNACCEPTABLE, sadat de bern-SA nea omheech komt ek al kaam de IKE_SA wol. Oan beide kanten moat it konfigurearre subnet gelyk wêze oan wat de lokale kearn nei de tunnel rûtet.

WireGuard draacht deselde ynformaasje yn AllowedIPs, mei ien draai: AllowedIPs is in boarnefilter by ûntfangst en tagelyk in rûte by ferstjoeren. As de peer-ynskriuwing fan side B foar side A 2001:db8:a1:10::/64 weilitten hat, komme pakketten fan side A op in jildige hânskutel oan en wurde se as net tastien weilitten. Dat jout it bekende patroan fan in hânskutel dy't hieltyd fernijt wylst der nea in antwurd út giet. Ferlykje beide einen mei wg show wg0 allowed-ips. Kontrolearje dy list op 'e nij wannear't de delegaasje feroaret; in ferâldere /64 hâldt de sessy oerein en de nije prefiks ûnberikber.

Slút earst trochstjoeren, brânmuorre en MTU út

Foardat jo noch in logrigel lêze, befêstigje dat de gateways überhaupt trochstjoere. sysctl net.ipv6.conf.all.forwarding moat op beide 1 weromjaan, tapast op 'e tunnel- en LAN-ynterfaces ek. Ien falstrik komt derby: sadree't trochstjoeren oan is, hâldt in ynterface mei accept_ra=1 op om routeroankundigings fan 'e provider oan te nimmen, sadat it kastje syn opstream standby-rûte ferlieze kin wylst it binnen de tunnel perfekt rûtet. Set accept_ra=2 dêr't in RA fan 'e provider noch nedich is.

Dêrnei moatte de brânmuorrerogels de prefiks yn beide rjochtingen tastean, en ICMPv6 moat oerlibje: buormanûntdekking, pakket-te-grut en bestimming-ûnberikber binne net opsjoneel. Goai se fuort en paad-MTU-ûntdekking brekt, wat jo ferbiningen jout dy't iepenje en dan by it earste grutte antwurd fêstrinme. In minimaal pear regels sjocht der sa út:

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

De MTU sit dêr efter. In tunnel krimpt de brûkbere MTU ûnder 1500, en IPv6 easket dat elke keppeling teminsten 1280 draacht. Lytse pings passearje, in SSH-sessy befriest by in grutte útbarsting, en /proc/net/snmp6 lit pakket-te-grut-berjochten sjen dy't nea weromkomme. Set de tunnel-MTU eksplisyt, of klamje TCP MSS yn 'e mangle-tabel, en lit de ICMPv6 dy't de lytsere MTU rapportearret weromkomme.

Test de weromwei, net it tunneladres

De flater dy't it measte tiid kostet, is ienrjochtingsrûting. Elke gateway rûtet de fiere prefiks de tunnel yn, mar hosts antwurdzje fia har eigen standby-gateway omdat dêr har /64 wennet. In pakket by de bestimming krije is mar de helte fan 'e wei.

What you seeLikely causeFirst check
Tunnel up, every host silentremote prefix not routed into the tunnelip -6 route get on both gateways
Handshake renews, no repliessource prefix missing from selectors or AllowedIPsipsec statusall, wg show allowed-ips
Small pings pass, transfers stallMTU or ICMPv6 packet-too-big filtered/proc/net/snmp6 counters
Old prefix still worksstale /64 left in routes or selectorsdelegation lease and route table

Twa kommando's besljochtsje it measte. Op side A lit ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 sjen hokker ynterface in antwurd fan dy boarne brûke soe; doch de spegelkontrôle op side B. Generearje dan ferkear fan in host ôf ynstee fan 'e gateway en ferlykje de tellers oan beide kanten.

As buormanbefragging foar de fiere prefiks op 'e tunnel ferskynt, dan is dy prefiks op 'e keppeling earne dêr't er net wêze moat; reparearje dat foardat jo rûtes oanpasse. Proxy NDP dekt gefallen dêr't brêgjen echt nedich is, en is gjin ferfanging foar in rûte.

Plan foar de prefiks dy't ûnder jo feroaret

Prefiksdelegaasje is in hieroerienkomst tusken de delegearjende en de oanfreegjende router, en in fernijing kin in oar blok weromjaan: in oare /56 nei in providermigraasje, of in koartere hier as de tiid dat de tunnel oerein is. Eltse plak dat de âlde prefiks neamt ferâldet tagelyk: rûtes, selekteurs, AllowedIPs, brânmuorrerogels, DNS-records en hokker monitoring dan ek dy't literal adressen hurd kodearret. De berjochteflow stiet yn RFC 8415.

Dêr't ferwachte wurdt dat de prefiks beweecht, hâld in yntern adresplan oan dat net fan him ôfhinklik is en oersette oan 'e grins. NPTv6 is de steatleaze opsje en hâldt yntern belied lêsber, mar it is prefiksoersetting, gjin magyske laach: /64-grinzen moatte oerienkomme, kontrôlesommen wurde oanpast, en applikaasjes dy't literal adressen ynbêde brekke noch altyd. As jo provideradressen fan ein oant ein hâlde, skriuw dan it hiergedrach en in feroaringsproseduere yn it adresplan.

Einigje mei in test dy't de tiid oerlibbet: in tastiene host op elke LAN berikt in tsjinst op 'e oare LAN, it antwurd komt fia de tunnel werom, en itselde pear wurket noch nei in werstart fan 'e tunnel en in fernijing fan 'e delegaasje. As it lêste part mislearret, hinget it ûntwerp ôf fan steat dy't de wike net oerlibbet.

Relatearre artikelen