TUN/TAP: nevalida argumento — malkongruo de OpenVPN-kadrigo

La kliento aŭtentikas, la protokolo diras konektita, kaj neniu paketo transiras la tunelon. La servilo finas la provon per write to TUN/TAP: Invalid argument (code=22), kio aspektas kiel pelila misfunkcio kaj kutime ne estas. Sur enkursigiloj kaj malgrandaj Linux-serviloj tiu linio plej ofte signifas, ke la du flankoj malkonsentas pri tio, kiel datpaketoj estas kadrigataj, do la kerno rifuzas la malĉifritan bufron, kiun ĝi ricevis. La enkursigado ankoraŭ ne estis testita je tiu punkto.

Ĝusta enkursiga tabelo kaj rompita kadriga interkonsento aspektas same de la kliento: konektita, kaj nenio funkcias.

La tunelo leviĝas kaj nenio transiras ĝin

Skriberaroj sur la tunela aparato okazas post malĉifrado kaj antaŭ enkursigado. La demono malĉifras paketon, transdonas ĝin al la interfaco, kaj la interfaco rifuzas ĝin ĉar la bufro ne kongruas kun tio, kion tiu aparato atendas. Kodo 22 estas la ĝenerala respondo pri nevalida argumento, do la utila informo estas la tavolo: ĉi tio estas la datvojo kaj ne la manpremo. Se trafiko funkciis hieraŭ kaj haltis hodiaŭ sen ŝanĝo de agordo, suspektu pakaĵon aŭ firmvaran ĝisdatigon, kiu movis defaŭlton, antaŭ ol suspekti la reton.

Legu la protokolon ĉirkaŭ la agordo de la datkanalo anstataŭ la unuan eraron. La intertraktita kunprema reĝimo, la speco dev kaj la puŝitaj opcioj ĉiuj aperas ĉe pli alta detalo, kaj ili diras al vi, kiun el la tri malkongruoj vi havas.

Kunpremado estas kadrigo, ne bendlarĝo

Kiam kunpremado estas ŝaltita, ĉiu datpaketo portas kaplinion priskribantan, kiel ĝi estis kodita, kaj ambaŭ finoj devas konsenti pri tiu kaplinio. Servilo ankoraŭ portanta comp-lzo el malnova ekzempla agordo, kune kun kliento sen kunprema linio, produktas ĝuste ĉi tiun eraron: la servilo atendas kaplinion, kiun la kliento neniam skribis. Miksi comp-lzo kun compress lz4-v2 malsukcesas same, ĉar la algoritmoj diferencas eĉ se ambaŭ nomiĝas kunpremado. La opcio estas kadriga kontrakto kaj ne bendlarĝa trajto sur modernaj ligoj.

La konduto de versioj aldonas kaptilon. La serio 2.5 komencis eldoni avertojn pri malnoveco por kunpremaj opcioj, kaj 2.6 tiras limon inter rifuzi kunpremitajn paketojn kaj simple lasi datumojn nekunpremitaj. Firmvara ĝisdatigo de enkursigilo do povas ŝanĝi la efektivan interkonsenton sen ke iu redaktu la tunelon.

Ĝisigu ambaŭ finojn aŭ forigu ĝin de ambaŭ

Listigu ĉiun kunpreman direktivon: la servila dosiero, iuj ajn puŝitaj opcioj, klientspecifaj dosieroj kaj la klienta profilo. comp-lzo sur la servilo bezonas la saman vorton sur la kliento, kaj adaptive estas la hereda defaŭlto, kiun la nuda opcio kutime signifas en pli malnovaj versioj. La GUI-ŝaltilo de enkursigilo etikedita LZO aŭ kunpremado skribas tiun saman opcion, do agordu ĝin por kongrui anstataŭ miksi algoritmojn. Ne supozu, ke simile aspekta nomo estas kongrua.

Se kunpremado ne estas dezirata, forigu ĝin intence de ambaŭ finoj. allow-compression no sur la servilo rifuzas kunpremitajn paketojn, sed nur post kiam klientoj ĉesis proponi ilin; apliki ĝin dum kliento ankoraŭ puŝas kunpremadon rekreas la malkongruon en la alia direkto.

Kontrolu la puŝon kaj la specon de aparato

Servilo povas puŝi kunpreman direktivon el sia ĉefa dosiero aŭ el klientspecifa dosiero, kaj kliento povas forĵeti puŝitajn opciojn per pull-filter. Konektu unu klienton ĉe detalo 4, legu, kion la servilo anoncis kontraŭ tio, kion la kliento akceptis, poste konfirmu, ke neniu filtrilo forigis ĝin. Se ambaŭ flankoj nun konsentas kaj la eraro restas, rigardu la specon de aparato: dev tap ĉe unu fino kaj dev tun ĉe la alia ne povas interŝanĝi kadrojn, kaj la kerno rifuzas la skribon same.

Ponta TAP-ekspedo bezonas realan ponton sur la servilo, ne nur alian aparatan nomon. Renomigi interfacon al tap0 sen aldoni ĝin al ponto produktas aparaton, kiu akceptas la skribon kaj iras nenie.

Poste kontrolu per unu kliento kaj unu celo: ping la tunelan adreson de la servilo, poste gastiganton en ĝia LAN. La unua pruvas la datkanalon kaj la dua la plusendadon.