Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Zdalne uruchomienie i zarządzanie swoim komputerem przez Internet

Telepraca jest w dzisiejszych czasach bardzo popularna. Coraz częściej firmy decydują się właśnie na taką formę zatrudnienia, gdyż jest to po prostu tańsze. Dla pracownika jest to oszczędność czasu i pieniędzy (które np.: trzeba byłoby wydać na dojazdy). Zajęcie może być wykonywane w dowolnym miejscu i momencie. Pracodawca natomiast nie musi wydawać pieniędzy na zorganizowanie stanowiska pracy. Unika także możliwego konfliktu między zatrudnionymi, jeśli musieliby oni pracować w jednym biurze.

Możliwość zdalnej pracy na komputerze przydaje się nie tylko firmom. Czasami taka sposobność potrzebna jest także zwykłemu użytkownikowi. Niekiedy, będąc poza domem, przydaje się nie tylko dostęp do plików, które mamy na lokalnym komputerze, ale także do aplikacji. Sam niekiedy, będąc w szkole żałowałem, że nie skonfigurowałem poprawnie tej usługi. Często brak dostępu do mojej maszyny po prostu utrudniał moje zajęcia. Warto wiedzieć o takiej możliwości tym bardziej, że konfiguracja nie jest bardzo skomplikowana. Oczywiście są pewne warunki, które musimy spełnić, aby przedstawiony w dalszej części artykułu sposób zadziałał. Przede wszystkim, musimy posiadać adres publiczny oraz niezablokowane przez operatora porty 22 i 3389. Natomiast komputer, którym będziemy chcieli zarządzać przez Internet powinien wspierać funkcję WoL (Wake on LAN).

Umożliwienie zdalnego dostępu do już włączonego komputera jest bardzo prostą sprawą. TeamViewer jest jedną z aplikacji, która nie wymaga żadnej konfiguracji do prawidłowego działania. My pójdziemy dłuższą, ale bezpieczniejszą ścieżką. Skonfigurujemy domyślny serwer usług pulpitu zdalnego dostępny w systemie Windows (RDP). Dla porównania pokażę także alternatywne rozwiązanie w postaci różnej maści programów wspierających protokół VNC. Dlaczego wolę używać RDP i VNC zamiast TeamViewer? Ponieważ żadna część ruchu nie przechodzi wtedy przez serwery firm trzecich. Nie oskarżam firmy rozwijającej TeamViewer ani podobne oprogramowanie o jakieś niecne zamiary, ale w dobie powszechnej inwigilacji wolę ryzyko podsłuchu ograniczyć do minimum.

r   e   k   l   a   m   a

Zastanawiasz się pewnie, dlaczego polecam protokół RDP kiedy istnieje tyle alternatyw? Przede wszystkim, produkt Microsoftu jest o wiele mocniej zintegrowany z systemem niż większość innych, darmowych serwerów i klientów usług pulpitu zdalnego.Do logowania można używać tych samych kont, które istnieją w systemie. RDP potrafi stworzyć oddzielną sesję. Dzięki temu użytkownik patrzący na monitor podłączony do komputera, z którym się łączymy nie będzie widział wykonywanych przez nas czynności. Posiada także większą ilość możliwości dostosowania przesyłanej jakości obrazu do prędkości łącza. Ostatnią, najważniejszą dla mnie zaletą jest szyfrowanie połączenia. RealVNC i podobne programy w wersji bezpłatnej szyfrują jedynie etap uwierzytelniania. Dalsza część transmisji jest już przesyłana w formie jawnej. W dobie dzisiejszych cyfrowych zagrożeń nie jest to zbyt ciekawa perspektywa. Niestety, nie ma róży bez kolców. O ile w systemie operacyjnym Windows konfiguracja zarówno VNC jak i RDP jest bardzo prosta, o tyle sytuacja komplikuje się w Linuksie. W systemach z logo pingwina na pokładzie jedynie VNC jest dość proste do skonfigurowania. Natomiast z protokołem RDP związanych jest kilka komplikacji.

Jeśli komputer docelowy jest włączony, nie istnieją praktycznie żadne problemy uniemożliwiające nam dostęp. Gorzej (a tak zwykle jest) gdy nasza maszyna jest wyłączona. Wtedy musimy użyć technologii WoL. W tym momencie pojawia się pewna komplikacja, gdyż pakietów WoL zwykle nie możemy wysłać przez Internet. Sposobu przedstawionego poniżej nie musisz stosować jedynie wtedy, kiedy twój router pozwoli na przekierowanie „magicznego pakietu” na adres broadcast. W przeciwnym wypadku musimy dodatkowo posiadać w sieci lokalnej jakieś stale działające urządzenie, do którego możemy zalogować się np.: poprzez SSH. Może to być zrootowany telefon, odpowiedni router czy nawet poczciwa malinka (Raspberry pi).

Zasadę działania omawianego w tym artykule pomysłu dobitnie przedstawia poniższy schemat:

Zaczynamy od budzenia – teoria

Gdy komputer jest wyłączony, nie wszystkie komponenty są pozbawione prądu. Jednym z takich, które cały czas wykonują jakąś pracę jest karta sieciowa. Na kompatybilnych z funkcją WoL (Wake on LAN) komputerach karta sieciowa cały czas nasłuchuje odpowiedniego komunikatu, nazywanego „,magicznym pakietem”. Gdy taki ciąg znaków zostanie odebrany, karta sieciowa uruchamia normalnie komputer.

W większości przypadków WoL jest domyślnie wyłączony. Dlaczego? Po pierwsze, może spowodować to naruszenie bezpieczeństwa sieci. Natomiast, jeśli chodzi o urządzenia mobilne, cały czas pracująca karta sieciowa może mocno skrócić czas pracy na baterii. Wobec tego warto włączyć tę funkcję tylko wtedy, kiedy naprawdę jest nam potrzebna.

Omawiana opcja różnie się nazywa. Najczęściej jest to Power on By PCI/PCIE Device. Abyśmy mogli uruchomić komputer przez sieć lokalną, musimy zmienić stan tego parametru z Disabled na Enabled. Od tego momentu nasza karta sieciowa będzie nasłuchiwała odpowiedniego sygnału.

Magiczny pakiet – jak on działa?

Powszechna nazwa pakietów WoL pochodzi z ich specyficznej budowy. Jest to zwykła ramka sieci Ethernet. Magiczne pakiety są przesyłane w warstwie drugiej modelu OSI (jeśli chcesz poznać szczegóły, odsyłam do kursu Packet Tracera ). Uniezależnia je to od adresu IP, którego przecież wyłączony komputer nie posiada.

Typowy pakiet (a właściwie ramka) WoL jest bardzo prosty i niewielki. Składa się ze 102 bajtów oraz zasadniczo z dwóch części. Pierwszy fragment zawiera sześć bitów wypełnionych samymi jedynkami binarnymi. Natomiast drugi to szesnastokrotnie powtórzony adres MAC komputera, który chcemy obudzić. Ramka taka wysyłana jest na adres rozgłoszeniowy sieci lokalnej. Trafia więc do wszystkich komputerów w danej sieci. Urządzenia, których pakiet nie dotyczy, ignorują go. Natomiast docelowy komputer, którego adres MAC zgadza się z tym zawartym w pakiecie rozpoczyna procedurę rozruchu.

Tym samym wyjaśniliśmy też, dlaczego nie możemy uruchomić komputera przez Internet, wysyłając pakiet WoL. Co prawda, ramka może zostać opakowana w prawidłowy pakiet protokołu UDP. Będzie poprawnie routowana, docierając do naszej sieci lokalnej. Jednakże, co potem? Sporo routerów (ze względów bezpieczeństwa) zablokuje wysłanie pakietu z sieci rozległej na adres rozgłoszeniowy sieci lokalnej. W najtańszych konstrukcjach najczęściej nie będziemy mogli przekierować ruchu na adres rozgłoszeniowy. Pakiet zostanie więc odrzucony przez nasz router.

Konfigurujemy router

Jeśli nasz router nie pozwala na przekierowanie pakietów na adres broadcast, musimy mieć w sieci lokalnej urządzenie działające bez przerwy. Powinna istnieć możliwość połączenia się z nim w każdym momencie. Można do tego celu użyć np.: Raspberry PI czy zrootowany telefon z wgranym busyboxem i serwerem SSH. Na tym urządzeniu powinniśmy skonfigurować stały adres IP. Jest to niezbędne, abyśmy nie mieli problemów z odpowiednim przekierowaniem portów. Dalsza część konfiguracji jest banalnie prosta. Musimy zainstalować program potrafiący wysyłać magiczne pakiety. Istnieje wiele tego typu aplikacji. Jednymi z najpopularniejszych jest wakeonlan. W przypadku Androida i BusyBoxa (na zrotowanym telefonie) mamy dostępną aplikację EtherWake. Jako argumenty najczęściej podaje się jedynie adres MAC komputera docelowego. Ewentualnie może być wymagany także numer portu UDP (aczkolwiek ta cyfra nie będzie miała większego znaczenia).

Abyśmy mogli połączyć się z naszym „oknem” na sieć lokalną musimy odpowiednio przekierować porty. Pojęcie to pojawiało się już wcześniej, lecz co ono oznacza? W domowej sieci najczęściej posiadamy jeden adres publiczny. Pod tym adresem są widoczne wszystkie komputery naszej sieci lokalnej. Router, za pomocą technologii NAT odpowiednio „tłumaczy” ruch z i do sieci. Zastanówmy się, co by było jeśli z poziomu Internetu będziemy chcieli połączyć się z serwerem SSH znajdującym się w naszej sieci lokalnej? Jako adres serwera będziemy musieli podać nasz adres publiczny. Jednakże, skąd router ma wiedzieć, o który komputer naszej sieci nam chodzi? Musimy mu to wytłumaczyć, konfigurując odpowiednio przekierowania portów.

Przykładową regułę widzimy na rysunku powyżej. Oznacza ona, żeby dowolny ruch przychodzący na port 22 adresu publicznego sieci kierować na taki sam port lokalnego urządzenia o adresie IP 192.168.1.200. Port 22, odpowiadający za usługę SSH powinniśmy przekierować na nasze stale działające urządzenie, takie jak Raspberry Pi czy zrootowany smartfon. Podobną regułę powinniśmy skonfigurować dla portów 3389 (RDP) oraz 5900 oraz 5800 (VNC). Lecz w tym wypadku ruch powinien być przekierowany już na właściwy komputer, z którym będziemy się łączyć Dzięki temu router będzie wiedział, gdzie kierować pakiety, które będzie otrzymywał na adres publiczny naszej sieci.

Jednakże, co zrobić, jeśli chcemy mieć dostęp do kilku komputerów z naszej sieci lokalnej? Nie możemy przekierować ruchu z portu np.: 3389 jednocześnie na dwa komputery. W takim wypadku, na drugim z komputerów musimy po prostu ustalić inny zakres portów. W przypadku VNC zmiana tego typu rzeczy jest dość prosta, gdyż możemy ją wykonać z poziomu GUI. Natomiast RDP rzuca nam w tym momencie kłody pod nogi. Możemy to zrobić jedynie przez edycję rejestru. Należy przejść do klucza

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

.
Następnie powinniśmy znaleźć zmienną DWORD o nazwie PortNumber i zmienić jej zawartość. Potem powinniśmy przekierować ruch z nowych portów na drugą maszynę w sieci lokalnej.

W przypadku, gdybyśmy chcieli skonfigurować dostęp do komputera trzeciego, czwartego itd. to zasady postępowania są takie same jak powyżej. Wystarczy za każdym razem zmieniać numer portu i przekierowywać ruch na kolejne adresy IP.

Konfiguracja no-ip

Zakładam, że jesteś użytkownikiem zwykłego Internetu domowego, takiego jak np.: Neostrada. W takim wypadku posiadasz publiczny, dynamiczny adres IP. Znaczenie słowa publiczny już wyjaśniliśmy. Co natomiast oznacza, że adres jest dynamiczny? Oznacza to, że adres IP nie jest na stałe przypisany do nas. Może się zmieniać. Np.: dzisiejszego dnia nam operator przypisał ciąg cyferek 30.40.50.60 a następnego dnia te liczby mogą należeć do naszego sąsiada. Utrudnia to połączenie się z naszą siecią lokalną, gdyż nie możemy przewidzieć, jaki akurat adres otrzymamy od operatora.

Istnieje bardzo proste rozwiązanie tego problemu. Wystarczy skonfigurować darmową domenę na www.noip.com. Następnie powinniśmy poinformować router (większość urządzeń, nawet tanich, posiada taką opcję) że korzystamy z takiego a takiego dostawcy dynamicznych domen oraz logujemy się za pomocą takiego a takiego loginu i hasła. Istnieje wielu dostawców tego typu usług. Ja, ze swojej autopsji polecam www.noip.com ze względu na brak problemów, darmową rejestrację oraz bardzo łatwą, darmową konfigurację do 5 hostów.

Po zarejestrowaniu nowej domeny na noip.com wystarczy już tylko wprowadzić właściwe ustawienia do routera. Opcja związana z omawianą opcją najczęściej nazywa się Dynamic DNS lub DDNS.

Konfigurujemy RDP w Windows

RDP – Remote Desktop Services –usługa obecna w systemach Windows od roku 1998. Początkowo klient wydawany był jako dodatek do systemu, a potem już nieodłącznie towarzyszył kolejnym wydaniom systemu firmy z Redmond. Domyślnie dostęp zdalny do komputera jest wyłączony. Zezwolenie na logowanie zdalne jest bajecznie proste. Wystarczy wejść do Panelu Sterowania (tradycyjnego, oldschoolowego). Wybieramy grupę opcji „System i zabezpieczenia”. Kolejnym krokiem jest „System”. Klikamy „Zmień” i przechodzimy na zakładkę „Zdalny”. Następnie Zezwalamy na połączenia zdalne z tym komputerem i wybieramy użytkowników, którzy będą mogli się zdalnie zalogować.

Warto wspomnieć o tym, że nasze konto, którego zamierzamy używać do zdalnego logowania powinno mieć ustawione jakieś hasło. Domyśłnie Windows nie zezwala na logowanie się użytkownikom zdalnym, których konta nie mają haseł.

Konfiguracja RealVNC w Windows

Konfiguracja RDP jest prosta, ale VNC w porównaniu z tym jest jeszcze banalniejsze. Instalator pobrany z oficjalnej strony projektu prowadzi nas przez standardowe procedury. Po zainstalowaniu oprogramowania musimy otworzyć konfigurator serwera VNC. Uruchomiony zostanie kreator pozwalający nam uzyskać klucz produktu. Jeśli wcześniej nie posiadaliśmy tego programu, powinniśmy wybrać opcję pierwszą – „Visit our Web to obtain a license key”. Po darmowej rejestracji uzyskamy klucz produktu, który należy wprowadzić na następnym ekranie. Następnie musimy zaznaczyć opcję „Unencrypted connections are acceptable”, gdyż wersja darmowa nie pozwala na szyfrowanie. Potem wprowadzamy hasło, którego będziemy używali do logowania się na tym komputerze. Na tym kroku konfiguracja jest zakończona. Program wita nas i informuje, że jest gotowy na przyjmowanie połączeń.

Testujemy rozwiązanie w praktyce

Podstawowa konfiguracja została wykonana. Zastanówmy się teraz, jak będzie wyglądała procedura uruchomienia zdalnego komputera, a następnie połączenia się z nim przez pulpit zdalny.

Na samym początku za pomocą protokołu SSH (jeśli na maszynie, z poziomu której się łączymy mamy zainstalowany system Windows, możemy użyć programu Putty) łączymy się z naszym „stale działającym” urządzeniem. Jako nazwę hosta podajemy domenę no-ip, którą wcześniej konfigurowaliśmy. Wydajemy polecenie Etherwake, albo wakeonlan gdzie jako argument podajemy adres MAC komputera, który będziemy chcieli uruchomić. Za pomocą polecenia ping możemy sprawdzić, czy stacja robocza już się uruchomiła. Kiedy zaczniemy dostawać odpowiedzi z naszego docelowego komputera, możemy podjąć próbę połączenia się z nim. Uruchamiany podłączanie pulpitu zdalnego. Jako nazwę hosta podajemy nazwę naszej domeny no-ip. Jeśli wszystko poprawnie skonfigurowaliśmy, zostaniemy poproszeni o nazwę użytkownika i hasło do docelowego komputera. Po poprawnym uwierzytelnieniu będziemy mogli rozpocząć pracę.

Dodatkowe możliwości konfiguracji, o których warto wiedzieć

Gdy zakończymy pracę ze zdalnym komputerem i będziemy chcieli go wyłączyć, możemy spotkać nas niemiłe zaskoczenie. Domyślnie, nie będziemy mieli możliwości łatwego wyłączenia zdalnej maszyny przez menu start. Opcję wyłączania, ponownego uruchomienia komputera zastępuje przycisk „Rozłącz”. Istnieje kilka rozwiązań tego problemu.
Możemy użyć linii poleceń do wyłączenia maszyny. Polecenie shutdown z odpowiednimi przełącznikami w większości przypadków rozwiązuje problem. Jeśli boimy się linii poleceń, możemy wywołać okienko „Uruchom” (skrót klawiszowy: Win+R). W polu edycyjnym wprowadzamy shutdown –i i naciskamy Enter. Zostanie wtedy wyświetlony przyjazny graficzny interfejs użytkownika, który pozwoli nam wybrać sposób i przyczynę wyłączenia stacji roboczej.

Innym sposobem jest kliknięcie Start->Windows Security. Wyświetlony zostanie ekran podobny do tego, jaki uzyskujemy po naciśnięciu klawiszy CTRL+ALT+DEL. W tym miejscu również będzie dostępna opcja wyłączenia komputera.

Jeśli chcesz umożliwić użytkownikom bez haseł zdalne logowanie, możesz to uczynić za pomocą Zasad Grupy (gpedit.msc). Aczkolwiek nie polecam tego rozwiązania, gdyż istotnie zmniejsza ono bezpieczeństwo naszej sieci.

Konfiguracja pulpitu zdalnego w Linuksie (Ubuntu 16.04)

W przypadku Linuksa, podobnie jak Windowsa, mamy dwie drogi. Możemy korzystać z protokołu VNC lub RDP. Zdecydowanie prostsza jest ta pierwsza opcja. W repozytorium mamy do wyboru bardzo dużą ilość programów udostępniających potrzebne nam możliwości. My, podobnie jak w przypadku Windowsa, zastosujemy RealVNC. Konfiguracja i instalacja tego oprogramowania jest banalnie prosta. Najpierw pobieramy ze strony RealVNC wersję przeznaczoną dla naszej dystrybucji. Pliki instalacyjne (.deb, .rpm) są spakowane w archiwum tar.gz. W przypadku Ubuntu, wbrew pozorom, lepiej użyć terminala i polecenia dpkg –i nazwa_pakietu.deb. Ubuntu Software czasami sprawia różne, dziwne problemy w przypadku instalacji paczek spoza repozytorium. Po ponownym uruchomieniu komputera uruchamiamy program służący do konfiguracji serwera VNC. Podobnie, jak na Windowsie, musimy wprowadzić klucz licencyjny. Interfejs wygląda identycznie tak samo, toteż nie będę się powtarzał.

Ostatnim krokiem, który musimy podjąć jest dodanie aplikacji VNC Server do autostartu. Jest to banalnie proste. Uruchamiamy Programy startowe. Klikamy przycisk Dodaj. Nazwę możemy wpisać, jaką chcemy. Natomiast, jako polecenie podajemy: vncserver-x11. Dzięki temu program automatycznie uruchomi się przy starcie systemu i będzie nasłuchiwał nadchodzących połączeń, dając nam możliwość połączenia się zdalnie w dowolnym momencie.

Drugą, trudniejszą opcją jest skonfigurowanie protokołu RDP. Najpierw musimy zainstalować program xrdp za pomocą polecenia:

sudo apt-get install xrdp

Następnie powinniśmy zainstalować inne, alternatywne w stosunku do Unity środowisko graficzne. Dlaczego? Otóż, Unity znajdujące się w Ubuntu po prostu nie współpracuje z serwerem xrdp i nic na to nie poradzimy. Możemy za to wybrać dowolne inne rozwijane środowisko (np.: MATE, KDE, GNOME, Xfce, LXDE). Zobaczmy, jak wygląda konfiguracja w przypadku wybrania MATE.

Najpierw instalujemy MATE poleceniem

sudo apt-get install mate-core mate-desktop-environment mate-notification-daemon

Następnie przeprowadzamy konfigurację xrdp. Pliki konfiguracyjne tej aplikacji znajdują się w lokalizacji /etc/xrdp. Spośród gamy wielu znajdujących się tam pozycji będzie nas interesowała jedynie jedna: startwm.sh. W pliku tym znajdują się informacje o tym, co i jak uruchomić, kiedy klient pomyślnie przejdzie proces uwierzytelniania. Kasujemy ostatnią linijkę. Na jej miejsce wstawiamy następujący ciąg znaków: /usr/bin/mate-session. Dzięki temu po pomyślnym zalogowaniu zostanie uruchomiony plik mate-session rozpoczynający sesję środowiska MATE.

Gdy spróbujemy się połączyć z naszym zdalnym komputerem przez opcję: Podłączanie pulpitu zdalnego, powita nas następujący ekran:

Jest to menedżer logowania xrdp. Aby operacja zakończyła się pomyślnie, nie musimy nic zmieniać. Wystarczy, że podamy nazwę użytkownika i hasło konta, którego używamy w naszym systemie.

DualBoot i bootloader

W rozważaniach powyżej przyjmowaliśmy, że mamy zainstalowany na komputerze jedynie jeden system operacyjny. Jednakże, co w przypadku, gdy na komputerze zainstalowany jest zarówno Ubuntu jak i Windows? Jak dobrze wiemy, GRUB nie pozwala na zdalne wybranie odpowiedniego systemu operacyjnego. Ale czy wtedy jesteśmy skazani na dostęp jedynie do domyślnego wyboru? Otóż nie. Najpopularniejszy obecnie bootloader, wśród wielu dostępnych poleceń i parametrów, posiada takie ciekawe polecenie jak: grub-reboot. Jako argument przyjmuje numer opcji, którą chcemy uruchomić po restarcie. Dzięki temu, możemy uruchomić dowolny inny zainstalowany na lokalnym komputerze system operacyjny. Przykład:

sudo grub-reboot 4

Po restarcie zostanie zaznaczona czwarta pozycja w menu. Przy standardowej instalacji zwykle odpowiada ona Windowsowi.

Podsumowanie

To już wszystko. Przedstawione powyżej procedury umożliwiają nam uruchomienie i bezpieczne, zdalne połączenie się z naszym komputerem z dowolnego miejsca na Ziemi. Procedurę można oczywiście ulepszać. Nic nie stoi na przeszkodzie, aby dodatkowo zabezpieczyć transmisję, używając VPN. Nie mniej, przedstawiony powyżej sposób (przyjmując, że użyjemy RDP) zapewnia użytkownikowi łatwą i stosunkowo bezpieczną komunikację ze swoją siecią domową.
 

porady

Komentarze