IPv6 marsruutimine kahe saidi vahel olemasoleva VPN-i kaudu

Ainult IPv4-ga WAN suudab siiski sisemist IPv6-t kanda. Jälgi valijaid, kerneli marsruute, edasisaatmist ja tagastusprefiksit, mis vastused vaikselt maha viskab.

Kui lisad saidi-vahelisele tunnelile IPv6-prefiksi, ei liigu pakett nii, nagu skeem vihjab. Kohalik lüüs võtab kogu IPv6-paketi, krüpteerib selle ja paneb ette välise IP-päise, mille aadressiperekonna määravad lõpp-punktide aadressid, mitte see, mis on sees. Kauglüüs eemaldab selle välise päise ja edastab algse paketi oma LAN-i, kus see on jälle tavaline IPv6-pakett. Väline tunnel ja sisemine liiklus on kaks eraldi vestlust, mis jagavad võtit, lõpp-punktide paari ja mitte midagi muud.

Kaks päist, kaks aadressiperekonda

IPsec-tunnelirežiimis saab sisemisest IPv6-paketist ESP-päise taga olev kandev sisu. Seda ESP-paketti kandev väline päis võib olla IPv4 või IPv6 ning järgib local_addrs ja remote_addrs. WireGuard teeb sama väiksema tseremooniaga: sisemine pakett on UDP-datagrammi kandev sisu partneri lõpp-punktini. Mõlemad jätavad sisemise päise puutumata, mistõttu kaugpool saab selle pärast dekapssuleerimist marsruutida.

Saitevaheline tee näeb ainult UDP 4500, kui IPsec kasutab NAT-läbimist, või UDP 51820 vaikimisi WireGuard-kuulaja jaoks. Iga tee peal olev ruuter võib olla ainult IPv4 ning IPv6-liiklus läbib ikkagi, sest see ei ilmu sellel teel kunagi IPv6-paketina. See annab puhta esimese jaotuse: tcpdump -ni eth0 udp port 51820 näitab krüpteeritud teed, tcpdump -ni wg0 ip6 näitab sisemist liiklust. Tihe väline püüdmine ja vaikne sisemine tähendab, et kernel ei pane IPv6-t tunnelisse; see on marsruutimine või poliitika, mitte lingi olek.

Lüüs vähendab edasisaatmisel ka sisemist Hop Limit-i, seega lõpp-punktid loetakse IPv6-teel ruuteriteks. Väline hüpete arv ja sisemine Hop Limit liiguvad sõltumatult ning kauglüüsil surev pakett suri edasisaatmises, mitte krüpteerimises.

Valijad ja AllowedIPs on lubade nimekiri

IKEv2 peab läbirääkimisi, milliseid sisemisi prefikseid child SA kanda tohib. StrongSwan 5.9 ja uuemates näeb nende üleskirjutamine failis swanctl.conf välja nii:

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

Jäta local_ts ja remote_ts välja ning strongSwan tuletab need liidese alamvõrkudest, mille see valib. Dual-stack-majutis annab see otsetee sageli ainult IPv4-paari: SA tõuseb üles ja IPv6 lükatakse tagasi enne ESP-koodini jõudmist. Mõlema prefiksi üleskirjutamine teeb SA võimeliseks neid kandma ning start_action = trap tõstab selle esimese sobiva paketi juures üles.

WireGuardil on üks nimekiri, mis teeb kahte tööd. Partnerplokis on AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 nii saatmisel paigaldatav marsruut kui ka vastuvõtmisel rakendatav filter: krüpteeritud pakett, mille sisemine allikas jääb selle partneri nimekirjast välja, visatakse vaikselt ära. wg-quick lisab iga kirje kohta marsruudi, seega allpool olev partnerplokk ei vaja eraldi ip -6 route-käsku.

[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

Mõlemad nimekirjad peavad olema peegelpildis: sait B võtab saidi A prefiksi kaugvalijana vastu ja marsruudib selle tagasi ning tunnel töötab ainult siis, kui kaks suunda on ühel meelel. Asümmeetriline nimekiri annab sümptomi, mis kulutab kõige rohkem aega — terve käepigistus, loendurid liiguvad ühel pool ja ping A-st B-sse õnnestub, samal ajal kui miski B-st A-ni ei jõua.

Edasisaatmine, marsruudid ja tagastusprefiks

Linux ei edasta IPv6-t enne, kui sa ütled, ja seade kehtib nimeruumi, mitte liidese kohta:

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

Teine rida on see, mille inimesed marsruudipõhistes lahendustes unustavad. Poliitikapõhine IPsec paigaldab prefiksidega sobiva XFRM-poliitika, kuid vti6 või WireGuardiga marsruudipõhine seadistus vajab tõelist IPv6-marsruuti, mis osutab sellele seadmele. Hoia sysctl-i failis /etc/sysctl.d/; muidu taastab taaskäivitamine edasisaatmise vaikselt väljalülitatud olekusse.

Edasisaatmisel on kõrvalmõju, mida tasub teada: kernel eirab siis ruuteriteateid, kui net.ipv6.conf.<wan>.accept_ra ei ole 2, seega lüüs, mille WAN-aadress saabub SLAAC-i kaudu, võib kaotada oma vaikemarsruudi hetkel, mil edasisaatmise sisse lülitad. Sea accept_ra = 2 sellele liidesele samas failis ja marsruut jääb püsima. Saiti B tuum peab tunnelilüüsilt õppima ka 2001:db8:aa::/48, staatilise marsruudi või tunneli kohal töötava marsruutimisprotokolli kaudu, muidu sureb vastus B enda võrgus.

Nelja sammu kontroll, mis paigutab katkestuse

Tööta selles järjekorras ja peatu esimesel sammul, mis ebaõnnestub, sest iga järgmine samm sõltub eelmistest.

  1. Valijad: swanctl --list-sas peaks näitama IPv6-prefiksite paari child SA-l või wg show wg0 allowed-ips kaugprefiksit värske latest-handshakes-ga.
  2. Kerneli marsruut: ip -6 route get 2001:db8:bb::10 peab vastama tunneliseadmega, mitte WAN-liidesega.
  3. Sisemine püüdmine: tcpdump -ni wg0 ip6 samal ajal kui pingid päris LAN-majutite vahel. Väljuvad paketid, kuid mitte ükski tagasitulev, osutavad B marsruudile või tulemüürile; üldse mitte paketid osutavad tagasi sammule 1 või 2.
  4. Sihtkoht: B majutis kinnitab ss -6 -ltn, et teenus kuulab IPv6-l, ja kohalikud tulemüüri loendurid näitavad, kas pakett võeti vastu või visati ära.

MTU kuulub samasse ringi. IPv6-ruuterid ei tükelda, seega liiga suur pakett visatakse ära ja Packet Too Big tuleb saatjale tagasi. Kui käepigistused ja väikesed pingid töötavad, kuid failisiire takerdub, vähenda kandev sisu kuni see läbib: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-liidesed on vaikimisi 1420-baidise MTU-ga ja IPsec IPv4 kohal lahutab rohkem, seega sisemise MTU seadmine on parem kui loota tee-MTU avastamisele läbi tulemüüri, mis ICMPv6 ära viskab.

Tõrkerežiimid, mis näevad välja nagu tulemüüriprobleemid

Kõige tavalisem polegi tulemüür: teenus seob 0.0.0.0-ga, mitte ::-ga, AAAA-kirje on olemas ja klient saab IPv6 kaudu kiire keeldumise, mille dual-stack-veebilehitseja peidab IPv4-le tagasi langedes. Kui ainult mõned rakendused ebaõnnestuvad, kontrolli kuulavat perekonda enne reeglistiku puutumist.

Teine on ICMPv6 filtreerimine. Neighbor Discovery ja Packet Too Big on osa tavapärasest tööst, mitte diagnostikast, ja poliitika, mis viskab ära kogu ICMPv6, tekitab tunneli, mis ühendub, autendib ja jääb siis seisma kõige juures, mis on väikesest paketist suurem. Luba tüübid, millest tee sõltub, ja jäta loendurid sisse, et äraviskamine oleks nähtav.

Kolmas on prefiks, mis lisatakse tunnelile, kuid mitte kunagi selle omaniksaidi aadressiplaanile, seega ükski ruuter ei teata seda ja ükski majuti ei saa sealt vastata. Alusta ühe prefiksi ja ühe majutipaariga, tõesta mõlemad suunad nelja sammuga, seejärel lisa ülejäänud; katkine prefiks jääb konfiguratsioonis üheks reaks ümberkujundamise asemel. Ainus ametlik viide, mida tasub lahti hoida, on RFC 8200, mis määratleb päise, mida tunnel kannab.

Seotud artiklid