vpncli -s a GUI: logowanie do Cisco Secure Client
vpncli -s czyta przygotowany plik odpowiedzi, a GUI czyta człowieka. Porównaj, kiedy skrypt się opłaca, czego potrzebuje plik i jak to udowodnić.
Cisco Secure Client daje dwa sposoby odpowiedzi na te same monity logowania: osoba wpisująca dane w vpnui.exe albo skrypt podający odpowiedzi do vpncli.exe przez standardowe wejście z -s. Drugi umożliwia połączenia zaplanowane bez odczytywania ekranu GUI, a także zamienia logowanie w plik, który trzeba chronić jak dane uwierzytelniające. To, który wybrać, zależy od tego, czy przy maszynie siedzi człowiek i jak często zmienia się hasło. Żadna opcja nie zmienia tego, o co pyta brama, tylko kto odpowiada.
Obie ścieżki kończą się w tym samym tunelu, więc porównanie dotyczy eksploatacji, a nie protokołu.
Dwa sposoby odpowiedzi na te same monity
Ścieżka GUI jest interaktywna z założenia: klient pyta, ktoś odpowiada, a sesja żyje, dopóki ta osoba jej nie zostawi. To właściwy wybór na laptopie, którego używa człowiek, ponieważ monity dopasowują się do metody uwierzytelniania bramy i nikt nie musi trzymać hasła jawnym tekstem na dysku.
Ścieżka skryptu pasuje do kiosku, maszyny laboratoryjnej lub zadania zaplanowanego, przy którym nie ma nikogo do wpisywania. Zamiana jest jawna: akceptujesz plik danych uwierzytelniających na dysku w zamian za połączenie bez nadzoru. Jeśli brama oferuje uwierzytelnianie certyfikatem lub SAML, ta zamiana zwykle się nie opłaca, ponieważ plik istnieje tylko po to, by odpowiadać na monity, których uniknęłaby silniejsza metoda.
Nie mieszaj obu na jednej maszynie jednocześnie. Wiersz poleceń i klient graficzny rywalizują o ten sam stan sesji, a to jest problem następnej sekcji.
Co musi zawierać plik odpowiedzi
Klient pyta po kolei — brama, czasem wybór grupy, nazwa użytkownika, hasło i każde potwierdzenie banera. Plik, który odpowiada na to wszystko, wygląda tak, z podstawionymi rzeczywistymi wartościami:
connect vpn.example.com
MyGroup
alice
correct-horse-battery
yNiezawodny sposób zbudowania tego pliku to jedno ręczne połączenie, zapisanie każdej wpisywanej linii i każdego naciśnięcia Enter, a następnie dokładne odtworzenie tej sekwencji. Wdrożenia, które przechowują grupę i nazwę użytkownika w profilu, mogą potrzebować pustych linii tam, gdzie te monity już się nie pojawiają, a ostatnia linia nadal potrzebuje własnego przejścia do nowej linii. Plikowi, któremu brakuje jednej linii, zwykle zawiesza się na ostatnim monicie zamiast zakończyć się jasnym błędem, i dlatego obwinia się sieć. Porównaj plik ze swoim zapisem dwa razy: raz pod kątem kolejności, a raz pod kątem pustych linii.
Trzymaj plik poza każdym synchronizowanym folderem i czytelny tylko dla konta, które uruchamia zadanie. To hasło jest jawnym tekstem, więc plik jest danymi uwierzytelniającymi: żadnego repozytorium, żadnego dysku współdzielonego, żadnego załącznika w zgłoszeniu. Klient nie ostrzeże cię o niczym z tego.
Dlaczego GUI musi zniknąć pierwsze
Zacznij skrypt od zakończenia procesu GUI, a potem uruchom CLI z jego własnego katalogu instalacyjnego, ponieważ znaczenie ma zarówno katalog roboczy, jak i wersja klienta. Ilustracyjna otoczka:
@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txtKody wyjścia nie są tu wiarygodnym sygnałem sukcesu. Klient wypisuje postęp i trzyma tunel w osobnym procesie, więc odczytaj z wyjścia wiersz stanu połączenia i dopiero potem rozpocznij pracę zależną od VPN.
Jeśli pominiesz uśmiercenie GUI, skrypt może wyglądać na działający, podczas gdy istniejąca sesja pozostaje w stanie, w jakim zostawił ją użytkownik. Ta awaria wygląda na przerywaną i właśnie taki błąd przeżywa tydzień domysłów.
Potwierdź sesję, nie zakładaj jej
Po powrocie skryptu sprawdź coś, co istnieje tylko wewnątrz tunelu — host wewnętrzny albo sufiks DNS, na który odpowiada wyłącznie firmowy resolver. Odczytaj też wiersz stanu połączenia z wyjścia klienta i wszystko inne traktuj jako porażkę, a nie wolny sukces. Ponowne uruchomienie pliku przy już aktywnej sesji może zostawić klienta w połowie skonfigurowanego, więc albo najpierw się rozłącz, albo pomiń logowanie, gdy sesja jest obecna.
Potem zdecyduj, kto odpowiada za ponowne połączenie. Pętla, która pinguje adres wewnętrzny i ponownie uruchamia logowanie, może utrzymać kiosk online miesiącami, a może też zablokować konto przy pierwszej zmianie hasła. Ogranicz liczbę prób, alarmuj po przekroczeniu i pozwól zespołowi tożsamości zmienić plik, zamiast zostawiać nieaktualne hasło ponawiające próby aż do blokady.
Starszy vpnclient.exe to nie to samo narzędzie
Ta sama automatyzacja występuje pod starszą nazwą i oba nie są wymienne. Wycofany klient Cisco IPsec używał vpnclient.exe z argumentami w wierszu, takimi jak czasownik connect, nazwa profilu, użytkownik i hasło w jednym wierszu poleceń; natomiast vpncli.exe oczekuje sekwencji monitów na standardowym wejściu z -s. Dlatego skopiowanie starego skryptu z forum na dzisiejszą maszynę daje polecenie, które się uruchamia, niczego nie pokazuje i za które obwinia się bramę.
Zanim edytujesz jakikolwiek argument, sprawdź, który klient jest zainstalowany i którego skrypt faktycznie wywołuje. Różnica w nazwie jest dość mała, by ją przeoczyć w zadaniu zaplanowanym, i to pierwsza rzecz do weryfikacji, gdy odziedziczony skrypt przestał działać po aktualizacji.