Być może kupię sobie wkrótce dwie karty wireless... Głównie tak dla zabawy, bo z laptopem zbyt mobilny po mieszkaniu nie jestem ze względu na umierającą baterię, ale trzeba się rozwijać, prawda? Access Point zamierzam postawić na przygotowanym wcześniej OpenBSD. Wiem już, że OpenBSD nie wspiera WPA (przynajmniej w chwili obecnej), a wykorzystanie WEP powodować może pewien dyskomfort, dlatego przećwiczyłem własnie tunele IPSec... Nie obyło się oczywiście bez pewnych przygód.
Tunele IPSec w Windows
Tworzenie reguł IPSec w Windows nie jest tak trywialne jak mogłoby się wydawać. Należy stworzyć filtr, czyli określić jaki ruch ma być tunelowany (w przypadku Windows tunelowane jest wszystko, czyli cały IP, nie można tunelować tylko niektórych protokołów lub portów), określić akcje (blokowanie ruchu, akceptowanie ruchu, wymuszenie określonego zabezpieczenia), określić końce tunelu, określić metodę uwierzytelnienia... Niby proste, a można się pogubić. W przykładzie, o którym mowa zakładam, że każdy ruch będzie tunelowany, tak więc filtry wyglądają mniej więcej tak:
- Mój adres IP -> Dowolny adres IP
- Dowolny adres IP -> Mój adres IP
Tu jest właśnie pierwsza pułapka, nie można wykorzystwać opcji Mirrored, która dobrze się sprawdza przy IPSec w trybie innym niż tunelowy. Konieczne jest stworzenie DWÓCH reguł, a nie jednej mirrorowanej.
Po drugie konieczne jest podanie adresów bramki IPSec. I tutaj znowu częstym błędem (który zresztą sam nie jeden raz popełniłem) jest podanie w obu przypadkach tego samego adresu IP, czyli bramki tej "drugiej strony". A dowcip polega na tym, że tak NIE ma być. Zresztą gdy nad tym pomyśleć, całość wydaje się sensowna. Z tunelem jak z kijem - ma dwa końce. Jeśli tworzony jest tunel z NetA do sieci NetB i w sieciach tych znajdują się odpowiednio GwA i GwB, to co dziwne opisując regułę ruchu NetA->NetB jako koniec tunelu podać należy GwB, a w drugiej regule GwA.
Należy wspomnieć również, że istnieje narzędzie pozwalające na skonwertowanie pliku konfiguracyjnego FreeS/WAN na reguły IPSec dla Windows. Dostępne ono jest tutaj.
Tu własnie pojawia się pewna pułapka. Oczywiście jako osoba nieco nienormalna postanowiłem zrobić sobie IPSec w oparciu o certyfikaty. Udało mi się to jakiś czas temu, w ramach dodatkowej zabawy włączyłem w rejestrze flagę StrongCRLCheck, a konkretnie ustawiłem ją na wartość 2. Opis weryfikacji certyfikatu w IPSec znajduje się między innymi tutaj. Wartość 2 powoduje, że gdy CRL nie uda się zweryfikować (np. nie udaje połączyć się z serwerem określonym w CDP), certyfikat jest traktowany jako nieważny. I tutaj problem, reguła określa, że tunelowany ma być cały ruch z określonego adresu IP do jakiegokolwiek innego adresu. Pod jakikolwiek inny adres podpada również adres CDP, czyli w celu pobrania listy CRL należy pobrać listę z adresu, do którego ruch powinien być zabezpieczony przez IPSec, ale nie można tego tunelu nawiązać, ponieważ nie można sprawdzić statusu certyfikatu. Chwilowo przestawiłem flagę StrongCRLCheck na 1, ale docelowo postaram się zrobić takie reguły (o ile okaże się to możliwe), by ruch w obrębie sieci nie był kierowany do tunelu. Oczywiście, mógłby być nadal zabezpieczony przez IPSec, natomiast ruch po kilku portach (między innymi tych potrzebnych do pobrania listy CRL) będzie mógł odbywać się bez szyfrowania.
Wydajność... No cóż, z wydajnością IPSec bywa różnie. Skorzystałem z algorytmów 3DES oraz SHA1. Przy takiej konfiguracji udało się osiągnąć przepustowość na poziomie 8Mbit/s, gdzie drugi koniec kanału to Gentoo zainstalowane na komputerze z procesorem AMD K6-2 450Mhz. Wydajność może nie przytłacza, ale w "normalnych" zastosowaniach (przeglądanie stron, poczta elektroniczna, itp) jest to wystarczające. Zwłaszcza, że łącze do internetu to tylko 640Kbit/s :)
