Re: [tproxy] tproxy 2.6.10+
Szervusz, 2005-06-22, sze keltezéssel 14.43-kor Pásztor Lénárd Zoltán ezt írta:
Esetleg meg tudja nekem valaki mondani mikorra varhato tproxy patch frissites? Sajnos csak 2.6.10-es patch-et talaltam de (az xen 2.0.6 miatt) nekem legalabb 2.6.11-es kernelen kene hogy mukodjon. Sajnos nem vagyok toppon C-ben igy magam nem tudom megoldani a conflict-okat. :(
Jelenleg még nincs ilyen, és bizonytalan hogy mikor lesz, mivel nem csak triviális változtatásokról van szó. Panaszkodni a főnökömnél lehet... :)
Jol gondolom, hogy ha nekem adott 1 szolgaltatas IP es belul tobb webszerver amelyek kulonbozo domaineket szolgalnak ki es szuksegem van az eredeti kliens IP-kre az access.log-okban akkor zorp+tproxy+iptables megoldasra van szuksegem?
Ha csak HTTP logoláshoz kell, akkor meg lehet csinálni azt is, hogy mivel a Zorp a tproxy patch nélkül is tudja a kliens IP-jét, egy plusz headerként bele tudja tenni azt a HTTP requestekbe, amit aztán az apache simán ki tud logolni az access.log-ba. Erről bővebb információt itt találhatsz: https://lists.balabit.hu/pipermail/zorp-hu/2004-November/001582.html Egyébként a tproxy levelezési lista angol nyelvű, ezért inkább áttettem a zorp-hu listára a választ. -- Regards, Krisztian Kovacs
Szia! Megneztem a linket amit kuldtel. Igy megy is a dolog, persze jobban belegondolva sajnos meg sem egeszen jo nekem ez a megoldas, mivel igaz igy a logjaim jok lesznek, de dinamikus oldalaknal ahol a site ellenorzi a kliens IP cimet (lekeri az apache-tol, pl $REMOTE_HOST php-ben) mindig a proxy cimet kapja viszont. Ket megoldas letezik a fejemben: 1. apache szinten vajon meg lehet-e oldani, hogy mit adjon vissza? (es akkor ez a headeres hack mehet tovabbra is igy) 2. tproxy gondolom. Irtad hogy ha a 01-nat_reservations tema kimarad akkor gyorsan ossze tudsz hozni egy patch-et nagyobb verzioszamu kernelhez. El tudod mondani mit csinal ez a resze a patch-nek? Amugy a lenyeg az, hogy a belso szerver ugy lassa, hogy az eredeti kliens IP-rol jon a csomag. Ezt meg lehet oldani a nat reservation nelkuli patch-el? Sajnos nem vagyok jo C-ben esetleg el tudod kesziteni a patch-et nekem? Jelenleg 2.6.12-t hasznalok, de jo a 2.6.11-es verzioval mukodo patch is ha az elobbi nagy szivas. udv, Lenard KOVACS Krisztian wrote:
Szervusz,
2005-06-22, sze keltezéssel 14.43-kor Pásztor Lénárd Zoltán ezt írta:
Esetleg meg tudja nekem valaki mondani mikorra varhato tproxy patch frissites? Sajnos csak 2.6.10-es patch-et talaltam de (az xen 2.0.6 miatt) nekem legalabb 2.6.11-es kernelen kene hogy mukodjon. Sajnos nem vagyok toppon C-ben igy magam nem tudom megoldani a conflict-okat. :(
Jelenleg még nincs ilyen, és bizonytalan hogy mikor lesz, mivel nem csak triviális változtatásokról van szó. Panaszkodni a főnökömnél lehet... :)
Jol gondolom, hogy ha nekem adott 1 szolgaltatas IP es belul tobb webszerver amelyek kulonbozo domaineket szolgalnak ki es szuksegem van az eredeti kliens IP-kre az access.log-okban akkor zorp+tproxy+iptables megoldasra van szuksegem?
Ha csak HTTP logoláshoz kell, akkor meg lehet csinálni azt is, hogy mivel a Zorp a tproxy patch nélkül is tudja a kliens IP-jét, egy plusz headerként bele tudja tenni azt a HTTP requestekbe, amit aztán az apache simán ki tud logolni az access.log-ba. Erről bővebb információt itt találhatsz:
https://lists.balabit.hu/pipermail/zorp-hu/2004-November/001582.html
Egyébként a tproxy levelezési lista angol nyelvű, ezért inkább áttettem a zorp-hu listára a választ.
Szervusz, 2005-06-22, sze keltezéssel 15.11-kor Pásztor Lénárd Zoltán ezt írta:
Megneztem a linket amit kuldtel. Igy megy is a dolog, persze jobban belegondolva sajnos meg sem egeszen jo nekem ez a megoldas, mivel igaz igy a logjaim jok lesznek, de dinamikus oldalaknal ahol a site ellenorzi a kliens IP cimet (lekeri az apache-tol, pl $REMOTE_HOST php-ben) mindig a proxy cimet kapja viszont.
Ket megoldas letezik a fejemben:
1. apache szinten vajon meg lehet-e oldani, hogy mit adjon vissza? (es akkor ez a headeres hack mehet tovabbra is igy)
Ezt gondolom PHP szinten egy egyszeru search-and-replace-szel lehet megoldani; a headereket ott is latod. Ennek persze megvan az a hatranya, hogy a dolog innentol nem teljesen transzparens... A dolog elonye viszont, hogy kihagysz egy komponenst a rendszeredbol, ami egyebkent raadasul a kernelben lakozik, plusz problemaforras, stb. (Raadasul amint latszik, ha sajat kernelt hasznalsz akkor a patcheles is problema.)
2. tproxy gondolom. Irtad hogy ha a 01-nat_reservations tema kimarad akkor gyorsan ossze tudsz hozni egy patch-et nagyobb verzioszamu kernelhez.
El tudod mondani mit csinal ez a resze a patch-nek? Amugy a lenyeg az, hogy a belso szerver ugy lassa, hogy az eredeti kliens IP-rol jon a csomag. Ezt meg lehet oldani a nat reservation nelkuli patch-el?
Persze. Ilyen HTTP proxyzashoz nem kell a NAT reservations; az csak bonyolultabb esetekben segit annyit, hogy kisebb esellyel foglalja el valami mas kapcsolat a Zorp altal hasznalni kivant cimet. (A reszletek kicsit bonyolultak, ugyhogy itt most nem mennek bele a Netfilter connection tracking lelkivilagaba.)
Jelenleg 2.6.12-t hasznalok, de jo a 2.6.11-es verzioval mukodo patch is ha az elobbi nagy szivas.
Ha egyszer lesz patch 2.6.11-hez, akkor onnan a 2.6.12 mar trivialis. -- Regards, Krisztian Kovacs
1. apache szinten vajon meg lehet-e oldani, hogy mit adjon vissza? (es akkor ez a headeres hack mehet tovabbra is igy)
Ezt gondolom PHP szinten egy egyszeru search-and-replace-szel lehet megoldani; a headereket ott is latod. Ennek persze megvan az a hatranya, hogy a dolog innentol nem teljesen transzparens... A dolog elonye viszont, hogy kihagysz egy komponenst a rendszeredbol, ami egyebkent raadasul a kernelben lakozik, plusz problemaforras, stb. (Raadasul amint latszik, ha sajat kernelt hasznalsz akkor a patcheles is problema.)
Eddig a SetEnv direktivaval probalkoztam, de a REMOTE_ADDR valtozot sajnos nem engedi atallitani vele. Az applikaciok fele transzparensnek kell lennie, ezert probaltam meg az apache szintjen megfogni. Igy nem kene php-kben atirogatni es van meg a dologban tomcat is.
Persze. Ilyen HTTP proxyzashoz nem kell a NAT reservations; az csak bonyolultabb esetekben segit annyit, hogy kisebb esellyel foglalja el valami mas kapcsolat a Zorp altal hasznalni kivant cimet. (A reszletek kicsit bonyolultak, ugyhogy itt most nem mennek bele a Netfilter connection tracking lelkivilagaba.)
Jelenleg 2.6.12-t hasznalok, de jo a 2.6.11-es verzioval mukodo patch is ha az elobbi nagy szivas.
Ha egyszer lesz patch 2.6.11-hez, akkor onnan a 2.6.12 mar trivialis.
Gondolom itt a teljes patch-re gondolsz? Tudom, hogy melozol kemenyen es nem egy projecten, de tudsz mondani kb idot, hogy mikor leszel meg vele? Mert akkor ugy kell terveznem. Esetleg nat reservation nelkuli valtozat? Sajna nem vagyok jo C-ben. Amennyiben csak mashova kell mozgatni u.a. a kodot az meg menne, de a .rej fajlokat nezve itt talan ennel tobbrol van szo. :( udv, Lenard
Szervusz, 2005-06-22, sze keltezéssel 15.53-kor Pásztor Lénárd Zoltán ezt írta:
Gondolom itt a teljes patch-re gondolsz? Tudom, hogy melozol kemenyen es nem egy projecten, de tudsz mondani kb idot, hogy mikor leszel meg vele? Mert akkor ugy kell terveznem.
Esetleg nat reservation nelkuli valtozat? Sajna nem vagyok jo C-ben. Amennyiben csak mashova kell mozgatni u.a. a kodot az meg menne, de a .rej fajlokat nezve itt talan ennel tobbrol van szo. :(
Nem rajtam múlik. További részletekről itt lehet érdeklődni: sasa kukac balabit pont hu. -- Regards, Krisztian Kovacs
Szia! Seikerult vegul beizzitanom 2.6.10-el (teszt jelleggel). A zorp proxy modul nem szolgalja ki az oldalt, a logban bind() failed;... uzenetet talalok. Strace-el megneztem es a kliens IP-jet akarja bind-elni a gepen. Gondolom ez is resze transzparens mukodest megoldo eljarasnak. Hogyan lehet ezt megoldani? Erre kell a dummy interface? udv, Lenard Pásztor Lénárd Zoltán wrote:
1. apache szinten vajon meg lehet-e oldani, hogy mit adjon vissza? (es akkor ez a headeres hack mehet tovabbra is igy)
Ezt gondolom PHP szinten egy egyszeru search-and-replace-szel lehet megoldani; a headereket ott is latod. Ennek persze megvan az a hatranya, hogy a dolog innentol nem teljesen transzparens... A dolog elonye viszont, hogy kihagysz egy komponenst a rendszeredbol, ami egyebkent raadasul a kernelben lakozik, plusz problemaforras, stb. (Raadasul amint latszik, ha sajat kernelt hasznalsz akkor a patcheles is problema.)
Eddig a SetEnv direktivaval probalkoztam, de a REMOTE_ADDR valtozot sajnos nem engedi atallitani vele. Az applikaciok fele transzparensnek kell lennie, ezert probaltam meg az apache szintjen megfogni. Igy nem kene php-kben atirogatni es van meg a dologban tomcat is.
Persze. Ilyen HTTP proxyzashoz nem kell a NAT reservations; az csak bonyolultabb esetekben segit annyit, hogy kisebb esellyel foglalja el valami mas kapcsolat a Zorp altal hasznalni kivant cimet. (A reszletek kicsit bonyolultak, ugyhogy itt most nem mennek bele a Netfilter connection tracking lelkivilagaba.)
Jelenleg 2.6.12-t hasznalok, de jo a 2.6.11-es verzioval mukodo patch is ha az elobbi nagy szivas.
Ha egyszer lesz patch 2.6.11-hez, akkor onnan a 2.6.12 mar trivialis.
Gondolom itt a teljes patch-re gondolsz? Tudom, hogy melozol kemenyen es nem egy projecten, de tudsz mondani kb idot, hogy mikor leszel meg vele? Mert akkor ugy kell terveznem.
Esetleg nat reservation nelkuli valtozat? Sajna nem vagyok jo C-ben. Amennyiben csak mashova kell mozgatni u.a. a kodot az meg menne, de a .rej fajlokat nezve itt talan ennel tobbrol van szo. :(
udv,
Lenard
Szervusz, 2005-06-23, cs keltezéssel 14.53-kor Pásztor Lénárd Zoltán ezt írta:
Seikerult vegul beizzitanom 2.6.10-el (teszt jelleggel). A zorp proxy modul nem szolgalja ki az oldalt, a logban bind() failed;... uzenetet talalok. Strace-el megneztem es a kliens IP-jet akarja bind-elni a gepen. Gondolom ez is resze transzparens mukodest megoldo eljarasnak.
Igen. Milyen verzioju zorp-pal probalod (ujabbak el sem indulnak autobind IP nelkul)? Illetve az lenne meg a kerdes, hogy amikor elinditod a Zorp-ot, akkor ir a logba valami ilyesmit: System dependant init; sysdep_tproxy='tproxy20' Namarmost nalad ide a sysdep_tproxy-hoz mit ir? -- Regards, Krisztian Kovacs
Szia! # dpkg -l zorp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-========================================================== ii zorp 2.0.9-9 An advanced protocol analyzing firewall # /etc/init.d/zorp start Starting Zorp Firewall Suite: reverse_http Jun 23 15:35:42 hosting1 reverse_http[12144]: zorp version 2.0.9 starting up Jun 23 15:35:42 hosting1 reverse_http[12146]: (Log thread): /usr/share/zorp/pylib/Zorp/Domain.py:123: FutureWarning: x<<y losing bits or changing sign will return a long in Python 2.4 and up Es egy http keres utan: Jun 23 15:36:16 test reverse_http[12144]: (zorp@test/tproxy_test): Starting service; name='tproxy_test' Jun 23 15:36:16 test reverse_http[12144]: (zorp@test/tporxy_test:0): Starting proxy instance; client_fd='15', client_address='AF_INET(10.3.6.55:59855)', client_zone='Zone(site-net, 10.3.0.0/16)', client_local='AF_INET(10.3.6.253:1200)' Jun 23 15:36:16 test reverse_http[12144]: (zorp@test/tproxy_test:0/http): Proxy starting; class='ReverseHostHttpProxy', module='http' Jun 23 15:36:16 test reverse_http[12146]: (Log thread): /usr/share/zorp/pylib/Zorp/Zone.py:578: FutureWarning: x<<y losing bits or changing sign will return a long in Python 2.4 and up Jun 23 15:36:16 test reverse_http[12144]: (reverse_http@zorp@test/nosession): accept count; accepts='1' Jun 23 15:36:16 test reverse_http[12211]: (zorp@test/tproxy_test:0/http): bind() failed; error='Cannot assign requested address' Jun 23 15:36:16 test reverse_http[12211]: (zorp@test/tproxy_test:0/http): Server connection failure; server_address='AF_INET(10.21.10.1:80)', server_zone='Zone(www-test, 21.0.0/16)', server_local='None' Jun 23 15:36:16 test reverse_http[12211]: (zorp@test/tporxy_test:0/http): Proxy ending; class='ReverseHostHttpProxy', module='http' Jun 23 15:36:16 test reverse_http[12211]: (zorp@test/tporxy_test:0): Ending proxy instance; Jun 23 15:36:16 test reverse_http[12211]: (zorp@test/tporxy_test:0/http/client): accounting info; type='stream', duration='0', sent='858', received='392' 10.3.6.55 a kliens IP 10.3.6.253 a zorp tuzfal IP 10.21.10.1 a webszerver IP A netfilter a :80-ra jovo csomagokat nyomja tproxy tablaban :1200-as portra, ahol a zorp figyel. Additional information: Error establishing connection to cafeserver.wonderline.hu Nem talaltam a logban olyan bejegyzest amit irtal. Lehet tul regi verziot hasznalok? KOVACS Krisztian wrote:
Szervusz,
2005-06-23, cs keltezéssel 14.53-kor Pásztor Lénárd Zoltán ezt írta:
Seikerult vegul beizzitanom 2.6.10-el (teszt jelleggel). A zorp proxy modul nem szolgalja ki az oldalt, a logban bind() failed;... uzenetet talalok. Strace-el megneztem es a kliens IP-jet akarja bind-elni a gepen. Gondolom ez is resze transzparens mukodest megoldo eljarasnak.
Igen. Milyen verzioju zorp-pal probalod (ujabbak el sem indulnak autobind IP nelkul)? Illetve az lenne meg a kerdes, hogy amikor elinditod a Zorp-ot, akkor ir a logba valami ilyesmit:
System dependant init; sysdep_tproxy='tproxy20'
Namarmost nalad ide a sysdep_tproxy-hoz mit ir?
Szervusz, 2005-06-23, cs keltezéssel 15.46-kor Pásztor Lénárd Zoltán ezt írta:
# dpkg -l zorp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-========================================================== ii zorp 2.0.9-9 An advanced protocol analyzing firewall
Nem talaltam a logban olyan bejegyzest amit irtal. Lehet tul regi verziot hasznalok?
Igen, ez a verzio meg nem megy a 2.x.x-es tproxy verziokkal, es igy 2.6-os kernellel sem. Alapvetoen ket lehetoseg van, vagy downgradeled a kerneledet 2.4.x-re, es ahhoz hasznalod az 1.2.2-es tproxy patchet, vagy upgradeled a Zorpodat (peldaul a frissen megjelent 3.0.5-re...) -- Regards, Krisztian Kovacs
OK, akkor nezzuk a Zorp 3.0.x-et. A hirlevelbol kiolloztam a deb http://apt.balabit.com/zorp-os-gpl zorp-os-3.0/3.0 common-gpl zorp zorp-os zorp-os-extra forrast, de file not found a vege. Megneztem bongeszovel es The requested URL /zorp-os-gpl/ was not found on this server. az eredmeny. En cseszek el valamit vagy tenyleg nem elerheto? S ha nem jo a cim akkor tudnal kuldeni egy url-t? KOVACS Krisztian wrote:
Szervusz,
2005-06-23, cs keltezéssel 15.46-kor Pásztor Lénárd Zoltán ezt írta:
# dpkg -l zorp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-========================================================== ii zorp 2.0.9-9 An advanced protocol analyzing firewall
Nem talaltam a logban olyan bejegyzest amit irtal. Lehet tul regi verziot hasznalok?
Igen, ez a verzio meg nem megy a 2.x.x-es tproxy verziokkal, es igy 2.6-os kernellel sem. Alapvetoen ket lehetoseg van, vagy downgradeled a kerneledet 2.4.x-re, es ahhoz hasznalod az 1.2.2-es tproxy patchet, vagy upgradeled a Zorpodat (peldaul a frissen megjelent 3.0.5-re...)
On Thu, 2005-06-23 at 15:56 +0200, Pásztor Lénárd Zoltán wrote:
OK, akkor nezzuk a Zorp 3.0.x-et.
A hirlevelbol kiolloztam a deb http://apt.balabit.com/zorp-os-gpl zorp-os-3.0/3.0 common-gpl zorp zorp-os zorp-os-extra forrast, de file not found a vege.
Megneztem bongeszovel es The requested URL /zorp-os-gpl/ was not found on this server. az eredmeny.
En cseszek el valamit vagy tenyleg nem elerheto? S ha nem jo a cim akkor tudnal kuldeni egy url-t?
Probald ezt: deb http://apt.balabit.com/zorp-gpl-os zorp-os-3.0/3.0 common-gpl zorp-gpl zorp-os zorp-os-extra MCS
Szia! A csomaggal van gaz, vagy az elozo zorp installacio maradvanyai miatt szallt el, vagy? Debian Sarge distro-t hasznalok. # apt-get install zorp Reading Package Lists... Done Building Dependency Tree... Done zorp is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up zorp (3.0.5) ... Config directory has invalid permissions, expected: dir='/etc/zorp', owner='root', group='zorp', perm='0750' invoke-rc.d: initscript zorp, action "start" failed. dpkg: error processing zorp (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: zorp E: Sub-process /usr/bin/dpkg returned an error code (1) Letre kellett hoznom egy zorp csoportot majd: apt-get install zorp Reading Package Lists... Done Building Dependency Tree... Done zorp is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 0B of archives. After unpacking 0B of additional disk space will be used. Setting up zorp (3.0.5) ... Starting Zorp Firewall Suite: The following errors occurred so far: Error opening instances file: /etc/zorp/instances.conf Ha le szeretnem torolni akkor: # dpkg --purge zorp zorp-modules (Reading database ... 18293 files and directories currently installed.) Removing zorp-modules ... Purging configuration files for zorp-modules ... rmdir: `zorp/policy.boot': Not a directory dpkg: error processing zorp-modules (--purge): subprocess post-removal script returned error exit status 1 dpkg: dependency problems prevent removal of zorp: zorp-modules depends on zorp (= 3.0.5). dpkg: error processing zorp (--purge): dependency problems - not removing Errors were encountered while processing: zorp-modules zorp Major Csaba wrote:
On Thu, 2005-06-23 at 15:56 +0200, Pásztor Lénárd Zoltán wrote:
OK, akkor nezzuk a Zorp 3.0.x-et.
A hirlevelbol kiolloztam a deb http://apt.balabit.com/zorp-os-gpl zorp-os-3.0/3.0 common-gpl zorp zorp-os zorp-os-extra forrast, de file not found a vege.
Megneztem bongeszovel es The requested URL /zorp-os-gpl/ was not found on this server. az eredmeny.
En cseszek el valamit vagy tenyleg nem elerheto? S ha nem jo a cim akkor tudnal kuldeni egy url-t?
Probald ezt:
deb http://apt.balabit.com/zorp-gpl-os zorp-os-3.0/3.0 common-gpl zorp-gpl zorp-os zorp-os-extra
MCS
------------------------------------------------------------------------
_______________________________________________ zorp-hu mailing list zorp-hu@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/zorp-hu
On Thu, 2005-06-23 at 16:12 +0200, Pásztor Lénárd Zoltán wrote:
Szia!
A csomaggal van gaz, vagy az elozo zorp installacio maradvanyai miatt szallt el, vagy?
Debian Sarge distro-t hasznalok.
Lehet, hogy a GPL-es csomag nem tokeletes. Hozz letre egy instances.conf-ot (amit keres), meg majd egy policy.py-t, es akkor valoszinuleg felmegy. MCS
Szia! Vegul sikerult megoldani az installt es most mar szo nelkul mukodik is. :) Hasznalhato a DirectedRouter akkor is ha tobb szerver van a zorp mogott amelyek tobb domaint szolgalnak ki vagy arra mas megoldas kell? Amennyiben a DirectedRouter-nek nem adok dest_addr-t akkor elszall. udv, Lenard KOVACS Krisztian wrote:
Szervusz,
2005-06-23, cs keltezéssel 15.46-kor Pásztor Lénárd Zoltán ezt írta:
# dpkg -l zorp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-========================================================== ii zorp 2.0.9-9 An advanced protocol analyzing firewall
Nem talaltam a logban olyan bejegyzest amit irtal. Lehet tul regi verziot hasznalok?
Igen, ez a verzio meg nem megy a 2.x.x-es tproxy verziokkal, es igy 2.6-os kernellel sem. Alapvetoen ket lehetoseg van, vagy downgradeled a kerneledet 2.4.x-re, es ahhoz hasznalod az 1.2.2-es tproxy patchet, vagy upgradeled a Zorpodat (peldaul a frissen megjelent 3.0.5-re...)
Szia! Pontositok, mert asszem eleg nagy butasagot kerdeztem... :( Szoval adott 1 fw ahol a Zorp csucsul, mogotte n darab webszerver. A szerverek mas-mas domaineket szolgalnak ki. van egy ReverseHostHttpProxy(HttpProxy) class-om, amiben beallitodik a self.session.server_address.ip_s parameter. Ha ezt a beallitast kikapcsolom akkor nem szolgalja ki az oldalt. Hogyan oldhato meg, hogy ne kelljen felsorolnom az IP-ket a domainekhez, hanem DNS alapjan visszaadott IP-t hasznalja? Gondolom egy olyan python fgv kell ami resolvolja a hostnevet es IP-t ad vissza? + hibakezeles... A python.org-on nezelodom de nem nagyon talalok fgv-t ami resolvolna. :( class ReverseHostHttpProxy(HttpProxy): host_mapping = { 'www-test': '10.21.10.1' } default_ip = '10.21.10.1'; def config(self): HttpProxy.config(self) self.request_headers["Host"] = (HTTP_HDR_POLICY, self.checkHostHeader) def checkHostHeader(self, name, value): # check the host header and set destination address # based on the header's value if self.host_mapping.has_key(value): self.session.server_address.ip_s = self.host_mapping[value] else: self.session.server_address.ip_s = self.default_ip # we don't need further hooks del self.request_headers["Host"] return HTTP_HDR_ACCEPT Pásztor Lénárd Zoltán wrote:
Szia!
Vegul sikerult megoldani az installt es most mar szo nelkul mukodik is. :) Hasznalhato a DirectedRouter akkor is ha tobb szerver van a zorp mogott amelyek tobb domaint szolgalnak ki vagy arra mas megoldas kell?
Amennyiben a DirectedRouter-nek nem adok dest_addr-t akkor elszall.
udv,
Lenard
KOVACS Krisztian wrote:
Szervusz,
2005-06-23, cs keltezéssel 15.46-kor Pásztor Lénárd Zoltán ezt írta:
# dpkg -l zorp Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-=====================-=====================-==========================================================
ii zorp 2.0.9-9 An advanced protocol analyzing firewall
Nem talaltam a logban olyan bejegyzest amit irtal. Lehet tul regi verziot hasznalok?
Igen, ez a verzio meg nem megy a 2.x.x-es tproxy verziokkal, es igy 2.6-os kernellel sem. Alapvetoen ket lehetoseg van, vagy downgradeled a kerneledet 2.4.x-re, es ahhoz hasznalod az 1.2.2-es tproxy patchet, vagy upgradeled a Zorpodat (peldaul a frissen megjelent 3.0.5-re...)
_______________________________________________ zorp-hu mailing list zorp-hu@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/zorp-hu
szia,
Pontositok, mert asszem eleg nagy butasagot kerdeztem... :( nem kérdeztél butaságot. Amit leírsz egy élő dolog.
Szoval adott 1 fw ahol a Zorp csucsul, mogotte n darab webszerver. A szerverek mas-mas domaineket szolgalnak ki. A megoldás nem az amit leírsz, hanem az, hogy vagy a tűzfal /etc/hosts fileban legyen benne az a belső címe a www.domain1.hu stb. gépeknek és akkor a zorp a névfeloldás alapján tudja majd, hogy merre irányítsa a csomagot. Sima HTTP-val működik, mindenfajta különösebb varázslat nélkül (bár egy ideje már csak copyzom az ilyen beállításokat, egyszer kell vele "megszenvedni"). "Gond" ott lesz, ha HTTPS-t is akarsz, azt is meg lehet oldani, de akkor egymás mellék kell stackelni a proxykat, a SideStackChainer-rel. A listaarchívumban volt már bőven hivatkozás rá.
hanem DNS alapjan visszaadott IP-t hasznalja? na most ,ez alapján van DNS. Akkor viszont nem privát címeken vannak a webszerverek? Teszem azt a .129-es gép a tűzfal, ami routerként funciónál a .130,.131 astb. végű gépek előtt? Vagy egy belső DNS-ed van? Mert akkor a resolv.conf-ban kellene elsődleges névkiszolgálónak azt beállítanod. Vagy a fentebb említett /etc/hosts fájl is megoldás, ha kevés szerver van. 100%-ig korrekt persze a DNS.
üdv, Ago
On Thu, 2005-06-23 at 20:17 +0200, ago@lsc.hu wrote:
szia,
Pontositok, mert asszem eleg nagy butasagot kerdeztem... :( nem kérdeztél butaságot. Amit leírsz egy élő dolog.
Szoval adott 1 fw ahol a Zorp csucsul, mogotte n darab webszerver. A szerverek mas-mas domaineket szolgalnak ki. A megoldás nem az amit leírsz, hanem az, hogy vagy a tűzfal /etc/hosts fileban legyen benne az a belső címe a www.domain1.hu stb. gépeknek és akkor a zorp a névfeloldás alapján tudja majd, hogy merre irányítsa a csomagot. Sima HTTP-val működik, mindenfajta különösebb varázslat nélkül (bár egy ideje már csak copyzom az ilyen beállításokat, egyszer kell vele "megszenvedni"). "Gond" ott lesz, ha HTTPS-t is akarsz, azt is meg lehet oldani, de akkor egymás mellék kell stackelni a proxykat, a SideStackChainer-rel. A listaarchívumban volt már bőven hivatkozás rá.
hanem DNS alapjan visszaadott IP-t hasznalja? na most ,ez alapján van DNS. Akkor viszont nem privát címeken vannak a webszerverek? Teszem azt a .129-es gép a tűzfal, ami routerként funciónál a .130,.131 astb. végű gépek előtt? Vagy egy belső DNS-ed van? Mert akkor a resolv.conf-ban kellene elsődleges névkiszolgálónak azt beállítanod. Vagy a fentebb említett /etc/hosts fájl is megoldás, ha kevés szerver van. 100%-ig korrekt persze a DNS.
3.0.5-ben mar van un. Resolver interface, bar meg csak experimental jelleggel, valoszinuleg 3.1-ben egy csoppet valtozni fog. Annak az a lenyege, hogy egy fuggetlen objektum oldja fel a celcimet, ami alapbol DNS, de akar sajat modszerrel is megoldhatja a nev->IP lekepezest. Pl: mostanival kompatibilis mukodes: Service("http", HttpProxy, router=InbandRouter(), resolver=DNSResolver()) kicsit erdekesebb: class HashResolver(AbstractResolver): def __init__(self, host_map): AbstractResolver.__init__(self) self.host_map = host_map def resolve(self, host, port): if self.host_map.has_key(host): return SockAddrInet(self.host_map[host], port) return None Ezek utan: Service("http", HttpProxy, router=InbandRouter(), resolver=HashResolver({'www.alma.hu': '1.2.3.4', 'www.korte.hu': '4.5.6.7'})) Ami varhato 3.1-ben az az, hogy a Resolver-bol is "policy" lesz, mint a NATPolicy vagy az AuthPolicy, azaz nevvel letrehozott objektum lesz, amire a Service-nel mar csak hivatkozni kell, azaz kb igy: ResolverPolicy('web', HashResolver({'www.alma.hu': '1.2.3.4', 'www.korte.hu': '4.5.6.7'}) Service("http", HttpProxy, router=InbandRouter(), resolver_policy='web') Igy tobb service-bol lehet majd egyszeruen ugyanarra hivatkozni. -- Bazsi
szia,
3.0.5-ben mar van un. Resolver interface, bar meg csak experimental jelleggel, akkor ezek szerint maradunk még a jól bevált módszereknél. Addig mások szívjanak :-) lehetőleg a tesztlabor.
valoszinuleg 3.1-ben egy csoppet valtozni fog. Annak az a lenyege, hogy egy fuggetlen objektum oldja fel a celcimet, ami alapbol DNS, de akar sajat modszerrel is megoldhatja a nev->IP lekepezest. Pl: ez jó. Ezek szerint akár - bár nem látom be most miért ne lehetne, de valahogy a leírtak alapján ez könnyebb lesz - feltételekkel is meghatározható, hogy milyen irányból milyen névlekérdezés valósul meg. Eddig bind szinten cseszegettük, most már Zorp szintjén is közbe tudunk majd avatkozni, de szebben, policykkal. Ha jól értettem. Bár kicsit késő van, leragad a szemem is.
Ami varhato 3.1-ben az az, hogy a Resolver-bol is "policy" lesz, mint a NATPolicy vagy az AuthPolicy, azaz nevvel letrehozott objektum lesz, amire a Service-nel mar csak hivatkozni kell, azaz kb igy: ResolverPolicy('web', HashResolver({'www.alma.hu': '1.2.3.4', 'www.korte.hu': '4.5.6.7'}) Ez a hashresolver nagyon visszatérő :-) Talán csak nem lesz egy ilyen beépítve? Eddig úgy tűnik. Viszont ahogyan látom semmi nem akadályozza meg, hogy a policyban a hashresolver helyett saját classt hívogassak, csak létezzen és megfelelő módon adjon vissza értékeket. Legalábbis úgy látom errefelé megy el a dolog.
Service("http", HttpProxy, router=InbandRouter(), resolver_policy='web') Erről jut eszembe, az előbbi kérdéshez. Fontos, hogy több ugyanolyan szolgáltatású (protokoll) szervernél inbandrouter-t kell használni, ha név alapú feloldást és irányítást akarsz, nem directedrouter-t. A másikkal eléggé megerőszakolnád a zorp működési elvét, ha mindig átvasalsz rajta egy címet. Ráadásul eléggé nehezen karbantarthatónak tűnik nekem az a megoldás. InbandRouter pedig olyan esetben tud lehetőséget adni routingra, mármint, hogy a ConnectChainer ki tudja választani hova, melyik szerverre kell kapcsolódnia, ha a protokoll erre lehetőséget ad. http és ftp-n kívül van olyan protokoll ami támogatja ezt a virtuális lehetőséget? És van is hozzá natív proxy a zorpon belül, persze. Jelenleg nem tudok ilyet, de ez az én hibám is lehet.
Igy tobb service-bol lehet majd egyszeruen ugyanarra hivatkozni. visszatérve ide: igen, ez jó dolog, továbbra is objektumorintált maradt a Zorp működése :-)
üdv, Ago
On Fri, 2005-06-24 at 00:21 +0200, ago@lsc.hu wrote:
szia,
3.0.5-ben mar van un. Resolver interface, bar meg csak experimental jelleggel, akkor ezek szerint maradunk még a jól bevált módszereknél. Addig mások szívjanak :-) lehetőleg a tesztlabor.
nem errol van szo, a ZMS meg nem tamogatja, a jelenlegi 3.0-as megvalositas pedig meg nem tud 'policy'-kat. 3.1-ben megjelenik a policy, es a ZMS is tamogatni fogja. Experimental-nak azert hivom, mert gyanitom, meg senki nem hasznalja a tesztkonfigon kivul. A 3.1-es valtozas nagy valoszinuseggel felfele kompatibilis marad.
valoszinuleg 3.1-ben egy csoppet valtozni fog. Annak az a lenyege, hogy egy fuggetlen objektum oldja fel a celcimet, ami alapbol DNS, de akar sajat modszerrel is megoldhatja a nev->IP lekepezest. Pl: ez jó. Ezek szerint akár - bár nem látom be most miért ne lehetne, de valahogy a leírtak alapján ez könnyebb lesz - feltételekkel is meghatározható, hogy milyen irányból milyen névlekérdezés valósul meg. Eddig bind szinten cseszegettük, most már Zorp szintjén is közbe tudunk majd avatkozni, de szebben, policykkal. Ha jól értettem. Bár kicsit késő van, leragad a szemem is.
nagyjabol igy. eddig fel kellett venned a belso gepeket a DNS-be, esetleg az /etc/hosts-ba. Mostantol ez is _lehet_ a zorp konfig resze, nem jon be egy ujabb komponens.
Ami varhato 3.1-ben az az, hogy a Resolver-bol is "policy" lesz, mint a NATPolicy vagy az AuthPolicy, azaz nevvel letrehozott objektum lesz, amire a Service-nel mar csak hivatkozni kell, azaz kb igy: ResolverPolicy('web', HashResolver({'www.alma.hu': '1.2.3.4', 'www.korte.hu': '4.5.6.7'}) Ez a hashresolver nagyon visszatérő :-) Talán csak nem lesz egy ilyen beépítve? Eddig úgy tűnik. Viszont ahogyan látom semmi nem akadályozza meg, hogy a policyban a hashresolver helyett saját classt hívogassak, csak létezzen és megfelelő módon adjon vissza értékeket. Legalábbis úgy látom errefelé megy el a dolog.
Pontosan. Ha neked LDAP-ban vannak tarolva a host->cim lekepezesek, az is megvalosithato.
Service("http", HttpProxy, router=InbandRouter(), resolver_policy='web') Erről jut eszembe, az előbbi kérdéshez. Fontos, hogy több ugyanolyan szolgáltatású (protokoll) szervernél inbandrouter-t kell használni, ha név alapú feloldást és irányítást akarsz, nem directedrouter-t. A másikkal eléggé megerőszakolnád a zorp működési elvét, ha mindig átvasalsz rajta egy címet. Ráadásul eléggé nehezen karbantarthatónak tűnik nekem az a megoldás.
ezt nem ertem.
InbandRouter pedig olyan esetben tud lehetőséget adni routingra, mármint, hogy a ConnectChainer ki tudja választani hova, melyik szerverre kell kapcsolódnia, ha a protokoll erre lehetőséget ad. http és ftp-n kívül van olyan protokoll ami támogatja ezt a virtuális lehetőséget? És van is hozzá natív proxy a zorpon belül, persze. Jelenleg nem tudok ilyet, de ez az én hibám is lehet.
sqlnet -- Bazsi
Sziasztok! Koszonom a valaszokat! A HTTPS-es dologgal amit irtal utananeztem (nem talaltam a listaban kereses funkciot ezert google), de vagy nem mukodo vagy regi peldakat talaltam. Pliiz kuldj egy linket ha van ra pelda. Hogy egyszerubb legyen bemasolom a jelenlegi teszt configot: ... # Reverse HTTP Proxy class ReverseHostHttpProxy(HttpProxy): def config(self): HttpProxy.config(self) # Reverse HTTPS Proxy class ReverseHostHttpsProxy(PsslProxy): def config(self): PsslProxy.config(self); self.copy_to_server = TRUE; self.copy_to_client = TRUE; self.client_need_ssl = TRUE; self.server_need_ssl = TRUE; self.shutdown_soft = TRUE; self.client_verify_type = SSL_VERIFY_NONE; self.server_verify_type = SSL_VERIFY_NONE; self.client_cert = "/etc/zorp/certs/test.crt"; self.client_key = "/etc/zorp/keys/test.key"; self.stack_proxy = ReverseHostHttpProxy; # Instance definition def reverse_http(): Service( "http", ReverseHostHttpProxy, router=InbandRouter(forge_addr=TRUE), resolver=DNSResolver() ) Service( "https", ReverseHostHttpsProxy, router=InbandRouter(forge_addr=TRUE), chainer=SideStackChainer(ReverseHostHttpProxy) ) Listener(SockAddrInet('10.3.6.253', 1200), "http") Listener(SockAddrInet('10.3.6.253', 1201), "https") A cel: transparent http/http zorp proxy beallitasa oly modon, hogy ha https protokollon kerdezik o is https-en csatlakozzon a DNS alapjan meghatarozott cimhez. Jelenlegi allapot: A http igy megy, a https ezt dobja (kliens oldalon timeoutol): reverse_http[10227]: (reverse_http@zorp@test/https): Starting service; name='https' reverse_http[10227]: (reverse_http@zorp@test/https:1): Starting proxy instance; client_fd='18', client_address='AF_INET(10.3.6.55:43362)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(10.3.6.253:443)', client_protocol='TCP' reverse_http[10227]: (reverse_http@zorp@test/https:1/pssl): Proxy starting; class='ReverseHostHttpsProxy', module='pssl' reverse_http[11660]: (reverse_http@zorp@test/https:1/pssl): Side-stacking proxy instance; server_fd='21', client_fd='22', proxy_class='ReverseHostHttpProxy' reverse_http[11660]: (reverse_http@zorp@test/https:1/http): Proxy starting; class='ReverseHostHttpProxy', module='http' reverse_http[11661]: (reverse_http@zorp@test/https:1/http): Invalid line, embedded NUL character found; buffer='|' reverse_http[11661]: (reverse_http@zorp@test/https:1/http): Proxy ending; class='ReverseHostHttpProxy', module='http' reverse_http[11660]: (reverse_http@zorp@test/https:1/pssl): SSL handshake failed on the server side; error='error:00000000:(null):lib(0):(null):func(0):(null):reason(0)' reverse_http[11660]: (reverse_http@zorp@test/https:1/pssl): Proxy ending; class='ReverseHostHttpsProxy', module='pssl' reverse_http[11660]: (reverse_http@zorp@test/https:1): Ending proxy instance; reverse_http[11660]: (reverse_http@zorp@test/https:1/pssl/client): accounting info; type='stream', duration='0', sent='918', received='309' Kerdeseim: - mi a problema a https resszel? - van-e felesleges kod? - amennyiben mukodo konfig lesz belole mit celszeru meg rogziteni a configban biztonsagi es teljesitmeny szempontbol (amire idaig gondoltam ezek)? - hany zorp proces futhat - mennyi ramot ehet osszesen - halozati zonak definialasa es ez alapjan a szolgaltatas engedelyezese vagy tiltasa - hogyan definialhatok hibauzeneteket a zorp-ban vagy hogyan vaghatom felul mas html oldallal az altala generalt uzeneteket? udv, Lenard ago@lsc.hu wrote:
szia,
Pontositok, mert asszem eleg nagy butasagot kerdeztem... :(
nem kérdeztél butaságot. Amit leírsz egy élő dolog.
Szoval adott 1 fw ahol a Zorp csucsul, mogotte n darab webszerver. A szerverek mas-mas domaineket szolgalnak ki.
A megoldás nem az amit leírsz, hanem az, hogy vagy a tűzfal /etc/hosts fileban legyen benne az a belső címe a www.domain1.hu stb. gépeknek és akkor a zorp a névfeloldás alapján tudja majd, hogy merre irányítsa a csomagot. Sima HTTP-val működik, mindenfajta különösebb varázslat nélkül (bár egy ideje már csak copyzom az ilyen beállításokat, egyszer kell vele "megszenvedni"). "Gond" ott lesz, ha HTTPS-t is akarsz, azt is meg lehet oldani, de akkor egymás mellék kell stackelni a proxykat, a SideStackChainer-rel. A listaarchívumban volt már bőven hivatkozás rá.
hanem DNS alapjan visszaadott IP-t hasznalja?
na most ,ez alapján van DNS. Akkor viszont nem privát címeken vannak a webszerverek? Teszem azt a .129-es gép a tűzfal, ami routerként funciónál a .130,.131 astb. végű gépek előtt? Vagy egy belső DNS-ed van? Mert akkor a resolv.conf-ban kellene elsődleges névkiszolgálónak azt beállítanod. Vagy a fentebb említett /etc/hosts fájl is megoldás, ha kevés szerver van. 100%-ig korrekt persze a DNS.
üdv, Ago
_______________________________________________ zorp-hu mailing list zorp-hu@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/zorp-hu
On Fri, 2005-06-24 at 13:02 +0200, Pásztor Lénárd Zoltán wrote:
# Reverse HTTPS Proxy class ReverseHostHttpsProxy(PsslProxy):
def config(self): PsslProxy.config(self); self.copy_to_server = TRUE; self.copy_to_client = TRUE; self.client_need_ssl = TRUE; self.server_need_ssl = TRUE; self.shutdown_soft = TRUE; self.client_verify_type = SSL_VERIFY_NONE; self.server_verify_type = SSL_VERIFY_NONE; self.client_cert = "/etc/zorp/certs/test.crt"; self.client_key = "/etc/zorp/keys/test.key"; self.stack_proxy = ReverseHostHttpProxy;
# Instance definition def reverse_http(): Service( "https", ReverseHostHttpsProxy, router=InbandRouter(forge_addr=TRUE), chainer=SideStackChainer(ReverseHostHttpProxy) )
Melléstackelés esetén (SideStackChainer) az SSL proxy kimenete fog bekerűlni a mögötte lévő Proxyba. Vagyis Ha a self.server_need_ssl TRUE, akkor az SSL proxy titkosítja a tartlamat (legalábbis megpróbálja :) ) és azt kapja meg a Http Proxy. Ez egyiküknek sem jó. Éppen ezért, ha a szerver oldalon titkosított kapcsolatot szeretnél, akkor SSL szendvicset kell csinálnod. Ráadásul ilyenkor nem stack-elünk az SSL-be semmit, tehát nem kell e self.stack_proxy, mert így szegény Http proxy kétszer is fog találkozni az adattal. Vagyis SSL --- Http --- SSL formában. Es az első SSL-nél a szerver oldal ne legyen titkosított, a másodiknál a kliens oldal. Ja és a chainer definíció: chainer=SideStackChainer(ReverseHostHttpProxy, SideStackChainer(RightSSLProxy)) -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
Ha jol ertem amit irtal akkor 2 https proxyra van szuksegem. Igy a configom erre valtozott: # HTTP Proxy class HTTPProxy(HttpProxy): def config(self): HttpProxy.config(self) # HTTPS Proxy - Listener class HTTPSListener(PsslProxy): def config(self): PsslProxy.config(self); self.copy_to_server = TRUE; self.copy_to_client = TRUE; self.client_need_ssl = TRUE; self.server_need_ssl = FALSE; self.shutdown_soft = TRUE; self.client_verify_type = SSL_VERIFY_NONE; self.server_verify_type = SSL_VERIFY_NONE; self.client_cert = "/etc/zorp/certs/test.crt"; self.client_key = "/etc/zorp/keys/test.key"; # HTTPS Proxy - Worker class HTTPSWorker(PsslProxy): def config(self): PsslProxy.config(self); self.copy_to_server = TRUE; self.copy_to_client = TRUE; self.client_need_ssl = FALSE; self.server_need_ssl = TRUE; self.shutdown_soft = TRUE; self.client_verify_type = SSL_VERIFY_NONE; self.server_verify_type = SSL_VERIFY_NONE; self.client_cert = "/etc/zorp/certs/test.crt"; self.client_key = "/etc/zorp/keys/test.key"; # Instance definition def reverse_http(): Service( "http", HTTPProxy, router=InbandRouter(forge_addr=TRUE), resolver=DNSResolver() ) Service( "https", HTTPSListener, router=InbandRouter(forge_addr=TRUE), chainer=SideStackChainer( HTTPProxy, SideStackChainer(HTTPSWorker) ) ) Listener(SockAddrInet('10.3.6.253', 1200), "http") Listener(SockAddrInet('10.3.6.253', 1201), "https") Igy szeretnem: SSL Client -> HTTPSListener -> HTTPProxy -> HTTPSWorker -> SSL Server Mostmar eljut a keres az SSL Server-hez, csak ahogy nezem a 80-as portja jon be a 443 helyett. Tenyleg? Honnan tudja a Zorp, hogy melyik portra csatlakozzon (ok ha az url-ben nincs megadva akkor default 80, 443). Meg lehet ezt kulon adni? Gondolom itt nem az lesz a baj, hogy kulon meg kene adnom. Felek meg mindig hibas a config.
Melléstackelés esetén (SideStackChainer) az SSL proxy kimenete fog bekerűlni a mögötte lévő Proxyba. Vagyis Ha a self.server_need_ssl TRUE, akkor az SSL proxy titkosítja a tartlamat (legalábbis megpróbálja :) ) és azt kapja meg a Http Proxy. Ez egyiküknek sem jó. Éppen ezért, ha a szerver oldalon titkosított kapcsolatot szeretnél, akkor SSL szendvicset kell csinálnod. Ráadásul ilyenkor nem stack-elünk az SSL-be semmit, tehát nem kell e self.stack_proxy, mert így szegény Http proxy kétszer is fog találkozni az adattal.
Vagyis SSL --- Http --- SSL formában.
Es az első SSL-nél a szerver oldal ne legyen titkosított, a másodiknál a kliens oldal.
Ja és a chainer definíció: chainer=SideStackChainer(ReverseHostHttpProxy, SideStackChainer(RightSSLProxy))
On Fri, 2005-06-24 at 14:10 +0200, Pásztor Lénárd Zoltán wrote:
Mostmar eljut a keres az SSL Server-hez, csak ahogy nezem a 80-as portja jon be a 443 helyett. Tenyleg? Honnan tudja a Zorp, hogy melyik portra csatlakozzon (ok ha az url-ben nincs megadva akkor default 80, 443). Meg lehet ezt kulon adni?
Igen. Mégpedig úgy, hogy a HttpProxy-nak megmondod, hogy a default port nem a 80, hanem a 443. (A HttpProxy semmit sem tud arrol, hogy SSL-ben jött a kapcsolat, viszont ő irányítja az InbandRouter-t) Ezt a self.default_port opcióval tudod megtenni.
Gondolom itt nem az lesz a baj, hogy kulon meg kene adnom. Felek meg mindig hibas a config.
De igen. -- Szalay Attila BalaBit IT Biztonságtechnikai Kft. tel:(36-1)-371-05-40 1116 Bp. Csurgoi ut 20/b fax:(36-1)-208-08-75 http://www.balabit.hu/
Most mar ez is teljesen vilagos. Ket utat latok. Vagy a mar definialt http proxy-ba teszek egy logikat, hogy el tudja donteni, hogy kell-e portot valtoztatni, vagy letrehozok meg egy http proxy classt, amibe ezt beegetem es ezt hivom. Az utobbit probaltam, az megy, de gondolom az elobbi lenne a 'szep' megoldas. Ezt meg lehet tenni? Tovabba van meg par kerdesem amiben kerem segitsegeteket: - mit celszeru/lehetseges rogziteni a configban biztonsagi es teljesitmeny szempontbol (amire idaig gondoltam ezek)? - hany zorp proces futhat - mennyi ramot ehet osszesen - halozati zonak definialasa es ez alapjan a szolgaltatas engedelyezese vagy tiltasa - hogyan definialhatok hibauzeneteket a zorp-ban vagy hogyan vaghatom felul mas html oldallal az altala generalt uzeneteket? - van-e elerheto dokumentacio ami lerija a zorp-ban levo fuggvenyek mukodeset, parameterezesi lehetosegeit? udv, Lenard Szalay Attila wrote:
On Fri, 2005-06-24 at 14:10 +0200, Pásztor Lénárd Zoltán wrote:
Mostmar eljut a keres az SSL Server-hez, csak ahogy nezem a 80-as portja jon be a 443 helyett. Tenyleg? Honnan tudja a Zorp, hogy melyik portra csatlakozzon (ok ha az url-ben nincs megadva akkor default 80, 443). Meg lehet ezt kulon adni?
Igen. Mégpedig úgy, hogy a HttpProxy-nak megmondod, hogy a default port nem a 80, hanem a 443. (A HttpProxy semmit sem tud arrol, hogy SSL-ben jött a kapcsolat, viszont ő irányítja az InbandRouter-t) Ezt a self.default_port opcióval tudod megtenni.
Gondolom itt nem az lesz a baj, hogy kulon meg kene adnom. Felek meg mindig hibas a config.
De igen.
participants (6)
-
ago＠lsc.hu
-
Balazs Scheidler
-
KOVACS Krisztian
-
Major Csaba
-
Pásztor Lénárd Zoltán
-
Szalay Attila