Klienten godkender, loggen siger forbundet, og ingen pakke krydser tunnelen. Serveren afslutter forsøget med write to TUN/TAP: Invalid argument (code=22), hvilket lyder som en driverfejl og normalt ikke er det. På routere og små Linux-servere betyder den linje oftest, at de to parter ikke er enige om, hvordan datapakker rammes ind, så kernen afviser den dekrypterede buffer, den fik. Routingen er ikke testet på det tidspunkt.

En korrekt rutetabel og en brudt rammeaftale ser ens ud fra klienten: forbundet, og intet virker.

Tunnelen kommer op, og intet krydser den

Skrivefejl på tunneleenheden opstår efter dekryptering og før routing. Daemonen dekrypterer en pakke, giver den videre til grænsefladen, og grænsefladen afviser den, fordi bufferen ikke svarer til det, den enhed forventer. Kode 22 er det generiske svar om ugyldigt argument, så den nyttige information er laget: dette er datastien og ikke håndtrykket. Hvis trafikken kørte i går og stoppede i dag uden konfigurationsændring, skal du mistænke en pakke- eller firmwareopgradering, der flyttede en standardværdi, før du mistænker netværket.

Læs loggen omkring opsætningen af datakanalen i stedet for den første fejl. Den forhandlede komprimeringstilstand, dev-typen og de skubbede muligheder vises alle ved højere detaljeringsgrad, og de fortæller dig, hvilken af de tre uoverensstemmelser du har.

Komprimering er rammeformat, ikke båndbredde

Når komprimering er aktiveret, bærer hver datapakke et header, der beskriver, hvordan den blev kodet, og begge ender skal være enige om det header. En server, der stadig bærer comp-lzo fra en gammel eksempelkonfiguration, parret med en klient uden en komprimeringslinje, giver præcis denne fejl: serveren forventer et header, som klienten aldrig skrev. At blande comp-lzo med compress lz4-v2 fejler på samme måde, da algoritmerne er forskellige, selvom begge kaldes komprimering. Valget er en rammeaftale snarere end en båndbreddefunktion på moderne links.

Versionsadfærd tilføjer en fælde. 2.5-serien begyndte at udsende forældelsesadvarsler for komprimeringsvalg, og 2.6 trækker en grænse mellem at afvise komprimerede pakker og blot at lade data være ukomprimerede. En firmwareopdatering på routeren kan derfor ændre den effektive aftale, uden at nogen redigerer tunnelen.

Tilpas begge ender eller fjern det fra begge

Opret en liste over hver komprimeringsdirektiv: serverfilen, eventuelle skubbede muligheder, klientspecifikke filer og klientprofilen. comp-lzo på serveren kræver det samme ord på klienten, og adaptive er den gamle standard, som den nøgne mulighed normalt betyder på ældre builds. En routers GUI-kontakt mærket LZO eller komprimering skriver den samme mulighed, så indstil den til at matche i stedet for at blande algoritmer. Antag ikke, at et lignende navn er kompatibelt.

Hvis komprimering ikke ønskes, skal du fjerne den bevidst fra begge ender. allow-compression no på serveren afviser komprimerede pakker, men først når klienterne er stoppet med at tilbyde dem; at anvende det, mens en klient stadig skubber komprimering, genskaber uoverensstemmelsen i den anden retning.

Kontrollér skubbet og enhedstypen

En server kan skubbe et komprimeringsdirektiv fra sin hovedfil eller fra en klientspecifik fil, og en klient kan droppe skubbede muligheder med pull-filter. Forbind én klient ved detaljeringsgrad 4, læs, hvad serveren annoncerede, op imod hvad klienten accepterede, og bekræft derefter, at intet filter fjernede det. Hvis begge sider nu er enige, og fejlen består, se på enhedstypen: dev tap i den ene ende og dev tun i den anden kan ikke udveksle rammer, og kernen afviser skrivningen på samme måde.

En broet TAP-udrulning kræver en egentlig bro på serveren, ikke blot et andet enhedsnavn. At omdøbe en grænseflade til tap0 uden at føje den til en bro giver en enhed, der accepterer skrivningen og ender ingen steder.

Bekræft derefter med én klient og én destination: ping serverens tunneladresse, derefter en vært på dens LAN. Det første beviser datakanalen, og det andet beviser videresendelsen.

Relaterede artikler