hackgfw
commented
11 years ago 如果使用gfw-vpn而没有用AntiDNSPoisoning, 需要修改gfw-vpn的配置文件, 把dns那几行的注释去掉, 不然dns请求还是走的本地线路. 会被污染. 另外 iptables -t mangle -L gfwvpn 应该能看到将翻墙流量打上mark的规则. 没有的话请检查下 /etc/config/gfw-vpn
Closed zeroinyang closed 11 years ago
hackgfw
commented
11 years ago 如果使用gfw-vpn而没有用AntiDNSPoisoning, 需要修改gfw-vpn的配置文件, 把dns那几行的注释去掉, 不然dns请求还是走的本地线路. 会被污染. 另外 iptables -t mangle -L gfwvpn 应该能看到将翻墙流量打上mark的规则. 没有的话请检查下 /etc/config/gfw-vpn
zeroinyang
commented
11 years ago 谢谢您的回复，dns那几行注释已经去掉，下面就是执行结果 通过ip访问的时候，同时执行了iptables，结果如下
iptables -t mangle -L gfwvpn Chain gfwvpn (3 references) target prot opt source destination
/etc/config/gfw-vpn如下，请问检查哪些内容，或者还有什么是需要检查的？ 其中那些#注释贴上的时候去掉了，因为加了都变成标题格式了。
config 'gfw-vpn' 'general' option 'enabled' '1' option 'interface' 'wall'
config 'rule' option 'proto' 'tcp' option 'port' '80'
config 'rule' option 'proto' 'tcp' option 'port' '443'
config 'rule' option 'proto' 'tcp' option 'port' '1935'
config 'rule' option 'proto' 'udp' option 'port' '53'
zeroinyang
commented
11 years ago 把ip-up-wall修改一下，直接执行后，发现问题了。 提示 iptables v1.4.10: unknown option `--set-mark'
安装了opkg install kmod-ipt-ipopt iptables-mod-ipopt后，
再执行iptables -t mangle -L gfwvpn
看到了下面的结果
Chain gfwvpn (3 references)
target prot opt source destination
MARK udp -- anywhere anywhere udp dpt:domain MARK set 0xffff
MARK tcp -- anywhere anywhere tcp dpt:1935 MARK set 0xffff
MARK tcp -- anywhere anywhere tcp dpt:https MARK set 0xffff
MARK tcp -- anywhere anywhere tcp dpt:www MARK set 0xffff
现在正常了。
hackgfw
commented
11 years ago iptables-mod-ipopt 已经是 gfw-vpn 的依赖项了, 如果通过opkg安装 gfw-vpn, 应该不会出现这个问题
zeroinyang
commented
11 years ago 谢谢您前几天的答复。 几天前配好以后，打开twitter的客户端，可以直接访问了，觉得都OK，其实还有问题。
如访问http://instagram.com/p/fW2lQWIhBd/ 打开Firefox中的Firebug看详细的情况 第一行 http://instagram.com/p/fW2lQWIhBd/ 1.68s就完成了。 第二行 http://d36xtkk24g8jdx.cloudfront.net/bluebar/ca7a258/scripts/jquery.js 就一直在load，打不开。 下面的请求都是这样的。 ping d36xtkk24g8jdx.cloudfront.net 是能访问到的 PING d36xtkk24g8jdx.cloudfront.net (54.230.143.112): 56 data bytes 64 bytes from 54.230.143.112: seq=0 ttl=51 time=380.788 ms 按照ip也应该走VPN，正常显示才对，但现在访问不了，不知道这个是什么原因？
zeroinyang
commented
11 years ago 还比如pic.twitter.com，页面可以打开，但是图片是不能显示的
hackgfw
commented
11 years ago 有可能是vpn服务器的设置问题. 有的网站不遵守tcp协议, 发送的数据超过tcp窗口大小. 如果直连网站的话问题不大, 因为客户端每收到一个数据包就会ack, 同时也滚动了窗口, 以客户端的角度看, 并没有溢出窗口, 但是如果经过vpn的话, vpn服务器是不负责ack的, 因此在vpn服务器看来tcp窗口会溢出从而导致vpn服务器主动重置连接. 只能怪网站"优化"过渡, 不惜破坏tcp协议规范. 可以在vpn服务器 /etc/sysctl.conf 中加入 net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1 使得vpn服务器不跟踪tcp窗口状态
zeroinyang
commented
11 years ago 谢谢您的回复，vpn服务器是不能改的，只是购买的vpn服务，不过可能不是vpn服务器的问题笔记本直接拨号vpn，选择「Send all traffic over VPN connection」，访问twitter.com没有前面描述的问题。 不知道还可以有什么调试的log，可以记录更多的数据，方便找到哪里的问题。
hackgfw
commented
11 years ago 你可以试试把tcp初始的窗口大小改大, 修改客户端的 /etc/sysctl.conf (不是路由器, 你用笔记本上网, 就得修改笔记本的) net.core.rmem_default=262144 net.core.rmem_max=16777216 net.core.wmem_default=262144 net.core.wmem_max=16777216 net.ipv4.tcp_mem=8192 12288 16384 net.ipv4.tcp_rmem=4096 262144 16777216 net.ipv4.tcp_wmem=4096 262144 16777216
如果不行的话或者你笔记本用的是windows系统没法改的话, 可以用wireshark抓包看看
zeroinyang
commented
11 years ago wireshark安装了，还不会用。 为了避免是前面手工配置的问题，按照说明去编译了一次，把路由器reset了，这样不会受其它影响。 第一次编译安装后，发现没有pptp，ppp-mod-pptp没有写到DEPENDS，需要手动去选。 第二次编译安装后，配置好pptp。 问题还是一样的，如twiiter.com访问了， https://abs.twimg.com/a/1382598364/t1/css/t1_core_logged_out.bundle.css，这些abs.twing.com上的css png js都不能load成功。 不知道是不是可以先简单改写为符合条件的ip都通过vpn，这样比如traceroute的时候，可以明确看到是是不走的vpn，判断起来直观一点。
hackgfw
commented
11 years ago pptp，ppp-mod-pptp没有写到DEPENDS是因为gfw-vpn也可以用于OpenVPN(需要再写个10来行的脚本) 你访问 http://www.whatismyip.com/ 看到的是VPN服务器的地址吗? 执行 iptables -t mangle -I gfwvpn -p icmp -j MARK --set-mark 0xffff 可以让traceroute请求也走VPN 另外 nslookup abs.twimg.com 得到的ip是否被污染?
zeroinyang
commented
11 years ago 谢谢您的回复。
zeroinyang
commented
11 years ago iptables -t mangle -I gfwvpn -p icmp -j MARK --set-mark 0xffff 加入ip-up-wall中了 拨通vpn和断开的情况下，traceroute www.whatismyip.com显示没有走vpn server，但是www.whatismyip.com两次分别显示了两个IP
hackgfw
commented
11 years ago 这个情况比较奇怪, 毕竟 http://www.whatismyip.com/ 显示的是vpn服务器的地址, 最好能用wireshark看下直接访问 http://d36xtkk24g8jdx.cloudfront.net/bluebar/ca7a258/scripts/jquery.js 的结果.
zeroinyang
commented
11 years ago 谢谢您的回复。 按照建议，我打开了Wireshark，同时Firefox陆续开了三个页面，首先是路由器的用来点击vpn的「connect」，接着访问http://d36xtkk24g8jdx.cloudfront.net/bluebar/ca7a258/scripts/jquery.js（这个还是没有load成功），第三个是 http://www.whatismyip.com/，再确认一下显示的是vpn服务器的地址。 保存了pcapng文件，请问怎么发给您，这里好像不能上传附件。
hackgfw
commented
11 years ago zeroinyang
commented
11 years ago 谢谢，已经上传了，麻烦您看一下，不知道能不能找到原因。 http://www.cloudshark.org/captures/83d2a1e8377c
hackgfw
commented
11 years ago 我看了下抓包结果, 你只收到了第一个包, 后面的包都没收到. 而收到的那个包有禁止分片标志, 因此我估计可能是由于后续的几个包太大, 而且同样也有禁止分片标志, 因此在通过VPN服务器时被丢弃. 这应该算是VPN服务器配置问题, 如果遵循标准的话, VPN服务器在丢弃数据包的同时应告知发送方, 以便发送方减小每个包的大小. 这个问题在windows没有遇到应该是因为windows下vpn接口的mtu默认是1400, 而linux会根据你的网络情况计算出最大可用的mtu
你可以在wall接口中加入一行 option mtu '1400' 如果你没有手动修改 /etc/config/firewall 里关于mss设置的话, openwrt会自动根据mtu计算调整mss大小
zeroinyang
commented
11 years ago 已经设置了mtu 1400，没有变化。 登录路由器看了，设定的mtu是有效的 ifconfig pptp-wall UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1400 Metric:1 wan没有设置，显示的默认值是1500，但是实际拨号后显示为1492 ifconfig pppoe-wan UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 同时担心是版本的问题，编译了两个版本，一个是trunk，一个是attitude_adjustment，表现都一样。
今天多访问了几个网站，国内和国外看上去都有一样的问题 如访问http://ruby-china.org/，这个是一个国内网站 取png的部分，Firefox显示502 Bad Gateway或504 Gateway Time-out
502错误：http://ruby-china.org/avatar/19e786a2a74377ff6e052d87fd8d1fa8.png?s=96&d=404 IP：112.226.207.19 GET /avatar/19e786a2a74377ff6e052d87fd8d1fa8.png?s=96&d=404 HTTP/1.1 Host: ruby-china.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: image/png,image/;q=0.8,/*;q=0.5 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://ruby-china.org/ Cookie: request_method=GET; _homeland_session=aW4rOVRIeWhIeisxNmYzU0tnRUZGU2xQcUgvVUE2MFAzUGtzbXU4Uy9tclNjRDRZUXRBblNIVU05MnREUWNuaVo3MEpwZVZxUkhRNWcySlNFT1VwckpZMTdsY2hEVktNT1dQVDl6RGI4ZGxVdjFDWDl0TFNyRktpSjY3Z0NBYlNRaVp2SEVQT0lDVzBRVFZQOGJIWXhlOEh5bFRQNHV4enZQUHBNK0JMQ3EvYjI2WTBwcCtZR1lGN213eHc3Zi8yLS1nbU9VUzBOK1ZPZkR3cFo4VlExNlBnPT0%3D--1bec09c10ca35854a9b2949d988cd73f7d1bab74; utma=34396194.758391661.1382933709.1382933709.1382933709.1; utmb=34396194.4.7.1382933709; utmc=34396194; utmz=34396194.1382933709.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) Connection: keep-alive
HTTP/1.1 502 Bad Gateway Server: nginx/1.4.2 Date: Mon, 28 Oct 2013 04:15:22 GMT Content-Type: text/html Content-Length: 172 Connection: keep-alive
504错误：http://ruby-china.org/avatar/da01dbea6f1d88e8a1c39f48900d394b.png?s=96&d=404 IP：112.226.207.19 GET /avatar/da01dbea6f1d88e8a1c39f48900d394b.png?s=96&d=404 HTTP/1.1 Host: ruby-china.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: image/png,image/;q=0.8,/*;q=0.5 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://ruby-china.org/ Cookie: request_method=GET; _homeland_session=aW4rOVRIeWhIeisxNmYzU0tnRUZGU2xQcUgvVUE2MFAzUGtzbXU4Uy9tclNjRDRZUXRBblNIVU05MnREUWNuaVo3MEpwZVZxUkhRNWcySlNFT1VwckpZMTdsY2hEVktNT1dQVDl6RGI4ZGxVdjFDWDl0TFNyRktpSjY3Z0NBYlNRaVp2SEVQT0lDVzBRVFZQOGJIWXhlOEh5bFRQNHV4enZQUHBNK0JMQ3EvYjI2WTBwcCtZR1lGN213eHc3Zi8yLS1nbU9VUzBOK1ZPZkR3cFo4VlExNlBnPT0%3D--1bec09c10ca35854a9b2949d988cd73f7d1bab74; utma=34396194.758391661.1382933709.1382933709.1382933709.1; utmb=34396194.4.7.1382933709; utmc=34396194; utmz=34396194.1382933709.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) Connection: keep-alive
HTTP/1.1 504 Gateway Time-out Server: nginx/1.4.2 Date: Mon, 28 Oct 2013 04:19:21 GMT Content-Type: text/html Content-Length: 182 Connection: keep-alive
hackgfw
commented
11 years ago 有的时候在vpn协商时本地的mtu值和服务器的mtu值会相差4. 你可以试着在 ip-up-wall 里再加一句 ifconfig $PPP_IFACE mtu 1300 另外 iptables -t mangle -nvL 应该能看到修改TCPMSS的规则
hackgfw
commented
11 years ago 至于你提到的502 和504错误,这个一般是网站问题, 现在我这里访问这个连接也是出同样的错误
zeroinyang
commented
11 years ago 谢谢您的回复。 语句加好了，现在访问当前页面没有了，可以不用断开vpn来回复了。
ifconfig pptp-wall pptp-wall Link encap:Point-to-Point Protocol UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1300 Metric:1
iptables -t mangle -nvL Chain PREROUTING (policy ACCEPT 229 packets, 41625 bytes) pkts bytes target prot opt in out source destination 44 5395 gfwvpn all -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set whiteip src ! match-set whiteip dst ! match-set whitezone dst 235 41997 fwmark all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 149 packets, 20842 bytes) pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 80 packets, 20783 bytes) pkts bytes target prot opt in out source destination 34 4475 gfwvpn all -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set whiteip src ! match-set whiteip dst ! match-set whitezone dst 82 20911 mssfix all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 127 packets, 24237 bytes) pkts bytes target prot opt in out source destination 68 7571 gfwvpn all -- * * 0.0.0.0/0 0.0.0.0/0 ! match-set whiteip src ! match-set whiteip dst ! match-set whitezone dst
Chain POSTROUTING (policy ACCEPT 207 packets, 45020 bytes) pkts bytes target prot opt in out source destination
Chain fwmark (1 references) pkts bytes target prot opt in out source destination
Chain gfwvpn (3 references) pkts bytes target prot opt in out source destination 0 0 MARK udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 MARK set 0xffff 0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:1935 MARK set 0xffff 74 9190 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 MARK set 0xffff 1 40 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK set 0xffff
Chain mssfix (1 references) pkts bytes target prot opt in out source destination 2 128 TCPMSS tcp -- * pptp-wall 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /* wan (mtufix) / TCPMSS clamp to PMTU 4 256 TCPMSS tcp -- * pppoe-wan 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 /_ wan (mtu_fix) */ TCPMSS clamp to PMTU
zeroinyang
commented
11 years ago 访问http://ruby-china.org/，502 和504错误，断开vpn后确实也是这样，昨天访问是好的，今天vpn拨拨通后，直接就测试一下，没有在断开后对比。
hackgfw
commented
11 years ago 根据以上信息，这个问题总结下来： 1 vpn服务器或所访问的网站不支持 Path MTU Discovery，这是问题的根源，如果支持的话下面几条都不需要了。而且通常来讲绝大部分网站都支持PMTU的，因此问题很有可能是出在vpn服务器。 2 vpn服务器没有修正tcp协商时的mss值 3 vpn服务器在协商mtu时其值与客户端的不一致
你可以把wall接口中的 option mtu '1400' 删掉，然后逐步调大 ifconfig $PPP_IFACE mtu 1300 找到能正常访问的最大值，然后设置成最大值减去20基本就可以在保证网络性能的同时又不会遇到无法访问网站。
zeroinyang
commented
11 years ago 还测试了一下，如果把上面的ipconfig变为wall接口中设置option mtu '1300'，就是不正常的，只能用ifconfig $PPP_IFACE mtu 1300，虽然ifconfig pptp-wall看到的mtu都是1300。
hackgfw
commented
11 years ago 因为 “3 vpn服务器在协商mtu时其值与客户端的不一致” 所以你设置成option mtu '1300'就不正常了 虽然你本地看到的mtu是1300，但是服务器上mtu是1296，数据包因为比1296大4个字节而被vpn服务器丢弃 所以只要你ifconfig pptp-wall看到的mtu比协商时的mtu小4个字节就不会有问题，比如option mtu '1400'，ifconfig pptp-wall mtu 1396 就不会有问题
zeroinyang
commented
11 years ago 非常感谢，现在使用正常了，下面就是联系vpn提供商，看看他们是不是可以修正这个问题。 本来还准备测试l2tp，担心是pptp的问题，正好提供商提供了两种方式pptp和l2tp，然后安装了xl2tpd，但是界面只有用户名和密码，没有地方输入预共享密钥，就放弃了。
zeroinyang
commented
11 years ago 最后测试结果的是/etc/config/network中就是不加入option mtu，那么mtu就是默认值1500，然后小4个字节 ifconfig $PPP_IFACE mtu 1496 下午向提供商提交了ticket，结果就是「openwrt 本身不是很稳定，并且路由器上配置 VPN 的问题可能情况很多，能保证 VPN 服务肯定没问题」，「建议路由器或电脑上调整 MTU」等等，按照上面三个问题问了很详细，就是没有直接的回复。 等到期了，自己用vps搭一个了，请问您的PPTP server是什么配置，用系统的默认包就可以了，就已经有了Path MTU Discovery，还是需要有些什么设定？
hackgfw
commented
11 years ago mtu 如果是1500的话，会导致底层数据包分片，如果链路上有丢包会比较影响性能。我实测下来pppoe上网的话，1448的mtu就不会导致底层数据包分片了。 至于Path MTU Discovery，只要你的防火墙允许icmp通过就没有问题，不过你还要看vps服务商的防火墙，比如ec2默认就会屏蔽icmp，需要手动开
zeroinyang
commented
11 years ago 谢谢，mtu改为1448了。
ScrewChineseCommunist
commented
9 years ago 我的1448连不上google，1440连了11次终于行了
现在pptp连接成功 pptp-wall Link encap:Point-to-Point Protocol
inet addr:10.10.0.15 P-t-P:10.10.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:86 (86.0 B) TX bytes:92 (92.0 B)
ipset -L whitezone | wc -l 3587
iptables看起来有了 iptables -t mangle -L gfwvpn Chain gfwvpn (3 references) target prot opt source destination
iptables -t mangle --list-rules gfwvpn -N gfwvpn
这个文件/etc/iproute2/rt_tables里有"11 wall"
下面就不知道怎么debug，看问题出在哪里，请问怎么来查找问题，可以正常使用