Closed mengbingrock closed 8 years ago
启动 iptables 和 ss-redir 之后,可以先在服务器 curl https://www.google.com
,如果成功,就只是 VPN 的问题。
非常感谢您的回复!
在国内服务器 curl https://www.google.com
的结果如下
curl https://www.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="https://www.google.co.jp/?gfe_rd=cr&ei=_F5sV9W0NazY8geuxoHgDg">here</A>.
</BODY></HTML>
于是继续 curl "https://www.google.co.jp/?gfe_rd=cr&ei=_F5sV9W0NazY8geuxoHgDg" 好长时间没有反应。
看起来似乎没有成功,可是自动解析的.jp域名,因为我国外的服务器位于日本。所以也不能说完全不成功。 我在日本的服务器ss不是libev 版本,是python版本,不知道会不会是这里出问题。 python版本的服务器记载了尝试访问google的请求
2016-06-23 22:12:47 INFO connecting 216.58.203.4:443 from ::ffff:42.159.237.109:1145`
其中42.159.237.109是国内vps ip地址,216.58.203.4是推测是Google服务器地址。
iptable 启动结果(sudo iptables -L -n -v)
`Chain INPUT (policy ACCEPT 14784 packets, 48M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:225
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:68
0 0 ACCEPT esp -- eth0 * 0.0.0.0/0 0.0.0.0/0
6 4788 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
369 48378 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT esp -- venet0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT esp -- venet0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- venet0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- venet0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT esp -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT esp -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
0 0 ACCEPT esp -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:500
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:4500
0 0 ACCEPT udp -- eth0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1701
0 0 ACCEPT tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1723
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT all -- * * 10.31.0.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.1.0/24 0.0.0.0/0
0 0 ACCEPT all -- * * 10.31.2.0/24 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 11646 packets, 49M bytes)
pkts bytes target prot opt in out source destination
帮你修正了一下 Markdown 格式。
既然 Server 端收到连接的请求,就证明 ss-redir 是正常的,服务端是什么版本对这个没影响。
这个应该就是 VPN 不正常而已,我估计是你一开始参数设置错了。 请问你的服务器是什么类型?openvz or xen/kvm? 脚本运行的时候会询问用户的,你检查一下有没有设置错,把 iptables 错误的条目清除掉。
谢谢您的耐心解答和对格式修正。 我也觉得是vpn工作不正常。我的国内服务器应该是kvm,选择的时候应该没错。 我发现eth0的ip地址是内网地址,和外网地址是不同的。并且在安装vps时候域名我填写的域名为服务商提供的二级域名,二级域名指向外网地址。不知道会不会这里出问题。 另外国内的vps服务商默认关闭除了22外的所有端口,我去手动开放了1723和我Google到的一些ipsec认证需要用到的端口。不知道会不会是这里出问题。 感谢您的帮助。
那应该是 eth1 是公网的网卡,你可以清除 iptables 之后再来一次。
可是只有一个eth0,没有eth1。运营商好像做了转发之类的。
换言之并没有公网 IP ?
对外有公网ip的,用二级域名或者公网ip都可以ssh到vps。只是奇怪的是公网ip和eth0的ip地址不同,不知道运营商这样做想节约ip还是什么。运营商是高冷的azure。
eth0 Link encap:Ethernet HWaddr 00:17:fa:00:33:71
inet addr:10.215.134.26 Bcast:10.215.135.255 Mask:255.255.254.0
inet6 addr: fe80::217:faff:fe00:3371/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:269664 errors:0 dropped:0 overruns:0 frame:0
TX packets:327665 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:154973191 (154.9 MB) TX bytes:56559073 (56.5 MB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:26973 errors:0 dropped:0 overruns:0 frame:0
TX packets:26973 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:83911427 (83.9 MB) TX bytes:83911427 (83.9 MB)
的确很奇怪,网卡不是公网 IP,外网访问应该是转发的,azure 比较神奇。
我接着在本地树莓派测试了一下,ubuntu-mate系统内核 4.1.19-v7+ 现象完全相同,连接成功无法打开任何网页。ip地址填写的本地地址192.168.1.2。 我想是不是自己连接的验证方法写错了。我在OS X上选择的是cisco ipsec, win10上是不是没有提供合适的vpn选项,L2TP/IPsec 和 IKEv2都不work,无法连接成功。 另外是否可以选择不是非常安全的pptp和l2tp,比较适合校园内网,并且一般带有vpn功能的路由器会支持。 感谢!
可以,你完全可以配置任何一个 VPN,然后运行这份脚本即可。
首先很感谢作者。 我是Linux新手,不知道无法打开网页是因为iptable的问题,于是重启; 然后就无法连接了,我看到ss-redir在运行,但是不确定和ipsec有关的东西是不是开机启动呢? 谢谢!
更新,看了脚本文件发现需要启动 ipsec:
ipsec start
可是还是无法打开网页,无论是百度还是Google再次更新:怀疑是iptable的问题,可是无奈我不懂iptable 我把前几个函数注释掉,只运行最后一个set_iptables 函数,并且变量赋值 os=1 ethX="eth0" shadowsocksport= “使用的port"