zorp-hu

Download

zorp-hu@lists.balabit.hu

June 2006

7 participants
2 discussions

HttpProxy, tcp kapcsolat szakadas, timeout
by Tuska Viktor 23 Jun '06

23 Jun '06

Udv, a kovetkezo problemaval kuzdok: HttpProxy-n keresztul bizonyos (intranet-es)webloldalak elerese eseten az oldalhoz tartozo utolso (komponens-ek/)kep -ek letoltese 30 masodperces timeout-al tortenik. Kicsit tcpdump-olgattam es a kovetkezokre jutottam: A zorp kulso laban csordogalnak lefele az adatok, mignem a browser-tol erkezik egy GET 14:41:57.449898-kor. Ezutan erdekes modon ezen a tcp kapcsolaton keresztul 30 masodpercig nem megy adat semelyik iranyba. Kozvetlenul ezutan a keres utan erkeznek a browser-tol ujabb keresek egy masik(52156-os port) tcp kapcsolaton keresztul. Ezekenek a kereseknek a kiszolgalasa megtortenik jol, majd az elobb emlitett 30 masodperces ido lejarta utan megerkeznek az adatok a server-tol, a korabban kert GET-re valaszkent az 52155-os porthoz tartozo tcp kapcsolaton keresztul. Ugy tunik, hogy valami ok miatt a zorp belso laban mar nem jelenik meg idoben a 14:41:57.449898-kor a kulso labon beerkezett GET keres. 30 masodperc utan a webserver a belso labon lezarja 14:42:27.474240-kor a korabban hasznalt tcp kapcsolatot(gondolom timeout miatt, mivel semmilyen adatforgalom nem generalodik azon). Ezutan a zorp nyit 1 ujabb kapcsolatot es szepen elkuldi azon GET kerest, amit 30 masodperce "tartogatott". Van olyan pillanat, amikor ugyanazon oldalnal nem jelentkezik a hiba. A zorp log-jaiban nem latok error-t/furcsasagot. Kicsit reszletesre allitottam a zorp log-jat, ezert nem vagtam azt be ide. Van valakinek otlete mi lehet a gond? Esetleg valamilyen konfiguralasi problema? Szivesen kuldenek tovabbi adatokat, ha szukseges. Zorp external interface: ... 14:41:57.424095 browser.52155 > zorp-external.www: . ack 139408 win 16022 <nop,nop,timestamp 27500724 7753825> (DF) 14:41:57.449898 browser.52155 > zorp-external.www: P 4184:4774(590) ack 139408 win 16022 <nop,nop,timestamp 27500730 7753825> (DF) 14:41:57.449899 browser.52156 > zorp-external.www: S 4265315493:4265315493(0) win 5840 <mss 1460,sackOK,timestamp 27500731 0,nop,wscale 2> (DF) 14:41:57.449958 zorp-external.www > browser.52156: S 2947827391:2947827391(0) ack 4265315494 win 5792 <mss 1460,sackOK,timestamp 7753828 27500731,nop,wscale 0> (DF) 14:41:57.450124 browser.52156 > zorp-external.www: . ack 1 win 1460 <nop,nop,timestamp 27500731 7753828> (DF) 14:41:57.457584 browser.52156 > zorp-external.www: P 1:589(588) ack 1 win 1460 <nop,nop,timestamp 27500732 7753828> (DF) 14:41:57.457616 zorp-external.www > browser.52156: . ack 589 win 6468 <nop,nop,timestamp 7753829 27500732> (DF) ... 14:41:58.029345 zorp-external.www > browser.52156: P 53723:54921(1198) ack 8818 win 15876 <nop,nop,timestamp 7753886 27500875> (DF) 14:41:58.031300 browser.52156 > zorp-external.www: . ack 54921 win 15705 <nop,nop,timestamp 27500876 7753886> (DF) 14:42:03.033384 zorp-external.www > browser.52156: F 54921:54921(0) ack 8818 win 15876 <nop,nop,timestamp 7754387 27500876> (DF) 14:42:03.073498 browser.52156 > zorp-external.www: . ack 54922 win 16022 <nop,nop,timestamp 27502136 7754387> (DF) 14:42:05.087281 browser.52156 > zorp-external.www: F 8818:8818(0) ack 54922 win 16022 <nop,nop,timestamp 27502640 7754387> (DF) 14:42:05.087299 zorp-external.www > browser.52156: . ack 8819 win 15876 <nop,nop,timestamp 7754592 27502640> (DF) 14:42:27.483361 zorp-external.www > browser.52155: P 139408:139746(338) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483386 zorp-external.www > browser.52155: . 139746:141194(1448) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483409 zorp-external.www > browser.52155: . 141194:142642(1448) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483988 browser.52155 > zorp-external.www: . ack 141194 win 16022 <nop,nop,timestamp 27508239 7756831> (DF) ... Zorp internal interface: ... 14:41:57.420243 webserver.webcache > zorp-internal.33219: P 136615:137071(456) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420290 zorp-internal.33219 > webserver.webcache: . ack 129375 win 34752 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420296 zorp-internal.33219 > webserver.webcache: . ack 132271 win 34752 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420346 zorp-internal.33219 > webserver.webcache: . ack 137071 win 31856 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420364 webserver.webcache > zorp-internal.33219: . 137071:138519(1448) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420365 webserver.webcache > zorp-internal.33219: P 138519:139236(717) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420427 zorp-internal.33219 > webserver.webcache: . ack 139236 win 31856 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.458339 zorp-internal.59756 > webserver.webcache: S 2940820984:2940820984(0) win 5840 <mss 1460,sackOK,timestamp 7753829 0,nop,wscale 0> (DF) 14:41:57.458597 webserver.webcache > zorp-internal.59756: S 1722218316:1722218316(0) ack 2940820985 win 49232 <nop,nop,timestamp 243245680 7753829,mss 1460,nop,wscale 0,nop,nop,sackOK> (DF) 14:41:57.458627 zorp-internal.59756 > webserver.webcache: . ack 1 win 5840 <nop,nop,timestamp 7753829 243245680> (DF) 14:41:57.459096 zorp-internal.59756 > webserver.webcache: P 1:589(588) ack 1 win 5840 <nop,nop,timestamp 7753829 243245680> (DF) 14:41:57.459345 webserver.webcache > zorp-internal.59756: . ack 589 win 49232 <nop,nop,timestamp 243245680 7753829> (DF) 14:41:57.464592 webserver.webcache > zorp-internal.59756: . 1:1449(1448) ack 589 win 49232 <nop,nop,timestamp 243245681 7753829> (DF) 14:41:57.464610 zorp-internal.59756 > webserver.webcache: . ack 1449 win 8688 <nop,nop,timestamp 7753830 243245681> (DF) ... 14:41:58.028135 webserver.webcache > zorp-internal.59756: P 55127:55236(109) ack 8818 win 49232 <nop,nop,timestamp 243245737 7753885> (DF) 14:41:58.028201 zorp-internal.59756 > webserver.webcache: . ack 55236 win 34752 <nop,nop,timestamp 7753886 243245737> (DF) 14:42:03.033452 zorp-internal.59756 > webserver.webcache: F 8818:8818(0) ack 55236 win 34752 <nop,nop,timestamp 7754387 243245737> (DF) 14:42:03.033759 webserver.webcache > zorp-internal.59756: . ack 8819 win 49232 <nop,nop,timestamp 243246237 7754387> (DF) 14:42:03.131822 webserver.webcache > zorp-internal.59756: F 55236:55236(0) ack 8819 win 49232 <nop,nop,timestamp 243246247 7754387> (DF) 14:42:03.131852 zorp-internal.59756 > webserver.webcache: . ack 55237 win 34752 <nop,nop,timestamp 7754396 243246247> (DF) 14:42:27.474240 webserver.webcache > zorp-internal.33219: F 139236:139236(0) ack 4184 win 49232 <nop,nop,timestamp 243248682 7753825> (DF) 14:42:27.474753 zorp-internal.33219 > webserver.webcache: F 4184:4184(0) ack 139237 win 34752 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.474986 webserver.webcache > zorp-internal.33219: . ack 4185 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.475386 zorp-internal.36988 > webserver.webcache: S 2971223218:2971223218(0) win 5840 <mss 1460,sackOK,timestamp 7756831 0,nop,wscale 0> (DF) 14:42:27.475614 webserver.webcache > zorp-internal.36988: S 3369441031:3369441031(0) ack 2971223219 win 49232 <nop,nop,timestamp 243248682 7756831,mss 1460,nop,wscale 0,nop,nop,sackOK> (DF) 14:42:27.475641 zorp-internal.36988 > webserver.webcache: . ack 1 win 5840 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.476110 zorp-internal.36988 > webserver.webcache: P 1:591(590) ack 1 win 5840 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.476364 webserver.webcache > zorp-internal.36988: . ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.482734 webserver.webcache > zorp-internal.36988: . 1:1449(1448) ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.482764 zorp-internal.36988 > webserver.webcache: . ack 1449 win 8688 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.482735 webserver.webcache > zorp-internal.36988: . 1449:2897(1448) ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) ... #zorpctl version Zorp 3.0.11 Revision: devel(a)balabit.hu--zorp-1/zorp-core--mainline--3.0--patch-424 Compile-Date: Mar 6 2006 23:35:53 Config-Date: 2006/03/06 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Netfilter-Linux22-Fallback: on Linux22-Tproxy: off Conntrack: on Zorplib 3.0.6.6 Revision: devel(a)balabit.hu--zorp-1/zorp-lib--mainline--3.0--patch-134 Compile-Date: Apr 28 2006 14:29:30 Trace: off MemTrace: off Caps: on Debug: off StackDump: on Probaltam gpl-es(3.0.9) zorp-al is, ami ugyanezt produkalta. Remelem valamennyire erthetore sikeredett. Koszontem, Viktor

1 0

Skype
by _Zorp 21 Jun '06

21 Jun '06

Sziasztok! Használ valaki Skype-ot Zorp tűzfal mögül élvezhető minőségben? A problémám a következő: A tűzfal úgy van beállítva, hogy alapvetően minden forgalmat blokkol, ami nem kell meghatározott feladatokhoz, így nincsenek szabadon használható portok sem kifelé, sem befelé. A HTTP forgalom a megfelelő alkalmazás proxyval és vírus ellenőrzéssel megy át a tűzfalon. A HTTPS forgalom ma még plug-proxyval működik, de ezt is tervezzük alkalmazás proxyra cserélni. Ilyen feltételek mellett azonban a Skype működik ugyan, de gyakorlatilag használhatatlan, annyira szagatottan megy át a hang. A Skype dokumentációja szerint az ideális hálózati konfigurció a Skype számára: 1. Kimenő TCP forgalom engedélyezett az 1024 és nagyobb portokra 2. Kimenő TCP forgalom engedélyezett a 80 és 443 portokra 3. Kimenő UDP forgalom engedélyezett az 1024 és nagyobb portokra. Ahhoz, hogy az UDP-t használni tudja a Skype a NAT-nak engedélyeznie kell, hogy UDP válasz csomagok visszajussanak a küldőhöz (Az UDP "kapcsolatokat" minimum 30 másodpercig meg kell tartani, de azt javasolják, hogy ha lehet, akkor inkább 1 óráig legyenek aktívak az ilyen kapcsolatok.) 4. A NAT konzisztens fordítást kell alkalmazzon, azaz a kimenő címfordításnál használt port azonos a bejövő csomagoknál használt porttal UDP csomagok esetében. A felsorolt környezet vállalati környezetben sok mindennek nevezhető, de nagyon biztonságosnak biztosan nem. Persze van egy olyan jegyzet is a Skype dokumentációban, hogy mik a minimális feltételek a tűzfal mögüli használathoz: - Lehetőleg legyen engedélyezett a kimenő TCP forgalom minden portra (1-65535) - Ha ez nem lehetséges, akkor a 443-as TCP portra legyen engedélyezett a kimenő forgalom. - Ha a fentiek nem lehetségesek, akkor a 80-as portra legyen engedélyezett a kimenő forgalom, de ügyeljünk arra, hogy nem jó az a megoldás, ahol a tűzfal ellenőrzi a 80-as porton a HTTP protokolt, mert a Skype nem használja a HTTP protokolt, így az ilyen tűzfal blokkolni fogja a Skype működését. - Ha a fentiek nem lehetségesek, akkor a Skype képes HTTPS/SSL vagy SOCKS5 proxy használatára. Ezzel sem vagyok nagyon kisegítve. Gondolom esetemben a 443-as porton a Plug-proxyn keresztül megy, és a többi forgalom blokkolt, de így nem igazán használható rendeltetésének megfelelően. Van valakinek esetleg olyan megoldása, ahol még elfogadható szintű a hálózati biztonság és megfelelő minőségben képes működni a Skype is? (Nem kell lemondani a 80 és 443 portok protokol elemzéséről, nem kell kinyitni az összes nagy TCP és UDP portot kifelé.) Van esetleg tapasztalat proxy használatra vonatkozóan és ha igen, akkor melyik proxy szofvert és mire figyelve érdemes használni? A probléma biztosan a tűzfalon van, mert ha ugyanazt a gépet átteszem a tűzfal mögé, akkor nagyságrendeket javul a Skype hangminősége. Előre is köszönöm a segítséget. Petya

6 7