TUN/TAP: ugyldig argument — rammeavtalen i OpenVPN stemmer ikkje

Klienten godkjenner, loggen seier tilkopla, og ingen pakke kryssar tunnelen. Tenaren avsluttar forsøket med write to TUN/TAP: Invalid argument (code=22), som ser ut som ein drivarfeil og vanlegvis ikkje er det. På rutarar og små Linux-tenarar tyder den linja oftast at dei to partane ikkje er samde om korleis datapakkar blir ramma inn, så kjernen avviser den dekrypterte bufferen han fekk. Rutinga er ikkje testa på det tidspunktet.

Ein korrekt rutetabell og ein broten rammeavtale ser like ut frå klienten: tilkopla, og ingenting verkar.

Tunnelen kjem opp og ingenting kryssar han

Skrivefeil på tunneleininga oppstår etter dekryptering og før ruting. Daemonen dekrypterer ein pakke, gir han til grensesnittet, og grensesnittet avviser han fordi bufferen ikkje svarer til det eininga ventar. Kode 22 er det generiske svaret på ugyldig argument, så den nyttige informasjonen er laget: dette er datastien og ikkje handtrykket. Viss trafikken gjekk i går og stoppa i dag utan konfigurasjonsendring, mistenk ein pakke- eller fastvareoppgradering som flytta ein standardverdi, før du mistenk nettverket.

Les loggen rundt oppsettet av datakanalen i staden for den første feilen. Den forhandla komprimeringsmodusen, dev-typen og dei skyva alternativa viser seg alle ved høgare detaljrikdom, og dei fortel deg kva av dei tre avvika du har.

Komprimering er innramming, ikkje bandbreidd

Når komprimering er aktivert, ber kvar datapakke ein header som skildrar korleis han vart koda, og båe endar må vere samde om den headeren. Ein tenar som framleis ber comp-lzo frå ein gamal døme-konfigurasjon, saman med ein klient utan komprimeringslinje, gir nøyaktig denne feilen: tenaren ventar ein header som klienten aldri skreiv. Å blande comp-lzo med compress lz4-v2 feilar på same måte, sidan algoritmane er ulike sjølv om båe blir kalla komprimering. Alternativet er ein rammeavtale og ikkje ein bandbreiddfunksjon på moderne lenkjer.

Versjonsåtferd legg til ei felle. 2.5-serien byrja å gje ut foreldingsåtvaringar for komprimeringsalternativ, og 2.6 dreg ei line mellom å avvise komprimerte pakkar og berre la data vere ukomprimerte. Ei fastvareoppdatering på rutaren kan difor endre den effektive avtalen utan at nokon redigerer tunnelen.

Juster båe endar eller fjern det frå båe

List opp kvar komprimeringsdirektiv: tenarfilen, eventuelle skyva alternativ, klientspesifikke filer og klientprofilen. comp-lzo på tenaren treng det same ordet på klienten, og adaptive er den gamle standarden som det nakne alternativet vanlegvis tyder på eldre bygg. Ein rutargrensesnittbrytar merkt LZO eller komprimering skriv det same alternativet, så set han til å samsvare i staden for å blande algoritmar. Ikkje gå ut frå at eit liknande namn er kompatibelt.

Viss komprimering ikkje er ønskt, fjern ho medvite frå båe endar. allow-compression no på tenaren avviser komprimerte pakkar, men først etter at klientane har slutta å tilby dei; å bruke det medan ein klient framleis skyv komprimering gjenopprettar avviket i den andre retninga.

Kontroller skyvinga og einingstypen

Ein tenar kan skyve eit komprimeringsdirektiv frå hovudfila eller frå ei klientspesifikk fil, og ein klient kan droppe skyva alternativ med pull-filter. Kople til éin klient ved detaljrikdom 4, les kva tenaren kunngjorde mot kva klienten godtok, og stadfest deretter at ingen filter fjerna det. Viss båe sider no er samde og feilen held fram, sjå på einingstypen: dev tap i den eine enden og dev tun i den andre kan ikkje utveksle rammer, og kjernen avviser skrivinga på same måte.

Ein brúa TAP-utrulling krev ei ekte bru på tenaren, ikkje berre eit anna eining namn. Å gje eit grensesnitt nytt namn til tap0 utan å leggje det til ei bru gir ei eining som godtek skrivinga og endar ingen stad.

Stadfest deretter med éin klient og éin destinasjon: ping tunneladressa til tenaren, deretter ein vert på LAN-et. Den første beviser datakanalen og den andre videresendinga.