OpenWrt ssh alagút

Hálózatok általános

Adva van két router (WR1043ND). Az egyik otthon a "laboromban" nyócker. A másik vidéken a "víkend házamban" Nógrád. Sajnos az utóbbi egy NAT mögött csücsül, így nem tudom elérni sehonnan :( A legkézenfekvőbb megoldásnak az ssh tunnel ígérkezett, de elakadtam. A jelszó nélküli login -t megoldottam - publikus kulcsokkal - működik :)
Viszont a "reverse" alagút sehogy sem áll össze: 


$ssh -NT -R 10022:127.0.0.1:10023 lab.vlmi.org -p 10022 -i .ssh/id_rsa

Azaz szeretném ha a (vidéki) router ssh portja (10022) "megjelenne" a Pesti router 10023 -as portján.
Az eredmény mindig ugyanaz:
dropbear[2857]: Child connection from x.y.z.v:nnnnn
dropbear[2857]: Pubkey auth succeded for 'tovis' with key md5 ...
dropbear[2857]: TCP forward failed: Error listening: Address already in use

Most milyen cím is van használatban? A 127.0.0.1 szerintem a localhost, a 10023 -as port tutira nincs használatban. Az OpenWrt wiki -ben írnak arról hogy a "GatewayPorts" opciónak be kell lennie kapcsolva - be van.
Nincs valami tippetek?
Jelenleg még a "laborban" az asztalon szimulálom a feltételeket. Van ugye a "lab" routerem ami most éppen az internetet szolgáltatja nekem. A mögötte lévő lanon csücsül egy kis ócskavas, amiben van két hálókártya, engedélyezve az "ip_forward" és az iptables -ban beállítva a teljes kiforgatás és nat - ő a "szolgáltatót" pótolja.
Egyébként, az OpenWrt tartalmaz egy sshtunnel csomagot, de mielőtt ezzel kezdenék kínlódni, szerintem ennek parancssorból is kellene működnie - egyébként is kicsit zavaros a leírás.

  • 5643 megtekintés

( mazsi v | 2015. 10. 02., p – 01:45 )

forditva a ket portot:

$ssh -NT -R 10023:127.0.0.1:10022 lab.vlmi.org -p 10022 -i .ssh/id_rsa

szerk: ha az egesz internetrol el akarod erni a nogradi szervert a pesti 10023-as portjan, akkor kell meg egy kettospont:

$ssh -NT -R :10023:127.0.0.1:10022 lab.vlmi.org -p 10022 -i .ssh/id_rsa

es a pesti szerveren az sshd/dropbear configjaban megfeleloen beallitani a GatewayPorts-ot.

A másik "opcionális szebbítés" is fontos lehet: az ssh kliens a szerver neve utáni dolgokat hajlamos bizonyos esetekben a szerveren "futtatni", parancsként értelmezni, így érdemes a szervert rakni az utolsó opciónak!

csak localhost-ra:
$ssh -NT -R 10023:127.0.0.1:10022 -i .ssh/id_rsa -p 10022 lab.vlmi.org

teljes internetre:
$ssh -NT -R :10023:127.0.0.1:10022 -i .ssh/id_rsa -p 10022 lab.vlmi.org
vagy ezt így is lehet írni:
$ssh -NT -R 0.0.0.0:10023:127.0.0.1:10022 -i .ssh/id_rsa -p 10022 lab.vlmi.org

Az "N" és a "T" opció ezért kerül be.
N - Don't run a remote command
T - Don't allocate a pty
Később beteszem az "f" opciót is - "run in background after auth".
Egyébként ha előre veszem az "R" opciót, akkor az "NT" opcióra panaszkodik - kicsit leegyszerűsítették az opciók értelmezésének a kódját :)

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

Köszönöm szépen! Ez a megoldás!
Újra olvasom a leírást, ssh/dropbear:

Dropbear client v2011.54
Usage: ssh [options] [user@]host[/port] [command]
Options are:
...
-R <[enaddress:]listenport:remotehost:remoteport> Remote port forwarding
...

Ebből hogy jön ki az amit, megadtál és MŰKÖDIK?
Mi a különbség, ha a help szerint elhagyom a (jelen esetben) localhost címet, és ha a port elé kiteszem a ":"?
A működő parancs, szerintem nem stimmel a help -ben megadottal!?
Így a legfontosabb az, hogy erre hogy jöttél rá?
Ami még homályos, az a "keepalive" opció, az elnevezés azt sugallná, hogy így biztosíthatom, hogy a kapcsolat fennmaradjon ha a kapcsolat megszakad, majd újra létrejön. A "dokumentáció" szerint ez "csak" a megadott időnként, amolyan "életjel" csomagokat küldözget. Amennyire tudom maga a tcp protokoll is csinál effélét - ettől is "kapcsolat orientált" - azaz jelzi ha a másik oldallal a kapcsolat megszakad.
Most akkor mire jó ez a "keepalive" opció?
Egyébként, megnéztem mit is tartalmaz az OpenWrt "sshtunnel" csomag. Gyakorlatilag egy alap konfigurációs fájl, egy indító szkript, illetve egy luci beállító szkript - WEB -es felületről kezelhető :) Azt hiszem kifogom próbálni.

OFF: Számomra amúgy is roppant zavarba ejtő a local és a remote értelmezése és parancssori alkalmazása az ssh tunnel felállításakor. OpenSSH -val ez gond nélkül működött.
Egyébként, zseniálisnak tartom és áldassék neve annak aki kitalálta!
Az előző, ehhez kapcsolódó topicomban valaki említette, hogy miért nem vpn -t építek. Nem igazán érzem szükségét - a távoli ponton nem egy fájl szerver fog állni, hanem egy rpi kamerával, hő/légnyomás/pára érzékelővel és ami még "jól jöhet" később. Vagyis onnan kell az ssh és a http port elérhetőség.

* Én egy indián vagyok. Minden indián hazudik.
[/]

az openssh manualjaban nezd meg a -R listenaddress jelenteset, ott szerintem jol le van irva.

ugy jottem ra, hogy szoktam hasznalni a -R-t :) (mondjuk openssh-val, az le sem esett, hogy te a dropbear klienset hasznalod, jo, hogy kompatibilisre csinaltak a -R opciot).

a TCP csinalhat keepalive-ot, de nem feltetlenul csinal, ezert szokott lenni magasabb protokol szinen is erre opcio (ssh, openvpn).

es tenyleg tok jo a port forwarding. :) hasznos szokott meg lenni a SOCKS proxy (-D kapcsolo).

ha egyszer elkezdesz VPN-nel jatszani, akkor nezd majd meg az ssh -w kapcsolojat is.

( Nyosigomboc v | 2015. 10. 03., szo – 00:20 )

Amikor ilyesmivel jatszottam, az ssh-t egy vegtelen ciklusban futtattam, es egy rovid sleep utan ujra probalkozott a kapcsolat kiepitesevel. Altalaban egyebkent az a szabaly, hogy ha halozati programot irsz, akkor fel kell keszulnod a kapcsolat megszakadasara, es ez is hasonlo pelda. Nem csak a keepalive hianya miatt szakadhat meg a kapcsolat, hanem mas okokbol is.

--
Hi, welcome to Fight Club.
First of all, how did you hear about us?

"..., hanem mas okokbol is." - így igaz.
Viszont csak arra tudsz felkészülni, amit előre látsz, és egyáltalán védhető/kezelhető - ha leég a berendezés akkor talán a 100% meleg/hideg tartalék, mai kicsit túlméretezett lenne az adott feladathoz.

Jobban át kell nézzem az OpenWrt "sshtunnel" csomagját, nyújt-e valamit azonkívül, hogy (elég nyakatekerten) lehetőséget nyújt az ssh tunnel(ek) konfigurálására WEB -es felületen (mondjuk akkor nem szaladok bele a hibába, viszont nem is tanulok belőle ...).

Hasonló esetben, az volt a megoldás, hogy cron -ból futtattam egy scriptet (ami belül dinamikusan szabályozta milyen sűrűn is fusson le teljesen) ami ellenőrizte, a tunnel(ek) működését (fut-e az ssh megfelelő példánya process id alapján). Ha nem akkor újraindította a tunnel(eket). Gond, hogy itt még úgy tűnik, ha nincs kapcsolat akkor nem lép ki az ssh processz. Ki kell találnom mi alapján tudom eldönteni, hogy a tunnel működik-e (a "szerver" egyszerű pingelésével azt is eldönthetem, hogy van-e kapcsolat egyáltalán, egy vezérelt relés egységgel újraindíthatom akár magát a routert is).
Mire kellene még felkészülnöm és hogyan szerinted?

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

Érdekes! - ezzel még nem is találkoztam.
Ha jól értem ez arra jó, hogy ellenőrizze az ssh kapcsolat meglétét, egy másik port pár segítségével? Nem mennyire tudom ezt használni.
(Ha csak pusztán a kapcsolat működését/meglétét akarom ellenőrizni, lehet elég ha a kliensről a távoli szerverre kitett porton át küldök egy parancsot ssh segítségével - mondjuk lekérem a pontos időt.)

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

( tovis v | 2016. 01. 19., k – 13:57 )

Felelevenítem a témát :)
A tunnel működik - teszt körülmények között az asztalon.
Kérdések:
Hogy a távoli (a tunnelt "beindító") eszközön (router) tudok meggyőződni arról hogy a tunnel él? - ha nem akkor újra kell indítani.
A tunnel automatikus indítása sokféle képpen lehetséges. Most épp arra hajlok, hogy a felhasználói crontab -ból indítom (van busybox crond applet). Viszont ehhez mindenképpen kellene valami amivel meggyőződhetek a tunnel állapotáról. Ötlet?
Az is járható út, úgy is lesz a router mögött egy eszköz (most a terv egy RPI),az is tesztelheti a tunnelt, vagy a "host" oldalon a "host" routeren túl is van eszköz (a házi szerverem) ő is tesztelheti, de a legszebb mégis az lenne ha a két router egymásközt elintézné a dolgot.

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

Sikerült a "keep alive" -ot beállítanom, így 5 percenként (-K 300) küld egy csomagot, hogy fenntartsa a kapcsolatot.
Szerintem a "nem kilépéssel" azaz, ha a tunnel nem meg el a "háttérbe" mint daemon fenntartja az ash -t, azaz feleslegesen foglalja a memóriát, folyamatosan. A routerben csak 32M RAM -van, az otthoni (nagyobb alapterheltségű) jelen pillanatban 11M RAM marad "szabadon".
Egy próbát megér.

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

OpenWrt szerint elavult nem karbantartott?
Amit láttam belőle, az nem foglalkozik a kapcsolat meglétével. Beállítja azokat illetve ad egy felületet a WEB -es beállításhoz. A WEB -es felületet nemigen használom, általában lekapcsolom - memória spórolásból.

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

Hogy mennyire elavult, vagy nem karbantartott (vagy csak az openwrtben nem az) azt passzolnám, emlékeim szerint egy kőegyszerű kis wrapper volt (nem túl meglepő módon, mert egy alap működést fentebb xclusiv mutatott kb 3 sorban, csak minek, ha valaki megcsinálta már normálisan, gyanítom még karbantartatlanul is jobb, mint egy shell script amit nem értesz.)

És nem tudom mit néztél, de pontosan arra való, amit te szeretnél: "autossh is a program to start a copy of ssh and monitor it, restarting it as necessary should it die or stop passing traffic".

De egyébként az openwrt wiki egy sshtunnel nevű hasonló packaget ajálngat még (mondjuk annak kell az openssh, nem biztos, hogy azt annyira akarod)

Nem ismerem.
Képes egy NAT eszköz mögül kapcsolódni?
Mit kínál a kapcsolat megszakadása esetén?
Kapok valami jelzést a távoli oldalon, hogy mondjuk egy vezérelt relével ki/be kapcsoljam a kábel modemet és újraindítsam a routert?
(mondjuk a kapcsolat meglétére az is megoldás ha a google -t pingelem és ha nem kapok választ akkor elindítom a mechanizmust)
Hogyan illeszti a távoli, NAT mögötti rendszert?
Az ssh tunnel kipróbált dolog. Az otthoni, a netről látható címemre tudok úgy "forwardolni" hogy azt bárhol a netről szintén lássam.
Több kérdést vet fel mint amennyit megold?

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

Képes egy NAT eszköz mögül kapcsolódni? -Igen.
Mit kínál a kapcsolat megszakadása esetén? -Azt, hogy megpróbál újracsatlakozni, ha jól rémlik scriptet is tud futtatni sikerese és sikertelen kapcsolódásnál is.
Kapok valami jelzést a távoli oldalon, hogy mondjuk egy vezérelt relével ki/be kapcsoljam a kábel modemet és újraindítsam a routert? - Igen, down-ba lesz a VPN interfésze, a 1043ND-be lehet kapcsolgatni az usb tápját GPIOn keresztül, szóval bármit vezérelhetsz.
Hogyan illeszti a távoli, NAT mögötti rendszert? Mint egy alhálózatot, így minden portot forwardol a cél ip felé, nem úgy mint a tunnel.
Több kérdést vet fel mint amennyit megold? -Az én meglátásom szerint megoldás a problémádra, az ssh tunnel is jó dolog, de azt meg kell hozzá faragnod, ez meg készen van "csak" meg kell ismerni.

--------------------
http://grant-it.com/

Megfontolandó alternatíva és mindenképp előre mutató, bár kicsit homályos "minden portot forwardol a cél IP felé" - biztonsági szempontból kockázatosabbnak tűnik, mint egy-egy port célirányos forgatása.
Mivel a routerben csak 32M RAM -om van nem tudom mennyire képes ezt működtetni.
Jobban át kell gondolnom.

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

Az OpenVPN egy tunnel-t (csatornát) hoz létre, és abban megy minden forgalom.
Tehát aki csatlakozik OpenVPN klienssel, aki "belelát" a tunnel-be, csak az fér hozzá a tartalomhoz, így biztonságos(nak mondható).
Való igaz, hogy a két oldalt előre be kell állítani (PKI!), de az OpenVPN kliens át tud jutni NAT-on is (akár többön is!), csak az OpenVPN szerveroldalnak kell közvetlenül elérhetőnek lennie (ehhez viszont elég egyetlen tcp-portforward!).
Az ssh-portforward, különösen akkor, ha nem csak a localhost-ra készít portot, akkor akár internet felől is elérhető, ez már inkább biztonsági kockázat! (De ez kiküszöbölhető megfelelő beállítással, persze!)

Ha folyamatos kapcsolat a cél, mindenképpen a VPN a stabilabb, robusztusabb, az ssh-portforward inkább időnkénti kapcsolódásra való.

Még nem találtam róla leírást, hogy is lehet "nobody" -ként futtatni valamit. Eddig ezzel csak az OpenWrt -nél találkoztam a dnsmasq -t futtatja így.
Az ssh tunnelhez felállítottam a magam felhasználóját, annak profiljában vannak az ssh kulcsok, a jelszó nélküli kapcsolódáshoz.
Hogy lehet nobody -ként futtatni valamit OpenWrt alatt?

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

Még nem tartok ott az openvpn "tanulmányozásában", hogy értelmes kérdéseket tudjak feltenni. Mi az hogy "új route-ot hozzáadni"?
Több LAN hálózat egyesítéséről van szó, vagy a (két) különböző lanon csücsülő eszközöket, külön-külön hozzá kell adni?

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

A "push route" azért kell, hogy a másik hálózatról tallózhassuk (browse) a klienseket?
Alapvetően úgy gondoltam, hogy elég ha a router tud róla hogy ha az x hálózatból, az y hálózaton lévő kliensre hivatkozunk (címezzük) akkor a csomagokat oda irányítja.
Persze ehhez az x hálózaton ülő kliensnek tudnia kell, hogy az y hálózaton van egy olyan című kliens.
Általában kis hálózatokkal dolgozok - legfeljebb egy tucat gép egy-egy hálóban/szegmensben.

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

Ha jól rémlik a push route-al a vpn kliensnek mondod meg, hogy milyen háló van vpn szerver mögött.
a sima route és iroute-al a szervernek mondod meg, hogy milyen háló van a kliens mögött.
Azt hiszem valahogy így kell elképzelni:
A háló <-> VPN szerver <-> VPN kliens <-> B háló.

--------------------
http://grant-it.com/

( tovis v | 2016. 01. 21., cs – 14:53 )

Nemigazán ide tartozik :(
Jelenleg három db WR1043ND van a kezemben. Szeretném "asztalon" kipróbálni az openvpn lehetőségeket. A háromból 2 ver:1.8 és egy ver:1.4 ráadásul az egyik 1.8 -as a műhelyemet/lakásomat látja el.
Mindhárom konfigurációját - flash-ét lementettem. Rátöltöttem a műhely konfigurációját az 1.4 -re és kicseréltem.
A LAN, WAN beállítások úgy tűnik rendben vannak - az asztali gépek látják a netet. Viszont, a WiFi interfész "duplikálódott"?
[quota]
Generic 802.11.bgn Wireless Controller (radio0)
Generic 802.11.bgn Wireless Controller (radio1)
[/quota]
Némi kattintgatás után, a "radio1" sikerült életre lehelni, a "radio0" -t nem tudtam engedélyezni és a helyes konfiguráció ott volt - így újra fel kellett paraméterezni ssid, cypher, password stb.
Ráadásul, a "régi"(?) radio0 -át törölni sem tudom :(
Lehet ez a MAC address miatt?
Azt nem hiszem, hogy ekkora váltás lenne a két verzió között ...

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