Hozzászólások
-
Bejegyzés
-
gendelider wrote:0.) A port forwarding kifejezésröl:
„Port Forwarding is only called within masquerading functions so it
fits inside the same IPFWADM/IPCHAINS rules. Masquerading is an extension to
IP forwarding. Therefore, ipportfw only sees a packet if it fits
both the input and masquerading ipfwadm rule sets.”(Megjegyzés: profi tüzfalaknál nem csak masquerading, hanem 1:1 (fully) NAT esetében is használják a kifejezést.
Na ezt nem értem, ennyire nem jó se az angolom se az iptables tudásom.
gendelider wrote:1.) Van a céges gépednél egy proxy, hogy ki tudjál menni a világba. Gondolom, ha ezen átküzdötte magát a csomag, akkor, amikor a routeredre odaér, már a 22-es, 80-as, 41477-es portot címzi. Ha így van, felejtsük el céges proxydat, mert ekkor ennek semmi köze a problémához.Ez így van, a céges proxy és tűzfal már megkerülve, azok nem kavarnak be.
gendelider wrote:2.) Ha „kipucolod” teljesen a router iptable-ját, nem lesz router a router. Kár is megpróbálni.A NAT részét természetesen nem lőném ki, csak az INPUT/OUTPUT/FORWARD láncokat.
gendelider wrote:3.) Ha az otthoni gépeden fut egy proxy (tulajdonképpen reverse-proxy) a 80-as portra (gondolom a webszervered meg inetd/xinetd -s) , akkor a routerben a 80-as port egyszerüen forwardolandó az otthoni gépedre (192.168.x.y). Ha jól értettem, ez ment is jól.Webszerverem nincs, a többit jól értetted.
gendelider wrote:4.) Ha nem az otthoni gépeden, hanem a routeredben fut a reverse proxy, akkor a 80-as portot nem szabad forwardolni (meg kell változtatni a roter beállításait) mert a proxy figyeli a WAN:80-at (pontosabban a ppp0:80-at) és ha „tetszik neki” ami jött, akkor továbbítja a 192.168.x.y:80-ra. Lehet, hogy itt nem kapcsoltad ki a router beállításainal a forwardot? Itt a kígyó a saját farkába haraphat.
Természetesen azt olyankor kikapcsolom, a routerre és más gépekre be is tudok lépni azon keresztül, csak a gépemre nem, tehát az nem zavar be.Azon a doksin én sem fogom tudni átrágni magam, a 0. pontnál említettek miatt.
Én még mindig azt furcsállom amit korábban írtam, hogy miért nem dobja át a router belső IP-jére.gendelider wrote:0.) A port forwarding kifejezésröl:„Port Forwarding is only called within masquerading functions so it
fits inside the same IPFWADM/IPCHAINS rules. Masquerading is an extension to
IP forwarding. Therefore, ipportfw only sees a packet if it fits
both the input and masquerading ipfwadm rule sets.”(Megjegyzés: profi tüzfalaknál nem csak masquerading, hanem 1:1 (fully) NAT esetében is használják a kifejezést.
Na ezt nem értem, ennyire nem jó se az angolom se az iptables tudásom.
gendelider wrote:1.) Van a céges gépednél egy proxy, hogy ki tudjál menni a világba. Gondolom, ha ezen átküzdötte magát a csomag, akkor, amikor a routeredre odaér, már a 22-es, 80-as, 41477-es portot címzi. Ha így van, felejtsük el céges proxydat, mert ekkor ennek semmi köze a problémához.Ez így van, a céges proxy és tűzfal már megkerülve, azok nem kavarnak be.
gendelider wrote:2.) Ha „kipucolod” teljesen a router iptable-ját, nem lesz router a router. Kár is megpróbálni.A NAT részét természetesen nem lőném ki, csak az INPUT/OUTPUT/FORWARD láncokat.
gendelider wrote:3.) Ha az otthoni gépeden fut egy proxy (tulajdonképpen reverse-proxy) a 80-as portra (gondolom a webszervered meg inetd/xinetd -s) , akkor a routerben a 80-as port egyszerüen forwardolandó az otthoni gépedre (192.168.x.y). Ha jól értettem, ez ment is jól.Webszerverem nincs, a többit jól értetted.
gendelider wrote:4.) Ha nem az otthoni gépeden, hanem a routeredben fut a reverse proxy, akkor a 80-as portot nem szabad forwardolni (meg kell változtatni a roter beállításait) mert a proxy figyeli a WAN:80-at (pontosabban a ppp0:80-at) és ha „tetszik neki” ami jött, akkor továbbítja a 192.168.x.y:80-ra. Lehet, hogy itt nem kapcsoltad ki a router beállításainal a forwardot? Itt a kígyó a saját farkába haraphat.
Természetesen azt olyankor kikapcsolom, a routerre és más gépekre be is tudok lépni azon keresztül, csak a gépemre nem, tehát az nem zavar be.Azon a doksin én sem fogom tudni átrágni magam, a 0. pontnál említettek miatt.
Én még mindig azt furcsállom amit korábban írtam, hogy miért nem dobja át a router belső IP-jére.Ez a szál megszakadt, én is elfelejtettem, hogy volt róla szó, de most megint van egy jó pár fájlom, amikben az a karakter szerepel, úgyhogy ismét elővenném ezt a problémát.
gendelider wrote: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.Ez adott, a gépen a 22-esen fut az ssh, a routeren a 41477-esen.
gendelider wrote:Ha jól értelek, a proxy működése mégis elkettyint valamit, ami nem 80-as port…Ezt nem értem.
Alapból http futna a 80-anas porton, de mivel most socks proxy van rajta persze, hogy nem használható http-re.
Lehet azt az infót kár volt leírni.gendelider wrote: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”.Ha kitörlök minden szabályt, csak az alapértelmezett policy marad(ACCEPT), akkor sem megy, de azért holnap ezt újra tesztelem.
gendelider wrote:1.) az ssh miért meg a proxyn keresztül, ha semmi köze hozzá?Mert másképp nem engedi a céges tűzfal, csak egy szerverre lehet közvetlen ssh-zni, ezért kell a proxy és ezért kell, hogy a 80-as porton fusson.
gendelider wrote:2.) mi köze van a 80-as porton lógó proxynak mindehhez?Igazából nem tudom hogyan működik egy proxy, csak feltételeztem, hogy ahhoz beérkezik egy kérés, elbírálja, hogy engedélyezett-e, majd a saját IP-jéről továbbítja a cél címre, ezért látszódik úgy, hogy a router IP-jéről indul egy kérés, szintén a router IP-jére, mert ha nem ezt tenné, akkor a melóhelyem külső IP-jét kellene látnom vagy nem?
Mikor a gépemen futó proxyt használtam akkor is a gépem belső IP-jéről jött a kapcsolat a tcpdump szerint.Még azt fogom megfigyelni holnap, hogy hogyan jön létre a kapcsolat akkor, amikor a routerre lépek be a korábban említett porton, hátha okosabb leszek.
gendelider wrote: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.Ez adott, a gépen a 22-esen fut az ssh, a routeren a 41477-esen.
gendelider wrote:Ha jól értelek, a proxy működése mégis elkettyint valamit, ami nem 80-as port…Ezt nem értem.
Alapból http futna a 80-anas porton, de mivel most socks proxy van rajta persze, hogy nem használható http-re.
Lehet azt az infót kár volt leírni.gendelider wrote: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”.Ha kitörlök minden szabályt, csak az alapértelmezett policy marad(ACCEPT), akkor sem megy, de azért holnap ezt újra tesztelem.
gendelider wrote:1.) az ssh miért meg a proxyn keresztül, ha semmi köze hozzá?Mert másképp nem engedi a céges tűzfal, csak egy szerverre lehet közvetlen ssh-zni, ezért kell a proxy és ezért kell, hogy a 80-as porton fusson.
gendelider wrote:2.) mi köze van a 80-as porton lógó proxynak mindehhez?Igazából nem tudom hogyan működik egy proxy, csak feltételeztem, hogy ahhoz beérkezik egy kérés, elbírálja, hogy engedélyezett-e, majd a saját IP-jéről továbbítja a cél címre, ezért látszódik úgy, hogy a router IP-jéről indul egy kérés, szintén a router IP-jére, mert ha nem ezt tenné, akkor a melóhelyem külső IP-jét kellene látnom vagy nem?
Mikor a gépemen futó proxyt használtam akkor is a gépem belső IP-jéről jött a kapcsolat a tcpdump szerint.Még azt fogom megfigyelni holnap, hogy hogyan jön létre a kapcsolat akkor, amikor a routerre lépek be a korábban említett porton, hátha okosabb leszek.
uzsolt wrote:Akkor szeptember végére várom a végeredményt 🙂Ha ilyen tempóval jön ki Debian-ra a csomag akkor nem fog menni. 🙁
„3.0-1: amd64 hppa sparc ” már lassan minden kevésbé használt platformra elkészítik, csak épp a legelterjedtebbre nem…uzsolt wrote:Akkor szeptember végére várom a végeredményt 🙂Ha ilyen tempóval jön ki Debian-ra a csomag akkor nem fog menni. 🙁
„3.0-1: amd64 hppa sparc ” már lassan minden kevésbé használt platformra elkészítik, csak épp a legelterjedtebbre nem…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.
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.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.
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.
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.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.
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.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.
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.
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.
