vpncli nie działa w Windows? Uruchom Cisco Secure Client poprawnie

Wpisujesz vpncli w wierszu polecenia Windows i otrzymujesz błąd, że polecenie nie jest rozpoznawane, albo okno otwiera się i zatrzymuje na pytaniu, którego się nie spodziewałeś. Oba objawy zwykle pochodzą z tego samego miejsca: na komputerze zainstalowano więcej niż jedną linię klienta Cisco VPN, a wykonane polecenie należy do niewłaściwej. Rozwiązaniem jest uruchomienie pliku wykonywalnego dostarczanego z Secure Client, a następnie odpowiadanie na monity, które brama faktycznie wysyła.

Objaw wskazuje na dwóch różnych klientów

Cisco Secure Client zawiera interfejs wiersza polecenia Windows o nazwie vpncli.exe. Starszy klient Cisco IPsec VPN dostarczał inny program, vpnclient.exe, z innymi poleceniami i innymi przełącznikami hasła. Poradniki, które mieszają oba, tworzą polecenia wyglądające wiarygodnie i natychmiast zawodzące. Zainstalowany folder programu to najszybszy sposób, aby je rozróżnić.

To, że vpncli nie ma w PATH, nie jest dowodem na brak komponentu. Instalator po prostu nie dodaje folderu do PATH, więc wywołujesz plik wykonywalny pełną ścieżką.

Uruchom plik wykonywalny należący do Secure Client

W instalacji Secure Client 5.x udokumentowana lokalizacja to folder Secure Client w Program Files (x86). W PowerShellu wymagany jest operator wywołania, ponieważ ścieżka zawiera spacje: & 'C:\Program Files (x86)\Cisco\Cisco Secure Client\vpncli.exe'. Jeśli tego pliku nie ma, sprawdź zainstalowaną wersję i jej folder, zamiast pobierać starszego klienta, aby wypełnić lukę.

Z cmd.exe ta sama ścieżka działa bez operatora wywołania, ale nadal wymaga cudzysłowów. Wybierz jedną powłokę i pozostań w niej, ponieważ obie obsługują cudzysłowy inaczej, a połowa nieudanych przykładów w sieci to problem z cudzysłowami.

Połącz się i odpowiedz na to, o co pyta brama

W monicie klienta połącz się z zatwierdzoną bramą lub skonfigurowanym aliasem: connect vpn.example.com. Zastąp przykład własną nazwą hosta. Klient pyta następnie o poświadczenia wymagane przez twoje wdrożenie, które mogą obejmować wybór certyfikatu, kod tokenu lub drugi składnik. Odpowiadaj na każdy monit w kolejności, w jakiej się pojawia.

Udokumentowany przykład Cisco pokazuje też baner, który wymaga wyraźnej odpowiedzi, więc skrypt dostarczający tylko nazwę użytkownika i hasło może zatrzymać się na tym banerze. Czytaj pytanie na ekranie, zamiast zakładać, że następny monit to hasło.

Sprawdź sesję, zanim jej zaufasz

Po nawiązaniu połączenia stats wypisuje informacje o sesji: bramę, przypisany adres, protokół i czas trwania. Sprawdź także jeden zamierzony zasób wewnętrzny, ponieważ sesja istnieje, zanim udowodnisz, że jej trasy, DNS i uprawnienia aplikacji spełniają zadanie. Zapisz przypisany adres, dopóki sesja jest aktywna.

Uruchom disconnect, gdy chcesz zakończyć sesję VPN, a quit, gdy chcesz opuścić interaktywne CLI. To nie są synonimy, a zamknięcie okna nie jest udokumentowanym zamiennikiem żadnego z nich.

Automatyzacja to osobna decyzja

Działające logowanie w terminalu nie dowodzi, że zadanie zaplanowane może wykonać to samo uwierzytelnianie. Zapisz wymaganą tożsamość, konto wykonawcze, dostęp do certyfikatu i wszelką interakcję użytkownika, zanim zamienisz sesję w zadanie w tle. Jeśli wdrożenie wymaga logowania w przeglądarce lub zatwierdzenia, potwierdź obsługiwany przepływ pracy u jego operatora, zamiast traktować monit jako przeszkodę.

Nie adaptuj starych przykładów, które umieszczają hasło bezpośrednio w wierszu polecenia. Stałe wiersze wstrzykiwane do interaktywnej rozmowy psują się, gdy tylko brama zmieni pytania, a poświadczenie zapisane w skrypcie to ustalenie, które tylko czeka na opisanie. Dokumentacja Cisco CLI opisuje obsługiwane polecenia dla tego klienta.

Gdy logowanie się nie powiedzie, zachowaj wersję klienta, bramę, czas i niebędący tajemnicą tekst błędu. Te cztery fakty odróżniają niewłaściwy plik wykonywalny od odrzucenia uwierzytelniania i od połączonej sesji, która nie dociera do swojej aplikacji.