Gnezdeni tuneli VPN: zakaj se notranji ustavi pri velikih paketih
Vsak tunel porabi del proračuna paketov poti, preden se začne naslednji. Seštejte glave in notranja seja pri velikih paketih spodleti.
DNS se razreši, seja SSH se obdrži, nato pa se velik prenos ustavi, medtem ko ping na isti gostitelj še vedno odgovarja. Ta ločitev kaže na velikost paketa in ne na pokvarjen tunel. Gnezdeni tuneli to dosežejo pri velikostih, ki jih noben tunel sam ne bi dosegel. Notranja seja je v redu; le pakete dobiva, ki ne gredo več noter.
Kam gre MTU poti v resnici
Vsaka enkapsulacija porabi bajte, preden pride na vrsto naslednja plast. Pot Ethernet ponuja zunanjemu paketu 1500 bajtov, zunanji tunel pa vzame svoj delež, preden je karkoli v njem mogoče nasloviti. Ena ugibana vrednost režije bo napačna natančno za toliko, kolikor je pomembno.
Naštejte plasti po vrsti: dostopna pot, zunanji transport, zunanji tunel, notranji transport, notranji tunel, aplikacija. Vsako glavo štejte enkrat, UDP pa ločite od lastne glave in oznake tunela.
Dve plasti WireGuard, preštete enkrat
Vzemite dostopno pot IPv4 z enim tunelom WireGuard znotraj drugega. Zunanja plast stane 20 bajtov IPv4, 8 UDP in 32 za podatkovno glavo WireGuard skupaj z njeno oznako overjanja. Znotraj tega notranji tunel potrebuje svojo 20-bajtno glavo IPv4 in 8-bajtno glavo UDP pred svojimi drugimi 32 bajti režije WireGuard. Kar ostane, sprejme glavo IPv4, glavo TCP in podatke. Zunanja pot IPv6 stane 40 namesto 20 in pusti 1320.
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
Aritmetika se ustavi pri 1340 bajtih. Ena plast po enakih pravilih pusti 1400 za koristni tovor TCP, to je 1500 minus 20, 8, 32, 20 in 20, razlika 60 bajtov pa je natanko notranja enkapsulacija, ki jo doda drugi tunel.
Uporabite 1400 na gnezdeni poti in notranjemu tunelu manjka 60 bajtov, nevidno, dokler paket ni dovolj velik, da bi jih potreboval. Polnjenje in lastna možnost razdrobljenosti protokola spet premakneta številke, zato zaupajte tabeli.
MTU, MSS in razdrobljenost delujejo na različnih mestih
MTU vmesnika omejuje, kaj bo vmesnik oddal, medtem ko stiskanje MSS v TCP spreminja, kaj je TCP partner pripravljen poslati. Stiskanje popravi seje TCP in ne naredi ničesar za velik datagram UDP, zato je popravek videti uspešen za eno aplikacijo in tiho zgreši naslednjo. Lastna možnost razdrobljenosti protokola je tretji vzvod z lastnimi neuspehi. MTU vmesnika je običajna prva poteza in najbolj groba.
Mostovni in usmerjeni tuneli nosijo različne okvire, zato se številke iz druge uvedbe le redko prenesejo. Odkrivanje MTU poti, opisano v RFC 8201, pomaga le dokler so sporočila ICMP, od katerih je odvisno, spuščena skozi.
Iskanje plasti, ki ji manjka
Preverite vsak tunel posebej, preden jih gnezdite, če zahteve dovoljujejo primerjavo. Sonda fiksne velikosti to odloči: ping -M do -s 1472 -c 3 10.8.0.1 pošlje poln paket IPv4 s 1500 bajti znotraj te plasti. Dodajte drugo plast in ponovite isto sondo, da vsaka napaka pripada znani spremembi.
Ko se prenos ustavi, spreminjajte en dokumentiran parameter naenkrat in zabeležite velikost, pri kateri spodleti. Preverite tudi povratno pot, ker gnezdna rekurzija poti lahko dokaj zvesto posnema težavo z velikostjo paketa, da stane celo popoldne. Filtriran odgovor ICMP lahko skrije resnično mejo, zato je sonda pomembnejša od razmišljanja.
Zapišite proračun tja, kjer ga bo našla naslednja oseba
Tabela z eno vrstico na plast preživi pravilo palca. Imajte jo ob diagramu tunela, da nihče ne ponavlja aritmetike pod pritiskom.
Več tunelov pomeni več odvisnosti, zato si načrt vračanja zasluži mesto ob proračunu. Če se številke še vedno ne izidejo, izmerite pot, namesto da spet ugibate. Cilj je številka, ki jo lahko zagovarjate, ne tista, ki si jo zapomnite.