Enkursigi IPv6 inter du lokoj tra ekzistanta VPN

WAN kun nur IPv4 ankoraŭ povas porti internan IPv6. Sekvi selektilojn, kernajn vojojn, plusendadon kaj la revenan prefikson, kiu silenteme forĵetas respondojn.

Kiam vi aldonas IPv6-prefikson al loko-al-loka tunelo, la pako ne vojaĝas kiel la diagramo sugestas. La loka pordego prenas la tutan IPv6-pakon, ĉifras ĝin, kaj metas antaŭ ĝi eksteran IP-kapon, kies adresa familio estas decidita de la finpunktaj adresoj, ne de tio, kio estas interne. La malproksima pordego forigas tiun eksteran kapon kaj plusendas la originalan pakon al sia LAN, kie ĝi denove estas ordinara IPv6-pako. Ekstera tunelo kaj interna trafiko estas du apartaj interparoloj, kiuj dividas ŝlosilon, finpunktan paron kaj nenion pli.

Du kapoj, du adresaj familioj

En IPsec-tunela modo, la interna IPv6-pako iĝas la utileco malantaŭ ESP-kapo. La ekstera kapo, kiu portas tiun ESP-pakon, povas esti IPv4 aŭ IPv6, kaj ĝi sekvas local_addrs kaj remote_addrs. WireGuard faras la samon kun malpli da ceremonio: la interna pako estas la utileco de UDP-datagramo al la finpunkto de la kunulo. Ambaŭ lasas la internan kapon netuŝita, tial la malproksima flanko povas enkursigi ĝin post malĉifrado.

La vojo inter la lokoj vidas nur UDP 4500 kiam IPsec uzas NAT-trairecon, aŭ UDP 51820 por implicita WireGuard-aŭskultanto. Ĉiu enkursigilo sur la vojo povas esti nur IPv4 kaj la IPv6-trafiko tamen trapasas, ĉar ĝi neniam aperas kiel IPv6-pako sur tiu vojo. Tio donas puran unuan dividon: tcpdump -ni eth0 udp port 51820 montras la ĉifritan vojon, tcpdump -ni wg0 ip6 montras la internan trafikon. Okupata ekstera kapto kun silentema interna signifas, ke la kerno ne metas IPv6 en la tunelon; tio estas enkursigado aŭ politiko, ne ligila stato.

La pordego ankaŭ malpliigas la internan Hop Limit dum plusendado, do la finpunktoj konsideriĝas enkursigiloj sur la IPv6-vojo. Ekstera hops-nombro kaj interna Hop Limit moviĝas sendepende, kaj pako, kiu mortas ĉe la malproksima pordego, mortis en plusendado, ne en ĉifrado.

Selektiloj kaj AllowedIPs estas la permeslisto

IKEv2 intertraktas, kiujn internajn prefiksojn child SA rajtas porti. Sur strongSwan 5.9 kaj poste, skribi ilin en swanctl.conf aspektas jene:

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

Forlasi local_ts kaj remote_ts kaj strongSwan derivas ilin el la subretoj de la interfaco, kiun ĝi elektas. Sur dual-stack-mastiganto tiu mallongigo ofte donas paron kun nur IPv4: la SA levitas kaj IPv6 estas rifuzata antaŭ ol atingi la ESP-kodon. Skribi ambaŭ prefiksojn faras la SA kapabla porti ilin, kaj start_action = trap levigas ĝin ĉe la unua kongrua pako.

WireGuard havas unu liston, kiu plenumas du taskojn. En la kunula bloko, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 estas samtempe la vojo instalata ĉe sendado kaj la filtrilo aplikata ĉe ricevado: malĉifrita pako, kies interna fonto falas ekster la listo de tiu kunulo, estas silenteme forĵetata. wg-quick aldonas vojon por ĉiu ero, do la kunula bloko sube ne bezonas apartan ip -6 route-komandon.

[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

Ambaŭ listoj devas esti spegulitaj: loko B akceptas la prefikson de loko A kiel malproksiman selektilon kaj enkursigas ĝin reen, kaj la tunelo funkcias nur kiam la du direktoj interkonsentas. Nesimetria listo kaŭzas la simptomon, kiu konsumas plej multe da tempo — sana manpremo, nombriloj moviĝantaj unuflanke, kaj ping de A al B, kiu sukcesas dum nenio el B atingas A.

Plusendado, vojoj kaj la revena prefikso

Linux ne plusendas IPv6 antaŭ ol vi diras, kaj la agordo estas por namespace, ne por interfaco:

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

La dua linio estas tiu, kiun homoj forgesas en voj-bazitaj dezajnoj. Politik-bazita IPsec instalas XFRM-politikon kongruantan kun la prefiksoj, sed voj-bazita agordo kun vti6 aŭ WireGuard bezonas realan IPv6-vojon indikantan al tiu aparato. Permanenta sysctl sub /etc/sysctl.d/; aliokaze restarto silenteme reŝaltas plusendadon al malŝaltita.

Plusendado havas kromefikon indan koni: la kerno tiam ignoras enkursigilajn anoncojn, krom se net.ipv6.conf.<wan>.accept_ra estas 2, do pordego, kies WAN-adreso alvenas per SLAAC, povas perdi sian implicitan vojon en la momento, kiam vi ebligas plusendadon. Agordu accept_ra = 2 sur tiu interfaco en la sama dosiero kaj la vojo pluvivas. La kerno de loko B ankaŭ devas lerni 2001:db8:aa::/48 de la tunela pordego, per statika vojo aŭ enkursiga protokolo sur la tunelo, aliokaze la respondo mortas interne de la propra reto de B.

Kvarŝtupa kontrolo, kiu lokalizas la rompon

Laboru en ĉi tiu ordo kaj haltu ĉe la unua ŝtupo, kiu malsukcesas, ĉar ĉiu posta ŝtupo dependas de la antaŭaj.

  1. Selektiloj: swanctl --list-sas devus montri la IPv6-prefiksan paron sur la child SA, aŭ wg show wg0 allowed-ips la malproksiman prefikson kun freŝa latest-handshakes.
  2. Kerna vojo: ip -6 route get 2001:db8:bb::10 devas respondi per la tunela aparato, ne per la WAN-interfaco.
  3. Interna kapto: tcpdump -ni wg0 ip6 dum vi pingas inter realaj LAN-mastigantoj. Pakoj elirantaj sed neniuj revenantaj montras al la vojo aŭ fajroŝirmilo de B; neniuj pakoj entute montras reen al ŝtupo 1 aŭ 2.
  4. Loko: sur la B-mastiganto, ss -6 -ltn konfirmas, ke la servo aŭskultas sur IPv6, kaj la lokaj fajroŝirmilaj nombriloj montras, ĉu la pako estis akceptita aŭ forĵetita.

MTU apartenas al la sama pasado. IPv6-enkursigiloj ne fragmentas, do trogranda pako estas forĵetata kaj Packet Too Big revenas al la sendinto. Se manpremoj kaj malgrandaj pingoj funkcias sed dosiera transigo haltas, malpliigu la utilecon ĝis ĝi pasas: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-interfacoj implicite havas MTU de 1420 bajtoj kaj IPsec sur IPv4 subtiras pli, do agordi la internan MTU valoras pli ol esperi vojo-MTU-malkovron tra fajroŝirmilo, kiu forĵetas ICMPv6.

Malsukcesaj modoj, kiuj aspektas kiel fajroŝirmilaj problemoj

La plej ordinara estas tute ne fajroŝirmilo: la servo ligiĝas al 0.0.0.0 anstataŭ ::, la AAAA-rikordo ekzistas, kaj la kliento ricevas rapidan rifuzon sur IPv6, kiun dual-stack-retumilo kaŝas per reiro al IPv4. Se nur kelkaj aplikaĵoj malsukcesas, kontrolu la aŭskultantan familion antaŭ ol tuŝi regulan aron.

La dua estas ICMPv6-filtrado. Neighbor Discovery kaj Packet Too Big apartenas al normala operacio, ne al diagnozado, kaj politiko, kiu forĵetas ĉiun ICMPv6, produktas tunelon, kiu konektiĝas, aŭtentikigas kaj poste haltas sur io ajn pli granda ol malgranda pako. Permesu la tipojn, de kiuj la vojo dependas, kaj lasu la nombrilojn ŝaltitaj por ke forĵeto estu videbla.

La tria estas prefikso aldonita al la tunelo sed neniam al la adresa plano de la loko, kiu posedas ĝin, do neniu enkursigilo anoncas ĝin kaj neniu mastiganto povas respondi el ĝi. Komencu per unu prefikso kaj unu mastiganta paro, pruvu ambaŭ direktojn per la kvar ŝtupoj, poste aldonu la reston; difektita prefikso restas unu linio en agordo anstataŭ tuta rearanĝo. La sola oficiala referenco inda resti malferma estas RFC 8200, kiu difinas la kapon, kiun la tunelo portas.

Rilataj artikoloj