Hello! Van egy gep, 3.3.6-os gpl-es zorp fut rajta. Csinaltam egy uj proxy-t, lemasoltam hozza a csomagszuroben egy mar mukodo szabalyt, atirtam az interfeszt, portot, src-t es dst-t, betoltottem, es nem mukodik. Nem kerul fel a zorp-hoz a csomag. Tettem logolo szabalyt a szabaly ele es moge (vim-mel masoltam a TPROXY-tol kezdve atirtam LOG --log-prefix "akarmi: ", tehat biztosan azonos az illeszkedes). Az elotte levo logol, a mogotte levo nem, a szabaly szamlaloi novekednek, tehat megkapja a csomagot. Mar egy netcat-ot is akasztottam a zorp helyett arra a portra, de nem jelenik meg benne semmi. A tcpdump is azt mutatja, hogy eljut a gephez a csomag (ami nem is csoda, hiszen a csomagszuro logolja is). Valtoztattam a portszamot is (ertelemszeruen mindenhol atirva), de semmi. Ha direktbe arra a portra konnektalok, amin a zorp (vagy a netcat) log, akkor elindul a megfelelo proxy, illetve latszik a netcat-ban a forgalom. A netstat-ban is latszik, hogy a megfelelo porton figyel a zorp (vagy a netcat). Egy tanacsra felraktam a conntrack csomagot, probalkoztam a conntrack -F paranccsal, de nem valtozott a helyzet. Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra? A szabaly ennyi lenne: -A PREROUTING -i tun0 -p tcp -s VPN1 -d SZERVER --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 60001 --on-ip 10.10.0.1 A 10.10.0.1 a tun0 IP cime. # zorpctl version Zorp 3.3.6 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/zorp-core--mainline--3.3#master#6edb5a74eba572a6ffd442b5a9760c3c3ac7907e Compile-Date: Nov 11 2010 14:43:34 Config-Date: 2010/11/11 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Linux22-Tproxy: off libzorpll 3.3.0.12 Revision: ssh+git://hidden@git.balabit//var/scm/git/zorp/libzorpll--mainline--3.3#master#ac32b2a0ec71fbb94690d959fedb55217d8c5ec5 Compile-Date: Jun 20 2010 22:42:59 Trace: off MemTrace: off Caps: on Debug: off StackDump: off -- Udvozlettel Zsiga
Szia, On 05/09/2011 10:06 AM, Kosa Attila wrote:
Van egy gep, 3.3.6-os gpl-es zorp fut rajta. Csinaltam egy uj proxy-t, lemasoltam hozza a csomagszuroben egy mar mukodo szabalyt, atirtam az interfeszt, portot, src-t es dst-t, betoltottem, es nem mukodik. Nem kerul fel a zorp-hoz a csomag. Tettem logolo szabalyt a szabaly ele es moge (vim-mel masoltam a TPROXY-tol kezdve atirtam LOG --log-prefix "akarmi: ", tehat biztosan azonos az illeszkedes). Az elotte levo logol, a mogotte levo nem, a szabaly szamlaloi novekednek, tehat megkapja a csomagot. Mar egy netcat-ot is akasztottam a zorp helyett arra a portra, de nem jelenik meg benne semmi. A tcpdump is azt mutatja, hogy eljut a gephez a csomag (ami nem is csoda, hiszen a csomagszuro logolja is). Valtoztattam a portszamot is (ertelemszeruen mindenhol atirva), de semmi. Ha direktbe arra a portra konnektalok, amin a zorp (vagy a netcat) log, akkor elindul a megfelelo proxy, illetve latszik a netcat-ban a forgalom. A netstat-ban is latszik, hogy a megfelelo porton figyel a zorp (vagy a netcat). Egy tanacsra felraktam a conntrack csomagot, probalkoztam a conntrack -F paranccsal, de nem valtozott a helyzet.
Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra?
A szabaly ennyi lenne: -A PREROUTING -i tun0 -p tcp -s VPN1 -d SZERVER --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 60001 --on-ip 10.10.0.1
A 10.10.0.1 a tun0 IP cime.
Milyen kernelt hasznalsz? Milyen routing rule-jaid es routing tabla entry-id vannak? -- KOVACS Krisztian
On Mon, May 09, 2011 at 10:33:08AM +0200, KOVACS Krisztian wrote:
On 05/09/2011 10:06 AM, Kosa Attila wrote:
Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra?
A szabaly ennyi lenne: -A PREROUTING -i tun0 -p tcp -s VPN1 -d SZERVER --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 60001 --on-ip 10.10.0.1
A 10.10.0.1 a tun0 IP cime.
Milyen kernelt hasznalsz? Milyen routing rule-jaid es routing tabla entry-id vannak?
2.6.32-5-amd64 (Squeeze gyari kernel). $ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.10.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 193.224.xxx.xxx 0.0.0.0 255.255.255.252 U 0 0 0 eth0 10.10.0.0 10.10.0.2 255.255.255.248 UG 0 0 0 tun0 193.225.xxx.xxx 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.10.2.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.65.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.64.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 10.10.1.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth1 0.0.0.0 193.224.xxx.xxx 0.0.0.0 UG 0 0 0 eth0 -- Udvozlettel Zsiga
On Mon, 9 May 2011 11:54:56 +0200, Kosa Attila wrote:
On Mon, May 09, 2011 at 10:33:08AM +0200, KOVACS Krisztian wrote:
On 05/09/2011 10:06 AM, Kosa Attila wrote:
Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra?
A szabaly ennyi lenne: -A PREROUTING -i tun0 -p tcp -s VPN1 -d SZERVER --dport 80 -j
TPROXY --tproxy-mark 0x1/0x1 --on-port 60001 --on-ip 10.10.0.1
A 10.10.0.1 a tun0 IP cime.
Milyen kernelt hasznalsz? Milyen routing rule-jaid es routing tabla entry-id vannak?
2.6.32-5-amd64 (Squeeze gyari kernel).
$ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.10.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 193.224.xxx.xxx 0.0.0.0 255.255.255.252 U 0 0 0 eth0 10.10.0.0 10.10.0.2 255.255.255.248 UG 0 0 0 tun0 193.225.xxx.xxx 0.0.0.0 255.255.255.0 U 0 0 0 eth0 10.10.2.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.65.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.64.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 10.10.1.0 10.10.0.2 255.255.255.0 UG 0 0 0 tun0 192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth1 0.0.0.0 193.224.xxx.xxx 0.0.0.0 UG 0 0 0 eth0
Szia! Ez a része megvan?: /etc/network/interfaces: auto lo iface lo inet loopback up ip route add local 0.0.0.0/0 dev lo table 100 up ip rule add fwmark 1 lookup 100 Vagy berakod interfaces-be vagy kiadod kézzel. Enélkül nem megy az új tproxy. Én is sokáig szívtam vele. Üdv: Krisztián
On Mon, May 09, 2011 at 12:59:41PM +0200, Csányi Krisztián wrote:
On Mon, 9 May 2011 11:54:56 +0200, Kosa Attila wrote:
On Mon, May 09, 2011 at 10:33:08AM +0200, KOVACS Krisztian wrote:
On 05/09/2011 10:06 AM, Kosa Attila wrote:
Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra?
Ez a része megvan?: /etc/network/interfaces: auto lo iface lo inet loopback up ip route add local 0.0.0.0/0 dev lo table 100 up ip rule add fwmark 1 lookup 100
Vagy berakod interfaces-be vagy kiadod kézzel. Enélkül nem megy az új tproxy. Én is sokáig szívtam vele.
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. -- Udvozlettel Zsiga
On Tue, 10 May 2011 08:32:57 +0200, Kosa Attila wrote:
On Mon, May 09, 2011 at 12:59:41PM +0200, Csányi Krisztián wrote:
On Mon, 9 May 2011 11:54:56 +0200, Kosa Attila wrote:
On Mon, May 09, 2011 at 10:33:08AM +0200, KOVACS Krisztian wrote:
On 05/09/2011 10:06 AM, Kosa Attila wrote:
Hogyan lehetne kideriteni, hogy mi lesz a csomaggal, miert nem kerul fel a megfelelo portra?
Ez a része megvan?: /etc/network/interfaces: auto lo iface lo inet loopback up ip route add local 0.0.0.0/0 dev lo table 100 up ip rule add fwmark 1 lookup 100
Vagy berakod interfaces-be vagy kiadod kézzel. Enélkül nem megy az új tproxy. Én is sokáig szívtam vele.
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. De ahogy mondtad ez egy mukodo konfigrol lett masolva... Krisztian
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. -- Udvozlettel Zsiga
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
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
On Mon, May 16, 2011 at 10:28:03AM +0200, Kosa Attila wrote:
On Sat, May 14, 2011 at 02:10:20PM +0200, Balazs Scheidler wrote:
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
Ez ele betettem az alabbi szabalyt: -A INPUT -m mark --mark 0x1/0x1 -j LOG --log-prefix "markolva: " Egy csomo forgalmat logoz, de amit a vpn-en keresztul bekuldok, azt nem. Emiatt ugy gondolom, hogy ide mar nem jutnak el a csomagok, tehat elorebb lesz a problema. De hol? Az egyes pont - szerintem - jo. A negyes pont megint csak - szerintem - jo. Tehat a kettes es a harmas pont maradt. Hogy lehet kideriteni, hogy hol bukik meg a mutatvany? -- Udvozlettel Zsiga
participants (4)
-
Balazs Scheidler
-
Csányi Krisztián
-
Kosa Attila
-
KOVACS Krisztian