TUN/TAP nevažeći argument: neusklađenost okvira OpenVPN

Klijent se autentificira, dnevnik kaže povezano, i nijedan paket ne prelazi tunel. Server završava pokušaj s write to TUN/TAP: Invalid argument (code=22), što izgleda kao kvar upravljačkog programa i obično nije. Na ruterima i malim Linux serverima taj red najčešće znači da se dvije strane ne slažu oko toga kako se uokviruju podatkovni paketi, pa kernel odbija dešifrirani međuspremnik koji mu je predan. Rutiranje u tom trenutku još nije testirano.

Ispravna tablica rutiranja i pokvaren sporazum o uokvirenju izgledaju isto s klijentove strane: povezano, i ništa ne radi.

Tunel se podiže i ništa ga ne prelazi

Greške pisanja na uređaju tunela nastaju nakon dešifriranja i prije rutiranja. Demon dešifrira paket, predaje ga sučelju, a sučelje ga odbija jer međuspremnik ne odgovara onome što taj uređaj očekuje. Kod 22 je opći odgovor za nevažeći argument, pa je korisna informacija sloj: ovo je podatkovna putanja, a ne rukovanje. Ako je promet išao juče i stao danas bez promjene konfiguracije, sumnjajte na ažuriranje paketa ili firmvera koje je pomjerilo zadanu vrijednost prije nego što posumnjate u mrežu.

Čitajte dnevnik oko postavljanja podatkovnog kanala, a ne prvu grešku. Pregovoreni način kompresije, tip dev i gurnute opcije svi se pojavljuju pri većoj opširnosti i govore vam koje od tri neusklađenosti imate.

Kompresija je uokvirenje, ne propusni opseg

Kad je kompresija omogućena, svaki podatkovni paket nosi zaglavlje koje opisuje kako je kodiran, i oba kraja moraju se složiti o tom zaglavlju. Server koji još nosi comp-lzo iz starog primjera konfiguracije, uparen s klijentom bez retka za kompresiju, proizvodi upravo ovu grešku: server očekuje zaglavlje koje klijent nikada nije napisao. Miješanje comp-lzo s compress lz4-v2 ne uspijeva na isti način, jer se algoritmi razlikuju iako se oba zovu kompresija. Opcija je ugovor o uokvirenju, a ne značajka propusnog opsega na modernim vezama.

Ponašanje verzija dodaje zamku. Serija 2.5 počela je izdavati upozorenja o zastarjelosti za opcije kompresije, a 2.6 povlači crtu između odbijanja komprimiranih paketa i pukog ostavljanja podataka nekomprimiranim. Ažuriranje firmvera rutera stoga može promijeniti stvarni sporazum bez ikakvog uređivanja tunela.

Uskladite oba kraja ili to uklonite s oba

Nabrojite svaku direktivu kompresije: serversku datoteku, sve gurnute opcije, datoteke specifične za klijenta i profil klijenta. comp-lzo na serveru traži istu riječ na klijentu, a adaptive je naslijeđena zadana vrijednost koju gola opcija obično znači na starijim gradnjama. GUI prekidač rutera označen LZO ili kompresija piše tu istu opciju, pa ga postavite da se podudara umjesto da miješate algoritme. Ne pretpostavljajte da je slično ime kompatibilno.

Ako kompresija nije željena, uklonite je namjerno s oba kraja. allow-compression no na serveru odbija komprimirane pakete, ali tek nakon što klijenti prestanu da ih nude; primjena dok klijent još gura kompresiju ponovno stvara neusklađenost u drugom smjeru.

Provjerite guranje i tip uređaja

Server može gurnuti direktivu kompresije iz svoje glavne datoteke ili iz datoteke specifične za klijenta, a klijent može odbaciti gurnute opcije pomoću pull-filter. Povežite jedan klijent pri opširnosti 4, pročitajte šta je server najavio prema onome što je klijent prihvatio, zatim potvrdite da nijedan filter nije to uklonio. Ako se obje strane sada slažu, a greška ostaje, pogledajte tip uređaja: dev tap na jednom kraju i dev tun na drugom ne mogu razmjenjivati okvire, i kernel odbija pisanje na isti način.

Raspoređivanje TAP-a s mostom zahtijeva stvarni most na serveru, a ne samo drugačije ime uređaja. Preimenovanje sučelja u tap0 bez dodavanja u most stvara uređaj koji prihvata pisanje i ne ide nikamo.

Zatim provjerite s jednim klijentom i jednim odredištem: pingajte adresu tunela servera, pa host na njegovom LAN-u. Prvo dokazuje podatkovni kanal, a drugo prosljeđivanje.