Ці павінен трафік 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 і што яго фаервол прымае пакеты, перасланыя з тунеля. Правільна маршрутызаваны пакет у выхад, які адмаўляецца рэтрансляваць, выглядае з боку кліента дакладна як памылка маршрутызацыі.

Ці можа кліент захаваць шлях да канчатковага пункта?

Гэта тое, што злавіла мяне на ноўтбуку з канчатковым пунктам WireGuard, які працуе толькі на IPv6. Адрас канчатковага пункта — звычайны глабальны адрас, таму ён трапляе ўсярэдзіну ::/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. Калі гэта перастае працаваць, умова трэцяя ніколі не была выкананая, што б ні сцвярджала тады табліца маршрутызацыі.

Запішыце вынік там, дзе яго знойдзе наступны чалавек: якія прэфіксы застаюцца лакальнымі, чаму і што робіць кліент пасля адключэння. Два радкі ў інструкцыі збярэгуць наступнага інжынера ад паўторнага адкрыцця пятлі канчатковага пункта апоўначы.