Hello, A 2.0.2 Zorp néha kapcsolat hibával visszadobja a http kérést. Az alap szitu, hogy egy szerver zónát véd a zorp. Igen szép számú kérés érkezik. Általában 150-180 zorp thread fut egyszerre. Kernel 2.4.20+rsbac+tproxy. Debian woody. Itt a log részlet, amikor ilyet csinál: Jun 12 13:46:15 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:d8ba, sr->faddr=799238c3:d9ba, flags=90005 Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): Error in setsockopt(SOL_IP, IP_TPROXY_ASSIGN), netfilter-tproxy support required; fd='614', error='Invalid argument' Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): bind() failed; error='Invalid argument' Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): Server connection failure; server_address='AF_INET(1.2.3.4:8888)', server_zone='Zone(vedett, 1.2.3.0/24)', server_local='None' Mit lehet tenni ezek elkerüléséért? Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
On Thu, Jun 12, 2003 at 05:06:41PM +0200, Czakó Krisztián wrote:
Hello,
A 2.0.2 Zorp néha kapcsolat hibával visszadobja a http kérést. Az alap szitu, hogy egy szerver zónát véd a zorp. Igen szép számú kérés érkezik. Általában 150-180 zorp thread fut egyszerre. Kernel 2.4.20+rsbac+tproxy. Debian woody.
Itt a log részlet, amikor ilyet csinál:
Jun 12 13:46:15 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:d8ba, sr->faddr=799238c3:d9ba, flags=90005 Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): Error in setsockopt(SOL_IP, IP_TPROXY_ASSIGN), netfilter-tproxy support required; fd='614', error='Invalid argument' Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): bind() failed; error='Invalid argument' Jun 12 13:46:15 fw new_internet_http[16455]: (firewall@fw.hu/http:16957/http): Server connection failure; server_address='AF_INET(1.2.3.4:8888)', server_zone='Zone(vedett, 1.2.3.0/24)', server_local='None'
Mit lehet tenni ezek elkerüléséért?
a kernel modul ezekben az esetekben ad EINVAL-t: - ha a bindolt socket mar kapcsolodott (azaz nem frissen van nyitva) - ha a setsockopt bemeno parametere rossz meretu - ha a bindolt socket nem UDP/TCP - ha a socket nincs autobindolva ill ez a bind nem fully qualified (azaz ip vagy a portszam 0) - ha az autobindcim utkozes van (azaz ketszer ugyanahhoz az autobind cimhez akar idegencim hamisitast kerni) ezek kozul az utolso kettot erzem elkepzelhetonek. hmm... most neztem meg a kernel uzenetedet, ez alapjan egyertelmu, hogy az utolso eset jott be. a flags alapjan az latszik, hogy a megtalalt korabbi bejegyzest szinten kapcsolodasra hasznaltak fel. valami race condition-t sejtek, ugyanis ez azt jelenti, hogy a TPROXY jelenleg ket olyan socketet lat, aminek ugyanaz a local cime. ez szerintem akkor kepzelheto el, ha 1) preemptiv kernel patched 2) vagy tobb procid van mivel a TPROXY a socket lezarasanak vegen veszi ki a sajat hashebol a socket cimet, ezert elofordulhat az, hogy a socket mar kikerult a TCP-s socket hashbol, de meg nem torlodott a TPROXY-s hashbol, kozben viszont egy masik thread mar bindolta (sikeresen, hiszen a TCP hashben mar nincs bent), es probalt ra IP_TPROXY_ASSIGN-t hivni. Ez mondjuk azert eleg nehezen valosul meg, plane mivel a socketek lezaras utan egy darabig TIME_WAIT-ben maradnak (kb 2 perc) raadasul az autobind sorban egymas utan veszi a portokat, tehat ehhez az is kell, hogy az osszes port foglalt legyen a local port range tartomanyban. ez szinte lehetetlen. a local port range defaultbol 32768-61000 (2.4-es kernelen) itt most a 47832-es portrol van szo. hany nyitott socketed van az autobind-ip -re bindolva? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
2003-06-12, cs keltezéssel Balazs Scheidler ezt írta:
valami race condition-t sejtek, ugyanis ez azt jelenti, hogy a TPROXY jelenleg ket olyan socketet lat, aminek ugyanaz a local cime.
ez szerintem akkor kepzelheto el, ha 1) preemptiv kernel patched 2) vagy tobb procid van
Egyik sem. Gyári 2.4.20 + rsbac + xfs + freeswan + tproxy.
mivel a TPROXY a socket lezarasanak vegen veszi ki a sajat hashebol a socket cimet, ezert elofordulhat az, hogy a socket mar kikerult a TCP-s socket hashbol, de meg nem torlodott a TPROXY-s hashbol, kozben viszont egy masik thread mar bindolta (sikeresen, hiszen a TCP hashben mar nincs bent), es probalt ra IP_TPROXY_ASSIGN-t hivni.
Ez mondjuk azert eleg nehezen valosul meg, plane mivel a socketek lezaras utan egy darabig TIME_WAIT-ben maradnak (kb 2 perc)
raadasul az autobind sorban egymas utan veszi a portokat, tehat ehhez az is kell, hogy az osszes port foglalt legyen a local port range tartomanyban.
ez szinte lehetetlen. a local port range defaultbol 32768-61000 (2.4-es kernelen) itt most a 47832-es portrol van szo.
hany nyitott socketed van az autobind-ip -re bindolva?
Ezt hogyan számolom meg egyszerűen? Annyi adalék még, hogy két hejről jöhet kapcsolat. Az egyik internetről bárhonnan, de az nem sok, a másik egy konkrét proxy (Squid), utóbbi sok. Erre mondtam, hogy összesen átlag 150-180 Zorp thread-et számolok egyidőben. A Zorp ezt két tűzfalon is csinálja, melyek egymás után vanak, de egymástól függetlenül jön a jelenség. Az egyiken a Zorp két instance-al megy (internet és dmz felé 1-1). A dmz felől van 1 IP-ről minden kapcsolat. Ez a Zorp threads 200-al fut instance-onként, míg a másik Zorp melyhez az elsőn át vezet az út threads 400-al fut. A hiba utóbbin gyakoribb. Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
On Thu, Jun 12, 2003 at 10:40:52PM +0200, Czakó Krisztián wrote:
2003-06-12, cs keltezéssel Balazs Scheidler ezt írta:
hany nyitott socketed van az autobind-ip -re bindolva?
Ezt hogyan számolom meg egyszerűen?
netstat -ant | grep <autobindip>
Annyi adalék még, hogy két hejről jöhet kapcsolat. Az egyik internetről bárhonnan, de az nem sok, a másik egy konkrét proxy (Squid), utóbbi sok. Erre mondtam, hogy összesen átlag 150-180 Zorp thread-et számolok egyidőben. A Zorp ezt két tűzfalon is csinálja, melyek egymás után vanak, de egymástól függetlenül jön a jelenség. Az egyiken a Zorp két instance-al megy (internet és dmz felé 1-1). A dmz felől van 1 IP-ről minden kapcsolat. Ez a Zorp threads 200-al fut instance-onként, míg a másik Zorp melyhez az elsőn át vezet az út threads 400-al fut. A hiba utóbbin gyakoribb.
van egy uzenet az iptable_tproxy.c-ben, az IP_TPROXY_UNASSIGN setsockopt-ban, ami igy nez ki: DEBUGP(KERN_DEBUG "IP_TPROXY_UNASSIGN: unhashing %08x:%04x\n", sk->rcv_saddr, sk->sport); ha atirod a DEBUGP-t printk-ra, akkor ez az uzenet sokat segithetne a hiba kideriteseben. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
2003-06-13, p keltezéssel Balazs Scheidler ezt írta:
On Thu, Jun 12, 2003 at 10:40:52PM +0200, Czakó Krisztián wrote:
2003-06-12, cs keltezéssel Balazs Scheidler ezt írta:
hany nyitott socketed van az autobind-ip -re bindolva?
Ezt hogyan számolom meg egyszerűen?
netstat -ant | grep <autobindip>
A 83 napos uptime-al rendelkező tűzfalon 151 van belőle és mind CLOSE_WAIT-en van. Néha van 1-1 ESTABLISHED és TIME_WAIT, de azok eltűnnek. A félórás uptime után lévőn csak 16 van, amiből 14 TIME_WAIT, 2 ESTABLISHED. Egy zorp stop után minden ilyen eltűnik.
van egy uzenet az iptable_tproxy.c-ben, az IP_TPROXY_UNASSIGN setsockopt-ban, ami igy nez ki:
DEBUGP(KERN_DEBUG "IP_TPROXY_UNASSIGN: unhashing %08x:%04x\n", sk->rcv_saddr, sk->sport);
ha atirod a DEBUGP-t printk-ra, akkor ez az uzenet sokat segithetne a hiba kideriteseben.
Ezt majd este. Napközben nem indíthatom újra. Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
2003-06-13, p keltezéssel Czakó Krisztián ezt írta:
van egy uzenet az iptable_tproxy.c-ben, az IP_TPROXY_UNASSIGN setsockopt-ban, ami igy nez ki:
DEBUGP(KERN_DEBUG "IP_TPROXY_UNASSIGN: unhashing %08x:%04x\n", sk->rcv_saddr, sk->sport);
ha atirod a DEBUGP-t printk-ra, akkor ez az uzenet sokat segithetne a hiba kideriteseben.
Ezt majd este. Napközben nem indíthatom újra.
Egyszuszra frissítettem 2.4.21-re. A gyári 2.4.21-re csak rsbac és a weboldalatokon levő 2.4.21-hez való (pom) patch került. Azóta nincs hiba. Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
On Sun, Jun 22, 2003 at 09:19:35PM +0200, Czakó Krisztián wrote:
2003-06-13, p keltezéssel Czakó Krisztián ezt írta:
van egy uzenet az iptable_tproxy.c-ben, az IP_TPROXY_UNASSIGN setsockopt-ban, ami igy nez ki:
DEBUGP(KERN_DEBUG "IP_TPROXY_UNASSIGN: unhashing %08x:%04x\n", sk->rcv_saddr, sk->sport);
ha atirod a DEBUGP-t printk-ra, akkor ez az uzenet sokat segithetne a hiba kideriteseben.
Ezt majd este. Napközben nem indíthatom újra.
Egyszuszra frissítettem 2.4.21-re. A gyári 2.4.21-re csak rsbac és a weboldalatokon levő 2.4.21-hez való (pom) patch került. Azóta nincs hiba.
ez jo hir, bar nem ertem mi oldhatta meg. lehet, hogy valami core problema. arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
2003-06-23, h keltezéssel Balazs Scheidler ezt írta:
On Sun, Jun 22, 2003 at 09:19:35PM +0200, Czakó Krisztián wrote:
2003-06-13, p keltezéssel Czakó Krisztián ezt írta:
van egy uzenet az iptable_tproxy.c-ben, az IP_TPROXY_UNASSIGN setsockopt-ban, ami igy nez ki:
DEBUGP(KERN_DEBUG "IP_TPROXY_UNASSIGN: unhashing %08x:%04x\n", sk->rcv_saddr, sk->sport);
ha atirod a DEBUGP-t printk-ra, akkor ez az uzenet sokat segithetne a hiba kideriteseben.
Ezt majd este. Napközben nem indíthatom újra.
Egyszuszra frissítettem 2.4.21-re. A gyári 2.4.21-re csak rsbac és a weboldalatokon levő 2.4.21-hez való (pom) patch került. Azóta nincs hiba. ez jo hir, bar nem ertem mi oldhatta meg. lehet, hogy valami core problema.
Ez már túl van az érthetőség határán :)
arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat)
Amikor leszedtem még nem volt... Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
On Mon, Jun 23, 2003 at 10:49:49AM +0200, Czakó Krisztián wrote:
arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat)
Amikor leszedtem még nem volt...
hmm.. az iw elrontott valamit koztunk es a webszerver kozott, ezert nem megy a downloads konyvtar szinkronizalasa. remelem hamarosan megjavul. (ha nem TPROXY-zol UDP-s csomagokat, akkor nem lehet gond) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
2003-06-23, h keltezéssel Balazs Scheidler ezt írta:
On Mon, Jun 23, 2003 at 10:49:49AM +0200, Czakó Krisztián wrote:
arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat)
Amikor leszedtem még nem volt...
hmm.. az iw elrontott valamit koztunk es a webszerver kozott, ezert nem megy a downloads konyvtar szinkronizalasa. remelem hamarosan megjavul.
(ha nem TPROXY-zol UDP-s csomagokat, akkor nem lehet gond)
Sebajd, de megjött a nem várt hiba. A szervernek 6 napos uptime után sikerült produkálnia. Érdekesség, hogy az apache tesztprogramjával igen szépen meg lett hajtva mind a zorp, mind a mögötte lévő webszerver és egy szikra hiba nem volt. Ez volt múlt pénteken. Ma pedig jött egy hiba, mikor csak 2-3 párhuzamos kérés csordogált rendszeresen. A kért debug: Jun 23 08:58:29 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:3ea2 Jun 23 08:58:29 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:40a2 Jun 23 08:58:29 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:42a2 Jun 23 08:58:30 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:44a2 Jun 23 08:58:43 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:46a2 Jun 23 08:58:43 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:48a2 Jun 23 08:58:44 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:4aa2 Jun 23 08:58:50 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:4ca2 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:4ea2 Jun 23 08:59:00 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:50a2, sr->faddr=799238c3:51a2, flags=90005 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:50a2 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:51a2 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:53a2 Jun 23 08:59:05 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:55a2 Jun 23 08:59:05 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:57a2 Jun 23 08:59:05 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:59a2 Jun 23 08:59:05 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:5ba2 Jun 23 08:59:11 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:5da2 Jun 23 08:59:41 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:5fa2 Jun 23 08:59:41 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:61a2 Jun 23 08:59:49 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:63a2 Jun 23 08:59:49 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:65a2 Jun 23 09:57:41 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:32a7 Jun 23 09:57:47 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:34a7 Jun 23 09:57:47 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:36a7 Jun 23 09:57:48 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:38a7 Jun 23 09:57:48 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:3aa7, sr->faddr=799238c3:3ba7, flags=90005 Jun 23 09:57:48 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:3aa7 Jun 23 09:57:48 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:3ba7 Jun 23 09:57:48 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:3da7 Jun 23 09:57:52 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:3fa7 Jun 23 09:57:52 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:41a7 És van még. Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
On Mon, Jun 23, 2003 at 02:25:44PM +0200, Czakó Krisztián wrote:
2003-06-23, h keltezéssel Balazs Scheidler ezt írta:
On Mon, Jun 23, 2003 at 10:49:49AM +0200, Czakó Krisztián wrote:
arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat)
Amikor leszedtem még nem volt...
hmm.. az iw elrontott valamit koztunk es a webszerver kozott, ezert nem megy a downloads konyvtar szinkronizalasa. remelem hamarosan megjavul.
(ha nem TPROXY-zol UDP-s csomagokat, akkor nem lehet gond)
Sebajd, de megjött a nem várt hiba. A szervernek 6 napos uptime után sikerült produkálnia. Érdekesség, hogy az apache tesztprogramjával igen szépen meg lett hajtva mind a zorp, mind a mögötte lévő webszerver és egy szikra hiba nem volt. Ez volt múlt pénteken. Ma pedig jött egy hiba, mikor csak 2-3 párhuzamos kérés csordogált rendszeresen.
A kért debug:
Jun 23 08:59:00 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:50a2, sr->faddr=799238c3:51a2, flags=90005 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:50a2
hmm. pontosan az latszik, amit nagyjabol elmondtam, azaz: kesobb tunik el a TPROXY-s hashbol az adott portszam, ezert a masik szal lefoglalja mielott a tproxy-s hashbol eltunne. hm. workaroundot mar tudok, valami jobb megoldason gondolkozom... -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
2003-06-23, h keltezéssel Balazs Scheidler ezt írta:
On Mon, Jun 23, 2003 at 02:25:44PM +0200, Czakó Krisztián wrote:
2003-06-23, h keltezéssel Balazs Scheidler ezt írta:
On Mon, Jun 23, 2003 at 10:49:49AM +0200, Czakó Krisztián wrote:
arra figyelj, hogy az utolso pom-os release az 14-es, nem pom-os pedig van 15-os is. (UDP kezelesben volt egy hibajavitas, ami oops-ot okozhat)
Amikor leszedtem még nem volt...
hmm.. az iw elrontott valamit koztunk es a webszerver kozott, ezert nem megy a downloads konyvtar szinkronizalasa. remelem hamarosan megjavul.
(ha nem TPROXY-zol UDP-s csomagokat, akkor nem lehet gond)
Sebajd, de megjött a nem várt hiba. A szervernek 6 napos uptime után sikerült produkálnia. Érdekesség, hogy az apache tesztprogramjával igen szépen meg lett hajtva mind a zorp, mind a mögötte lévő webszerver és egy szikra hiba nem volt. Ez volt múlt pénteken. Ma pedig jött egy hiba, mikor csak 2-3 párhuzamos kérés csordogált rendszeresen.
A kért debug:
Jun 23 08:59:00 fw kernel: IP_TPROXY: socket already assigned, reuse=1, 5d92380a:50a2, sr->faddr=799238c3:51a2, flags=90005 Jun 23 08:59:00 fw kernel: IP_TPROXY_UNASSIGN: unhashing 5d92380a:50a2
hmm. pontosan az latszik, amit nagyjabol elmondtam, azaz: kesobb tunik el a TPROXY-s hashbol az adott portszam, ezert a masik szal lefoglalja mielott a tproxy-s hashbol eltunne.
Vajon ez eddig máshol/másnál még miért nem jött ki?
hm. workaroundot mar tudok, valami jobb megoldason gondolkozom...
Megosztod velünk a workaroundot? Slapic -- Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
participants (2)
-
Balazs Scheidler
-
Czakó Krisztián