Łączenie z maszyną wirtualną Windows przez RDP z użyciem przekierowania portów na linuxowym bastion hoście w NSIS Cloud
Łączenie się z maszynami wirtualnymi Windows za pomocą protokołu Remote Desktop Protocol (RDP) często wymaga wystawienia usługi RDP bezpośrednio do sieci publicznej. Takie podejście zwiększa powierzchnię ataku, czyni usługę bardziej widoczną dla automatycznych skanów oraz może być sprzeczne z politykami bezpieczeństwa ograniczającymi bezpośredni dostęp do portów administracyjnych.
Powszechnym sposobem rozwiązania tych problemów jest całkowite unikanie publikowania usługi RDP i zamiast tego kierowanie połączenia przez kontrolowany punkt dostępu. W takim scenariuszu maszyna wirtualna Linux pełni rolę bastion hosta, a ruch RDP jest tunelowany przez szyfrowane połączenie SSH.
Bastion host nie nawiązuje sesji RDP. Pełni wyłącznie rolę przekazywania ruchu TCP za pomocą przekierowania portów SSH. Z punktu widzenia maszyny Windows istnieje dokładnie jedno połączenie przychodzące RDP, pochodzące z lokalnej maszyny użytkownika przez tunel SSH. Maszyna Windows nie łączy się sama ze sobą, a bastion host nie tworzy żadnych dodatkowych sesji RDP.
Takie podejście zmniejsza ekspozycję, poprawia ogólne bezpieczeństwo oraz umożliwia użycie jednego adresu floating IP do dostępu do wielu maszyn Windows bez przypisywania publicznych adresów IP do każdej z nich.
Zakres artykułu
Wymagania wstępne
Nr 1 Konto
Musisz posiadać konto hostingowe NSIS Cloud z dostępem do interfejsu Horizon: https://horizon.cloudferro.com/.
Nr 2 Maszyny wirtualne
Utwórz następujące maszyny wirtualne w tym samym projekcie chmurowym NSIS Cloud:
Jedna maszyna Linux (Ubuntu 24.04) pełniąca rolę bastion hosta, z włączonym dostępem SSH.
Jedna maszyna Windows (Windows Server 2019) pełniąca rolę celu RDP, znajdująca się w tej samej sieci prywatnej co bastion host.
Przypisz publiczny adres IPv4 wyłącznie do bastion hosta Linux. Maszyna Windows nie wymaga publicznego adresu IP, ponieważ dostęp do niej odbywa się wyłącznie poprzez przekierowanie portów SSH przez bastion hosta.
Pomocne mogą być następujące artykuły:
Poniżej przedstawiono maszyny wirtualne użyte w tym artykule: Bastion z Ubuntu 24.04 oraz rdp z Windows Server 2019.
Nr 3 Lokalny system Windows
Wszystkie kroki opisane w tym artykule wykonasz na lokalnym systemie Windows 11.
Nr 4 Grupy bezpieczeństwa
Upewnij się, że grupy bezpieczeństwa przypisane do maszyn wirtualnych zezwalają na następujące porty:
22/tcp — dostęp SSH do bastion hosta Linux
3389/tcp — dostęp RDP w sieci prywatnej (pomiędzy bastion hostem a maszyną Windows)
Maszyny wirtualne powinny mieć przypisaną grupę bezpieczeństwa podobną do allow_ping_ssh_icmp_rdp.
Nr 5 PuTTY i klucz SSH
Zainstaluj PuTTY na lokalnym systemie Windows, jeśli nie jest jeszcze zainstalowany:
Wymagane są również:
Prywatny klucz SSH pobrany z panelu OpenStack
Klucz przekonwertowany z formatu .pem do .ppk przy użyciu PuTTYgen
Szczegółowe instrukcje znajdziesz w artykule: Jak uzyskać dostęp do maszyny wirtualnej z Windows PuTTY na NSIS
Nr 6 Dane logowania Administratora Windows
Hasło Administratora dla maszyny Windows jest ustawiane bezpośrednio wewnątrz maszyny wirtualnej.
Skorzystaj z opcji Console w panelu OpenStack, aby zalogować się do maszyny Windows i ustawić lub zmienić hasło Administratora przed nawiązaniem połączenia RDP.
Hasło Administratora jest wymagane do uwierzytelnienia RDP i nie jest powiązane z lokalnymi użytkownikami Windows ani kontami SSH używanymi w tym artykule.
Krok 1. Informacje wymagane do nawiązania połączenia z bastion hostem
Uruchom PuTTY i zmień ustawienia zgodnie z poniższymi instrukcjami:
Zakładka Session: Podaj adres floating IP bastion hosta oraz port SSH (domyślnie 22).
Zakładka Connection > Data: Ustaw nazwę użytkownika do automatycznego logowania jako „eouser”.
Następnie wybierz Connection > SSH > Auth > Credentials > Private key file for authentication: i dodaj prywatny klucz w formacie .ppk.
Zakładka Connection > SSH > Tunnels: Podaj port źródłowy dla lokalnego połączenia RDP oraz adres docelowy (w formacie prywatny adres IP maszyny Windows:port RDP — jak na poniższym zrzucie ekranu).
Kliknij przycisk „Add”, aby zatwierdzić zmiany. Przekierowany port powinien być widoczny na liście.
Nadaj nazwę sesji i zapisz konfigurację, aby nie powtarzać całego procesu przy każdym kolejnym połączeniu.
Krok 2. Nawiązanie połączenia w PuTTY
Kliknij „Open”, aby nawiązać połączenie:
Efekt końcowy: jesteś teraz zalogowany jako eouser na maszynie bastion z systemem Linux. Pozostaw sesję PuTTY otwartą podczas korzystania z RDP, ponieważ utrzymuje ona tunel SSH wymagany do połączenia.
Krok 3. Uruchomienie sesji RDP do localhost w celu dotarcia do serwera docelowego
Ten krok jest wykonywany na lokalnym systemie Windows, a nie na bastion hoście.
Pozostaw sesję SSH w PuTTY otwartą, ponieważ utrzymuje ona tunel SSH i przekierowanie portów. Zamknięcie PuTTY natychmiast zakończy tunel i rozłączy sesję RDP.
Na lokalnym komputerze z systemem Windows uruchom klienta Pulpitu zdalnego:
Naciśnij Win + R.
Wpisz
mstsci naciśnij Enter, aby otworzyć Remote Desktop Connection.
W polu Computer wpisz lokalny adres i port skonfigurowany w PuTTY (np.
localhost:8888lub127.0.0.1:8888).Kliknij Connect.
Po wyświetleniu monitu o dane logowania wprowadź:
Username:
AdministratorPassword: hasło Administratora ustawione dla zdalnej maszyny Windows przy użyciu konsoli w panelu OpenStack (zob. Wymaganie wstępne nr 6).
Ważne
Jeśli uwierzytelnianie RDP nie powiedzie się, a w Horizon nie jest dostępna opcja „Reset Password”, otwórz Console dla maszyny Windows i zweryfikuj lub zmień tam hasło Administratora.
Potwierdź ostrzeżenie certyfikatu, jeśli pojawi się monit o kontynuację połączenia.
Po pomyślnym uwierzytelnieniu jesteś połączony ze zdalną maszyną Windows przez tunel SSH zapewniany przez linuxowy bastion host.
Lokalny Windows 11 a zdalny Windows Server
Na tym etapie połączenie RDP jest aktywne i pracujesz na zdalnej maszynie wirtualnej Windows Server, a nie na lokalnym systemie Windows 11.
Chociaż klient RDP został uruchomiony lokalnie, a jako cel połączenia podano localhost:8888,
adres ten reprezentuje jedynie lokalny koniec tunelu SSH.
Sesja Windows działa w całości na zdalnym serwerze Windows Server, a całe uwierzytelnianie i zachowanie systemu są obsługiwane po stronie serwera.
Panel Server Manager potwierdza ten stan. Server Manager jest dostępny wyłącznie w edycjach Windows Server i wskazuje, że wszystkie dalsze działania dotyczą wyłącznie zdalnego serwera. Lokalny system Windows służy jedynie do utrzymania tunelu SSH i wyświetlania pulpitu zdalnego.
Liczba możliwych jednoczesnych połączeń RDP
Systemy Windows (w tym Windows Server 2019 używany w tym artykule, a także Windows 10 i Windows 11) domyślnie pozwalają na jedną interaktywną sesję RDP na konto użytkownika w danym momencie.
Jeśli zostanie nawiązane drugie połączenie RDP przy użyciu tego samego użytkownika, gdy istniejąca sesja jest nadal aktywna, system Windows automatycznie rozłączy poprzednią sesję i wyświetli komunikat w stylu:
„Zostałeś rozłączony, ponieważ nawiązano inne połączenie z komputerem zdalnym.”
Takie zachowanie jest oczekiwane i nie ma związku z przekierowaniem portów SSH ani bastion hostem Linux.
Jeśli po nawiązaniu połączenia zostaniesz niespodziewanie rozłączony, sprawdź, czy inny klient RDP nie jest już połączony z tą samą maszyną Windows przy użyciu tego samego konta użytkownika.
Korzystanie z jednego bastion hosta do dostępu do wielu maszyn Windows
Jeden linuxowy bastion host może być używany do jednoczesnego dostępu do wielu maszyn wirtualnych Windows, o ile wszystkie maszyny Windows są podłączone do tej samej sieci prywatnej i są osiągalne z poziomu bastion hosta.
Każda maszyna Windows nasłuchuje wewnętrznie na standardowym porcie RDP (3389). Na lokalnym systemie Windows tworzone są oddzielne przekierowania portów SSH, z których każde używa innego portu lokalnego i wskazuje na inną maszynę Windows.
Na przykład:
localhost:8888→192.168.168.104:3389(Maszyna Windows 1)
localhost:8889→192.168.168.105:3389(Maszyna Windows 2)
Przekierowania portów mogą być skonfigurowane jako oddzielne zapisane sesje PuTTY
lub jako wiele wpisów tuneli w jednej sesji PuTTY.
Każde połączenie RDP jest następnie inicjowane niezależnie przy użyciu mstsc i odpowiedniego portu lokalnego.
Takie podejście umożliwia ponowne wykorzystanie jednego bastion hosta i jednego adresu floating IP do bezpiecznego dostępu do wielu systemów Windows równolegle, przy jednoczesnym zachowaniu braku publicznych adresów IP dla maszyn Windows i spójnego modelu bezpieczeństwa w obrębie projektu. W PuTTY każdy przekierowany port jest definiowany w sekcji Connection > SSH > Tunnels, z użyciem unikalnego lokalnego portu źródłowego.
Bezpieczny dostęp do maszyn Windows w sieciach prywatnych
Po wykonaniu opisanej procedury skonfigurowałeś dostęp RDP do maszyny Windows bez wystawiania usługi RDP do sieci publicznej. Maszyna Windows pozostaje dostępna wyłącznie w sieci prywatnej, a cały dostęp zewnętrzny jest kierowany przez linuxowy bastion host za pomocą tunelu SSH.
Model ten jest powszechnie stosowany na platformach NSIS Cloud, gdzie maszyny Windows są częścią prywatnych sieci projektowych i bezpośredni dostęp do usług administracyjnych jest ograniczony. Typowe scenariusze obejmują aplikacje Windows korzystające z EODATA, object storage lub innych usług wewnętrznych dostępnych wyłącznie w sieci projektowej.
Bastion host pełni rolę pojedynczego punktu wejścia dla dostępu administracyjnego. Dodatkowe maszyny Windows mogą być obsługiwane przy użyciu tego samego bastion hosta poprzez skonfigurowanie osobnych przekierowań portów SSH, co umożliwia zarządzanie wieloma prywatnymi systemami Windows bez przypisywania publicznych adresów IP do każdej z nich.
W takim układzie linuxowy bastion host zapewnia kontrolowany dostęp sieciowy, podczas gdy maszyny Windows pozostają odizolowane w prywatnej sieci projektu.