Hozzászólások
-
SzerzőBejegyzés
-
Itt szerintem több dolog keveredik. (Ha valamit félreértettem, elnézést.)
birno wrote:A tűzfal szabályokat most egy az egyben a router hozza létre, az én scriptemet direkt kiiktattam, nehogy azzal legyen a para, tehát tételezzük fel, hogy az ssh-nak mindhárom helyen szerepelnie kell, az első kettőnél logikus is, egyedül a postroutingnál nem értem 100%-ig, hogy mi a szerepe, bár talán csak annyi, hogy minden forgalomnak át kell mennie a routeren.
Gondlom, ez meg is csinál minden olyat, hogy a router a WAN és a LAN között elvégezze a feladatát. Olyasmi ez, mint az én esetemben a shorewall volt. A gond akkor van, amikor a WAN és a LAN között történik valami. Azaz, ez a generált iptables beállítás (véletlenül, vagy esetleg éppen szándékosan) nem támogatja azt, hogy a belső rendszer „piszkálódjon”. Nincs erről valami a Tomato doksijában?birno wrote:A routeren futó proxy az srelay, amit ezen paranccsal indítok el automatikusan minden router rebootkor: „/jffs/srelay -i :80 -a p”.
Annyit takar, hogy a 80-as porton figyeljen és csak authentikációval lehessen használni.
Ha jól értem kérdésed kívülről küldök bele valamit elsődlegesen, mivel maga az ssh kapcsolat is ezen keresztül jön létre a munkahelyemről a router felé.
A proxy ténylegesen a router és az azon futó tűzfal 80-as portjába kapaszkodik, ezért pl. nem is lehet http-n keresztül elérni a router felületét, belső hálóról sem.Ha jól értelek, a proxy működése mégis elkettyint valamit, ami nem 80-as port…
birno wrote:Különben szerény tudásom alapján én a NAt-nál tippelek valami galibára, mert amint a tcpdump logok alapján is látszódik, amikor a gépemen futó dante proxy-t használom, akkor a külső IP-n a 22-es portra érkező kapcsolat kezdeményezőjének a gépem belső hálós IP-jét látja, ezt a kérést továbbítja a router belső IP-jére és az kezdeményezi a kapcsolatot a gépem belső IP-jén keresztül a 22-es portra.Ez eddig a jól működő port forward.
birno wrote:Azonban amikor a routeren futó proxyn keresztül megy, akkor a külső IP-ről érkezik a kapcsolat kezdeményezése, a még szintén külső IP-vel címzett 22-es portra és itt nem csinálja meg azt, hogy ezt a kérést átdobja a router belső IP-jére és onnan menjen egy kezdeményezés a gépem felé, hanem újra a külső IP-vel indul egy „ack”-t kérő a kapcsolat, immár a 22-es portról s mivel a routeren ténylegesen nem fut ssh a 22-es porton, így elutasítja a kapcsolatot.1.) az ssh miért meg a proxyn keresztül, ha semmi köze hozzá?
2.) mi köze van a 80-as porton lógó proxynak mindehhez?birno wrote:Szerintem ez lehet az oka, csak nem tudom miért nem NAT-ol olyankor, mert itt jön a képbe az, hogy source-nek nincs megadva semmi a tűzfal szabályaiban, tehát bárhonnan mennie kellene a NAT-nak.Nem. amikor a routerben belül vagy, akkor ott nincs NAT!!! NAT csak a WAN és LAN kapcsolatában van. Amikor „benne vagy”, akkor két hálókártyád van, és pont. Ez az, amit feljebb írtam, hogy a shorewallnál volt a fw source/destination, ami pontosan ez a hely volt, azaz nálad a router „belseje”.
A routerben belül futtatnék egy sshd-t (azt hiszem, időnként megteszed), de valami egészen más porton! Hogy jól szétváljanak a dolgok, és egyszerre mindkettőre, azaz a routerbe is, meg a gépedbe is bemehessél.
Itt szerintem több dolog keveredik. (Ha valamit félreértettem, elnézést.)
birno wrote:A tűzfal szabályokat most egy az egyben a router hozza létre, az én scriptemet direkt kiiktattam, nehogy azzal legyen a para, tehát tételezzük fel, hogy az ssh-nak mindhárom helyen szerepelnie kell, az első kettőnél logikus is, egyedül a postroutingnál nem értem 100%-ig, hogy mi a szerepe, bár talán csak annyi, hogy minden forgalomnak át kell mennie a routeren.
Gondlom, ez meg is csinál minden olyat, hogy a router a WAN és a LAN között elvégezze a feladatát. Olyasmi ez, mint az én esetemben a shorewall volt. A gond akkor van, amikor a WAN és a LAN között történik valami. Azaz, ez a generált iptables beállítás (véletlenül, vagy esetleg éppen szándékosan) nem támogatja azt, hogy a belső rendszer „piszkálódjon”. Nincs erről valami a Tomato doksijában?birno wrote:A routeren futó proxy az srelay, amit ezen paranccsal indítok el automatikusan minden router rebootkor: „/jffs/srelay -i :80 -a p”.
Annyit takar, hogy a 80-as porton figyeljen és csak authentikációval lehessen használni.
Ha jól értem kérdésed kívülről küldök bele valamit elsődlegesen, mivel maga az ssh kapcsolat is ezen keresztül jön létre a munkahelyemről a router felé.
A proxy ténylegesen a router és az azon futó tűzfal 80-as portjába kapaszkodik, ezért pl. nem is lehet http-n keresztül elérni a router felületét, belső hálóról sem.Ha jól értelek, a proxy működése mégis elkettyint valamit, ami nem 80-as port…
birno wrote:Különben szerény tudásom alapján én a NAt-nál tippelek valami galibára, mert amint a tcpdump logok alapján is látszódik, amikor a gépemen futó dante proxy-t használom, akkor a külső IP-n a 22-es portra érkező kapcsolat kezdeményezőjének a gépem belső hálós IP-jét látja, ezt a kérést továbbítja a router belső IP-jére és az kezdeményezi a kapcsolatot a gépem belső IP-jén keresztül a 22-es portra.Ez eddig a jól működő port forward.
birno wrote:Azonban amikor a routeren futó proxyn keresztül megy, akkor a külső IP-ről érkezik a kapcsolat kezdeményezése, a még szintén külső IP-vel címzett 22-es portra és itt nem csinálja meg azt, hogy ezt a kérést átdobja a router belső IP-jére és onnan menjen egy kezdeményezés a gépem felé, hanem újra a külső IP-vel indul egy „ack”-t kérő a kapcsolat, immár a 22-es portról s mivel a routeren ténylegesen nem fut ssh a 22-es porton, így elutasítja a kapcsolatot.1.) az ssh miért meg a proxyn keresztül, ha semmi köze hozzá?
2.) mi köze van a 80-as porton lógó proxynak mindehhez?birno wrote:Szerintem ez lehet az oka, csak nem tudom miért nem NAT-ol olyankor, mert itt jön a képbe az, hogy source-nek nincs megadva semmi a tűzfal szabályaiban, tehát bárhonnan mennie kellene a NAT-nak.Nem. amikor a routerben belül vagy, akkor ott nincs NAT!!! NAT csak a WAN és LAN kapcsolatában van. Amikor „benne vagy”, akkor két hálókártyád van, és pont. Ez az, amit feljebb írtam, hogy a shorewallnál volt a fw source/destination, ami pontosan ez a hely volt, azaz nálad a router „belseje”.
A routerben belül futtatnék egy sshd-t (azt hiszem, időnként megteszed), de valami egészen más porton! Hogy jól szétváljanak a dolgok, és egyszerre mindkettőre, azaz a routerbe is, meg a gépedbe is bemehessél.
lacix wrote:Nem értem, hogy az miért lenne jó, a jmicron-ra van kötve a vinyója.Ha jól értettem a bug-os bejegyzést, nem magát a kontrollert, hanem annak az AHCI funkcióját tiltják. (Gondolom, akkor „nativan” kezeli a rendszer a kontrollert)
Egyébként egy ötlet, ez az én alaplapomnál + a Promise IDE (raid)kontrollernél kell a BIOS-ban: ez a PnP OS YES beállítása: enélkül, bár lefut a promise BIOSa, de nem jelzi ki a driveokat, amik rajta lógnak!
lacix wrote:Nem értem, hogy az miért lenne jó, a jmicron-ra van kötve a vinyója.Ha jól értettem a bug-os bejegyzést, nem magát a kontrollert, hanem annak az AHCI funkcióját tiltják. (Gondolom, akkor „nativan” kezeli a rendszer a kontrollert)
Egyébként egy ötlet, ez az én alaplapomnál + a Promise IDE (raid)kontrollernél kell a BIOS-ban: ez a PnP OS YES beállítása: enélkül, bár lefut a promise BIOSa, de nem jelzi ki a driveokat, amik rajta lógnak!
Az a gondom, hogy – ahogy előbb implicite bevallottam a shorewall emlegetésével – iptables parancsokkal direktben nem dolgoztam. A shorewall is elég régen volt. Tapasztalt haver azért ajánlotta azt nekem, mert ott gyorsan kellett a megoldás, és a shorewallban a szabály megfogalmazása az én szemléletem szerinti. (Egyébként a shorewall is iptables parancsokat generál, ráadásul előtte ellenőriz ellentmondásokra) Így konkrétan nem látom sajnos a hibát sem az iptables outputjában. Viszont kérdezek…
Az ssh, mint port, három láncban is szerepel, a wanin-ben a megfelelő helyre mutatva, a PREROUTINGban és a POSTROUTINGban is. Jó ez? Meg rengeteg az any, anywhere. Itt is gyanakszom arra, amit „körbeforgásnak” neveztél.
Mit jelent részetesen az, hogy „a routeren futó proxy-t használom” ? Elindítod csak? Vagy beleküldesz valamit? És honnan? Kívülről, vagy ssh-val a routeren belülről?
(Egyébként a shorewallnál volt egy „érdekes” source/target is, amit az előzőekben neked localhostnak neveztem, ez a fw (firewall) A te proxyd tulajdonképpen ennek a portjaira kapaszkodik, ha jól értem a dolgokat)Az a gondom, hogy – ahogy előbb implicite bevallottam a shorewall emlegetésével – iptables parancsokkal direktben nem dolgoztam. A shorewall is elég régen volt. Tapasztalt haver azért ajánlotta azt nekem, mert ott gyorsan kellett a megoldás, és a shorewallban a szabály megfogalmazása az én szemléletem szerinti. (Egyébként a shorewall is iptables parancsokat generál, ráadásul előtte ellenőriz ellentmondásokra) Így konkrétan nem látom sajnos a hibát sem az iptables outputjában. Viszont kérdezek…
Az ssh, mint port, három láncban is szerepel, a wanin-ben a megfelelő helyre mutatva, a PREROUTINGban és a POSTROUTINGban is. Jó ez? Meg rengeteg az any, anywhere. Itt is gyanakszom arra, amit „körbeforgásnak” neveztél.
Mit jelent részetesen az, hogy „a routeren futó proxy-t használom” ? Elindítod csak? Vagy beleküldesz valamit? És honnan? Kívülről, vagy ssh-val a routeren belülről?
(Egyébként a shorewallnál volt egy „érdekes” source/target is, amit az előzőekben neked localhostnak neveztem, ez a fw (firewall) A te proxyd tulajdonképpen ennek a portjaira kapaszkodik, ha jól értem a dolgokat)Most fáradt vagyok, bocs, értelmes ötletem épp nincs a megoldásra, (az iptablest majd megnézem), a socks-ot nem ismerem. Viszont nézd meg esetleg, mely portok „foglaltak”, tehát
netstat -an | grep -i listen
(esetleg a proxy indítása előtt is, meg utána is)
nem lepődnék meg, ha azok, amikkel baj van, ott lennének.Most fáradt vagyok, bocs, értelmes ötletem épp nincs a megoldásra, (az iptablest majd megnézem), a socks-ot nem ismerem. Viszont nézd meg esetleg, mely portok „foglaltak”, tehát
netstat -an | grep -i listen
(esetleg a proxy indítása előtt is, meg utána is)
nem lepődnék meg, ha azok, amikkel baj van, ott lennének.Felsoroltam dolgokat, mert konkrét a szemléletem. Az (absztrakt) MINDEN -re nem gondoltam.
Azért bízom benne, hogy nem csak én vagyok ilyen „egyszerű lélek”. (Elrejtettél valami statisztikaletárolót legalább benne? ;D)Felsoroltam dolgokat, mert konkrét a szemléletem. Az (absztrakt) MINDEN -re nem gondoltam.
Azért bízom benne, hogy nem csak én vagyok ilyen „egyszerű lélek”. (Elrejtettél valami statisztikaletárolót legalább benne? ;D) -
SzerzőBejegyzés