背景
一同事在研究他的安全大业, 需要在 AWS 服务器上部署他的秘密武器, 秘密武器通过 Docker 来部署; 在部署前可以通过跳板机的内外网 SSH 登录上这台服务器; 部署后只能通过外网 SSH 登录这台服务器.......; 症状就是这么个症状, 怎么下药就得看医术了.....
排查心里路程
1, 部署秘密武器之前, 可以内外网; 部署后, 只能外网, 看这么个症状就是网络防火墙问题, 于是乎~~~
- )iptables -F
- )setenforce 0
3) 在 AWS 上把此服务器的安全组入站 0.0.0.0(这纯粹是为了测试, 正式环境千万别~~~)
2, 这 SSH 不通难道是 SSH 的配置文件修改了, 因为改了端口, 难道 SSH 的配置文件里有控制内外网是否可以登录的配置? 于是乎~~~
VIM /etc/SSH/sshd_config 一顿瞎改 (这里就体现了对 SSH 的认识不足, 对配置文件不熟悉, 得学习)
3, 这什么玩意儿, 网络是可以的, 安全组没问题, 不知为什么脑袋里面想到了路由, route -n 先看看, 哇~~ 噢, 这么多条路由, 看到这些路由的时候, 其中有一条 172.29.0.0(我们跳板机的网段跟这个很像), 就隐隐约约觉得这里有问题 (女人的直觉不只在判断男朋友是否在外面有狗, 还爱不爱上; 在这里直觉也还是挺准, 哈哈); 于是乎~~~
- route -n
- route del -net 172.22.32.0 netmask 255.255.255.0
- route del -net 172.23.32.0 netmask 255.255.255.0
- ......
只要是与容器有关的路由全部干掉, 然后再从跳板机去内网 SSH 登录, 哇~~~ 哇~~~ 可以了耶, 好激动好激动噢~~~~
4, 确定了, 就是那一条路由的问题, 这个容器分配的网段与跳板机的网段冲突了, 于是乎~~~~
- route add -net 172.22.32.0 netmask 255.255.255.0
- ......
把刚刚删了的路由除了那一条冲突的, 又傻不拉几的加上, 接下来就是解决这个问题的时候了
当时的解决办法
想了想, 既然冲突了, 那我肯定就是把这个容器的网段给改了, 怎么改呢, 用了一个及其愚蠢的办法, 我把这个容器停掉删除, 重新用 docker-compose 重启启动了一个, 就重新分配了一个新的网段, 就不冲突了.
根本解决办法
在启动容器之前就把整个 docker 的网络改为与我们自己的网段不冲突的, 这样 docker 永远只分配我们给他设置的
操作步骤: 修改 docker.JSON, 使得整个 docker 的网络网段都改掉, 原来是 172 网段, 现在我要改为 192
- 1)VIM /etc/docker/daemon.JSON(这里没有这个文件的话, 自行创建)
- {
- "bip":"192.168.0.1/24"
- }
2) 重启 docker
systemctl restart docker
3) 在重新看网段
注: 在使用 docker 容器最初规划的时候就要想到这一点, 要规划好使用什么样的网段; 上面的这种办法得重启 docker, 重启容器的;
疑问
还没有其他更好的办法呢, 在不停止容器不删除容器的前提下, 修改网段?(待我研究好了, 再来补充)
总结
1: 对 SSH 的配置文件不熟悉 (这个得找个时间系统的过一遍)
2: 对网络这块熟悉, 尤其是路由这些, 说实在的, 到现在还是说不出路由的具体作用, 只可意会的那种, 只知道没他不行 (等这段时间把 PMP 考完了, 开始看思科那几本书, 不说考证, 先把那几本书好好看看, 加强网络)
3: 对 Docker 网络模式不熟悉 (接下来这段时间好好看 Dokcer 网络部分的官方文档)
下次再见~~~
来源: https://www.cnblogs.com/lemon-le/p/10515069.html