Nem fog az agyam :( Segítsetek kicsit.
Van egy Linuxos gép két tűzfal/NAT mögött a távoli homályos interneten, rajta egy kis WEB szerver a 10080 -as porton, amit kívülről nem lehet látni.
Van egy kis Linux szerver a házamban, ami tűzfal/NAT mögött csücsül, de az ssh port kivan rakva :)
Addig jutottam, hogy a távoli homályból, "reverse" ssh -val beléptem a házi szerverembe:
ssh -R 29999:localhost:10080 tovis@tovis-lab.dyndns.be -p 20022
így a szerveremen a
$lynx http://localhost:29999
látom a távoli homályos web szervert :)
Viszont szeretném a házi lanon mondjuk a 20080 -as porton elérni (a házi szerverem csak konzolt tud). Mintha a netcat tudna ilyesmit, de az csak egy irányban működik, illetve mintha lenne valami proxy opciója de nem tudom a man -ból összereakni. Tudtok valamit súgni?
- 9162 megtekintés
Hozzászólások
Szia.
ssh -gL 20080:localhost:10080 -l tovis -p 20022 tovis-lab.dyndns.be
Üdv: Zoli
- A hozzászóláshoz be kell jelentkezni
Sajna ez így nem működik, de ha jól értem akkor nem kell netcat, hanem ssh tunneling -el kellene megoldani?
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Bocsánat, már én is fáradt vagyok. Az otthoni szervereden add ezt ki:
ssh -gL 20080:localhost:10080 -l remote-username -p 20022 remote-hostname
Értelemszerűen a távoli ssh portot és adatokat lecserélve a sajátodra.
Üdv: Zoli
- A hozzászóláshoz be kell jelentkezni
Ha feltétlenül reverse tunnel-re van szükséged:
az ssh szerveren még be kell állítani a GatewayPorts opciót, illetve az -R parancssori kapcsolónál még bind-olt interface-nek meg kell adni a *-ot:
-R '*':29999:localhost:10080Ennek hatására az sshd mindenkit ki fog szolgálni, aki eléri a tovis-lab.dyndns.be:29999 portot. Így azt a portot valahogyan korlátoznod kell a helyi hálódra -- mondjuk iptables-zel.
Egyébként én sem értem, miért reverse tunnel-t akarsz. Elvileg a távoli homályban lévő gépre is belépsz valahogy, nem? Ha már belépsz rá ssh-val, akkor crt megadta a jó választ.
- A hozzászóláshoz be kell jelentkezni
A homályban ember nyúl most bele, majd lesz egy script, mondjuk az inittab -ból (ha kell újraépíti). De most nincs már ott senki, úgyhogy folyt köv holnap.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Köszönöm!
Ez volt a megoldás:
"az ssh szerveren még be kell állítani a GatewayPorts opciót, illetve az -R parancssori kapcsolónál még bind-olt interface-nek meg kell adni a *-ot:
-R '*':29999:localhost:10080"
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Szépen működik, de ha leállítom (a kezdeményező gépen - ahol kiadom a parancsot) akkor a távoli hoston nem állnak le a tunnelek, legalábbis nem azonnal.
A parancs(ok) így néznek ki:
$ssh -nNTv -R ip:port:localhost:port user@host
ä parancs eredményeként, a host ip:port -ján megjelenik a localhost:port. Ha ezt a localhoston leállítod (^c) akkor a host -on (ps axu Äó| grep ssh) a tunnelek tovább "működnek", viszont ha a localhoston újra kiadod a parancsot akkor elindulnak, de a debug -ban jelzi, hogy nem sikerül a tunnel címen "figyelni" (listen).
Mi kellhet ahhoz hogy a host tunnelek leálljanak ha a localhost -on leállítom a tunnelt?
Környezet: Van egy busybox httpd (localhost:http_port) szerver és egy ffserver (localhost:flv_port). Vagyis két tunnelt kell alkalmaznom, az egyiken a http kommunikáció zajlik, a másikon az flv stream továbbtás ("élő" kamera kép). Ha, miután a tunneleket felállítom, elindítok egy másik gépen egy böngészőt akkor szépen működik (a kamera képet a flowplayer flashplayer jeleníti meg), viszont ha mondjuk félórára magára hagyod (leállított böngészővel) akkor nem áll össze. Ha a localhost -on újraindítom a tunneleket akkor a hoston, a lezáratlan tunnelek nem hagyják újra építeni a kapcsolatot.
Még vizsgálom, lehet hogy csak a stream tunnel hal le és akkor az ffserver tájékán kell kutatni.
szerk.
A tunnelek halnak meg :(
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
-o ServerAliveInterval=30
Valszeg van a két vég között valami NAT, ahol a conntrack entry-k mondjuk 120 másodperc inaktivitás után elpukkannak. Amikor ^C-vel kinyomod a helyi processzt, a FIN a NAT-oló cuccon nem talál élő bejegyzést, így megy a kukába. Ha a távoli TCP vég nem lát forgalmat, az számára csak annyi, hogy nem küldtek neki semmit. Ezért az ottani daemon vígan futni fog (és természetesen a port foglalt lesz).
http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_t…
A fenti kapcsolóval elérheted, hogy a conntrack entry-k fél percenként frissüljenek.
Ha tényleg hálózati probléma keletkezik, és a kliens a fenti kapcsoló hatására kilép valamennyi idő után, attól a szerver még ugyanúgy fog viselkedni, ahogy most is. Ehhez lásd: ClientAliveInterval. Valószínűleg ezt volna érdemes beállítanod (a szervernél), mert a conntrack entry-t ugyanúgy életben tartja, és ha a hálózat valóban lerohad, akkor a szervert kell felmosni, nem a klienst (azt amúgy is lenyomod kézzel).
A probléma egyébként tipikus bármilyen hálózatban, ahol NAT vagy conntrack csomagszűrő van; túlméretezett vállalati belső hálón is láttam.
- A hozzászóláshoz be kell jelentkezni
Rákerestem erre az opcióra. Érdekes mert nem találtam a man -ban, sem az sshd sem az sshd_conf relációban. Rákerestem a googleban az első cik amit kidobott, piont erről a szituációról szolt és ott is ezt az opciót említi és a ServerAliveCountMax -ot. A cikk 2006 -os így ez biztos, hogy nem a verziómban van a hiba (Debian Lenny a kliensek Debian Squeeze). Hol találtad ezt az opciót deklarálva?
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
ssh_config(5) és sshd_config(5) man-ok
- A hozzászóláshoz be kell jelentkezni
Jogos! Csak most akkor összezavarodtam. Mivel én végig úgy értettem, hogy a szervert kell piszkálni, ezért az sshd_conf -ban keresgéltem az ServerAliveInterval -t, pedig az az ssh_conf -ban , azaz a kliens oldali konfigurációban van. Most akkor kliens ssh konfigurációját kéne finomítanom?
OFF: Más oldalról, kliensből akár száz is lehet. A sok kliens egyidejű tunnelezését, nem lehet és nem is kell fenntartani. Kell valami más, jelző mechanizmus ami kezdeményezi ezt a kapcsolatot, és csak annyit enged egyidejűleg amennyit lehet vagy ésszerű. Kezdeményezni azonban a kliensnek kell, mert a szerver nem éri el őket a NAS%/MASQUERADE miatt.
Ráadásul, az ffmpeg/ffserver - flv - flowplayer kombó vonatkozásában jobb lenne nyílt, nem titkosított csatornát alkalmazni - gyorsabb (gondolom). Vajon mi képes, hasonló módon "reverse" csatornát létrehozni - netcat proxy (ssh remote paranccsal felállítva)?
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Ahogy fentebb írtam, feltehetőleg a szerveroldali ClientAliveInterval beállítás volna a leghasznosabb.
- A hozzászóláshoz be kell jelentkezni
Na még mindig zavaros, kit nevezünk itt szervernek? Azt a gépet amelyik a reverse tunnel -t kéri/indítja vagy azt aki ezt a kérést kiszolgálja?
Mindenesetre, úgy tűnik a tunnelt igénylő gépen a a parancsba beillesztettem az opciót és nem esik szét :)
A parancs most így fest:
ssh -nNTv -o ServerAliveInterval=30 -R remoteIP:remotePORT:localhost:port remoteIP
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Subscribe
- A hozzászóláshoz be kell jelentkezni
subscribe
- A hozzászóláshoz be kell jelentkezni
Felmerült még egy kérdés. Az látszik a "ps axu" kimenetéből, hogy vannak ssh kapcsolatok, de mégis a fogadó/host gépen, hogy lehetne pontosan megnézni honnan (értsd milyen IP címről) melyik portra megy a kapcsolat. Valami ötlet?
Az lenne a szép, ha kilehetne hozni egy olyan kimenetet, hogy erről az ip címről portró, arra az IP címre portra, kapcsolódnak.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
iptraf
- A hozzászóláshoz be kell jelentkezni
#netstat -npt
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
ss
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Van egy ilyen szituáció:
gép1 - GW1 - gép2 - GW2 - szerver:666
- "gép1" és "gép2" között megy az ssh.
- A "telnet szerver 666" megy gép2-ből.
- Azt szeretném, hogy a "telnet gép2 666" a gép1-ből ugyanígy menjen.
- szerver:666-ot nem ismerjük, nem tudunk bele ssh-zni, nem linux és nem férünk hozzá belülről.
Lehet ilyet?
Ez nem oldja meg:
ssh -L 666:szerver:666 root@gép2
Próbálkoztam még iptables-szel port forward-dolni, de az szerintem azért nem megy, mert nem a gép2 a GW (és ezt nem is tudom a szerver-ben változtatni)
Üdv,
taarzaan
- A hozzászóláshoz be kell jelentkezni
"Próbálkoztam még iptables-szel port forward-dolni, de az szerintem azért nem megy, mert nem a gép2 a GW (és ezt nem is tudom a szerver-ben változtatni)"
A connected hálózathoz nem kell gateway, így ha a gép2-n a szerver felé néző interfészen source natolsz (SNAT v. MASQUERADE), úgy vissza fog találni a válaszcsomag.
- A hozzászóláshoz be kell jelentkezni
Köszi a segítséget, de az iptables lelki világa nekem túl bonyolult volt... el is vesztem benne egy időre...
...viszont az ssh tunnel végül megoldást jelentett:
root@gép2:~# ssh -gL 666:szerver:666 -l root 10.12.6.41
Így gép1 látja a szerver 666-os portját gép2 666-os portján.
- A hozzászóláshoz be kell jelentkezni
Már megint azok a fránya alagutak ...
Van két kis hálózat a neten - az egyik az enyém a másikat felügyelném.
Mindkét hálózat egy-egy routerrel kezdődik (WR1043ND)és mindkettőben van egy kis Linux szerver (samba, apache/squirrelamil stb.) ami elérek ssh -val - azaz mindkettőn fut ssh szerver.
Szeretném elérni a router felügyeleti felületét, amihez ssh tunnelt gondoltam használni.
Most már teljesen összezavarodtam a verziókban ...
Egyáltalán meg lehet ezt oldani ssh tunnellel és most ez -R vagy -L ?
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Megoldva.
Még a téma elején megkaptam a kész választ - csak kicsit kell rajta igazítani.
ssh -gL 20080:localhost:10080 -l tovis -p 20022 tovis-lab.dyndns.be
ssh {-v} -gL 8080:routerIP:80 -p 20022 tovis-lab.dyndns.be
Így a saját (belső) szerveremen a 8080 -as porton ott van a WEB -es admin felület.
* Én egy indián vagyok. Minden indián hazudik.
- A hozzászóláshoz be kell jelentkezni
Subscribe
- A hozzászóláshoz be kell jelentkezni