Usmjeravanje IPv6 između dva lokaliteta preko postojećeg VPN-a
WAN samo s IPv4 i dalje može prenositi unutarnji IPv6. Pratite selektore, kernelove rute, prosljeđivanje i povratni prefiks koji tiho odbacuje odgovore.
Kada dodate IPv6 prefiks u tunel između lokaliteta, paket ne putuje onako kako dijagram sugerira. Lokalni gateway uzima cijeli IPv6 paket, šifrira ga i ispred stavlja vanjski IP zaglavlje čiju obitelj adresa određuju adrese krajnjih točaka, a ne ono što je unutra. Udaljeni gateway uklanja to vanjsko zaglavlje i prosljeđuje izvorni paket na svoj LAN, gdje je opet običan IPv6 paket. Vanjski tunel i unutarnji promet dva su odvojena razgovora koja dijele ključ, par krajnjih točaka i ništa drugo.
Dva zaglavlja, dvije obitelji adresa
U IPsec načinu tunela unutarnji IPv6 paket postaje teret iza ESP zaglavlja. Vanjsko zaglavlje koje nosi taj ESP paket može biti IPv4 ili IPv6 i slijedi local_addrs i remote_addrs. WireGuard čini isto s manje ceremonije: unutarnji paket je teret UDP datagrama prema krajnjoj točki partnera. Oba ostavljaju unutarnje zaglavlje netaknutim, zbog čega ga udaljena strana može usmjeriti nakon dekapsulacije.
Put između lokaliteta vidi samo UDP 4500 kada IPsec koristi NAT prolaz, ili UDP 51820 za zadani WireGuard osluškivač. Svaki usmjerivač na putu može biti samo IPv4 i IPv6 promet ipak prolazi, jer se na tom putu nikada ne pojavljuje kao IPv6 paket. To daje čistu prvu podjelu: tcpdump -ni eth0 udp port 51820 prikazuje šifrirani put, tcpdump -ni wg0 ip6 prikazuje unutarnji promet. Zauzeto vanjsko snimanje s tihim unutarnjim znači da kernel ne stavlja IPv6 u tunel; to je usmjeravanje ili politika, a ne stanje veze.
Gateway također smanjuje unutarnji Hop Limit dok prosljeđuje, pa se krajnje točke računaju kao usmjerivači na IPv6 putu. Vanjski broj skokova i unutarnji Hop Limit kreću se neovisno, a paket koji umre na udaljenom gatewayu umro je u prosljeđivanju, ne u šifriranju.
Selektori i AllowedIPs su popis dopuštenja
IKEv2 pregovara koje unutarnje prefikse child SA smije nositi. Na strongSwan 5.9 i novijima njihovo ispisivanje u swanctl.conf izgleda ovako:
children {
net6 {
local_ts = 2001:db8:aa::/48
remote_ts = 2001:db8:bb::/48
mode = tunnel
esp_proposals = aes256gcm16-prfsha384-ecp384
start_action = trap
}
}
Izostavite local_ts i remote_ts i strongSwan ih izvodi iz podmreža sučelja koje odabere. Na dual-stack hostu ta kratica često daje par samo IPv4: SA se digne i IPv6 se odbija prije nego što stigne do ESP koda. Ispisivanje oba prefiksa čini SA sposobnim da ih nosi, a start_action = trap podiže ga na prvom odgovarajućem paketu.
WireGuard ima jedan popis koji obavlja dva posla. U bloku partnera AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 je i ruta instalirana pri slanju i filtar primijenjen pri primanju: dešifrirani paket čiji unutarnji izvor padne izvan popisa tog partnera tiho se odbacuje. wg-quick dodaje rutu po unosu, pa blok partnera ispod ne treba zasebnu ip -6 route naredbu.
[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
Oba popisa moraju biti zrcalna: lokalitet B prihvaća prefiks lokaliteta A kao udaljeni selektor i usmjerava ga natrag, a tunel radi samo kad se dva smjera slažu. Asimetričan popis daje simptom koji troši najviše vremena — zdrav stisak ruke, brojila se kreću na jednoj strani, i ping od A do B koji uspijeva dok ništa iz B ne dolazi do A.
Prosljeđivanje, rute i povratni prefiks
Linux ne prosljeđuje IPv6 dok ne kažete, a postavka vrijedi po namespaceu, a ne po sučelju:
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
Drugi redak je onaj koji ljudi zaborave u dizajnima temeljenima na rutama. IPsec temeljen na politici instalira XFRM politiku koja odgovara prefiksima, ali postava temeljena na rutama s vti6 ili WireGuardom treba stvarnu IPv6 rutu koja pokazuje na taj uređaj. Sačuvajte sysctl pod /etc/sysctl.d/; inače ponovno podizanje tiho vraća prosljeđivanje u isključeno stanje.
Prosljeđivanje ima nuspojavu koju vrijedi znati: kernel tada ignorira najave usmjerivača osim ako net.ipv6.conf.<wan>.accept_ra nije 2, pa gateway čija WAN adresa dolazi preko SLAAC-a može izgubiti zadanu rutu u trenutku kad uključite prosljeđivanje. Postavite accept_ra = 2 na tom sučelju u istoj datoteci i ruta preživljava. Jezgra lokaliteta B također mora naučiti 2001:db8:aa::/48 od gatewaya tunela, statičnom rutom ili protokolom usmjeravanja nad tunelom, inače odgovor umire unutar mreže samog B.
Provjera u četiri koraka koja lokalizira prekid
Radite ovim redom i stanite na prvom koraku koji zakaže, jer svaki kasniji korak ovisi o prethodnima.
- Selektori:
swanctl --list-sasbi trebao pokazati par IPv6 prefiksa na child SA, iliwg show wg0 allowed-ipsudaljeni prefiks sa svježimlatest-handshakes. - Kernel ruta:
ip -6 route get 2001:db8:bb::10mora odgovoriti uređajem tunela, a ne WAN sučeljem. - Unutarnje snimanje:
tcpdump -ni wg0 ip6dok pingate između pravih LAN hostova. Paketi koji izlaze, ali nijedan se ne vraća, upućuju na rutu ili vatrozid B; posve nikakvi paketi upućuju natrag na korak 1 ili 2. - Odredište: na hostu B
ss -6 -ltnpotvrđuje da usluga osluškuje na IPv6, a lokalna brojila vatrozida pokazuju je li paket prihvaćen ili odbačen.
MTU pripada istom prolazu. IPv6 usmjerivači ne fragmentiraju, pa se preveliki paket odbacuje i Packet Too Big se vraća pošiljatelju. Ako stisci ruke i mali pingovi rade, ali prijenos datoteke zapne, smanjite teret dok ne prođe: ping -6 -s 1400 -c 3 2001:db8:bb::10. Sučelja WireGuard standardno imaju MTU od 1420 bajtova, a IPsec nad IPv4 oduzima više, pa je postavljanje unutarnjeg MTU-a bolje od nade u otkrivanje MTU-a puta kroz vatrozid koji odbacuje ICMPv6.
Načini kvara koji izgledaju kao problemi s vatrozidom
Najčešći uopće nije vatrozid: usluga se veže na 0.0.0.0 umjesto na ::, AAAA zapis postoji, a klijent dobiva brzo odbijanje preko IPv6 koje dual-stack preglednik skriva vraćanjem na IPv4. Ako zakažu samo neke aplikacije, provjerite obitelj osluškivanja prije nego što dirate skup pravila.
Drugi je filtriranje ICMPv6. Neighbor Discovery i Packet Too Big dio su normalnog rada, a ne dijagnostike, i politika koja odbacuje sav ICMPv6 stvara tunel koji se spoji, ovjeri i zatim zapne na svemu većem od malog paketa. Dopustite vrste o kojima put ovisi i ostavite brojila uključena da odbacivanje bude vidljivo.
Treći je prefiks dodan tunelu, ali nikada u adresni plan lokaliteta koji ga posjeduje, pa ga nijedan usmjerivač ne najavljuje i nijedan host ne može odgovoriti iz njega. Započnite s jednim prefiksom i jednim parom hostova, dokažite oba smjera s četiri koraka, pa dodajte ostatak; pokvaren prefiks ostaje jedan redak u konfiguraciji umjesto prerade. Jedina službena referenca koju vrijedi držati otvorenom je RFC 8200, koja definira zaglavlje koje tunel nosi.