IPv6:n reititys kahden sivuston välillä olemassa olevan VPN:n kautta

Kun lisäät sivusto-sivusto-tunneliin IPv6-etuliitteen, paketti ei matkusta kuten kaavio antaa ymmärtää. Paikallinen yhdyskäytävä ottaa koko IPv6-paketin, salaa sen ja asettaa eteensä ulkoisen IP-otsikon, jonka osoiteperheen päättävät päätepisteiden osoitteet, ei se mitä on sisällä. Kaukaisen puolen yhdyskäytävä poistaa tuon ulkoisen otsikon ja välittää alkuperäisen paketin omaan lähiverkkoonsa, jossa se on jälleen tavallinen IPv6-paketti. Ulkoinen tunneli ja sisäinen liikenne ovat kaksi erillistä keskustelua, jotka jakavat avaimen, päätepisteiden parin eikä mitään muuta.

Kaksi otsikkoa, kaksi osoiteperhettä

IPsec-tunnelitilassa sisäinen IPv6-paketti muuttuu ESP-otsikon takana olevaksi hyötykuormaksi. Tuota ESP-pakettia kuljettava ulkoinen otsikko voi olla IPv4 tai IPv6, ja se seuraa local_addrs ja remote_addrs. WireGuard tekee saman vähemmällä seremonialla: sisäinen paketti on UDP-datagrammin hyötykuorma vertaisparin päätepisteeseen. Molemmat jättävät sisäisen otsikon koskemattomaksi, minkä vuoksi kaukainen puoli voi reitittää sen purkamisen jälkeen.

Sivustojen välinen polku näkee vain UDP 4500:n, kun IPsec käyttää NAT-läpäisyä, tai UDP 51820 oletusarvoiselle WireGuard-kuuntelijalle. Mikä tahansa polun reititin voi olla vain IPv4, ja IPv6-liikenne kulkee silti, koska se ei koskaan esiinny IPv6-pakettina tuolla polulla. Se antaa puhtaan ensimmäisen jaon: tcpdump -ni eth0 udp port 51820 näyttää salatun polun, tcpdump -ni wg0 ip6 näyttää sisäisen liikenteen. Kiireinen ulkoinen kaappaus ja hiljainen sisäinen tarkoittaa, että ydin ei laita IPv6:ta tunneliin; se on reititystä tai politiikkaa, ei linkin tila.

Yhdyskäytävä myös vähentää sisäistä Hop Limit -arvoa välittäessään, joten päätepisteet lasketaan reitittimiksi IPv6-polulla. Ulkoinen hyppymäärä ja sisäinen Hop Limit liikkuvat itsenäisesti, ja kaukaisella yhdyskäytävällä kuoleva paketti kuoli välityksessä, ei salauksessa.

Valitsimet ja AllowedIPs ovat lupaluettelo

IKEv2 neuvottelee, mitä sisäisiä etuliitteitä child SA voi kantaa. strongSwan 5.9:ssä ja uudemmissa niiden kirjoittaminen tiedostoon swanctl.conf näyttää tältä:

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ätä local_ts ja remote_ts pois, niin strongSwan johtaa ne valitsemansa rajapinnan aliverkoista. Dual-stack-isännässä tuo oikotie tuottaa usein vain IPv4-parin: SA nousee ja IPv6 hylätään ennen kuin se saavuttaa ESP-koodin. Molempien etuliitteiden kirjoittaminen tekee SA:sta kykenevän kantamaan ne, ja start_action = trap nostaa sen ensimmäisellä sopivalla paketilla.

WireGuardilla on yksi luettelo, joka tekee kaksi työtä. Vertaislohkossa AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 on sekä lähetyksessä asennettava reitti että vastaanotossa sovellettava suodatin: salattu paketti, jonka sisäinen lähde jää tuon vertaisen luettelon ulkopuolelle, pudotetaan hiljaa. wg-quick lisää reitin jokaista merkintää kohden, joten alla oleva vertaislohko ei tarvitse erillistä ip -6 route-komentoa.

[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

Molempien luetteloiden on oltava peilikuvia: sivusto B hyväksyy sivuston A etuliitteen kaukovalitsijana ja reitittää sen takaisin, ja tunneli toimii vain, kun kaksi suuntaa ovat yhtä mieltä. Epäsymmetrinen luettelo antaa oireen, joka maksaa eniten aikaa — terve kättely, laskurit liikkuvat toisella puolella, ja ping A:sta B:hen onnistuu, kun taas mikään B:stä ei saavuta A:ta.

Edelleenlähetys, reitit ja paluuetuliite

Linux ei välitä IPv6:ta ennen kuin sanot niin, ja asetus on nimiavaruuskohtainen, ei rajapintakohtainen:

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

Toinen rivi on se, jonka ihmiset unohtavat reittipohjaisissa suunnitelmissa. Politiikkapohjainen IPsec asentaa etuliitteisiin sopivan XFRM-käytännön, mutta vti6 tai WireGuardin kanssa reittipohjainen kokoonpano tarvitsee todellisen IPv6-reitin, joka osoittaa tuohon laitteeseen. Tee sysctl-tiedostosta pysyvä /etc/sysctl.d/ alla; muuten uudelleenkäynnistys palauttaa välityksen hiljaa pois päältä.

Välityksellä on sivuefekti, joka kannattaa tietää: ydin jättää silloin reitittimien ilmoitukset huomiotta, ellei net.ipv6.conf.<wan>.accept_ra ole 2, joten yhdyskäytävä, jonka WAN-osoite saapuu SLAAC:lla, voi menettää oletusreittinsä heti, kun otat välityksen käyttöön. Aseta accept_ra = 2 tuolle rajapinnalle samassa tiedostossa, niin reitti säilyy. Sivuston B ytimen on myös opittava 2001:db8:aa::/48 tunneliyhdyskäytävältä, staattisella reitillä tai tunnelin päällä toimivalla reititysprotokollalla, muuten vastaus kuolee B:n omaan verkkoon.

Neljän askeleen tarkistus, joka paikantaa katkoksen

Työskentele tässä järjestyksessä ja pysähdy ensimmäisellä askeleella, joka epäonnistuu, koska jokainen myöhempi askel riippuu aiemmista.

1. Valitsimet: swanctl --list-sas näyttää IPv6-etuliiteparin child SA:lla, tai wg show wg0 allowed-ips kaukaisen etuliitteen tuoreella latest-handshakes:lla.
2. Ytimen reitti: ip -6 route get 2001:db8:bb::10 täytyy vastata tunnelilaitteella, ei WAN-rajapinnalla.
3. Sisäinen kaappaus: tcpdump -ni wg0 ip6 pingatessasi todellisten lähiverkon isäntien välillä. Paketit, jotka lähtevät mutta yksikään ei palaa, viittaavat B:n reittiin tai palomuuriin; ei yhtään pakettia viittaa takaisin askeleeseen 1 tai 2.
4. Kohde: B-isännällä ss -6 -ltn vahvistaa, että palvelu kuuntelee IPv6:lla, ja paikalliset palomuurilaskurit näyttävät, hyväksyttiinkö paketti vai pudotettiinko se.

MTU kuuluu samaan kierrokseen. IPv6-reitittimet eivät pirsto, joten liian suuri paketti pudotetaan ja Packet Too Big palaa lähettäjälle. Jos kättelyt ja pienet pingit toimivat mutta tiedostonsiirto jumittuu, pienennä hyötykuormaa kunnes se menee läpi: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard-rajapintojen MTU on oletuksena 1420 tavua ja IPsec IPv4:n päällä vähentää enemmän, joten sisäisen MTU:n asettaminen voittaa toivon polun MTU:n löytämisestä palomuurin läpi, joka pudottaa ICMPv6:n.

Vikatilat, jotka näyttävät palomuuriongelmilta

Yleisin ei ole palomuuri lainkaan: palvelu sitoutuu 0.0.0.0:ään :::n sijaan, AAAA-tietue on olemassa, ja asiakas saa nopean hylkäyksen IPv6:n yli, jonka dual-stack-selain piilottaa palaamalla IPv4:ään. Jos vain jotkin sovellukset epäonnistuvat, tarkista kuunteleva perhe ennen säännöstön koskemista.

Toinen on ICMPv6-suodatus. Neighbor Discovery ja Packet Too Big ovat osa normaalia toimintaa, eivät diagnostiikkaa, ja käytäntö, joka pudottaa kaiken ICMPv6:n, tuottaa tunnelin, joka yhdistyy, todentuu ja jumittuu sitten kaikkeen pientä pakettia suurempaan. Salli tyypit, joista polku riippuu, ja jätä laskurit päälle, jotta pudotus näkyy.

Kolmas on etuliite, joka lisätään tunneliin mutta ei koskaan sitä omistavan sivuston osoitesuunnitelmaan, joten mikään reititin ei ilmoita sitä eikä mikään isäntä voi vastata siitä. Aloita yhdellä etuliitteellä ja yhdellä isäntäparilla, todista molemmat suunnat neljällä askeleella ja lisää sitten loput; rikkinäinen etuliite jää kokoonpanon yhdeksi riviksi uudelleensuunnittelun sijaan. Ainoa virallinen viite, jota kannattaa pitää auki, on RFC 8200, joka määrittelee tunnelin kantaman otsikon.