TUN/TAP: ongeldig argument — OpenVPN-framing komt niet overeen

De client authenticeert, de log zegt verbonden, en er gaat geen enkel pakket door de tunnel. De server beëindigt de poging met write to TUN/TAP: Invalid argument (code=22), wat op een stuurprogrammafout lijkt en meestal niet zo is. Op routers en kleine Linux-servers betekent die regel meestal dat de twee peers het niet eens zijn over hoe datapakketten worden geframed, waardoor de kernel de ontsleutelde buffer weigert die hij kreeg. Routing is op dat punt nog niet getest.

Een correcte routetabel en een kapotte framingafspraak zien er vanaf de client hetzelfde uit: verbonden, en niets werkt.

De tunnel komt omhoog en er gaat niets door

Schrijffouten op het tunnelapparaat ontstaan na ontsleuteling en vóór routing. De daemon ontsleutelt een pakket, geeft het aan de interface, en de interface weigert het omdat de buffer niet overeenkomt met wat dat apparaat verwacht. Code 22 is het algemene antwoord voor een ongeldig argument, dus de nuttige informatie is de laag: dit is het datapad en niet de handshake. Als verkeer gisteren liep en vandaag stopt zonder configuratiewijziging, verdenk dan een pakket- of firmware-update die een standaardwaarde verschoof voordat je het netwerk verdenkt.

Lees de log rond de configuratie van het datakanaal in plaats van de eerste fout. De onderhandelde compressiemodus, het dev-type en de gepushte opties verschijnen allemaal bij hogere uitgebreidheid, en ze vertellen je welke van de drie afwijkingen je hebt.

Compressie is framing, niet bandbreedte

Met compressie ingeschakeld draagt elk datapakket een header die beschrijft hoe het is gecodeerd, en beide kanten moeten het over die header eens zijn. Een server die nog comp-lzo uit een oude voorbeeldconfiguratie draagt, gecombineerd met een client zonder compressieregel, levert precies deze fout: de server verwacht een header die de client nooit schreef. comp-lzo met compress lz4-v2 mengen mislukt op dezelfde manier, omdat de algoritmen verschillen ook al heten beide compressie. De optie is een framingcontract en geen bandbreedtefunctie op moderne verbindingen.

Versiegedrag voegt een valkuil toe. De 2.5-reeks begon verouderingswaarschuwingen voor compressieopties te geven, en 2.6 trekt een grens tussen het weigeren van gecomprimeerde pakketten en het simpelweg ongecomprimeerd laten van gegevens. Een firmware-update van de router kan daardoor de effectieve afspraak veranderen zonder dat iemand de tunnel bewerkt.

Lijn beide kanten uit of verwijder het aan beide kanten

Som elke compressiedirectief op: het serverbestand, eventuele gepushte opties, klientspecifieke bestanden en het clientprofiel. comp-lzo op de server vereist hetzelfde woord op de client, en adaptive is de oude standaard die de kale optie gewoonlijk op oudere builds betekent. Een GUI-schakelaar van de router met het label LZO of compressie schrijft diezelfde optie, dus stel hem zo in dat hij overeenkomt in plaats van algoritmen te mengen. Ga er niet van uit dat een vergelijkbare naam compatibel is.

Als compressie niet gewenst is, verwijder die dan bewust van beide kanten. allow-compression no op de server weigert gecomprimeerde pakketten, maar pas nadat clients zijn gestopt ze aan te bieden; het toepassen terwijl een client nog compressie pusht, herschept de afwijking in de andere richting.

Controleer de push en het apparaattype

Een server kan een compressiedirectief pushen vanuit zijn hoofdbeheerbestand of vanuit een klientspecifiek bestand, en een client kan gepushte opties laten vallen met pull-filter. Verbind één client bij uitgebreidheid 4, lees wat de server aankondigde tegen wat de client accepteerde, en bevestig dan dat geen filter het verwijderde. Als beide kanten het nu eens zijn en de fout blijft, kijk naar het apparaattype: dev tap aan de ene kant en dev tun aan de andere kunnen geen frames uitwisselen, en de kernel weigert het schrijven op dezelfde manier.

Een gebrugde TAP-implementatie vereist een echte bridge op de server, niet alleen een andere apparaatnaam. Een interface hernoemen naar tap0 zonder hem aan een bridge toe te voegen, levert een apparaat op dat het schrijven accepteert en nergens heen gaat.

Verifieer daarna met één client en één bestemming: ping het tunneladres van de server, dan een host op zijn LAN. Het eerste bewijst het datakanaal en het tweede de doorsturing.