Pulpit zdalny Microsoft za pośrednictwem portu przekierowanego przez ssh

Mam sytuację, w której zapewniam dostęp do serwera Windows, przekierowując port 3389 pulpitu zdalnego z ssh z mojego komputera Mac do „wnętrza” sieci niedostępnej w inny sposób.

Mogę teraz połączyć się z Pulpitem zdalnym w wersji dla systemu Windows , ale wersja Pulpitu zdalnego dla komputerów Mac przekroczyła limit czasu i nie zapewniam dostępu. Dzieje się tak nawet w przypadku używania numeru IP jako hosta do połączenia.

Masz pojęcie, dlaczego tak się dzieje i jak mogę to obejść?

Nie przekierowuj lokalnego portu 3389, różne wersje Pulpitu zdalnego są zbyt inteligentne dla własnego dobra.

Moje zwykłe kroki polegają na przekierowaniu lokalnego 3390 na zdalny 3389. Następnie w MacRDC używam: localhost:3390jako adresu do połączenia.

Nie wiem, czy używasz czegokolwiek do pomocy w konfiguracji połączenia ssh, ale z wiersza poleceń byłoby to coś takiego:

ssh -L 3390:172.16.5.32:3389 jason@remote.net

Gdzie;
- 3390to lokalny port przekierowania na moim urządzeniu.
- 172.16.5.32jest hostem zdalnego systemu Windows. i;
- 3389jest portem pulpitu zdalnego (oczywiście).

Na komputerze Mac wypróbuj to rozwiązanie:

• zainstaluj sshuttle (implementuje tunel ssh / proxy, ale także wprowadza zmiany w routingu) ( https://github.com/apenwarr/sshuttle.git )

• skonfiguruj sshuttle, aby kierował tylko adres IP okna systemu Windows, do którego chcesz dotrzeć:

  sshuttle --dns -r YourUserName@YourSSHBox.com 1.1.1.1/32

  Zastąpić:

  1.1.1.1/32 z adresem IP hosta systemu Windows. Jeśli istnieje liczba hostów, do których musisz uzyskać dostęp, i są one w tej samej podsieci, możesz po prostu zmienić / 32 na coś szerszego, powiedzmy / 24.

• Uruchom klienta Mac RDP na komputerze Mac i spróbuj uzyskać dostęp do adresu IP komputera z systemem Windows. Być może możesz użyć nazwy hosta, jeśli przesyłasz zapytania DNS do skrzynki używanej jako pomost.

Jest to odmiana metody -D3389, ale wykorzystuje ona funkcje proxy skarpet ssh.

Czy próbowałeś wyłączyć wymóg „Uwierzytelniania na poziomie sieci” w „Panelu sterowania -> System -> Zezwalaj na dostęp zdalny” na komputerze docelowym?

Pulpit zdalny systemu Windows implementuje więcej algorytmów uwierzytelniania i szyfrowania specyficznych dla systemu Windows. Zdarzyło nam się to często, w rzeczywistości jesteśmy zmuszeni do korzystania z pulpitu zdalnego systemu Windows przez naszych administratorów sieci, ponieważ używamy metod uwierzytelniania, których OSX nie implementuje. Trzymajmy kciuki i miejmy nadzieję, że Microsoft wyda mecz dla pulpitu zdalnego klasy Windows.

Wypróbuj CoRD: wpisz opis linku tutaj

Odkryłem, że działa lepiej niż oficjalny klient RDP i ma tendencję do płynniejszej obsługi niedoskonałych ustawień.

Wydaje się, że klient Microsoft Remote Desktop OSX nie obsługuje domyślnej metody uwierzytelniania używanej przez system Windows 7+

Rozwiązaniem jest wykonanie następujących czynności na komputerze z systemem Windows:

• Start -> Edytuj zasady grupy

• Konfiguracja komputera

  • Szablony administracyjne

    • Komponenty Windows

      • Usługi pulpitu zdalnego

      • Host sesji usług pulpitu zdalnego

        • Bezpieczeństwo

          1. Zmień „Wymagaj użycia określonych dla połączeń pulpitu zdalnego” na Włączone i wybierz RDP z menu rozwijanego.

          2. Zmień „Wymagaj uwierzytelnienia użytkownika dla połączeń zdalnych przy użyciu uwierzytelniania na poziomie sieci” na Wyłączone

Teraz powinieneś być w stanie połączyć się za pomocą klienta pulpitu zdalnego OSX bez żadnych problemów przez tunel SSH.

Czasami po prostu aktualizacja oprogramowania rozwiązuje problem.

W oczekiwaniu na system operacyjny powinieneś upewnić się, że masz prawidłową wersję WRDC.

Ponieważ masz nieaktualną wersję 2.1.0, powinieneś zaktualizować ją do jednej z poniższych. Ver. 2.1.1 od Microsoft lub najnowszej wersji. 2.1.2 od dołu.

http://www.cloud9realtime.com/Guides/Macintosh%20RDP%20Guide.pdf

Jeśli aktualizacja oprogramowania nie pomoże i nie możesz połączyć się z adresem IP, nazwą hosta lub nazwą komputera, prawdopodobnie port 3389 jest zablokowany gdzieś w Twojej sieci WAN.

Aby przetestować konfigurację tunelowania ssh, spróbuj telnetować do portu na komputerze lokalnym.

Przekazywanie do portu 3389 z pewnością sprawi ci problemy. System rozpozna to, co próbujesz zrobić, i po prostu sam zwarcie. To jest wada DIY Remote Desktop , imho.