Nie ma lepszej nagrody za beta-testy jakiegoś produktu niż satysfakcja z bezpośredniej pracy z grupą produktową zwieńczonej poprawieniem istniejącego od lat, uciążliwego błędu. Niniejszym chciałem się właśnie pochwalić, że taki uciążliwy błąd w kliencie VPN systemu Windows 7 udało mi się zgłosić i doprowadzić do rozwiązania. Jeśli w swojej sieci korzystacie ze split-tunnelingu, czytajcie dalej... :-)
Na początek trochę teorii. Łącząc się zdalnie do sieci firmowej na ogół jest tak, że tunel VPN staje się jedynym oknem na świat klienta - dzięki temu administrator zyskuje pełną kontrolę nad komputerem, gdy tylko jest obecny w sieci firmowej. Jak to często jednak bywa, bezpieczeństwo zwykle nie idzie w parze z komfortem pracy. Konieczność przepychania calego ruchu przez tunel VPN, zwłaszcza w "luźniejszych" środowiskach jest wielce problematyczna.
Dla takich scenariuszy wymyślono split-tunneling, czyli możliwość przesyłania przez tunel VPN jedynie tego ruchu, który adresowany jest bezpośrednio do sieci firmowej. Cała reszta przesyłana jest istniejącym łączem internetowym klienta z pominięciem VPN. Aby to działało, w większości przypadków konieczne jest posiadanie przez klienta VPN odpowiednich tras do sieci zdalnej. Klient takie trasy może dodać sobie samodzielnie po zestawieniu tunelu, ale znacznie prościej jest je wysłać automatycznie przy pomocy DHCP. Dla porządku powiem tylko, że częściowym rozwiązaniem jest także stworzenie klientom profilu połączenia narzędziem CMAK - w moim przypadku to jednak nie wchodziło w grę.
Skonfigurowany lata temu kombajn Routing and Remote Access + serwer DHCP z przypisaną opcją 121 (classless static routes) spisywał się znakomicie przez długi czas - do momentu, gdy u klientów VPN pojawił się Windows Vista. Wtedy wszystko przestało działać, bo trasy w ogóle nie były dodawane. Eskalacja tego problemu w pomocy technicznej Microsoftu doprowadziła do wydania artykułu Bazy Wiedzy KB933340, a później także poprawki, która została nawet umieszczona w Service Packu 1. Faktycznie poprawka coś tam poprawiała, bo trasy były już pomyślnie dodawane do tablicy routingu klienta po ustanowieniu połączenia. Problem jednak w tym, że raz na kilka połączeń nawet wspomniana poprawka nie mogła rozwiązać tego coraz bardziej uciążliwego problemu - tras nie było.
Po kilkunastu miesiącach wielokrotnego rozłączania i ponownego łączenia pojawiła się wersja beta systemu Windows 7. Z dużym zainteresowaniem sprawdziłem, czy Microsoftowi udało się uporać z problemem. Niestety z przerażeniem stwierdziłem, że jest jeszcze gorzej - jeśli w Viście SP1 trasy z DHCP były brane pod uwagę w trzech przypadkach na pięć, tak w Windows 7 w najlepszym razie w jednym na pięć. Korzystając z faktu, że jestem beta-testerem w technicznym programie beta Windows 7 zgłosiłem to zachowanie jako błąd.
Poprosiłem o walidację błędu na grupach dyskusyjnych i wśród znajomych beta-testerów. Poświęciłem nawet kilka chwil na zbudowanie kompletnego środowiska testowego złożonego z Windows Server 2008, Windows Vista i Windows 7, na którym skonfigurowałem RRAS, DHCP i klientów VPN. Okazało się, że problem jest powtarzalny za każdym razem na czystych instalacjach systemów. Wywołało to oczekiwane przeze mnie zainteresowanie Microsoftu. W trakcie rozmów z inżynierem odpowiadającym za moje zgłoszenie wysłałem mnóstwo logów i raportów z narzędzi diagnostycznych.
Opłacało się jednak - błąd został rozwiązany w jednym z ostatnich buildów Windows 7! Każde połączenie skutkuje prawidłowym zaaplikowaniem tras u klienta VPN. Nie ma już problemów ze split-tunnelingiem i nie trzeba łączyć się po kilka razy, zanim VPN będzie funkcjonować prawidłowo. Szkoda tylko, że trwało to trzy lata. Szkoda też, że prawdopodobnie nie doczekamy się podobnej poprawki dla Windows Vista - Service Pack 2 nadal zawiera wspominany błąd, a po moim pytaniu o dostępność oddzielnej łatki niestety Microsoft zamilkł...
Na szczęście nie używam już Visty... ale będę o tym pamiętał w programie beta trzeciego Service Packa! :-)