IPv6 maršrutizavimas tarp dviejų svetainių per esamą VPN

Tik IPv4 turintis WAN vis tiek gali perduoti vidinį IPv6. Stebėkite parinkiklius, branduolio maršrutus, persiuntimą ir grąžinimo prefiksą, kuris tyliai išmeta atsakymus.

Kai prie svetainės-svetainės tunelio pridedate IPv6 prefiksą, paketas keliauja ne taip, kaip siūlo schema. Vietinis šliuzas paima visą IPv6 paketą, užšifruoja jį ir priešais padeda išorinį IP antraštę, kurios adresų šeimą lemia galinių taškų adresai, o ne tai, kas yra viduje. Nuotolinis šliuzas nuima tą išorinę antraštę ir persiunčia pirminį paketą į savo LAN, kur jis vėl yra įprastas IPv6 paketas. Išorinis tunelis ir vidinis srautas yra du atskiri pokalbiai, kurie dalijasi raktu, galinių taškų pora ir niekuo daugiau.

Dvi antraštės, dvi adresų šeimos

IPsec tunelio režime vidinis IPv6 paketas tampa naudinguoju kroviniu už ESP antraštės. Išorinė antraštė, pernešanti tą ESP paketą, gali būti IPv4 arba IPv6, ir ji seka local_addrs bei remote_addrs. WireGuard tai daro su mažiau ceremonijų: vidinis paketas yra UDP datagramos naudingasis krovinys partnerio galiniame taške. Abi palieka vidinę antraštę nepaliestą, todėl nuotolinė pusė gali jį maršrutizuoti po dekapsuliavimo.

Kelias tarp svetainių mato tik UDP 4500, kai IPsec naudoja NAT perėjimą, arba UDP 51820 numatytajam WireGuard klausytojui. Bet kuris kelyje esantis maršrutizatorius gali būti tik IPv4, o IPv6 srautas vis tiek praeina, nes tame kelyje jis niekada nepasirodo kaip IPv6 paketas. Tai duoda švarų pirmąjį skirstymą: tcpdump -ni eth0 udp port 51820 rodo užšifruotą kelią, tcpdump -ni wg0 ip6 rodo vidinį srautą. Užimtas išorinis įrašymas su tyliu vidiniu reiškia, kad branduolys neįdeda IPv6 į tunelį; tai maršrutizavimas arba politika, o ne nuorodos būsena.

Šliuzas taip pat sumažina vidinį Hop Limit persiųsdamas, todėl galiniai taškai skaičiuojami kaip maršrutizatoriai IPv6 kelyje. Išorinis šuolių skaičius ir vidinis Hop Limit juda nepriklausomai, o paketas, kuris miršta nuotoliniame šliuze, mirė persiuntime, o ne šifravime.

Parinkikliai ir AllowedIPs yra leidimų sąrašas

IKEv2 derasi, kuriuos vidinius prefiksus gali nešti child SA. strongSwan 5.9 ir vėlesnėse versijose juos įrašius swanctl.conf atrodo taip:

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

Praleidus local_ts ir remote_ts, strongSwan išveda juos iš pasirinktos sąsajos potinklių. Dual-stack mazge šis trumpinys dažnai duoda tik IPv4 porą: SA pakyla, o IPv6 atmetamas dar nepasiekus ESP kodo. Abiejų prefiksų įrašymas daro SA pajėgų juos nešti, o start_action = trap pakelia jį ties pirmuoju tinkamu paketu.

WireGuard turi vieną sąrašą, atliekantį du darbus. Partnerio bloke AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 yra ir siunčiant įdiegtas maršrutas, ir priimant taikomas filtras: iššifruotas paketas, kurio vidinis šaltinis patenka už to partnerio sąrašo ribų, tyliai išmetamas. wg-quick prideda maršrutą kiekvienam įrašui, todėl žemiau esančiam partnerio blokui nereikia atskiro ip -6 route komandos.

[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

Abu sąrašai turi būti veidrodiniai: svetainė B priima svetainės A prefiksą kaip nuotolinį parinkiklį ir maršrutizuoja jį atgal, o tunelis veikia tik tada, kai abi kryptys sutaria. Asimetrinis sąrašas duoda simptomą, kuris kainuoja daugiausia laiko — sveikas rankos paspaudimas, skaitikliai juda vienoje pusėje, ir ping iš A į B, kuris pavyksta, kol niekas iš B nepasiekia A.

Persiuntimas, maršrutai ir grąžinimo prefiksas

Linux nepersiunčia IPv6, kol nepasakysi, ir nuostata galioja kiekvienai vardų erdvei, o ne sąsajai:

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

Antroji eilutė yra ta, kurią žmonės pamiršta maršrutais grįstuose sprendimuose. Politika grįstas IPsec įdiegia prefiksus atitinkančią XFRM politiką, bet maršrutais grįsta sąranka su vti6 arba WireGuard reikalauja tikro IPv6 maršruto, nukreipto į tą įrenginį. Išsaugok sysctl po /etc/sysctl.d/; priešingu atveju perkrovimas tyliai grąžina persiuntimą į išjungtą būseną.

Persiuntimas turi šalutinį poveikį, kurį verta žinoti: branduolys tada ignoruoja maršrutizatorių skelbimus, nebent net.ipv6.conf.<wan>.accept_ra yra 2, todėl šliuzas, kurio WAN adresas ateina per SLAAC, gali prarasti numatytąjį maršrutą tą akimirką, kai įjungiate persiuntimą. Nustatykite accept_ra = 2 toje sąsajoje tame pačiame faile, ir maršrutas išlieka. Svetainės B branduolys taip pat turi išmokti 2001:db8:aa::/48 iš tunelio šliuzo, statiniu maršrutu arba maršrutizavimo protokolu tunelyje, kitaip atsakymas miršta pačioje B tinkle.

Keturių žingsnių patikra, kuri nustato lūžio vietą

Dirbkite šia tvarka ir sustokite ties pirmuoju žingsniu, kuris nepavyksta, nes kiekvienas vėlesnis žingsnis priklauso nuo ankstesnių.

  1. Parinkikliai: swanctl --list-sas turėtų rodyti IPv6 prefiksų porą child SA, o wg show wg0 allowed-ips nuotolinį prefiksą su nauju latest-handshakes.
  2. Branduolio maršrutas: ip -6 route get 2001:db8:bb::10 turi atsakyti tunelio įrenginiu, o ne WAN sąsaja.
  3. Vidinis įrašymas: tcpdump -ni wg0 ip6 pingant tarp tikrų LAN mazgų. Išeinantys, bet negrįžtantys paketai rodo į B maršrutą arba užkardą; visiškai jokių paketų rodo atgal į 1 arba 2 žingsnį.
  4. Paskirties vieta: B mazge ss -6 -ltn patvirtina, kad paslauga klausosi IPv6, o vietiniai užkardos skaitikliai rodo, ar paketas buvo priimtas, ar išmestas.

MTU patenka į tą patį etapą. IPv6 maršrutizatoriai nedalija, todėl per didelis paketas išmetamas ir Packet Too Big grįžta siuntėjui. Jei rankos paspaudimai ir maži pingai veikia, bet failo perdavimas stringa, sumažinkite naudingąjį krovinį, kol jis praeis: ping -6 -s 1400 -c 3 2001:db8:bb::10. WireGuard sąsajų numatytasis MTU yra 1420 baitų, o IPsec per IPv4 atima daugiau, todėl vidinio MTU nustatymas geriau nei viltis dėl kelio MTU aptikimo per užkardą, kuri išmeta ICMPv6.

Gedimų būsenos, kurios atrodo kaip užkardos problemos

Dažniausia visai ne užkarda: paslauga prisiriša prie 0.0.0.0 vietoj ::, AAAA įrašas egzistuoja, ir klientas gauna greitą atmetimą per IPv6, kurį dual-stack naršyklė nuslepia grįždama prie IPv4. Jei nepavyksta tik kai kurios programos, patikrinkite klausymosi šeimą prieš liesdami taisyklių rinkinį.

Antroji yra ICMPv6 filtravimas. Neighbor Discovery ir Packet Too Big yra įprasto darbo dalis, o ne diagnostika, ir politika, išmetanti visą ICMPv6, sukuria tunelį, kuris prisijungia, autentifikuojasi ir tada stringa ties viskuo didesniu už mažą paketą. Leiskite tipus, nuo kurių priklauso kelias, ir palikite skaitiklius įjungtus, kad išmetimas būtų matomas.

Trečioji yra prefiksas, pridedamas prie tunelio, bet niekada prie jį valdančios svetainės adresų plano, todėl joks maršrutizatorius jo neskelbia ir joks mazgas negali iš jo atsakyti. Pradėkite nuo vieno prefikso ir vienos mazgų poros, įrodykite abi kryptis keturiais žingsniais, tada pridėkite likusią dalį; sulaužytas prefiksas lieka viena eilute konfigūracijoje, o ne perdarymas. Vienintelė oficiali nuoroda, kurią verta laikyti atidarytą, yra RFC 8200, kuri apibrėžia antraštę, kurią tunelis neša.

Susiję straipsniai