Занадта вялікі пакет IPv6: чаму вялікія перадачы праз VPN заміраюць

Ping працуе, браўзер адкрывае дробную старонку, а перадача файла вісне — і ўсё гэта праз IPv6 у адным і тым жа тунэлі. Такі ўзор звычайна значыць, што адпраўнік так і не даведаўся рэальны памер шляху, а не тое, што тунэль павольны. IPv6 чакае, што маршрутызатары паведамяць пра праблему паведамленнем Packet Too Big, а інкапсуляцыя дадае накладныя выдаткі перш, чым пакет дасягне знешняй сеткі. Калі гэтае паведамленне адфільтраванае, адпраўнік працягвае паўтараць памер, які не можа прайсці.

Дробныя запыты, вялікія замінкі

Тунэль заварочвае кожны пакет у чарговы загаловак, таму прыдатны памер унутры меншы за памер звонку. Пакет, падабраны пад фізічнае звяно да інкапсуляцыі, пасля яе становіцца занадта вялікім. Маршрутызатары IPv4 могуць фрагментаваць па шляху, а маршрутызатары IPv6 не робяць гэтага за адпраўніка, таму адпраўнік павінен падстроіцца сам. І гэтая падстройка цалкам залежыць ад атрымання зваротнай сувязі.

Адна страчанае паведамленне дастатковая для класічнага сімптому: рукапацісканні і дробныя адказы праходзяць, а спіс каталога ці загрузка спыняюцца ў адным і тым жа месцы кожны раз. Карыстальнікі апісваюць гэта як павольны VPN, а журналы не паказваюць нічога няправільнага ў аўтэнтыфікацыі. Абодва назіранні дакладныя, і ні адно з іх не вызначае месца няспраўнасці.

Packet Too Big — гэта зваротная сувязь, а не трафік

Паведамленне ICMPv6 Packet Too Big нясе памер, які можа прыняць наступны хоп, і адпраўнік выкарыстоўвае яго, каб паменшыць сваю ацэнку. Адфільтраваць яго — гэта тое ж, што зняць дарожны знак і потым вінаваціць вадзіцеляў. Правіла, якое скідвае ўвесь ICMPv6, выглядае строгім, але ламае выяўленне шляху на кожным звяне, якому яно патрэбнае. Паведамленне — гэта кіраўнічая інфармацыя пра шлях, а не карысная нагрузка праграмы.

Выбарчае фільтраванне ўсё яшчэ разумнае. Запыты рэха і выяўленне суседзяў выконваюць іншыя ролі, чым паведамленні пра памылкі, і палітыка можа абыходзіцца з імі па-рознаму. Ідзіце за дакументаванымі рэкамендацыямі платформы па фільтраванні, а не прымайце ці скідвайце ўвесь пратакол, бо RFC 8201 вызначае, як гэтая зваротная сувязь кіруе выяўленнем.

Правярайце абедзве сям’і адрасоў асобна

Праверце IPv6 асобна, бо паспяховая перадача IPv4 нічога не даказвае пра шлях IPv6. Затым злавіце кіраўнічыя паведамленні, пакуль вялікая перадача вісне. Два запісы разам або паказваюць, што зваротная сувязь сыходзіць, або даказваюць, што яна так і не прыйшла.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Проба адпраўляе пакет з усталяваным бітам забароны фрагментацыі і паведамляе памер, на якім ён зрываецца, — гэта лік, які павінен змясціць тунэль. Запыт маршруту называе інтэрфейс, які павёз бы пункт прызначэння, каб вы ведалі, які MTU звяна дзейнічае. Захоп фільтруе ICMPv6 тыпу 2, гэта значыць паведамленне Packet Too Big, і паказвае, ці дасягае яно гэты хост наогул. Калі паведамленне ёсць у захопе, а перадача ўсё яшчэ вісне, адпраўнік яго ігнаруе, і гэта пераносіць расследаванне ў стэк, а не ў сетку.

Змяняйце памер тунэлю толькі пасля доказаў

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

Калі вы кантралюеце шлюз, даследуйце правіла, якое скідвае паведамленне, замест таго каб адключаць міжсеткавы экран. Адно выпраўленае правіла вузейшае за выключэнне ў палітыцы і значна лягчэй абараняецца потым. Тое ж разважанне тычыцца тайм-аўтаў: не кожная замінка — праблема памеру, і менавіта захоп аддзяляе адно ад другога.