OpenVPN pe PPPoE: reducem link-mtu, tun-mtu sau mssfix?

Pingurile răspund, DNS-ul rezolvă, iar fiecare pagină care are nevoie de un segment complet se blochează. Pe un uplink care adaugă propria încapsulare, calea pierde în tăcere câteva zeci de octeți din buget, iar un profil scris pentru Ethernet curat continuă să ceară pachete pe care linia nu le poate duce. Conexiunea nu este lentă; ea aruncă exact pachetele care contează.

Trei opțiuni pot rezolva acest lucru și acționează la niveluri diferite. Alegerea greșită fie nu face nimic, fie face tunelul fragil într-un mod nou, așa că alegerea începe cu ceea ce calea suportă cu adevărat.

Trei butoane, trei niveluri diferite

link-mtu este bugetul exterior: sarcina criptată plus antetul OpenVPN, antetul UDP și antetul IP exterior. Descrie ce iese din mașină, și de aceea este numărul pe care calea fizică îl limitează.

tun-mtu este bugetul interior: interfața pe care o vede traficul dumneavoastră. Este mai mare decât ceea ce poate duce calea exact cu suprasarcina tunelului, iar OpenVPN îl derivă de obicei în loc să vă oblige să îl setați.

mssfix este un mecanism complet diferit. Rescrie dimensiunea maximă a segmentului anunțată în timpul strângerilor de mână TCP, astfel încât partenerii TCP să aleagă segmente care încap după încapsulare. Nu schimbă MTU-ul interfeței și nu are niciun efect asupra UDP.

Dacă setați link-mtu explicit, OpenVPN scade propria suprasarcină pentru a deriva MTU-ul interior. Acea suprasarcină nu este o constantă fixă; depinde de cifru și de autentificare, de aceea o valoare copiată de pe un forum poate fi greșită pe alt profil. Setarea atât a link-mtu, cât și a tun-mtu îi dă clientului două instrucțiuni contradictorii.

Măsurați calea înainte de a alege orice număr

Măsurați de la interfața fizică, nu din interiorul tunelului, și rețineți că ping raportează sarcina utilă, nu dimensiunea pachetului. Adăugați 28 de octeți pentru antetele IPv4 și ICMP înainte de a compara sarcina utilă cu un cadru de 1500 de octeți, și țineți cont de această corecție când un partener raportează un alt număr.

Pe un client Linux, ping -M do -s 1472 interzice fragmentarea și eșuează dacă pachetul este prea mare. Reduceți sarcina utilă până când trece, apoi adăugați 28 pentru a obține MTU-ul căii. PPPoE costă 8 octeți, așa că 1492 este normal pe DSL. DS-Lite și unele căi mobile costă 40 sau mai mult, iar răspunsul este de obicei mai mic decât sugerează viteza nominală a legăturii.

Dacă fiecare dimensiune de ping reușește, dar transferurile mari încă se blochează, suspectați o gaură neagră în loc de o simplă limită de dimensiune. Un mesaj ICMP despre fragmentarea necesară este filtrat undeva pe cale, așa că expeditorul nu învață niciodată să micșoreze, și doar fluxurile care au nevoie de un segment mare observă asta.

Limitați mai întâi TCP, micșorați tunelul apoi

Strângerile de mână TCP sunt singurul lucru pe care mssfix îl atinge, ceea ce îl face de obicei cel mai puțin invaziv control de încercat mai întâi. Setați-l puțin sub bugetul real al căii, trimiteți aceeași valoare de la server pentru ca ambele capete să fie de acord, și retestați un download mare. Dacă blocajul dispare, problema a fost dimensiunea segmentului TCP, și nimic altceva nu trebuie schimbat.

Reduceți MTU-ul interior când traficul afectat nu este TCP. Un serviciu UDP, un tunel în tunel sau o aplicație care trimite datagrame de dimensiune completă vor continua să eșueze după o limitare MSS pentru că nimic nu rescrie dimensiunea pachetelor sale. Reduceți tun-mtu pentru acel caz, sau setați link-mtu și lăsați clientul să derive valoarea interioară, dar niciodată ambele.

Nu apelați la vechea opțiune de fragmentare. Împărțea pachetele în interiorul tunelului, adăuga suprasarcină și a fost retrasă din motive bune; OpenVPN modern așteaptă o descriere precisă a căii.

De ce micile teste continuă să funcționeze

Interogările DNS, ecourile ICMP și strângerile de mână TCP sunt toate mult sub dimensiunea care eșuează. Tunelul pare deci sănătos în fiecare test rapid, în timp ce strângerile de mână TLS și răspunsurile HTTP eșuează în tăcere. Exact această combinație, un traceroute funcțional și un browser care se blochează la primul răspuns mare, este semnul pe care trebuie să îl căutați. Apelați la un test de dimensiune completă înainte de a apela la un profil nou.

Verificați cu traficul care a eșuat. Încărcați o pagină mare, trimiteți o datagramă UDP de dimensiune completă dacă acesta este serviciul afectat, și repetați de la un al doilea client pe alt uplink. Notați MTU-ul de cale măsurat și valoarea pe care ați ales-o, pentru că altfel următoarea persoană care atinge profilul va considera numărul arbitrar.

Nu coborâți niciodată MTU-ul interior sub 1280 când IPv6 rulează peste tunel, pentru că acesta este minimul pe care fiecare legătură IPv6 trebuie să îl ducă. Un MTU mai mic este un fapt despre cale, nu o setare de performanță de reglat după simț.