Делегирање IPv6 префикса кроз VPN између локација: контролна листа
Провере рутирања делегираног IPv6 префикса кроз VPN између локација: мапа префикса, селектори саобраћаја, прослеђивање, MTU, повратни пут и пренумерација.
Подизање тунела је лакша половина. Видео сам везу између локација која је данима остајала успостављена, док је сваки домаћин на удаљеном LAN-у добијао само тишину, зато што је делегирани префикс иза тог гејтвеја био конфигуриран на интерфејсу, али никада није био рутиран у тунел. Адресе тунела су све време одговарале на пинг, и управо зато нико није гледао префикс. Ево редоследа који проверавам када делегирани IPv6 префикс треба да прође кроз VPN локације: мапа префикса, селектори саобраћаја, прослеђивање и заштитни зид, а затим повратни пут.
Прво напиши мапу префикса, па онда дирај тунел
Делегирање префикса даје блок оном рутеру који га је затражио. Оно не инсталира руту на партнеру, не проширује тај блок као on-link и не говори удаљеном гејтвеју шта се налази иза рутера који тражи. Ове три ствари подешавате сами, и оне припадају плану адреса пре него што се промени било која конфигурациона датотека.
За сваку локацију забележите делегирани префикс, /64 који се стварно користи у LAN-у, адресе тунела и власника сваке руте. Провајдер делегира 2001:db8:a1::/56 локацији A, која у свом LAN-у сервира 2001:db8:a1:10::/64; локација B задржава 2001:db8:b2::/64. Ако локација A сервира само тај један /64, оба краја треба да наведу 2001:db8:a1:10::/64 уместо целог /56.
Скоро увек се појаве две грешке. Једна је третирати удаљени префикс као on-link, премостити га или ставити на интерфејс тунела, па гејтвеј одговара на суседни захтев за домаћине које не може да достигне. Друга је оглашавати цео /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, па child SA никада не устане иако је IKE_SA устао. На обе стране конфигурисана подмрежа мора да буде једнака ономе што локално језгро рутира ка тунелу.
WireGuard носи исте информације у AllowedIPs, са једним обртом: AllowedIPs је филтер извора при пријему и рута при слању. Ако peer запис локације B за локацију A изостави 2001:db8:a1:10::/64, пакети са локације A долазе на важећем handshake-у и бивају одбачени као недозвољени. Тако настаје познати образац handshake-а који се стално обнавља док одговор никада не излази. Упоредите оба краја са wg show wg0 allowed-ips. Поново проверите ту листу сваки пут када се делегирање промени; застарео /64 држи сесију живом и нови префикс чини недоступним.
Прво искључи прослеђивање, заштитни зид и MTU
Пре него што прочитате још једну линију дневника, потврдите да гејтвеји уопште прослеђују. sysctl net.ipv6.conf.all.forwarding мора да врати 1 на оба, примењено и на интерфејсе тунела и LAN-а. Прати једна замка: када је прослеђивање укључено, интерфејс са accept_ra=1 престаје да прима огласе рутера од провајдера, па машина може да изгуби узводну подразумевану руту иако у тунелу рутира беспрекорно. Поставите accept_ra=2 тамо где је RA провајдера још потребан.
Затим правила заштитног зида морају да дозволе префикс у оба смера, а 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 } acceptMTU стоји иза овога. Тунел смањује употребљиви MTU испод 1500, а IPv6 захтева да свака веза носи најмање 1280. Мали пингови пролазе, SSH сесија се замрзне на великом налету, а /proc/net/snmp6 показује packet-too-big поруке које се никада не враћају. Поставите 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. Затим генеришите саобраћај са домаћина, а не са гејтвеја, и упоредите бројаче на оба краја.
Ако се суседни захтев за удаљени префикс појави на тунелу, тај префикс је on-link негде где не би требало да буде; поправите то пре подешавања рута. Proxy NDP покрива случајеве када је премошћавање заиста потребно, а не замењује руту.
Планирај промену префикса под собом
Делегирање префикса је закуп између рутера који делегира и оног који тражи, а обнављање може да врати други блок: други /56 после миграције провајдера или краћи закуп од времена колико тунел стоји. Свако место које именује стари префикс застарева одједном: руте, селектори, AllowedIPs, правила заштитног зида, DNS записи и свако надгледање које уграђује буквалне адресе. Ток порука је у RFC 8415.
Где се очекује да се префикс помери, држите интерни план адреса који не зависи од њега и преводите на граници. NPTv6 је опција без стања и одржава интерну политику читљивом, али то је превод префикса, не магични слој: границе /64 морају да се поклопе, контролне суме се прилагођавају, а апликације које уграђују буквалне адресе и даље се кваре. Ако чувате адресе провајдера од краја до краја, запишите понашање закупа и поступак промене у план адреса.
Завршите тестом који издржава време: дозвољени домаћин у сваком LAN-у достиже услугу у другом LAN-у, одговор се враћа кроз тунел, и исти пар и даље ради после поновног покретања тунела и обнављања делегирања. Ако последњи део не успе, дизајн зависи од стања које неће преживети недељу.