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.

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 xrdpNastę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 4Po 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

0 nowych
miggi   4 #1 05.05.2016 07:41

Przekierowanie RDP na zewnątrz to proszenie się o kłopoty. W tym wszystkim zabrakło podstawowej rzeczy jaką jest VPN. Obecnie różne routery umożliwiają stawiania serwerów np. OpenVPN z poziomu wewnętrznego oprogramowania (DD WRT, PF Sense i wiele, wiele innych).

Jac0b   6 #2 05.05.2016 07:52

Zgadzam się z przedmówcą. Taka konfiguracja na domyślnych portach to prawie jak zaproszenie. Konieczny jest VPN, mniej bezpieczna lecz możliwa maskarada portu na routerze lub zmiana domyślnego na inny.

  #3 05.05.2016 08:32

Netia złom

McDracullo   17 #4 05.05.2016 08:35

@KlejnotNilu: Hm, no nie wiem - jako prostu router do domu wydaje się być w porządku. Siedziałem na nim parę łądnych lat i jakoś nigdy nie mogłem na niego narzekać.
No VPN by się przydał i może jeszcze tutek jak remotnie logować się do powershella...

karol221-10   10 #5 05.05.2016 08:56

@Jac0b: Zgadzam się z tym, że VPN jest konieczny. Niestety Netia złom, ani inne routery które posiadam nie mają tej możliwości.

Virruil   5 #6 05.05.2016 10:02

@karol221-10:
"sudo grub-reboot 4"

Właśnie szukałem sposobu na uruchamianie systemu w konfiguracji dual boot. Dzięki! :)

Ale koledzy mają rację, przekierowanie tych portów na zewnątrz to słaby pomysł. Osobiście już wolałbym nie udostępniać lub zainstalować Team Viewer. Piszesz, że obawiasz się inwigilacji, a wystawiasz na zewnątrz usługi zdalnego dostępu (w tym nieszyfrowane VNC!)... Ewentualnie mopzna kupić chocby maline lub jakis tani ruter za 50 zł na któróm postawisz np. tomato lub inne DD-WRT z VPNem.

bachus   20 #7 05.05.2016 10:11

@Virruil: "Ale koledzy mają rację, przekierowanie tych portów na zewnątrz to słaby pomysł. Osobiście już wolałbym nie udostępniać lub zainstalować Team Viewer" - czyli obawiasz się otworzyć port (gdzie na firewall możesz ustawić filtrowanie po IP i dopuścić tylko część ruchu), ale za to sugerujesz swego rodzaju "trojana" którym jest TeamViewer, Logmein i podobne usługi z serwerami pośredniczącymi? Otwieranie portów nie jest niczym złym - oczywiście jak robi się to rozsądnie. Zasadniczo nie ma wielkiej różnicy, czy otwiera się port dla serwera WWW, SMTP, czy właśnie RDP - jak jest luka, to zostanie ona wykorzystana. Jak wspomniałem, tutaj podstawa to najlepiej dopuszczać tylko ruch z określonych IP, lub jak już ktoś pisał łączyć się przez VPN.

guma77   10 #8 05.05.2016 10:43

ja tam wole team veiwer

Virruil   5 #9 05.05.2016 10:45

@bachus: Masz rację, oczywiście przekierowywanie portów samo w sobie jest w porządku i równie dobrze można zapewnić sobie dostęp z zewnątrz na własną rękę. Może źle się wyraziłem, także uważam że nie jest dobrze udostępniać tych usług bez dodatkowej ochrony, dlatego też pisałem o VPN. Szczególnie, gdzie np. nieszyfrowana sesja VNC może być podsłuchana np. w sieci szkolnej lub firmowej. Zewnętrzna usługa w porównaniu z tak skonfigurowanym dostępem bez zabezpieczeń zapewni prawdopodobnie większe bezpieczeństwo. Chociaż w tym momencie wchodzimy w problem zaufania do stron trzecich i ich wiarygodności.

Autor edytował komentarz w dniu: 05.05.2016 10:52
linqa   3 #10 05.05.2016 10:46

Jeśli chodzi o Linuksa, to duuuuuuużo lepszym rozwiązaniem jest X2Go albo zwykły forwarding X-ów.

kranu   4 #11 05.05.2016 10:48

Obecnie większość komputerów to laptopy, na których dla wygody korzysta się z WiFi czy tam innego LTE, gdzie Wake On Lan zwykle nie zadziała.

bachus   20 #12 05.05.2016 10:54

@kranu: Intel ma takie rozwiązania, gdzie karta wifi (oraz odpowiedni chipset...) utrzymuje połączenie ze wskazanym AP i daje to możliwość WoL via Wifi. Nigdy nie testowałem, nigdy nie używałem - tylko o tym kiedyś czytałem w dokumentacji.

Nerus87   7 #13 05.05.2016 10:58

@Jac0b: zmiana protu niewiele da, skan portów z nagłówkami rozwieje wszelakie wątpliwości :)

mly   7 #14 05.05.2016 11:05

@guma77: Ja również :)

bachus   20 #15 05.05.2016 11:23

@mly @guma77: wadą TeamViewer jest poza tym, że pośredniczą serwery firm trzecich (jest instalowanym z własnej woli "trojanem"), to newralgiczny wektor ataku: hasło do TeamViewer, lub hasło do konta pocztowego powiązanego z TeamViewer. Plusem TeamViewer jest to, że praktycznie nie ma możliwości zdalnego podłączenia bez wiedzy użytkownika (pojawia się powiadomienie o podłączeniu, transferze plików itd.). Aplikacje typu Logmein, czy TeamViewer to jednak zbawienie, gdy nie ma czasu/jest zbyt upierdliwe konfigurowanie firewalla, NATa itd. Programy takie jednak powinny dawać do myślenia - jeżeli program instalowany w tak prosty sposób (np. komercyjny TeamViewer ma kreatory instalatora bezobsługowego) tak prosto otwiera sobie "tunel" do połączeń - na tej samej zasadzie może działać trojan/wirus.
W komercyjnych rozwiązaniach stosuje się raczej produkty typu BOMGAR - działa dość podobnie jak TeamViewer, jednak połączenia nie idą na zewnątrz. W firmie stawia się serwer (jest to najczęściej 'appliance' w postaci niedużej skrzynki) i do niego bezpośrednio idą połączenia szyfrowane.

guma77   10 #16 05.05.2016 12:18

@bachus: dokladnie , mi sie przydaje TV do zarzadzania laptopem na ktorym stoi stacja moja meteo :)
http://www.branicemteo.barcikowski.pl

NieGooglujMnie   6 #17 05.05.2016 12:54

Na linux-windows jest oczywiście jeszcze jeden program, który możliwościami równa się z TV , no to jest Google Chrome Remote Desktop

Korzystam - ale to wynika z lenistwa, prostoty, szybkości, bo z TV więcej roboty (prawdopodobnie są bardziej "power" rozwiązania od Chrome Remote Desktop, ale to się sprawdza i tyle)

wie ktoś jak zrobić, żeby nie pytał o połączenie po 10 minutach ? żeby cały czas łączył
tylko ten sposób jest:
http://www.howtogeek.com/142146/how-to-use-google-chrome-to-remotely-access-your.../

?


Co do topicu, to oczywiście na Linuxie mamy:
ssh + ssh i forwarding x11 (jak ktoś potrzebuje sobie poklikać)
sshfs +
spoko jest też thunar z gvfs (fuse)
+ sftp

Ja realnie w pracy ssh , sshfs oczywiście , sftp też w Eclipse , ale muszę sobie pokombinować z tym całym gvfs i thunarem, żeby się tak fajnie mount`owały pliki w file managerze przez d-bus
(paczka gvfs-backend :
https://packages.debian.org/sid/gvfs-backends
)

Autor edytował komentarz w dniu: 05.05.2016 13:08
marson1   13 #18 05.05.2016 13:04

tekst bardzo fajny, choć akurat dla mnie to nic nowego jednak warto byłoby dodać informację, że serwer pulpitu zdalnego (RDP) jest dostępny tylko w Windowsach w wersjach pro, ponadto gpedit.msc też jest dostępny tylko w wersjach pro... Ja obecnie mam inną zagadkę, chcę postawić serwer VNC, niestety nikt nie pamięta hasła do liveboxa i nie ma jak się tam dostać by przekierować porty. Masz jakiś pomysł na pószczenie ruchu VNC przez jakieś proxy, podobnie jak ma to miejsce w TeamViewer?

Autor edytował komentarz w dniu: 05.05.2016 13:06
  #19 05.05.2016 13:14
mrDark   7 #20 05.05.2016 14:01

@marson1: UltraVNC Single Click - i to serwer będzie łączył się z klientem pod wskazanym adresem.

karol221-10   10 #21 05.05.2016 14:08

@marson1: Ewentualnie możesz spróbować postępować wg rad zawartych tutaj:http://lightofdawn.org/wiki/wiki.cgi/-wiki/Nat2NatVNC Myślę, że to mogłoby rozwiązać problem.

  #22 05.05.2016 15:42

RDP? owszem, ale wyłącznie opakowany w VPN!
zdalna praca = VPN
bez VPN'u mniejszym złem jest chyba jednak TV
a zdalne włączanie wyłączonych stacji?
Intel vPRO+AMT i nie ma problemu!

karol221-10   10 #23 05.05.2016 17:12

@n0n3 (niezalogowany): Intel vPRO+AMT - jedynym warunkiem jest wspieranie tych technologii przez nasz sprzęt - co nie zawsze jest tak oczywiste. Sposób, który przedstawiłem jest uniwersalny i prawie niezależny od komponentów naszego komputera.

  #24 05.05.2016 18:34

@McDracullo: Do podstawowych zadań może i tak, ale jak masz troszkę większy dom i łączysz wifi z netia player to dzieją się cuda na ich odtwarzaczu ;)
Ogólnie router nie jest najgorszy, przynajmniej przekierowanie portów jest idiotoodporne ;)

anthony0013   7 #25 05.05.2016 18:38

@miggi: a czy mógłbyś opisać coś więcej albo krok po kroku jak dodać opcję VPN na linuxie ? Krok po kroku how-to by się przydało... jeśli można

anthony0013   7 #26 05.05.2016 18:39

@karol221-10: czy mógłbyś opisać krok po kroku jak się połączyć używając technologii vPRO+ATM ?

karol221-10   10 #27 05.05.2016 18:57

@anthony0013: VPN-em zajmę się w przyszłości. Co do VPRO+ATM, to niestety mój sprzęt, oparty na platformie AMD nie wspiera tych technologii, więc nie napiszę nic na ten temat.

McDracullo   17 #28 05.05.2016 20:14

@KlejnotNilu: Jakie cuda? Możesz rozwinąć? Ja nic nie zauważyłem. Spadek wydajności na WiFi jest oczywisty, wkońcu streamowanie video w HD jest dość obciążające. Jakoś łączyłem dodatkowe ap i ten router akurat nie zawiódł mnie ani razu. Ale prawdziwie konfigurwalny robi się dopiero po wejściu na konto admina ;)

  #29 05.05.2016 20:26

Podstawową wadą opisanego rozwiązania jest konieczność administracyjnego dostępu do routera. W firmach zwykle tylko Wybrańcy Losu, Prezesta lub Najwyższego Bajta mają takowy, więc idea kwasi się w zarodku.

Z rozwiązań bezpłatnych, nie wymagających w ogóle nawet spoglądania w stronę routera najlepszy jest dodatek do Chrome. Inna rzecz, że niedoreklamowany, bo firma chyba nieszczególnie wie, jak i po co go promować. Być może stąd biorą się dziwne niedoróbki (np. przez schowek można przesłać skopiowany tekst, ale nie można pliku tekstowego). Aż dziw bierze, że np. Mozilla nie wykoncypowała czegoś podobnego, nie doprawiła zjawiska VPNem i nie reklamuje jako najłatwiejszego sposobu na pracę zdalną do której wystarczy FF...

Rozumiem też, że TeamViewer to samo zło ale utworzenie połączenia jest bajecznie proste, wydajność na ogół wystarczająca i jednak korzystają z niego liczne banki łącząc się ze swoimi oddziałami... a stawiam fasolę przeciw gwineom, że nie doszłoby do tego, gdyby skrupulatnie nie został sprawdzony. Choćby dlatego, żeby z pensji prezesa nie zniknęło jakieś zero. Zresztą jakkolwiek połączenie zdalne nie byłoby realizowane, to za wyjątkiem przypadków kiedy komputery są w tej samej sieci praktycznie zawsze będzie ono przechodziło przez _jakiś_ serwer, ergo, lepiej wiedzieć, przez jaki serwer to połączenie przechodzi (= firmy TV) niż nie wiedzieć...

Zresztą jedną z bolączek informatyki stosowanej jest kiepskość ogólna łączenia się komputerów. Kiedyś królowały dyskietki, dzisiaj nieśmiertelne wydają się pendrive'y, bo zwykle najszybciej jest nagrać plik na pena, podejść do drugiego komputera i zgrać. Rozumiem inteligentne lodówki, kibelki nucące w rytm fali perystaltycznej i gadające windy, ale jakoś postęp omija rzecz tak trywialną jak natychmiastowe przesłanie pliku na inny (mój) komputer, telefon itp.Jakoś oczywiście się da, ale większość rozwiązań jest nieintuicyjna i boleśnie powolna. Najlepszym np. rozwiązaniem jakie znalazłem do przesyłania plików w sieci lokalnej jest Dukto. Niedoskonałym wprawdzie, bo często szwankuje wyszukiwanie albo firewall na komputerze potrafi mu zrobić kuku, ale najszybszym. Znowuż, aż dziw człowieka bierze, że typowy Windows czy Linux nie ma wbudowanej aplikacji tego typu.

Ukłony,

  #30 05.05.2016 20:41

@McDracullo: Początkowe wersje firmware netii player, miały problemy z wifi gdzie trzeba było ciągle rekonfigurować wifi. HBO GO kaszana, nawet na laptopie, czasami miałem takie sytuacje, że musiałem ściągnąć serial z torrentów bo było szybciej, niż przeczekiwać awarie na HBO, ale to było prawie 2 lata temu, więc możliwe, że coś sie zmieniło na lepsze.

Shiroi   7 #31 05.05.2016 20:50

95% o Windows, 5% o Linux - o czym to świadczy? O tym, że Linux lepszy i łatwiejszy "w te kredki" :D

  #32 05.05.2016 22:55

Proste i chyba najszybsze wyłączenie zdalnej maszyny przez Zdalny Pulpit (RDP) to Alt+F4 na pulpicie =standardowy skrót do zamykania. Pojawi się okienko z możliwością wyboru całej gamy zamknięcia (uśpienia, hibernacji czy wyłączenia systemu).

Poradnik ciekawy.

McDracullo   17 #33 05.05.2016 23:08

@KlejnotNilu: Mam dwie wersje NetiaSpota - jedna bardzo wczesna z softem z początku tego urządzenia w Netii (zakupiony 2 czy 3 miesiące po "premierze" w Netii) - na żadnej nie mam tego typu problemów... Mam masę innych problemów z tym urządzeniem (niski transfer USB lub problemy z drukowaniem wielostronicowych dokumentów ale to mimo wszystko tanie urzadzenie i nie wymagajmy od niego cudów. Na bank nie sa to problemy które sprawiają ze jest to urządzenie zle.

bystryy   10 #34 06.05.2016 08:47

@bachus: "W komercyjnych rozwiązaniach stosuje się raczej produkty typu BOMGAR - działa dość podobnie jak TeamViewer, jednak połączenia nie idą na zewnątrz. W firmie stawia się serwer (jest to najczęściej 'appliance' w postaci niedużej skrzynki) i do niego bezpośrednio idą połączenia szyfrowane."

Dzieki za info, dobrze wiedzieć o takiej alternatywie.

mktos   10 #35 06.05.2016 09:45

@anthony0013: Jeżeli masz AMT aktywne to możesz dostać się do webowego panelu swojego komputera odwiedzając http://:16992 i po zalogowaniu tam w interfejsie jest możliwość zdalnego włączenia.

edmun   12 #36 06.05.2016 14:10

"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."
nie za bardzo rozumiem gdzie tutaj jest jakikolwiek problem. Na routerze ustawiasz przekierowanie np. z portu 654 na port 3389 drugiego komputera w sieci, po czym łącząc się z klienta wpisujesz adres "mojzewnetrznyadresip:654" i po sprawie.... :/

karol221-10   10 #37 06.05.2016 14:39

@edmun: fakt, może trochę przekombinowałem, ale nie udało mi się tego sposobu, o którym mówisz, zastosować na routerze Netii (znaczy, ustawić się da, tylko co z tego, jak nie działa)

edmun   12 #38 06.05.2016 16:47

@karol221-10: dziwne, większość routerów ma możliwość przekierowania portu X z WAN na port Y w LAN. I w dodatku działa to bezproblemowo :P No nic.. jakby co tak tylko mówię, że nie trzeba zmieniać "hosta", wystarczy dodać inną regułę na routerze.

pilot67   3 #39 07.05.2016 10:01

Spotkałem się z sytuacją, że WoL nie był w stanie obudzić tradycyjnie wyłączonego komputera (Dell Vostro 470) z systemu Windows 10. Nie ma natomiast żadnych problemów z wybudzeniem tegoż samego komputera ze starszymi systemami Windows. Doczytałem gdzieś, że Windows 10 wymaga trybu uśpienia (nie wyłączenia), aby WoL zadziałał. Czy ktoś może to szerzej wyjaśnić?

Druga sprawa. Autor wspomniał, że w przypadku zdalnego dostępu do większej ilości komputerów w sieci lokalnej trzeba zmieniać porty nasłuchowe. Moim skromnym zdaniem dużo prostsze i wygodniejsze (bez ingerencji w rejestry itp.) jest inne ich przekierowywanie, które polega na tym, że wszystkie docelowe maszyny nasłuchują na standardowych portach, a jedynie router przekierowuje ruch z różnych portów zewnętrznych na ten sam lokalny ale dla różnych maszyn np.:
zewnętrzny port 33891 przekierowujemy na 3389 pierwszego komputera
zewnętrzny port 33892 przekierowujemy na 3389 drugiego komputera
zewnętrzny port 33893 przekierowujemy na 3389 trzeciego komputera
itd.
Należy wtedy pamiętać, aby podczas zdalnego dostępu podać też numer odpowiedniego portu.
Co prawda spotkałem kiedyś router, który nie potrafił realizować przekierowania portu zewnętrznego na wewnętrzny o innym numerze, ale mam nadzieję, że ten badziew już wyszedł z rynku ;-)

menuchin   1 #40 18.11.2016 19:52

Przydatny artykuł. :) Ale jak można to coś chciałbym Ci podpowiedzieć i nie będzie to uwaga na temat VPN. ;) Ale.. skoro już masz dostęp przez ssh to zamiast otwierać kolejny port dla RDP na routerze na świat nie byłoby bezpieczniej tworzyć sobie tunel ssh i przez niego łączyć się do Twojego, już włączonego komputera? Przy okazji masz dodatkowo zabezpieczone połączenie RDP i... "szafa gra". ;) Jedyne co można tu zarzucić to nie wiem jakby w tej roli pośrednika spisał się zaproponowany przez Ciebie telefon, ale Raspberry PI zapewne by sobie poradził bez problemów. ;) Pozdrawiam!