/tags/%E5%B1%80%E5%9F%9F%E7%BD%91/Recent content in 局域网 on Colinx BlogHugo -- gohugo.ioen-usSat, 08 Feb 2020 00:00:00 +0000/posts/%E4%BB%8E%E4%B8%80%E6%AC%A1%E5%BC%82%E5%B8%B8%E6%96%AD%E7%BD%91%E8%B0%88%E9%98%B2%E7%81%AB%E5%A2%99%E9%85%8D%E7%BD%AE/Sat, 08 Feb 2020 00:00:00 +0000/posts/%E4%BB%8E%E4%B8%80%E6%AC%A1%E5%BC%82%E5%B8%B8%E6%96%AD%E7%BD%91%E8%B0%88%E9%98%B2%E7%81%AB%E5%A2%99%E9%85%8D%E7%BD%AE/ <h2 id="序"> 序 <a href="#%e5%ba%8f" class="h-anchor" aria-hidden="true">#</a> </h2> <p>十分钟前，突然发现手边的电脑上的 QQ 突然变灰，多次重新登陆均失败。而当前打开几个百度的网页均未出现异常。但点击几个搜索结果均显示打不开网页。一分钟后，iPad 播放的音乐也突然停止。尝试 Ping 局域网的网关和树莓派均失败。而路由器仍然显示网络连接正常，手机端仍可以正常上网，断网前半个小时内我是没有对路由器和承载着众多服务的树莓派进行任何改动的。初步查看，发现电脑网卡的 ip 变为<code>169.254</code>开头的 IP，而内网 IP 之前一直用的是<code>192.168.1.\*</code>。现在电脑和路由器<code>192.168.1.1</code>以及绑定了这个网段静态 IP 的树莓派都不在同一个网段内，自然是无法访问的。那么为什么会分配到这样的 IP 地址呢？<br> 简单查询得知，这样的 IP 属于保留的 IP 地址段，用于在无法 DHCP 获取 IP 时自己给自己分配一个 IP。这样分配得来的 IP 自然是不能正常使用的。而此前局域网的 DHCP 被我的树莓派承包了，那么首要任务是查看树莓派的 DHCP 服务是否正常运行。</p> <h2 id="排错三步走"> 排错三步走 <a href="#%e6%8e%92%e9%94%99%e4%b8%89%e6%ad%a5%e8%b5%b0" class="h-anchor" aria-hidden="true">#</a> </h2> <p>虽然树莓派之前绑定的 IP 地址无法 ping 通，但庆幸的是，通过主机名依然可以访问到局域网内树莓派，不过此时链接的是 IPv6。IPv6 作为 IPv4 的升级版，在很多方面都有所不同，局域网 IP 地址的分配和 IPv4 的 DHCP 走的并不是同一个路子。之前为了将树莓派的 DNS 用于家庭局域网，而家里的移动光猫上并不能修改 IPv4 DHCP 的 DNS 信息，无奈只能禁用路由器的 IPv4 DHCP 转而使用 AdGuardHome 内置的 DHCP 服务器。而 IPv6 的 DHCP 分为两个部分：</p> <ol> <li>内网的，分配的 IPv6 地址一般以<code>fe80</code>开头，这种地址仅用于内网访问。</li> <li>公网的，IPv6 的地址容量之大足以为地球上的每一粒沙子分配一个独一无二的 IPv6 地址，而这对于现今地址池即将枯竭的 IPv4 是根本无法想象的。</li> </ol> <p>由于要分配的公网 IPv6 地址是要由路由器从公网获取一个前缀然后再为局域网的每个支持 IPv6 的设备分配地址，这一项任务不能由内网的树莓派代劳，所以当时就没有改动，没想到现在竟然成了救命稻草。<br> 通过 IPv6 的方式，成功连接上了树莓派。查看了 AdGuardHome 的 DNS 服务以及 DHCP 服务，并没有发现任何异常。<br> 例行 SSH 连上查看日志。<code>sudo systemctl status AdGuardHome.service</code>，果然，发现了端倪。<br> <img src="https://blog-1301127393.file.myqcloud.com/BlogImgs/20200121221431.png" alt=""><br> 原来！DHCP 服务！是要单独监听 67 端口的！<br> 而一个小时之前，为了防止暴露在公网上的树莓派遭到攻击，我特地启用了防火墙，并设置规则为，除了放行的 DNS 53 等端口，其他默认屏蔽。想来应该是误伤了 DHCP 的 67 端口。而之前 DHCP 设置每个 IP 地址的租约为一个小时，即，每间隔一个小时才会重新进行一次 DHCP 请求。于是<code>sudo ufw allow 67/tcp</code>端口放行 DHCP 服务信息。win10 断网重连以令其重新获取 IP 地址。<br> 没想到还是不成功。AdGuardHome 的 DHCP 租约面板，依然显示没有任何设备连接。依据以往的经验，乖乖去查了 DHCP 所使用的端口信息，发现 DHCP 需要<code>67/udp</code>和<code>68/udp</code>两个端口，且还是使用 udp 连接。<br> 接下来问题就好办了，重复上面的操作。查看本机的 IP 地址已经恢复正常。</p> <h2 id="谈防火墙"> 谈防火墙 <a href="#%e8%b0%88%e9%98%b2%e7%81%ab%e5%a2%99" class="h-anchor" aria-hidden="true">#</a> </h2> <p>在树莓派未暴露在公网上之前，我对防火墙的理解仅限于早些年 360 卫士花里胡哨的网络安全服务。在这次事件之前，我也只是以为防火墙只是防范来自公网的不友善的访问的工具。今天才发现，防火墙除了字面上的意思，防范风险之外，他也是网络数据进出主机的安检。什么样的请求是允许的，什么样的是屏蔽的，这些都需要认真考虑，仔细配置。对于我那配置了众多服务的树莓派来说，我应当在没添加一个新的服务时，查询其使用的端口信息，并更新防火墙配置，我之前却大大忽视了这一点，直到出了事故才意识到。也希望给后来者提供一个减少犯错的机会，毕竟要是实际生产环境出了事故，可就不是十几分钟断网的事了。</p> <h2 id="防火墙设置"> 防火墙设置 <a href="#%e9%98%b2%e7%81%ab%e5%a2%99%e8%ae%be%e7%bd%ae" class="h-anchor" aria-hidden="true">#</a> </h2> <p>防火墙抵挡了来自外部的威胁，也会对现有的服务造成影响。除了网页访问的 80 和 443 端口，其他有固定端口的特定服务要手动在防火墙中添加规则。对于像 BT 下载这种没有固定端口的，需要根据实际设定来更新防火墙规则。<br> <img src="https://blog-1301127393.file.myqcloud.com/BlogImgs/20200122140951.png" alt=""><br> 图中为 Aria2 的默认监听端口，为了保证正常的 BT 下载，需要保证这个范围的端口也添加进防火墙允许通过的规则。<br> 最简单有效的办法是，将所有出站的请求默认允许，对于外部传入的请求，除了必要的几个服务，其他一概默认禁止。</p> <pre tabindex="0"><code>sudo ufw default allow outgoing sudo ufw default deny incoming </code></pre><p>这样设置可以保证我们能够正常访问互联网上的绝大多数服务，且阻挡大部分外部的攻击。不过这种情况下，如果你的系统被植入了后门，那么这台机器依然可以向外发送请求。如之前爆发的“永恒之蓝”，如果你的机器被感染了，那么他依然可以经由特定的端口，向外传送数据，从而感染局域网中的其他设备。防火墙的规则就要根据实际的情况来进行设置了。</p>