IPv6 bideratzea bi guneen artean lehendik dagoen VPN baten bidez

IPv6 aurrizki bat gune-guneko tunel bati gehitzen diozunean, paketea ez da diagramak iradokitzen duen moduan bidaiatzen. Tokiko gatewayak IPv6 pakete osoa hartzen du, enkriptatu egiten du, eta aurrez kanpoko IP goiburu bat jartzen du, zeinaren helbide-familia endpointen helbideek erabakitzen duten, ez barrutik dagoenak. Urruneko gatewayak kanpoko goiburu hori kentzen du eta jatorrizko paketea bere LANera birbidaltzen du, han berriro IPv6 pakete arrunta baita. Kanpoko tunela eta barneko trafikoa elkarrizketa bereiziak dira, gako bat, endpoint pare bat eta besterik ez dutenak elkarbanatzen.

Bi goiburu, bi helbide-familia

IPsec tunel moduan, barneko IPv6 paketea ESP goiburu baten atzeko karga bihurtzen da. ESP pakete hori daraman kanpoko goiburua IPv4 edo IPv6 izan daiteke, eta local_addrs eta remote_addrs jarraitzen ditu. WireGuardek gauza bera egiten du zeremonia gutxiagorekin: barneko paketea peerraren endpointera doan UDP datagrama baten karga da. Biek barneko goiburua ukitu gabe uzten dute, eta horregatik urruneko aldeak dekapsulatu ostean bidezkatu dezake.

Guneen arteko bideak UDP 4500 soilik ikusten du IPsec-ek NAT zeharkatzea erabiltzen duenean, edo UDP 51820 WireGuard entzule lehenetsi baterako. Bideko edozein router IPv4 soilik izan daiteke eta IPv6 trafikoak hala ere zeharkatzen du, bide horretan inoiz ez baita IPv6 pakete gisa agertzen. Horrek lehen banaketa garbia ematen du: tcpdump -ni eth0 udp port 51820 bide zifratua erakusten du, tcpdump -ni wg0 ip6 barne trafikoa erakusten du. Kanpoko harrapaketa bizia eta barnekoa isila izateak esan nahi du kernelak ez duela IPv6 tunelera sartzen; hori bideratzea edo politika da, ez esteka egoera.

Gatewayak barneko Hop Limit ere jaisten du birbidaltzean, beraz endpointak router gisa zenbatzen dira IPv6 bidean. Kanpoko hop kopurua eta barneko Hop Limit modu independentean mugitzen dira, eta urruneko gatewayan hiltzen den paketea birbidaltzean hil da, ez enkriptatzean.

Hautatzaileak eta AllowedIPs baimen zerrenda dira

IKEv2-k negoziatzen du zein barne aurrizki eraman ditzakeen child SA batek. strongSwan 5.9 eta geroago, swanctl.conf idaztea horrela ikusten da:

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

Utzi local_ts eta remote_ts eta strongSwanek aukeratzen duen interfazearen subnetetatik eratortzen ditu. Dual-stack ostalari batean lasterbide horrek IPv4 soilik duen pare bat ematen du sarritan: SA igotzen da eta IPv6 ukatu egiten da ESP kodea ukitzen duen aurretik. Bi aurrizkiak idazteak SA prest jartzen du haiek eramateko, eta start_action = trap bat datozen lehen paketean igotzen du.

WireGuardek zerrenda bakarra du, bi lan egiten dituena. Peer blokean, AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 bidaltzean instalatutako bidea da eta jasotzean aplikatutako iragazkia ere bai: kanpoko peer zerrendatik kanpo geratzen den jatorri barnekoa duen pakete deszifratua isilka botatzen da. wg-quick sarrera bakoitzeko bide bat gehitzen du, beraz beheko peer blokeak ez du ip -6 route komando bereizirik behar.

[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

Bi zerrendek ispilu izan behar dute: gune B-k gune A-ren aurrizkia urruneko hautatzaile gisa onartzen du eta atzera bidezkatzen du, eta tunelak bi norabideek ados egon behar dute. Zerrend asimetrikoak denbora gehien galtzen duen sintoma ematen du — handshake osasuntsua, kontagailuak alde batetik mugitzen, eta A-tik B-rako ping bat ondo doana, B-tik ezer A-ra iristen ez den bitartean.

Birbidaltzea, ibilbideak eta itzulera-aurrizkia

Linux-ek ez du IPv6 birbidaltzen zuk esan arte, eta ezarpena namespace bakoitzeko da, ez interfaze bakoitzeko:

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

Bigarren lerroa da jendeak bide oinarritutako diseinuetan ahazten duena. Politika oinarritutako IPsec-ek aurrizkiekin bat datorren XFRM politika instalatzen du, baina vti6 edo WireGuard duen bide oinarritutako konfigurazioak gailu horretara zuzendutako IPv6 bide bat behar du. Sysctl-a /etc/sysctl.d/ azpian iraunarazi; bestela berrabiarazteak birbidaltzea isilka itzalita uzten du.

Birbidaltzeak jakitea merezi duen bigarren efektua du: orduan kernelak router iragarkiak alde batera uzten ditu net.ipv6.conf.<wan>.accept_ra 2 ez bada, beraz SLAAC bidez WAN helbidea jasotzen duen gateway batek bere bide lehenetsia gal dezake birbidaltzea gaitzen duzun unean. Ezarri accept_ra = 2 interfaze horretan fitxategi berean eta bideak bizirauten du. Gune B-ren nukleoak ere 2001:db8:aa::/48 ikasi behar du tunelaren gatewaytik, bide estatiko baten edo tunelaren gaineko bideratze protokolo baten bidez, bestela erantzuna B-ren sarean bertan hiltzen da.

Lau urratseko egiaztapena, haustura kokatzen duena

Lan egin ordena honetan eta gelditu huts egiten duen lehen urratsean, urrats bakoitzak aurrekoen mende baitago.

1. Hautatzaileak: swanctl --list-sas child SA-an IPv6 aurrizki pareak erakutsi beharko lituzke, edo wg show wg0 allowed-ips urruneko aurrizkia latest-handshakes berri batekin.
2. Kernelaren ibilbidea: ip -6 route get 2001:db8:bb::10 tunel gailuarekin erantzun behar du, ez WAN interfazearekin.
3. Barne harrapaketa: tcpdump -ni wg0 ip6 LAN ostalari errealen artean ping egiten duzun bitartean. Ateratzen diren paketeak baina bat ere ez itzultzea B-ren bidea edo suebakia seinalatzen dute; paketerik ez izateak 1 edo 2 urratsera itzultzen du.
4. Helmuga: B ostalarian, ss -6 -ltn zerbitzuak IPv6-en entzuten duela baieztatzen du, eta tokiko suebaki kontagailuek paketea onartu edo baztertu zen erakusten dute.

MTU beste txanda berean doa. IPv6 routerrek ez dute zatikatzen, beraz pakete handiegia baztertu egiten da eta Packet Too Big bidaltzaileari itzultzen zaio. Handshakes eta ping txikiek funtzionatzen badute baina fitxategi transferentzia trabatzen bada, txikitu karga pasa arte: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard interfazeek 1420 byteko MTU dute lehenespenez eta IPv4 gaineko IPsec-ek gehiago kentzen du, beraz barneko MTUa ezartzeak ICMPv6 botatzen duen suebaki baten bidezko bide MTU aurkikuntzaren zain egoteak baino gehiago balio du.

Suebaki arazoen itxura duten hutsegite moduak

Ohikoena ez da suebaki bat: zerbitzua 0.0.0.0 ra lotzen da :: ordez, AAAA erregistroa existitzen da, eta bezeroak IPv6 bidezko arbuiatze azkarra jasotzen du, dual-stack nabigatzaileak IPv4ra itzuliz ezkutatzen duena. Aplikazio batzuek soilik huts egiten badute, begiratu entzute familia arau multzo bat ukitu aurretik.

Bigarrena ICMPv6 iragazketa da. Neighbor Discovery eta Packet Too Big funtzionamendu arruntaren parte dira, ez diagnostikoarenak, eta ICMPv6 guztia baztertzen duen politika batek konektatzen, autentifikatzen eta gero pakete txiki bat baino handiago den guztian trabatzen den tunela sortzen du. Baimendu bideak behar dituen motak eta utzi kontagailuak piztuta baztertzea ikusgai izan dadin.

Hirugarrena tunelari gehitzen zaion baina jabea den gunearen helbide planean inoiz sartzen ez den aurrizki bat da, beraz inongo routerrek ez du iragartzen eta inongo ostalarik ezin du handik erantzun. Hasi aurrizki batekin eta ostalari pare batekin, frogatu bi norabideak lau urratsekin, gero gainerakoa gehitu; aurrizki hautsiak konfigurazio bateko lerro bat izaten jarraitzen du birplanteamendu baten ordez. Irekita mantentzea merezi duen erreferentzia ofizial bakarra RFC 8200 da, tunelak daraman goiburua definitzen duena.