Rozwiązywanie podstawowych problemów z protokołem L2TP/IPSec w systemie Windows XP

Ten artykuł zawiera opis sposobu rozwiązywania problemów z protokołami L2TP (Layer 2 Tunneling Protocol) i IPSec (Internet Protocol Security) w systemie Windows XP.

L2TP to standard, który umożliwia przekazywanie ruchu protokołu PPP (Point to Point Protocol) między różnymi sieciami (opisano go w specyfikacji Request for Comments [RFC] #2661). Protokół L2TP jest łączony z protokołem IPSec i zapewnia tunelowanie oraz zabezpieczenia dla protokołów IP (Internet Protocol), IPX (Internetwork Packet eXchange) i innych pakietów protokołów w dowolnej sieci IP.

Hermetyzuje on oryginalne pakiety w ramce PPP (gdy jest to możliwe, wykonuje kompresowanie) oraz w pakietach typu UDP (User Datagram Protocol) przypisanych do portu 1701. Ponieważ pakiet w formacie UDP to pakiet IP, protokół L2TP automatycznie używa protokołu IPSec do zabezpieczenia tunelu zgodnie z ustawieniami zabezpieczeń zawartymi w konfiguracji użytkownika tunelu L2TP. Protokół IKE (IPSec Internet Key Exchange) negocjuje zabezpieczenia dla tunelu L2TP; uwierzytelnianiem domyślnym jest uwierzytelnianie oparte na certyfikacie. Uwierzytelnianie korzysta z certyfikatów komputera (a nie certyfikatów użytkownika) w celu sprawdzenia, czy komputer źródłowy i docelowy ufają sobie. Jeżeli zabezpieczenia transportu protokołu IPSec zostaną pomyślnie ustanowione, protokół L2TP negocjuje tunel (włącznie z kompresją i opcjami uwierzytelniania użytkownika) i wykonuje kontrolę dostępu na podstawie tożsamości użytkownika.

Wygląd struktury pakietów L2TP/IPSec przedstawiono w następującym przykładzie. Ładunek protokołu PPP zawiera oryginalny datagram IP oraz pisany kursywą tekst, który opisuje rodzaj danych szyfrowanych za pomocą protokołu IPSec. Protokół MPPE (Microsoft Point-to-Point Encryption Protocol), którego można używać do zabezpieczania ładunku protokołu PPP podczas korzystania z protokołów EAP-TLS (Extensible Authentication Protocol Transport Layer Security) lub MS-CHAP (Microsoft Challenge-Handshake Authentication Protocol), jest negocjowany przez system Windows po wyemitowaniu żądania przez końcówkę portu L2TP (klient lub serwer).

Protokół MPPE korzysta z szyfrowania strumieniowego RSA (Rivest-Shamir-Adleman) oraz z 40-bitowych, 56-bitowych lub 128-bitowych tajnych kluczy. Klucze MPPE są generowane podczas uwierzytelniania użytkownika przez protokoły MS-CHAP i EAP-TLS. Serwer zdalnego dostępu można skonfigurować w taki sposób, aby wymagał szyfrowania danych. Jeżeli klient zdalnego dostępu nie wykonuje wymaganego szyfrowania, próba połączenia jest odrzucana i pojawia się następujący komunikat o błędzie (#742): Protokół IPSEC jest negocjowany przed uruchomieniem protokołu PPP; protokół MPPE jest negocjowany po uruchomieniu protokołu PPE. Protokół PPP jest uruchamiany przez protokół L2TP przy użyciu protokołu IPSec. Podczas fazy uwierzytelniania protokołu PPP nazwa użytkownika jest wysyłana do składnika serwera dostępu zdalnego serwera sieci VPN (Virtual Private Network) za pomocą skonfigurowanego protokołu uwierzytelniania (na przykład MS-CHAP). Następnie serwer dostępu zdalnego dopasowuje nazwę użytkownika i inne właściwości wywołania do zasad dostępu zdalnego. Każda z zasad ma profil, a serwer dostępu zdalnego porównuje warunki wywołania przychodzącego z profilem w celu ustalenia, czy żądanie połączenia ma zostać zaakceptowane.

Informacje

• Jeżeli klient sieci VPN znajduje się za urządzeniem sieciowym, które wykonuje translację adresów sieciowych (NAT), sesja protokołu L2TP kończy się niepowodzeniem, ponieważ szyfrowane pakiety ESP (Encapsulating Security Payload) zostają uszkodzone. Jeżeli klient sieci VPN znajduje się na tym samym komputerze co składnik Udostępnianie połączenia internetowego systemu Windows/Translator adresów sieciowych, klient może ustanowić sesję L2TP, ponieważ translator NAT nie wykonuje translacji żadnego adresu IP ani portu w pakietach, które pochodzą z jego własnego węzła.
• Potrzebny jest certyfikat komputera z kluczem prywatnym, znajdujący się w osobistym magazynie certyfikatów komputera lokalnego. Można go sprawdzić, uruchamiając konsolę Microsoft Management Console (MMC.exe) i dodając przystawkę Certyfikaty dla komputera lokalnego. Użytkownik musi mieć prawa administratora lokalnego.
  
  W przypadku, gdy nie zostanie odnaleziony żaden certyfikat, protokół L2TP emituje ostrzeżenie, że użytkownik nie ma certyfikatu; protokół nie dysponuje jednak informacją, czy certyfikat został poprawnie zainstalowany i czy z istniejącym certyfikatem skojarzono prywatny klucz. Protokół IKE ustala to w czasie negocjacji. Uruchom przystawkę Certyfikaty (Komputer lokalny), kliknij dwukrotnie pozycję Certyfikaty i sprawdź, czy w pozycji Ogólne widać tekst „Masz klucz prywatny odpowiadający temu certyfikatowi”. Należy również sprawdzić, czy ścieżka certyfikatu jest kompletna oraz czy certyfikat jest prawidłowy.
  
  Klient musi dysponować certyfikatem komputera, którego główny urząd certyfikacji jest taki sam, jak urząd certyfikatu bramy. Przyczyna niepowodzenia certyfikatu jest rejestrowana przez protokół IKE we wpisie dziennika zdarzeń Zabezpieczenia. Obie strony muszą być w stanie pomyślnie wykonać sprawdzanie poprawności certyfikatu. Jeżeli uwierzytelnienie certyfikatu jest udane, wpis w dzienniku Zabezpieczenia informuje o pomyślnym zdarzeniu polegającym na ustanowieniu skojarzenia zabezpieczenia trybu głównego protokołu IPSec (logowanie/wylogowanie).
• Niepowodzenie negocjacji protokołu IKE: można sprawdzić, czy protokół IPSec działa prawidłowo, uruchamiając konsolę MMC (MMC.exe) i dodając Monitor zabezpieczeń IP (jako administrator lokalny). Opcje należy ustawić w taki sposób, aby były odświeżane w interwałach jednosekundowych. Jeżeli pojawia się skojarzenie zabezpieczenia protokołu IPSec, oznacza to, że protokół został pomyślnie uruchomiony. Można z tego wyciągnąć wniosek, że źródłem problemu jest protokół L2TP. Po zainstalowaniu narzędzi pomocy technicznej systemu Windows XP użyj polecenia netdiag /test:ipsec /v /debug, aby zobaczyć szczegóły zasad IPSec. (Jeżeli na komputerze lokalnym zasady zostały ustawione przez administratora domeny, nie wszystkie z nich są widoczne).
  
  Należy także zwrócić uwagę na następujące problemy:
  • Przekroczenie limitu czasu protokołu IKE: protokół IKE może przekroczyć limit czasu podczas wstępnego żądania negocjacji, jeżeli routery znajdujące się przed serwerem VPN nie zezwalają na korzystanie z portu UDP o adresach do 500. Protokół IKE przekracza limit czasu również wtedy, gdy na serwerze VPN brakuje odpowiednio skonfigurowanych zasad IPSec, co zazwyczaj oznacza, że na serwerze RRAS nie włączono portów L2TP lub że ręczne ustawienie zasady IPSec nie zostało prawidłowo skonfigurowane. Po przekroczeniu limitu czasu w dzienniku inspekcji widać informację, że końcówka nie może odpowiedzieć, a śledzenie przechwytywania sieci pokazuje informacje o pakietach ISAKMP UDP inicjowanych tylko przez klienta. Jeżeli klient VPN jest skonfigurowany specjalnie dla protokołu L2TP, to w ramach odpowiedzi wyświetla on następujący komunikat o błędzie:
    Negocjacje zabezpieczeń przekroczyły limit czasu.
    Po ustawieniu opcji automatycznej podejmowana jest ponowna próba wykonania zadania za pomocą następnego protokołu znajdującego się na liście (PPTP).
  • Niepowodzenie protokołu IKE: nieudane negocjacje protokołu IKE oraz przyczyny niepowodzenia są rejestrowane w dzienniku zabezpieczeń (należy skorzystać z polecenia Ustawienia zabezpieczeń, a następnie z polecenia Logowanie/wylogowanie nieudanych inspekcji). Działanie protokołu IKE może się zakończyć niepowodzeniem, ponieważ poświadczenia certyfikatów nie działają lub pojawia się problem z konfiguracją zasady IPSec w przypadku, gdy została ustawiona ręcznie.
    
    Powodzenie negocjacji IKE jest rejestrowane w dzienniku inspekcji. Aby wszystkie negocjacje zabezpieczeń IPSec zakończyły się powodzeniem, dla portu UDP 1701 należy ustanowić skojarzenie zabezpieczeń trybu głównego oraz skojarzenie zabezpieczeń trybu szybkiego.
• Jeżeli wystąpi jeden z następujących symptomów, oznacza to, że protokół IPSec nie spowodował problemu:
  • W dzienniku inspekcji widać pomyślne ustanowienie skojarzenia zabezpieczeń trybu głównego oraz pomyślne ustanowienie skojarzenia zabezpieczenia trybu szybkiego.
  • Śledzenie przechwytywania sieci pokazuje informacje o ruchu ESP pochodzącym od klienta lub serwera.
  • W programie Ipsecmon.exe widać skojarzenie zabezpieczeń protokołu IPSec.
  Należy pamiętać, że zawsze ustanawiane są dwa skojarzenia zabezpieczeń protokołu IPsec: jedno dla każdego kierunku, każde z własnym indeksem zabezpieczeń; program Ipsecmon.exe pokazuje jednak tylko wychodzące skojarzenie zabezpieczeń.
• Tryb ESP zablokowany: gdy translator NAT znajduje się przed klientem lub gdy routery znajdują się przed siecią VPN, serwer może nie zezwalać na korzystanie z protokołu 50 (ESP). Pojawia się ruch wychodzący ESP z numerami indeksu parametrów zabezpieczeń, ale nie widać pakietów ESP o innym numerze indeksu parametrów zabezpieczeń przychodzących z bramy.
• Modyfikacja trybu ESP: jeżeli translator NAT, nieprawidłowy przełącznik lub inny węzeł sieci modyfikują lub uszkadzają pakiety znajdujące się w dowolnym miejscu w określonej ścieżce, pakiety są odrzucane przez sterownik IPSec, a w dzienniku odbierającego systemu pojawia się zdarzenie 4285 „Nie można uwierzytelnić mieszania”. Pakiety mogą również zostać uszkodzone przez interfejs sieciowy mający możliwość odciążania protokołu IPSec. Aby ustalić, czy interfejs ma taką możliwość, użyj narzędzia pomocy technicznej netsh. Wpisz następujące polecenie:
  netsh int ip show offload
• Jeżeli podejrzewasz, że karta interfejsu sieciowego może odciążać protokół IPSec, uruchom przechwytywanie Monitora sieci i użyj narzędzia Ipsecmon.exe, aby przeanalizować wszystkie próby połączenia. Sprawdź licznik „Otrzymane bajty poufne” w narzędziu Ipsecmon, aby ustalić, czy pakiety są tracone podczas odbierania. Możesz również ustawić wartość rejestru HKLM\System\CurrentControlSet\Services\IPSEC\EnableOffload DWORD na wartość 0. Jeżeli połączenie powiedzie się, oznacza to, że problem jest związany z odciążeniem. Problem można również rozwiązać, włączając automatyczne zasady protokołu IPSec.
• Jeżeli agent zasad IPSec zostanie zatrzymany przy użyciu przystawki Usługi lub polecenia net stop policyagent, automatyczna konfiguracja zasad IPSec protokołu L2TP zostanie utracona. W przypadku klientów VPN zasady są automatycznie instalowane, gdy jest uruchamiane połączenie. Upewnij się, że usługa agenta zasad IPSec została uruchomiona przed uruchomieniem połączenia klienta. Gdy zostanie kliknięte polecenie Połącz i trwa próba połączenia, za pomocą polecenia netdiag /test:ipsec /v /debug można zobaczyć statystykę IPSec i aktywne filtry. Pamiętaj, że użycie opcji /debug jest niemożliwe, jeżeli nie masz uprawnień administracyjnych w domenie.

Aby uzyskać więcej informacji o sieci VPN, zobacz artykuł „Microsoft Privacy Protected Network Access: Virtual Private Networking and Intranet Security” pod następującym adresem:

Aby uzyskać dodatkowe informacje, kliknij następujące numery artykułów w celu wyświetlenia tych artykułów z bazy wiedzy Microsoft Knowledge Base: