IPv6 трафигі VPN арқылы өтуі керек пе, әлде тікелей ме?

Өткен айда екі адам менен қарама-қарсы нәтижелер сұрады: біреуі IPv6-ның VPN-мен қамтылуын қалады, екіншісі кеңсе принтерінің жұмысын жалғастырғысы келді. Бір ::/0 маршруты екеуін де өз бетінше қамтамасыз ете алмайды. Бұл маршрут туннельдің ішінде ме, жоқ па — үш шартқа байланысты, ал біріншісі оны коммерциялық шығыстардың көбісі үшін жоққа шығарады. Егер шығыс IPv6 тасымалдамаса, әдепкі маршрутты сол жаққа бағыттау трафигіңізді жіберер жері жоқ туннельде жасырады.

Жауапты үш шарт шешеді

Әдепкі маршрут — бір жол, ::/0, ол нақтырақ маршруты жоқ кез келген IPv6 межелісіне сәйкес келеді (RFC 4291). Оны орнату оңай. Мұны істеу керек пе, жоқ па — үш шартқа келіп тіреледі.

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

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

Шығыс шынымен IPv6 тасымалдай ма?

IPv6 мекенжайы бар туннель интерфейсі арғы жақ туралы ештеңе дәлелдемейді. Көптеген коммерциялық профиль ішінен тек IPv4: сервер сізге v4 мекенжайын береді де, қалғанының бәрін тастайды. Оның үстіне AllowedIPs-тен әдепкі маршрут орнатыңыз, сонда ядро IPv6-ны серіктесі ешқашан көрмейтін интерфейске қуана жібереді.

Туннель көтерілген кезде клиенттен тексеріңіз. ping -6 -c 3 2001:4860:4860::8888 мен ip -6 route get 2001:4860:4860::8888 әртүрлі сұрақтарға жауап береді: жауап қайта ма, және ядро қай құрылғыны таңдады. Екіншісі сіздің туннеліңізді атап, біріншісі ештеңе қайтармаса, мәселе маршрутта емес, шығыста.

Шығысты өзіңіз басқарсаңыз, клиент тесті өтуі мүмкін, ал жол бәрібір тұйыққа тіреледі. Шлюзде net.ipv6.conf.all.forwarding=1 қосулы екенін және оның брандмауэры туннельден жіберілген пакеттерді қабылдайтынын растаңыз. Қайта жіберуден бас тартатын шығысқа дұрыс бағытталған пакет клиент жағынан дәл маршруттау қатесіне ұқсайды.

Клиент соңғы нүктеге дейінгі жолын сақтай ала ма?

Бұл мені тек IPv6 WireGuard соңғы нүктесі бар ноутбукта ұстаған жағдай. Соңғы нүктенің мекенжайы қарапайым ғаламдық мекенжай, сондықтан ол ::/0 ішіне кіреді. Бүкіл префиксті интерфейске бағыттаңыз, сонда қол алысу пакеттері әлі салып жатқан туннельге өздерін қуып кіреді. Туннель ешқашан көтерілмейді, ал клиент шығысында неге екені айтылмайды.

wg-quick мұны Linux-те шешеді. Ол маршруттарды AllowedIPs-тен шығарады, өз кестесіне орнатады және соңғы нүктеге трафик алдымен негізгі кесте арқылы шешілуі үшін саясат ережесін қосады: suppress_prefixlength 0 ережесі, оны ip -6 rule-тен табасыз. Сондықтан wg-quick up қолмен жазылған ip -6 route add default dev wg0 сізді кесіп тастайтын жерде сәтті болады.

Екі күйді де ip -6 route get <endpoint-v6> арқылы тексеріңіз, туннельді көтерер алдында және одан кейін. Жауап туннель құрылғыңызға ауысса, туннельге қажет жолды жойдыңыз. Маршруттарды өзіңіз жазсаңыз, соңғы нүктеге бастапқы шлюз арқылы хост маршрутын қосыңыз немесе соңғы нүктеге IPv4 арқылы қосылып, IPv6-ны жүктемеге қалдырыңыз.

Туннельден тыс не қалуы керек?

Нақтырақ маршруттар әдепкіден басым, сондықтан буындағы префикс немесе өз маршруты бар ULA диапазоны қосымша күшсіз жұмысын жалғастырады. Бұл көптеген толық туннельді IPv4 конфигурацияларының өмір сүруінің тыныш себебі: LAN префикстері әдепкіден нақтырақ және туннельге ешқашан кірмейді.

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

Протокол бойынша емес, межелі бойынша шешіңіз. Екі-үш жергілікті хост маңызды болса, олардың префикстеріне физикалық интерфейстен шығатын маршрут беріңіз немесе келісілген жиынтықтан алып тастаңыз. Тізім өсе берсе, адал жауап — жазбаша ерекшеліктер тізімімен IPv6 үшін бөлінген туннель, ал сіз үнемі жамап жүрген әдепкі маршрут емес.

Жауап жоқ болса, оны бұғаттаңыз

IPv6-ны маршрутсыз қалдыру оны жалғыз қалдырумен бірдей емес. Жұмыс істейтін IPv6 әдепкісі бар хост туннель IPv4 тасымалдап жатқанда да оны пайдалана береді, сондықтан трафик VPN-нің қасынан шығады және IPv6-ны қалайтын әрбір қызмет сіздің нақты мекенжайыңызды көреді. Бұл ағу, бөлінген туннель емес.

Біреуін таңдап, қайсысын таңдағаныңызды жазыңыз. Әдепкі маршрутты бағыттап, жоғарыдағы ымыраларды қабылдаңыз немесе туннель созылатын уақытқа IPv6-ны өшіріңіз. Префиксті AllowedIPs-тен алып тастау жалғыз өзі жеткіліксіз, өйткені операциялық жүйе өз әдепкісін сақтайды. Linux-те өрескел нұсқа — sysctl -w net.ipv6.conf.all.disable_ipv6=1; нәзік нұсқа IPv6-ны брандмауэр ережесімен туннельден тыс тастайды. Телефон клиенттерінде дәл осы жұмысты істейтін айқын IPv6 бұғаттау қосқышы бар.

Оны ағу ретінде тексеріңіз

Туннельді көтеріп, қосқышқа сенудің орнына күйді оқыңыз. ip -6 route show default бір әдепкіні көрсетуі керек, ал ip -6 route get LAN-ыңыздан тыс межелі үшін туннель құрылғысын атауы керек. Қосылым үзілгеннен кейін екеуін де қайталаңыз: туннельден ұзақ өмір сүретін әдепкі — сіз іздеген қате.

Содан кейін қарсы бағытты тексеріңіз. Жергілікті желідегі хосттан клиентке оның жергілікті IPv6 мекенжайы арқылы жетіңіз. Егер бұл жұмысын тоқтатса, үшінші шарт ешқашан орындалмаған, сол кезде маршрут кестесі не деп тұрса да.

Нәтижені келесі адам табатын жерге жазыңыз: қандай префикстер жергілікті болып қалады, неге, және қосылым үзілгеннен кейін клиент не істейді. Runbook-тағы екі жол келесі инженерді түн ортасында соңғы нүкте циклін қайта ашудан сақтайды.