search

clowwindy / ShadowVPN

Removed according to regulations.
1.47k stars 1.06k forks source link

ping 10.7.0.1 no reply #109

Closed 4ft35t closed 9 years ago

4ft35t commented 9 years ago

client 和 server 都是 ubuntu 12.04 x86，编译安装。

  1. client 可以 ping server IP
  2. client ping 10.7.0.1 无回应

client tcpdump -i tun0

17:53:16.501119 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 678, length 64
17:53:17.501123 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 679, length 64
17:53:18.501164 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 680, length 64
17:53:19.501173 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 681, length 64
17:53:20.501265 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 682, length 64

server tcpdump -i tun0

05:51:56.472750 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 678, length 64
05:51:56.472769 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 24453, seq 678, length 64
05:51:57.463229 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 679, length 64
05:51:57.463252 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 24453, seq 679, length 64
05:51:58.468329 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 680, length 64
05:51:58.468347 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 24453, seq 680, length 64
05:51:59.468024 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 681, length 64
05:51:59.468050 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 24453, seq 681, length 64
05:52:00.468331 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 24453, seq 682, length 64
05:52:00.468350 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 24453, seq 682, length 64

client iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

server iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

使用 openwrt 做 client 也是同样问题，是我的 server 有问题吗？

cj1324 commented 9 years ago

建议对ShadowVPN 的udp端口进行抓包。server /client 对比。排除墙的干扰。

4ft35t commented 9 years ago

同一台机器上的 ShadowSocks 工作正常，晚上看看 udp 端口转包情况

riadev commented 9 years ago

我也有类似问题。 具体表现很奇怪：

如果在客户端持续ping 10.7.0.1 是不通的。 但是，这时候，我在screen里面持续保持ping 10.7.0.1 同时重启shadownvpn客户端。 会发现screen里面有连续sequence的3个包可以通，然后，就不通了。

不断重启shadownvpn的客户端，可以重现同样的现象。

为了防止干扰，我把client_up.sh里面的脚本都注释掉[不注释的时候，其实现象是一样的]，只剩下

ifconfig $intf 10.7.0.2 netmask 255.255.255.0

客户端：重启之后，就只有3个ping可以通，之后就不行了。

shadowvpn158client:~$ ping 10.7.0.1
PING 10.7.0.1 (10.7.0.1) 56(84) bytes of data.
64 bytes from 10.7.0.1: icmp_seq=9 ttl=64 time=119 ms
64 bytes from 10.7.0.1: icmp_seq=10 ttl=64 time=117 ms
64 bytes from 10.7.0.1: icmp_seq=11 ttl=64 time=117 ms

服务端抓包：这三个回应后，就停止了。

root@shadowvpn158server:~# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
19:17:58.497619 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 3328, seq 9, length 64
19:17:58.497729 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 3328, seq 9, length 64
19:17:59.497424 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 3328, seq 10, length 64
19:17:59.497467 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 3328, seq 10, length 64
19:18:00.499334 IP 10.7.0.2 > 10.7.0.1: ICMP echo request, id 3328, seq 11, length 64
19:18:00.499360 IP 10.7.0.1 > 10.7.0.2: ICMP echo reply, id 3328, seq 11, length 64

客户端抓eth0到服务器的包：可以看到是有出无回。

root@shadowvpn158client:/etc/shadowvpn# tcpdump -i eth0 host 45.63.122.145 -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:24:03.496735 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 136)
    192.168.168.21.54957 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
15:24:04.496684 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 136)
    192.168.168.21.54957 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
15:24:05.496678 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 136)
    192.168.168.21.54957 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
15:24:06.496674 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 136)
    192.168.168.21.54957 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
15:24:07.496757 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 136)
    192.168.168.21.54957 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108

服务端这时候抓的包也很奇怪，只有这三个包能通过的时候，可以抓到如下包，然后，客户端ping不通了之后，就什么也抓不到了。这个IP是我的公网ip 114.111.167.211

root@shadowvpn158server:~# tcpdump  host 114.111.167.211 -i eth0  -vv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:30:56.573182 IP (tos 0x0, ttl 44, id 31150, offset 0, flags [none], proto UDP (17), length 136)
    114.111.167.211.3923 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
19:30:56.573522 IP (tos 0x0, ttl 64, id 14900, offset 0, flags [DF], proto UDP (17), length 136)
    45.63.122.145.vultr.com.4000 > 114.111.167.211.3923: [bad udp cksum 0xc298 -> 0x5058!] UDP, length 108
19:30:57.574076 IP (tos 0x0, ttl 44, id 56623, offset 0, flags [none], proto UDP (17), length 136)
    114.111.167.211.3923 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
19:30:57.574323 IP (tos 0x0, ttl 64, id 15039, offset 0, flags [DF], proto UDP (17), length 136)
    45.63.122.145.vultr.com.4000 > 114.111.167.211.3923: [bad udp cksum 0xc298 -> 0xbf3b!] UDP, length 108
19:30:58.573966 IP (tos 0x0, ttl 44, id 32954, offset 0, flags [none], proto UDP (17), length 136)
    114.111.167.211.3923 > 45.63.122.145.vultr.com.4000: [udp sum ok] UDP, length 108
19:30:58.574115 IP (tos 0x0, ttl 64, id 15247, offset 0, flags [DF], proto UDP (17), length 136)
    45.63.122.145.vultr.com.4000 > 114.111.167.211.3923: [bad udp cksum 0xc298 -> 0x6e88!] UDP, length 108

也发现了udp bad chksum 信息。 不知道是不是GFW影响的结果。

fengqi commented 9 years ago

我也碰到同样问题, 不过我客户端是 os x, 然后ubuntu14, tcpdump 没包. ufw disable 再 enable 后有包, 但是 length 全部是0, 还是无法正常连通.

clowwindy commented 9 years ago

Merged to https://github.com/clowwindy/ShadowVPN/issues/114