Instalacja i konfiguracja elementów zdalnego dostępu z wykorzystaniem L2TP/IPsec i PKI, cz. II
Zawartość strony
 | Internet Authentication Service (IAS) |
| Serwer VPN |
| Import certyfikatów |
| Konfiguracja Klienta |
| Rozwiązywanie problemów i o czym warto pamiętać |
| Przeczytaj pozostałe części tego artykułu |
Internet Authentication Service (IAS)
Internet Authentication Service (Usługa Uwierzytelniania Internetowego) jest implementacją RADIUS-a (Remote Authentication Dial-In User Service) w Windows Server 2003. Potrafi wiele, jednak w naszym przykładzie jego rola będzie się sprowadzać do uwierzytelniania poświadczeń wprowadzanych przez użytkowników (w bazie kont Active Directory) i autoryzacji dostępu. Dlatego IAS musi być zainstalowany na serwerze, który jest członkiem naszej domeny.
Instalacja IAS
1. | Otwieramy aplet Start -> Control Panel -> Add or Remowe Programs. |
2. | Klikamy na Add/Remove Windows Components. |
3. | Następnie zaznaczamy Networking Services, klikamy na Details i wybieramy komponent Internet Authentication Service (Rys. 1). |
Rys. 1. Instalacja IAS.
Remote Access Policies
Remote Access Policies (Zasady Dostępu Zdalnego) są zbiorem reguł/warunków, które określają, kiedy połączenie zostanie zaakceptowane, bądź też odrzucone.
Utworzymy teraz na nasze potrzeby taką zasadę dostępu zdalnego i zagwarantujemy autoryzację członkom domenowej grupy „VPN Users”.
1. | Uruchamiamy przystawkę IAS znajdującą się w Administrative Tools. |
2. | Klikamy prawym klawiszem na Remote Access Policies i wybieramy New Remote Access Policy, co spowoduje uruchomienie kreatora. |
3. | Upewniamy się, że jest zaznaczona opcja „Use the wizard to set up a typical policy for a common scenario” i wpisujemy nazwę dla naszej zasady dostępu. |
4. | W następnym oknie wybieramy jedynie pierwszą opcję: VPN. |
5. | Kolejny krok umożliwia nam wybranie autoryzacji na poziomie pojedynczego użytkownika lub grupy. Zaznaczamy opcję Groups i dodajemy wcześniej utworzoną grupę dla użytkowników zdalnych, którą w naszym przypadku jest VPN Users. |
6. | Akceptujemy proponowaną metodę uwierzytelniania MS-CHAPv2 i przechodzimy dalej. |
7. | W oknie określającym poziom szyfrowania, odznaczamy dwie pierwsze opcje i zostawiamy jedynie najsilniejszą dostępną formę szyfrowania Triple DES or MPPE 128-bit. |
8. | Kończymy proces tworzenia nowej zasady dostępu zdalnego klikając na Finish. |
Sprawdźmy, czy nasza zasada znajduje się powyżej ogólnych zasad typu Deny (Rys. 2), ponieważ są one przetwarzane w kolejności; nieco upraszczając: „do pierwszej pasującej”.
IAS, jak widzimy, podczas instalacji utworzył standardowe reguły typu „Deny”, które uniemożliwią nam połączenie w przypadku, gdy któraś z nich zostanie zaaplikowana przed naszą polityką dostępu.
Więcej informacji na temat przetwarzania żądań połączeń: Processing a connection request (j. ang.).
Rys. 2. Zdalny dostęp dla grupy VPN Sers.
Dodajemy klienta RADIUS
W naszym przykładzie serwer VPN będzie przekazywał poświadczenia uwierzytelniające do serwera IAS. Musimy poinformować IAS o tym fakcie. Zrobimy to, definiując serwer VPN jako klienta RADIUS na serwerze IAS.
1. | Przechodzimy do przystawki IAS, którą znajdziemy w Administrative Tools i klikamy prawym przyciskiem myszy na RADIUS Clients, a następnie z menu wybieramy New RADIUS Client. |
2. | Podajemy adres naszego serwera VPN (192.168.1.254). |
3. | Następnym krokiem będzie wybranie Client-Vendor. |
4. | Jako że klientem IAS-a jest w naszym scenariuszu Windows Server 2003, wybieramy z listy: Microsoft. |
5. | Wpisujemy shared secret. |
6. | Zaznaczamy opcję „Request must contain the Message Authenticator attribute” (Rys. 3) i kończymy kreatora klikając na Finish. |
Rys. 3. Opcja “Request must contain the Message Authenticator attribute”.
Warto w tym miejscu wspomnieć o funkcji jaką pełni shared secret (wspólne hasło).
Otóż są nim szyfrowane niektóre elementy komunikacji pomiędzy klientami RADIUS i serwerem IAS, takie jak np. hasło użytkownika. Jest ono wykorzystywane również do sprawdzania, czy wiadomości przesyłane pomiędzy klientem i serwerem nie zostały w międzyczasie zmodyfikowane. Zapewnia więc ich integralność.
Zaleca się, aby shared secret złożony był przynajmniej z 22 znaków (maksymalnie 128) i zawierał litery, cyfry i znaki specjalne, oraz aby był co jakiś czas zmieniany. Przykład takiego ciągu znaków: A4U(dZ^YaQT%Rg6EW#4uWul!by6UhHe*. Komunikacja z serwerem IAS może stać się celem ataków „brute force”, dlatego naprawdę istotne jest, aby wspólne hasło, które wybierzemy, spełniało zalecenia wymienione powyżej.
Zaznaczenie opcji „Request must contain the Message Authenticator attribute” podwyższy bezpieczeństwo, kiedy uwierzytelnianie realizowane jest protokołami PAP, CHAP, MS-CHAP i MS-CHAP v2. Po jej aktywowaniu, każda wiadomość RADIUS zostanie wzbogacona o hasz MD5 całej wiadomości, gdzie za klucz posłuży nasz shared secret.
Serwer IAS akceptuje przychodzące wiadomości RADIUS typu "Access-Request" tylko z adresów IP zdefiniowanych wcześniej przez nas jako adresy klientów RADIUS.
Wymóg posiadania dodatkowego atrybutu w postaci haszu MD5 zabezpieczy przed ewentualnym fałszowaniem (spoofing) adresów źródłowych klientów RADIUS i przed ich modyfikacją, gdyż wiadomości pozbawione tego atrybutu uwierzytelniającego, bądź posiadające błędny hasz, będą po prostu przez serwer IAS odrzucane.
Z pewnością warto zwrócić uwagę na jeszcze jeden problem, zwłaszcza gdy w naszej domenie skonfigurowana jest polityka haseł, a konkretnie ustawienie „Account Lockout Policy: Account lockout threshold”. Chodzi o metodę brute-force skierowaną na konta użytkowników posiadających prawo zdalnego dostępu.
Użycie L2TP/IPsec znacznie zmniejsza prawdopodobieństwo wystąpienia takiego zagrożenia, gdyż najpierw osoba chcąca skorzystać z tej metody musiałaby wejść w posiadanie certyfikatów niezbędnych do zestawienia kanału IPsec. Nie eliminuje jednak tego zagrożenia całkowicie, nawet przy założeniu , że ograniczymy dostęp po PPTP.
Może zaistnieć taka sytuacja, kiedy konta użytkowników w AD będą regularnie blokowane, ponieważ podczas ataku brute-force serwer IAS będzie próbował uwierzytelnić użytkownika, przesyłając poświadczenia do kontrolera domeny i po kilku (w zależności od naszej polityki haseł) nieudanych próbach, zadziała domenowa polityka blokady konta.
Jednak nawet jeżeli nie uaktywniliśmy w AD blokady kont, to i tak nie chcemy przecież zezwolić na nieograniczone korzystanie z brute-force, które w końcu mogłoby zakończyć się powodzeniem. ;-)
Aby temu zapobiec, musimy odpowiednio skonfigurować serwer IAS. Umożliwi nam to ustawienie blokady konta dostępu zdalnego w rejestrze systemu przeprowadzającego uwierzytelnianie. W naszym przypadku będzie to więc serwer IAS. Dokonujemy modyfikacji klucza (Rys 4):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout
Rys. 4. Modyfikacja klucza.
Jak widać, możemy wykorzystać dwie funkcje: MaxDenials i ResetTime (mins).
Pierwsza z nich określa liczbę nieudanych logowań, po której osiągnięciu następne próby będą odrzucane. Wartość 0 oznacza, że opcja ta jest nieaktywna.
ResetTime określa oczywiście przedział czasu w minutach, po upływie którego, resetowany jest licznik nieudanych prób logowania. Standardowym ustawieniem jest 2880, czyli 48 godzin.
Logiczne wydaje się uzależnienie wartości MaxDenials od ewentualnego domenowego maksimum. Skoro więc w Active Directory blokujemy konto po np. 5 nieudanych próbach, to na serwerze IAS wartość MaxDenials nie powinna być wyższa niż 4. W przypadkach, gdy z różnych względów zechcemy ręcznie odblokować konto, będziemy musieli usunąć odpowiedni podklucz w rejestrze, odpowiadający nazwie zablokowanego konta użytkownika (Rys. 5.). Znajdziemy go w kluczu:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\
Rys. 5. Podklucz w rejestrze, odpowiadający nazwie zablokowanego konta użytkownika.
Serwer VPN
Teraz możemy rozpocząć konfigurację naszego serwera VPN:
1. | W tym celu przechodzimy do Administrative Tools i uruchamiamy przystawkę Routing and Remote Access. |
2. | Na ekranie powitalnym kreatora klikamy Next i przechodzimy do konfiguracji. |
3. | Naszym celem jest bezpieczne podłączenie zdalnych użytkowników do firmowej sieci, dlatego wybieramy opcję pierwszą, Remote Access (dial-up or VPN). |
4. | Założyliśmy, że nasi użytkownicy dysponują szerokopasmowym dostępem do Internetu i nie będą się wdzwaniać bezpośrednio do serwera VPN, dlatego w następnym oknie zaznaczamy jedynie pierwszą opcję: VPN. |
5. | Następnie wybieramy kartę sieciową łączącą serwer z Internetem. W naszym przypadku będzie to karta z adresem IP 10.1.1.254. |
6. | Mamy jeszcze możliwość podniesienia zabezpieczeń serwera, zezwalając na automatyczne utworzenie statycznych filtrów, dzięki którym na wybranej przez nas karcie dopuszczony będzie jedynie ruch związany z rolą, jaką pełnić ma nasz serwer. Zdecydowanie chcemy uaktywnić tę ochronę. Upewniamy się więc, że opcja „Enable security on the selected interface by setting up static packet filters” jest zaznaczona i klikamy Next (Rys. 6).  Rys. 6. Opcja „Enable security on the selected interface by setting up static packet filters”. |
7. | W następnym kroku określamy sposób przydzielania adresów IP łączącym się z naszym serwerem komputerom. Jeżeli posiadamy w sieci serwer DHCP, to możemy z niego skorzystać. Drugim rozwiązaniem jest ręczne określenie puli adresowej. Na tę opcję możemy się oczywiście zdecydować niezależnie od tego, czy w naszym środowisku jest aktywny DHCP. W przypadku gdy własnoręcznie przydzielimy zakres będący jednak częścią aktywnego scope serwera DHCP, to powinniśmy na nim wybraną przez nas pulę dodać do wyjątków (exclusion range). My wydzielimy ręcznie kilka adresów IP na potrzeby naszego VPN (Rys. 7) i przejdziemy do następnego okna kreatora. Pamiętajmy, że jeżeli zdecydujemy się przydzielić zakres adresów z innej podsieci niż nasza wewnętrzna, to musimy odpowiednio skonfigurować routing w naszej sieci.  Rys. 7. Ręczne wydzielanie adresów IP. |
8. | Nadszedł czas, aby skorzystać ze skonfigurowanego wcześniej serwera IAS, do którego nasz serwer VPN będzie przekierowywał dane uwierzytelniające wprowadzane przez użytkowników. Zaznaczamy więc opcję „Yes, set up this server to work with a RADIUS server” i klikamy Next. |
9. | Podajemy adres IP serwera RADIUS, którym w naszym przykładzie jest adres kontrolera domeny i wpisujemy shared secret, oczywiście taki sam, jaki wybraliśmy podczas konfiguracji klienta RADIUS na serwerze IAS. |
10. | Klikamy Next, a następnie Finish w oknie kończącym konfigurację RRAS-a. |
Wyłączymy jeszcze obsługę słabszych metod uwierzytelniania na naszym serwerze. Zrobimy to na zakładce Security we właściwościach naszego serwera, w przystawce „Routing and Remote Access”. Pomimo że uwierzytelnianie będzie już odbywało się w bezpiecznym kanale IPsec (w przeciwieństwie do PPTP), to i tak na ogół nie ma powodów, aby zostawić możliwość korzystania z takich metod, jak np. PAP i CHAP.
Klikamy przycisk „Authentication Methods...” i odznaczamy „Microsoft encrypted authentication (MS-CHAP)”.
MS-CHAPv2 jest wspierany nawet w Windows 95/98 (po doinstalowniu klienta VPN), więc nie powinno być problemów z kompatybilnością metod uwierzytelniania (Tabela 1).
Dodatkowo nie zaszkodzi na karcie akceptującej połączenia VPN, wyłączyć komponenty „Client for Microsoft Networks” i „File and Printer Sharing for Microsoft Networks”.
Tabela 1. Informacje dotyczące obsługi protokołów uwierzytelniania przez klientów wirtualnej sieci prywatnej firmy Microsoft
| Klient wirtualnej sieci prywatnej | Obsługiwane protokoły uwierzytelniania dostępu zdalnego | Nieobsługiwane protokoły uwierzytelniania dostępu zdalnego |
Systemy z rodziny Windows Server 2003, Windows XP i Windows 2000 | Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), Challenge Handshake Authentication Protocol (CHAP), Shiva Password Authentication Protocol (SPAP), Password Authentication Protocol (PAP), MS-CHAP w wersji 2 (MS-CHAP v2) i Extensible Authentication Protocol (EAP) |
|
System Windows NT w wersji 4.0 | MS-CHAP, CHAP, SPAP, PAP i MS-CHAP v2 (z dodatkiem Service Pack 4 lub nowszym) | EAP |
Windows 98 | MS-CHAP, CHAP, SPAP, PAP i MS-CHAP v2 (z dodatkiem Service Pack 1 lub nowszym) | EAP |
Windows 95 | MS-CHAP, CHAP, SPAP, PAP i MS-CHAP v2 (z uaktualnieniem Dial-Up Networking 1.4) | EAP |
Na tym etapie jest już możliwe połączenie VPN do serwera, ale z wykorzystaniem PPTP. Nie to jest naturalnie naszym głównym celem, chociaż może być bardzo przydatne podczas importu certyfikatów na komputerach spoza naszej sieci.
Istnieje również możliwość przetestowania połączeń L2TP/IPSec, tyle że z użyciem preshared key do zabezpieczenia połączenia. Rozwiązanie takie jest do zaakceptowania w celach testowych. Na przykład w przypadku problemów z połączeniem przy użyciu certyfikatów, możemy w ten sposób szybko potwierdzić, że ewentualny problem nie leży w obszarze topologii sieciowej, bądź też konfiguracji firewalla.
Aby połączenia L2TP/IPSec z użyciem współdzielonego klucza były możliwe, musimy w dwóch miejscach delikatnie dopasować konfigurację.
Pierwszym będzie serwer VPN.
Uruchamiamy przystawkę „Routing and Remote Access”, otwieramy właściwości naszego serwera VPN klikając na niego prawym klawiszem myszy i wybierając „Properties”, a następnie przechodzimy na zakładkę „Security”. Na niej zaznaczamy opcję „Allow custom IPSec policy for L2TP connection” i wpisujemy preshared key.
Drugim miejscem wymagającym modyfikacji, jest również zakładka Security, ale we właściwościach połączenia VPN na kliencie. Sposób utworzenia takiego połączenia opisałem nieco niżej, w części „Konfiguracja Klienta”. Znajdziemy tam przycisk „IPSec Settings...”, po którego kliknięciu, będziemy mogli zaznaczyć opcję „Use pre-shared key for authentication” i podać klucz. Powinien on być naturalnie identyczny z kluczem, który wpisaliśmy podczas konfiguracji „Allow custom IPSec policy for L2TP connection” na serwerze VPN.
Jeszcze raz zwrócę uwagę na fakt, że z tego rozwiązania powinniśmy korzystać jedynie w celach testowych.
Import certyfikatów
Poprawny import certyfikatów jest kluczowy, jeżeli chcemy przy ich pomocy uwierzytelnić i zaszyfrować bezpieczny kanał IPsec. Po pierwsze, musimy wygenerować odpowiedni certyfikat. Po drugie, musi się on znaleźć w odpowiednim magazynie certyfikatów na serwerze i na komputerze z którego będzie inicjowane połączenie VPN. Mając to na uwadze, już podczas konfiguracji CA, przygotowaliśmy odpowiedni szablon spełniający nasze potrzeby (IPSec (Offline request)).
Import certyfikatów na serwerze VPN
1. | Uruchamiamy przeglądarkę Internet Explorer. |
2. | Przechodzimy do http://192.168.1.1/certsrv, gdzie podajemy nazwę administratora domeny i hasło (lub użytkownika należącego do grupy Domain Administrators). |
3. | Po zalogowaniu się na stronie, klikamy Request a certificate -> advanced certificate request -> Create and submit a request to this CA. |
4. | Wybieramy z dostępnych szablonów IPSec (Offline request) (Rys. 8).  Rys.8. Szablon IPSec (Offline request). |
5. | Aby żądanie certyfikatu zakończyło się pomyślnie, musimy uzupełnić przynajmniej jedno pole w części Identifying Information For Offline Template. W miarę potrzeb podajemy również pozostałe informacje (Rys. 9).  Rys. 9. Pozostałe informacje. |
6. | Ostatnią zmianą jakiej dokonamy na stronie żądania certyfikatu, będzie zaznaczenie opcji „Store certificate in the local computer certificate store”. (Rys. 10). Jest to niezbędna czynność, która pozwoli zaimportować nasz certyfikat do właściwego magazynu. Pamiętajmy o tym, że aby import do magazynu certyfikatów lokalnego komputera zakończył się pomyślnie, musimy być zalogowani jako użytkownik z prawami lokalnego administratora.  Rys. 10. Opcja „Store certificate in the local computer certificate store”. |
7. | Resztę ustawień pozostawiamy bez zmian i akceptujemy żądanie klikając Submit. |
8. | Zatwierdzamy ewentualne ostrzeżenia. Jeżeli wykonaliśmy nasze dotychczasowe czynności poprawnie, to zostanie nam przedstawiona strona z linkiem „Install this certificate”. |
9. | Korzystamy z odnośnika i ponownie akceptujemy ewentualne ostrzeżenia. |
10. | O końcu całej operacji powinna poinformować nas strona z tekstem „Your new certificate has been successfully installed.”. Możemy zamknąć okno IE. |
Sprawdzimy teraz, czy nasz świeżo otrzymany certyfikat faktycznie został pomyślnie zaimportowany do odpowiedniego magazynu.
Do zarządzania certyfikatami skorzystamy z konsoli MMC i przystawki Certificates.
Dostosowanie konsoli MMC
1. | Na serwerze VPN otwieramy nowe okno konsoli. Start -> Run -> mmc.exe |
2. | Z Menu wybieramy File -> Add/Remove Snap-in... lub wciskamy Ctrl+M. |
3. | W oknie Add/Remove Snap-in klikamy Add i zaznaczamy przystawkę Certificates. |
4. | Ponownie wybieramy Add -> Computer account, a w następnym oknie, Local computer. |
5. | Kończymy dodawanie apletu. Odpowiednio: Finish, Close, OK i zapisujemy naszą nowo utworzoną konsolę. |
Aby potwierdzić obecność certyfikatu, sprawdzamy zawartość Certificates (Local Computer) -> Personal -> Certificates (Rys. 11).
Rys. 11. Zawartość Certificates (Local Computer) -> Personal -> Certificates.
Klikamy teraz prawym na certyfikat „VPN Server” i z menu wybieramy Open. Upewnijmy się, że jesteśmy w posiadaniu klucza prywatnego. Świadczyć o tym będzie ikonka klucza z opisem „You have a private key that corresponds to this certificate”, w dolnej części zakładki General (Rys. 12).
Rys. 12. Ikonka klucza z opisem „You have a private key that corresponds to this certificate”.
Oczywiście ciężko nie zauważyć czerwonej ikonki i informacji, że certyfikat nie może zostać poddany weryfikacji w urzędzie certyfikacyjnym. Powodem tego jest fakt, iż wciąż nie zaufaliśmy CA, od którego otrzymaliśmy nasz certyfikat. Naprawimy teraz to niedopatrzenie.
Import CA certificate chain
1. | Ponownie logujemy się na stronie http://192.168.1.1/certsrv. |
2. | Tym razem klikamy link “Download a CA certificate, certificate chain, or CRL” (Rys. 13), a następnie na “Download CA certificate chain”.  Rys. 13. Link “Download a CA certificate, certificate chain, or CRL”. |
3. | Zapisujemy certyfikat na pulpicie, np. jako „Firma CA chain.p7b”. |
4. | Klikamy na nim prawym i z menu wybieramy „Install Certificate”, a następnie z okna powitalnego kreatora importu przechodzimy do wyboru magazynu certyfikatów. |
5. | Zaznaczamy “Place all certificates in the following store” i klikamy “Browse…”. |
6. | W oknie “Select Certificate Store” najpierw wybieramy opcję “Show physical stores”, a później rozwijamy Trusted Root Certification Authorities i zaznaczamy Local Computer (Rys. 14).  Rys. 14. Trusted Root Certification Authorities i zaznaczone Local Computer. |
7. | Po zaakceptowaniu naszego wyboru wrócimy do poprzedniego okna, które teraz powinno wyglądać tak jak na Rys. 15.  Rys. 15. Nowy wygląd okna. |
8. | Klikamy kolejno Next i Finish, aby zakończyć działanie kreatora. |
Przy pomocy zapisanej wcześniej konsoli z przystawką „Certificates” sprawdzimy, czy „Firma CA” należy teraz do urzędów, którym ufa nasz komputer.
Rozwijamy Certificates (Local Computer) -> Trusted Root Certification Authorities -> Certificates i odszukujemy nazwę naszego CA (Rys. 16).
Rys. 16. Nazwa naszego CA.
Od tej chwili nie powinniśmy mieć już również problemów z weryfikacją wcześniej zaimportowanego certyfikatu “VPN Server”.
Na tym możemy właściwie zakończyć konfigurację naszego serwera VPN.
W tym miejscu, warto wspomnieć o dość istotnym szczególe. Jeżeli skonfigurowaliśmy RRAS-a przed importem certyfikatów, to aby próby połączeń L2TP/IPsec zakończyły się sukcesem, musimy zrestartować usługę „Routing and Remote Access”. Możemy to zrobić np. z poziomu przystawki RRAS.
Przechodzimy do Start -> Control Panel -> Administrative Tools -> Routing and Remote Access, klikamy prawym na nasz serwer i z menu wybieramy All Tasks -> Restart.
Konfiguracja Klienta
Import certyfikatów na kliencie możemy przeprowadzić co najmniej na dwa sposoby. Pierwszy nie różni się praktycznie w ogóle od tego, co zrobiliśmy przed chwilą na serwerze VPN. Preferowanym rozwiązaniem, jest nawiązanie połączenia VPN, ale z wykorzystaniem PPTP, o czym wspomnieliśmy już powyżej. Następnie generujemy żądanie certyfikatu i importujemy go w identyczny sposób, jak podczas konfiguracji serwera VPN. Można jeszcze udostępnić stronę CA w Internecie, jednak ze względów bezpieczeństwa, jest to zdecydowanie mniej kuszące rozwiązanie.
Druga opcja. Jeżeli jesteśmy w stanie zapewnić bezpieczny transport certyfikatów, to możemy je w imieniu klienta wygenerować i dostarczyć na zdalną stację przy pomocy pamięci USB lub dyskietki. Po podjęciu dodatkowych kroków (np. szyfrowanie), możemy pokusić się o ich transport również drogą elektroniczną, a hasło zabezpieczające klucz prywatny certyfikatu przekazać ustnie.
W naszym przykładzie skorzystamy z VPN PPTP. Musimy więc na naszej stacji utworzyć nowe połączenie.
Nowe połączenie sieciowe
1. | W celu utworzenia nowego połączenia na stacji, przechodzimy do Start -> Control Panel -> Network Connections -> New Connection Wizard. |
2. | W oknie „New Connection Type” zaznaczamy “Connect to the network at my workplace”. |
3. | Następnie wybieramy “Virtual Private Network connection” i przechodzimy dalej. |
4. | Wpisujemy nazwę połączenia (np. „VPN Firma”). |
5. | Zaznaczamy „Do not dial the initial connection.” |
6. | W części „VPN server Selection” podajemy adres IP naszego serwera VPN (10.1.1.254). |
7. | Dalej wybieramy „My use only”, co sprawi, że połączenie będzie dostępne tylko dla aktualnie zalogowanego użytkownika, i kończymy kreatora. |
W oknie „Connect VPN Firma” wpisujemy nazwę użytkownika i hasło, i klikamy „Connect” (Rys. 17).
Rys. 17. Okno „Connect VPN Firma”.
Po pomyślnym utworzeniu połączenia VPN w jego właściwościach łatwo sprawdzimy jakiego jest ono typu. Widzimy, że na razie udało nam się zestawić tunel PPTP (Rys. 18). Zresztą zgodnie z oczekiwaniami.
Rys. 18. Tunel PPTP.
Import certyfikatów na stacji PC.
Ponieważ procedura jest praktycznie identyczna z tą zastosowaną podczas konfiguracji serwera VPN, nie będziemy jej ponownie opisywać. Po prostu powtarzamy punkty z sekcji „Import certyfikatów na serwerze VPN”, „Dostosowanie konsoli MMC” i „Import CA certificate chain”.
Drobna zmiana nastąpi w polu „Name” formularza Identifying Information For Offline Template. Najpraktyczniej będzie wpisać nazwę identyfikującą jakoś zdalnego klienta, dla którego generowany jest certyfikat. To może być na przykład nazwa komputera. Na potrzeby artykułu, wpiszemy WKS-1 (Rys. 19).
Rys. 19. Nazwa zdalnego klienta.
Po pomyślnie zakończonym imporcie certyfikatów odłączamy się od firmy i we właściwościach połączenia „VPN Firma”, na zakładce Networking, w części „Type of VPN”, ustawiamy „L2TP IPSec VPN”. Jeżeli wszystko poszło dobrze, to tym razem okno „Details” powinno wyglądać tak, jak na Rys. 20.
Rys. 20. Okno „Details”.
Cel osiągnięty. Mam nadzieję, że nie tylko w tym artykule. ;-)
Rozwiązywanie problemów i o czym warto pamiętać
Garść uwag...
Gdy w magazynie posiadamy więcej certyfikatów, to mechanizm automatycznej selekcji może wybrać nieodpowiedni do próby połączenia (np. brak odpowiedniego rozszerzenia w EKU (Enhanced Key Usage) umożliwiającego uwierzytelnienie komputera), która to próba oczywiście zakończy się niepowodzeniem.
Jeżeli nie widzimy zaimportowanych certyfikatów w magazynie, pomimo komunikatu o pomyślnym ich imporcie, to przed rozpoczęciem bardziej zaawansowanych kroków zmierzających do rozwiązania „problemu”, najpierw po prostu spróbujmy odświeżyć zawartość magazynu.
Błąd 930: The authentication server did not respond to authentication requests in a timely fashion podczas próby połączenia, może oznaczać błąd w konfiguracji „atrybutu uwierzytelniającego”. Sprawdzamy jego konfigurację w RRAS: prawym przyciskiem na serwerze -> Properties -> zakładka Security -> Radius authentication: Configure -> Zaznaczamy zdefiniowany serwer RADIUS -> Edit.
Upewniamy się, że jest zaznaczona opcja „Always use message authenticator”.
Nie zapominamy o restarcie RRAS-a.
Na serwerze IAS: przystawka IAS -> Radius clients -> dwuklik na kliencie i zaznaczamy „Request must contain the Message Authenticator attribute”.
Błąd 649: The account does not have permissions to dial in.
Sprawdźmy konfigurację zakładki Dial-in we właściwościach konta użytkownika. Konto mogło również zostać zablokowane po osiągnięciu limitu „MaxDenials” w kluczu:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout
W takim przypadku usuwamy odpowiedni podklucz, o czym wspominałem powyżej.
Błąd 781: “The encryption attempt failed because no valid certificate was found”.
Najprawdopodobniej popełniliśmy błąd podczas importu certyfikatów i potrzebne jest poprawne przeprowadzenie odpowiedniej procedury.
Błąd 678: The remote computer did not respond.
Oprócz “popularnych” przyczyn, błąd ten może być spowodowany również modyfikacją rejestru, dlatego sprawdźmy obecność ustawienia „ProhibitIpSec” w kluczu:
HKLM\System\CurrentControlSet\Services\Rasman\Parameters\
Niektóre programy dopisują lub modyfikują wartość „ProhibitIpSec”. http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/regentry/87671.mspx
Jeżeli okaże się, że serwer IAS nie potafi uwierzytelnić naszych użytkowników domenowych, może to oznaczać, iż nie został on zarejestrowany w AD.
Metod rejestracji jest kilka:
| • | W przystawce IAS prawym przyciskiem na „Internet Authentication Service (Local)” i wybieramy „Register Server in Active Directory”. |
| • | W CMD wpisujemy: netsh ras add registeredserver. |
| • | W ADUC dodajemy konto serwera IAS do grupy “RAS and IAS Servers”. |
Zastosowanie którejkolwiek z tych metod, powinno zaowocować pożądanym rezultatem.
Więcej informacji na temat rozwiązywania problemów związanych z IPsec:
| • | Rozwiązywanie podstawowych problemów z protokołem L2TP/IPSec w systemie Windows XP (j.ang.) |
| • | |
| • |
Przeczytaj pozostałe części tego artykułu
| • |
 | Dariusz Kiszkiel (MCSE+S) |