Сайттар арасындағы VPN арқылы IPv6 префиксін делегациялау: тексеру тізімі
Делегацияланған IPv6 префиксін сайттар арасындағы VPN арқылы маршруттау тексерістері: префикс картасы, трафик селекторлары, форвардинг, MTU, қайту жолы және қайта нөмірлеу.
Туннельді көтеру — оңай жартысы. Сайттар арасындағы байланыс күндер бойы орнатылған күйде тұрғанын, бірақ алыстағы 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=startB сайтының 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 } acceptMTU осының артында тұр. Туннель қолданылатын MTU-ды 1500-нен төмен қысады, ал IPv6 әрбір байланыс кемінде 1280 тасымалдауын талап етеді. Кішкене ping-дер өтеді, SSH сессиясы үлкен ағында қатып қалады және /proc/net/snmp6 ешқашан қайтпайтын packet-too-big хабарламаларын көрсетеді. Туннель MTU-ын анық орнат немесе mangle кестесінде TCP MSS-ті шекте және кішірек MTU туралы хабарлайтын ICMPv6-ға қайтуға мүмкіндік бер.
Туннель мекенжайын емес, қайту жолын сына
Ең көп уақытты алатын ақау — бір бағытты маршруттау. Әрбір шлюз алыстағы префиксті туннельге маршруттайды, бірақ хосттар өздерінің әдепкі шлюзі арқылы жауап береді, өйткені олардың /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, firewall ережелері, DNS жазбалары және литерал мекенжайларды қатырып жазған кез келген мониторинг. Хабарлама ағыны RFC 8415 ішінде.
Префикс жылжиды деп күтілсе, оған тәуелді емес ішкі мекенжай жоспарын ұста және шекарада аудар. NPTv6 — күйсіз нұсқа, ішкі саясатты оқылатын күйде ұстайды, бірақ бұл префикс аудармасы, сиқырлы қабат емес: /64 шекаралары сәйкесуі керек, бақылау сомалары түзетіледі, ал литерал мекенжайларды ендірген қолданбалар бәрібір сынады. Провайдер мекенжайларын ұштан ұшқа дейін сақтасаң, жалдау мінез-құлқы мен өзгерту рәсімін мекенжай жоспарына жаз.
Уақытқа төтеп беретін сынақпен аяқта: әрбір LAN-дағы рұқсат етілген хост екінші LAN-дағы қызметке жетеді, жауап туннель арқылы қайтады және сол жұп туннель қайта іске қосылған соң әрі делегация жаңарған соң да жұмыс істейді. Егер соңғы бөлік сәтсіз болса, жоба аптаға шыдамайтын күйге тәуелді.