Przychodzący VPN w Windows czy host OpenVPN: wybierz w pięć minut
Wbudowany nasłuch Windows wystarczy do testu między dwoma maszynami. Porównaj go z punktem końcowym na routerze i hostem OpenVPN, zanim wybierzesz dla prawdziwych użytkowników.
Windows może przyjmować połączenie VPN bez niczego zainstalowanego poza systemem operacyjnym, i to naprawdę pomaga, gdy dwie należące do ciebie maszyny potrzebują tunelu na jedno popołudnie. Przydatne pozostaje mniej więcej tak długo. Wbudowany nasłuch ma stałe menu protokołów, brak polityki dla poszczególnych klientów i zależność od pulpitu, który ktoś może zamknąć. Wybór między nim, punktem końcowym na routerze i hostem OpenVPN sprowadza się do trzech warunków, a nie do preferencji.
Czym wbudowany nasłuch naprawdę jest
Kreator połączeń przychodzących zamienia stację roboczą w mały punkt końcowy dostępu zdalnego. Wybierasz, które konta lokalne mogą się łączyć, jak przydzielane są adresy i który protokół jest włączony: PPTP oraz L2TP/IPsec lub SSTP tam, gdzie obsługują je edycja i praca z certyfikatami.
Czym nie jest, to warstwa polityki. Nie ma przydziału tras dla poszczególnych użytkowników, nie ma wymuszonego przez serwer tunelu dzielonego ani rozdzielenia między tunelem a własną tożsamością sieciową stacji roboczej. Klient, który się łączy, trafia do tego samego segmentu co stacja robocza, pod reguły zapory tego segmentu.
Właśnie ten ostatni punkt trzeba rozważyć. Własne porty, udziały i przeglądarka stacji roboczej są teraz osiągalne dla każdego, kto ma konto, a konto jest lokalnym kontem Windows z wszystkim innym, co już potrafi.
Trzy warunki, które decydują
Zapytaj, jak długo dostęp ma trwać, ile osób go potrzebuje i czy sieć w ogóle potrafi dostarczyć protokół.
Jeśli odpowiedź brzmi: jedna maszyna, jedna osoba i kilka godzin w sieci, w której to ty kontrolujesz router, wbudowany nasłuch jest odpowiedni. Jeśli dostęp musi przetrwać restarty przez miesiąc, obsługiwać pięciu kolegów z osobnymi poświadczeniami lub działać z sieci komórkowej, która nie może odbierać połączeń przychodzących, to nie jest. Jeśli protokół wymaga protokołu IP 47 zamiast portu, sieć może odmówić jego dostarczenia, niezależnie od tego, co obsługuje Windows.
Te trzy odpowiedzi usuwają większość sporu za jednym razem. Reszta to szczegół implementacji.
Gdzie wygrywa punkt końcowy na routerze
Tunel kończący się na routerze jest naturalnym wyborem dla stałego dostępu. Router jest już zawsze włączony, potrafi przenosić tunel między lokalizacjami do innego biura, a klienci nie muszą nic instalować, jeśli router oferuje protokół, którego używają.
Ograniczeniem jest firmware. Routery konsumenckie często obsługują tylko część tego, co dopuszcza specyfikacja, a model reklamujący obsługę VPN może nie zawierać dokładnie tego protokołu, który zaplanowałeś. Sprawdź listę funkcji zainstalowanego firmware, a nie rodziny produktów.
Gdzie wygrywa host OpenVPN
Serwer OpenVPN na małej, zawsze włączonej maszynie pasuje do mieszanych klientów, kilku użytkowników z osobnymi poświadczeniami i sieci, w których jeden port przyjazny dla ruchu wychodzącego jest różnicą między działaniem a zablokowaniem. Wydaje profil dla każdego klienta, działa na wszystkich głównych platformach i z punktu widzenia klienta zachowuje się jak zwykła aplikacja wychodząca.
Wymaga też właściciela. Ktoś musi odnawiać certyfikaty, stosować aktualizacje hosta i czytać dziennik, gdy klient nie może się połączyć. Bez tej osoby samodzielnie hostowany punkt końcowy cicho podupada aż do dnia, w którym ma znaczenie.
Sprawdź ścieżkę, zanim obiecasz dostęp
Najczęstszą przyczyną awarii nasłuchu Windows nie jest uwierzytelnianie. To ścieżka: PPTP potrzebuje przychodzącego TCP 1723 i GRE, czyli protokołu 47, a nie portu, a wiele routerów przekazuje tylko porty. Niektóre sieci dostępowe w ogóle nie pozwalają na połączenia przychodzące. Ten jeden fakt wyklucza wbudowany nasłuch w większej liczbie sieci niż jakiekolwiek ustawienie Windows.
Przetestuj ścieżkę przed skonfigurowaniem kont, żeby awaria miała jednego kandydata zamiast trzech:
Test-NetConnection -ComputerName 203.0.113.45 -Port 1723
Get-NetAdapterBinding | Where-Object ComponentID -like ms_pptp
ss -lunp | grep 1194Zamknięty port w pierwszej linii to problem przekierowania lub operatora, a nie Windows. Trzecia linia to sprawdzenie, które wykonałbyś po wybraniu OpenVPN, gdzie jeden nasłuchujący port UDP zastępuje całe pytanie o protokół.
Którąkolwiek opcję wybierzesz, nie zostawiaj PPTP skierowanego do internetu jako rozwiązania długoterminowego; jego uwierzytelnianie i szyfrowanie są przestarzałe. A jeśli prawdziwą potrzebą jest jedna aplikacja webowa, odwrotne proxy jest mniejszą odpowiedzią niż jakikolwiek VPN.