前言 为了解决日益增长的计算、存储、测试环境的需求，结合我们办公室小机房优异的散热、电量、网络条件(详情如下)，因此在2021年3月份决定将公司的13台Dell R720服务器搬迁到机房进行托管，以期获得稳定的使用条件。 散热：开了16度然而还能热出汗的空调 供电：物业预期下午5点断电早上11点先进行预演，时不时跳一下闸什么的 机房布线管理：网线乱飞、电源线乱飞、随时踩一脚断电or断网 潘多拉的域名玩法：电信专线并不封堵TCP/443，当年（2017）使用TCP/443并配合DNS-01 challenge验证域名所有权，然后使用Let's Encrypt来签发证书，最终提供给测试环境HTTPS证书，并且在公网环境提供免备案的服务 极其漫长的踩坑之路 从过年后3月初决定要搞事，开始采购新机器到最终上架“萝岗加速器”机房的时间是5月7号，整整跨了两个月。 硬件玄学 二手硬件不稳定什么的，对于我们这种垃圾佬当然不是什么问题啦！插电，开机~~~ 服务器采购（花费一周） 购买6台新的Dell R720 XD 2U服务器，每台机器配置 CPU： E5 2650V2 * 2 H710P mini 硬盘阵列卡 内存：8GB/16GB * 16 = 144GB/288GB 迁移原有服务器(Dell R420)内硬盘到新的机器 顺利的：基本能够直接开机，只要硬件自检通过，然后重新配置阵列卡，开机完成硬件升级 失败的：硬盘阵列卡故障、硬盘背板失败不通电、内存没装好….. PVE集群之坑 从已有用于测试环境的3台1U服务器，升级成4台2U的服务器（由于IP经过了变更，所以需要重新组件集群而不是使用现有的集群） 旧的集群：2台1U服务器原本已经安装了PVE并且有虚拟机提供测试环境数据，正在服役 新的集群：2台新机器直接安装PVE操作系统，组建集群 集群管理的坑 对pve集群node节点管理不熟悉 官方文档是最好的解决方案 对pve虚拟机磁盘管理不熟悉导致的坑 误删两个虚拟机硬盘，直接导致测试环境需要重建 remove/purge的时候要认真阅读警告信息。。。 域名备案问题 这是个迷之问题，只有在神奇的东方才有这种需求，这个过程花了一些时间去了解政策，才算是明确了再次备案不影响原先接入备案的问题。 遵循接入方备案原则：同一个域名，接入阿里云需要做一次备案，接入另外一家服务商需要再做一次备案。 当年绕过电信专线不封堵TCP/443用来提供HTTPS，然后间接提供相对标准（只使用80/443端口）的公网HTTP服务的方案，在经过了几年的发展，积累了一大批域名，还好基本都是属于同一个顶级域名的二级、三级域名，没造成太大的修改难题 文网文问题 这是一个更迷的问题，同样只存在于大局域网国家，多次申诉、联系客服折腾无果，只能按照某福报厂要求对网站内容进行大幅度修改，去掉游戏相关字眼（只要网站内容有游戏，必须要求文网文证件）的内容。 一个国家有关部门已经不签发的证书，却在审核备案的的初审部分需要审核，投诉无门，喝喝 网络架构调整 原网络拓扑：公司和服务器之间是局域网(192.168.0.0/21），服务器局域网连接是通过连接同一个交换机并uplink到公司主路由来实现访问的，几个提供对外访问的具有公网的服务器则是另外一个专线交换机连接 新网络拓扑：为了方便公司同事在开发的时候，直接使用局域网地址+端口号来访问测试服务，而不是一切访问都经过网关做端口转发 通过 SD-WAN 技术，使用P2P VPN软件Zerotier建立局域网 172.16.200.0/24 托管机房网关 Zerotier 网口 IP 172.16.200.1 配置防火墙允许流量 iptables -t raw -A INPUT -i zt+ -j ACCEPT 配置 NAT iptables -t nat -A POSTROUTING -o zt+ -j MASQUERADE 配置入站数据转发 iptables -A FORWARD -i zt+ -j ACCEPT 配置 Linux 内核开启 ipv4 转发，修改 /etc/sysctl.……

阅读全文

背景 局域网 Kubernetes 测试服务器的具有公网(1.2.3.4)、局域网(10.0.0.10)双网卡 日常需求较多需要从局域网内/公网环境通过域名访问测试服务器（同时还有部分正式环境的大数据服务） 旧方案 公网环境 DNS 配置gw.sukikaka.com A 1.2.3.4 局域网环境 DNS Server 10.0.0.1 配置劫持成 gw.sukikaka.com A 10.0.0.10 局域网环境通过 DHCP Server 配置 DHCP Options 6,10.0.0.1,223.5.5.5 来达到下发 DNS Server 的目的 而以前用内网DNS服务器添加劫持，将gw.sukikaka.com A 10.0.0.10从而解决解析的问题，但是其他测试环境域名通过CNAME将解析指向gw.sukikaka.com时，并不能将CNAME再次顺利解析到10.0.0.10 存在的问题 需要将DNS Server设置成内网指定的DNS Server 10.0.0.10，否则无法劫持 增减域名需要在公网DNS Server设置解析，也需要在局域网DNS Server设置解析 另外，由于公司不少同事是使用科学上网，而这些科学上网很难要求他们会自己将DNS Server设置成内网的Server，所以最终导致占用 Kubernetes 公网带宽，测试环境体验不好 访问测试环境的数据会经过主路由器 NAT 成 default route 的公网地址，然后再访问Kubernetes的公网地址NAT回来，然后处理完成之后再反向回来局域网内的请求客户端，ip packet 增加了多余的NAT 新方案 公网环境 DNS 配置gw.sukikaka.com A 1.2.3.4 局域网环境通过 DHCP Server(网关) 配置 DHCP Options 6,10.0.0.1,223.5.5.5 来达到下发 DNS Server的目的（此时内网DNS Server仅通过使用SmartDNS服务，用于优化DNS查询，不做测试环境解析记录劫持） 利用 DHCP Server 将 DHCP Options 121, 1.……

阅读全文

本文围绕端口讲解网络流量流向中可能出现的各种问题，水平有限，仅当入门篇。 访问端：怎么确认目标设备对应端口已经开启 常规方法： tcpping 端口open状态 telnet 端口可连接 其他tcp方案 本地端口没有被运营商or其他工具封锁，比如邮件的25端口 如果以上外部方案都发现并不能连接到目标端口，该那么怎么排查问题 SSH登录目标主机 假设我们想了解为什么80端口没连通，先确认80端口是否正在服务 sudo netstat -anp | grep :80 从结果可以看出主机已经开启了80端口，且服务的程序是Nginx 被访问端：如何确认有请求访问 以下假设访问端和被访问端使用公网访问。 ifconfig找出公网流量交换的网卡，比如下图我的是eth0 监听网卡eth0上的80端口的流量 sudo tcpdump -i eth0 port 80 开启监听 另外一台机器使用tcpping来访问tcpping 45.34.167.101 80 观察tcpdump结果 结果是连通的，可以清晰看到tcp3次握手的sequence code 接下来使用sudo service nginx stop关停nginx的80端口，然后再次做tcpping 端口已经关闭了，tcpdump依然可以看到类似上面的tcp握手请求 被访问端：怎么确认端口是可达的（未被封锁） 那么假设防火墙拦截对80端口的请求呢？我们使用iptables对INPUT的流量全部采取DROP处理 sudo iptables -A INPUT -p tcp --dport 80 -j DROP 访问端再次使用tcpping发起请求，可以在被访问端tcpdump看到请求，但无法成功建立tcp连接 访问端看到的请求结果 -> timeout，network packet只进不出，被DROP了 弄完之后我把iptables删掉啦，不然网站都开不动啦- -# sudo iptables -D INPUT -p tcp --dport 80 -j DROP……

阅读全文

大背景 说需求不讲背景就是耍流氓。 ———– by 一个被虐的码农 那么，背景是这样的，公司现有的测试业务情况如实交代： 局域网自建mongo数据库，用于业务的测试环境数据（IP：192.168.2.100，电信公网IP 200.201.202.203，标记为服务器A） 公网阿里云ECS(IP: 100.101.102.103，标记为服务器B），用于外网测试环境代码的运行，通过服务器A的公网IP来连接mongo数据库 阿里云DNS配置A解析记录 dev.xxx.com 100.101.102.103 在脱离公司的公网环境，需要能正常访问dev.xxx.com的服务 问题来了 运营人员抱怨各种测试服务反应很慢。噢？那么我们来研究下网络数据走向和对应的时间消耗咯 运营人员使用测试服务->DNS解析dev.xxx.com->请求服务器B->通过服务器A的公网IP连接到mongo数据库->上传数据回服务器B->返回数据给和服务器A同一个公网出口的App（哇，这链条长的很开心） 通过配置PHP fpm slowlog得知，发现实际上时间消耗都花在了mongo相关的连接上面了，为什么呢？？？ 分析问题 我们用的电信家用宽带，100M下载带宽，上传也就那么4M，完全不能看啊，稍微查询一个大一点的数据集，传输时间够喝一壶了，而且这么4M带宽，还要服务于公司员工正常的上网需求，那么降低这里的上传带宽使用也是很有必要的。 选定方案 so，找到问题了，光说有什么用，得有解决方案啊 把数据库也扔到外网去，那么对整个公司局域网来说，主要消耗只有对公网服务器B的请求下行数据，然而mongo对硬件消耗有点大，作为一个测试环境来讲，升级硬件配置或者再开一台服务器难免有点资源浪费，退而求其次，合理利用局域网服务器做mongo服务才是正路 服务器A硬件配置是强于ECS好多倍的，不要浪费了，那么就在服务器A上面搞事吧 通过分析上面的请求路径，那么我们可以把服务器A的公网上传拦截掉，怎么拦截呢？从DNS上面动手，于是请求路径会变成：APP->解析dev.xxx.com->请求服务器A（192.168.2.100）->服务器A的程序请求localhost的数据库->返回数据给程序->返回给同一个局域网的运营测试人员 这样一来，速度提升的有点可怕，运营人员再也不腰痛了 解决问题 既然有初步方案了，那么怎么解决？ 那么需要使用“提速”的运营人员，可以通过配置HOST来实现 dev.xxx.com 解析成 192.168.2.100，如果只有PC平台的产品，倒也不失为一种选择 移动设备怎么办？Android不root，iOS不root没法玩啊，除非这些测试机器允许以某种方式“模拟配置host”，比如Android读取sd卡某个文件，若定义了解析数据，则以解析结果为准，需要预埋代码，改起来也麻烦，一点也不优雅 移动设备实在没办法改呢？那我配置代理咯，代理设备请求到能改HOST的PC设备，也是麻烦 既然这么蛋疼，那我配置一个DNS服务器好了，一番搜索之后，unbound这个软件上场了，配置一个DNS服务器，使用标准端口53，将局域网所有需要”提速“的设备首选DNS改成192.168.2.100即可 本着优化应该对使用者透明的原则，把上面这个配置DNS的步骤也省了，直接用DHCP服务器返回192.168.2.100作为首选DNS 断一下网，重新连接，刷新页面，一切只如初见，那么美好~ 题外话 有人说，为了性价比，透明解决问题，为何不把所有服务都放在局域网的服务器A上面，连买ECS的钱都省了。。。 骚年，你还是太年轻 电信运营商怎能允许家用宽带用来做服务器提供服务这种行为，那么谁购买他高贵的企业专线带宽呢？于是我们家用宽带的80端口、8080端口默认都是被封了。 就算运营商不搞事，国家要求所有IDC必须只对有域名备案信息的域名才能提供正常的服务，就算配置了解析，在访问到具体的IP的时候，也是一样不能正常访问你的业务，从这个角度来讲，电信运营商封锁这两个端口也算是为了规避备案问题。 改端口也不是不行，然而综合考虑，改端口方案导致各个业务都需要做额外的配置修改，还是买个ECS做外网测试业务简单粗暴 那么其实除了上面的DNS方案，还有没有其他方案？答案是有的，理论上通过配置路由表SNAT，把对服务器B（100.101.102.103）的流量请求转发到服务器A192.168.2.100，然而该方案似乎有点一刀切，不够灵活，还是留着DNS，需要这种访问链路优化的话，配置首选DNS服务器为192.168.2.100，不需要的时候或者想强行访问服务器B的逻辑，那么只需要配置其他公用DNS即可。 UPDATE 2017-09-05 由于在实际使用过程中（大概1个多月的持续时长），发现对于不甚了解原理的小伙伴来讲，有额外的理解成本，业务也准备上HTTPS访问，那么就又来搞事吧，于是改为下面的方式： 仅保留局域网服务器A，全部使用Let’s Encrypt部署HTTPS访问（电信没封443端口），局域网访问可以使用HTTP或者HTTPS，而公网访问就只有HTTPS能通啦- - unbound DNS配置依然保留 路由表在另外一个服务器上面，暂时未变动 ……

阅读全文