Kaj uporabit za remote dostop do domačega računalnika?

poweroff je 26. mar 2020 ob 16:55 izjavil:

Kam se pa v osnovi povežeš preko ssh?

Nekam, do kjer imas dostop.
Recimo, da imas racunalnik na lokaciji IPA in racunalnik na lokaciji IPB, ti si pa na mobilni lokaciji IPC. Iz IPC bi rad prisel do omrezja na lokaciji A, pri cemer so vse povezave proti IPA onemogocene, lahko pa tako iz IPA kot iz IPC naredis SSH na IPB. Vnaprej si vzpostavis povezavo iz IPA na IPB (uporabis recimo autossh, ce se slucajno povezava prekine) in nastavis, da se lokalni port 127.0.0.1:PB na IPB preslika na port 127.0.0.1:PA na IPA (to je tisti reverse, ki je bil omenjen). Ko si na IPC, vzpostavis SSH na IPB, pri cemer naredis normalen port tunneling lokalnega porta 127.0.0.1:PC na 127.0.0.1:PB na napravi IPB. Na IPA:PA imas zagnan OpenVPN server (na TCP portu), klienta, ki ga zazenes na IPC pa usmeris na 127.0.0.1:PC. Na IPA potem naredis se masquerading v IPA za vse, kar prihaja preko tunela, pa si zmagal (upam, da nisem pri opisu kje naredil napake, definitvno pa to funkcionira, ker sam to uporabljam).

MrStein je 26. mar 2020 ob 18:40 izjavil:

misek je 26. mar 2020 ob 18:00 izjavil:

A povezava poteka od doma na službeni računalnik ali iz službenega računalnika domov?

Če bi se OP bolj jasno izrazil glede tega, bi že imel delujočo rešitev.

Zato pa sprašujem. Polno postov ampak ni jasno kateri je dober :-)

knesz je 26. mar 2020 ob 11:00 izjavil:

RealVNC. Dela mac to mac, win to mac in obrnjene kombinacije.

Mogoče bi moral napisati malo več. Imam RealVNC, dinamični IP in sem za natom ter zadeva deluje enako kot Teamviewer. Za domačo uporabno brezplačno in ne prekinja povezave kot TW. Mogoče bi vsaj poizkusil?

Ja, samo z reverse povezavo te ne zanima dostop do omrezja serverja ampak v obratno smer. Pa (OpenVPN ali karkoli drugega) server je potem tisti, iz katerega si se prvotno povezal kot klient pri SSH.

In kaj ce tudi gazda rabi vpn?

Drugace eden od soft vpnjev resi problem v nulo, wireguard, zerotier, softether... preferiram zerotier, ker je za taksen namen idealen

rokp je 27. mar 2020 ob 08:35 izjavil:

Za tiste, ki pa zagovarjajo razne VPN resitve, ki med dvema poljubnima tockama brez kaksnih posebnih muk vzpostavijo povezavo - morda se ne zavedate, da taksne resitve potrebujejo se neko tretjo tocko, ki ni pod vasim nadzorom...

Ni res, v primeru ZeroTier je ta tretja točka lahko v tvoji lasti, če želiš.

MrStein je 26. mar 2020 ob 18:40 izjavil:

misek je 26. mar 2020 ob 18:00 izjavil:

A povezava poteka od doma na službeni računalnik ali iz službenega računalnika domov?

Če bi se OP bolj jasno izrazil glede tega, bi že imel delujočo rešitev.

Zgleda sicer, da se povezuje domov, od kod pa ... "Povezoval se bom 99% iz enega od svojih prenosnikov"

"Povezoval se bom 99% iz enega od svojih prenosnikov" - ki se bo nahajal na lokaciji, kjer ga bom trakrat uporabljal :) (včasih iz službe, včasih iz vikenda, včasih z dopusta na morju)..

Na to lahko gledas tudi drugace - bodi zadovoljen, da si zadnji v vrsti, tako imas verjetno ti dostop do omrezij sosedov in ne oni do tvojega. ;)

mzakelj je 27. mar 2020 ob 09:53 izjavil:

rokp je 27. mar 2020 ob 08:35 izjavil:

>
Za tiste, ki zagovarjajo razne VPN resitve, ki med dvema poljubnima tockama brez kaksnih posebnih muk vzpostavijo povezavo - morda se ne zavedate, da taksne resitve potrebujejo se neko tretjo tocko, ki ni pod vasim nadzorom...

Ni res. VPN lahko gre direkt server client, ni treba 3 strani ...

Je res, samo ti ne znas brati. Ne more portov odpirat ne na eni ne na drugi strani. Ima rokp cisto prav.

proto je 27. mar 2020 ob 10:29 izjavil:

mzakelj je 27. mar 2020 ob 09:53 izjavil:

rokp je 27. mar 2020 ob 08:35 izjavil:

>
Za tiste, ki zagovarjajo razne VPN resitve, ki med dvema poljubnima tockama brez kaksnih posebnih muk vzpostavijo povezavo - morda se ne zavedate, da taksne resitve potrebujejo se neko tretjo tocko, ki ni pod vasim nadzorom...

Ni res. VPN lahko gre direkt server client, ni treba 3 strani ...

Je res, samo ti ne znas brati. Ne more portov odpirat ne na eni ne na drugi strani. Ima rokp cisto prav.

Behind NAT Solution:
NAT-Traversal Function is enabled by default. No need to open any TCP/UDP ports on the NAT for accepting VPN connections which are initiated from Internet-side.

https://www.softether.org/3-spec

Evo, zdaj sem za hec naredil SSH tunel na zunanjo kišto, dostopati pa hočem na lokalno kišto (192.168.178.XXX) in to preko RDP (port 3389):

ssh -L 3389:192.168.178.XXX:3389 user@zunanjakista.si

V RDP clientu potem samo rečem: localhost, in padem na Windows mašino (192.168.178.XXX).

Najlepše je pa to, da če je Widows mašina ugasnjena. jo lahko z magic packetom preprosto zbudim oz. prižgem... in naslednjo sekundo se že povežem nanjo.

Tudi jaz sem do sedaj uporabljal obratni openvpn. Sedaj imamo zaradi razmer zrihtano drugače.
Drugače pa, če imaš v službi windows pro, enterprise ..,, ki omogoča rdp strežnik:
1. služben pc je klient
2. domači pc je strežnik
3. uredi si zastonj dns
4. port forward na domačem ruterju na tvoj pc na port 1194
5. namesti na oba openvpn: OpenVPN
6. drži se navodil za statično povezavo Navodila
7. ko se povežeš uporabiš windows remote desktop

V službi imaš datoteko s podatki kam se povezuješ (tvoj zastonj dns naslov), z datoteko ključa, doma pa je datoteka s konfiguracijo "strežnika" in ključ.

Pa ti beres problematiko? Ce ne mores odpret portov za noter, ti noben od teh klasicnih vpn tunelov ne bo deloval. NAT-traversal tudi ne resuje tega problema. Ostanejo samo resitve z vmesno, tretjo tocko izven source in destination omrezja, ce imas oba limitirana, da ne mores NAT urejat.

zerotier je open-source, če koga to skrbi (kot da RDP ni sam po sebi enkriptan...).

zerotier preverjeno deluje čez NAT-e na obeh straneh (tudi več zapovrstjo).

Navodila za začetek so tule: https://zerotier.atlassian.net/wiki/spa...

(je malo več kot dva klika, nekje pet...)

Še enkrat, ker sem danes spil eno kavo premalo: ali Zerotier uporablja kakšen vmesni, zunanji strežnik?

Ja, uporablja.

Sami paketki potem gredo direktno, če ni preveč "čudno" omrežje.

Eh, probaj, pa boš videl, a ne?

(če že ne veš, kako te stvari delujejo)

Daj, razloži kako UDP hole punching deluje, če sta OBE strani zaprti?

Saj je razloženo. Rabiš randevouz server.

Ja, mogoče se ne razumeva čisto.

Jaja. Ampak kolikor razumem OP-a je ravno to problem, da tega nima.

Saj ne rabi, to mu ponuja ponudnik softvera.


Bom ponovil za tiste, ki berejo samo z enim očesom:
Stvar.
Preverjeno.
Deluje.

Bo?

Skozi celo temo se vleče zmešnjava pojmov.

Prva zmešnjava je rezultat metanja pojmov v isti koš. Tako nihče ne loči več med "orodji za oddaljeni dostop" in VPN povezavami.
Poleg tega marsikdo očitno ne razume osnovnih principov mrežarjenja in VPN povezovanja.

Če se odmaknemo od remote access/managemnt rešitev in pogledamo samo 'prave' VPN povezave, imamo običajno opravka z dvema tipoma povezav:
a) omrežje - omrežje
b) odjemalec - omrežje

V tipični varianti mreža-mreža lahko katerakoli stran vzpostavi tunel - če sta obe strani na statičnih IP naslovih.
V primeru, da statični naslovi niso na voljo, si pogosto lahko pomagamo z DynDNS strežniki, tako da se tunel ne vzpostavlja na IP naslov, ampak na FQDN naslov, katerega preko DynDNS servica razrešimo v IP naslov.

Pri tem se običajno vzpostavi tunel, ko se pojavi 'potreba', da se preko njega pošlje paket podatkov na drugo stran. Pri mreža-mreža variantah je običajno lahko vsaka stran iniciator vzpostavitve tunela.

Drugače pri odjemalec-mreža varianti. Tu se ve, da je odjemalec precej 'mobilen', tako da se vsi scenariji nanašajo na to, da bo izključno odjemalec tisti, ki bo (po potrebi) vzpostavljal tunel.

Če zdaj v sliko postavimo še router ali dva z NAT-om brez forwardiranih portov, se seveda stvari bistveno zakomplicirajo, saj se s tem avtomatično določi stran z problematičnimi routerji kot stran, ki mora biti iniciator tunelov.
Pri mreža-mreža varianti to morda še deluje, problematično pa postane pri odjemalec-mreža varianti, saj ta že v osnovi ne predvideva, da bi bil 'gateway' tisti, ki bo vzpostavljal povezavo.
Pa tudi če bi gateway izvajal nekakšen 'callback' - če odjemalec ni direktno dosegljiv in se skriva izza NAT routerja, potem stvar spet ne bo delovala brez nekih dodatnih fint in for.

Tudi če bi bil odjemalec direktno dosegljiv na IP naslovu, ki ga deli preko DynDNS, mora nekdo dopovedati VPN strežniku, da odjemalec potrebuje povezavo. Ker je ta strežnik izza NAT-a, pa imaš spet problem.

Najlažje bi bilo, če bi se poslužil metod, ki se jih poslužujejo botneti. To nekje na IRC čakajo na znanem kanalu na ustrezen ukaz, ali pa npr. na twitterju na določen ukaz preko twitter omrežja.

Še pa vedno imaš problem, ko sta obe strani izza NAT routerjev brez forwardiranja portov. Takrat direktna povezava ne pride v poštev in se ne moreš izogniti nekemu 'posredniku', ki bo promet posredoval v eno in drugo stran. Tako, kot to že takointako počne večina 'remote access' rešitev.

V glavnem nobena znanost, zgolj nekaj logike je treba uporabiti.

SeMiNeSanja je 29. mar 2020 ob 05:58 izjavil:

Še pa vedno imaš problem, ko sta obe strani izza NAT routerjev brez forwardiranja portov. Takrat direktna povezava ne pride v poštev in se ne moreš izogniti nekemu 'posredniku', ki bo promet posredoval v eno in drugo stran.

Seveda gre. Bilo opisano, z linkom na detajle.

TW nameščen na hdd (ne portable) trenutno zadnja verzija za win je 15.4.4445, kako odpraviti reklamni nag, ki se pojavi pri izhodu iz TW ?
Zapri TW.
V mapi %userprofile%\AppData\Local\Temp\TeamViewer\ se nahaja fajl "TeamViewer11_Exit.hta", odprite ga v notepad++/wordpad, pobrišite vsebino, shranite, nato dodajte attribut read-only (velikost fajla 0 bytov).

https://docs.microsoft.com/en-us/window...

attrib +r %userprofile%\AppData\Local\Temp\TeamViewer\TeamViewer11_Exit.hta