A default policy szép nagy http open post proxy, és ezért blacklistre rakták egyik gépemet a dsbl-en :-#, viszont ez mindenkit fenyeget, akit megtalálnak, ha jól látom. Itt a teszt trace-e (nem túl szószátyár, de legalább azonnal feljelent :-#): connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("xxx.xxx.xxx.xxx")}, 16) = 0 send(5, "POST http://205.231.29.241:25/ HTTP/1.1\r\nHost: http://205.231.29.241:25/\r\nConnection: close\r\nContent-length: 395\r\n\r\nHELO [xxx.xxx.xxx.xxx]\r\nMAIL FROM :<dsbltester@"..., 511, 0) = 511 recv(5, "220 ", 8192, 0) = 4 recv(5, "dsbl [xxx.xxx.xxx.xxx]\r\n", 8192, 0) = 22 recv(5, "502 huh?\r\n502 huh?\r\n502 huh?\r\n502 huh?\r\n502 huh?\r\n502 huh?\r\n", 8192, 0) = 60 recv(5, "250 ok\r\n250 ok\r\n250 ok\r\n354 go ahead\r\n250 listed [xxx.xxx.xxx.xxx]\r\n221 goodbye\r\n", 8192, 0) = 79 recv(5, "", 8192, 0) = 0 close(5) = 0 Mit tudok tenni ez ellen? Miért fogadja el az idegen szervernek szóló post-ot? -- Gabor HALASZ <halasz.g@freemail.hu>
On Fri, 2004-10-29 at 12:16, Gabor Halasz wrote:
A default policy szép nagy http open post proxy, és ezért blacklistre rakták egyik gépemet a dsbl-en :-#, viszont ez mindenkit fenyeget, akit megtalálnak, ha jól látom.
Kellene az ehhez tartozo zorp konfig, mert ez valoban nem volt tul bobeszedu. Ez elvileg csak akkor lehetne, ha inband router-t hasznalsz, de akkor is default-bol csak 80-as portra enged meg becsattani. Valamint az access controll miatt eleg valoszinutlen, hogy mondjuk valaki az internet iranybol becsatlakozzon egy zorpra, es utana az internet iranyaba vissza is csatlakozzon (legalabbis ertelmes konfigot feltetelezve) MCS
Major Csaba wrote:
Kellene az ehhez tartozo zorp konfig, mert ez valoban nem volt tul bobeszedu. Ez elvileg csak akkor lehetne, ha inband router-t hasznalsz, de akkor is default-bol csak 80-as portra enged meg becsattani.
InetZone("Wan", "0.0.0.0/0", inbound_services=["Ftp_S", "Http_S", "HttpS_S", "ImapS_S", "Neptun_S", "PopS_S", "Ssh_S", "Imap_S", "Pop_S"], outbound_services=["*"]) class Http_C(HttpProxy): def config(self): HttpProxy.config(self) self.transparent_mode = 1 self.request_headers["X-Host"] = (HTTP_HDR_INSERT, self.session.client_address.ip_s) Service("Http_S", Http_C, InbandRouter()) Listener(SockAddrInet("xxx.xxx.xxx.xxx", 80), "Http_S")
Valamint az access controll miatt eleg valoszinutlen, hogy mondjuk valaki az internet iranybol becsatlakozzon egy zorpra, es utana az internet iranyaba vissza is csatlakozzon (legalabbis ertelmes konfigot feltetelezve)
Akkor hol a hiba? -- Gabor HALASZ <halasz.g@freemail.hu>
Szia! On Fri, 2004-10-29 at 13:51, Gabor Halasz wrote:
InetZone("Wan", "0.0.0.0/0", inbound_services=["Ftp_S", "Http_S", "HttpS_S", "ImapS_S", "Neptun_S", "PopS_S", "Ssh_S", "Imap_S", "Pop_S"], outbound_services=["*"])
Az elso hiba, hogy itt minden visszaengedtel. Ez durvan azt jelenti, hogy ha a Http_S-t (is meg minden mast) visszaengedtel a Wan zonaba, akkor ne csodalkozz, hogy a Zorp kienged, ha ki akar menni!
Service("Http_S", Http_C, InbandRouter())
InbandRouter-t csak akkor hasznalj, ha: * nem transzparens proxyd van * egy fix IP-n es porton figyel * host header alapjan tobb szerver fele akarod tovabb kuldeni a kapcsolatot
Valamint az access controll miatt eleg valoszinutlen, hogy mondjuk valaki az internet iranybol becsatlakozzon egy zorpra, es utana az internet iranyaba vissza is csatlakozzon (legalabbis ertelmes konfigot feltetelezve)
Pont ezt rontottad el, mert az access controlban _megengedted_ ezt. Es meg valami: Meg lehetne oldani, hogy ellenorizzuk a celportot, de ez a konfig akkor is open proxy lenne, mert jol hasznalhato (a kliens szempontjebol) anonymizer-nek. Mivel barmit le tud kerni a te nevedben... Udv, -- HÖLTZL Péter BalaBit IT Kft | Tel: +36 1 371-0540 | GnuPG Fingerprint: holtzl.peter@balabit.hu | Mobil: +36 20 366-9667 | 796B C9D3 E492 B006 C8B2 http://www.balabit.hu/ | Fax: +36 1 208-0875 | 4D1F 5320 28E3 9A1B 3FC6
HÖLTZL Péter wrote:
Szia!
On Fri, 2004-10-29 at 13:51, Gabor Halasz wrote:
InetZone("Wan", "0.0.0.0/0", inbound_services=["Ftp_S", "Http_S", "HttpS_S", "ImapS_S", "Neptun_S", "PopS_S", "Ssh_S", "Imap_S", "Pop_S"], outbound_services=["*"])
Az elso hiba, hogy itt minden visszaengedtel. Ez durvan azt jelenti, hogy ha a Http_S-t (is meg minden mast) visszaengedtel a Wan zonaba, akkor ne csodalkozz, hogy a Zorp kienged, ha ki akar menni!
Igen, mindent ki akarok engedni, amit a zorp generál, lévén ez a bordergw.
Service("Http_S", Http_C, InbandRouter())
InbandRouter-t csak akkor hasznalj, ha: * nem transzparens proxyd van
Nem transzparens proxy
* egy fix IP-n es porton figyel
Egy fix ip/porton figyel
* host header alapjan tobb szerver fele akarod tovabb kuldeni a kapcsolatot
host header alapján több szerver felé akarom tovább küldeni a kapcsolatot
Valamint az access controll miatt eleg valoszinutlen, hogy mondjuk valaki az internet iranybol becsatlakozzon egy zorpra, es utana az internet iranyaba vissza is csatlakozzon (legalabbis ertelmes konfigot feltetelezve)
Pont ezt rontottad el, mert az access controlban _megengedted_ ezt.
És? Hogyan tiltsam ki?
Es meg valami:
Meg lehetne oldani, hogy ellenorizzuk a celportot, de ez a konfig akkor is open proxy lenne, mert jol hasznalhato (a kliens szempontjebol) anonymizer-nek. Mivel barmit le tud kerni a te nevedben...
Nem a célportot kell ellenőrizni, hanem a dest addresst. -- Gabor HALASZ <halasz.g@freemail.hu>
hali, On Fri, 2004-10-29 at 18:18, Gabor Halasz wrote:
HÖLTZL Péter wrote:
Szia!
On Fri, 2004-10-29 at 13:51, Gabor Halasz wrote:
InetZone("Wan", "0.0.0.0/0", inbound_services=["Ftp_S", "Http_S", "HttpS_S", "ImapS_S", "Neptun_S", "PopS_S", "Ssh_S", "Imap_S", "Pop_S"], outbound_services=["*"])
Service("Http_S", Http_C, InbandRouter())
InbandRouter-t csak akkor hasznalj, ha: * nem transzparens proxyd van
Nem transzparens proxy
* egy fix IP-n es porton figyel
Egy fix ip/porton figyel
* host header alapjan tobb szerver fele akarod tovabb kuldeni a kapcsolatot
host header alapján több szerver felé akarom tovább küldeni a kapcsolatot
hmm.. ez most kintrol jon befele, vagy bentrol megy kifele? ha bentol megy kifele, akkor TransparentRouter, ha kintrol megy befele akkor InbandRouter, de ne engedd vissza.
Valamint az access controll miatt eleg valoszinutlen, hogy mondjuk valaki az internet iranybol becsatlakozzon egy zorpra, es utana az internet iranyaba vissza is csatlakozzon (legalabbis ertelmes konfigot feltetelezve)
Pont ezt rontottad el, mert az access controlban _megengedted_ ezt.
És? Hogyan tiltsam ki?
ld lent.
Es meg valami:
Meg lehetne oldani, hogy ellenorizzuk a celportot, de ez a konfig akkor is open proxy lenne, mert jol hasznalhato (a kliens szempontjebol) anonymizer-nek. Mivel barmit le tud kerni a te nevedben...
Nem a célportot kell ellenőrizni, hanem a dest addresst.
az engedelyezett utvonalakat az access control-lal irod le. azaz a zonaidnal az inbound es outbound services tombokkel. te beengeded a wan iranybol a HTTP kereseket, majd visszaengeded ugyanezt a szolgaltatast, ezzel effektive engedelyezed a "pattintast". Vedd ki a '*'-ot a Wan zona inbound_services-ei kozul. a zorp kizarolag a zonakat hasznalja a "cim" ellenorzesre, amugy nincs arrol informacioja, hogy mi van kint, es mi van bent. A default policy-ban levo '*' mintakent szerepel, eles konfigban erosen ellenjavalt. A mintabol is kiveszem, a felreerteseket elkerulendo. -- Bazsi
Balazs Scheidler wrote:
te beengeded a wan iranybol a HTTP kereseket, majd visszaengeded ugyanezt a szolgaltatast, ezzel effektive engedelyezed a "pattintast". Vedd ki a '*'-ot a Wan zona inbound_services-ei kozul.
?? Ott nincs. Viszont ha az outbound-ból veszem ki, akkor nem megy semmi.
a zorp kizarolag a zonakat hasznalja a "cim" ellenorzesre, amugy nincs arrol informacioja, hogy mi van kint, es mi van bent.
Nem kellene/lehetne tiltani, hogy egy proxy ugyanabba a zónába ne mehessen vissza, ahonnan jött a kapcsolat? Ilyen forgalomnak nem sok haszna lenne. -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, 2004-11-02 at 11:02, Gabor Halasz wrote:
Balazs Scheidler wrote:
te beengeded a wan iranybol a HTTP kereseket, majd visszaengeded ugyanezt a szolgaltatast, ezzel effektive engedelyezed a "pattintast". Vedd ki a '*'-ot a Wan zona inbound_services-ei kozul.
?? Ott nincs. Viszont ha az outbound-ból veszem ki, akkor nem megy semmi.
a zonaidnal ne hasznalj csillagot egyaltalan, csak teljes service nevet. outbound - innen indulhat a kliens inbound - itt talalhato a szerver
a zorp kizarolag a zonakat hasznalja a "cim" ellenorzesre, amugy nincs arrol informacioja, hogy mi van kint, es mi van bent.
Nem kellene/lehetne tiltani, hogy egy proxy ugyanabba a zónába ne mehessen vissza, ahonnan jött a kapcsolat? Ilyen forgalomnak nem sok haszna lenne.
marpedig en tudok olyan helyrol ahol igy mukodik. (pl. nem transzparens HTTP szolgaltatas a lokalis halozaton, ahol virus-szures tortenik, es el akarjak erni a lokalis halozaton levo szervereket is) -- Bazsi
Balazs Scheidler wrote:
marpedig en tudok olyan helyrol ahol igy mukodik. (pl. nem transzparens HTTP szolgaltatas a lokalis halozaton, ahol virus-szures tortenik, es el akarjak erni a lokalis halozaton levo szervereket is)
Lehetséges, de szerintem érdemes lenne megfontolni; pl a kernelben az rp_filter-t is többnyire jó szolgálatot tesz, csak kevés esetben kell kikapcsolni. -- Gabor HALASZ <halasz.g@freemail.hu>
Gabor Halasz wrote:
Balazs Scheidler wrote:
marpedig en tudok olyan helyrol ahol igy mukodik. (pl. nem transzparens HTTP szolgaltatas a lokalis halozaton, ahol virus-szures tortenik, es el akarjak erni a lokalis halozaton levo szervereket is)
Lehetséges, de szerintem érdemes lenne megfontolni; pl a kernelben az rp_filter-t is többnyire jó szolgálatot tesz, csak kevés esetben kell kikapcsolni.
Mindenhol, ahol a teljesitmeny fontos, ki KELL kapcsolni, mert tul nagy az overhead-je. Zorp eseteben kulonosen fontos kikapcsolni.... -- Geller Sandor wildy@balabit.hu
Gellér Sándor wrote:
Mindenhol, ahol a teljesitmeny fontos, ki KELL kapcsolni, mert tul nagy az overhead-je. Zorp eseteben kulonosen fontos kikapcsolni....
Csak példa volt, lehet, hogy nem a legjobb. -- Gabor HALASZ <halasz.g@freemail.hu>
Balazs Scheidler wrote:
a zonaidnal ne hasznalj csillagot egyaltalan, csak teljes service nevet.
outbound - innen indulhat a kliens inbound - itt talalhato a szerver
Most ez van: InetZone("Wan", "0.0.0.0/0", inbound_services=["Http_S"], outbound_services=["Http_S"]) InetZone("Dmz", "192.168.1.0/24", inbound_services=[], outbound_services=[]) def Wan(): Service("Http_S", Http_C, InbandRouter()) Listener(SockAddrInet("xxx.xxx.xxx.xxx", 80), "Http_S") debug(0, "Policy bootstrap OK"); Ez így openproxy. Ha kiveszem az inboundból, akkor nem konnektál a szerverekhez és az errorpaget adja vissza, ha az outboundban nem szerepel, akkor eldobja a kapcsolatot. Ez szerintem normális, csak azt nem értem még mindig, hogyan tudom azt szabályozni, hogy csak a válasz mehessen a Wan zóna irányába. -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, Nov 02, 2004 at 12:39:40PM +0100, Gabor Halasz wrote:
Balazs Scheidler wrote:
a zonaidnal ne hasznalj csillagot egyaltalan, csak teljes service nevet.
outbound - innen indulhat a kliens inbound - itt talalhato a szerver
Most ez van:
InetZone("Wan", "0.0.0.0/0", inbound_services=["Http_S"], outbound_services=["Http_S"])
InetZone("Dmz", "192.168.1.0/24", inbound_services=[], outbound_services=[])
def Wan():
Service("Http_S", Http_C, InbandRouter()) Listener(SockAddrInet("xxx.xxx.xxx.xxx", 80), "Http_S")
debug(0, "Policy bootstrap OK");
Ez így openproxy. Ha kiveszem az inboundból, akkor nem konnektál a szerverekhez és az errorpaget adja vissza, ha az outboundban nem szerepel, akkor eldobja a kapcsolatot. Ez szerintem normális, csak azt nem értem még mindig, hogyan tudom azt szabályozni, hogy csak a válasz mehessen a Wan zóna irányába.
Egesz pontosan mit akarsz megvalositani? Mert ez igy - ahogy irod is - nyilvanvaloan openproxy. Valoban azt akarod, hogy a wan fele levo kliensek nezzenek wan fele eso oldalakat? Gyula
Kerekes Gyula wrote:
Egesz pontosan mit akarsz megvalositani? Mert ez igy - ahogy irod is - nyilvanvaloan openproxy. Valoban azt akarod, hogy a wan fele levo kliensek nezzenek wan fele eso oldalakat?
Nem. Éppen ez a probléma. Mégegyszer: Van egy public ip-m, arra mutat egy halom A rekord, ezek http forgalmát akarom namebased különböző szerverekhez routolni, akik a Dmz zónában laknak. Ehhez tartozik a fenti konfig azzal a kiegészítéssel, hogy a firewall a privát dns-től kapja a hostneveket, tehát a HOST alapján megfelelően routol az inbandrouter. A problémám csak az, hogy nem tudom korlátozni, hova routoljon (illetve tudok filtereket írni, de ezt akartam elkerülni, talán mögé rakni még egy proxyt). -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, Nov 02, 2004 at 01:21:44PM +0100, Gabor Halasz wrote:
Kerekes Gyula wrote:
Egesz pontosan mit akarsz megvalositani? Mert ez igy - ahogy irod is - nyilvanvaloan openproxy. Valoban azt akarod, hogy a wan fele levo kliensek nezzenek wan fele eso oldalakat?
Nem. Éppen ez a probléma. Mégegyszer: Van egy public ip-m, arra mutat egy halom A rekord, ezek http forgalmát akarom namebased különböző szerverekhez routolni, akik a Dmz zónában laknak. Ehhez tartozik a fenti konfig azzal a kiegészítéssel, hogy a firewall a privát dns-től kapja a hostneveket, tehát a HOST alapján megfelelően routol az inbandrouter. A problémám csak az, hogy nem tudom korlátozni, hova routoljon (illetve tudok filtereket írni, de ezt akartam elkerülni, talán mögé rakni még egy proxyt).
Ez nem megoldas? InetZone("Wan", "0.0.0.0/0", inbound_services=[""], outbound_services=["Http_S"]) InetZone("Dmz", "192.168.1.0/24", inbound_services=["Http_S"], outbound_services=[]) Igy a Http_S service csak a 192.168.1.0/24 cimekre mehet (tehat a Dmz zonaba) Gyula
Kerekes Gyula wrote:
InetZone("Wan", "0.0.0.0/0", inbound_services=[""], outbound_services=["Http_S"])
InetZone("Dmz", "192.168.1.0/24", inbound_services=["Http_S"], outbound_services=[])
Igy a Http_S service csak a 192.168.1.0/24 cimekre mehet (tehat a Dmz zonaba)
Ezt próbáltam már egyszer, de azért használt, mert rájöttem a gyogyóra :) A turpisság: valami jótét lélek elírta a specifikációt, rossz a dmz zóna definíciója (csak a http forgalmat routolják egy másik netre, hogy nehezebb legyen észrevenni), 23 bites maszkkal már jó. Kösz. Tanulságképpen: kissé félrevezetőek az ilyen hibaüzenetek: Nov 2 14:05:29 firewall fromWan[28899]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Proxy starting; class='Http_C', module='http' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Accounting; command='GET', url='http://www.domain.hu/' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0): Inbound service not permitted; service='Http_S', zone='Zone(Wan, 0.0.0.0/0)' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): DAC policy violation; info='None' Nov 2 14:05:29 firewall fromWan[28899]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Proxy ending; class='Http_C', module='http' Értem, miért ezt írja, csak keveset segít a probléma megoldásában. -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, 2004-11-02 at 14:14, Gabor Halasz wrote:
Kerekes Gyula wrote:
Kösz.
Tanulságképpen: kissé félrevezetőek az ilyen hibaüzenetek:
Nov 2 14:05:29 firewall fromWan[28899]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Proxy starting; class='Http_C', module='http' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Accounting; command='GET', url='http://www.domain.hu/' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0): Inbound service not permitted; service='Http_S', zone='Zone(Wan, 0.0.0.0/0)' Nov 2 14:05:29 firewall fromWan[28906]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): DAC policy violation; info='None' Nov 2 14:05:29 firewall fromWan[28899]: (fromWan@zorp@firewall.domain.hu/Http_S:0/http): Proxy ending; class='Http_C', module='http'
Értem, miért ezt írja, csak keveset segít a probléma megoldásában.
Pontosan melyik uzeneten kellene javitani szerinted? -- Bazsi
Balazs Scheidler wrote:
Pontosan melyik uzeneten kellene javitani szerinted?
(fromWan@zorp@firewall.domain.hu/Http_S:0): Inbound service not permitted; service='Http_S', zone='Zone(Wan, 0.0.0.0/0)' Nem arra az zónára panaszkodik, amelyik a hibát okozza, de ha jól gondolom, akkor ez a helyes működése, hiszen a 0/0 illeszkedik. Viszont ha tiltani tudnám, hogy a proxy ugyanabba a zónába kalandozzon vissza, ahonnan a kliens érkezett, akkor adhatna más üzenetet, miszerint nincs ilyen zóna vagy hasonlót. -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, 2004-11-02 at 15:07, Gabor Halasz wrote:
Viszont ha tiltani tudnám, hogy a proxy ugyanabba a zónába kalandozzon vissza, ahonnan a kliens érkezett, akkor adhatna más üzenetet, miszerint nincs ilyen zóna vagy hasonlót.
mondjuk egy olyan üzenet, hogy "inbound and outbound zone is the same" segitene? -- HÖLTZL Péter BalaBit IT Kft | Tel: +36 1 371-0540 | GnuPG Fingerprint: holtzl.peter@balabit.hu | Mobil: +36 20 366-9667 | 796B C9D3 E492 B006 C8B2 http://www.balabit.hu/ | Fax: +36 1 208-0875 | 4D1F 5320 28E3 9A1B 3FC6
On Tue, 2004-11-02 at 15:21, HÖLTZL Péter wrote:
mondjuk egy olyan üzenet, hogy "inbound and outbound zone is the same" segitene?
s/is/are/g -- HÖLTZL Péter BalaBit IT Kft | Tel: +36 1 371-0540 | GnuPG Fingerprint: holtzl.peter@balabit.hu | Mobil: +36 20 366-9667 | 796B C9D3 E492 B006 C8B2 http://www.balabit.hu/ | Fax: +36 1 208-0875 | 4D1F 5320 28E3 9A1B 3FC6
HÖLTZL Péter wrote:
On Tue, 2004-11-02 at 15:07, Gabor Halasz wrote:
Viszont ha tiltani tudnám, hogy a proxy ugyanabba a zónába kalandozzon vissza, ahonnan a kliens érkezett, akkor adhatna más üzenetet, miszerint nincs ilyen zóna vagy hasonlót.
mondjuk egy olyan üzenet, hogy "inbound and outbound zone is the same" segitene?
Ez mindenképpen hasznos információ, gyorsabban felderíthetők az elgépelések vagy az általam is elkövetett bénázás. -- Gabor HALASZ <halasz.g@freemail.hu>
On Tue, 2004-11-02 at 15:38, Gabor Halasz wrote:
HÖLTZL Péter wrote:
On Tue, 2004-11-02 at 15:07, Gabor Halasz wrote:
Viszont ha tiltani tudnám, hogy a proxy ugyanabba a zónába kalandozzon vissza, ahonnan a kliens érkezett, akkor adhatna más üzenetet, miszerint nincs ilyen zóna vagy hasonlót.
mondjuk egy olyan üzenet, hogy "inbound and outbound zone is the same" segitene?
Ez mindenképpen hasznos információ, gyorsabban felderíthetők az elgépelések vagy az általam is elkövetett bénázás.
mar csak az a kerdes, hogy ezt az uzenetet mi triggerelne. onmagaban a korabban emlitett konfiguracio meg nem indokolja, ahogy mar mondtam teljesen legalisan is elofordulhat ez a helyzet. -- Bazsi
Balazs Scheidler wrote:
mar csak az a kerdes, hogy ezt az uzenetet mi triggerelne.
Ezt nem tudom, eddig nem éreztem kéztetést, hogy a forrást nézegessem.
onmagaban a korabban emlitett konfiguracio meg nem indokolja, ahogy mar mondtam teljesen legalisan is elofordulhat ez a helyzet.
Ahogy észrevettem, minden legális forgalmat logol :), szerintem nagyobb loglevel esetén elférne egy ilyen üzenet. -- Gabor HALASZ <halasz.g@freemail.hu>
On Wed, 2004-11-03 at 12:26, Gabor Halasz wrote:
Balazs Scheidler wrote:
mar csak az a kerdes, hogy ezt az uzenetet mi triggerelne.
Ezt nem tudom, eddig nem éreztem kéztetést, hogy a forrást nézegessem.
nem forrasban gondolkozom, hanem felhasznaloi feluletben. azaz mikor tekintse hibanak azt, hogy a forraszona == celzona
onmagaban a korabban emlitett konfiguracio meg nem indokolja, ahogy mar mondtam teljesen legalisan is elofordulhat ez a helyzet.
Ahogy észrevettem, minden legális forgalmat logol :), szerintem nagyobb loglevel esetén elférne egy ilyen üzenet.
ja, ha nem kell levagni a kapcsolatot, akkor termeszetesen elfer. -- Bazsi
Balazs Scheidler wrote:
nem forrasban gondolkozom, hanem felhasznaloi feluletben. azaz mikor tekintse hibanak azt, hogy a forraszona == celzona
Nem kell feltétlenül hibának tekinteni, mint már írtad. Esetleg akkor tekinthetné hibának, ha én beállítom neki (talán a zóna definiálásakor lenne logikus), és akkor bonthatna is, különben csak (megfelelő loglevel esetén) logolna. -- Gabor HALASZ <halasz.g@freemail.hu>
Gabor Halasz wrote:
Nem kell feltétlenül hibának tekinteni, mint már írtad. Esetleg akkor tekinthetné hibának, ha én beállítom neki (talán a zóna definiálásakor lenne logikus), és akkor bonthatna is,
Az jutott még eszembe, hogy opcionális harmadik listaként lehetne definiálni azokat a service-okat a zóna definiálásakor, amelyek nem fordulhatnak vissza, és akkor kellemesen konfigurálható feature lenne. -- Gabor HALASZ <halasz.g@freemail.hu>
On Thu, Nov 04, 2004 at 10:16:28AM +0100, Gabor Halasz wrote:
Gabor Halasz wrote:
Nem kell feltétlenül hibának tekinteni, mint már írtad. Esetleg akkor tekinthetné hibának, ha én beállítom neki (talán a zóna definiálásakor lenne logikus), és akkor bonthatna is,
Az jutott még eszembe, hogy opcionális harmadik listaként lehetne definiálni azokat a service-okat a zóna definiálásakor, amelyek nem fordulhatnak vissza, és akkor kellemesen konfigurálható feature lenne.
Lehet, hogy en nem ertem egeszen, de ha nem akarod, hogy visszaforduljon, nem egyszerubb, ha siman nem irod be a service-t mindket iranyhoz? Gyula
Kerekes Gyula wrote:
Lehet, hogy en nem ertem egeszen, de ha nem akarod, hogy visszaforduljon, nem egyszerubb, ha siman nem irod be a service-t mindket iranyhoz?
Jogos, elvesztem a részletekben. -- Gabor HALASZ <halasz.g@freemail.hu>
participants (6)
-
Balazs Scheidler
-
Gabor Halasz
-
Gellér Sándor
-
HÖLTZL Péter
-
Kerekes Gyula
-
Major Csaba