Вложени VPN тунели: защо вътрешният зацикля при големи пакети

DNS се разрешава, SSH сесията остава активна, а после голямо качване замръзва, докато ping към същия хост все още отговаря. Това разделяне сочи към размера на пакета, а не към счупен тунел. Вложените тунели го достигат при размери, които нито един тунел сам не би достигнал. Вътрешната сесия е наред; просто ѝ се подават пакети, които вече не се побират.

Къде всъщност отива MTU на пътя

Всяка инкапсулация изразходва байтове, преди следващият слой да получи ред. Ethernet път предлага 1500 байта на външния пакет, а външният тунел взема своя дял, преди нещо вътре в него да може да бъде адресирано. Една предполагаема стойност на разходите ще бъде грешна точно с количеството, което има значение.

Избройте слоевете по ред: път за достъп, външен транспорт, външен тунел, вътрешен транспорт, вътрешен тунел, приложение. Броите всеки заглавен блок веднъж и дръжте UDP отделно от собствения заглавен блок на тунела и неговия етикет.

Два слоя WireGuard, преброени веднъж

Вземете IPv4 път за достъп с един WireGuard тунел в друг. Външният слой струва 20 байта IPv4, 8 за UDP и 32 за заглавния блок на данните на WireGuard плюс неговия етикет за удостоверяване. Вътре в това вътрешният тунел се нуждае от свой 20-байтов IPv4 заглавен блок и 8-байтов UDP заглавен блок преди вторите си 32 байта разходи за WireGuard. Останалото побира IPv4 заглавен блок, TCP заглавен блок и данните. Външен IPv6 път струва 40 вместо 20 и оставя 1320.

Сметката стига до 1340 байта. Един слой при същите правила оставя 1400 за TCP полезния товар, което е 1500 минус 20, 8, 32, 20 и 20, а разликата от 60 байта е точно вътрешната инкапсулация, която добавя вторият тунел.

Приложете 1400 към вложен път и вътрешният тунел е с 60 байта по-малко, невидимо, докато пакетът не стане достатъчно голям, за да ги потрябва. Подпълването и собствената опция за фрагментация на протокола отново разместват числата, затова се доверете на таблицата.

MTU, MSS и фрагментацията действат на различни места

MTU на интерфейса ограничава какво ще излъчи интерфейсът, докато притискането на MSS в TCP променя какво TCP партньорът е готов да изпрати. Притискането поправя TCP сесии и не прави нищо за голяма UDP дейтаграма, така една поправка изглежда успешна за едно приложение и тихо пропуска следващото. Собствената опция за фрагментация на протокола е трети лост със своите откази. MTU на интерфейса е общият първи ход и най-грубият.

Мостовите и маршрутизираните тунели носят различни кадри, затова числата от друго внедряване рядко се пренасят. Откриването на MTU на пътя, описано в RFC 8201, помага само докато ICMP съобщенията, от които зависи, се пропускат.

Намиране на слоя, на който не достига

Проверете всеки тунел поотделно, преди да ги вложите, ако изискванията позволяват сравнение. Сонда с фиксиран размер решава въпроса: ping -M do -s 1472 -c 3 10.8.0.1 изпраща пълен IPv4 пакет от 1500 байта в този слой. Добавете втория слой и повторете същата сонда, за да принадлежи всеки отказ на известно изменение.

Когато трансферът зацикли, променяйте един документиран параметър наведнъж и записвайте размера, при който се проваля. Проверете и обратния път, защото вложената рекурсия на маршрутите може да имитира проблем с размера на пакета достатъчно близо, за да ви струва следобеда. Филтриран ICMP отговор може да скрие истинската граница, затова сондата е по-важна от разсъжденията.

Запишете бюджета там, където следващият човек ще го намери

Таблица с един ред на слой живее по-дълго от правило наум. Дръжте я до схемата на тунела, за да не пресмята никой сметката под натиск.

Повече тунели означават повече зависимости, затова планът за връщане назад заслужава място до бюджета. Ако числата все още не се събират, измерете пътя, вместо да гадаете отново. Целта е число, което можете да защитите, а не да запомните.