SNX w Linuksie: biblioteki 32-bitowe i resolver, który się resetuje

SNX w Linuksie zawodzi w loaderze, tabeli routingu lub resolverze, a każdy z tych błędów wygląda jak problem z logowaniem. Przejdź przez cztery objawy po kolei.

SSL Network Extender firmy Check Point zawodzi w Linuksie na cztery rozpoznawalne sposoby, a trzy z nich są błędnie czytane jako problem z logowaniem. Albo plik binarny nie startuje, albo startuje i nie zostawia żadnej trasy, albo łączy się i rozwiązywanie nazw umiera, albo portal w przeglądarce działa, a wiersz poleceń nie. Przejdź przez nie w tej kolejności, bo każdy jest warunkiem wejścia dla następnego.

Objaw pierwszy: loader odmawia przed logowaniem

Instalator pobrany z zapory ogniowej umieszcza 32-bitowy plik binarny z setuid-root w /usr/bin/snx. W dystrybucji 64-bitowej nie działa, dopóki architektura i386 nie jest włączona i dopóki nie istnieją biblioteki, z którymi się linkuje.

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libstdc++5:i386 libstdc++6:i386 libx11-6:i386 libpam0g:i386
ldd /usr/bin/snx | grep "not found"

Pusta lista not found jest bramą dla wszystkiego, co następuje. Dokładny zestaw pakietów zmienia się między wydaniami: jeden działający raport wymagał libstdc++5:i386, libx11-6:i386 i libpam0g:i386, inny wymagał też libstdc++6:i386. Czytaj ldd zamiast kopiować listę pakietów z poradnika napisanego dla innej dystrybucji.

Jeśli snx w ogóle nie zostanie znaleziony, instalator nigdy się nie zakończył albo zainstalował się gdzieś poza twoim PATH. To inny błąd i warto go potwierdzić, zanim dodasz architektury do systemu. Sprawdź za pomocą command -v snx i zajrzyj do katalogu, który zgłosił instalator. Dodawanie pakietów i386 do maszyny, na której pliku binarnego po prostu nie ma, niczego nie naprawia.

Objaw drugi: logowanie się udaje i nic nie jest routowane

Udane logowanie tworzy tunsnx i samo edytuje tabelę routingu, więc sprawdź, co naprawdę istnieje, zanim zmienisz cokolwiek innego.

ip -br addr show tunsnx
ip route | grep tunsnx
snx -d

Użyj snx -d do demontażu. Zabicie procesu pozostawia interfejs i jego trasy, a następna próba zawodzi wtedy z powodu, który nie ma nic wspólnego z poświadczeniami. Pierwsze logowanie zapisuje też podpis serwera pod /etc/snx/, dlatego skrypt bez nadzoru może potrzebować jednego przebiegu interaktywnego, zanim w ogóle zacznie działać. Usuwaj ten stan tylko wtedy, gdy zamierzasz ponownie zatwierdzić serwer.

Objaw trzeci: nazwy są rozwiązywane, dopóki tunel się nie podniesie

To ten, który psuje się po cichu. snx zapisuje wypchnięte serwery DNS prosto do /etc/resolv.conf. Tam, gdzie ta ścieżka jest dowiązaniem symbolicznym do /run/systemd/resolve/, zmiana może zginąć przy następnym zdarzeniu resolvera, a po rozłączeniu wypchnięte wpisy równie dobrze mogą zostać.

Działają dwa układy, a wybór powinien być świadomy, a nie taki, jaki zasugerował pierwszy wynik wyszukiwania:

  • Przejmij plik: zastąp dowiązanie symboliczne plikiem statycznym i zainstaluj libnss-resolve wraz z jego wariantem dla i386, aby usługa nazw nadal miała odwrót, gdy plik zostanie pod nim przepisany.
  • Pozostaw systemd-resolved jako właściciela i zarejestruj połączenie tunelu: resolvectl dns tunsnx 10.0.0.10, następnie resolvectl domain tunsnx corp.example, i potwierdź za pomocą resolvectl status.

Zapisz serwery nazw sprzed VPN przed połączeniem. Jeśli edytujesz plik ręcznie, usunięcie wypchniętych wpisów później jest częścią procedury, a nie opcjonalnym sprzątaniem, ponieważ laptop, który po rozłączeniu zachowuje firmowy DNS, nie będzie mógł rozwiązać niczego innego.

Objaw czwarty: portal działa, a CLI nie

Ostatnie wydania zapory ogniowej przeniosły oprogramowanie pośredniczące z przeglądarki do lokalnego demona Java, więc portal rozmawia z lokalnym agentem na porcie 14186. Ten adres wymaga wyjątku certyfikatu w przeglądarce i działającego procesu.

ps ax | grep cshell
/usr/bin/cshell/launcher

Wiersz poleceń to osobna ścieżka: snx -s vpn.example.com -u user, a ~/.snxrc przechowuje serwer, nazwę użytkownika i preferencję ponownego uwierzytelniania. Działająca sesja portalu nic nie mówi o tym, czy CLI jest poprawnie zainstalowane, a sam klient nie obsługuje kodów jednorazowych.

Skrót z kontenerem, który kosztuje więcej, niż oszczędza

snx sprawdza moduł tun, ładuje go, gdy go nie ma, tworzy interfejs tunelu, przepisuje trasy i przepuszcza przez niego ruch. Odtworzenie tego w kontenerze oznacza zamontowanie /dev i /lib/modules oraz przyznanie szerokich uprawnień, co oddaje kontenerowi większość administracji siecią hosta.

Gdy piaskownica jest naprawdę potrzebna, maszyna wirtualna jest czystszą granicą: klient dostaje jądro, które może zmieniać, a host zachowuje swoją tabelę routingu. Wybierz to, zanim spędzisz popołudnie na uprawnieniach, których przyznania pożałujesz.

Powiązane artykuły