Рутирање на 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, која го дефинира заглавјето што го носи тунелот.

Поврзани статии