说到查自己主机在公网上的IP,你的第一反应是用什么: ifconfig? curl ip.sb? 百度/谷歌我的ip?这些方法都对,也都不对。下面从我们一个实际开发的业务场景来逐步抽丝剥茧这个过程吧。
我们在使用云端数据库的时候,本地需要连接数据库进行开发管理。
默认情况下,从安全角度考虑,云端的数据库是禁止外网访问的。如果需要外网访问,可以通过设置IP白名单进行过滤。因此,我们可以将单位的出口IP添加到数据库连接的白名单中,这样开发同学在单位的网络环境下,就可以本地连接云端数据库了。
按照这个思路走,首先需要获取单位的出口IP是什么。用curl ip.gs得到出口IP是:IP_A, 然后将这个IP_A加入到了数据库访问的白名单中, 然后本地访问数据库,发现连接不上,te.NET 数据库的端口也显示无法连接。
连接不上,排查的思路有2个:
- 云端数据库的白名单机制有问题
- IP_A有问题
第一个排查思路,云端这个SaaS服务出问题的概率基本很小,而且比较难以从使用者的角度去直接证明。第二个排查思路,比较好处理,而且如果这个排查思路被证实/证伪,那么可以间接去证明第一个排查思路。
如果IP_A有问题,说明这个IP并不是真正连接数据库的IP,那么真正连接数据库的IP是否可以获得呢?答案是可以的:
- 先放开数据库连接白名单,也就是允许所有的外部连接都可访问该数据库。
- 本地连接数据库 MySQL -hRDS连接地址 -u账户 -p密码 -P3306
- 进入数据库查看进程信息:show processlist;
- 找到Info是show processlist的这一列,发现IP果然不是IP_A, 而是IP_B
然后把IP_B添加到数据库访问的白名单之后,就可以正常访问数据库了。
其实到这里,就会有个问题出现:
为什么我通过curl ip.gs 或者google查询我的IP显示的都是IP_A,而数据库连接后,显示我的IP是IP_B呢?
因为单位的网络是(合法地)支持科学上网的,会根据请求的目的地地址,自动判断走国内的网络还是走境外的代理。在获取IP_A的时候,其实请求的目的地地址都在境外,所以返回的公网IP自然也是境外代理的IP,也就是IP_A。如果用curl cip.cc 或者 bAIdu查询我的IP显示的就是IP_B,这个是走的国内的网络。
以上。