Vultr主机更换IP

今天下午Vultr日本机房大量IP被GFW收录,由于以前日本节点也经常抽风,开始没在意,过了很久还没恢复,于是查看哪儿丢包了:

tracert wujc.cn

 1     1 ms    <1 毫秒   <1 毫秒 192.168.1.1
 2     5 ms     5 ms     6 ms  111.0.200.1
 3     6 ms     6 ms     6 ms  111.0.94.177
 4     7 ms     *        7 ms  211.138.119.153
 5     6 ms     5 ms     6 ms  221.183.13.233
 6     9 ms     9 ms     9 ms  221.183.10.5
 7    23 ms    22 ms    22 ms  221.183.23.26
 8     *        *        *     请求超时。
 9     *        *        *     请求超时。
10     *        *        *     请求超时。
11     *        *        *     请求超时。
12     *        *        *     请求超时。
13     *        *       58 ms  203.131.254.1
14    76 ms    53 ms    51 ms  203.131.254.1
15    95 ms    96 ms    96 ms  ae-3.r01.tkokhk01.hk.bb.gin.ntt.net [129.250.5.162]
16    50 ms    46 ms    46 ms  ae-3.r24.tkokhk01.hk.bb.gin.ntt.net [129.250.4.21]
17   100 ms    97 ms   100 ms  ae-18.r30.tokyjp05.jp.bb.gin.ntt.net [129.250.2.96]
18   106 ms    96 ms    94 ms  ae-5.r02.tokyjp03.jp.bb.gin.ntt.net [129.250.3.251]
19   106 ms   126 ms   106 ms  ae-0.choopa.tokyjp03.jp.bb.gin.ntt.net [117.103.177.122]
20   130 ms   118 ms   117 ms  vl526-ds1-j2-r237.tyo2.choopa.net [45.76.201.82]
21     *        *        *     请求超时。
22     *        *        *     请求超时。
23     *        *        *     请求超时。
24     *        *        *     请求超时。
25     *        *        *     请求超时。
26     *        *        *     请求超时。
27     *        *        *     请求超时。
28     *        *        *     请求超时。
29     *        *        *     请求超时。
30     *        *        *     请求超时。

初看丢包发生在日本,于是给Vultr提了一个ticket咨询,答复是他们收到很多类似的反馈,这个是ISP的问题,他们没办法处理,建议我更换一个服务器IP。但tracert的结果明明是日本丢包的,看起来很像是vultr把包扔了,随便找个日本的vultr IP再跟踪路由看看:

1     1 ms    <1 毫秒   <1 毫秒 192.168.1.1
  2    21 ms     6 ms     6 ms  111.0.200.1
  3     6 ms     8 ms     5 ms  111.0.94.173
  4     5 ms     4 ms     5 ms  211.138.127.25
  5     6 ms    18 ms     8 ms  221.183.14.93
  6    88 ms    33 ms    33 ms  221.176.15.253
  7    32 ms     *        *     221.176.16.214
  8     *        *       28 ms  221.183.25.202
  9    35 ms    36 ms    37 ms  221.183.55.113
 10    54 ms    61 ms     *     223.120.22.22
 11    67 ms    68 ms     *     223.120.2.13
 12     *        *        *     请求超时。
 13    61 ms    55 ms    64 ms  203.131.254.1
 14   129 ms   115 ms   124 ms  ae-7.r00.tkokhk01.hk.bb.gin.ntt.net [129.250.5.142]
 15    72 ms    70 ms    62 ms  ae-2.r24.tkokhk01.hk.bb.gin.ntt.net [129.250.2.126]
 16     *        *      133 ms  ae-18.r30.tokyjp05.jp.bb.gin.ntt.net [129.250.2.96]
 17   114 ms   109 ms   111 ms  ae-5.r02.tokyjp03.jp.bb.gin.ntt.net [129.250.3.251]
 18     *      128 ms     *     ae-0.choopa.tokyjp03.jp.bb.gin.ntt.net [117.103.177.122]
 19   140 ms   143 ms   140 ms  vl508-ds1-b5-2407.tyo1.choopa.net [45.32.30.94]
 20     *        *        *     请求超时。
 21   119 ms   117 ms   117 ms  45.77.132.235.vultr.com [45.77.132.235]

换个IP就一切正常了,看来日本NTT的网络应该没问题,从控制台登录到服务器,检查回国的路由,仍然是在ntt过了后就丢包了,有点怀疑服务器IP被vultr拉黑了,于是又继续询问他们是否把我的服务器IP拉入了黑名单啥的,很快回复说他们不存在黑名单,不会封自己的IP。

后来才知道,GFW现在封IP没以前那么简单粗暴了,以前是直接封掉出去的数据包,在国内出口时就直接把包扔了,现在弄了一层遮羞布,出去的包放行,回来的包拦掉。

这样看起来好像国内的网络都正常的,国外的网络有问题导致网络不可达,把锅甩出去了。

接下来只能更换vultr的主机IP了,先给要更换IP的主机创建一个Snapshot,大概耗时半小时左右,然后Destroy掉主机,销毁前建议找个地方记录一下该主机的root密码,因为从Snapshot恢复后,root密码再也找不回来了,显示Unknown, set in snapshot.只能很麻烦的重置密码。主机也可以先不Destroy,等新的主机正常运行后再删掉老的主机。Deploy new server ->  Server Type -> Snapshot,选择刚刚创建的快照,十来分钟后,服务恢复完成,IP更换成功,检查新IP是否被墙,如果新IP被墙了,继续销毁后新建,直到分配到可用的IP。每次更换IP只需要0.01刀,还是很划算的,只是耗时有点长,能否分到可用的IP还得看运气,因为vultr的日本机房支持支付宝付款后已经成了重灾区了,很多IP都被GFW盯上了。

查了下新分到的IP,地址竟然显示在美国,去whois.arin.net上查询,显示这个IP于2017-10-06被Reassigned到了日本,由于是刚漫游到日本的,因此绝大部分IP库都还显示这个IP在美国,Google地图定位也显示在美国。测试了一下速度,能跑满带宽,主机应该在日本没错。

 

解决OpenVPN “Waiting for TUN/TAP interface to come up”的问题

公司的VPN忽然连不上了,拨号成功后,OpenVPN 的日志中隔几秒就出现:

Route: Waiting for TUN/TAP interface to come up...

一段时间后直接出现失败的提示,虽然OpenVPN会变成绿色,并且鼠标移上去会显示出10开头的内网IP,但是其实是不能访问公司内网的,VPN并没有成功拨号。

在网上搜了一下,最终解决方案如下:

使用管理员权限打开cmd窗口,然后输入:

netsh winsock reset catalog
netsh int ipv4 reset reset.log

重启电脑即可解决。

 

让mysql支持emoji

emoji表情是通用的unicode字符串,不需要第三方工具支持,就可以显示丰富的表情图标,emoji表情由4个字节组成,mysql的utf8是3个字符,因此当emoji表情存入mysql数据库时会报错,通过一些设置可以让mysql支持emoji表情。

1.utf8mb4的最低mysql版本支持版本为5.5.3+,若不是,请升级到较新版本。
查看mysql版本的方法有:
在终端下:mysql -V
在mysql中:mysql> status;
使用mysql的函数:select version();
2.修改database、table和column字符集。参考以下语句:
ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE table_name CHANGE column_name VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
可以根据需要,在数据库层、表层或者字段层设置utf8mb4
3.修改mysql配置文件my.cnf(windows为my.ini)
my.cnf一般在etc/mysql/my.cnf位置。找到后请在以下三部分里添加如下内容:

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect=’SET NAMES utf8mb4′

修改参数后需要重启mysql,重启后,在mysql命令行中输入:SHOW VARIABLES WHERE Variable_name LIKE ‘character_set_%’ OR Variable_name LIKE ‘collation%’;

检查是否如下:

+————————–+——————–+
| Variable_name            | Value              |
+————————–+——————–+
| character_set_client    | utf8mb4            |
| character_set_connection | utf8mb4            |
| character_set_database  | utf8mb4            |
| character_set_filesystem | binary            |
| character_set_results    | utf8mb4            |
| character_set_server    | utf8mb4            |
| character_set_system    | utf8              |
| collation_connection    | utf8mb4_unicode_ci |
| collation_database      | utf8mb4_unicode_ci |
| collation_server        | utf8mb4_unicode_ci |
+————————–+——————–+
rows in set (0.00 sec)

特别说明下:collation_connection/collation_database/collation_server如果是utf8mb4_general_ci,没有关系。但必须保证character_set_client/character_set_connection/character_set_database/character_set_results/character_set_server为utf8mb4。

5.如果你用的是java服务器,升级或确保你的mysql connector版本高于5.1.13,否则仍然无法使用utf8mb4
mysql连接字符串可参考:jdbc:mysql://localhost/dbname?useUnicode=true&characterEncoding=utf8&autoReconnect=true&failOverReadOnly=false
6.如果不打算重启mysql数据库,可以在数据库连接池中设置,建立连接后执行
SET NAMES utf8mb4,如DruidDataSource:

<property name="connectionInitSqls">
  <list>
    <value>set names utf8mb4</value>
  </list>
</property>

使用Navicat等客户端,如果查询出来的数据是乱码,也可先执行SET NAMES utf8mb4,然后再进行查询。

阿里云上面的mysql数据库,可以参考阿里云的官方文档:https://help.aliyun.com/knowledge_detail/5990076.html
emoji的表情列表,可参考:http://getemoji.com/