TUN/TAP: virheellinen argumentti — OpenVPN:n kehystyksen ero
Koodin 22 kirjoitusvirheet tarkoittavat yleensä, että osapuolet eivät sovi datapakettien kehystyksestä, eivät ajurivikaa. Vertaa pakkausta molemmissa päissä ja sitten laitteen tyyppiä.
Asiakas todentaa itsensä, loki sanoo yhdistetty, eikä mikään paketti ylitä tunnelia. Palvelin päättää yrityksen write to TUN/TAP: Invalid argument (code=22)-viestiin, joka näyttää ajurivialta eikä yleensä ole sitä. Reitittimissä ja pienissä Linux-palvelimissa tuo rivi tarkoittaa useimmiten, että kaksi osapuolta eivät sovi siitä, miten datapaketit kehystetään, joten ydin hylkää sille annetun salauksen puretun puskurin. Reititystä ei ole vielä testattu siinä vaiheessa.
Oikea reititystaulu ja rikkinäinen kehystyssopimus näyttävät asiakkaan puolelta samalta: yhdistetty, eikä mikään toimi.
Tunneli nousee eikä mikään ylitä sitä
Kirjoitusvirheet tunnelilaitteessa tapahtuvat salauksen purkamisen jälkeen ja ennen reititystä. Daemon purkaa paketin salauksen, antaa sen rajapinnalle, ja rajapinta hylkää sen, koska puskuri ei vastaa sitä, mitä tämä laite odottaa. Koodi 22 on yleinen vastaus virheelliselle argumentille, joten hyödyllinen tieto on kerros: tämä on datapolku eikä kättely. Jos liikenne toimi eilen ja pysähtyi tänään ilman kokoonpanon muutosta, epäile paketin tai laiteohjelmiston päivitystä, joka siirsi oletusarvoa, ennen kuin epäilet verkkoa.
Lue lokia datakanavan asetusten ympäriltä ensimmäisen virheen sijaan. Neuvoteltu pakkaustila, dev-tyyppi ja työnnetyt valinnat näkyvät kaikki suuremmalla yksityiskohtaisuudella, ja ne kertovat, mikä kolmesta erosta sinulla on.
Pakkaus on kehystys, ei kaistanleveys
Kun pakkaus on käytössä, jokainen datapaketti kuljettaa otsikkoa, joka kuvaa, miten se koodattiin, ja molempien päiden on sovittava siitä otsikosta. Palvelin, joka yhä kuljettaa comp-lzo-asetusta vanhasta esimerkkikokoonpanosta, yhdessä asiakkaan kanssa, jolla ei ole pakkausriviä, tuottaa juuri tämän virheen: palvelin odottaa otsikkoa, jota asiakas ei koskaan kirjoittanut. comp-lzo-asetuksen sekoittaminen compress lz4-v2-asetukseen epäonnistuu samalla tavalla, koska algoritmit eroavat, vaikka molempia kutsutaan pakkaukseksi. Valinta on kehystyssopimus eikä kaistanleveysominaisuus nykyaikaisilla yhteyksillä.
Versiokäyttäytyminen lisää ansan. 2.5-sarja alkoi antaa vanhentumisvaroituksia pakkausvalinnoista, ja 2.6 vetää rajan pakattujen pakettien hylkäämisen ja datan pelkän pakkaamattomana jättämisen välille. Siten reitittimen laiteohjelmistopäivitys voi muuttaa voimassa olevaa sopimusta ilman, että kukaan muokkaa tunnelia.
Kohdista molemmat päät tai poista se molemmista
Listaa jokainen pakkausdirektiivi: palvelintiedosto, kaikki työnnetyt valinnat, asiakaskohtaiset tiedostot ja asiakasprofiili. comp-lzo palvelimella tarvitsee saman sanan asiakkaalla, ja adaptive on peritty oletusarvo, jota pelkkä valinta yleensä tarkoittaa vanhemmissa koosteissa. Reitittimen GUI-kytkin, jossa on merkintä LZO tai pakkaus, kirjoittaa saman valinnan, joten aseta se vastaamaan sen sijaan, että sekoitat algoritmeja. Älä oleta, että samannäköinen nimi on yhteensopiva.
Jos pakkausta ei haluta, poista se tarkoituksella molemmista päistä. allow-compression no palvelimella hylkää pakatut paketit, mutta vasta kun asiakkaat ovat lopettaneet niiden tarjoamisen; sen käyttäminen, kun asiakas yhä työntää pakkausta, luo eron uudelleen toiseen suuntaan.
Tarkista työntö ja laitteen tyyppi
Palvelin voi työntää pakkausdirektiivin päätiedostostaan tai asiakaskohtaisesta tiedostosta, ja asiakas voi pudottaa työnnetyt valinnat pull-filter-asetuksella. Yhdistä yksi asiakas yksityiskohtaisuudella 4, lue, mitä palvelin ilmoitti, verrattuna siihen, mitä asiakas hyväksyi, ja vahvista sitten, ettei mikään suodatin poistanut sitä. Jos molemmat puolet nyt sopivat ja virhe jatkuu, katso laitteen tyyppiä: dev tap toisessa päässä ja dev tun toisessa eivät voi vaihtaa kehyksiä, ja ydin hylkää kirjoituksen samalla tavalla.
Sillattu TAP-käyttöönotto tarvitsee todellisen sillan palvelimelle, ei vain erilaista laitenimeä. Rajapinnan nimeäminen uudelleen tap0-nimiseksi ilman sillan lisäämistä tuottaa laitteen, joka hyväksyy kirjoituksen eikä mene mihinkään.
Vahvista sitten yhdellä asiakkaalla ja yhdellä kohteella: pingaa palvelimen tunneliosoitetta, sitten isäntää sen lähiverkossa. Ensimmäinen todistaa datakanavan ja toinen edelleenlähetyksen.