Sziasztok! Van egy regi tuzfal, amin meg 2.0.8-as zorp fut. Ezen volt egy instance, ami az internet iranyabol engedte a dmz zonaba egy gepre az ssh kapcsolatot: def o2m_ssh(): Service("om_ssh", MyPlugProxy, router=DirectedRouter(SockAddrInet('aa.bb.cc.dd', 22),TRUE)) Listener(SockAddrInet("xx.yy.zz.vv", 22), "om_ssh") ahol aa.bb.cc.dd a dmz-ben levo szerver ip cime, xx.yy.zz.vv az internet oldali ipcime a tuzfalnak. Most ugyanezt szeretnem megcsinalni egy ubuntu 12.04 LTS alatt levo zorp 3.9.2-vel: def o2m_ssh(): Service("om_ssh", MyPlugProxy, router=DirectedRouter(SockAddrInet('aa.bb.cc.dd', 22),TRUE)) Dispatcher(bindto=DBIface(protocol=ZD_PROTO_TCP, iface="eth0", ip="xx.yy.zz.vv", port=22), service="om_ssh", transparent=FALSE, threaded=FALSE, backlog=255) De nem megy. A log-ban a kovetkezot latom (ee.ff.gg.hh a kulso gep cime, ahonnet inditom az ssh-t): May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (dsp/dispatch:0): Incoming connection; protocol='1', remote='AF_INET(ee.ff.gg.hh:50074)', local='AF_INET(xx.yy.zz.vv:22)', dest='AF_INET(xx.yy.zz.vv:22)' May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.session(5): (svc/om_ssh): Starting service; name='om_ssh' May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.session(3): (svc/om_ssh:0): Starting proxy instance; client_fd='15', client_address='AF_INET(ee.ff.gg.hh:50074)', client_zone='Zone(out, 0.0.0.0/0)', client_local='AF_INET(xx.yy.zz.vv:22)', client_protocol='TCP' May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.session(5): (svc/om_ssh:0/plug): Proxy starting; class='MyPlugProxy', proxy='plug' May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (group): thread starting; May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute changed; attribute='language', newvalue=''en'' May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute fetched; attribute='ssl', value='ZPolicyStruct object type Shared' May 27 23:24:38 zorp/o2m_ssh[6059]: last message repeated 7 times May 27 23:24:38 fal zorp/o2m_ssh[6059]: plug(2): (group): S: AF_INET(xx.yy.zz.vv:22) C: AF_INET(ee.ff.gg.hh:50074) May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute fetched; attribute='ssl', value='ZPolicyStruct object type Shared' May 27 23:24:38 zorp/o2m_ssh[6059]: last message repeated 2 times May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute fetched; attribute='server_local_tos', value='0' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.error(2): (svc/om_ssh:0/plug): Connection to remote end failed; local='AF_INET(xx.yy.zz.vv:35463)', remote='AF_INET(aa.bb.cc.dd:22)', error='connection timed out' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Established connection; conn='NULL' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.stderr(3): (stderr): #012 May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.stderr(3): (stderr): (zorp:6059): GLib-WARNING **: (/build/buildd/glib2.0-2.32.3/./glib/gerror.c:390):g_error_new_valist: runtime check failed: (domain != 0)#012 May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.session(3): (svc/om_ssh:0/plug): Server connection failure; server_address='AF_INET(aa.bb.cc.dd:22)', server_zone='Zone(dmz, 192.168.0.0/24)', server_local='None', server_protocol='TCP' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Proxy destroy; class='MyPlugProxy', module='plug' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug/client): Shutdown channel; fd='15', mode='2' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug/client): Closing stream; type='ZStreamFD' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.session(5): (svc/om_ssh:0/plug): Proxy ending; class='MyPlugProxy', module='plug' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.session(4): (svc/om_ssh:0): Ending proxy instance; A MyPlugProxy igy nez ki: class MyPlugProxy(PlugProxy): def config(self): PlugProxy.config(self) log("plug",2,"S: %s C: %s" % (self.session.client_local, self.session.client_address)) a dmz-ben levo szerverre a tuzfalrol lehet ssh-zni. Mit rontok el? Koszonom, Gabor
On Mon, May 27, 2013 at 11:40:45PM +0200, Gabor Tusnady wrote: Szia,
def o2m_ssh(): Service("om_ssh", MyPlugProxy, router=DirectedRouter(SockAddrInet('aa.bb.cc.dd', 22),TRUE)) Listener(SockAddrInet("xx.yy.zz.vv", 22), "om_ssh")
Most ugyanezt szeretnem megcsinalni egy ubuntu 12.04 LTS alatt levo zorp 3.9.2-vel:
May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute fetched; attribute='server_local_tos', value='0' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.error(2): (svc/om_ssh:0/plug): Connection to remote end failed; local='AF_INET(xx.yy.zz.vv:35463)', remote='AF_INET(aa.bb.cc.dd:22)', error='connection timed out'
Az általad postolt logok alapján a távoli kliens sikeresen kapcsolódik, viszont a szerver oldali továbbkapcsolódás timeoutra fut. Azt írtad, hogy a tűzfalról közvetlenül megy a kapcsolat, ezért azt javaslom próbáld meg úgy, hogy nem viszed a kliens címét (forge_addr=FALSE). Ha ezután sikeresen kiépül a kapcsolat, akkor az eredeti felállás az alábbi hibák miatt nem működött: * nincs az aa.bb.cc.dd szervernek routeja visszafelé (kliens felé) * csomagszűrő lakik az aa.bb.cc.dd szerveren, ami csendben eldobja a neki nem szimpatikus 22/TCP SYN csomagokat * nem működik a Zorp forge_addr mechanizmusa -- lajjan
On Tue, 2013-05-28 at 02:33 +0200, LAJOS Janos wrote:
On Mon, May 27, 2013 at 11:40:45PM +0200, Gabor Tusnady wrote:
Szia,
def o2m_ssh(): Service("om_ssh", MyPlugProxy, router=DirectedRouter(SockAddrInet('aa.bb.cc.dd', 22),TRUE)) Listener(SockAddrInet("xx.yy.zz.vv", 22), "om_ssh")
Most ugyanezt szeretnem megcsinalni egy ubuntu 12.04 LTS alatt levo zorp 3.9.2-vel:
May 27 23:24:38 fal zorp/o2m_ssh[6059]: core.debug(6): (svc/om_ssh:0/plug): Attribute fetched; attribute='server_local_tos', value='0' May 27 23:25:08 fal zorp/o2m_ssh[6059]: core.error(2): (svc/om_ssh:0/plug): Connection to remote end failed; local='AF_INET(xx.yy.zz.vv:35463)', remote='AF_INET(aa.bb.cc.dd:22)', error='connection timed out'
Az általad postolt logok alapján a távoli kliens sikeresen kapcsolódik, viszont a szerver oldali továbbkapcsolódás timeoutra fut.
Azt írtad, hogy a tűzfalról közvetlenül megy a kapcsolat, ezért azt javaslom próbáld meg úgy, hogy nem viszed a kliens címét (forge_addr=FALSE).
Ha ezután sikeresen kiépül a kapcsolat, akkor az eredeti felállás az alábbi hibák miatt nem működött: * nincs az aa.bb.cc.dd szervernek routeja visszafelé (kliens felé) * csomagszűrő lakik az aa.bb.cc.dd szerveren, ami csendben eldobja a neki nem szimpatikus 22/TCP SYN csomagokat * nem működik a Zorp forge_addr mechanizmusa
Köszönöm a választ. Valóban, forge_addr=FALSE beállítással működik. Ez azonban nem lehet végső megoldás. forge_addr=TRUE mellett tcpdump-pal vizsgálva a folyamatot az aa.bb.cc.dd szerver megkapja a SYN kérést, válaszolrá ACK-ot, ez megjelenik a tűzfalon is, de a kliensre már nem megy vissza, valahol a tűzfalon belül eltűnik. Próbálok logokat gyártani, ha addig is van valakinek ötlete mi a gond, örömmel veszem. Gábor
On Wed, May 29, 2013 at 04:07:15PM +0200, tusi wrote:
Köszönöm a választ. Valóban, forge_addr=FALSE beállítással működik. Ez azonban nem lehet végső megoldás.
forge_addr=TRUE mellett tcpdump-pal vizsgálva a folyamatot az aa.bb.cc.dd szerver megkapja a SYN kérést, válaszolrá ACK-ot, ez megjelenik a tűzfalon is, de a kliensre már nem megy vissza, valahol a tűzfalon belül eltűnik. Próbálok logokat gyártani, ha addig is van valakinek ötlete mi a gond, örömmel veszem.
Nem követem napi szinten a GPLes változatot, hogy pontosan hol tart, de az általad írt 2.x és jelenlegi verzió között jelentősen változott az abszorpciós :) réteg, azaz a transzparens kapcsolatok/viselkedés kezelése. Valószínűleg ez okozhat most problémát nálad (bár nem írtál a csomagszűrő konfigról). Szilárd írt annak idején egy rövid leírást, talán érdemes innen elindulnod: http://szilard.blogs.balabit.com/en/tag/kzorp-en/ -- lajjan
Nem követem napi szinten a GPLes változatot, hogy pontosan hol tart, de az általad írt 2.x és jelenlegi verzió között jelentősen változott az abszorpciós :) réteg, azaz a transzparens kapcsolatok/viselkedés kezelése. Valószínűleg ez okozhat most problémát nálad (bár nem írtál a csomagszűrő konfigról).
Szilárd írt annak idején egy rövid leírást, talán érdemes innen elindulnod: http://szilard.blogs.balabit.com/en/tag/kzorp-en/
Ezekkel az a baj, hogy csak az intranetrol az internetre valo transzparent proxyt igenylo beallitasok vannak. Ez nekem is mukodik, mivel ezen leirasok alapjan keszitettem a konfigot. Nekem a masik irany nem megy: az internetrol a tuzfal cimere ssh-zva egy dmz zona-ban levo gepre szeretnek bejutni. Mint irtam, ez abban az esetben mukodik, ha a DirectedRouter-t forge_addr=FALSE parameterrel hasznalom, TRUE eseten azonban nem megy. Alabb megtalalhatoak a konfig file-ok, illetve a syslog, es a tcpdump eredmenye. Amit nagyon nem ertek (mert nem vagyok szakember), hogyan lehet, hogy a tcpdump-ban sorr megjelennek a csomagok, amit a dmz-beli gep kuld a client-nek, ugyanezen csomagok a csomagszuro logjaban nem jelennek meg. Minden otletet, helyes iranyba terelest orommel veszek. Gabor ############################## # policy.py ############################## from Zorp.Core import * from Zorp.Plug import * from Zorp.Http import * Zorp.firewall_name = 'fal' iface_inter = "eth0" ip_inter = "fal_ip.5.6.7.8" iface_intra = "eth1" ip_intra = "172.16.0.254" iface_sys_dmz = "eth2" ip_sys_dmz = "192.168.0.254" InetZone("out", "0.0.0.0/0", inbound_services=["in_out_http"], outbound_services=["out_dmz_ssh"]) InetZone("dmz", "192.168.0.0/24", inbound_services=["out_dmz_ssh"], outbound_services=[]) InetZone("in", "172.16.0.0/16", inbound_services=[], outbound_services=["in_out_http"]) class MyPlugProxy(PlugProxy): def config(self): PlugProxy.config(self) log("plug",2,"S: %s C: %s" % (self.session.client_local, self.session.client_address)) def in2out_http(): Service(name="in_out_http", proxy_class=HttpProxy, router=TransparentRouter()) Dispatcher(bindto=DBIface(protocol=ZD_PROTO_TCP, iface=iface_intra, ip=ip_intra, port=50080), service="in_out_http", transparent=TRUE, threaded=FALSE, backlog=255) def out2dmz_ssh(): Service("out_dmz_ssh", MyPlugProxy, router=DirectedRouter(SockAddrInet("192.168.0.1", 22),TRUE)) Dispatcher(bindto=DBIface(protocol=ZD_PROTO_TCP, iface=iface_inter, ip=ip_inter, port=22), service="out_dmz_ssh", transparent=FALSE, threaded=FALSE, backlog=255) ############################## # instances.conf ############################## in2out_http --log-tags --verbose 2 -p /etc/zorp/policy.py out2dmz_ssh --log-tags --verbose 2 -p /etc/zorp/policy.py ############################## # iptables.conf ############################## *mangle :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :PRio - -A PREROUTING -i eth1 -s 172.16.0.0/16 -j PRio -A PRio -p tcp --dport 80 -j TPROXY --on-port 50080 --tproxy-mark 0x1/0x1 --on-ip 172.16.0.254 COMMIT *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :LOssh - :LOintra - :LOdmz - :LOinter - -A INPUT -s 127.0.0.1 -j ACCEPT -A INPUT -p tcp --dport 22 -j LOssh -A INPUT -p tcp --sport 22 -j LOssh -A LOssh -j LOG --log-prefix "Entering_input_ssh: " -A LOssh -j RETURN -A INPUT -i eth1 -s 172.16.0.0/16 -j LOintra -A LOintra -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -i eth2 -s 192.168.0.0/24 -j LOdmz -A LOdmz -j LOG --log-prefix "Entering_LOdmz: " -A LOdmz -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -i eth0 -s 0.0.0.0/0 -j LOinter -A LOinter -j LOG --log-prefix "Entering_LOinter: " -A LOinter -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -j LOG --log-prefix "DROP_INPUT: " -A INPUT -j DROP -A LOintra -j ACCEPT -A LOdmz -j LOG --log-prefix "DROP_LOdmz: " -A LOdmz -j DROP -A LOinter -j LOG --log-prefix "DROP_LOinter: " -A LOinter -j DROP COMMIT ############################## # indito script ############################## #!/bin/bash set -o nounset iptables="/sbin/iptables" ip="/sbin/ip" echo 1 > /proc/sys/net/ipv4/ip_forward ${ip} route add local 0.0.0.0/0 dev lo table 100 ${ip} rule add fwmark 1 lookup 100 ${ip} route flush cache ${iptables} -t mangle -N DIVERT ${iptables} -t mangle -A PREROUTING -p tcp -m socket -j DIVERT ${iptables} -t mangle -A DIVERT -j MARK --set-mark 1 ${iptables} -t mangle -A DIVERT -j ACCEPT iptables-restore < /etc/zorp/iptables.conf zorpctl start ############################## # syslog ############################## May 31 20:01:19 fal kernel: [28131.652257] Entering_input_ssh: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=42174 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 May 31 20:01:19 fal kernel: [28131.652271] Entering_LOinter: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=42174 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 May 31 20:01:19 fal kernel: [28131.671309] Entering_input_ssh: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=42175 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 May 31 20:01:19 fal kernel: [28131.671322] Entering_LOinter: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=60 TOS=0x00 PREC=0x00 TTL=58 ID=42175 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 May 31 20:01:19 fal zorp/out2dmz_ssh[14499]: plug(2): (group): S: AF_INET(fal_ip.5.6.7.8:22) C: AF_INET(client_ip.1.2.3.4:37285) May 31 20:01:19 fal kernel: [28131.820858] Entering_input_ssh: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=42176 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK URGP=0 May 31 20:01:19 fal kernel: [28131.820871] Entering_LOinter: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=52 TOS=0x00 PREC=0x00 TTL=58 ID=42176 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK URGP=0 May 31 20:01:19 fal kernel: [28131.852090] Entering_input_ssh: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=69 TOS=0x00 PREC=0x00 TTL=58 ID=42177 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK PSH URGP=0 May 31 20:01:19 fal kernel: [28131.852104] Entering_LOinter: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=69 TOS=0x00 PREC=0x00 TTL=58 ID=42177 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK PSH URGP=0 May 31 20:01:19 fal kernel: [28131.860767] Entering_input_ssh: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=64 TOS=0x00 PREC=0x00 TTL=58 ID=42178 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK URGP=0 May 31 20:01:19 fal kernel: [28131.860781] Entering_LOinter: IN=eth0 OUT= MAC=mac_addr SRC=client_ip.1.2.3.4 DST=fal_ip.5.6.7.8 LEN=64 TOS=0x00 PREC=0x00 TTL=58 ID=42178 DF PROTO=TCP SPT=37285 DPT=22 WINDOW=913 RES=0x00 ACK URGP=0 May 31 20:01:49 fal zorp/out2dmz_ssh[14499]: core.error(2): (svc/out_dmz_ssh:1/plug): Connection to remote end failed; local='AF_INET(client_ip.1.2.3.4:46711)', remote='AF_INET(dmz_ip.a.b.c.d:22)', error='connection timed out' ############################## # tcpdump ############################## 20:01:19.212812 IP client_ip.1.2.3.4.37285 > fal_ip.5.6.7.8.ssh: Flags [S], seq 1306370996, win 14600, options [mss 1392,sackOK,TS val 8652554 ecr 0,nop,wscale 4], length 0 20:01:19.213211 IP fal_ip.5.6.7.8.ssh > client_ip.1.2.3.4.37285: Flags [S.], seq 213728138, ack 1306370997, win 14480, options [mss 1460,sackOK,TS val 6974069 ecr 8652554,nop,wscale 6], length 0 20:01:19.231921 IP client_ip.1.2.3.4.37285 > fal_ip.5.6.7.8.ssh: Flags [S], seq 1306370996, win 14600, options [mss 1392,sackOK,TS val 8652654 ecr 0,nop,wscale 4], length 0 20:01:19.231977 IP fal_ip.5.6.7.8.ssh > client_ip.1.2.3.4.37285: Flags [S.], seq 213728138, ack 1306370997, win 14480, options [mss 1460,sackOK,TS val 6974074 ecr 8652554,nop,wscale 6], length 0 20:01:19.381813 IP client_ip.1.2.3.4.37285 > fal_ip.5.6.7.8.ssh: Flags [.], ack 1, win 913, options [nop,nop,TS val 8652679 ecr 6974069], length 0 20:01:19.382877 IP client_ip.1.2.3.4.46711 > dmz_ip.a.b.c.d.ssh: Flags [S], seq 2592204305, win 14600, options [mss 1460,sackOK,TS val 6974111 ecr 0,nop,wscale 6], length 0 20:01:19.383057 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905137 ecr 6974111,nop,wscale 4], length 0 20:01:19.383069 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905137 ecr 6974111,nop,wscale 4], length 0 20:01:19.413117 IP client_ip.1.2.3.4.37285 > fal_ip.5.6.7.8.ssh: Flags [P.], seq 1:18, ack 1, win 913, options [nop,nop,TS val 8652679 ecr 6974069], length 17 20:01:19.413175 IP fal_ip.5.6.7.8.ssh > client_ip.1.2.3.4.37285: Flags [.], ack 18, win 227, options [nop,nop,TS val 6974119 ecr 8652679], length 0 20:01:19.421814 IP client_ip.1.2.3.4.37285 > fal_ip.5.6.7.8.ssh: Flags [.], ack 1, win 913, options [nop,nop,TS val 8652679 ecr 6974074,nop,nop,sack 1 {0:1}], length 0 20:01:20.379890 IP client_ip.1.2.3.4.46711 > dmz_ip.a.b.c.d.ssh: Flags [S], seq 2592204305, win 14600, options [mss 1460,sackOK,TS val 6974361 ecr 0,nop,wscale 6], length 0 20:01:20.380065 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905386 ecr 6974111,nop,wscale 4], length 0 20:01:20.380081 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905386 ecr 6974111,nop,wscale 4], length 0 20:01:20.782112 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905487 ecr 6974111,nop,wscale 4], length 0 20:01:20.782127 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905487 ecr 6974111,nop,wscale 4], length 0 20:01:22.383892 IP client_ip.1.2.3.4.46711 > dmz_ip.a.b.c.d.ssh: Flags [S], seq 2592204305, win 14600, options [mss 1460,sackOK,TS val 6974862 ecr 0,nop,wscale 6], length 0 20:01:22.383995 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905887 ecr 6974111,nop,wscale 4], length 0 20:01:22.384012 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905887 ecr 6974111,nop,wscale 4], length 0 20:01:22.782099 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905987 ecr 6974111,nop,wscale 4], length 0 20:01:22.782114 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294905987 ecr 6974111,nop,wscale 4], length 0 20:01:26.391889 IP client_ip.1.2.3.4.46711 > dmz_ip.a.b.c.d.ssh: Flags [S], seq 2592204305, win 14600, options [mss 1460,sackOK,TS val 6975864 ecr 0,nop,wscale 6], length 0 20:01:26.392062 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294906889 ecr 6974111,nop,wscale 4], length 0 20:01:26.392079 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294906889 ecr 6974111,nop,wscale 4], length 0 20:01:26.782139 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294906987 ecr 6974111,nop,wscale 4], length 0 20:01:26.782155 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294906987 ecr 6974111,nop,wscale 4], length 0 20:01:34.407890 IP client_ip.1.2.3.4.46711 > dmz_ip.a.b.c.d.ssh: Flags [S], seq 2592204305, win 14600, options [mss 1460,sackOK,TS val 6977868 ecr 0,nop,wscale 6], length 0 20:01:34.408031 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294908893 ecr 6974111,nop,wscale 4], length 0 20:01:34.408049 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294908893 ecr 6974111,nop,wscale 4], length 0 20:01:34.782138 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294908987 ecr 6974111,nop,wscale 4], length 0 20:01:34.782153 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294908987 ecr 6974111,nop,wscale 4], length 0 20:01:49.412919 IP fal_ip.5.6.7.8.ssh > client_ip.1.2.3.4.37285: Flags [F.], seq 1, ack 18, win 227, options [nop,nop,TS val 6981619 ecr 8652679], length 0 20:01:49.412935 IP fal_ip.5.6.7.8.ssh > client_ip.1.2.3.4.37285: Flags [R.], seq 2, ack 18, win 227, options [nop,nop,TS val 6981619 ecr 8652679], length 0 20:01:50.782246 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294912987 ecr 6974111,nop,wscale 4], length 0 20:01:50.782263 IP dmz_ip.a.b.c.d.ssh > client_ip.1.2.3.4.46711: Flags [S.], seq 2096573511, ack 2592204306, win 14480, options [mss 1460,sackOK,TS val 4294912987 ecr 6974111,nop,wscale 4], length 0
Szia, már a linux listán is próbáltam válaszolni, de mivel nem vagyok tag, ezért az admin majd egyszer kiengedi On 05/31/2013 08:25 PM, tusi wrote:
Alabb megtalalhatoak a konfig file-ok, illetve a syslog, es a tcpdump eredmenye. Amit nagyon nem ertek (mert nem vagyok szakember), hogyan lehet, hogy a tcpdump-ban sorr megjelennek a csomagok, amit a dmz-beli gep kuld a client-nek, ugyanezen csomagok a csomagszuro logjaban nem jelennek meg.
Minden otletet, helyes iranyba terelest orommel veszek.
Gabor A konfigok első ránézésre jónak tűnnek, gyorsan összedobtam egy ilyet egy kéznél lévő 3.9.5-ös GPL zorp tesztgépre, igaz ez debian wheezy, de rendben megy.
A policy.py-ban gyakorlatilag ugyanaz van, mint Nálad: def zorp_ssh(): Service(name="inter_SSH_intra", proxy_class=PlugProxy, router=DirectedRouter(dest_addr=(SockAddrInet('<szerver címe>', 22),), forge_addr=TRUE)) Dispatcher(transparent=FALSE, bindto=DBIface(protocol=ZD_PROTO_TCP, port=2224, iface="eth0", family=2), rule_port="2224", service="inter_SSH_intra") A csomagszűrőben szimplán az INPUT-on engedélyeztem a TCP 2224-et. A routing-hoz és a socket match-es MARK-oláshoz pedig a Te scriptedet használtam, így: #!/bin/bash iptables="/sbin/iptables" ip="/sbin/ip" echo 1 > /proc/sys/net/ipv4/ip_forward ${ip} route add local 0.0.0.0/0 dev lo table 100 ${ip} rule add fwmark 1 lookup 100 ${ip} route flush cache ${iptables} -t mangle -N DIVERT ${iptables} -t mangle -A PREROUTING -p tcp -m socket -j DIVERT ${iptables} -t mangle -A DIVERT -j MARK --set-mark 1 ${iptables} -t mangle -A DIVERT -j ACCEPT Ezután nekem rendesen működött a kapcsolat: Jun 11 18:57:58 test zorp/zorp_ssh[14409]: core.session(3): (svc/inter_SSH_intra:5): Starting proxy instance; client_fd='14', client_address='AF_INET(<kliens IP>:33312)', client_zone='Zone(internet)', client_local='AF_INET(<tűzfal IP>:2224)', client_protocol='TCP' Jun 11 18:57:58 test zorp/zorp_ssh[14409]: core.session(3): (svc/inter_SSH_intra:5/plug): Server connection established; server_fd='16', server_address='AF_INET(<szerver IP>:22)', server_zone='Zone(site-local)', server_local='AF_INET(<kliens IP>:43735)', server_protocol='TCP' Jun 11 18:58:02 test zorp/zorp_ssh[14409]: core.session(4): (svc/inter_SSH_intra:5): Ending proxy instance; Jun 11 18:58:02 test zorp/zorp_ssh[14409]: core.accounting(4): (svc/inter_SSH_intra:5/plug/server): accounting info; type='ZStreamFD', duration='4', sent='2855', received='3129' Jun 11 18:58:02 test zorp/zorp_ssh[14409]: core.accounting(4): (svc/inter_SSH_intra:5/plug/client): accounting info; type='ZStreamFD', duration='4', sent='3129', received='2855' Olyan érzésem van, mintha a válaszcsomagok routingja körül lenne a probléma. Szerintem érdemes lenne tenni egy log targetet a DIVERT láncba a mark utánra, hogy látsszon, valóban rákerült-e a válaszcsomagra a MARK, illetve érdemes lenne bekapcsolni a martian és az invalid csomagok loggolását is (/proc/sys/net/netfilter/nf_conntrack_log_invalid, /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid, /proc/sys/net/ipv4/conf/all/log_martians), hogy nem ezek fogják-e meg. Milyen kernel verziót használsz? Üdv, Balint
Szia, köszönöm a választ,
már a linux listán is próbáltam válaszolni, de mivel nem vagyok tag, ezért az admin majd egyszer kiengedi A konfigok első ránézésre jónak tűnnek, gyorsan összedobtam egy ilyet egy kéznél lévő 3.9.5-ös GPL zorp tesztgépre, igaz ez debian wheezy, de rendben megy.
Hogyan tetted fel a zorp-ot, milyen kernel van a gépen?
A policy.py-ban gyakorlatilag ugyanaz van, mint Nálad:
def zorp_ssh(): Service(name="inter_SSH_intra", proxy_class=PlugProxy, router=DirectedRouter(dest_addr=(SockAddrInet('<szerver címe>', 22),), forge_addr=TRUE)) Dispatcher(transparent=FALSE, bindto=DBIface(protocol=ZD_PROTO_TCP, port=2224, iface="eth0", family=2), rule_port="2224", service="inter_SSH_intra")
Ez nekem így nem működik, egyből visszautasítja a kapcsolatot. Nem lehet, hogy a port=2224 helyett port=22 kellene )a 2224-es port amúgy engedélyezve van)? port=22-vel ugyanaz a jelenség áll elő, ami az eredeti probléma: befelé kiépül a kapcsolat, a visszajövő csomag viszont eltűnik valahol, majd timeouttal bontja a kapcsolatot.
Olyan érzésem van, mintha a válaszcsomagok routingja körül lenne a probléma. Szerintem érdemes lenne tenni egy log targetet a DIVERT láncba a mark utánra, hogy látsszon, valóban rákerült-e a válaszcsomagra a MARK, illetve érdemes lenne bekapcsolni a martian és az invalid csomagok loggolását is (/proc/sys/net/netfilter/nf_conntrack_log_invalid, /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid, /proc/sys/net/ipv4/conf/all/log_martians), hogy nem ezek fogják-e meg.
ezeket bekapcsoltam, nem jelent meg semmi a logban.
Milyen kernel verziót használsz?
Az ubuntu saját kernelét: 3.2.0-45-generic Köszönöm, Gábor
Szia, On 06/12/2013 09:52 AM, tusi wrote:
Szia,
köszönöm a választ,
már a linux listán is próbáltam válaszolni, de mivel nem vagyok tag, ezért az admin majd egyszer kiengedi A konfigok első ránézésre jónak tűnnek, gyorsan összedobtam egy ilyet egy kéznél lévő 3.9.5-ös GPL zorp tesztgépre, igaz ez debian wheezy, de rendben megy. Hogyan tetted fel a zorp-ot, milyen kernel van a gépen? Algernon repositoryjából, itt van hozzá a sources.list bejegyzés:
#zorp repo deb http://packages.madhouse-project.org/debian/ wheezy zorp deb-src http://packages.madhouse-project.org/debian/ wheezy zorp Zorp 3.9 (3.9.5) Revision: ssh+git://hidden@git.balabit//var/scm/git/zorp/zorp-core--mainline--4.0#master#e027ddb760607ae05caf8ac3526415a43669eeb3 Compile-Date: Jun 6 2012 17:30:01 Config-Date: 2012/06/06 Trace: off Debug: off IPOptions: off libzorpll 3.9.1.3 Revision: Compile-Date: Jun 1 2012 09:52:52 Trace: off MemTrace: off Caps: on Debug: off StackDump: off A kernel szintén 3.2, a stock debian wheezy-s. Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
A policy.py-ban gyakorlatilag ugyanaz van, mint Nálad:
def zorp_ssh(): Service(name="inter_SSH_intra", proxy_class=PlugProxy, router=DirectedRouter(dest_addr=(SockAddrInet('<szerver címe>', 22),), forge_addr=TRUE)) Dispatcher(transparent=FALSE, bindto=DBIface(protocol=ZD_PROTO_TCP, port=2224, iface="eth0", family=2), rule_port="2224", service="inter_SSH_intra")
Ez nekem így nem működik, egyből visszautasítja a kapcsolatot. Nem lehet, hogy a port=2224 helyett port=22 kellene )a 2224-es port amúgy engedélyezve van)? port=22-vel ugyanaz a jelenség áll elő, ami az eredeti probléma: befelé kiépül a kapcsolat, a visszajövő csomag viszont eltűnik valahol, majd timeouttal bontja a kapcsolatot.
Ha Te is egy másik portra teszed, akkor Nálad is működik?
Olyan érzésem van, mintha a válaszcsomagok routingja körül lenne a probléma. Szerintem érdemes lenne tenni egy log targetet a DIVERT láncba a mark utánra, hogy látsszon, valóban rákerült-e a válaszcsomagra a MARK, illetve érdemes lenne bekapcsolni a martian és az invalid csomagok loggolását is (/proc/sys/net/netfilter/nf_conntrack_log_invalid, /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid, /proc/sys/net/ipv4/conf/all/log_martians), hogy nem ezek fogják-e meg. ezeket bekapcsoltam, nem jelent meg semmi a logban. A DIVERT láncba felvetted a log sort? Megjelent ott a válaszcsomag?
Milyen kernel verziót használsz? Az ubuntu saját kernelét: 3.2.0-45-generic Ez nagyon hasonló az enyémhez, szerintem TPROXY változás ennek a környékén nem volt.
Balint
Köszönöm mindenkinek a segítséget. A gond az indító shell scriptben volt. Mint korábban írtam, ez volt benne: ... ${iptables} -t mangle -N DIVERT ${iptables} -t mangle -A PREROUTING -p tcp -m socket -j DIVERT ${iptables} -t mangle -A DIVERT -j MARK --set-mark 1 ${iptables} -t mangle -A DIVERT -j ACCEPT iptables-restore < /etc/zorp/iptables.conf ... mivel az iptables.conf-ban nem szerepelt a DIVERT chain, ezert az elozoleg letrehozot DIVERT lancot egybol le is torolte az iptables-restore..... igy jar aki maganak faragja a scripteket.. Még egyszer köszönök minden segítséget, Gábor On Wed, 2013-06-12 at 10:43 +0200, Kovács Bálint wrote:
Szia,
On 06/12/2013 09:52 AM, tusi wrote:
Szia,
köszönöm a választ,
már a linux listán is próbáltam válaszolni, de mivel nem vagyok tag, ezért az admin majd egyszer kiengedi A konfigok első ránézésre jónak tűnnek, gyorsan összedobtam egy ilyet egy kéznél lévő 3.9.5-ös GPL zorp tesztgépre, igaz ez debian wheezy, de rendben megy. Hogyan tetted fel a zorp-ot, milyen kernel van a gépen? Algernon repositoryjából, itt van hozzá a sources.list bejegyzés:
#zorp repo deb http://packages.madhouse-project.org/debian/ wheezy zorp deb-src http://packages.madhouse-project.org/debian/ wheezy zorp
Zorp 3.9 (3.9.5) Revision: ssh+git://hidden@git.balabit//var/scm/git/zorp/zorp-core--mainline--4.0#master#e027ddb760607ae05caf8ac3526415a43669eeb3 Compile-Date: Jun 6 2012 17:30:01 Config-Date: 2012/06/06 Trace: off Debug: off IPOptions: off libzorpll 3.9.1.3 Revision: Compile-Date: Jun 1 2012 09:52:52 Trace: off MemTrace: off Caps: on Debug: off StackDump: off
A kernel szintén 3.2, a stock debian wheezy-s.
Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2+deb7u2 x86_64 GNU/Linux
A policy.py-ban gyakorlatilag ugyanaz van, mint Nálad:
def zorp_ssh(): Service(name="inter_SSH_intra", proxy_class=PlugProxy, router=DirectedRouter(dest_addr=(SockAddrInet('<szerver címe>', 22),), forge_addr=TRUE)) Dispatcher(transparent=FALSE, bindto=DBIface(protocol=ZD_PROTO_TCP, port=2224, iface="eth0", family=2), rule_port="2224", service="inter_SSH_intra")
Ez nekem így nem működik, egyből visszautasítja a kapcsolatot. Nem lehet, hogy a port=2224 helyett port=22 kellene )a 2224-es port amúgy engedélyezve van)? port=22-vel ugyanaz a jelenség áll elő, ami az eredeti probléma: befelé kiépül a kapcsolat, a visszajövő csomag viszont eltűnik valahol, majd timeouttal bontja a kapcsolatot.
Ha Te is egy másik portra teszed, akkor Nálad is működik?
Olyan érzésem van, mintha a válaszcsomagok routingja körül lenne a probléma. Szerintem érdemes lenne tenni egy log targetet a DIVERT láncba a mark utánra, hogy látsszon, valóban rákerült-e a válaszcsomagra a MARK, illetve érdemes lenne bekapcsolni a martian és az invalid csomagok loggolását is (/proc/sys/net/netfilter/nf_conntrack_log_invalid, /proc/sys/net/ipv4/netfilter/ip_conntrack_log_invalid, /proc/sys/net/ipv4/conf/all/log_martians), hogy nem ezek fogják-e meg. ezeket bekapcsoltam, nem jelent meg semmi a logban. A DIVERT láncba felvetted a log sort? Megjelent ott a válaszcsomag?
Milyen kernel verziót használsz? Az ubuntu saját kernelét: 3.2.0-45-generic Ez nagyon hasonló az enyémhez, szerintem TPROXY változás ennek a környékén nem volt.
Balint
_______________________________________________ zorp-hu mailing list zorp-hu@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/zorp-hu
participants (4)
-
Gabor Tusnady
-
Kovács Bálint
-
LAJOS Janos
-
tusi