Да изключим ли IPv6, за да поправим теч на VPN? По-добре решете политиката
Адресът link-local не е теч и глобалният маршрут IPv6 също не е. Първо изберете между блокиране, пренасяне и оставяне.
Адрес от диапазона IPv6 се появява в тестова страница, тунелът очевидно не го пренася, а най-популярният съвет в интернет е да изключите IPv6 навсякъде. Тази команда наистина прави панела тих. Тя също премахва протокол, от който мрежата за достъп може да зависи, и ви оставя без представа дали адресът е бил истински теч, адрес на интерфейс link-local или резолвер, който си върши работата. Три условия определят правилния контрол и само едно от тях води до блокиране.
Определете какво всъщност е измерил инструментът
Най-честата фалшива тревога е адрес link-local, който започва с fe80: и съществува на всеки интерфейс с поддръжка на IPv6, независимо дали машината достига интернет през IPv6. Появява се в списъците на интерфейсите и в някои диагностики на приложения и не казва нищо за пътя на трафика ви.
Втората фалшива тревога е уникален локален адрес в fc00::/7, който е частен диапазон, използван вътре в мрежа. Инструмент, който отпечатва всеки адрес на хоста, ще го покаже с удоволствие до публичния. Който чете набързо, нарича това теч и после губи час за проблем, който не съществува.
Третият изобщо не е фалшива тревога. Глобалният адрес, който достига интернет извън тунела, е истинският теч и си струва да бъде измерен, преди да решите каквото и да е:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coАко първата команда отпечата глобален адрес, а третата върне публичен адрес IPv6, който не е на тунела, имате истински път извън тунела. Ако първата не отпечата нищо освен записи link-local, никога не е имало теч за поправяне.
Три условия определят контрола
Решението не е "IPv6 е добър" или "IPv6 е лош". Решението е в коя от три ситуации сте, а всяка има различен правилен отговор с различна цена, ако сгрешите.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Първият ред е това, което хората обикновено имат предвид, и е законен. Клиент, чийто изход не поддържа IPv6, не бива тихо да пуска собствения трафик IPv6 на хоста, защото това е документираният теч при двоен стек. Смисълът е да го блокирате като обявена политика, а не да изключвате протокол в ядрото. Видимият резултат е идентичен и само един от двата може да бъде прегледан по-късно.
Третият ред е мястото, където общият съвет става активно вреден. Мобилните оператори и някои домашни връзки поддържат мрежи IPv6-only с транслация за дестинации IPv4. Премахнете IPv6 там и премахвате единствения транспорт, който мрежата предлага, което дава много по-лошо прекъсване от това, което отстранявахте.
Ако изходът няма IPv6, блокирайте го нарочно
Предпочитайте собствения механизъм на клиента, защото той действа точно докато тунелът е вдигнат и се връща назад, когато падне. OpenVPN има опция за това, а iptables има еквивалентно правило за други клиенти:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableДирективата принадлежи в профила; правилото — в защитна стена, която можете да прегледате и премахнете. И двете отказват затворено, което е желаното, и двете се виждат в разлика на конфигурацията, каквото не може да се каже за sysctl в ядрото, заровен в стартов скрипт.
Запишете защо е там. Правило за блокиране без коментар се премахва от следващия човек, на когото IPv6 потрябва за нещо несвързано, и тогава течът тихо се връща.
Ако изходът пренася IPv6, насочете го и тествайте двете семейства
Пренасянето на IPv6 е по-добрият отговор, когато сървърът го поддържа, и не е много по-трудно. Изискването е интерфейсът на тунела да има адрес в това семейство и маршрутът по подразбиране за него да сочи в тунела, а не навън от физическия интерфейс:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coТърсенето на маршрут е решаващият тест: ако посочи интерфейса на тунела, трафикът IPv6 се пренася. Двете извиквания на curl после потвърждават какво вижда всяко семейство и сравняването им е начинът да докажете, че двата пътя вече излизат през един и същ изход.
Не спирайте при успешна връзка. Свържете тунела отново и проверете пак, защото изпратен маршрут IPv6 може да се загуби при повторно установяване, ако сървърът го изпраща само в началната конфигурация. После проверете една изключена дестинация, защото правилата на разделения тунел са мястото, където двете семейства най-често се разминават.
Ако мрежата за достъп е само IPv6, оставете я на мира
Някои мрежи предоставят само IPv6 и очакват устройството да достига услуги IPv4 през механизъм за транслация от страна на оператора. Изключването на IPv6 на такава машина не е подобрение на сигурността; то премахва единствения маршрут до каквото и да е. Това е прекъсване, което сам си причинявате в името на резултат от тест, който никой не е поискал.
Симптомът на тази грешка е отличителен и неприятен: тунелът сякаш се установява, разрешаването на имена работи, а нищо не се зарежда. Ако видите това след промяна на IPv6, върнете настройката веднага и продължете диагностиката другаде.
Каквото и да изберете, дръжте решението явно в профила или защитната стена, свържете го с това, което изходът наистина поддържа, и отбележете поведението при двоен стек, което описва обсъждането на двоен стек в RFC 7359 . Обявеното блокиране е политика. Изключеният протокол е заобиколно решение, което никой не може да одитира, и от тестовата страница изглеждат еднакво.