Рутирање IPv6 између два локалитета преко постојећег VPN-а

WAN само са IPv4 и даље може преносити унутрашњи IPv6. Пратите селекторе, кернел руте, прослеђивање и повратни префикс који тихо одбацује одговоре.

Када додате IPv6 префикс у тунел између локалитета, пакет не путује онако како дијаграм сугерише. Локални гејтвеј узима цео IPv6 пакет, шифрује га и испред ставља спољни IP заглавље чију фамилију адреса одређују адресе крајњих тачака, а не оно што је унутра. Удаљени гејтвеј уклања то спољно заглавље и прослеђује изворни пакет на свој LAN, где је опет обичан IPv6 пакет. Спољни тунел и унутрашњи саобраћај два су одвојена разговора која деле кључ, пар крајњих тачака и ништа друго.

Два заглавља, две фамилије адреса

У IPsec режиму тунела унутрашњи IPv6 пакет постаје терет иза ESP заглавља. Спољно заглавље које носи тај ESP пакет може бити IPv4 или IPv6 и следи local_addrs и remote_addrs. WireGuard чини исто са мање церемоније: унутрашњи пакет је терет UDP датаграма ка крајњој тачки партнера. Оба остављају унутрашње заглавље нетакнутим, због чега га удаљена страна може рутирати након декапсулације.

Пут између локалитета види само UDP 4500 када IPsec користи NAT пролаз, или UDP 51820 за подразумевани WireGuard ослушкивач. Сваки рутер на путу може бити само IPv4 и IPv6 саобраћај ипак пролази, јер се на том путу никада не појављује као IPv6 пакет. То даје чисту прву поделу: tcpdump -ni eth0 udp port 51820 приказује шифровани пут, tcpdump -ni wg0 ip6 приказује унутрашњи саобраћај. Заузето спољно снимање са тихим унутрашњим значи да кернел не ставља IPv6 у тунел; то је рутирање или политика, а не стање везе.

Гејтвеј такође смањује унутрашњи Hop Limit док прослеђује, па се крајње тачке рачунају као рутери на IPv6 путу. Спољни број скокова и унутрашњи Hop Limit крећу се независно, а пакет који умре на удаљеном гејтвеју умро је у прослеђивању, не у шифровању.

Селектори и AllowedIPs су списак дозвола

IKEv2 преговара које унутрашње префиксе child SA сме да носи. На strongSwan 5.9 и новијим њихово исписивање у swanctl.conf изгледа овако:

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

Ако изоставите local_ts и remote_ts, strongSwan их изводи из подмрежа интерфејса који одабере. На dual-stack домаћину та кратица често даје пар само IPv4: SA се подигне и IPv6 се одбија пре него што стигне до ESP кода. Исписивање оба префикса чини SA способним да их носи, а start_action = trap подиже га на првом одговарајућем пакету.

WireGuard има једну листу која обавља два посла. У блоку партнера AllowedIPs = 2001:db8:bb::/48, fd00:bb::/48 је и рута инсталирана при слању и филтер примењен при пријему: дешифровани пакет чији унутрашњи извор падне изван листе тог партнера тихо се одбацује. wg-quick додаје руту по уносу, па блок партнера испод не треба засебну ip -6 route наредбу.

[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

Обе листе морају бити зрцалне: локалитет B прихвата префикс локалитета A као удаљени селектор и рутира га назад, а тунел ради само кад се два смера слажу. Асиметрична листа даје симптом који троши највише времена — здрав стисак руке, бројачи се крећу на једној страни, и пинг од A до B који успева док ништа из B не долази до A.

Прослеђивање, руте и повратни префикс

Linux не прослеђује IPv6 док не кажете, а подешавање важи по namespace-у, а не по интерфејсу:

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

Други ред је онај који људи забораве у дизајнима заснованим на рутама. IPsec заснован на политици инсталира XFRM политику која одговара префиксима, али поставка заснована на рутама са vti6 или WireGuard-ом треба стварну IPv6 руту која показује на тај уређај. Сачувајте sysctl под /etc/sysctl.d/; иначе подизање изнова тихо враћа прослеђивање у искључено стање.

Прослеђивање има нуспојаву коју вреди знати: кернел тада игнорише најаве рутера осим ако net.ipv6.conf.<wan>.accept_ra није 2, па гејтвеј чија WAN адреса долази преко SLAAC-а може изгубити подразумевану руту у тренутку кад укључите прослеђивање. Поставите accept_ra = 2 на том интерфејсу у истој датотеци и рута преживљава. Језгро локалитета B такође мора научити 2001:db8:aa::/48 од гејтвеја тунела, статичном рутом или протоколом рутирања над тунелом, иначе одговор умире унутар мреже самог B.

Провера у четири корака која лоцира прекид

Радите овим редом и станите на првом кораку који закаже, јер сваки каснији корак зависи од претходних.

  1. Селектори: swanctl --list-sas би требало да покаже пар IPv6 префикса на child SA, или wg show wg0 allowed-ips удаљени префикс са свежим latest-handshakes.
  2. Кернел рута: ip -6 route get 2001:db8:bb::10 мора одговорити уређајем тунела, а не WAN интерфејсом.
  3. Унутрашње снимање: tcpdump -ni wg0 ip6 док пингујете између правих LAN домаћина. Пакети који излазе, али ниједан се не враћа, упућују на руту или заштитни зид B; посве никакви пакети упућују назад на корак 1 или 2.
  4. Одредиште: на домаћину B ss -6 -ltn потврђује да услуга ослушкује на IPv6, а локални бројачи заштитног зида показују је ли пакет прихваћен или одбачен.

MTU припада истом пролазу. IPv6 рутери не фрагментирају, па се превелики пакет одбацује и Packet Too Big се враћа пошиљаоцу. Ако стисци руке и мали пингови раде, али пренос датотеке запне, смањите терет док не прође: ping -6 -s 1400 -c 3 2001:db8:bb::10. Интерфејси WireGuard подразумевано имају MTU од 1420 бајтова, а IPsec над IPv4 одузима више, па је постављање унутрашњег MTU-а боље од наде у откривање MTU-а пута кроз заштитни зид који одбацује ICMPv6.

Начини квара који изгледају као проблеми са заштитним зидом

Најчешћи уопште није заштитни зид: услуга се везује на 0.0.0.0 уместо на ::, AAAA запис постоји, а клијент добија брзо одбијање преко IPv6 које dual-stack прегледач крије враћањем на IPv4. Ако закажу само неке апликације, проверите фамилију ослушкивања пре него што дирате скуп правила.

Други је филтрирање ICMPv6. Neighbor Discovery и Packet Too Big део су нормалног рада, а не дијагностике, и политика која одбацује сав ICMPv6 ствара тунел који се споји, овери и затим запне на свему већем од малог пакета. Дозволите врсте од којих пут зависи и оставите бројаче укључене да одбацивање буде видљиво.

Трећи је префикс додат тунелу, али никада у адресни план локалитета који га поседује, па га ниједан рутер не најављује и ниједан домаћин не може одговорити из њега. Почните с једним префиксом и једним паром домаћина, докажите оба смера с четири корака, па додајте остатак; покварен префикс остаје један ред у конфигурацији уместо прераде. Једина службена референца коју вреди држати отвореном је RFC 8200, која дефинише заглавље које тунел носи.

Повезани чланци