diff --git a/.vitepress/theme/locations.ts b/.vitepress/theme/locations.ts index 3d7f560..cf4bb82 100644 --- a/.vitepress/theme/locations.ts +++ b/.vitepress/theme/locations.ts @@ -3,8 +3,9 @@ const CITY = { }; const DISTRICT = { - 渔业社区: "宝安区西乡街道渔业社区", + 大冲社区: "南山区粤海街道大冲社区", 高新区社区: "南山区粤海街道高新区社区", + 渔业社区: "宝安区西乡街道渔业社区", }; const LOCATIONS = { @@ -15,6 +16,10 @@ const LOCATIONS = { 创维半导体设计大厦西座: { city: CITY.深圳, district: DISTRICT.高新区社区, + }, + 大冲新城花园: { + city: CITY.深圳, + district: DISTRICT.大冲社区, } }; diff --git a/posts/better-not-mess-around-with-iptables/README.md b/posts/better-not-mess-around-with-iptables/README.md new file mode 100644 index 0000000..c60b45c --- /dev/null +++ b/posts/better-not-mess-around-with-iptables/README.md @@ -0,0 +1,121 @@ +--- +date: 2019-12-15 +spot: 大冲新城花园 +sort: Computer Science +tags: + - Network + - iptables + - NAT + - TCP + - MySQL + - Unix domain socket + - man page +--- + +# 慎用 iptables：误用规则引发的疑问 + +![BCY0349 Masquerade](./bcy0349.jpg "Permitted under the [Terms and conditions](https://www.dfo-mpo.gc.ca/terms-conditions-avis-eng.htm). ©️ [**Contributors**](https://www.dfo-mpo.gc.ca/species-especes/mammals-mammiferes/humpback-rorqual-a-bosse/photos/index-eng.html) on [*dfo-mpo.gc.ca*](https://www.dfo-mpo.gc.ca/species-especes/mammals-mammiferes/humpback-rorqual-a-bosse/photos/bcy-eng.html).") + +昨天去了一趟广州。在深圳安检排队时微信突然来了一串消息： + +> 有个 Web 服务突然被数据库拒绝访问。 + +事态比较紧急，我们组长先做了临时处理，之后通知了我们几个相关的人。由于我前阵子接手了这个项目，所以也就承担调查事故原因的任务。 + +## 背景 + +这里涉及一些业务层面的东西，需要脱敏，所以只提取出涉事技术因素： + +- Web 服务（下文以 `IDLE` 代称）：一个重要而不繁忙的内部网站，只有工作时间会有人使用。 +- 数据库（下文以 `DB` 代称）：一个重要且繁忙的数据库，`IDLE` 会对 `DB` 进行只读操作。 +- 另一个 Web 服务（下文以 `BUSY` 代称）：持续对 `DB` 进行高频读写操作。 +- `IDLE` 和 `BUSY` 位于同一个 Linux 服务器。 + +### 具体故障 + +`IDLE` 被 `DB` 拒绝访问。 + +在这之前，`IDLE` 对 `DB` 的访问是完全正常的。作为当前唯一的维护人员，我上周根本就没有对它做任何变更，出了这个故障实属让我摸不着头脑。 + +### 初步调查及临时措施 + +组长做了初步调查及临时措施，并提出疑问： + +- Web 服务报错：`sqlMessage: "Host 'IP.IP.IP.IP' is not allowed to connect to this MySQL server"` +- 临时措施： + - `GRANT ALL PRIVILEGES ON *.* TO 'USER'@'IP.IP.IP.IP';` + - 对 `DB` 做了此变更之后 `IDLE` 恢复正常 +- 疑问： + > 1. MySQL 拒绝 `IDLE` 访问，为什么昨天没有出现，而今天早晨出现了？周五晚上有人修改了 MySQL 配置吗？ + > 2. `IDLE` 服务连接数据库的配置中，`host = "localhost"`，为什么 MySQL 的报错会是 `"IP.IP.IP.IP"`？ + +### 可能相关的运维变更 + +对于疑问 `1`，我并没有对服务器或服务做任何变更，所以应该是其他人做了相关操作。有位同事补充了周五晚上他对服务器做的变更，出于运维需要，给 iptables 加了如下规则： + +```sh +sudo iptables -t nat -A POSTROUTING -j MASQUERADE +``` + +之后，又使用 `iptables-restore` 将变更前备份的 iptables 规则表重新导入。 + +### 我的疑问 + +得到以上信息之后，我也产生了新的疑问：为什么在同一台服务器上面，且使用同样配置连接 `DB` 的 `BUSY` 服务不受影响？ + +## 调查 + +同事对服务器 iptables 做了相关的配置，而刚好出了故障，从直觉上来说这两件事有关联的概率很大。但由于后续用 `iptables-restore` 导入了原来的配置，所以这个因素暂时就先搁置了。 + +对于疑问 `2`，按照正常情况，如果客户端使用 `localhost` 连接 `DB`，那么客户端自身的地址也会是 `localhost` [[1]]，现在却变成 `IP.IP.IP.IP`，导致被 `DB` 拒绝连接。 + +会是 `localhost` 指向有问题吗？ + +```sh +$ ping localhost +PING localhost (127.0.0.1) 56(84) bytes of data. +64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.026 ms +64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.024 ms +... +``` + +显然，`localhost` 正常。 + +### MySQL client 的连接方式 + +如果用 `mysql` 的命令行客户端登录呢？也正常： + +```sh +$ mysql -uUSER -p +Enter password: +Welcome to the MySQL monitor. Commands end with ; or \g +... +``` + +之后跟朋友 `@Shady` 吐槽了这个现象，他告诉我在 Linux 上 `mysql` 命令行客户端默认使用 Unix domain socket [[2]] 而不是 TCP 协议。这个信息很重要： + +```sh +$ mysql -uUSER -h 127.0.0.1 -p --protocol=TCP +Enter password: +ERROR 1130 (HY000): Host 'IP.IP.IP.IP' is not allowed to connect to this MySQL server +``` + +可以看到，只要是通过 TCP 协议通过 `localhost` (`127.0.0.1`) 连接 `DB`，就会有问题。 + +>>>>> progress + +--- + +:::details 封面图 + +::: + +## References + +1. [What is the source IP address when we ping 127.0.0.1?][1]. *forum.networklessons.com*. +2. [4.3.3 Connecting using Unix Sockets and Windows Named Pipes][2]. *dev.mysql.com*. +3. [Linux man pages][20]. *man7.org*. + +[1]: +[2]: +[20]: diff --git a/posts/better-not-mess-around-with-iptables/bcy0349.jpg b/posts/better-not-mess-around-with-iptables/bcy0349.jpg new file mode 100644 index 0000000..0701bbd Binary files /dev/null and b/posts/better-not-mess-around-with-iptables/bcy0349.jpg differ