未分类 – 滴水技术日志

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地图定位也显示在美国。测试了一下速度，能跑满带宽，主机应该在日本没错。

sublime使用小贴士

sublime是一款非常好用的编辑器，插件生态链非常丰富，要收费，但是不注册貌似也可以一直正常使用。

常用插件：

packagecontrol 插件安装管理必备

常用快捷方式：ctrl+shift+p 打开管理命令行

Preety JSON 格式化JSON数据

常用快捷方式： ctrl+alt+j 格式化JSON数据

解决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%’;

检查是否如下：

特别说明下：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/