TUN/TAP: nieprawidłowy argument — niezgodność ramkowania OpenVPN
Błędy zapisu z kodem 22 zwykle oznaczają, że strony nie zgadzają się co do ramkowania pakietów danych, a nie usterkę sterownika. Porównaj kompresję po obu stronach, potem typ urządzenia.
Klient uwierzytelnia się, log mówi połączono, a żaden pakiet nie przekracza tunelu. Serwer kończy próbę komunikatem write to TUN/TAP: Invalid argument (code=22), który wygląda jak usterka sterownika i zwykle nią nie jest. Na routerach i małych serwerach Linux ta linia najczęściej oznacza, że dwie strony nie zgadzają się co do sposobu ramkowania pakietów danych, więc jądro odrzuca otrzymany odszyfrowany bufor. Routing nie został jeszcze w tym momencie sprawdzony.
Poprawna tabela routingu i zepsuta umowa ramkowania wyglądają z punktu widzenia klienta tak samo: połączono, i nic nie działa.
Tunel wstaje i nic przez niego nie przechodzi
Błędy zapisu na urządzeniu tunelu pojawiają się po odszyfrowaniu i przed routingiem. Demon odszyfrowuje pakiet, przekazuje go interfejsowi, a interfejs go odrzuca, bo bufor nie odpowiada temu, czego oczekuje to urządzenie. Kod 22 to ogólna odpowiedź na nieprawidłowy argument, więc użyteczną informacją jest warstwa: to ścieżka danych, a nie uzgadnianie. Jeśli ruch działał wczoraj, a dziś zatrzymał się bez zmiany konfiguracji, podejrzewaj aktualizację pakietu lub firmware’u, która przesunęła wartość domyślną, zanim podejrzysz sieć.
Czytaj log wokół konfiguracji kanału danych, a nie pierwszy błąd. Wynegocjowany tryb kompresji, typ dev i wypchnięte opcje pojawiają się przy wyższej szczegółowości, i mówią ci, która z trzech niezgodności występuje.
Kompresja to ramkowanie, nie przepustowość
Przy włączonej kompresji każdy pakiet danych niesie nagłówek opisujący, jak został zakodowany, i oba końce muszą się na ten nagłówek zgodzić. Serwer, który nadal niesie comp-lzo ze starej przykładowej konfiguracji, w parze z klientem bez linii kompresji, daje dokładnie ten błąd: serwer oczekuje nagłówka, którego klient nigdy nie napisał. Mieszanie comp-lzo z compress lz4-v2 zawodzi tak samo, ponieważ algorytmy się różnią, choć oba nazywają się kompresją. Opcja jest umową ramkowania, a nie funkcją przepustowości na nowoczesnych łączach.
Zachowanie wersji dodaje pułapkę. Seria 2.5 zaczęła wydawać ostrzeżenia o przestarzałości opcji kompresji, a 2.6 rysuje granicę między odrzucaniem skompresowanych pakietów a samym pozostawianiem danych nieskompresowanymi. Aktualizacja firmware’u routera może więc zmienić obowiązującą umowę, choć nikt nie edytuje tunelu.
Wyrównaj oba końce albo usuń z obu
Wylicz każdą dyrektywę kompresji: plik serwera, wszelkie wypchnięte opcje, pliki specyficzne dla klienta i profil klienta. comp-lzo na serwerze wymaga tego samego słowa na kliencie, a adaptive to odziedziczona wartość domyślna, którą naga opcja zwykle oznacza w starszych kompilacjach. Przełącznik GUI routera oznaczony LZO lub kompresja zapisuje tę samą opcję, więc ustaw go zgodnie, zamiast mieszać algorytmy. Nie zakładaj, że podobnie wyglądająca nazwa jest zgodna.
Jeśli kompresja nie jest pożądana, usuń ją świadomie z obu końców. allow-compression no na serwerze odrzuca skompresowane pakiety, ale dopiero gdy klienci przestaną je oferować; zastosowanie go, gdy klient nadal wypycha kompresję, odtwarza niezgodność w drugą stronę.
Sprawdź wypychanie i typ urządzenia
Serwer może wypchnąć dyrektywę kompresji ze swojego pliku głównego lub z pliku specyficznego dla klienta, a klient może odrzucić wypchnięte opcje za pomocą pull-filter. Połącz jednego klienta przy szczegółowości 4, przeczytaj, co ogłosił serwer, w porównaniu z tym, co przyjął klient, a następnie potwierdź, że żaden filtr tego nie usunął. Jeśli obie strony się teraz zgadzają, a błąd pozostaje, spójrz na typ urządzenia: dev tap na jednym końcu i dev tun na drugim nie mogą wymieniać ramek, a jądro odrzuca zapis w ten sam sposób.
Wdrożenie TAP z mostem wymaga prawdziwego mostu na serwerze, nie tylko innej nazwy urządzenia. Zmiana nazwy interfejsu na tap0 bez dodania go do mostu tworzy urządzenie, które przyjmuje zapis i nigdzie nie trafia.
Następnie zweryfikuj z jednym klientem i jednym celem: pingnij adres tunelu serwera, potem hosta w jego sieci LAN. Pierwsze dowodzi kanału danych, a drugie przekazywania.