shadowsocks / shadowsocks-libev

Bug-fix-only libev port of shadowsocks. Future development moved to shadowsocks-rust
https://github.com/shadowsocks/shadowsocks-rust
GNU General Public License v3.0
15.79k stars 5.69k forks source link

shadowsocks does not work well with docker #2086

Closed rdbox closed 6 years ago

rdbox commented 6 years ago

Please answer these questions before submitting your issue. Thanks!

(Please mention that if the issue you filed is solved, you may wish to close it by yourself. Thanks again.)

(PS, you can remove 3 lines above, including this one, before post your issue.)

What version of shadowsocks-libev are you using?

shadowsocks-libev 3.1.3

What operating system are you using?

windows 7 pro + docker

What did you do?

I run shadowsocks like this command

ss-server -c /etc/shadowsocks-libev/config_no_obfs.json -uv

What did you expect to see?

What did you see instead?

after a while shadowsocks stops working and any site does not ping in the most docker container

What is your config in detail (with all sensitive info masked)?

{
    "server":"0.0.0.0",
    "server_port":8000,
    "local_address":"",
    "local_port":1080,
    "password":"123",
    "timeout":600,
    "method":"aes-256-cfb",
    "plugin":"",
    "plugin_opts":""

}

ss-local this gui shadowsocks windows 7 image

the problem appears by itself, I've already turned off everything I can and removed the -u option, the problem still does not go away.

this ip 192.168.99.100 is the address of my docker-machine

nameserver 10.0.2.3
root@ff7d16b0c8e5:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      *               255.255.0.0     U     0      0        0 eth0
root@ff7d16b0c8e5:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
root@ff7d16b0c8e5:~# 
root@ff7d16b0c8e5:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02
          inet addr:172.17.0.2  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1270 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:90854 (88.7 KiB)  TX bytes:95986 (93.7 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@ff7d16b0c8e5:~#
root@ff7d16b0c8e5:~# ping bing.com
ping: unknown host bing.com
root@ff7d16b0c8e5:~#
rdbox commented 6 years ago

more a request to the developers do not close the question until we solve the problem.

madeye commented 6 years ago

Try https://mtyurt.net/post/docker-how-to-increase-number-of-open-files-limit.html

rdbox commented 6 years ago

here is the output of the ulimit command there are great parameters. And with this setting, the connection between the ss-server and ss-local What other suggestions are there?

root@ff7d16b0c8e5:~# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 3804
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1048576
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1048576
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
root@ff7d16b0c8e5:~#
rdbox commented 6 years ago

I think the problem is not only in the docker itself but in the entire docker-machine because when the Internet breaks inside the container. the docker-machine ls command does not work. To fix the work of docker + shadowsocks, I need to do a full restart of docker-machine restart.

I really hope that you could understand me

madeye commented 6 years ago

Read the link carefully.

Your problem has nothing to do with shadowsocks-libev. It'd be a typical misconfiguration problem.

rdbox commented 6 years ago

I read the instructions, and I already answered it does not help me I already wrote in support of the docker. I was told that this works bad shadowsocks.

then you must help to find the problem

madeye commented 6 years ago

No one can help you unless you can provide detailed information to reproduce your problem.

Shadowsocks-libev is a user-space software that works well on any container. If it's a docker specific problem, please report it to Docker instead.

rdbox commented 6 years ago

this is a joke?? I provided all the detailed information. I need to work now and I can not, I perfectly understand that shadowsocks are software.

I once again write to you, that to me support Docker has written that the problem at you a problem in shadowsocks most

you know your program better how it works, so why these empty words ?.

I need a solution, I need the right actions to understand where the problem lies. and how to solve it, and find solutions

I have been suffering with this problem for more than a month. And I already have nerves, I'm very angry

madeye commented 6 years ago

If you believe the problem is related to shadowsocks-libev, just try shadowsocks-python or go-shadowsocks2 in your docker instead.

It's not necessary to stick with this project, we have a lot of different implementations of shadowsocks protocol, the best solution for now is trying them instead

rdbox commented 6 years ago

then let's try somehow to test the work of docker that would reveal an anomaly.

And to understand what the problem is, I like the implementation of shadowsocks-libev

madeye commented 6 years ago

You can try other implementations first to verify if it's a shadowsocks-libev specific issue.

If yes, since your setup is very special, which is Windows + docker, I suggest debugging it yourself. Anyone using this setup can also help reproduce your problem.

And of course, it's not necessary, we don't force anyone to use shadowsocks-libev as the shadowsocks server. That's also why we provided so many implementations here.

madeye commented 6 years ago

Other implementations you may try:

https://github.com/shadowsocks/go-shadowsocks2

https://github.com/shadowsocks/shadowsocks

https://github.com/shadowsocks/shadowsocks-rust

All of them above have prebuilt packages or binaries.

rdbox commented 6 years ago

well, I will try these versions of the implementation. If the problem is, do I have to create a new question? or write here

kubecto commented 7 months ago

For docker pull images, you need to set up an agent to tell the docker daemon. This is my configuration

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target firewalld.service containerd.service
Wants=network-online.target

[Service]
Type=notify
Environment="HTTP_PROXY=socks5://127.0.0.1:1080/" "HTTPS_PROXY=socks5://127.0.0.1:1080/"
ExecStart=/usr/bin/dockerd
ExecReload=/bin/kill -s HUP $MAINPID
ExecStartPost=/usr/sbin/iptables -P FORWARD ACCEPT
TimeoutSec=0
RestartSec=2
Restart=always
StartLimitBurst=3
StartLimitInterval=60s
LimitNOFILE=1500000
LimitNPROC=infinity
LimitCORE=infinity
TasksMax=infinity
Delegate=yes
KillMode=process

[Install]
WantedBy=multi-user.target

Then systemctl daemon-reload &&systemctl restart docker can pull the image

docker pull registry.k8s.io/build-image/kube-cross:v1.28.0-go1.20.13-bullseye.0

You can view client logs

2024/01/29 14:12:16 tcp.go:87: proxy 127.0.0.1:53850 <-> x.x.x.x:8388 <-> registry.k8s.io:443