On Sat, May 14, 2011 at 02:10:20PM +0200, Balazs Scheidler wrote:
a TPROXY csak akkor vegzi el a redirekciot, ha a listener socket-re amugy be lett allitva az IP_TRANSPARENT flag.
A lenyeg, hogy ha a netcat-tel nem megy, meg nem biztos, hogy nem a Zorp konfigban van a hiba. transparent=TRUE van megadva?
Csak egy sima plug-ot tettem egyelore oda, hogy lassam mukodik-e... Ennyi az egesz: class IPPlug(PlugProxy): pass Service("plug", IPPlug, TransparentRouter(forge_addr=TRUE)) Listener(bindto=DBIface(iface="tun0", ip="10.10.0.1", port=60001), service="plug", transparent=TRUE)
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.
Sajnos nincs benne a kernelben.
Ha viszont nem sajat kernelt hasznalsz, akkor gyakrolatilag az osszes pontot ellenorizned kell, hogy:
1) a TPROXY szabaly illeszkedik (elvileg ezt megnezted)
Szerintem igen.
2) a TPROXY-nak megadott --on-ip, --on-port listener nyitva van, es proxyzasra meg van jelolve (IP_TRANSPARENT socket opciot bekapcsolja az alkalmazas)
A zorp-nak be kellene kapcsolnia, meg ha a netcat-nak nem is. Vagy tevedek? De megneztem strace-szel, es nem lattam ehhez hasonlo nevu opciot benne.
3) a mark valoban rakerul a csomagra (a fenti ketto teljesulese eseten ra kell keruljon, a LOG target ki tudja irni az aktualis markot)
Erre konkret opciot nem talaltam. A kovetkezo szabalyokat vettem fel: -A PREROUTING -i tun0 -p tcp -s 10.10.2.1 -d 192.168.0.80 --dport 80 -j LOG --log-prefix "gyun: " -A PREROUTING -i tun0 -p tcp -s 10.10.2.1 -d 192.168.0.80 --dport 80 -j LOG --log-prefix "gyun2: " --log-tcp-sequence --log-tcp-options --log-ip-options -A PREROUTING -i tun0 -p tcp -s 10.10.2.1 -d 192.168.0.80 --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 60001 --on-ip 10.10.0.1 Es a kovetkezo logokat generaltak: May 16 10:10:11 fw kernel: [3246830.386696] gyun: IN=tun0 OUT= MAC= SRC=10.10.2.1 DST=192.168.0.80 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=56371 DF PROTO=TCP SPT=39184 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 May 16 10:10:11 fw kernel: [3246830.386710] gyun2: IN=tun0 OUT= MAC= SRC=10.10.2.1 DST=192.168.0.80 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=56371 DF PROTO=TCP SPT=39184 DPT=80 SEQ=xxx ACK=0 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405580402080A0F721AA80000000001030307) Es a zorp nem indult el.
4) a megfelelo routing rule/tabla fel van veve, ami az adott markot "local" -kent routolja.
Ezeket a parancsokat futtattam le: /sbin/ip route add local 0.0.0.0/0 dev lo table 100 /sbin/ip rule add fwmark 1 lookup 100 /sbin/ip route flush cache Probaltam ezt is, de az alabbi hibauzenetet kaptam: # ip -f inet route add local 0.0.0.0/0 dev tun0 table 100 RTNETLINK answers: File exists Probaltam a tun0 helyere mas interfeszt irni, de mindig ugyanezt a hibauzenetet kaptam.
5) az INPUT chain nem dobja el a beerkezo csomagot (pl mark alapjan atengedi az ilyen forgalmat)
Van ilyen szabalyom a filter tablaban: -A INPUT -m mark --mark 0x1/0x1 -j ACCEPT
6) az alkalmazas valoban megkapja a kapcsolatot.
Es ezt hogy lehetne ellenorizni?
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.
Hat, igen... -- Udvozlettel Zsiga