Сайттар арасындагы VPN аркылуу IPv6 префиксин делегациялоо: текшерүү тизмеси

Туннелди көтөрүү — оңой жарымы. Сайттар арасындагы байланыш күнү бою орнотулган бойдон турганын, бирок алыскы LANдагы ар бир хост үнсүздүк алганын көргөм, анткени ал шлюздун артындагы делегацияланган префикс интерфейске конфигурацияланган, бирок туннелге эч качан маршрутталган эмес. Туннел даректери ошол убакта pingге жооп берип турган, ошондуктан эч ким префикске көңүл бурган эмес. Делегацияланган IPv6 префикси сайт VPN аркылуу өтүшү керек болгондо мен текшере турган тартип: префикс картасы, трафик селекторлору, форвардинг жана firewall, анан кайтуу жолу.

Туннелге тийүүдөн мурун префикс картасын жаз

Префикс делегациясы блокту аны сураган маршрутизаторго берет. Ал теңтушка маршрут орнотпойт, бул блокту on-link кеңейтпейт жана сураган маршрутизатордун артында эмне бар экенин алыскы шлюзга айтпайт. Бул үчөөнү өзүңүз конфигурациялашыңыз керек жана алар кандайдыр бир конфиг файлы өзгөргөнгө чейин дарек планында болушу керек.

Ар бир сайт үчүн делегацияланган префиксти, LANда чындап колдонулган /64тү, туннел даректерин жана ар бир маршруттун ээсин жазып алыңыз. Провайдер A сайтына 2001:db8:a1::/56ны делегациялайт, ал өз LANында 2001:db8:a1:10::/64тү тейлейт; B сайты 2001:db8:b2::/64тү сактайт. Эгер A сайты ушул бир /64тү гана тейлесе, эки учу тең бүт /56ны эмес, 2001:db8:a1:10::/64тү аташы керек.

Эки ката дээрлик ар дайым көрүнөт. Бири — алыскы префиксти on-link деп эсептөө, аны bridge кылуу же туннел интерфейсине коюу, ошентип шлюз жете албаган хосттор үчүн кошуна сурамжылоосуна жооп берет. Экинчиси — бир гана /64 конфигурацияланганда бүт /56ны жарнамалоо: маршрут таблицасы блокко жетүүгө болот деп эсептейт, ал эми даректердин көбү кара көңдөйгө түшөт.

Эки учтун тең трафик селекторлорун маршруттарга шайкеш келтир

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=start

B сайтынын conn жазуусу эки ички тармакты чагылдырат. Алар макулдашпаса, жооп берүүчү CHILD_SAны TS_UNACCEPTABLE менен четке кагат, ошондуктан IKE_SA көтөрүлсө да child SA эч качан көтөрүлбөйт. Эки тарапта тең конфигурацияланган ички тармак жергиликтүү kernel туннелге карай маршруттаганга барабар болушу керек.

WireGuard ушул эле маалыматты AllowedIPs ичинде алып жүрөт, бир өзгөчөлүк менен: AllowedIPs кабыл алуудагы булак фильтри жана жөнөтүүдөгү маршрут. Эгер B сайтынын A сайтына арналган peer жазуусу 2001:db8:a1:10::/64тү өткөрүп жиберсе, A сайтынан келген пакеттер жарактуу handshake менен келип, уруксат берилбеген деп ташталат. Ошондон тааныш схема келип чыгат: handshake тынымсыз жаңыртылат, бирок жооп эч качан чыкпайт. Эки учту wg show wg0 allowed-ips менен салыштыр. Делегация өзгөргөн сайын ошол тизмени кайра текшер; эскирген /64 сессияны тирүү кармап, жаңы префиксти жеткиликсиз кылат.

Алгач форвардингди, firewallды жана MTUну жокко чыгар

Кийинки журнал сапты окуудан мурун шлюздар жалпысынан форварддайбы деп ыраста. sysctl net.ipv6.conf.all.forwarding экөөндө тең 1ди кайтарышы керек, туннел жана LAN интерфейстерине да колдонулат. Бир тузак коштолот: форвардинг күйгүзүлгөндөн кийин accept_ra=1 интерфейси провайдердин маршрутизатор жарнамаларын кабыл алууну токтотот, ошондуктан түзмөк туннелдин ичинде мыкты маршруттап турса да, жогорку агымдагы демейки маршрутун жоготушу мүмкүн. Провайдердин RA дагы керек болгон жерде accept_ra=2 орнот.

Андан кийин firewall эрежелери префиксти эки багытта уруксат бериши керек, ал эми ICMPv6 аман калышы керек: кошуна издөө, packet-too-big жана destination-unreachable милдеттүү. Аларды таштасаң, жолдун 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 } accept

MTU ушунун артында турат. Туннел колдонулуучу MTUну 1500дөн төмөн кысат, ал эми IPv6 ар бир байланыш кеминде 1280ди ташуусун талап кылат. Кичине pingдер өтөт, SSH сессиясы чоң агымда тоңуп калат жана /proc/net/snmp6 эч качан кайтпаган packet-too-big билдирүүлөрүн көрсөтөт. Туннелдин MTUсун ачык орнот же mangle таблицасында TCP MSSди чекте жана кичирээк MTU тууралуу билдирген ICMPv6га кайтууга жол бер.

Туннел дарегин эмес, кайтуу жолун сынап көр

Эң көп убакытты алган бузулуу — бир багыттуу маршруттоо. Ар бир шлюз алыскы префиксти туннелге маршруттайт, бирок хосттор өздөрүнүн демейки шлюзу аркылуу жооп берет, анткени алардын /64ү ошол жерде турат. Пакетти барар жерине жеткирүү — жолдун жарымы.

Эки команда көбүн чечет. A сайтында ip -6 route get 2001:db8:b2::53 from 2001:db8:a1:10::5 ошол булактан келген жооп кайсы интерфейсти колдоноорун көрсөтөт; B сайтында күзгүдөй текшерүүнү жүргүз. Андан кийин трафикти шлюзден эмес, хосттон жаратып, эки учтагы эсептегичтерди салыштыр.

Эгер алыскы префикске арналган кошуна сурамжылоосу туннелде көрүнсө, ал префикс болбошу керек жерде on-link болуп турат; аны маршруттарды оңдоодон мурун оңдо. Proxy NDP көпүрө чындап эле керек болгон учурларды камтыйт, маршруттун ордун баспайт.

Префикс астыңда өзгөрөрүн планда

Префикс делегациясы делегациялаган жана сураган маршрутизаторлордун ортосундагы ижара келишими, ал эми жаңыртуу башка блокту кайтарышы мүмкүн: провайдер көчкөндөн кийин башка /56 же туннел турган убакыттан кыскараак ижара. Эски префиксти атаган ар бир жер бирден эскирет: маршруттар, селекторлор, AllowedIPs, firewall эрежелери, DNS жазуулары жана литерал даректерди катырып жазган ар кандай мониторинг. Билдирүү агымы RFC 8415 ичинде.

Префикс жылышы күтүлсө, ага көз каранды эмес ички дарек планын сакта жана чек арада котор. NPTv6 — абалсыз вариант, ички саясатты окула турган бойдон сактайт, бирок бул префикс которуусу, сыйкырдуу катмар эмес: /64 чек аралары дал келиши керек, текшерүү суммалары оңдолот, ал эми литерал даректерди камтыган колдонмолор баары бир бузулат. Эгер провайдердин даректерин учтан учка чейин сактасаң, ижаранын жүрүм-турумун жана өзгөртүү процедурасын дарек планына жаз.

Убакытка туруштук бере турган тест менен аякта: ар бир LANдагы уруксат берилген хост экинчи LANдагы кызматка жетет, жооп туннел аркылуу кайтат жана ошол эле жуп туннел кайра иштетилгенден жана делегация жаңыртылгандан кийин да иштейт. Эгер акыркы бөлүк ишке ашпаса, долбоор аптага чыдабай турган абалга көз каранды.