IPv6 tusken twa sites oer in besteande VPN rûte

In WAN mei allinnich IPv4 kin noch altyd innerlik IPv6 drage. Folgje selektors, kernrûtes, trochstjoeren en it weromprefiks dat antwirden stilwei weilizze.

As jo in IPv6-prefiks tafoegje oan in site-nei-site-tunnel, reizget it pakket net sa’t it diagram suggerearret. De lokale gateway nimt it hiele IPv6-pakket, fersiferet it en set in bûtenste IP-kop foar dat waans adresfamylje bepaald wurdt troch de einpuntadressen, net troch wat der binnen sit. De fiere gateway stript dy bûtenste kop en stjoert it oarspronklike pakket troch nei syn LAN, dêr’t it wer in gewoan IPv6-pakket is. Bûtenste tunnel en ynterne ferkear binne twa aparte petearen dy’t in kaai, in einpuntpear en neat oars diele.

Twa koppen, twa adresfamyljes

Yn IPsec-tunnelmodus wurdt it ynterne IPv6-pakket de lading efter in ESP-kop. De bûtenste kop dy’t dat ESP-pakket draacht, kin IPv4 of IPv6 wêze, en folget local_addrs en remote_addrs. WireGuard docht itselde mei minder seremoanje: it ynterne pakket is de lading fan in UDP-datagram nei it einpunt fan de peer. Beide litte de ynterne kop ûnoantaast, en dêrom kin de oare kant it nei dekapsulaasje rûte.

It paad tusken de sites sjocht allinnich UDP 4500 as IPsec NAT-traversal brûkt, of UDP 51820 foar in standert WireGuard-harker. Elke router ûnderweis kin allinnich IPv4 wêze en it IPv6-ferkear giet dochs oer, om’t it op dat paad nea as IPv6-pakket ferskynt. Dat jout in skjinne earste splitsing: tcpdump -ni eth0 udp port 51820 lit it fersifere paad sjen, tcpdump -ni wg0 ip6 lit it ynterne ferkear sjen. In drok bûtenste opname mei in stille ynterne betsjut dat de kernel gjin IPv6 yn de tunnel leit; dat is rûtering of belied, net keppelstatus.

De gateway fermindert ek de ynterne Hop Limit wylst er trochstjoert, sadat de einpunten as routers telle op it IPv6-paad. Bûtenste hopoantal en ynterne Hop Limit bewege ûnôfhinklik, en in pakket dat by de fiere gateway stjert, stoar yn it trochstjoeren, net yn de fersifering.

Selektors en AllowedIPs binne de tastimminglist

IKEv2 ûnderhannelet hokker ynterne prefiksen in child-SA drage mei. Op strongSwan 5.9 en letter sjocht it der sa út as jo se yn swanctl.conf útskriuwe:

children {
  net6 {
    local_ts  = 2001:db8:aa::/48
    remote_ts = 2001:db8:bb::/48
    mode = tunnel
    esp_proposals = aes256gcm16-prfsha384-ecp384
    start_action = trap
  }
}

Lit local_ts en remote_ts weilizze en strongSwan liedt se ôf fan de subnetten fan de interface dy’t it kiest. Op in dual-stack-host jout dy fluchwei faak in pear mei allinnich IPv4: de SA komt op en IPv6 wurdt wegere foar’t it de ESP-koade berikt. Beide prefiksen útskriuwe makket de SA geskikt om se te dragen, en start_action = trap bringt it op by it earste passende pakket.

WireGuard hat ien list dy’t twa taken docht. Yn it peer-blok is AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 sawol de rûte dy’t by ferstjoeren ynstallearre wurdt as it filter dat by ûntfangst tapast wurdt: in ûntsifere pakket waans ynterne boarne bûten de list fan dy peer falt, wurdt stilwei weilitten. wg-quick foeget in rûte per ynfier ta, dus it peer-blok hjirûnder hat gjin aparte ip -6 route-opdracht nedich.

[Interface]
Address = 2001:db8:aa:ff::1/64, fd00:aa:ff::1/64
ListenPort = 51820

[Peer]
PublicKey = <site-b-public-key>
Endpoint = 203.0.113.20:51820
AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48

Beide listen moatte spegele wêze: site B akseptearret it prefiks fan site A as fiere selektor en rûtet it werom, en de tunnel wurket allinnich as de twa rjochtingen oerienkomme. In asymmetryske list jout it symptoom dat de measte tiid kostet — in sûne hânsklean, tellers dy’t op ien kant bewege, en in ping fan A nei B dy’t slagget wylst neat fan B A berikt.

Trochstjoeren, rûtes en it weromprefiks

Linux stjoert IPv6 net troch foar’t jo it sizze, en de ynstelling jildt per namespace en net per interface:

sysctl -w net.ipv6.conf.all.forwarding=1
ip -6 route add 2001:db8:bb::/48 dev wg0
ip -6 route get 2001:db8:bb::10 from 2001:db8:aa::10

De twadde rigel is dy’t minsken ferjitte yn rûtebasearre ûntwerpen. Beliedsbasearre IPsec ynstallearret in XFRM-belied dat by de prefiksen past, mar in rûtebasearre opset mei vti6 of WireGuard hat in echte IPv6-rûte nedich dy’t nei dat apparaat wiist. Meitsje de sysctl ûnder /etc/sysctl.d/ duorsum; oars set in werstart it trochstjoeren stilwei wer op ôf.

Trochstjoeren hat in sydffekt dy’t de muoite wurdich is om te witten: de kernel negearret dan router advertisements, útsein as net.ipv6.conf.<wan>.accept_ra 2 is, sadat in gateway waans WAN-adres fia SLAAC oankomt syn standertrûte ferlieze kin op it stuit dat jo trochstjoeren aktivearje. Set accept_ra = 2 op dy interface yn deselde triem en de rûte oerlibbet. De kearn fan site B moat ek 2001:db8:aa::/48 fan de tunnelgateway leare, fia in statyske rûte of in rûteringsprotokol oer de tunnel, oars stjert it antwird binnen B syn eigen netwurk.

In fjouwerstapkontrôle dy’t de brek lokalisearret

Wurkje yn dizze folchoarder en stopje by de earste stap dy’t mislearret, om’t elke lettere stap fan de eardere ôfhinget.

  1. Selektors: swanctl --list-sas soe it IPv6-prefikspear op de child-SA sjen litte, of wg show wg0 allowed-ips it fiere prefiks mei in resint latest-handshakes.
  2. Kernrûte: ip -6 route get 2001:db8:bb::10 moat antwirdzje mei it tunnelapparaat, net mei de WAN-interface.
  3. Ynterne opname: tcpdump -ni wg0 ip6 wylst jo tusken echte LAN-hosts pingje. Pakketten dy’t útgeane mar gjinien dy’t weromkomt wize op de rûte of fjoermuorre fan B; hielendal gjin pakketten wize werom op stap 1 of 2.
  4. Bestimming: op de B-host befêstiget ss -6 -ltn dat de tsjinst op IPv6 harket, en de lokale fjoermuorretellers litte sjen oft it pakket akseptearre of weilitten is.

MTU heart by deselde trochgong. IPv6-routers fragmintearje net, dus in te grut pakket wurdt weilitten en Packet Too Big komt werom nei de stjoerder. As hânskleanen en lytse pings wurkje mar in triemferpleatsing fêstset, ferlytsje de lading oant it trochkomt: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-interfaces hawwe standert 1420 bytes MTU en IPsec oer IPv4 lûkt mear ôf, dus de ynterne MTU sette is better as hoopje op paad-MTU-ûntdekking troch in fjoermuorre dy’t ICMPv6 weilit.

Foutmodi dy’t op fjoermuorreproblemen lykje

De meast foarkommende is hielendal gjin fjoermuorre: de tsjinst bynt oan 0.0.0.0 yn stee fan ::, it AAAA-record bestiet, en de klient krijt in flugge wegering oer IPv6 dy’t in dual-stack-browser ferstekt troch werom te fallen op IPv4. As allinnich guon applikaasjes mislearje, kontrolearje de harkende famylje foar’t jo in regelset oanreitsje.

De twadde is ICMPv6-filtering. Neighbor Discovery en Packet Too Big binne diel fan normale operaasje, net fan diagnostyk, en in belied dat alle ICMPv6 weilit liedt ta in tunnel dy’t ferbynt, autentisearret en dan fêstset op alles grutter as in lyts pakket. Lit de typen ta dêr’t it paad fan ôfhinget en lit de tellers oan sadat in drop sichtber is.

De tredde is in prefiks dat oan de tunnel tafoege wurdt mar nea oan it adresplan fan de site dy’t it besit, sadat gjin router it oankundiget en gjin host derút antwirdzje kin. Begjin mei ien prefiks en ien hostpear, bewês beide rjochtingen mei de fjouwer stappen en foegje dan de rest ta; in stikken prefiks bliuwt ien rigel yn in konfiguraasje yn stee fan in werûntwerp. De iene offisjele referinsje dy’t de muoite wurdich is om iepen te hâlden, is RFC 8200, dy’t de kop definiearret dy’t de tunnel draacht.

Relatearre artikelen