不是翻墙的时候吗。。。

下个文件下半天，本来几分钟就可以完成的事情，要花 N 个小时。

人手两台 vps 才够应急啊，昨天搬瓦工的一台凤凰城的看那 icmp 丢包率至少 90%以上，从来没见这么夸张过，今天 ping 又正常了，只有 180ms ，比另外一台还低。。。

刚开始用那天 ps -aux 注意到有 2 个 dhcpcd 的进程的，今天装了 dhcpcd5 也不知道装对了没，现在 ps -aux 里见不到这个进程，目前手动指定还好没什么问题。。。

# apt-cache search dhcpcd
dhcpcd-dbus - DBus bindings for dhcpcd
dhcpcd-gtk - GTK+ frontend for dhcpcd and wpa_supplicant
dhcpcd5 - DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet6 dhcp
accept_ra 1
iface eth0 inet dhcp

汗，用的 debian 8 ，重启多次还是 ip 消失。

虽然用以下命令能修复网络连接，但是发现一些原先正常的服务像 dnsmasq 却无法启动，以前没玩过 kvm 也不知道哪里搞错了，看情况只能重装。。。。

#ifconfig eth0 hw ether 02:04:a3:2c:98:ac

ip address add 163.44.152.172/23 dev eth0
ip route add default via 163.44.152.1

#apt-get install dhcpcd5
#systemctl enable dhcpcd
#systemctl start dhcpcd
echo "nameserver 163.44.146.11">>/etc/resolv.conf
echo "nameserver 163.44.146.12">>/etc/resolv.conf

ip address add 2001:df6:b800:1130:163:44:152:172/64 dev eth0
#ip -6 route add default via 2001:0DF6:B800:1130::1

网上搜索情况提到针对 conoha 的限速
有说客服回复一小时不好达到十几 g 流量
有说不能长时间以 20mbps 流量下载

假设 10g 的话 10*1020*1024/3600=2912.71kb/s ，干脆直接对 ouput 方向限速 eth0 接口 20mbps 以防万一。实际新加坡，估计是共享的，它不像搬瓦工要慢就持续慢，有时候慢到才 500kbps ，刚想说连搬瓦工都不如，隔几分钟它又上去了。。。

TC=$(which tc)

DOWNLINK=2560
interface=eth0

$TC qdisc del dev $interface root 2> /dev/null > /dev/null

$TC qdisc add dev $interface root handle 1: htb default 3
$TC class add dev $interface parent 1: classid 1:1 htb rate $((DOWNLINK))kbps

迅雷属于断点续传

单线程下不动的时候最好用专门的下载软件。大概有两三个月时间，现在开 putty 窗口都要另外开一个窗口专门 ping 服务器避免没响应。用过的工具即便是运行在端口 80 443 仍然有一定的机率被 tcp reset ，像工作在 1723 这个 pptp 端口好的时候很好，坏的时候连续 N 个 tcp reset ，然后 youtube 就从高峰掉到 500kbps 以下。

呵，记得同事当时是说要不是封了 google ，她才不用 baidu 。

没办法，在无法访问 google 的时候也只能用百度。大概做了 2 年的百度 SEO 报销，从当初的小打小闹 2 万，后来月月固定 6 万，实际去年整整消费了 94 万，对一个无法盈利的部门，苦笑整个部门都在为 baidu 打工。去年大概 3 月份的时候充 2 万到 google 做推广，结果年底又还回来 18K 。而 baidu 呢，根本不清不楚，每天集中就是 2 千多的消费几小时就没了。然后也就 360 推广，基本就无人跟 baidu 竞争 SEO ，一个关键词都高达 30 多块。。。

这家的 dns 确实有点问题

访问 ipv6-test.com 的时候由于指向了 fonts.googleapis.com ，结果这个域名指向国内的 ip ，导致页面半天没反应。昨天平板用 vpn firefox 刚升级就出现很多网站打不开，不知道是否是因为 dns 查询的问题。有点怕怕，本来想用它来 fq ，结果它又指回国内的 ip ，危险分子。

nslookup fonts.googleapis.com
Server: 163.44.146.11
Address: 163.44.146.11#53

Non-authoritative answer:
fonts.googleapis.com canonical name = googleadapis.l.google.com.
googleadapis.l.google.com canonical name = googleadapis-china.l.google.com.
Name: googleadapis-china.l.google.com
Address: 203.208.48.130
Name: googleadapis-china.l.google.com
Address: 203.208.48.135

用 nslookup fonts.googleapis.com 8.8.8.8 仍然是国内的结果。

最后只能通过搬瓦工查询，在 dnsmasq 指定
address=/fonts.googleapis.com/74.125.196.95

才发现以前在路由里一直正常的强制重定向，在 vps 里根本无法生效，
#iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to 192.168.40.253

由于在 vps 上 vpn 用了虚拟接口，就直接编辑 /etc/resolv.conf 添加,终于挂代理时正常了。
nameserver=192.168.30.1

好了，这下没问题了，用了一下 www.google.com/ncr ，希望不会有安全问题

现在 firefox
https://www.google.com.hk/#q=ip
https://www.google.com/?gws_rd=ssl#q=ip

Unknown - Use precise location

晕，对 google 这个 ip 判定不懂，刚在挂 vpn 状态下面，显示为上海浦东新区，后来点了一下 更新位置信息，却又变成 本地 ISP 位置。。。就是没说是 新加坡 的。

根据以前 conoha 的口碑直接买了新加波， 1170 日元换算下来 60+元，跟 linode 的价格没差几块。搜了一下挂靠在 GMO 名下的 vps 还真不少，至少有 5 家。
虽然现在新开网速还不错，没个三个月不知道结果。 conoha 的口碑并不好，其中有一条就是持续长时间 20mbps 以上的流量就可能被限速为 64kb/s ， 24 小时解封。。。甚至包括直接的停机或者删除。。。不知道为什么这个新加波 ip google 却判定为上海浦东新区，网上是有反应它家的 dns 解析的 google ip 为墙内的北京 203.。

无语 softether + ocserver 都正常连上了。晕晕晕。

不行， google 的结果说有些 conoha 的一些早期用户没问题，后面的用户有人反应 openvpn 没问题，其它的 pptp softethervpn 都是禁止的，而且最关键的一点是，防火墙上隐蔽了 vpn 的相关协议和端口，晕死。用 nmap 也扫不到 udp 4500 ，太坑了。。。如果这样的话，网上即便有重装系统的方法，防火墙端口却不受自己控制。。。

Starting Nmap 6.49BETA6 ( https://nmap.org ) at 2015-11-20 19:44 ?D1ú±ê×?ê±??
NSE: Loaded 131 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 19:45
Completed NSE at 19:45, 0.01s elapsed
Initiating NSE at 19:45
Completed NSE at 19:45, 0.00s elapsed
Initiating Ping Scan at 19:45
Scanning xxx.xxx.xxx.xxx [4 ports]
Completed Ping Scan at 19:45, 0.44s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 19:45
Completed Parallel DNS resolution of 1 host. at 19:45, 0.01s elapsed
Initiating SYN Stealth Scan at 19:45
Scanning v163-44-152-172.a00d.g.sin1.static.cnode.io (xxx.xxx.xxx.xxx) [1000 ports]
Discovered open port 22/tcp on xxx.xxx.xxx.xxx
Discovered open port 111/tcp on xxx.xxx.xxx.xxx
Discovered open port 1723/tcp on xxx.xxx.xxx.xxx
Discovered open port 5555/tcp on xxx.xxx.xxx.xxx
Discovered open port 992/tcp on xxx.xxx.xxx.xxx
Discovered open port 990/tcp on xxx.xxx.xxx.xxx
Discovered open port 1080/tcp on xxx.xxx.xxx.xxx
Discovered open port 465/tcp on xxx.xxx.xxx.xxx
Discovered open port 179/tcp on xxx.xxx.xxx.xxx
Completed SYN Stealth Scan at 19:45, 9.66s elapsed (1000 total ports)
Initiating UDP Scan at 19:45
Scanning v163-44-152-172.a00d.g.sin1.static.cnode.io (xxx.xxx.xxx.xxx) [1000 ports]
Discovered open port 111/udp on xxx.xxx.xxx.xxx
Discovered open port 123/udp on xxx.xxx.xxx.xxx
Increasing send delay for xxx.xxx.xxx.xxx from 0 to 50 due to max_successful_tryno increase to 5
Increasing send delay for xxx.xxx.xxx.xxx from 50 to 100 due to max_successful_tryno increase to 6
Warning: xxx.xxx.xxx.xxx giving up on port because retransmission cap hit (6).
Increasing send delay for xxx.xxx.xxx.xxx from 100 to 200 due to 11 out of 13 dropped probes since last increase.
UDP Scan Timing: About 7.84% done; ETC: 19:51 (0:06:04 remaining)
Increasing send delay for xxx.xxx.xxx.xxx from 200 to 400 due to 11 out of 11 dropped probes since last increase.
Increasing send delay for xxx.xxx.xxx.xxx from 400 to 800 due to 11 out of 11 dropped probes since last increase.
UDP Scan Timing: About 11.10% done; ETC: 19:54 (0:08:09 remaining)
UDP Scan Timing: About 14.01% done; ETC: 19:56 (0:09:18 remaining)
UDP Scan Timing: About 16.83% done; ETC: 19:57 (0:09:58 remaining)
Discovered open port 500/udp on xxx.xxx.xxx.xxx
Discovered open port 53/udp on xxx.xxx.xxx.xxx

18:41 stunnel tcp 流量还是全速的，就是不知道为什么常用的 softether ocserv 没一个成功， vpn 看情况也无力解决。。。

搜 conoha 时就注意到有些用户反应服务器不能建 vpn ，虽然仍然看到部分用 openvpn 的用户成功了。今天搭的第一个软件 softethervpn 已经失败，这个一贯 3 分钟解决的软件，却不知道这个 Network system 是什么原因，继续 ocserv

---------------------------------------------------
SoftEther VPN Operation Environment Check Tool

Copyright (c) SoftEther VPN Project.
All Rights Reserved.

If this operation environment check tool is run on a system and that system passes, it is most likely that SoftEther VPN software can operate on that system. This check may take a while. Please wait...

Checking 'Kernel System'...
Pass
Checking 'Memory Operation System'...
Pass
Checking 'ANSI / Unicode string processing system'...
Pass
Checking 'File system'...
Pass
Checking 'Thread processing system'...
Pass
Checking 'Network system'...
Connect Failed. (0)
Fail

Some checks failed. Please check the operation environment of this system. If SoftEther VPN Server / Bridge were to be executed on this system, troubles may occur.

The command completed successfully.


--------------------------------------------------------------------
The preparation of SoftEther VPN Server is completed !

我也来个小尾巴，试试日本的。
https://cloud.z.com/jp/zh/signup/?token=wEvzVfYaOd2rd7HhMBytbllv9tguceuMr3jUp3PQJ1hFL.Jx_.0-G70

很多教程都忽略了防火墙的默认状态。
一般省事点都是
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

以下针对 ocserv 的回复， vpn 防火墙部分都差不多，由于 ocserv 会新建 vpns0 vpns1 ，所以 vpns+是通配符

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m state --state INVALID -j DROP
-A INPUT -i lo -m state --state NEW -j ACCEPT
-A INPUT -i vpns+ -j ACCEPT #大多数教程都少了这条，导致无法进行 dns 查询

-A POSTROUTING -o venet0 -j MASQUERADE

pptp ，怎么这东西还是这么多人用。

vpn 的话 l2tp 没问题，但是还是推荐 ocserv 提供的 anyconnect ，主要优势在于端口可以随意指定， udp 流量夸张，客户端丰富，连接非常稳定。 softethervpn 提供的 l2tp 目前只有手机端正常， windows 还是会被干扰，而 SSTP 似乎是有 linux 下的客户端，还是建议 ocserv ，可以更改端口就是一个很大的优势。

ss 的话， 8 月份就爆出返回探测的时候有问题，虽然前段时间用了一下最新的 libev 版本，但是 windows-gui 客户端还是老提示 timeout ，不大用这个。

用 stunnel 吧， v5.26 版直接内置 sock5 实现
https://www.stunnel.org/config_windows.html

stunnel 是个很安全的软件，它有 linux windows openwrt 的客户端，用了 3 张自签证书，基于 pki 认证 1.pem 用于服务器端 verify 3 验证客户端身份， verify 2 用于客户端验证服务器端加密用证书。所以它是个很安全的防止中间人攻击的方案。又是 linode ，看论坛的反应， linode 还不如搬瓦工。。。搬瓦工的掉包率 1%不到。

client = yes
;compression = zlib

socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:60
socket = r:SO_OOBINLINE=no
;socket = a:SO_REUSEADDR=yes
TIMEOUTconnect = 10

RNDbytes = 1024
RNDfile = r:/rnd.txt
RNDoverwrite = yes
debug = 6

sslVersion = all
;options = NO_TLSv1.2
options = NO_TLSv1.1
options = NO_TLSv1
options = NO_SSLv3
options = NO_SSLv2

;ciphers = ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384
;ciphers = ECDHE-RSA-AES256-GCM-SHA384
;ciphers = ECDHE-RSA-AES128-GCM-SHA256

cert = 1.pem
verify=2
CAfile = stunnel.pem
checkHost = XXX.XXX.XXX.XXX


[server1]
accept = 127.0.0.1:1081
connect = XXX.XXX.XXX.XXX:1723