vpnc wobec Check Point lub Nortela: dlaczego się zawiesza

Objaw łatwo odczytać błędnie: vpnc startuje, pyta o hasło grupy, a potem zatrzymuje się na kroku negocjacji, aż zgłosi, że nie ma odpowiedzi od celu. W danych wyjściowych nigdzie nie ma informacji o produkcie bramki, a konto działa z przeglądarki, więc oczywisty wniosek to błędne hasło albo zablokowany port. W większości takich przypadków bramka wcale nie jest partnerem IPsec, więc wymiana nigdy nie dociera do sprawdzenia danych logowania. Ten wzorzec warto sprawdzić, zanim zmieni się cokolwiek innego w profilu.

Zidentyfikuj produkt, zanim edytujesz kolejne pole profilu.

Awaria wygląda jak błędne dane logowania

vpnc zaczyna od wysłania IKE na UDP 500 i, jeśli zaproponowano przechodzenie przez NAT, na UDP 4500. Bramka, która kończy SSL zamiast IPsec, nie odpowiada na żadne z nich, więc klient ponawia próbę i w końcu poddaje się z ogólnym błędem. Jeśli to samo konto działa przez portal przeglądarki, który ładuje niewielką aplikację pomocniczą, to silna wskazówka, że tunel opiera się na SSL i klient zadaje niewłaściwe pytanie.

Nieudana próba nic tu nie mówi o koncie użytkownika, ponieważ bramce nigdy nie przedstawiono danych logowania.

Sprawdź, jaki protokół oferuje bramka

Dwie minuty sondowania oddzielają partnera IPsec od portalu SSL. Uruchom je z tej samej sieci, której będzie używać klient, i czytaj, które porty odpowiadają, a nie które są w dokumencie. Zachowaj wynik, bo te same porty decydują, którego klienta powinien wspierać właściciel bramki. Sondowanie prowadź z sieci klienta, a nie z hosta obok bramki.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Otwarty 443 z przekierowaniem na stronę logowania i cisza na 500 i 4500 wskazują na SSL VPN. Otwarte 500 i 4500 z certyfikatem serwowanym na 443 sugerują bramkę IPsec, która uruchamia też interfejs webowy, a właśnie dla tego przypadku zbudowano vpnc.

SSL Network Extender firmy Check Point i klient Aventail firmy Nortel należą oba do drugiej kategorii i żaden nie przyjmuje grupowego sekretu IKEv1.

Co profil vpnc może, a czego nie może wyrazić

Pod maską vpnc prowadzi IKEv1 wobec wstępnie współdzielonego klucza grupowego, a następnie wysyła dane logowania pojedynczego użytkownika przez XAuth. Wszystko w jego pliku konfiguracji należy do tej wymiany: bramka, nazwa grupy, sekret grupy, nazwa użytkownika i hasło użytkownika. Te pola opisują jeden protokół i żadna ich kombinacja nie może kazać klientowi mówić innym.

Dlatego rozszerzanie listy szyfrów ani wyłączanie sprawdzania certyfikatów nigdy nie naprawia tej klasy awarii. Te zmiany osłabiają negocjację, której bramka nie nasłuchuje.

Wybór klienta pasującego do bramki

Dla bramki Check Point użyj pakietu SNX zbudowanego dla tej wersji bramki, który dostawca publikuje wraz z dokumentacją dostępu zdalnego. Starsze kompilacje SNX często zawodzą na obecnych dystrybucjach, bo oczekują bibliotek 32-bit, których już nie ma, a łatanie porzuconego pakietu jest zwykle gorsze niż uruchamianie wspieranego klienta na wspieranej platformie.

Klienci Aventail dawno utracili wsparcie. Tam, gdzie taka bramka nadal działa, realne wybory to portal przeglądarki, jeśli organizacja go włączy, albo wspierany klient dostawcy na wspieranym systemie operacyjnym.

Zapytaj właściciela bramki o produkt i wersję, o klienta wspieranego na Linuksie oraz o to, czy w ogóle istnieje profil IPsec. Jeśli istnieje, poproś o identyfikator grupy i sekret grupy jako osobne pozycje, bo to nie jest hasło użytkownika, a zamieniona para to inna częsta przyczyna nieudanego tunelu. Gdy połączenie w końcu się powiedzie, zanotuj, który protokół wynegocjowano, aby następna osoba zaczynała od faktu, a nie powtarzała tego samego domysłu.