TUN/TAP: ûnjildich argumint — OpenVPN-ramme komt net oerien

De klant ferifiearret, it loch seit ferbûn, en gjin pakket stekt de tunnel oer. De server einiget de poging mei write to TUN/TAP: Invalid argument (code=22), wat as in stjoerderflater liket en meastentiids net is. Op routers en lytse Linux-servers betsjut dy regel meast dat de beide kanten it net iens binne oer hoe’t datapakketten yn rammen set wurde, sadat de kernel de ûntsifere buffer ôfwiist dy’t er krige. De routing is op dat stuit noch net test.

In korrekte routingtabel en in brutsen ramme-ôfspraak sjogge der fan de klant ôf itselde út: ferbûn, en neat wurket.

De tunnel komt omheech en neat stekt him oer

Skriuflaters op it tunnelapparaat barre nei ûntsifering en foar routing. De daemon ûntsiferet in pakket, jout it oan de ynterface, en de ynterface wegeret it omdat de buffer net oerienkomt mei wat dat apparaat ferwachtet. Kode 22 is it algemiene antwurd foar ûnjildich argumint, dus de nuttige ynformaasje is de laach: dit is it datapad en net de hânskudding. As ferkear juster rûn en hjoed stoppen is sûnder konfiguraasjeferoaring, fertink dan in pakket- of firmware-opwurdearring dy’t in standertwearde ferskuord hat, foardat jo it netwurk fertinke.

Lês it loch om de ynstelling fan it datakanaal hinne ynstee fan de earste flater. De úthannele kompresjemodus, it type dev en de tawapene opsjes ferskine allegear by hegere wiidweidichheid, en se fertelle jo hokker fan de trije ôfwikingen jo hawwe.

Kompresje is ramme, net bânbreedte

Mei kompresje ynskeakele draacht elk datapakket in kop dy’t beskriuwt hoe’t it kodearre is, en beide kanten moatte it oer dy kop iens wêze. In server dy’t noch comp-lzo út in âlde foarbyldkonfiguraasje draacht, keppele oan in klant sûnder kompresjeregel, jout krekt dizze flater: de server ferwachtet in kop dy’t de klant nea skreaun hat. comp-lzo mei compress lz4-v2 minge mislearret itselde, om’t de algoritmen ferskille sels al wurde beide kompresje neamd. De opsje is in ramme-kontrakt en net in bânbreedtefunksje op moderne ferbiningen.

Fersjonegedrach foeget in falstrik ta. De 2.5-searje begûn ferâlderewarskôgings foar kompresje-opsjes te jaan, en 2.6 lûkt in line tusken it wegerjen fan komprimearre pakketten en it gewoan ûnkomprimearre litten fan gegevens. In firmware-opwurdearring fan ’e router kin dêrom de effektive ôfspraak feroarje sûnder dat immen de tunnel bewurket.

Lynje beide kanten út of helje it fan beide ôf

List elke kompresjedirektive op: it serverbestân, alle tawapene opsjes, klientspesifike bestannen en it klantprofyl. comp-lzo op ’e server hat itselde wurd op ’e klant nedich, en adaptive is de âlde standertwearde dy’t de bleate opsje meastentiids op âldere builds betsjut. In GUI-skeakel fan ’e router mei it label LZO of kompresje skriuwt deselde opsje, dus set it oerienkommend ynstee fan algoritmen te mingjen. Nim net oan dat in ferlykbere namme kompatibel is.

As kompresje net winske is, helje it dan bewust fan beide kanten ôf. allow-compression no op ’e server wegeret komprimearre pakketten, mar pas nei’t klanten ophâlden binne se oan te bieden; it tapasse wylst in klant noch kompresje stjoert, makket de ôfwiking yn ’e oare rjochting op ’e nij.

Kontrolearje de push en it type apparaat

In server kin in kompresjedirektive fan syn haadbestân of fan in klientspesifyk bestân push, en in klant kin tawapene opsjes mei pull-filter weilitte. Ferbyn ien klant by wiidweidichheid 4, lês wat de server oankundige hat tsjin wat de klant akseptearre, en befêstigje dan dat gjin filter it fuorthelle hat. As beide kanten no iens binne en de flater bliuwt, sjoch nei it type apparaat: dev tap oan ’e iene kant en dev tun oan ’e oare kinne gjin frames útwikselje, en de kernel wegeret it skriuwen op deselde wize.

In brêge TAP-útrulling hat in echte brêge op ’e server nedich, net allinnich in oare apparaatnamme. In ynterface omneame nei tap0 sûnder it oan in brêge ta te foegjen, makket in apparaat dat it skriuwen akseptearret en nearne hinne giet.

Ferifiearje dan mei ien klant en ien bestimming: ping it tunneladres fan ’e server, dan in host op syn LAN. It earste bewiist it datakanaal en it twadde it trochstjoeren.