Tuneluri VPN imbricate: de ce cel interior se blochează la pachete mari

DNS-ul se rezolvă, sesiunea SSH rămâne activă, apoi un transfer mare îngheață în timp ce un ping către același host încă răspunde. Această separare indică dimensiunea pachetului, nu un tunel defect. Tunelurile imbricate ajung acolo la dimensiuni la care niciunul singur nu ar ajunge. Sesiunea interioară este în regulă; doar primește pachete care nu mai încap.

Unde ajunge de fapt MTU-ul căii

Fiecare încapsulare consumă octeți înainte ca stratul următor să-și primească rândul. O cale Ethernet oferă 1500 de octeți pachetului exterior, iar tunelul exterior își ia partea înainte ca ceva din interior să poată fi adresat. O singură valoare estimată a suprasarcinii va fi greșită exact cu cantitatea care contează.

Enumerați straturile în ordine: cale de acces, transport exterior, tunel exterior, transport interior, tunel interior, aplicație. Numărați fiecare antet o dată și țineți UDP separat de antetul și eticheta proprii tunelului.

Două straturi WireGuard, numărate o dată

Luați o cale de acces IPv4 cu un tunel WireGuard în altul. Stratul exterior costă 20 de octeți IPv4, 8 UDP și 32 pentru antetul de date WireGuard plus eticheta sa de autentificare. În interior, tunelul interior are nevoie de propriul antet IPv4 de 20 de octeți și de un antet UDP de 8 octeți înaintea celor de-al doilea 32 de octeți de suprasarcină WireGuard. Ce rămâne găzduiește un antet IPv4, un antet TCP și datele. O cale exterioară IPv6 costă 40 în loc de 20 și lasă 1320.

Aritmetica ajunge la 1340 de octeți. Un singur strat după aceleași reguli lasă 1400 pentru încărcătura utilă TCP, adică 1500 minus 20, 8, 32, 20 și 20, iar diferența de 60 de octeți este exact încapsularea interioară pe care o adaugă al doilea tunel.

Aplicați 1400 pe o cale imbricată și tunelului interior îi lipsesc 60 de octeți, invizibil până când pachetul este suficient de mare pentru a avea nevoie de ei. Umplutura și opțiunea de fragmentare proprie protocolului mută din nou cifrele, așa că aveți încredere în tabel.

MTU, MSS și fragmentarea acționează în locuri diferite

MTU-ul interfeței limitează ce va emite interfața, în timp ce strângerea MSS din TCP schimbă ce este dispus să trimită un partener TCP. Strângerea repară sesiunile TCP și nu face nimic pentru un datagramă UDP mare, așa arată o corecție reușită pentru o aplicație și rata în tăcere următoarea. Opțiunea de fragmentare proprie protocolului este o a treia pârghie cu propriile eșecuri. MTU-ul interfeței este prima mișcare obișnuită și cea mai grosieră.

Tunelurile cu punte și cele rutate transportă cadre diferite, așa că cifrele dintr-o altă implementare rareori se transferă. Descoperirea MTU a căii, descrisă în RFC 8201, ajută doar cât timp mesajele ICMP de care depinde sunt lăsate să treacă.

Găsirea stratului care lipsește

Verificați fiecare tunel separat înainte de a le imbrica, dacă cerințele permit o comparație. O sondă de dimensiune fixă decide: ping -M do -s 1472 -c 3 10.8.0.1 trimite un pachet IPv4 complet de 1500 de octeți în acel strat. Adăugați al doilea strat și repetați aceeași sondă, astfel încât orice eșec să aparțină unei modificări cunoscute.

Când un transfer se blochează, schimbați un parametru documentat o dată și notați dimensiunea la care eșuează. Verificați și calea de întoarcere, pentru că recursia imbricată a rutelor poate imita o problemă de dimensiune a pachetului destul de fidel încât să coste o după-amiază. Un răspuns ICMP filtrat poate ascunde limita reală, așa că sonda contează mai mult decât raționamentul.

Scrieți bugetul acolo unde îl va găsi următoarea persoană

Un tabel cu un rând pe strat supraviețuiește unei reguli empirice. Țineți-l lângă diagrama tunelului ca nimeni să nu refacă aritmetica sub presiune.

Mai multe tuneluri înseamnă mai multe dependențe, așa că un plan de revenire își merită locul lângă buget. Dacă cifrele încă nu se potrivesc, măsurați calea în loc să ghiciți din nou. Scopul este o cifră pe care o puteți apăra, nu una de memorat.