Kerio w Linuksie: dać kvnetowi MAC, którego oczekuje serwer

Trzy rzeczy muszą się zgadzać, zanim tunel Kerio poprowadzi ruch: adres na interfejsie kvnet, wartość zapisana przez klienta oraz to, czego oczekuje polityka serwera lub DHCP. Gdy się nie zgadzają, tunel nadal się uwierzytelnia i nadal wstaje, i właśnie to czyni awarię mylącą. Interfejs jest tworzony dla każdego połączenia, więc adres ustawiony ręcznie należy do tej sesji i do niczego innego. Taki jest kształt problemu, a rozwiązaniem jest hook, a nie plik konfiguracyjny. Reszta to gdzie odczytać wartość i gdzie ją zastosować.

Dlaczego adres wciąż wraca

kvnet to wirtualny adapter, który klient tworzy przy rozpoczęciu połączenia i usuwa przy jego zakończeniu. Ręczne ip link set przeżywa więc dokładnie tyle, ile trwa sesja, do której je zastosowano, a następne połączenie zaczyna się od tego, co przydzieli klient. Na maszynie, na której klient nie potrafi zastosować oczekiwanego adresu, każde ponowne połączenie wprowadza tę samą niezgodność, a reguła dzierżawy lub dostępu ponownie odrzuca urządzenie.

Ten wzorzec jest sam w sobie diagnostyczny. Tunel, który działa jedną sesję i zawodzi w następnej, nie jest problemem poświadczeń, bo poświadczenia nie zmieniają się między połączeniami.

Czytaj wartość z klienta, a nie z interfejsu

Klient Linuksa zapisuje szczegóły negocjacji do swojego dziennika debugowania, a adres, którego zamierza użyć, pojawia się tam jako ostatni token w kształcie adresu w sekwencji połączenia. Porównaj go z tym, co jądro faktycznie trzyma, a to jest o jeden readlink dalej: cat /sys/class/net/kvnet/address.

Jeśli oba się różnią, klient znał właściwą wartość i nie zdołał jej zastosować, a hook, który stosuje ją po powstaniu interfejsu, zamyka tę lukę. Jeśli dziennik w ogóle nie zawiera adresu, problem jest wcześniejszy i należy do wersji klienta lub profilu serwera, a nie do skryptu.

Zastosuj go po powstaniu interfejsu

Użytkownicy NetworkManagera mogą umieścić skrypt w jego katalogu dyspozytora i działać tylko wtedy, gdy interfejs VPN się podnosi. Klient zarządzany przez systemd wymaga więcej staranności: drop-in uruchamiany przy starcie usługi zwykle aktywuje się, zanim adapter istnieje, więc hook musi czekać na interfejs, zamiast go zakładać. Ustaw wtedy adres, a jeśli jądro odmówi, gdy łącze jest podniesione, opuść je, ustaw adres i podnieś ponownie. Odczytaj wyodrębniony token z powrotem przez wzorzec MAC, zanim przekażesz go do ip link, aby nieoczekiwana linia dziennika nie mogła stać się argumentem.

Wszystko, co działa jako root na podstawie dziennika klienta, zasługuje na wąską własność: plik należący do roota, niezapisywalny dla innych i bez interpolacji powłoki poza zweryfikowanym adresem. Trzymaj sprawdzanie wzorca wewnątrz skryptu. Nie pozwól, by zawartość dziennika decydowała, które polecenie się uruchomi.

Sprawdzaj dzierżawę, a nie łącze

ip -4 -o addr show dev kvnet powinno pokazywać adres w oczekiwanym zakresie, ip neigh show dev kvnet powinno pokazywać bramę, a jedna usługa za VPN powinna odpowiadać. Następnie rozłącz się i połącz ponownie raz; jeśli adres wróci, hook uruchamia się przy złym zdarzeniu albo wcale.

Interfejs, który pojawia się z poprawnym adresem i nigdy nie dostaje dzierżawy, wskazuje na stronę serwera. To inne sprawdzenie i zwykle inny zespół. Zanim ponownie edytujesz hook, potwierdź, że konto jest dozwolone, a pula nadal ma adres.

Po aktualizacji przejrzyj obejście

Wersja klienta, która poprawnie ustawia adres, pozostawia hook stosujący nieaktualną wartość, co jest nową usterką wprowadzoną przez poprawkę. Nigdy nie kopiuj też MAC z innej maszyny ani z postu na forum; użyj wartości, którą ten klient zapisuje dla tego konta, i zanotuj datę jej weryfikacji.

Utrzymuj skrypt na tyle krótki, by przeczytać go za jednym posiedzeniem. Obejścia parsujące dzienniki są z natury tymczasowe. Przetrwają te, które przyszły czytelnik zrozumie bez pierwotnego wątku.