Teamviewer és Anydesk alternatíva - HopToDesk

Fórumok

Sziasztok,

Teamviewer és Anydesk helyett keresek ingyenes alternatívát.
Rátaláltam a HopToDesk programra, mely Free és Open Source, személyes és üzleti felhasználás esetén is.

https://www.hoptodesk.com
 

Feltelepítettem, három külön helyen lévő windows gépen és androidon is használom, szépen, stabilan működik, csak dög lassú.
Nagyon lassan mennek át a képadatok, bármennyire is lebutítom a felbontást.
Tudja azt a funkciót, hogy készíthetek saját szervert hozzá (mondjuk pl. egy VPS-en), ahhoz tudnak a kliensek csatlakozni, és akkor gyorsabban lehetne használni, és csak saját gépen mennek át az adataim...

Amit találtam hozzá doksit, abból nem tudtam egy debian alapú vps-re feltelepíteni és beüzemelni a szerver részét. A windows-os config fájlok is .toml kiterjesztésűek, a doksiban pedig .json szerepel.

https://help.hoptodesk.com/#category-advanced

Segítséget szeretnék kérni, ha van köztünk, aki használja a szerver részét, vagy szeretné használni, ossza meg legyen szíves, hogyan tudom debian vps konzolból telepíteni, konfigolni, és elindítani a szervert.

Köszönöm!

Joda.

Hozzászólások

Microsofton van távsegítség. Ingyenes, a segítőnek online account kell hozzá.

ki akartam próbálni - de nem jött elő csak feldobta ezt:

--------------------------------------------------

| Ezen ms-quick-assist típusú hivatkozás     |

|  megnyitásához új alkalamzás szükséges  |

-------------------------------------------------

For Whites Only meeting room!

Ez - finoman szólva - nem egészen ugyanaz, mint amit a TeamViewer vagy az AnyDesk tud. Utóbbi kettő esetén nagyjából elegendő a sikerhez annyi a segítséget váró oldalon, hogy le kell tölteni és el kell indítani egy alkalmazást, nem kell foglalkozni a router és a PC tűzfalával sem. A kérdés nem erről szólt. Nem Windows a téma. Más problémát így hirtelen nem látok...

Mi lemondtuk ez évben a Teamviewer és AnyDesk előfizetést is, mert kezdett nem tetszeni az évenként másférszerezés-duplázás árban.

A RustDesk lett helyette, ez messze a legközelibb alternatíva a lehetőségek közül.

Tökéletesen működik, nagyon gyors az átvitel saját szervert üzemeltetve.

Annyi kínlódás van vele, hogy nincs egyszerű/profi módszer arra, hogy a telepített kliens a saját szerverre kapcsolódjon kapásból (ami elvárás, ha egy új user letölti a support oldalunkról, és elindítja). Az alárt publikus bináris a teszt szerverre kapcsolódik, és írja is, hogy üzemelj be saját szervert, hogy gyorsabb legyen a működés.
A Windows kliens tud olyant, hogy a fájlnévbe bele lehet kódolni a szükséges adatokat, és azokkal fut/települ. Működik is így rendesen, ezt használjuk most, de nem elegáns. Más OS-en ez nem működik (szerencsére máson még nem is kellett egy kollégának sem).
Lehet előre megírt script-tel telepíteni saját adatokkal (ilyen példa script van minden OS-re az oldalukon), de van amikor csak egyszeri futtatás kell, nem telepített mód. Van olyan opció, hogy saját kliens fordítása, ehhez még egy Docker is össze van rakva. Viszont azt a rész én még nem láttam eddig át, hogyan lesz abból könnyen futtatható/telepíthető Windows által elfogadottan aláírt bináris...

Maga a szerver oldala 5 perc alatt futtatható kis VPS-en Docker-ben, semmiség beüzemelni.

Ezen felül lehet érte fizetni (teljesen korrekt pénzt kérnek), és akkor a saját szerver az alapfunkción felül user menedzsmentet kap hozzáférés szabályozással, és központi címtárat. Ilyent még nem csináltunk magunknak, eddig nem éreztük a hiányát. A doksi alapján jelenleg a fizetős verzió sem tud olyan binárist kiköpni, ami a saját szervert tartalmazza alapból.

Bárkinek bármi tapasztalata van ezzel a rendszerre, szívesen venném!

Nincs. Az csak úgy működik magában, kezeli a felek összekötését (elsősorban közvetlenül próbálja, de ha nem megy, akkor magán keresztül relay-ezi).

Két "modulból" áll, ezek külön konténerben futnak. Az egyik egy relay, a másik a vezérlő. Több relay is lehet különböző helyeken, és a vezérlő megpróbálja a kliensek számára legoptimálisabbat választani a késleltetés csökkentésére. Ez modjuk minket itthon nem igazán érint a jelentéktelen távolságok és az aránylag jó internet kapcsolatok miatt, de lehet ilyent is akár.

Nekem egy Nginx Reverse Proxy mögött vannak egy VPS-en, az ingyenes verzió esetében webes forgalamat nem, csak stream-et kell továbbítani a konténerek felé.

Erős érv, hogy opensource és saját infrastruktúrán használható. 

Az csöppet aggasztó, hogy szeptemberben eltávolították a Play storeból az androidos klienst, pláne az ok.

Ha nem cél a saját kézben tartani az infrastruktúrát, akkor a https://remotedesktop.google.com/access a legjobb megoldás. Chrome mindenhol van, a google account biztonságos, különösen ha élnek a userek a rendelkezésre álló biztonsági extrákkal.

Mindkettőtöktől kérdezem, hogy biztonsági aggályok sem nektek sem az ügyfeleknek nincs ilyen fixen telepített VNC-vel? Oké, hogy VPN-en megy a forgalom, így az biztonságos. De ha sikerül bejutni a rendszebe, akkor onnantól a fixen telepített VNC már nem egy nagy kihívás, és a hozzáférést senkinek sem kell jóváhagynia, a felhasználó nem is tud róla adott esetben.

A másik, hogy a VNC-t át kell engedni a windows/egyéb tűzfalon, az plusz feladat és plusz hibalehetőség. Míg kifelé általában mindent engednek ugyanezek tázfalak alapból.

Mi úgy használjuk a telepített verziót is, hogy amikor távsegítség kell, akkor a felhasználó hagyja jóvá a kapcsolatot minden esetben, nem előre megadott fix jelszóval megyünk be. Ráadásul egy csomó ügyfél van NAT-olt internet mögött, így oda nem is tudnánk VPN-ezni, csak akkor ha csinálnánk egy VPN hubot magunknak, de az is egy biztonsági rés lenne onnantól, hogy az ügyfelek rendszerei oda fixen fel vannak csatlakozva. Szerintem. Az meg általában nem járható (emberi korlátja van :-), hogy az ügyfél gépere egyesével tegyünk VPN klienst és az ügyfél becsatlakozzon rajta távsegítség kérés előtt...

A tűzfalon engedni a VPN ip tartományt kell a VNC fele, nem mindent.

Pont az az előnye, hogy nem kell user-interakció, ha csak otthagyja bekapcsolva a gépet, akkor rá lehet lépni csinálni.

Nem te VPN-ezel az ügyfélhez vagy a klienshez, hanem a kliens VPN-ezik ki "hozzád".

"Sose a gép a hülye."

Értem, de pont ez a para, hogy "valaki" hozzáférhet úgy a géphez, hogy a felhasználó/cég nem tud róla... Ez manapság egyre kevesebb helyen tetszik, ahol már eljutott valami vezetőig, hogy az adatokra vigyázni kell, mert komoly bünti jár ellenkező esetben.

Meg ugyan ez van a folyamatosan élő admin VPN kapcsolattal, amin keresztül jó eséllyel olyan dolog is elérhető az adott cégnél, ami alapból a belső hálózatról sem (admin VLAN vagy hasonló).

A tűzfalat már fent íták, arra nem tudok érdemben mit mondani, h az user mit szól hozzá. Nálunk a bizalom megvan, nem szoktam leskelődni, illetve nem hobbim nézelődni, ha valahová be kell néznem, akkor hívnak, mert munka van. Meg szokták érteni, h nekem nem a munkám a hobbim, tököm sem fog belépni, ha nincs valami bajuk, és nem hívnak. Amúgy az ikonja megváltozik, illetve villan a képernyő, mikor belép valaki.

Márkaszervízben is ott hagyod a kocsid, és hiszel nekik, amikor becsszó lecserélték a fékfolyadékot is...

Itt nem a bizalomról van szó, hanem a felelősségről.

Ha bármikor hozzáférhetsz egy ügyfél/felhasználó gépéhez a közreműködése nélkül, akkor hogyan bizonyítod egy arról a gépről történt pl. károkozás esetén, hogy nem Te voltál? Ilyen reszletes, pláne hiteles naplózás tuti nincs ilyen távmenedzselt desktopokon...

Szerinten ez nem kötekedés kérdése (az ügyfél részéről), hanem felelős hozzáállás a szolgáltató részéről. Pont az ügyfelek legtöbbször leszarják az ilyesmi kockázatokat, mert nem is tudnak róla, vagy nem érzik úgy, hogy ebből bajuk lehet (amíg nem fordult elő). Ellenben a szakembernek igen is foglalkoznia kellene ezzel, mert Ő ért hozzá, neki kell ezt tudnia az ügyfél helyett is. Szerintem ez a professzionalizmus része.

Hétvégén szerver/hálózat tervezett munkák vannak csak (nyilván az sem minden héten), nem desktop. Az megy alkalmi admin VPN-en (vagy helyszínen előben). Desktophoz nem kell hozzáférés hétvégén.

Hajnal kettőkor csak hibaelhárítás, ha életbevágó a rendszer, de az is csak egyszer. Mert ha ilyen előfordul, vagy finanszírozzák a redundánsra alakítást, vagy együtt élnek a megállással a második alkalommal az emberi időpontban történő hibaelhárításig (a legtöbb KKV nem tudja/akaja kifizetni a valódi 24 órás rendelkezésre állást, meg valószínű nem is érné meg). Olyan nincs, hogy egy rendszer annyira fontos, de nem hibatűrő. Az filléreskedés, olyan ügyfél nem kell, aki az én időm pocsékolásával spórol.

Ha egy desktopnak 15 percnél hosszabban javítható baja van munkaidőben, akkor csereeszköz, dolgozzon azon tovább, és majd visszakapja az eredetit, ha kész. Ha nincs csere eszköze, akkor biztosítunk, de ki kell várnia, míg hozzá eljut (ezért nem szaladunk oda soron kívül senkihez). Így mindenki mérlegeli, tudja nélkülözni addig (mondjuk 1 munkanap), vagy tart saját cserét ilyen kis értékű dolgokból, mint egy desktop vagy laptop.

Aki desktop supportot vár el hétvégén és/vagy éjjel, úgy, hogy Ő nem akar a gép előtt ülni (engedélyezni - ergo folyamatos unattended elérhetőség kell a desktophoz), de az IT-s akkor csinálja (csak mert), az valóban keressen máshol balekot... Az az igazi fillérmegcsináló kategória, szóba sem szabadna egy IT-snek sem állnia ezekkel, hogy eltűnjenek a piacról, vagy foglalkozzanak olyasmivel, amihez nem kell számítógép.

Vendéglátó iparban kicsit más a szitu, mint máshol. Mikor éjjel a pincér hív, és én mondanám neki, h akkor adjon tv azonosítót/jelszót, hát, az egy elég hosszú beszélgetés lenne, én ilyenkor inkább alszom. Jelenleg belépek a szerverünkre, onnan vnc ikonra duplaklikk, megoldom a baját, csurizok, és fekszek vissza.

Ami gépre belépek, ott az esetek 99%-ban nincs is semmi más adat, csak az éttermi rendszeré, mert arra használják. Nyilván forgalmat látnék, ha érdekelne, de nem érdekel.

Mi a baj az állandó VPN-nel? Üzemeltetni hogy lehet másképp? Telefonálgassak mindig a usernek, hogy lécci-lécci, engedj már be, hadd nézzek be az egyik switchre, hadd restartoljam az egyik AP-t. Vagy ami mégjobb, restart után nem indult el a szerver, engedj már be idrac-ra... Mindezt mondjuk szombat este vagy vasárnap akár.

De egyébként nem kell állandó VPN, ha van egy épkézláb mgmt-ed vagy monitoring rendszered, azon keresztül is kb. bármikor bármit meg lehet csinálni. Ezek nélkül meg nem lehet üzemeltetni.

És igen, a belső office/prod/akármilyen hálóról rohadtul nem kell elérni sem a mgmt hálót, se a voip-ot, se a kamerást, csak max. 1-2 nagyon specifikus dolgot (pl. NVR-nek a remote app portja). Ezzel ő van védve.

"Sose a gép a hülye."

Hát, nekem sohasem fordult meg a fejemben, hogy az ügyfelek felől _állandó_ VPN kapcsolat csatlakozzon be hozzánk (vagy tőlünk az ügyfél felé), ráadásul olyan hozzáféréssel, amivel a belső rendszerek, menedzsment dolgok is elérhetőek... Hogy még azért is aggódjak, hogy ha engem felnyomnak, akkor mindenkit felnyomnak (és nem azért, mert a suszter cipője lyukas, hanem azért, mert nincs 100% védelem...).

Én amikor ügyfélnél csinálni szeretnék valamit szerveren/hálózaton (ilyen aránylag gyakran van, ez a fő profilunk :-), akkor admin célú VPN-en kapcsolódok az ügyfél rendszerébe, aztán bontom a VPN-t, amikor végeztem. Az összes ügyfélnél elvárásunk, hogy legalább publikus IP cím legyen (ha nem is fix), amin tudunk VPN-t üzemeltetni.

Desktop gépekre meg kizárólag ügyfél/felhasználói engedéllyel kapcsolódunk rá javítani, bármit csinálni minden alkalommal. Nem is értem, kinek jó az, ha az ügyfél erről nem tud/távollétében történik. Akkor ha valami baj van, mehet a magyarázkodás, hogy ki volt a ludas... Ráadásul itt is bejon az, hogy ha megszerzik a (feleslegesen) fixen folyamatosan rendelkezésre álló hozzáférést illetéktelenek, akkor van a baj...

Bármi olyan rendszert üzemeltetsz, ami folyamatos hozzáférést nyújt egy távoli hálózathoz, az biztonsági rés, ráadásul komoly. Én a monitorozást is úgy csinálom, hogy ügyfélnél Zabbix proxy aktív módban, ő csatlakozik a Zabbix szerverre (ügyfél oldalon nincs erre port nyitva befelé), és úgy küldi az egész ottani hálózatból mindenről az adatot, persze ttikosítottan. Ezen felül a monitoring szerver semmilyen beavatkozást nem tud végezni a megfigyelt rendszereken, pont a biztonság miatt, hogy ha azt megtalálják, akkor ne tudjanak ügyfélnél kárt okozni.

Persze, hogy a belső hálóról nem kell a speciális szegmenseket elérni. Nade kintről sem kell folyamatosan, kvázi felügyelet nélkül elérni ezeket. Szerintem.

Bár ingyenes alternatíváról volt szó, nem tudom mit tud az ingyenes ága, de mi nagy megelégedettséggel használjuk ezt: https://www.splashtop.com/products/business-access

Van ad-hoc futtatási lehetőség (https://www.splashtop.com/downloads#sos), amikor csak a linket kiküldjük az ügyfélnek (vagy beágyazzuk a saját rendszerünkbe), letölti, futtatja, kódot beolvassa és tudunk csatlakozni. Ennél nem volt semmivel sem jobb vagy gyorsabb a fent említett két szolgáltatás.

Sub

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

en is attertem a rustdesk-re, foleg hogy a TV mar egy ideje hasznalhatatlan, kezdte az 5 perces limitekkel mostmar connect utan par masodperccel kidob valamiert (mac-es kliens, win gepre csatlakozik).

nekem a sebessegevel sincs gondom, igy egyelore sajat szervert se csinaltam hozza.

egyeduli bajom vele, hogy ha az egeret a tulso fel mozgatja, akkor azt en nem latom, de megse tudok kattintani vagy nem oda ahova gondolom. szoval vagy le kell tiltani addig a tavoli iranyitast, vagy szolni neki hogy ne piszkalja o is. (maceras ha meg akarna mutatni valamit)

En a remotly-t varom mar, hogy rancba szedjek.

 

https://remotly.com/

 

Nagy elonye, hogy ez nem csak tavsegitsegre jo, hanem akar tavmunkara is, hiszen (pl NVidia kartya eseten) NVENC-t hasznal (Mint a Sunshine, vagy akar a Geforce Now), amivel nem gond a 4K 120 FPS sem, kozel valos idoben. Tehat pl Autocad kaliberu dolgokra is jo. (pl Home Office eseten)

 

Jelenleg ami hatranya:

- Nincs Linux kliens :( (igerik a nativ klienst, ill a HTML5/WebRTC valtozatot) 

- A lokalisan uzemeltetheto relay server meg szinten "under construction"

- Van egy bug, ami miatt aktiv VPN eseten is relay serveren keresztul akar csatlakozni, nem pedig direktben. (ezt elv a kovetkezo release-re javitjak)