Вгнездени 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 на интерфејсот ограничува што ќе испрати интерфејсот, додека TCP MSS стегањето менува што е подготвен да испрати TCP партнерот. Стегањето ги поправа TCP сесиите и не прави ништо за голем UDP датаграм, така една поправка изгледа успешна за една апликација и тивко ја промашува следната. Сопствената опција за фрагментација на протоколот е трета рачка со сопствени неуспеси. MTU на интерфејсот е вообичаениот прв чекор и најгрубиот.

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

Пронаоѓање на слојот на кој му недостига

Проверете го секој тунел одделно пред да ги вгнездите, ако барањата дозволуваат споредба. Сонда со фиксна големина го решава тоа: ping -M do -s 1472 -c 3 10.8.0.1 испраќа целосен IPv4 пакет од 1500 бајти во тој слој. Додајте го вториот слој и повторете ја истата сонда, за секој неуспех да припаѓа на позната промена.

Кога трансферот ќе заглави, менувајте еден документиран параметар одеднаш и запишете ја големината на која паѓа. Проверете го и повратниот пат, бидејќи вгнездената рекурзија на рутите може доволно верно да го имитира проблемот со големината на пакетот за да чини едно попладне. Филтриран ICMP одговор може да ја сокрие вистинската граница, затоа сондата е поважна од расудувањето.

Запишете го буџетот таму каде што ќе го најде следниот човек

Табела со еден ред по слој живее подолго од правило на памет. Држете ја до шемата на тунелот за никој да не ја повторува аритметиката под притисок.

Повеќе тунели значат повеќе зависности, затоа планот за враќање назад заслужува место до буџетот. Ако бројките уште не се собираат, измерете ја патеката наместо повторно да претпоставувате. Целта е бројка што можете да ја одбраните, а не да ја запомните.