VPN w Windows a Cisco Secure Client: który jest właściwy?

Dla tej samej bramy przychodzą dwie instrukcje: połącz się przez VPN w Windows lub zainstaluj klienta Cisco. Żadna nie nazywa wymiany, której oczekuje brama, ponieważ Windows udostępnia kilka natywnych typów połączeń, a klient dostawcy niesie profile dla więcej niż jednego trybu. Obie etykiety opisują oprogramowanie, podczas gdy brama negocjuje protokół, uwierzytelnianie i politykę. Odpowiedź jest w profilu i można ją odczytać bez łączenia.

Etykieta nazywa oprogramowanie, nie wymianę

Marka i system operacyjny to dwa różne fakty i żaden z nich nie wybiera formatu na przewodzie. Windows dostarcza zestaw natywnych typów, a klient Cisco dostarcza silnik profili, który potrafi prowadzić SSL lub IPsec/IKEv2. Mylenie obu daje tabele, które porównują firmy zamiast wymian.

Poniższa tabela zastępuje pytanie o produkt trzema miejscami odczytu i polem, które każde z nich przechowuje. Zapisz te pola, a niejednoznaczność zniknie:

Dokumentacja Microsoftu dotycząca typów VPN w Windows wymienia IKEv2 i SSTP wśród typów natywnych, co obala wyobrażenie, że natywny profil oznacza PPTP. Dokumentacja profili Cisco opisuje zarówno tryb SSL, jak i IPsec/IKEv2 z pasującą polityką centralnego węzła. Każdy dostawca oferuje kilka opcji, więc żadna nazwa nie wskazuje jednego protokołu.

Co natywne typy kładą na przewodzie

IKEv2 negocjuje asocjacje bezpieczeństwa przez UDP i przenosi ruch wewnątrz IPsec, co czyni go równym innym implementacjom IKEv2, a nie projektem typowym dla Microsoftu. SSTP opakowuje PPP w sesję HTTPS, więc przechodzi przez serwery pośredniczące, których IKEv2 nie pokona, i na przewodzie wygląda jak TLS, nie będąc protokołem TLS VPN. Te dwa fakty wyjaśniają większość zgłoszenia, które mówi, że tunel działa w jednej sieci, a w innej zawodzi.

L2TP z IPsec i starsza pozycja PPTP stoją w tej samej liście rozwijanej, a ich obecność tam nic nie mówi o obsłudze po stronie serwera. Lista rozwijana to menu tego, czego system może spróbować, a nie deklaracja możliwości bramy. Czytanie jej jako listy obsługi to sposób, w jaki zaczyna się dwugodzinne polowanie na dane logowania.

Pola, które mają znaczenie w natywnym profilu, to typ połączenia, metoda uwierzytelniania i tożsamość serwera. Zły typ zawodzi na innym etapie niż złe hasło, i właśnie ta różnica jest wskazówką wartą śledzenia.

Co dodaje klient dostawcy: profile, nie protokół

Klient Cisco jest pojemnikiem na profile. Tryb SSL i tryb IPsec/IKEv2 różnią się wymianą, oczekiwaniami co do portu i tekstem błędu, a importowany profil wybiera między nimi. Instalacja klienta nie dowodzi więc niczego o osiągalności.

Wersje są parowane nie bez powodu. Funkcje, przepływy uwierzytelniania i kontrole postury są negocjowane między klientem a centralnym węzłem, więc stary klient wobec nowego węzła może zawieść w sposób czytany jak awaria sieci. To parowanie należy do definicji połączenia, a nie do notatki o aktualizacji.

Profil wyeksportowany z innej organizacji rzadko pasuje do lokalnego centralnego węzła, a jego import może zostawić klienta oferującego tryb, którego brama nie obsługuje. Najpierw odczytaj tryb z profilu, potem porównaj go ze skonfigurowanym protokołem i polityką uwierzytelniania bramy. Dopiero gdy się zgadzają, sieć staje się podejrzana. Ta kolejność oszczędza przechwycenie pakietów, które pokazałoby zdrową sesję TLS skierowaną do niewłaściwej usługi.

Przeczytaj lokalny profil, zanim cokolwiek zmienisz

W Windows natywną konfigurację można odczytać bez wybierania, a wynik wprost nazywa typ i metodę uwierzytelniania. Porównaj te wartości z tym, co właściciel bramy mówi, że węzeł akceptuje. Jeśli typ nie zgadza się ze zgłoszeniem, najpierw popraw zgłoszenie, bo to tańsze niż ponowna instalacja klienta, który nigdy nie był błędny.

Te cztery polecenia obejmują profil, jego trasy, próbę połączenia i osiągalność portu. Uruchom je w tej kolejności na maszynie, na której profil jest już zainstalowany:

Get-VpnConnection | Format-List Name,TunnelType,AuthenticationMethod,ServerAddress
Get-VpnConnection -Name 'Corp' | Select-Object -ExpandProperty Routes
rasdial
Test-NetConnection -ComputerName vpn.example.com -Port 443

Test portu to ten, który bywa nadinterpretowany. Nasłuch TCP 443 serwujący stronę logowania i ten, który kończy IKEv2, wyglądają z zewnątrz identycznie, bo port jest miejscem, a nie protokołem.

Zapisz wynik jako trzy pola, klient, tryb i brama, i trzymaj je obok zgłoszenia. Wszystko krótsze zostawia następnej osobie ponowne odkrycie tej samej niejednoznaczności.