Дэлегацыя прэфікса IPv6 праз VPN паміж сайтамі: кантрольны спіс
Праверкі для маршрутызацыі дэлегаванага прэфікса IPv6 праз VPN паміж сайтамі: карта прэфіксаў, селектары трафіку, перадача, MTU, зваротны шлях і перанумараванне.
Падняць тунель — гэта лёгкая палова. Я бачыў, як сувязь паміж сайтамі трымалася ўзнятай цэлымі днямі, пакуль кожны хост у далёкай LAN атрымліваў у адказ цішыню, бо дэлегаваны прэфікс за гэтым шлюзам быў наладжаны на інтэрфейсе, але ніколі не маршрутызаваўся ў тунель. Адрасы тунеля ўвесь гэты час адказвалі на пінгі, і менавіта таму ніхто не глядзеў на прэфікс. Вось парадак, які я правяраю, калі дэлегаваны прэфікс IPv6 павінен перасекчы сайтавы VPN: карта прэфіксаў, селектары трафіку, перадача і міжсеткавы экран, затым зваротны шлях.
Запішыце карту прэфіксаў, перш чым кранаць тунель
Дэлегацыя прэфікса перадае блок маршрутызатару, які яго запытаў. Яна не ўсталёўвае маршрут на партнёры, не пашырае гэты блок на звёне і не паведамляе далёкаму шлюзу, што знаходзіцца за маршрутызатарам-запытчыкам. Гэтыя тры рэчы наладжваеце вы, і іх месца — у плане адрасацыі, перш чым зменіцца хоць адзін файл канфігурацыі.
Для кожнага сайта запішыце дэлегаваны прэфікс, /64, які фактычна выкарыстоўваецца ў LAN, адрасы тунеля і ўладальніка кожнага маршруту. Правайдэр дэлегуе 2001:db8:a1::/56 сайту A, які абслугоўвае 2001:db8:a1:10::/64 у сваёй LAN; сайт B захоўвае 2001:db8:b2::/64. Калі сайт A абслугоўвае толькі гэтую адну /64, абодва бакі павінны называць 2001:db8:a1:10::/64, а не ўвесь /56.
Дзве памылкі з'яўляюцца амаль кожны раз. Першая — ставіцца да далёкага прэфікса як да знаходзячагася на звёне: злучаць яго мастом ці змяшчаць на інтэрфейс тунеля, каб шлюз адказваў на запыт суседа для хастоў, да якіх не можа дабрацца. Другая — аб'яўляць увесь /56, калі наладжана толькі адна /64: табліца маршрутаў сцвярджае, што блок дасяжны, а большасць адрасоў правальваецца ў чорную дзірку.
Узгадніце селектары трафіку абодвух бакоў з маршрутамі
IKEv2 і WireGuard абодва адмаўляюць неадпаведны трафік, дастаткова ціха, каб тунель усё яшчэ выглядаў здаровым.
У strongSwan селектары выразныя. На сайце A:
conn a-to-b
left=2001:db8:ff::1
leftsubnet=2001:db8:a1:10::/64
right=2001:db8:ff::2
rightsubnet=2001:db8:b2::/64
auto=startconn сайта B люстэркава паўтарае дзве падсеткі. Калі яны не супадаюць, рэспандэр адхіляе CHILD_SA з TS_UNACCEPTABLE, таму дачэрняя SA ніколі не ўзнімаецца, хоць IKE_SA ўзнялася. На абодвух баках наладжаная падсетка павінна раўняцца таму, што лакальнае ядро маршрутызуе ў тунель.
WireGuard носіць тую ж інфармацыю ў AllowedIPs, з адной асаблівасцю: AllowedIPs — гэта фільтр крыніцы пры прыёме і адначасова маршрут пры адпраўцы. Калі запіс партнёра сайта B для сайта A не ўтрымлівае 2001:db8:a1:10::/64, пакеты з сайта A прыходзяць па валіднай рукапацісканні і адкідваюцца як недазволеныя. Гэта стварае знаёмы ўзор: рукапацісканне ўвесь час аднаўляецца, а адказ так і не выходзіць. Параўнайце абодва бакі з wg show wg0 allowed-ips. Пераправярайце гэты спіс кожны раз, калі дэлегацыя змяняецца; састарэлая /64 трымае сеанс узнятым, а новы прэфікс недасяжным.
Спачатку выключыце перадачу, міжсеткавы экран і MTU
Перш чым чытаць яшчэ адзін радок журнала, пераканайцеся, што шлюзы наогул перадаюць трафік. sysctl net.ipv6.conf.all.forwarding павінен вярнуць 1 на абодвух, ужыты таксама да інтэрфейсаў тунеля і LAN. Разам з гэтым прыходзіць пастка: калі перадача ўключана, інтэрфейс з accept_ra=1 перастае прымаць аб'явы маршрутызатара ад правайдэра, таму скрынка можа страціць вышэйшы маршрут па змаўчанні, маршрутызуючы ідэальна ўнутры тунеля. Усталюйце accept_ra=2 там, дзе RA правайдэра ўсё яшчэ патрэбна.
Затым правілы міжсеткавага экрана павінны дазваляць прэфікс у абодвух кірунках, а ICMPv6 павінен выжыць: выяўленне суседзяў, пакет-занадта-вялікі і недасяжная прызначэнне не з'яўляюцца апцыянальнымі. Адкіньце іх — і выяўленне MTU шляху ламаецца, даючы злучэнні, якія адкрываюцца і потым затыкаюцца на першым вялікім адказе. Мінімальная пара правілаў выглядае так:
nft add rule inet filter forward ip6 saddr 2001:db8:a1:10::/64 ip6 daddr 2001:db8:b2::/64 accept
nft add rule inet filter forward ip6 saddr 2001:db8:b2::/64 ip6 daddr 2001:db8:a1:10::/64 accept
nft add rule inet filter forward icmpv6 type { packet-too-big, nd-neighbor-solicit, nd-neighbor-advert } acceptMTU стаіць за гэтым. Тунель паменшвае карысны MTU ніжэй за 1500, а IPv6 патрабуе, каб кожнае звёно несла мінімум 1280. Малыя пінгі праходзяць, сеанс SSH замярзае на вялікім усплёску, а /proc/net/snmp6 паказвае паведамленні пакет-занадта-вялікі, якія ніколі не вяртаюцца. Усталюйце MTU тунеля яўна або абмяжуйце TCP MSS у табліцы mangle і дазвольце вярнуцца ICMPv6, які паведамляе пра меншы MTU.
Правярайце зваротны шлях, а не адрас тунеля
Збой, які каштуе найбольш часу, — аднабаковая маршрутызацыя. Кожны шлюз маршрутызуе далёкі прэфікс у тунель, але хасты адказваюць праз уласны шлюз па змаўчанні, бо менавіта там жыве іх /64. Даставіць пакет да прызначэння — гэта палова шляху.
| What you see | Likely cause | First check |
|---|---|---|
| Tunnel up, every host silent | remote prefix not routed into the tunnel | ip -6 route get on both gateways |
| Handshake renews, no replies | source prefix missing from selectors or AllowedIPs | ipsec statusall, wg show allowed-ips |
| Small pings pass, transfers stall | MTU or ICMPv6 packet-too-big filtered | /proc/net/snmp6 counters |
| Old prefix still works | stale /64 left in routes or selectors | delegation lease and route table |
Дзве каманды вырашаюць большасць выпадкаў. На сайце A ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 паказвае, які інтэрфейс выкарыстаў бы адказ з гэтай крыніцы; выканайце люстэркавую праверку на сайце B. Затым згенеруйце трафік з хоста, а не са шлюза, і параўнайце лічыльнікі на абодвух баках.
Калі запыт суседа для далёкага прэфікса з'яўляецца ў тунелі, гэты прэфікс знаходзіцца на звёне там, дзе яго быць не павінна; выпраўце гэта, перш чым карэктаваць маршруты. Proxy NDP пакрывае выпадкі, дзе маставанне сапраўды патрэбна, і не з'яўляецца заменай маршруту.
Плануйце змену прэфікса пад вамі
Дэлегацыя прэфікса — гэта арэнда паміж маршрутызатарам, які дэлегуе, і маршрутызатарам-запытчыкам, і працяг арэнды можа вярнуць іншы блок: іншы /56 пасля міграцыі правайдэра ці карацейшую арэнду, чым час, на які ўзняты тунель. Кожнае месца, якое называе стары прэфікс, састарэе адначасова: маршруты, селектары, AllowedIPs, правілы міжсеткавага экрана, запісы DNS і любы маніторынг, які жорстка кадуе літаральныя адрасы. Паток паведамленняў апісаны ў RFC 8415.
Там, дзе чакаецца зрух прэфікса, трымайце ўнутраны план адрасацыі, які ад яго не залежыць, і перакладайце на мяжы. NPTv6 — гэта варыянт без стану, і ён захоўвае ўнутраную палітыку чытэльнай, але гэта трансляцыя прэфіксаў, а не чароўны пласт: межы /64 павінны супадаць, кантрольныя сумы карэктуюцца, а праграмы, якія ўбудоўваюць літаральныя адрасы, усё роўна ламаюцца. Калі вы трымаеце адрасы правайдэра ад пачатку да канца, запішыце паводзіны арэнды і працэдуру змен у план адрасацыі.
Скончыце тэстам, які вытрывае час: дазволены хост у кожнай LAN дасягае сэрвісу ў іншай LAN, адказ вяртаецца праз тунель, і тая ж пара ўсё яшчэ працуе пасля перазапуску тунеля і працягу дэлегацыі. Калі апошняя частка не ўдаецца, дызайн залежыць ад стану, які не пражыве тыдзень.