Van egy vidéki végpontom, ami szolgáltató routere mögött csücsül (NAT), vagyis nincs publikus IP címem.
Ezen a hálózaton van egy raspberry pi, amit szeretnék pestről (otthonról) elérni ssh port forward segítségével. Pesten publikus IP címem van freeDNS -el elérhető.
Ha egy nem "védett" portot akarok forwardolni, az anno egy ilyebn egyszerű paranccsal működött:
ssh -R 10080:localhost:10080 tovis@freedns.wn -p 10022
A parancsot a távoli gépen futtattam úgy, hogy óránként megnéztem működike a kapcsolat és ha kellett megpróbáltam újra indítani (crontab).
Akkor amikor ezt használtam, a pesti szerver oldalon az 10080 címen elértem a távoli gépet,, mintha az a szerveren működne (egyébként egy kis web szerver volt erre portra felrakva a távoli eszközön).
Most viszont magát az ssh portot szeretném így beüzemelni sudo -val, de sehogy sem akar működni. Úgy tűnik, miután lefut hogy a szerverbe loginelnék, kiadja a szerver promtját a távoli eszközön.
Mi nem stimmel ezzel a megoldással?
Kijavítottam a port neveket, felhasználtam két jó kis opciót a lejjebb látható scriptből (köszönöm9 és screen -ből indítva működik.
Köszönöm a segítséget!
Hozzászólások
Nem egyszerűbb szólni a szolgáltatónak, hogy kapcsoják ki a NAT-ot? Kb. 5 perc miután felvette az ügyfélszolgálatos a telefont.
Utána beállítod a routered, csinálsz egy dinamikus dns nevet oszt' csá.
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
Sajna eddig mindig az volt a válasz, hogy akkor fix IP kérek?
3-4 eFt.
Persze sokkal egyszerűbb lenne az életem.
* Én egy indián vagyok. Minden indián hazudik.
Aki nem érti a különbséget, az menjen kapálni, ne ilyen ügyfélszolgálaton dolgozzon. Ezt bele is mondtam a telefonba egyszer. Mindjárt tudták miről beszélek. Csak sokszor játsszák a hülyét, mert úgy könnyebb eladni még valami szart, amire a jobbágynak amúgy semmi szüksége.
Egyébként fix ip magánszemélyeknek nem is jár sok szolgáltatónál. Akkor sem ha kéred, mert legtöbbször csak üzleti előfizetéshez tartozik. A publikus IP-ről pedig úgy tudom, hogy van valamilyen hírközlési törvény, amiben benne foglaltatik, hogy a usernek jár a publikus IP alanyi jogon ha kéri, így azért plusz pénzt felszámítani nem lehet.
- Indítsd újra a gépet! - Az egészet? - Nem, a felét...
Kicsit nehézkes (nekem) a kommunikáció velük. De eszembe jutott, hogy most cserélődött a tulajdonos és tavasszal egy egészen értelmes ügyfélszolgálatossal volt dolgom. Lehet érdemes megpróbálkozni ezzel - sok fejfájástól megkímélne.
Pesten üzleti ügyfélként fut az előfizetésem, ott vasárnap késő délután is felkapta a műszaki ügyfélszolgálat a telefont és segített. Nem mondom a vidéki előfizetésem fele annyi (meg a sebesség is).
* Én egy indián vagyok. Minden indián hazudik.
Ez a tövény/jogszabály engem is érdekel. Ha esetleg majd megleled, kérlek csadold ide.
Amúgy igen, a szolgáltatók többsége nem akadékoskodik és feloldjda a NAT-ot.
Tapasztalatok:
ssh -J ?
Öreg róka létemre még nem láttam ezt a switchet!
A https://linux.die.net/man/1/ssh nincs is felsorolva, viszont a --helpo -re kidbja hogy van.
A Raspberry pi -n egy 10 raspbian fut, (4.19.c kernel).
Eltudnád mondani mire is jó ez a "jump" parancs?
Próbálom értelmezni de nem igazán vágom :(
* Én egy indián vagyok. Minden indián hazudik.
ssh -J kulso_IP belso_IP
és már bent is vagy
Sem nem -R sem nem -L ?
ssh -R 10080:localhost:10080 tovis@freedns.wn -p 10022
ez a távoli ( remote) szerver külső )internet oldali) címe + port.
a localhost pedig a helyi IP cím.
Mi itt a belső és mi a külső?
Bocs, hogy értetlenkedek de ez még mindig zavaros nekem.
* Én egy indián vagyok. Minden indián hazudik.
Ha a routerhez is van ssh accountod, akkor tudod használni jumpnak
ssh -J wan_ip lan_client_ip
ssh -J 8.8.8.8 192.168.1.110
Ahol a 8888 a router a belsőhálóra és a 110-es gép a cél.
Sajnos ez nem tűnik hasznosnak. Az a router ami látja a 192.168.1.110 wan címe, nem publikus, egy router mögött csücsül - NAT.
Az a router aminek van publikus IP címe (freeDNS) az meg nem "látja" a 192.168.1.10 címet.
OFF: Egy másik topicban próbálok segítséget kapni az ASUS OpenVPN beállításhoz, mivel a pesti szerverre kapcsolódik a vidéki kliens (két azonos típusú router). A vidéki kliens látja a pesti hálózatot, viszont a pesti szerver oldalról nem látom a vidéki hálózatot- Érthetetlen.
* Én egy indián vagyok. Minden indián hazudik.
Ezekszerint: Router(Publikus)->Router(Privat)->Lan(Privat) ?
Jól értem?
Talán így helyesebb
LAN(privat)->router(punlicus)<-router(szolgáltató NAT)<-router(privat)<LAN(privat)
* Én egy indián vagyok. Minden indián hazudik.
Mi az a punlicus? :-D
Hát ez már így marad :)
* Én egy indián vagyok. Minden indián hazudik.
Tudom - szándékos volt :-P
Freud lehetett. Ehes makkal disznokat almodsz. :)
A strange game. The only winning move is not to play. How about a nice game of chess?
:D
igen, ez így müködik, de a portot is forwardolja közben. hásználhatod a -N opciot ha csak forwardra kell.
btw, erre wireguardot használnék.
Ez jó (és könnyen értelmezhető) tippnek tűnik, (Mintha az rsync parancsokban láttam volna ezt a swicthet)
* Én egy indián vagyok. Minden indián hazudik.
+1 a vpn-es megoldásra.
A gond, hogy nem akar összeállni. Az ssh tunnel régi jó megoldás az ilyesmire.
* Én egy indián vagyok. Minden indián hazudik.
Az ssh-s portforward a tákolás erre... A "nem akar összeállni"-nál valami bővebb infó volna, hogy segíteni tudjunk? Mit konfiguráltál már az egyik meg a másik végén, a routereden van-e erre portforward (ha buta a router, és nem tud vpn-szerverként működni), stb...
Most ilyen hibaüzenetem van:
Warning: remote port forwarding failed for listen port 22
* Én egy indián vagyok. Minden indián hazudik.
akkor rossz a parancsod. valami ilyesmi kéne:
ssh -R 2222:localhost:22 user@remote
aztán a remote serverren ssh user@rpi -p 2222
esetleg leírnád a parancsod? :)
Csak
csúfroot felhasználó tudja megnyitni a 22-es portot. Ha még nem foglalt.Hibásan adtam meg a parancsot, a remote host 22 portját próbálta befoglalni ;)
Javítottam, elindult, viszont mire hazaértem már lefittyent - broken pipe stb.
Kell valami ami újra indítja.
* Én egy indián vagyok. Minden indián hazudik.
Miota felfedeztem az openvpn-t, nem szenvedek az ssh port forwarddal. Bohockodjon a fene crontabbal...
Biztonsagi megoldasnak ott a TOR vegpont. Ez legalabb jo lassu.
+1, fillerekert lehet kapni vpst, oda bekoti openvpnnel, es nincs gondja hogy mikor szakad le, meg takolja korbe az ssh-t...
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Meg az se kell.
A kozeli gep publikus IP cimen van, megy a dinamikus DNS. A tavoli gepen futhat az openvpn kliens, a kozelin meg a szerver.
Off: múltkor olyasmi gondunk támadt, hogy A-gépről nem lehetett B-re jutni (tűz- és vízfalak), de B-ről A-ra igen; viszont az A:20020 portot kellett volna B:20020-ra továbbítani (rinetd). Ezért a B gépen lett egy ilyen csodaság:
A helyes megoldás: normál eljárásrend szerint kérni tűzfalon nyitást.
Ez akkor igaz, ha a szolgáltatódnak van megfelelő kapacitása az ilyen feladatokhoz.
Másként több hetes átfutási idő, hibás beállítások stb.
Sokszor, amikor egy harmadik szolgáltató is benne van már az s gond, hogy hol van a hiba.
* Én egy indián vagyok. Minden indián hazudik.
Attól még a tűzfalak ilyetén történő meghágása nem elfogadható. Nekem is volt olyan, hogy SOS-ben kellett DB-t javítani, és ilyen jellegű megoldás maradt - vezetői jóváhagyással, és kizárólag a javítás idejére. Általában nem véletlen, hogy merről-merre mehet át a tcp syn csomag a tűzifán, és merre nem.
Köszönöm szépen!
Áttanulmányozom mit is csinálhat ez a script pontosan.
* Én egy indián vagyok. Minden indián hazudik.
Lehet azért nem tudom "röptében" átirányítani mert egyébként ssh -n csatlakozok?
(Nincs konzol, lokálisan is ssh kapcsolatot használok.)
* Én egy indián vagyok. Minden indián hazudik.
Esetleg csinálsz egy ingyenes vm-et pl. oracle cloudban, annak van fix ip címe és arra teszel egy vpn szervert, a raspberry-re meg egy klienst, így bármikor eléred. De a fixip-s vm-et az ssh-s portforwarddal is egyszerűbb elérni. Vagy tailscale.com ingyenes accountal csinálsz magadnak egy vpn-t, felteszed a raspberry-re, felteszed magadhoz és készen vagy.
Desktop: MacOS | Server: CentOS
+1 erre a megoldásra. Tailscale egyébként Wireguardra épül, pár eszközig ingyenes, teljesen jó megoldás. Oracle Cloudban akár viszonylag "combos" arm alapú instance-ot is lehet futtatni ingyen, vagy szimpla x86 VM-et minimális erőforrással, OpenVPN szerverként, és van public IP, Frankfurti régióban nincs is messze.
Illetve én régen, amikor a vpn nem jöhetett szóba, akkor autossh-t használtam 4-5 éve systemd (illetve akkor még init.d service-ként), itt egy egész jó leírás róla: https://pesin.space/posts/2020-10-16-autossh-systemd/
de ha mar felsorolunk megoldasokat, akkor ezt is egy lehetseges: https://ngrok.com/
es meg van egy cloudflare tunnel megoldas is: https://developers.cloudflare.com/cloudflare-one/connections/connect-ap… (ha jol latom ssh-t is lehet vele tunnelezni valahogy)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!