OpenVPN semnalează utilizarea inconsecventă a MTU: ce compară avertismentul

Acel avertisment raportează o comparație între opțiunile partenerilor, nu o măsurare a traseului dintre ei. Oamenii îl citesc ca «MTU este greșit» și schimbă numărul până dispare linia. Astfel, o comparație de configurație este tratată ca măsurătoare de rețea, iar tunelul se înrăutățește adesea în timp ce jurnalul devine mai silențios. Primul pas util este să decideți care dintre cele două probleme o aveți de fapt.

Trei condiții decid răspunsul: ce compară partenerii, dacă valoarea este veche și ce simptom există dincolo de avertisment.

Avertismentul compară opțiuni, nu pachete

Partenerii OpenVPN își schimbă șirurile de opțiuni în timpul strângerii de mână și le compară ca parte a verificării consecvenței opțiunilor. Când o parte raportează link-mtu sau tun-mtu diferit de cealaltă, nepotrivirea este înregistrată cu ambele valori. Acel schimb nu trimite niciodată un pachet mare ca să vadă ce se întâmplă, așa că avertismentul descrie configurația, nu capacitatea. Un tunel poate transporta trafic de dimensiune completă și totuși să imprime avertismentul, sau poate eșua la pachete mari și să nu imprime nimic.

Păstrați avertismentul complet împreună cu valoarea locală și cea îndepărtată. Perechea este dovada; numărul singur pe care îl țineți minte nu este.

De ce link-mtu este învechit

OpenVPN 2.6 declară link-mtu învechit pentru că antetele variabile și cifrurile negociate fac o valoare fixă de legătură nesigură. Opțiunea presupunea o dispunere a pachetului pe care protocolul nu o mai garantează, așa că un profil vechi cu un link-mtu literal descrie o intenție pe care codul actual nu o poate îndeplini. Copierea acelui număr într-un profil nou răspândește o presupunere învechită. Citiți-l ca parte din istoria profilului vechi, nu ca recomandare.

Verificarea consecvenței are și o valoare OCC opțională legată de tun-mtu, care schimbă ce se compară fără a schimba ce transportă rețeaua. Setarea ei nu face să încapă pachete mai mari.

Remediați profilul înainte de a testa traseul

Remediați o nepotrivire neintenționată prin cel care deține profilurile și țineți minte că o modificare pe server afectează fiecare client. Editați profilul pe care instanța îl încarcă efectiv, nu un export aflat într-un folder de descărcări. Apoi reconectați un client de test și notați ce avertisment supraviețuiește. Dacă mesajul își schimbă forma în loc să dispară, comparați alte opțiuni decât credeți.

Un server partajat are nevoie de verificarea inventarului de clienți înainte de a muta o valoare globală, pentru că valoarea potrivită pentru un site poate strica altul.

Apoi testați simptomul pe care îl aveți cu adevărat

Dacă transferurile mari se blochează în timp ce cererile mici reușesc, măsurați dimensiunea pachetului față de o destinație controlată. O sondă care setează bitul „nu fragmenta” și crește dimensiunea încărcăturii găsește MTU-ul utilizabil al traseului mult mai sigur decât un ping care pur și simplu reușește. Includeți în test și aplicația care eșuează: un timeout ICMP poate reflecta filtrare, iar un ping mic reușit nu spune nimic despre un pachet de aplicație de dimensiune completă.

mssfix limitează MSS-ul anunțat pentru sesiunile TCP din interiorul tunelului, ceea ce ajută TCP și nu face nimic pentru o încărcare UDP internă. Fragmentarea și offload-ul au propriile condiții de compatibilitate. Alegeți un mecanism pentru problema demonstrată în loc să schimbați mai multe deodată pentru a liniști o linie de jurnal.

Păstrați valorile efective împreună cu rezultatul

Notați valorile efective originale și corectate lângă rezultatul unui transfer real. Această pereche este cea care separă o opțiune de profil învechită de o problemă de MTU pe traseu care există independent. Fără ea, următorul cititor vede un avertisment dispărut și presupune că rețeaua s-a schimbat.

Suprimarea verificării consecvenței nu împacă nimic. Elimină observația și lasă ambele configurații așa cum erau.