TUN/TAP: argument invalid — nepotrivire de încadrare OpenVPN

Clientul se autentifică, jurnalul spune conectat, și niciun pachet nu traversează tunelul. Serverul încheie încercarea cu write to TUN/TAP: Invalid argument (code=22), care arată ca o defecțiune a driverului și de obicei nu este. Pe routere și servere Linux mici, acea linie înseamnă cel mai adesea că cele două capete nu sunt de acord asupra modului în care pachetele de date sunt încadrate, așa că nucleul respinge bufferul decriptat care i-a fost dat. Rutarea nu a fost încă testată în acel moment.

Un tabel de rutare corect și un acord de încadrare rupt arată la fel din perspectiva clientului: conectat, și nimic nu funcționează.

Tunelul se ridică și nimic nu îl traversează

Erorile de scriere pe dispozitivul tunelului apar după decriptare și înainte de rutare. Daemonul decriptează un pachet, îl predă interfeței, iar interfața îl respinge pentru că bufferul nu corespunde cu ceea ce așteaptă acel dispozitiv. Codul 22 este răspunsul generic pentru argument invalid, deci informația utilă este stratul: aceasta este calea de date și nu handshake-ul. Dacă traficul funcționa ieri și s-a oprit astăzi fără nicio modificare de configurare, suspectați o actualizare de pachet sau firmware care a mutat o valoare implicită înainte de a suspecta rețeaua.

Citiți jurnalul din jurul configurării canalului de date în loc de prima eroare. Modul de compresie negociat, tipul dev și opțiunile împinse apar toate la o verbositate mai mare, și vă spun care dintre cele trei nepotriviri o aveți.

Compresia este încadrare, nu lățime de bandă

Când compresia este activată, fiecare pachet de date poartă un antet care descrie cum a fost codificat, iar ambele capete trebuie să fie de acord asupra acelui antet. Un server care încă poartă comp-lzo dintr-o configurație exemplu veche, împreună cu un client fără linie de compresie, produce exact această eroare: serverul așteaptă un antet pe care clientul nu l-a scris niciodată. Amestecarea comp-lzo cu compress lz4-v2 eșuează la fel, deoarece algoritmii diferă chiar dacă ambele se numesc compresie. Opțiunea este un contract de încadrare și nu o caracteristică de lățime de bandă pe legăturile moderne.

Comportamentul versiunilor adaugă o capcană. Seria 2.5 a început să emită avertismente de depreciere pentru opțiunile de compresie, iar 2.6 trasează o linie între respingerea pachetelor comprimate și simpla lăsare a datelor necomprimate. O actualizare de firmware a routerului poate deci schimba acordul efectiv fără ca cineva să editeze tunelul.

Aliniați ambele capete sau eliminați din ambele

Enumerați fiecare directivă de compresie: fișierul serverului, orice opțiuni împinse, fișierele specifice clientului și profilul clientului. comp-lzo pe server necesită același cuvânt pe client, iar adaptive este valoarea implicită moștenită pe care opțiunea goală o înseamnă de obicei pe build-urile mai vechi. Comutatorul GUI al routerului etichetat LZO sau compresie scrie aceeași opțiune, așa că setați-l să corespundă în loc să amestecați algoritmi. Nu presupuneți că un nume asemănător este compatibil.

Dacă compresia nu este dorită, eliminați-o deliberat din ambele capete. allow-compression no pe server respinge pachetele comprimate, dar numai după ce clienții au încetat să le ofere; aplicarea lui în timp ce un client încă împinge compresie recreează nepotrivirea în direcția opusă.

Verificați împingerea și tipul dispozitivului

Un server poate împinge o directivă de compresie din fișierul său principal sau dintr-un fișier specific clientului, iar un client poate renunța la opțiunile împinse cu pull-filter. Conectați un client la verbositate 4, citiți ce a anunțat serverul față de ce a acceptat clientul, apoi confirmați că niciun filtru nu l-a eliminat. Dacă ambele părți sunt acum de acord și eroarea persistă, uitați-vă la tipul dispozitivului: dev tap la un capăt și dev tun la celălalt nu pot schimba cadre, iar nucleul respinge scrierea în același mod.

O implementare TAP cu punte necesită o punte reală pe server, nu doar un nume de dispozitiv diferit. Redenumirea unei interfețe în tap0 fără a o adăuga la o punte produce un dispozitiv care acceptă scrierea și nu merge nicăieri.

Apoi verificați cu un client și o destinație: faceți ping la adresa tunelului serverului, apoi la un host din LAN-ul său. Primul dovedește canalul de date, iar al doilea redirecționarea.