OpenConnect vpnc-script: który plik jest uruchamiany?

OpenConnect może zakończyć uzgadnianie tunelu i mimo to zostawić cię bez trasy do prywatnej podsieci, ponieważ klient i skrypt pomocniczy zmieniający stan sieci lokalnej to dwa różne programy. Uwierzytelnianie dowodzi, że brama zaakceptowała sesję; nie dowodzi niczego o tym, który interfejs, jakie trasy lub jakie ustawienia resolvera zainstalowano później. Większość mylących zgłoszeń bierze się z zastąpienia skryptu kopią ze starej odpowiedzi, co zmienia zachowanie każdego połączenia na maszynie. Zanim cokolwiek w nim zmienisz, znajdź skrypt, który działający klient naprawdę wywołuje.

Dwa programy, dwie odpowiedzialności

Klient odpowiada za transport, uwierzytelnianie i urządzenie tunelu. Osobny skrypt pomocniczy odpowiada za to, co dzieje się w systemie lokalnym, gdy tunel już istnieje: adresację interfejsu, trasy do podsieci ogłoszonych przez bramę i konfigurację resolvera. dokumentacja skryptu pomocniczego OpenConnect opisuje ten podział i środowisko, które otrzymuje skrypt. Rozróżnienie ma znaczenie podczas awarii, ponieważ odrzucone hasło i brakująca trasa to nie to samo zdarzenie, nawet gdy pulpit pokazuje jedno okno dla obu.

Pamiętanie o tym podziale wyjaśnia też, dlaczego połączenie może zgłaszać sukces, a nazwy prywatne nadal się nie rozwiązują. Tunel jest w obu przypadkach podniesiony i różni się tylko etap integracji lokalnej.

Znajdź skrypt, którego używa działający klient

Ścieżka jest ustalana podczas budowania pakietu i można ją nadpisać przy każdym wywołaniu, więc plik, który pamiętasz z innej dystrybucji, może nie mieć nic wspólnego z tym połączeniem. Pytaj działający proces, a nie dokumentację, którą przypadkiem masz otwartą.

openconnect --version
ps -o args= -C openconnect
dpkg -L openconnect | grep -i script
ls -l /etc/vpnc/ 2>/dev/null

Jeśli wiersz procesu zawiera argument --script , ten plik wygrywa ze skompilowaną wartością domyślną. Starsze ścieżki, takie jak /etc/vpnc/vpnc-script , mogą istnieć i pozostać nieużywane, dlatego ich usunięcie lub edycja niczego nie zmienia w nowym buildzie. Sprawdź też datę modyfikacji, ponieważ skrypt, którego nikt nie dotykał od lat, jest mocnym sygnałem, że pracę wykonuje wartość domyślna z pakietu.

Integracja z NetworkManagerem to trzeci właściciel, z własnym skryptem i własnymi ustawieniami profilu. Dołożenie drugiego skryptu tras lub resolvera na tę integrację dubluje trasy i zostawia resolver, o którym dwa programy twierdzą, że nim zarządzają. Wybierz jednego właściciela na połączenie i wyłącz drugiego przed testem.

Czytaj pierwszą nieudaną operację, a nie ostatnie ostrzeżenie

Konfiguracja interfejsu, instalacja tras, wybór resolvera i sprzątanie nieaktualnego stanu to osobne kroki, a ostrzeżenie drukowane jako ostatnie jest często skargą na sprzątanie, a nie awarią, która zerwała połączenie. Czytaj w górę do pierwszej konkretnej nieudanej operacji. Błąd skryptu, który nazywa plik lub adres, jest wart więcej niż dziesięć linii szumu demontażu.

Porównaj zamierzony wynik lokalny z zaobserwowanym: urządzenie tunelu istnieje, trasa do znanego adresu prywatnego przechodzi przez nie, a resolver odpowiada dla nazwy prywatnej. Skrypt, który udaje się w dwóch pierwszych i zawodzi w trzecim, wskazuje na politykę resolvera, a nie na routing. Skrypt, który w ogóle nie konfiguruje urządzenia, prawdopodobnie nigdy nie został uruchomiony, a to kwestia uprawnień, nie sieci. Potwierdź bit wykonywalny i konto usługi, zanim przepiszesz jakąkolwiek logikę.

Sprawdź połączenie, ponowne połączenie i rozłączenie

Konfiguracja to tylko połowa umowy, ponieważ ten sam skrypt musi przywrócić lub usunąć stan, który posiada, gdy tunel się zamyka. Skrypt, który dodaje trasy i nigdy ich nie usuwa, zostawia maszynę z nieaktualną ścieżką, która przeżywa sesję.

ip -brief address show tun0
ip route get 10.24.8.15
resolvectl status tun0
journalctl -u NetworkManager -b --no-pager | grep -i -E 'vpnc|script'

Uruchom pierwsze trzy, będąc połączonym, rozłącz się, a potem uruchom je ponownie i potwierdź, że trasa i wpis resolvera zniknęły. Czwarta linia pokazuje, czy skrypt w ogóle został wywołany i której wykonywalnej ścieżki użyła usługa. Zachowaj tę parę wyników w zgłoszeniu, ponieważ to porównanie przed i po czyni błąd sprzątania oczywistym.

Trzymaj skrypt spakowany i wykonywalny dla konta usługi, ponieważ skrypt działający w twojej powłoce nadal może zostać odrzucony w ramach ograniczonej polityki usługi. Gdy dostosowanie jest naprawdę konieczne, udokumentuj jego cel i właściciela i porównuj je ze spakowaną wersją przy każdej aktualizacji. Niewyjaśniony fork skryptu to jedna z niewielu rzeczy, które mogą sprawić, że działające połączenie zawiedzie rok później.