port forward? ssh tunnel?

 ( tovis | 2011. március 25., péntek - 22:14 )

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

-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?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szia.

ssh -gL 20080:localhost:10080 -l tovis -p 20022 tovis-lab.dyndns.be

Üdv: Zoli

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.

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

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:10080

Ennek 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 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.

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.

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.

-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_termination

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.

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.

ssh_config(5) és sshd_config(5) man-ok

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.

Ahogy fentebb írtam, feltehetőleg a szerveroldali ClientAliveInterval beállítás volna a leghasznosabb.

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.

Subscribe

subscribe

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.

iptraf

#netstat -npt

* Én egy indián vagyok. Minden indián hazudik.

ss

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

"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.

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.

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.

Megoldva.
Még a téma elején megkaptam a kész választ - csak kicsit kell rajta igazítani.

Idézet:
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.

Subscribe