Звычка — зніжаць MTU, як толькі WireGuard пачынае паводзіць сябе неяк не так, і гэтая звычка хавае іншую няспраўнасць. Шлюз, які не перасылае, і шлях, які не трымае вялікіх пакетаў, даюць розныя ўзоры: адзін адмаўляе ў абодвух кірунках і пры любым памеры, другі перажывае маленькія запыты і гіне на вялікіх. Вызначце, якая форма ў вас, перш чым змяняць любы лік. Тэст каштуе танна і прыбірае палову магчымых прычын.

Дзве няспраўнасці, дзве розныя формы

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

Праблема памеру праяўляецца толькі вышэй за парог. DNS, рукапацісканне TCP і маленькі выклік API працуюць, а спампоўка файла ці вялікі адказ завісаюць. Пакеты, якія змясціліся, прайшлі ад пачатку да канца, а тыя, што не змясціліся, былі скінутыя недзе без карыснай справаздачы.

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

Выключыце перасылку, перш чым нешта паменшыць

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

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

Там, дзе дызайн выкарыстоўвае трансляцыю адрасоў, правіла трансляцыі з’яўляецца часткай гэтага зваротнага шляху. Выдаленне яго падчас пошуку праблемы MTU ператварае працуючы дызайн у зламаны, таму прачытайце існуючыя правілы, перш чым іх правіць.

Вымерайце, дзе пачынаецца разрыў

Спачатку прачытайце стан перасылкі і правілы фільтрацыі. Гэта праверкі толькі для чытання, і яны адказваюць на таннае пытанне:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Затым праверце памеры з бітам «не фрагментаваць», ад кліента, да хоста за шлюзам:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

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

ObservationPoints towardWhere to look
Nothing beyond the gateway worksForwarding or return routeForwarding flag, filter rules, routing table
Small works, large stallsPacket size on the pathTunnel MTU and the link underneath
Only names failDNS resolutionThe resolver configured for the tunnel
Works sometimesMultiple paths or state expiryFlow selection and NAT state

Выпраўце той узровень, які вы даказалі

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

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

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

Падобныя артыкулы