TUN/TAP: sobimatu argument — OpenVPN-i raamistiku erinevus

Klient autendib end, logi ütleb ühendatud, ja ükski pakett ei läbi tunnelit. Server lõpetab katse koodiga write to TUN/TAP: Invalid argument (code=22), mis näeb välja nagu draiveri rike ja tavaliselt ei ole seda. Ruuteritel ja väikestel Linuxi serveritel tähendab see rida kõige sagedamini, et kaks poolt ei ole ühel meelel, kuidas andmepakette raamistatakse, mistõttu kernel lükkab tagasi talle antud dekrüpteeritud puhvri. Marsruutimist ei ole selles punktis veel testitud.

Õige marsruutimistabel ja katkine raamistuskokkulepe näevad kliendi poolt ühesugused välja: ühendatud, ja miski ei tööta.

Tunnel tõuseb ja miski ei läbi seda

Kirjutamisvead tunnelseadmel tekivad pärast dekrüpteerimist ja enne marsruutimist. Deemon dekrüpteerib paketi, annab selle liidesele, ja liides lükkab selle tagasi, sest puhver ei vasta sellele, mida see seade ootab. Kood 22 on üldine vastus sobimatule argumendile, seega on kasulik teave kiht: see on andmetee, mitte kätlemine. Kui liiklus töötas eile ja peatus täna ilma konfiguratsiooni muutmiseta, kahtlustage paketi- või püsivara uuendust, mis nihutas vaikeväärtust, enne kui kahtlustate võrku.

Lugege logi andmekanali seadistamise ümber, mitte esimest viga. Kokkulepitud tihendusrežiim, dev tüüp ja edastatud valikud ilmuvad kõik suuremal detailsusel, ja need ütlevad, milline kolmest erinevusest teil on.

Tihendus on raamistamine, mitte ribalaius

Kui tihendus on lubatud, kannab iga andmepakett päist, mis kirjeldab, kuidas see kodeeriti, ja mõlemad otsad peavad selle päise osas kokku leppima. Server, mis kannab endiselt comp-lzo vanast näidiskonfiguratsioonist, koos kliendiga, kellel pole tihendusrida, tekitab täpselt selle vea: server ootab päist, mida klient kunagi ei kirjutanud. comp-lzo segamine compress lz4-v2-ga ebaõnnestub samamoodi, kuna algoritmid erinevad, kuigi mõlemat nimetatakse tihenduseks. Valik on raamistuskokkulepe, mitte ribalaiuse funktsioon kaasaegsetel linkidel.

Versioonikäitumine lisab lõksu. Seeria 2.5 hakkas tihendusvalikute kohta aegumishoiatusi väljastama ja 2.6 tõmbab piiri tihendatud pakettidest keeldumise ning andmete lihtsalt tihendamata jätmise vahele. Seega võib ruuteri püsivara uuendus muuta kehtivat kokkulepet, ilma et keegi tunnelit muudaks.

Joondage mõlemad otsad või eemaldage see mõlemast

Loetlege iga tihenduskäsk: serverifail, kõik edastatud valikud, kliendipõhised failid ja kliendiprofiil. comp-lzo serveris nõuab klientis sama sõna, ja adaptive on pärandvaikeväärtus, mida paljas valik vanemates buildides tavaliselt tähendab. Ruuteri GUI-lüliti, millel on silt LZO või tihendus, kirjutab sama valiku, seega seadke see sobivaks, mitte ärge segage algoritme. Ärge eeldage, et sarnase nimega on ühilduv.

Kui tihendust ei soovita, eemaldage see teadlikult mõlemast otsast. allow-compression no serveris keeldub tihendatud pakettidest, kuid alles pärast seda, kui kliendid on lakanud neid pakkumast; selle rakendamine ajal, mil klient veel tihendust saadab, loob erinevuse vastassuunas uuesti.

Kontrollige edastust ja seadme tüüpi

Server võib tihenduskäsu edastada oma põhifailist või kliendipõhisest failist, ja klient saab edastatud valikud pull-filter abil ära jätta. Ühendage üks klient detailsusel 4, lugege, mida server teatas, selle vastu, mida klient vastu võttis, seejärel kinnitage, et ükski filter seda ei eemaldanud. Kui mõlemad pooled nüüd nõustuvad ja viga püsib, vaadake seadme tüüpi: dev tap ühes otsas ja dev tun teises ei saa kaadreid vahetada ning kernel lükkab kirjutamise samamoodi tagasi.

Sillaga TAP-paigaldus vajab serveris tegelikku silda, mitte ainult teistsugust seadme nime. Liidese ümbernimetamine tap0-ks ilma selle sillale lisamiseta loob seadme, mis võtab kirjutamise vastu ja ei lähe kuhugi.

Seejärel kontrollige ühe kliendi ja ühe sihtkohaga: pingige serveri tunneli aadressi, seejärel hosti selle LAN-is. Esimene tõestab andmekanali ja teine edastamise.