search

jpetazzo / squid-in-a-can

361 stars 78 forks source link

Docker's v1.11 networking braking use of iptables method? #24

Closed ruffsl closed 8 years ago

ruffsl commented 8 years ago

I'm using the docker-compose up to launch the transparent squid proxy, but as soon as I do, I lose access to the outside net through port 80, i.e. apt-get update will hang. Reverting the iptables changes using 

iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to 3129 -w

also does not revert the issue, nor restarting the docker service. I've only just found rebooting reverts this behavior. I had multiple appends to the same chain as the tproxy script encountered a hard stop.

$ docker --version 
Docker version 1.11.1, build 5604cbe
ruffsl commented 8 years ago

Here is a diff of how my PREROUTING channel looks like and changes

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 3129 -w
$ sudo iptables -L -vt nat 
Chain PREROUTING (policy ACCEPT 20 packets, 2319 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  277 19716 DOCKER     all  --  any    any     anywhere             anywhere             ADDRTYPE match dst-type LOCAL
+    0     0 REDIRECT   tcp  --  any    any     anywhere             anywhere             tcp dpt:http redir ports 3129

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4 packets, 240 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DOCKER     all  --  any    any     anywhere            !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 4 packets, 240 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  353 22336 MASQUERADE  all  --  any    !docker0  172.17.0.0/16        anywhere            
    0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:9090
    0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:8085
    0     0 MASQUERADE  tcp  --  any    any     172.17.0.2           172.17.0.2           tcp dpt:http-alt

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 RETURN     all  --  docker0 any     anywhere             anywhere            
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:9090 to:172.17.0.2:9090
    0     0 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:8085 to:172.17.0.2:8085
    1    40 DNAT       tcp  --  !docker0 any     anywhere             anywhere             tcp dpt:http-alt to:172.17.0.2:8080
ruffsl commented 8 years ago

Never mind, I think this has to do with the remove_redirect_cmd subprocess check_call, or exit function not being called in time before docker-compose stops the tproxy container, resulting in leftover iptable REDIRECT entries.