Czy VPN może zastąpić pulpit zdalny? Co robi każde z nich

Otwiera się okno, prosi o dane logowania, po czym zostaje puste albo się zamyka, a użytkownik zgłasza, że VPN zepsuł zdalny dostęp. Czasem tunel jest w porządku, a sesja nigdy się nie zaczęła. Wiedza o tym, gdzie aplikacja faktycznie działa, jest tym, co rozdziela te przypadki, bo tunel i sesja pulpitu dają różne rzeczy i zawodzą w różnych miejscach.

Tunel daje twojemu urządzeniu drogę do sieci. Sesja pulpitu daje ci ekran i klawiaturę podłączone do innej maszyny.

Objaw zależy od tego, gdzie działa aplikacja

Przy bezpośrednim dostępie przez tunel aplikacja działa na twoim własnym urządzeniu, a jej żądania przechodzą dozwoloną prywatną trasą do udziału plików lub wewnętrznej witryny. Jeśli ta aplikacja zawodzi, patrzysz na problem z rozwiązywaniem nazw albo routingiem, a lokalny program poza tym zachowuje się normalnie.

W sesji zdalnej aplikacja działa na maszynie po drugiej stronie, a twoje urządzenie otrzymuje jej obraz. To całkowicie zmienia listę usterek: host sesji musi być dostępny, usługa przyjmująca połączenia musi nasłuchiwać, a twoje konto musi być upoważnione zarówno na tunelu, jak i na hoście. Puste okno po udanym logowaniu do tunelu zwykle oznacza, że druga autoryzacja nigdy się nie powiodła.

Oba rozwiązania mogą współistnieć dla tego samego użytkownika. Typowy układ wymaga najpierw tunelu, a potem sesji pulpitu w nim, dlatego częściowy sukces tak łatwo odczytać jako jedną zepsutą funkcję.

Wydajność zależy od obciążenia, nie od etykiety

Otwarcie dużego pliku bezpośrednio przez tunel przenosi ten plik przez sieć, a widoczne opóźnienie idzie za transferem, nie za kliknięciem. W sesji zdalnej plik może nigdy nie opuścić centrum danych, co usuwa transfer i zastępuje go odświeżaniem ekranu oraz opóźnieniem wejścia. Żadne rozwiązanie nie jest ogólnie szybsze, bo przenoszą różne rzeczy. Zapytaj, na jaką wielkość użytkownik naprawdę czeka, zanim wybierzesz metrykę.

Ta różnica ma znaczenie, gdy ktoś zgłasza powolność. Sesja zdalna, która podczas pisania wydaje się ociężała, jest wrażliwa na opóźnienie w obie strony, natomiast bezpośrednie otwarcie pliku przez ten sam tunel jest wrażliwe na przepustowość. Mierz zadanie, a nie ogólny wskaźnik szybkości, i testuj konkretną czynność, na którą użytkownik się skarży.

Praca interaktywna po trasie o wysokim opóźnieniu pogarsza się, im więcej ekranu się zmienia, dlatego przewijanie dokumentu odczuwa się inaczej niż patrzenie na nieruchome okno. Jeśli skarga dotyczy responsywności, a nie czasu zakończenia, to miejsce obciążenia jest tą zmienną, którą warto zmienić.

Gdy coś zawodzi, sprawdzaj każdą warstwę osobno

Idź od środka na zewnątrz i zapisuj, co zwraca każdy krok, bo restartowanie wszystkiego naraz niszczy dowody. Potwierdź, że tunel działa, potem że prywatna trasa się rozwiązuje, potem że host sesji przyjmuje połączenia, potem że twoje konto jest na nim dozwolone.

Test-NetConnection -ComputerName 172.20.8.30 -Port 3389
Resolve-DnsName workstation-14.corp.example
qwinsta /server:172.20.8.30

Trasa, która odpowiada, i port, który odmawia, to różne wyniki, a port, który odpowiada, gdy twoje dane logowania są odrzucane, to trzeci wynik. Jeśli wdrożenie korzysta z zarządzanej bramy dostępu zamiast tunelu do biura, podążaj za tą architekturą, a nie wystawiaj usługi pulpitu do internetu tylko dlatego, że prywatna trasa zawiodła.

Szyfrowanie i autoryzacja to także osobne zadania. Tunel szyfruje drogę, protokół sesji uwierzytelnia cię na hoście, a aplikacja może uwierzytelnić cię jeszcze raz. Zaliczenie pierwszego sprawdzenia nic nie mówi o trzecim, a wskazówki, jak dotrzeć do zdalnego komputera spoza sieci opisują elementy potrzebne w działającym wdrożeniu.

Zdecyduj, co musi pozostać w organizacji

Zakładanie, że sesja zdalna trzyma każdy dokument w centrum danych, jest niebezpieczne. Udostępnianie schowka, przekierowane dyski i drukowanie mogą przenosić informacje między oboma środowiskami, gdy polityka na to pozwala, a tunel nie ogranicza, które pliki upoważniony użytkownik kopiuje z osiągalnego udziału. Jeśli wymogiem jest zamknięcie, przejrzyj rzeczywiste mechanizmy kontroli transferu w sesji, a nie ufaj schematowi architektury. Zapytaj właściciela sesji, które przekierowania są włączone, zanim coś obiecasz w jego imieniu.

Czas życia sesji to druga niespodzianka. Zamknięcie okna może zostawić sesję działającą na hoście, więc utrata tunelu może ją tylko tymczasowo uczynić nieosiągalną. Poznaj zatwierdzony sposób kończenia pracy na współdzielonej maszynie i sprawdź potem host, zamiast zakładać, że wylogowanie nastąpiło.

Zapisz, która warstwa zawiodła, co zmieniłeś i co użytkownik powinien sprawdzić ponownie. Ten zapis jest wart więcej niż rozwiązanie, którego nikt nie potrafi odtworzyć.