On Tue, 2011-05-10 at 09:25 +0200, Kosa Attila wrote:
On Tue, May 10, 2011 at 09:08:49AM +0200, Csányi Krisztián wrote:
On Tue, 10 May 2011 08:32:57 +0200, Kosa Attila wrote:
Bocs, ha nem volt egyertelmu, de azzal kezdtem, hogy egy mukodo szabalyt masoltam le, tehat mukodik a tproxy azon a gepen, csak ez az uj szabaly nem akar valamiert.
Vilagos. Ilyen esetben szerintem nincs jobb eszköz, mint: iptables -t mangle -L -v -n itt laszik, hogy match-el a csomagokra vagy sem. Ha a tcpdumpnal is az latszik, hogy eljut oda a csomag akkor az el is jut. Nalam ilyenkor csak egyetlen problema szokott lenni: a Dispatcher-nek nem adom meg a transparent=TRUE -t.
Irtam, hogy novekszenek a szamlalok, a tcpdump-ban latszanak a csomagok, es ha zorp helyett netcat-ot akasztok oda, akkor sem kerulnek fel a csomagok (tehat a Dispatcher-hez el sem jutnak).
De ahogy mondtad ez egy mukodo konfigrol lett masolva...
Az iptables szabalyra irtam, hogy egy mukodo szabalyt masoltam le.
a TPROXY csak akkor vegzi el a redirekciot, ha a listener socket-re amugy be lett allitva az IP_TRANSPARENT flag. van olyan netcat, ami beallitja, de patchelni kell hozza. http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patc... Viszont csereben nem egy, hanem legalabb 2 fele netcat valtozat van, az pedig, hogy az upstream gyakorlatilag nem mukodik azt jelenti, hogy a kulonbozo Linux/FreeBSD stb valtozatokban erosen eltero netcatek vannak. netcat-openbsd - TCP/IP swiss army knife netcat - TCP/IP swiss army knife -- transitional package netcat-traditional - TCP/IP swiss army knife netcat6 - TCP/IP swiss army knife with IPv6 support A lenyeg, hogy ha a netcat-tel nem megy, meg nem biztos, hogy nem a Zorp konfigban van a hiba. transparent=TRUE van megadva? Hmm.. jo lenne valami diagnosztika ebben az esetben, a TPROXY cel esetleg logolhatna egyet ilyenkor. ... megneztem, a TPROXY target-ben vannak pr_debug()-os uzenetek, igy ha a kerneledben van CONFIG_DYNAMIC_DEBUG (ami sajnos ubuntu kernelben pl. nincs), akkor be lehet kapcsolni ezeket az uzeneteket, ld. $KERNEL_SOURCE/Documentation/dynamic-debug-howto.txt Ha viszont nem sajat kernelt hasznalsz, akkor gyakrolatilag az osszes pontot ellenorizned kell, hogy: 1) a TPROXY szabaly illeszkedik (elvileg ezt megnezted) 2) a TPROXY-nak megadott --on-ip, --on-port listener nyitva van, es proxyzasra meg van jelolve (IP_TRANSPARENT socket opciot bekapcsolja az alkalmazas) 3) a mark valoban rakerul a csomagra (a fenti ketto teljesulese eseten ra kell keruljon, a LOG target ki tudja irni az aktualis markot) 4) a megfelelo routing rule/tabla fel van veve, ami az adott markot "local" -kent routolja. 5) az INPUT chain nem dobja el a beerkezo csomagot (pl mark alapjan atengedi az ilyen forgalmat) 6) az alkalmazas valoban megkapja a kapcsolatot. Gyakorlatilag barmelyik pont nem teljesulese eseten semmi nem tortenik, a csomagot eldobjuk. Az eredeti TPROXY 4.0 egy picit konnyebben hasznalhato volt (tproxy tabla stb), csereben azt nem fogadtak el az upstream kernelben, ezert maradt ez, a nehezebben kezelheto valtozat. -- Bazsi