Bardzo wygodnym sposobem zarządzania maszyną wirtualną oprócz połączenia pulpitu zdalnego jest Powershell. Świeżo utworzone maszyny wirtualne za pomocą obrazów dostarczonych przez Microsoft w Azure nie są przygotowane do tego typu zdalnej administracji. A my chcemy żeby były, więc w dzisiejszym wpisie będzie trochę kodowania a dokładnie – skryptowania 🙂
Maszyna wirtualna utworzona z wykorzystaniem grup zasobów
Zauważyłem, że tworząc maszynę z wykorzystaniem grup zasobów (Resource Groups) nie mogłem się z nią połączyć przez Powershell od razu po jej utworzeniu – komunikat wskazywał że nazwa jest w ogóle nie rozpoznawalna, tak jakby w ogóle nie można było się do niej dobić. Z wykorzystaniem Powershell można się połączyć ze zdalnym komputerem w dwojaki sposób:
- po nieszyfrowanym połączeniu za pomocą protokołu HTTP na porcie 5985
- przez HTTPS na 5986
Oczywiście porty te muszą być otwarte po stronie maszyny wirtualnej w Azure, w przeciwnym razie Powershell nie będzie mógł się do niej połączyć. Domyślnie maszynka będąca w grupie zasobów ma otwarty tylko port do połączeń pulpitu zdalnego (RDP). Nic więc dziwnego, że Powershell nie może się skomunikować – blokuje go Azure’owy firewall.
Skupię się na połączeniu szyfrowanym czyli po protokole HTTPS. Zgodnie z tym co napisałem powyżej aby podłączyć się Powershell’em wykorzystując szyfrowanie SSL zarówno serwer jak i Azure musi mieć otwarty port 5986. Jeśli jeszcze nie wiesz jak otworzyć port dla maszyny w Azure będącej w grupie zasobów zapraszam do mojego wcześniejszego wpisu na ten temat. W każdym razie u mnie konfiguracja endpoint’a wygląda następująco:
Celem debugowania możemy w ten sam sposób otworzyć port 5985 czyli port wykorzystywany przez Powershell przy połączeniach nieszyfrowanych.
Zanim przejdziemy dalej nadam jeszcze jakąś przyjazną nazwę DNS dla mojej maszyny. W tym celu wchodzę w panelu sterowania Azure w ustawienia maszyny wirtualnej i klikam publiczny adres IP. Nowo utworzona maszyna wirtualna znajdująca się w grupie zasobów powinna mieć przydzielony tylko publiczny adres IP stąd etykieta <none> dla jej nazwy DNS.
Następnie wybieram Configuration i wpisuję nazwę DNS. Moja maszyna znajduje się w centrum danych w Zachodniej Europie dlatego DNS jest w formacie <nazwa>.westeurope.cloudapp.azure.com. Dla maszyn w innych centrach danych adres DNS będzie się różnić. Ustawiam DNS fsvm-rg.westeurope.cloudapp.azure.com
Spróbujmy połączyć się Powershell’em do maszyny wirtualnej:
1 |
Enter-PSSession -ComputerName fsvm-rg.westeurope.cloudapp.azure.com -Port 5986 -Credential tuczap -UseSSL |
Niestety komunikat:
1 |
Enter-PSSession : Connecting to remote server fsvm-rg.westeurope.cloudapp.azure.com failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits access to remote computers within the same local subnet. |
Mimo że odblokowałem port w Azure Powershell nadal w ogóle nie może się dobić do mojej maszyny wirtualnej 🙁 Rzeczy do sprawdzenia jakie przychodzą mi do głowy:
- Firewall na komputerze z którego nawiązuję połączenie (u mnie jest wyłączony ale Ty Drogi Czytelniku muszisz o nim pamiętać 🙂 )
- Firewall na maszynie docelowej
- Sprawdzić czy WinRM jest włączony na maszynie docelowej
- Po sprawdzeniu powyższego punktu sprawdzić czy WinRM nasłuchuje na porcie 5986 (ponieważ chcemy wykorzystać SSL)
No to jedziemy po kolei.
Firewall na maszynie docelowej
Łączymy się zdalnym pulpitem, Control Panel – Windows Firewall i teraz mamy dwie możliwości:
- wyłączyć Firewall całkowicie
- ustawić regułę pozwalającą na ruch po porcie 5986
Całkowite wyłączenie firewall’a to pójście na łatwiznę 🙂 więc spróbujmy ustawić regułę zezwalającą na ruch po porcie 5986. W linii komend wpisujemy:
1 |
netsh advfirewall firewall add rule name="WinRM-HTTPS" dir=in localport=5986 protocol=TCP action=allow |
W ramach troubleshooting’u możemy również odblokować ruch na porcie 5985 (czyli port wykorzystywany przez Powershell gdy nie stosujemy szyfrowanego połączenia). Ma to sens jeśli wcześniej w panelu sterowania Azure otworzyliśmy ten port dla maszyny wirtualnej. Port odblokowuje się podobnie jak 5986:
1 netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow
Włączenie WinRM na maszynie docelowej
W systemie Windows Server 2012R2 WinRM powinien być domyślnie włączony i skonfigurowany. Jednak nie zaszkodzi (a na wcześniejszych wersjach Windows Server nawet trzeba) włączyć go na serwerze którym mamy zamiar sterować. W tym celu uruchamiamy konsolę Powershell na maszynie docelowej i wpisujemy
1 |
Enable-PSRemoting |
ewentualnie w linii komend
1 |
winrm quickconfig |
na wszystkie pytania zadane w trakcie wykonywania się komendy odpowiadamy twierdząco i na koniec powinniśmy mieć działającą usługę WinRM.
Do sprawdzenia czy połączenie zdalne jest już możliwe służy komenda Test-WSMan:
1 |
Test-WSMan -ComputerName fsvm-rg.westeurope.cloudapp.azure.com -UseSSL |
Niestety nadal ten sam komunikat jaki dostaliśmy przy okazji próby połączenia się komendą Enter-PSSession.
1 |
WinRM cannot complete the operation. Verify that the specified computer name... |
Teraz połączenie się Powershell’em do zdalnej maszyny w Azure z wykorzystaniem SSL jeszcze nie zadziała, ale jeśli wcześniej otworzyłeś port 5985 to powinno się już udać przetestować połączenie Powershell po HTTP:
1234567 Test-WSMan -ComputerName fsvm-rg.westeurope.cloudapp.azure.comwsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsdProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsdProductVendor : Microsoft CorporationProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.0
Konfiguracja WinRM do pracy z protokołem HTTPS
Dzieje się tak, ponieważ domyślnie WinRM jest skonfigurowany do pracy tylko i wyłącznie z portem 5985. Możemy to sprawdzić wpisując w linii komend na serwerze docelowym:
1 |
winrm e winrm/config/listener |
W odpowiedzi powinniśmy dostać coś w stylu:
1 2 3 4 5 6 7 8 9 10 |
Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 10.2.0.4, 127.0.0.1, ::1, 2001:0:5ef5:79fd:1c2d:1264:d78c:e15d, fe80::5efe:10.2.0.4%22, fe80::1c2d:1264:d78c:e15d%23, fe80::90f6:80c3:14dc:60f 8%12 |
Jak widać brakuje listener’a dla portu 5986. Musimy dodać go ręcznie, ale wpierw aby miało to sens trzeba utworzyć nasz własny podpisany certyfikat. Przechodzimy do konsoli Powershell na maszynie docelowej i tam wpisujemy
1 |
$cert = New-SelfSignedCertificate -DnsName fsvm-rg.westeurope.cloudapp.azure.com -CertStoreLocation cert:\LocalMachine\My |
Teraz należy skonfigurować WinRM do połączeń HTTPS:
1 |
winrm create winrm/config/Listener?Address=*+Transport=HTTPS "@{Hostname=`"fsvm-rg.westeurope.cloudapp.azure.com`";CertificateThumbprint=`"$($cert.ThumbPrint)`"}" |
Jesli teraz sprawdzimy listener’y skonfigurowane dla WinRM to powinniśmy oprócz HTTP zobaczyc również HTTPS
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
winrm e winrm/config/listener Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 10.2.0.4, 127.0.0.1, ::1, 2001:0:5ef5:79fd:1c2d:1264:d78c:e15d , fe80::5efe:10.2.0.4%22, fe80::1c2d:1264:d78c:e15d%23, fe80::90f6:80c3:14dc:60f 8%12 Listener Address = * Transport = HTTPS Port = 5986 Hostname = fsvm-rg.westeurope.cloudapp.azure.com Enabled = true URLPrefix = wsman CertificateThumbprint = 3FE81A514FC090F184B8DADB7D95B5E5F12164D5 ListeningOn = 10.2.0.4, 127.0.0.1, ::1, 2001:0:5ef5:79fd:1c2d:1264:d78c:e15d , fe80::5efe:10.2.0.4%22, fe80::1c2d:1264:d78c:e15d%23, fe80::90f6:80c3:14dc:60f 8%12 |
Uffff… Wygląda na to że wszystko już jest w porządku i nic nie powinno stać na przeszkodzie do zdalnego zarządzania maszyną wirtualną – oprócz dodania certyfikatu do zaufanych dostawców na maszynie z której będziemy nawiązywać połączenia 🙂
1 |
Enter-PSSession -ComputerName fsvm-rg.westeurope.cloudapp.azure.com -Credential tuczap -UseSSL |
1 2 3 |
Enter-PSSession : Connecting to remote server fsvm-rg.westeurope.cloudapp.azure.com failed with the following error mes sage : The server certificate on the destination computer (fsvm-rg.westeurope.cloudapp.azure.com:5986) has the following errors: The SSL certificate is signed by an unknown certificate authority. |
Przejdź do poniższego opisu ustawienia Powershell’a do łączenia się z klasyczną maszyną wirtualną aby dodać wymagany certyfikat i zostać prawdziwym chmurowym adminem 😉
Klasyczna maszyna wirtualna
Maszynka utworzona w sposób klasyczny domyślnie ma już skonfigurowany endpoint do łączenia się przez Powershell HTTPS (wykorzystujący certyfikat SSL). Można to potwierdzić wchodząc w jej ustawienia w portalu Azure’a i wybierając Endpoints. Powinny być odblokowane co namjmniej dwa porty: 3389 oraz 5986. Ten drugi odpowiada właśnie za Powershell po HTTPS.
Skoro port jest otwarty to nic nie stoi na przeszkodzie aby spróbować połączyć się konsolą Powershell aby móc zarządzać maszyną.
1 |
Enter-PSSession -ComputerName <nazwa_hosta> -Port 5986 -Credential <username> -UseSSL |
Username to oczywiście login użytkownika, podany przy tworzeniu maszyny wirtualnej. Po wpisaniu powyższej komendy trzeba będzie jeszcze podać hasło tegoż użytkownika. Jeśli dostałeś komunikat o błędzie certyfikatu SSL to się nie przejmuj – tak powinno być 🙂
1 2 3 |
Enter-PSSession : Connecting to remote server fsvm2.cloudapp.net failed with the following error message : The server certificate on the destination computer (40.114.246.12:5986) has the following errors: The SSL certificate is signed by an unknown certificate authority. The SSL certificate contains a common name (CN) that does not match the hostname. For more information, see the about_Remote_Troubleshooting Help topic. |
Oznacza to nie mniej nie więcej, że certyfikat pochodzi z niezaufanego źródła i Powershell odmawia połączenia. Aby dodać certyfikat można wykorzystać przeglądarkę Chrome. Jako adres podaj https://PEŁNA_NAZWA_DNS:5986. Chrome również poinformuje że połączenie jest niezaufane 🙂 Należy kliknąć ikonkę kłódki po lewej stronie od paska adresu i wybrać Certificate information.
W okienku, które się otworzy przejdź do zakładki Details i kliknij Copy to file…
W kreatorze importu certyfikatu kliknij Next, upewnij się że DER encoded binary X.509 (.CER) jest zaznaczony i ponownie kliknij Next.
Wybierz ścieżkę zapisu, potwierdź Next i w ostatnim oknie kliknij Finish.
Teraz przejdź do lokalizacji gdzie zapisałeś certyfikat, kliknij na nim prawym przyciskiem myszy i wybierz Install Certificate.
Otworzy się kreator importu certyfikatu – wybierz Place all certificates in the following store, wybierz Browse i zaznacz Trusted Root Certification Authorities. Kliknij Next i potem Finish.
Pojawi się okno z ostrzeżeniem. Kliknij Yes.
Możemy jeszcze przetestować możliwość zarządzania maszyną zdalną
1 2 3 4 5 6 7 |
Test-WSMan -ComputerName fsvm2.cloudapp.net -UseSSL wsmid : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd ProductVendor : Microsoft Corporation ProductVersion : OS: 0.0.0 SP: 0.0 Stack: 3.0 |
Spróbuj teraz podłączyć się Powershell’em do maszyny.
Gratulacje! Teraz możesz przez Powershell zarządzać maszyną wirtualną w Azure 🙂