TUN/TAP ongeldige argument: OpenVPN-raamstemming

Die kliënt verifieer, die log sê verbind, en geen pakkie kruis die tonnel nie. Die bediener beëindig die poging met write to TUN/TAP: Invalid argument (code=22), wat soos 'n drywerfout lyk en gewoonlik nie is nie. Op routers en klein Linux-bedienerders beteken daardie reël meestal dat die twee eweknieë nie saamstem oor hoe datapakkies geraam word nie, so die kernel verwerp die gedekripteerde buffer wat aan hom gegee is. Roetering is op daardie punt nog nie getoets nie.

’n Korrekte roetertabel en ’n stukkende raamwerkooreenkoms lyk van die kliënt se kant dieselfde: verbind, en niks werk nie.

Die tonnel kom op en niks kruis dit nie

Skryffoute op die tonneltoestel gebeur ná dekripsie en voor roetering. Die daemon dekripteer ’n pakkie, gee dit aan die koppelvlak, en die koppelvlak weier dit omdat die buffer nie ooreenstem met wat daardie toestel verwag nie. Kode 22 is die algemene antwoord vir ongeldige argument, so die nuttige inligting is die laag: dit is die datapad eerder as die handdruk. As verkeer gister geloop het en vandag stop sonder enige konfigurasieverandering, vermoed ’n pakket- of firmware-opgradering wat ’n verstekwaarde verskuif het voordat jy die netwerk vermoed.

Lees die log rondom die datakanaal-opstelling eerder as die eerste fout. Die onderhandelde kompressiemodus, die dev-tipe en die gestuurde opsies verskyn almal by hoër breedsprakigheid, en hulle sê vir jou watter van die drie teenstrydighede jy het.

Kompressie is raamwerk, nie bandwydte nie

Met kompressie geaktiveer dra elke datapakkie ’n kop wat beskryf hoe dit geënkodeer is, en beide kante moet oor daardie kop saamstem. ’n Bediener wat nog comp-lzo uit ’n ou voorbeeldkonfigurasie dra, saam met ’n kliënt wat geen kompressielyn het nie, lewer presies hierdie fout: die bediener verwag ’n kop wat die kliënt nooit geskryf het nie. Om comp-lzo met compress lz4-v2 te meng, misluk op dieselfde manier, want die algoritmes verskil selfs al word albei kompressie genoem. Die opsie is ’n raamwerkkontrak eerder as ’n bandwydtefunksie op moderne skakels.

Weergawegedrag voeg ’n lokval by. Die 2.5-reeks het begin om waarskuwings oor veroudering vir kompressieopsies uit te reik, en 2.6 trek ’n lyn tussen die weiering van saamgeperste pakkies en bloot die los van data ongekomprimeer. ’n Router-firmware-opgradering kan dus die effektiewe ooreenkoms verander sonder dat iemand die tonnel wysig.

Belyn beide kante of verwyder dit aan albei

Rangskik elke kompressieriglyn: die bedienerlêer, enige gestuurde opsies, kliëntspesifieke lêers en die kliëntprofiel. comp-lzo op die bediener benodig dieselfde woord op die kliënt, en adaptive is die ou verstekwaarde wat die kaal opsie gewoonlik op ouer weergawes beteken. ’n Router se GUI-skakelaar gemerk LZO of kompressie skryf daardie selfde opsie, so stel dit om te pas eerder as om algoritmes te meng. Moenie aanneem dat ’n soortgelyke naam versoenbaar is nie.

As kompressie nie verlang word nie, verwyder dit doelbewus van beide kante. allow-compression no op die bediener weier saamgeperste pakkies, maar eers nadat kliënte opgehou het om hulle aan te bied; om dit toe te pas terwyl ’n kliënt nog kompressie stuur, skep die teenstrydigheid in die ander rigting weer.

Kontroleer die stoot en die toesteltipe

’n Bediener kan ’n kompressieriglyn uit sy hoof-lêer of uit ’n kliëntspesifieke een stuur, en ’n kliënt kan gestuurde opsies met pull-filter laat val. Verbind een kliënt by breedsprakigheid 4, lees wat die bediener aangekondig het teen wat die kliënt aanvaar het, en bevestig dan dat geen filter dit verwyder het nie. As beide kante nou saamstem en die fout bly, kyk na die toesteltipe: dev tap aan die een kant en dev tun aan die ander kant kan nie raampies uitruil nie, en die kernel verwerp die skryf op dieselfde manier.

’n Gebrugde TAP-ontplooiing benodig ’n werklike brug op die bediener, nie net ’n ander toestelnaam nie. Om ’n koppelvlak na tap0 te hernoem sonder om dit by ’n brug te voeg, lewer ’n toestel wat die skryf aanvaar en nêrens heen gaan nie.

Verifieer dan met een kliënt en een bestemming: ping die bediener se tonneladres, dan ’n gasheer op sy LAN. Die eerste bewys die datakanaal en die tweede bewys aanstuur.