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

Klienten godkjenner, loggen sier tilkoblet, og ingen pakke krysser tunnelen. Serveren avslutter forsøket med write to TUN/TAP: Invalid argument (code=22), som ser ut som en driverfeil og vanligvis ikke er det. På rutere og små Linux-servere betyr den linjen oftest at de to partene ikke er enige om hvordan datapakker rammes inn, så kjernen avviser den dekrypterte bufferen den fikk. Rutingen er ikke testet på det tidspunktet.

En korrekt rutetabell og en brutt rammeavtale ser like ut fra klienten: tilkoblet, og ingenting virker.

Tunnelen kommer opp og ingenting krysser den

Skrivefeil på tunneleenheten oppstår etter dekryptering og før ruting. Daemonen dekrypterer en pakke, gir den til grensesnittet, og grensesnittet avviser den fordi bufferen ikke samsvarer med det enheten forventer. Kode 22 er det generiske svaret på ugyldig argument, så den nyttige informasjonen er laget: dette er datastien og ikke håndtrykket. Hvis trafikken gikk i går og stoppet i dag uten konfigurasjonsendring, mistenker du en pakke- eller fastvareoppgradering som flyttet en standardverdi, før du mistenker nettverket.

Les loggen rundt oppsettet av datakanalen i stedet for den første feilen. Den forhandlede komprimeringsmodusen, dev-typen og de skyvede alternativene vises alle ved høyere detaljrikdom, og de forteller deg hvilken av de tre avvikene du har.

Komprimering er innramming, ikke båndbredde

Når komprimering er aktivert, bærer hver datapakke en header som beskriver hvordan den ble kodet, og begge ender må være enige om den headeren. En server som fortsatt bærer comp-lzo fra en gammel eksempelkonfigurasjon, sammen med en klient uten komprimeringslinje, gir nøyaktig denne feilen: serveren forventer en header som klienten aldri skrev. Å blande comp-lzo med compress lz4-v2 feiler på samme måte, siden algoritmene er forskjellige selv om begge kalles komprimering. Alternativet er en rammeavtale og ikke en båndbreddefunksjon på moderne lenker.

Versjonsatferd legger til en felle. 2.5-serien begynte å utstede foreldelsesadvarsler for komprimeringsalternativer, og 2.6 trekker en linje mellom å avvise komprimerte pakker og bare la data være ukomprimerte. En fastvareoppdatering på ruteren kan derfor endre den effektive avtalen uten at noen redigerer tunnelen.

Juster begge ender eller fjern det fra begge

List opp hver komprimeringsdirektiv: serverfilen, eventuelle skyvede alternativer, klientspesifikke filer og klientprofilen. comp-lzo på serveren trenger det samme ordet på klienten, og adaptive er den gamle standarden som det bare alternativet vanligvis betyr på eldre bygg. En rutergrensesnittbryter merket LZO eller komprimering skriver det samme alternativet, så sett den til å samsvare i stedet for å blande algoritmer. Ikke ant at et lignende navn er kompatibelt.

Hvis komprimering ikke er ønsket, fjern den bevisst fra begge ender. allow-compression no på serveren avviser komprimerte pakker, men først etter at klientene har stoppet å tilby dem; å bruke det mens en klient fortsatt skyver komprimering gjenoppretter avviket i den andre retningen.

Kontroller skyvingen og enhetstypen

En server kan skyve et komprimeringsdirektiv fra hovedfilen eller fra en klientspesifikk fil, og en klient kan droppe skyvede alternativer med pull-filter. Koble til én klient ved detaljrikdom 4, les hva serveren kunngjorde mot hva klienten aksepterte, og bekreft deretter at ingen filter fjernet det. Hvis begge sider nå er enige og feilen vedvarer, se på enhetstypen: dev tap i den ene enden og dev tun i den andre kan ikke utveksle rammer, og kjernen avviser skrivingen på samme måte.

En broet TAP-utrulling krever en ekte bro på serveren, ikke bare et annet enhetsnavn. Å gi et grensesnitt nytt navn til tap0 uten å legge det til en bro gir en enhet som aksepterer skrivingen og ender ingen steder.

Bekreft deretter med én klient og én destinasjon: ping serverens tunneladresse, deretter en vert på LAN-et. Den første beviser datakanalen og den andre videresendingen.