Екі uplink fe80::1 мекенжайын бөліскендегі IPv6 саясат маршруттауы

Сізде екі uplink бар және ip -6 route show екеуінде де бірдей келесі секірімді шығарады: default via fe80::1 dev uplink0 және default via fe80::1 dev uplink1. Бұл қайталанған мекенжай қақтығысы емес, ал жалаң келесі секірімді fe80::1 саясат кестесіне көшіру ядроға қай байланыс желісін меңзегеніңізді айтпайды. Нақты сұрақ белгіден тар: екінші кестеге бір байланыс желісі керек пе әлде екеуі ме, және қайта жүктеуден кейін бұл маршруттарды не тірі ұстайды. Кезекпен тексерілетін үш шарт оның көбін шешеді.

Бірдей fe80::1 — екі түрлі көрші

Байланыс-жергілікті мекенжайлар бір байланыс желісімен шектеледі, сондықтан fe80::1 екі рет басылған бір мекенжай емес; бұл кездейсоқ бірдей жұрнақты бөлісетін екі көрші. Аймақ индексі — хост қайсысын меңзеп тұрғанын айтатын тәсіл, сондықтан fe80::1%uplink0 мен fe80::1%uplink1 ядро үшін әртүрлі межелер, және бұл жұрнақ ешқашан қашықтағы маршрутизаторға жетпейді. RFC 4007 осының артындағы аймақ моделін сипаттайды, сондықтан саясат кестесі әрбір байланыс-жергілікті келесі секіріммен бірге құрылғыны алып жүруі керек.

Бір хосттан сандық аймақ ID-ін үлгіге көшіретін VPN конфигурация генераторы жергілікті контексті мекенжайдың бөлігі ретінде қарастырады, және ол жазатын файл интерфейс атаулары немесе индекстері өзгеше әр машинада қате. Саясат кестесі де екі байланыс желісін біріктірмейді: маршрутталған VPN желілер арасында пакеттерді өткізеді, бірақ қашықтағы Ethernet көршісінің байланыс-жергілікті идентитігін туннель арқылы алып өтпейді, сондықтан байланыс-жергілікті трафик өз байланыс желісінде қалады.

Құрылғыны алып тастаңыз, маршрут жазылмайтын болады. ip -6 route add default via fe80::1 table 200 шлюзді шеше алмайды, ал iproute2 оны Error: Nexthop has invalid gateway.-пен қабылдамайды; dev uplink0 қосыңыз, команда сәтті орындалады, өйткені құрылғы келесі секірімді сол екі көршінің біріне бекітеді. Құрылғы айта алмайтын нәрсе — uplink0 осы кесте үшін дұрыс байланыс желісі ме, ал басқа хосттан көшірілген маршрут сол хосттың интерфейс атауларын бірге алып келеді, нақты қателер сондан басталады.

Бірінші шарт: кестеде бір байланыс желісі ме әлде екеу ме

Екінші uplink не үшін екенінен бастаңыз. Егер екі байланыс желісі бірдей трафикті тасыса және біреуі резервте болса, балама кесте екі шлюзді де әртүрлі метрикамен ұстауы керек: бірдей межелер, бір таңдаулы жол, бір айқын екінші таңдау. Егер uplink-тер әртүрлі трафик әртүрлі провайдерлер арқылы шығуы үшін, немесе бұл бөлінген туннель болып, кейбір трафик VPN-ды айналып өтіп, қалғаны іште қалатын болса, екі байланыс желісі бір кестеге мүлде тиесілі емес. Олар ережемен таңдалатын екі кестеге тиесілі, және ереже кестені таңдайды, туннельді емес: айналып өтетін трафик маршруттауға дейін таңбаланады, және дәл сол таңба оны екінші кестеге жібереді.

Осы екінші жағдайда ереже кестеге қашан жүгінетінін шешеді, ал маршрут жүгінгеннен кейін пакеттің қайда кететінін шешеді:

ip -6 rule add fwmark 0x2 table 201
ip -6 route add default via fe80::1 dev uplink1 metric 100 table 201
ip -6 route add 2001:db8:100::/48 dev uplink1 metric 100 table 201
ip -6 route show table 201

Екі нысанның ешқайсысы екіншісін алмастырмайды, және тек әдепкісі бар кесте де өз шлюзін шешуде сәтсіздікке ұшырауы мүмкін. Егер қосу қабылданбаса, немесе маршрут бар болса да пайдалануға жарамсыз болса, сол интерфейстің қосылған префиксін сол кестеге салыңыз, немесе бұл префикс басқа жерде маршрутталғанда секірімді onlink деп белгілеңіз. Жоғарыдағы блокта 2001:db8:100::/48 uplink1-дегі сол қосылған префиксті білдіреді, кездейсоқ межені емес. fwmark ережесі тек басқа бірдеңе қоюы тиіс таңбаны тұтынады, өткізу жолындағы nftables немесе iptables ережесінен немесе сокеттегі SO_MARK-тен, сондықтан таңба көзі жоқ көшірілген блок ештеңеге сәйкес келмейді.

Екінші шарт: метрикалар өлі провайдерді анықтамайды

Метрика — бар маршруттар арасындағы артықшылық, денсаулық тексерісі емес. Тасымалдаушы құлағанда, ядро сол құрылғыдағы маршруттарды жояды және екінші әдепкі қабылдайды. Кабель орнында тұрып, артындағы провайдер өлгенде, кестеде ештеңе өзгермейді: таңдаулы маршрут орнатылған, көрші 2-қабатта қолжетімді, ал пакеттер қара қуысқа кетеді. Егер бұл айырмашылық сіздің конфигурацияңыз үшін маңызды болса, ауысу жолды тексеретін және маршрутты жоятын бірдеңеден келуі керек, ол маршруттау демоны болсын немесе жазбаны жойып, қайта орнататын шағын скрипт болсын.

Кестені құрғаннан кейін таңдауды тексеріңіз және оны ядро көретіндей тексеріңіз. ip -6 route get 2001:db8:100::1 қолданылатын маршрутты шығарады, оның ішінде құрылғы мен таңдалған бастау мекенжайы бар, және ол саясат ережелерін сақтайды. Дұрыс емес uplink-ке тиесілі бастау мекенжайы ереженің күткеннен ерте сәйкес келгенінің кәдімгі белгісі.

Үшінші шарт: тұрақтылыққа кім ие екенін шешіңіз

ip -6 route add-пен қосылған маршрут қайта жүктеуге дейін немесе бірдеңе оны тазалағанға дейін өмір сүреді. Маршрутизатор хабарландыруларынан үйренген әдепкі өмір сүру мерзімін алып жүреді және маршрутизатор оны кері қайтара алады, ал қолмен қосылған әдепкі өзі ешқашан бітпейді. Екеуін бір кестеде араластыру — ескірген тұрақты маршруттың жаңа хабарланғаннан жоғары қалуының жолы, ол сипаттаған uplink әлдеқашан жоқ болғаннан кейін де.

Әр кесте үшін бір ие таңдаңыз. Егер желі менеджері немесе маршруттау демоны интерфейсті әлдеқашан басқарса, саясат маршрутын сонда сипаттап, ядроға тиіспеңіз. Егер оны скриптпен жасасаңыз, скриптті идемпотентті етіп, бұзуды сол уақытта жазыңыз, өйткені алғашқы нашар өзгеріс кезінде ол сізге қажет болады:

ip -6 route flush table 201
ip -6 rule del fwmark 0x2 table 201

Басқа хосттар үшін өткізетін маршрутизаторда кестені кінәламас бұрын net.ipv6.conf.all.forwarding-ты тексеріңіз. Өткізу өшірулі болса, басқа желіге адрестелген пакеттер 201-кесте қаншалықты дұрыс болса да тасталады.

Дизайнды келесі адам аудиттей алатындай жазып қойыңыз

Тек fe80::1-ны сақтайтын түгендеу маңызды өрістерді тастайды. Межені, келесі секірімді, құрылғыны, кестені және метриканы бірге жазыңыз, сонымен қатар әр маршруттың қайдан келгенін: хабарланған, менеджер жасаған немесе статикалық. Кейінірек біреу екінші uplink шынымен трафик тасып жатқанын сұраса, сол жазба болжамсыз жауап береді.

Кестені дайын деп жарияламас бұрын ip -6 neigh show dev uplink0-пен көршіні растаңыз, реттік оқиғалар үшін ip -6 rule show-ты қайта оқыңыз және әдепкі маршрутты алатын ping орнына ережеге сәйкес трафикпен сынаңыз. Содан кейін әдейі бір uplink-ті өшіріп, ядро қай маршрутқа оралатынын қараңыз; жауап жазғаныңызбен сәйкесуі керек.