跳转至

network

  • 分类于 network
  • 需要 4 分钟阅读时间

TCP & UDP

TCP和UDP的区别？

对比如下：

UDP TCP
是否连接 无连接 面向连接
是否可靠 不可靠传输，不使用流量控制和拥塞控制 可靠传输，使用流量控制和拥塞控制
是否有序 无序 有序，消息在传输过程中可能会乱序，TCP 会重新排序
传输速度 快 慢
连接对象个数 支持一对一，一对多，多对一和多对多交互通信 只能是一对一通信
传输方式 面向报文 面向字节流
首部开销 首部开销小，仅8字节 首部最小20字节，最大60字节
适用场景 适用于实时应用（IP电话、视频会议、直播等） 适用于要求可靠传输的应用，例如文件传输

总结：

  • TCP 用于在传输层有必要实现可靠传输的情况，
  • UDP 用于对高速传输和实时性有较高要求的通信。
  • TCP 和 UDP 应该根据应用目的按需使用。
  • 注意虽然UDP传输时是无序的，但每个报文还是包含有报文序号，以便接收后排序

UDP 和 TCP 对应的应用场景是什么？

TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：

  • FTP文件传输
  • HTTP / HTTPS

UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：

  • 包总量较少的通信，如 DNS 、SNMP等
  • 视频、音频等多媒体通信
  • 广播通信

image-20210519180008296

TCP协议如何保证可靠性？

TCP主要提供了检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和 流量控制等方法实现了可靠性传输。

  • 检验和：通过检验和的方式，接收端可以检测出来数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
  • 序列号/确认应答： 序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。 TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
  • 滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。
  • 超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。
  • 拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
  • 流量控制：
  • 如果主机A 一直向主机B发送数据，不考虑主机B的接受能力，则可能导致主机B的接受缓冲区满了而无法再接受数据，从而会导致大量的数据丢包，引发重传机制。
  • 而在重传的过程中，若主机B的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。
  • 所以引入流量控制机制，主机B通过告诉主机A自己接收缓冲区的大小，来使主机A控制发送的数据量。流量控制与TCP协议报头中的窗口大小有关。

详细讲一下拥塞控制？

TCP 一共使用了四种算法来实现拥塞控制：

  • 慢开始(slow-start)：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
  • 拥塞避免(congestion avoidance)：
  • 拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。
  • 这样拥塞窗口按线性规律缓慢增长。
  • 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。当cwnd ssthresh时，改用拥塞避免算法。
  • 快重传(fast retransmit)：
  • 我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。
  • 比如接收方在收到一个失序的报文段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。
  • 快重传规定：发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。快重传
  • 快恢复(fast recovery)：主要是配合快重传。
  • 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞），但接下来并不执行慢开始算法，
  • 因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

详细介绍一下 TCP 的三次握手机制？

图片来自：https://juejin.cn/post/6844904005315854343

三次握手机制：

  • 第一次握手：
  • 客户端请求建立连接，向服务端发送一个同步报文（SYN=1），
  • 同时选择一个随机数 seq = x 作为初始序列号，
  • 并进入SYN_SENT状态，等待服务器确认。
  • 第二次握手：：
  • 服务端收到连接请求报文后，如果同意建立连接，则向客户端发送同步确认报文（SYN=1，ACK=1），
  • 确认号为 ack = x + 1，同时选择一个随机数 seq = y 作为初始序列号，
  • 此时服务器进入SYN_RECV状态。
  • 第三次握手：
  • 客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），
  • 确认号为 ack = y + 1，序列号为 seq = x + 1，
  • 客户端和服务器进入ESTABLISHED状态，完成三次握手。

理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

为什么需要三次握手，而不是两次？

主要有三个原因：

  1. 防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。

在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。

客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。

此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。

  1. 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。

第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；

第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。

  1. 告知对方自己的初始序号值，并确认收到对方的初始序号值。

TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

为什么要三次握手，而不是四次？

因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。

  • 第一次握手：服务端确认“自己收、客户端发”报文功能正常。
  • 第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
  • 第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信。

什么是 SYN洪泛攻击？如何防范？

SYN洪泛攻击属于 DOS 攻击的一种，它利用 TCP 协议缺陷，通过发送大量的半连接请求，耗费 CPU 和内存资源。

原理：

  • 在三次握手过程中，服务器发送 [SYN/ACK] 包（第二个包）之后、收到客户端的 [ACK] 包（第三个包）之前的 TCP 连接称为半连接（half-open connect），
  • 此时服务器处于 SYN_RECV（等待客户端响应）状态。如果接收到客户端的 [ACK]，则 TCP 连接成功，
  • 如果未接受到，则会不断重发请求直至成功。
  • SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址，向服务器不断地发送 [SYN] 包，服务器回复 [SYN/ACK] 包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时。
  • 这些伪造的 [SYN] 包将长时间占用未连接队列，影响了正常的 SYN，导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。

检测：当在服务器上看到大量的半连接状态时，特别是源 IP 地址是随机的，基本上可以断定这是一次 SYN 攻击。

防范：

  • 通过防火墙、路由器等过滤网关防护。
  • 通过加固 TCP/IP 协议栈防范，如增加最大半连接数，缩短超时时间。
  • SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改，专门用来防范 SYN 洪泛攻击的一种手段。

三次握手连接阶段，最后一次ACK包丢失，会发生什么？

服务端：

  • 第三次的ACK在网络中丢失，那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制，会等待3秒、6秒、12秒后重新发送SYN+ACK包，以便客户端重新发送ACK包。
  • 如果重发指定次数之后，仍然未收到 客户端的ACK应答，那么一段时间后，服务端自动关闭这个连接。

客户端：

客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

详细介绍一下 TCP 的四次挥手过程？

图片来源：https://juejin.im/post/5ddd1f30e51d4532c42c5abe

  • 第一次挥手：客户端向服务端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待服务端的确认。

  • 序列号 seq = u，即客户端上次发送的报文的最后一个字节的序号 + 1

  • 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1

  • 第二次挥手：服务端收到连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = k，确认号 ack = u + 1。

这时 TCP 连接处于半关闭状态，即客户端到服务端的连接已经释放了，但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了，但是服务端可能还要给客户端发送数据。

  • 第三次挥手：服务端向客户端发送连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待 A 的确认。

  • 序列号 seq = w，即服务端上次发送的报文的最后一个字节的序号 + 1。

  • 确认号 ack = u + 1，与第二次挥手相同，因为这段时间客户端没有发送数据

  • 第四次挥手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号 seq = u + 1，确认号为 ack = w + 1。

此时，客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放，必须经过 2*MSL（最长报文段寿命）的时间后，才进入 CLOSED 状态。而服务端只要收到客户端发出的确认，就立即进入 CLOSED 状态。可以看到，服务端结束 TCP 连接的时间要比客户端早一些。

为什么连接的时候是三次握手，关闭的时候却是四次握手？

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.

接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

主要有两个原因：

  1. 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。

第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK 报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。

MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。

如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。

  1. 防止已失效的连接请求报文段出现在之后的连接中。

TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

如果已经建立了连接，但是客户端出现故障了怎么办？

或者说，如果三次握手阶段、四次挥手阶段的包丢失了怎么办？如“服务端重发 FIN丢失”的问题。

简而言之，通过定时器 + 超时重试机制，尝试获取确认，直到最后会自动断开连接。

具体而言，TCP 设有一个保活计时器。服务器每收到一次客户端的数据，都会重新复位这个计时器，时间通常是设置为 2 小时。若 2 小时还没有收到客户端的任何数据，服务器就开始重试：每隔 75 分钟发送一个探测报文段，若一连发送 10 个探测报文后客户端依然没有回应，那么服务器就认为连接已经断开了。

TIME-WAIT 状态过多会产生什么后果？怎样处理？

从服务器来讲，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，严重消耗着服务器的资源，此时部分客户端就会显示连接不上。

从客户端来讲，客户端TIME_WAIT过多，就会导致端口资源被占用，因为端口就65536个，被占满就会导致无法创建新的连接。

解决办法：

  • 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，此套接字选项告诉内核，即使此端口正忙（处于 TIME_WAIT状态），也请继续并重用它。

  • 调整系统内核参数，修改/etc/sysctl.conf文件，即修改net.ipv4.tcp_tw_reuse 和 tcp_timestamps

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。
  • 强制关闭，发送 RST 包越过TIME_WAIT状态，直接进入CLOSED状态。

TIME_WAIT 是服务器端的状态?还是客户端的状态?

TIME_WAIT 是主动断开连接的一方会进入的状态，一般情况下，都是客户端所处的状态;服务器端一般设置不主动关闭连接。

TIME_WAIT 需要等待 2MSL，在大量短连接的情况下，TIME_WAIT会太多，这也会消耗很多系统资源。对于服务器来说，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求），由浏览器来主动断开连接，可以一定程度上减少服务器的这个问题。

阿里云秋招笔试题的一个选择题

现在有一个数据部分长度为8192B的数据需要通过UDP在以太网上传播，经过分片化为多个IP数据报片，这些片中的数据部分长度都有哪些?(假设按照最大长度分片)， 计网习题

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

无

  • 分类于 network
  • 需要 3 分钟阅读时间

VPN

VPN原理

vpn：英文全称是“Virtual Private Network”，翻译过来就是“虚拟专用网络”。vpn通常拿来做2个事情:

  • 一个是可以让世界上任意2台机器进入一个虚拟的局域网中（当然这个局域网的数据通讯是加密的，很安全，用起来和一个家庭局域网没有区别），
  • 一个是可以用来翻墙。

VPN与SS的区别

  • SS全称shadowsocks，SSR全称shadowsocks-R
  • VPN是为了保证通信的安全性、私密性，不是专门为“科学上网”制定的技术
  • 而SS/SSR则是为了转发客户端流量，绕过防火墙的检测，从而达到“科学上网”的真实意图，但是没有保证数据传输的安全性。
  • vpn比ss更加底层，它通过操作系统的接口直接虚拟出一张网卡，后续整个操作系统的网络通讯都将通过这张虚拟的网卡进行收发。
  • 这和任何一个代理的实现思路都差不多，应用层并不知道网卡是虚拟的，这样vpn虚拟网卡将以中间人的身份对数据进行加工，从而实现各种神奇的效果。具体来说，vpn是通过编写一套网卡驱动并注册到操作系统实现的虚拟网卡，这样数据只要经过网卡收发就可以进行拦截处理。

一句话，vpn在IP层工作，而ss在TCP层工作。

内网访问举例

  • 普通用户无法访问公司内网服务器
  • 开启VPN以后，如果他想打开公司ERP，他的电脑就不再直接连接公司ERP网站，而是去连接VPN服务器，并给VPN服务器发一条指令——“我要访问公司ERP”。
  • VPN服务器接到指令后，VPN服务器自己去访问公司ERP，收到公司ERP网页的内容，再把内容回传给员工，这样使用VPN的员工最终就能看到公司ERP网站的内容了。
  • 也就是说，使用VPN时，这个员工的所有网上访问都通过VPN服务器代理完成的。

IP packet 如何被传输

理解 VPN 路由（以及任何网络路由）配置的关键是认识到一个 IP packet 如何被传输，以下描述的是极度简化后的单向传输过程：

  1. 机器 A (192.168.0.2) 发送了一个目标地址为 172.29.1.4 的 IP packet.
  2. 根据本地路由规则，172.29.1.0/24 的下一跳是虚拟网卡 tun0, 由 VPN 客户端接管。
  3. VPN 客户端将这个 packet 的来源地址从 192.168.0.2 改为 10.8.0.123, 转发给 VPN 服务端。
  4. VPN 服务端收到 packet. 根据本地路由规则，172.29.1.0/24 的下一跳是默认网关 172.29.1.1.
  5. 默认网关找到在同一个局域网内的机器 B (172.29.1.4).

客户端 -> 内网

为什么机器 A 的本地路由表里会有 172.29.1.0/24 这个网段的路由规则？通常情况下，这是 OpenVPN 服务端推送给客户端，由客户端在建立 VPN 连接时自动添加的。也可以由服务端自定义，比如wireguard

内网 -> 客户端

这个时候，如果机器 B 想要回复 A（比如发个 ACK），就会出问题，因为 packet 的来源地址还是 10.8.0.123, 而 10.8.0.0/24 网段并不属于当前局域网，是 VPN 服务端私有的——机器 B 往 10.8.0.123 发送的 ACK 会在某个位置（比如默认网关）遇到 "host unreachable" 而被丢弃。对于机器 A 来说，表面现象可能是连接超时或 ping 不通。

解决方法是，在 packet 离开 VPN 服务端时，将其「伪装」成来自 172.29.0.3（举例VPN 服务端的局域网地址），这样机器 B 发送的 ACK 就能顺利回到 VPN 服务端，然后发给机器 A. 这就是所谓的 SNAT。

  • SNAT: Source Network Address Translation，是修改网络包源ip地址的。
  • DNAT: Destination Network Address Translation,是修改网络包目的ip地址的。

在 Linux 系统中由 iptables 来管理，具体命令是：

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE.

客户端 -> 另一个客户端的内网

连接 OpenVPN 的两个 client 之间可以互相通信，这是因为服务端推送的路由里包含了对应的网段。但是想从 Client A 到达 Client B 所在局域网的其他机器，还需要额外的配置。因为 OpenVPN 服务端缺少 Client B 局域网相关的路由规则。

# server.conf
push "route 172.29.0.0 255.255.0.0" # client -> Client B 给客户端推送 172.29.0.0/16 网段的路由(即这个网段的IP的信息都经过VPN)

route 172.29.0.0 255.255.0.0 #在 OpenVPN Server 上添加 172.29.0.0/16 网段的路由，具体下一跳是哪里，由 client-config 里的 iroute 指定

# 启用 client-config, 目录里的文件名对应 client.crt 的 Common Name
client-config-dir /etc/openvpn/ccd

# /etc/openvpn/ccd/client-b
iroute 172.29.0.0 255.255.0.0 # 告诉 OpenVPN Server, 172.29.0.0/16 的下一跳应该是 client-b (根据名字来)

内网与内网互访

在前两节所给的配置基础上，只需要再加一点配置，就能实现 OpenVPN 服务端所在局域网与客户端所在局域网的互访。配置内容是，在各自局域网的默认网关上添加路由，将对方局域网网段的下一跳设为 OpenVPN 服务端 / 客户端所在机器，同时用 iptables 配置相应的 SNAT 规则。

机场购买链接推荐

Based on the info in clashio, we select some cheap vpns to try.

name 每月价格(￥/GB/off on holiday) 每月单价(GB/￥) 每年单价(GB/￥) 节点数与稳定性 使用速度感觉
fastlink 2019 20/100/-30% 5 100+, 节点速度高达5Gbps 峰值 5Gbps (1)
totoro 2023 15/100/-20%(2) 6.6 ??? ???
冲浪猫 2022 16/200/-12%(3) 12.5 ??? 峰值 1Gbps
奈云机场 2021 10.6/168/-30%(4) 15.8 230624购买，240109几天全面掉线 峰值 5Gbps (6)
FatCat 2023 6/60/-20% 10 ??? 峰值 xx Gbps

detail info in table

  1. up to 6MB/s off-peak period
  2. 年付8折 + 优惠码8折 \(15*12*0.8*0.8=115.2\)
  3. 年付 150￥*0.88
  4. 年付+优惠码 128*0.7 = 89.6￥
  5. 年费+优惠码 128G每月，：46.99￥/128G or 76.36￥/256G。单价最低时间最短买法：256G,按季度买
  6. 新注册用户运行一周内测试5GB: up to 6MB/s in real download

My Choice: 单价，大小，速度，优惠码有效期

  1. 优惠码(春节 中秋 双十一)
  2. fastlink 用了两年了，还是x3很快的。但是相当于一个月只有30GB, 不够用。
  3. 奈云机场(可靠性暂时不行)，冲浪猫 平衡比较好。

现在组合：奈云机场(2) + fastlink。 等fastlink过期了(1)，看要不要转成 冲浪猫。

  1. 240624
  2. 241105 配置：复制订阅，订阅地址后面加 &flag=clash下载config.yaml
slow and expensive I had try

Nyacloud 喵云：只有10个节点 8￥/40GB/0.03Gbps or 17￥/128GB/0.2Gbps 平均 5GB/￥

BGP: Border Gateway Protocol

边界网关协议（Border Gateway Protocol，BGP）就是互联网的邮政服务。当有人把一封信投进邮筒时，邮政服务就会处理这封邮件，并选择一条快速、高效的路线将这封信投递给收件人。同样地，当有人通过互联网提交数据时，BGP 负责寻找数据能传播的所有可用路径，并选择最佳的路由，这通常意味着在自治系统之间跳跃。1

BGP不仅能够解决速度问题，还可以解决绕过线路故障:

IPLC: International Private Leased Circuit

中文翻译是国际私用出租线路，是指用户专用的跨国的数据、话音等综合信息业务的通信线路。通俗地说，也就是指传统的跨境专线。

延迟更低40ms、速度更快, 但是价格贵1 元 / GB。

Anycast

Anycast 是一种网络寻址和路由方法，可以将传入请求路由到各种不同的位置或“节点”。在 CDN 的上下文中，Anycast 通常会将传入的流量路由到距离最近并且能够有效处理请求的数据中心。选择性路由使 Anycast 网络能够应对高流量、网络拥塞和 DDoS 攻击。

SJF 稳定翻墙VPS

brook vpn+ Amazon American node

各种设备翻墙

教程

参考文献

OpenVPN 路由详解

  1. BGP 漫谈 ↩

  • 分类于 network
  • 需要 3 分钟阅读时间

Firewall

简介

防火墙是一种网络安全设备，主要是通过硬件和软件的作用于内部和外部网络的环境间产生一种保护的屏障，从而实现对计算机不安全网络因素的阻断。 * 所有流入流出的所有网络通信均要经过此防火墙。 * 功能 * 访问控制、隔离保护 * 组成 * 服务访问政策、验证工具、包过滤和应用网关

功能作用

  • 入侵检测功能
  • 主要有反端口扫描、检测拒绝服务工具、检测CGI/IIS服务器入侵、检测木马或者网络蠕虫攻击、检测缓冲区溢出攻击等功能，
  • 可以极大程度上减少网络威胁因素的入侵，有效阻挡大多数网络安全攻击。
  • 网络地址转换功能(NAT)
  • 分为源地址转换和目的地址转换，即SNAT和DNAT。可以由服务的发起者是谁来区分两者。
  • SNAT: 内部地址要访问公网上的服务时，内部地址会主动发起连接，将内部地址转换成公有ip
    • 修改源ip地址的目的一般都是为了让这个包能再回到自己这里，所以在iptables中，SNAT是在出口，也即POSTROUTING链发挥作用。
    • SNAT主要用于隐藏内部网络结构，避免受到来自外部网络的非法访问和恶意攻击，有效缓解地址空间的短缺问题，
  • DNAT：当内部需要对外提供服务时，外部发起主动连接公有ip的网关，路由器或着防火墙的网关接收到这个连接，然后把连接转换到内部，此过程是由带公有ip的网关代替内部服务来接收外部的连接，然后在内部做地址转换。
    • 修改目的ip地址的原因一般就是为了改变包发送的目的地，让包走出去，而不是留下来，所以在iptables中，DNAT是在入口，也即PREROUTING链中发挥作用，以便让包进入FORWARD表。
    • DNAT主要用于外网主机访问内网主机，以此避免内部网络被攻击。
    • DNAT与端口转发的区别在哪里？
  • 网络操作的审计监控功能
  • 对系统管理的所有操作以及安全信息进行记录，提供有关网络使用情况的统计数据，方便计算机网络管理以进行信息追踪。
  • 强化网络安全服务(类似GFW)
  • 集中化的安全管理，将安全系统装配在防火墙上，在信息访问的途径中就可以实现对网络信息安全的监管。

Linux实现原理

  • Linux系统内核中的安全框架Netfilter，为其他内核模块提供数据包过滤、网络地址转换（NAT）和负载均衡的功能。
  • 常用的iptables和firewalld服务都依赖于Netfilter来过滤数据包，两者自身并不具备防火墙的功能，只是创建并维护规则。
  • 不同之处在于iptables基于“过滤规则链”，firewalld基于zone区域。
  • iptables无守护进程，不能算作真正的服务，firewalld存在守护进程

三表五链 - 三表(应用规则)

  • filter 用于过滤，防火墙，过滤数据包
  • nat 用于网络地址转换、端口转发
  • mangle 用于拆解报文，作出修改，封装报文
  • raw表， 关闭nat表上启用的连接追踪机制，以提高性能。
  • 表规则应用优先级：raw>mangle>nat>filter
  • 每个表中能存在的链如下

三表五链 - 五链(数据包状态/ 过滤规则链)

  • PREROUTING 进入路由之前的数据包
  • INPUT 目的地址为本机的输入数据包
  • FORWARD 目的地址不为本机的包，可以实现转发(需要开启)
  • OUTPUT 源地址为本机的输出数据包
  • POSTROUTING 发送到网卡之前的数据包

Nftables

  • Allows configuration of tables, chains and rules provided by the Linux kernel firewall.
  • Nftables replaces iptables.
  • 解决的iptables的不足
    • 不同协议实现的代码重复
    • Nftables通过增强的通用集和映射基础结构，可以更快地进行数据包分类。
    • 解决语法不一致的问题，并提供更好，更紧凑的语法。
  • OpenWRT和ubuntu都使用Nftables

表

与iptables表的对应关系

nftables簇 iptables实用程序
ip iptables
ip6 ip6tables
inet iptables和ip6tables
arp arptables
bridge ebtables
  • ip（即IPv4）是默认簇，如果未指定簇，则使用该簇。
  • 创建同时适用于IPv4和IPv6的规则，请使用inet。inet允许统一ip和ip6簇，以便更容易地定义规则。

输出解释

table inet warp {
        chain warp-in {
                type filter hook input priority mangle; policy accept;
                ip6 saddr 2606:4700:d0::a29f:c001 udp sport 1701 @th,72,24 set 0x0
        }

        chain warp-out {
                type filter hook output priority mangle; policy accept;
                ip6 daddr 2606:4700:d0::a29f:c001 udp dport 1701 @th,72,24 set 0x46c997
        }
}
  • type 可以是filter、route或者nat。
  • hook 在IPv4/IPv6/Inet地址簇中，可以是prerouting、input、forward、output或者postrouting。其他地址簇中的钩子列表请参见nft(8)。

iptables命令

查看默认表filter的规则

对于每条链，内核会按照顺序依次检查 iptables 防火墙规则，如果发现有匹配的规则目录，则立刻执行相关动作，停止继续向下查找规则目录；如果所有的防火墙规则都未能匹配成功，则按照默认策略处理。 

$ sudo iptables -vnL 
Chain INPUT (policy ACCEPT 2211K packets, 855M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0

  • 命令
  • 默认 -t filter
  • -v 显示详细信息，-n显示具体ip和端口数值
  • 输出
  • policy ACCEPT 当前链的默认策略 ACCEPT
  • pkts：对应规则匹配到的报文的个数。
  • bytes：对应匹配到的报文包的大小总和。
  • target：规则对应的target，往往表示规则对应的"动作"，即规则匹配成功后需要采取的措施。
  • prot：表示规则对应的协议，是否只针对某些协议应用此规则。
  • opt：表示规则对应的选项。
  • in：表示数据包由哪个接口(网卡)流入，我们可以设置通过哪块网卡流入的报文需要匹配当前规则。
  • out：表示数据包由哪个接口(网卡)流出，我们可以设置通过哪块网卡流出的报文需要匹配当前规则。
  • source：表示规则对应的源头地址，可以是一个IP，也可以是一个网段。
  • destination：表示规则对应的目标地址。可以是一个IP，也可以是一个网段。

添加的动作

命令部分：-j + 如下动作 * ACCEPT：允许数据包通过。 * DROP：直接丢弃数据包，不给任何回应信息，这时候客户端会感觉自己的请求泥牛入海了，过了超时时间才会有反应。 * REJECT：拒绝数据包通过，必要时会给数据发送端一个响应的信息，客户端刚请求就会收到拒绝的信息。 * SNAT：源地址转换，解决内网用户用同一个公网地址上网的问题。 * MASQUERADE：是SNAT的一种特殊形式，适用于动态的、临时会变的ip上。 * DNAT：目标地址转换。 * REDIRECT：在本机做端口映射。 * LOG：在/var/log/messages文件中记录日志信息，然后将数据包传递给下一条规则，也就是说除了记录以外不对数据包做任何其他操作，仍然让下一条规则去匹配。

iptables管理命令

  • 选择表
  • -t指定表
  • 添加新规则
  • -A在链的最后追加一条规则 
  • -I在链的开头或指定序号插入一条规则 
  • -x显示精确值，不做单位换算
  • 替换规则
  • -R替换一条指定的规则
  • 查看规则
  • -L列出所有规则 
  • -n以数据形式显示地址与端口信息 
  • -v以更加详细的方式显示 
  • --line-numbers查看规则时，显示规则序号
  • 删除或清空规则
  • -D删除指定序号的一条规则 
  • -F清空指定表中的所有规则
  • 设置默认策略
  • -P为指定的链设置默认规则
  • 新建规则链
  • -N新建自定义链
  • 重命名链
  • -E重命名自定义链
  • 删除链
  • -X删除自定义空链 
  • -Z计数器清零

常见实例

Add a NAT rule to translate all traffic from the 192.168.0.0/24 subnet to the host's public IP: 

$sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE

$ sudo iptables -t nat -vnL --line-numbers
Chain POSTROUTING (policy ACCEPT 19 packets, 1551 bytes)
num   pkts bytes target     prot opt in     out     source               destination
6        0     0 MASQUERADE  all  --  *      *       192.168.0.0/24       0.0.0.0/0

$ sudo iptables -t nat -D POSTROUTING 6 #delete

有待学习

  • docker相关的iptables的输出
  • OpenWRT上iptables完全是空的，是显示错误还是防火墙用了firewalld
  • node5上的warp的mangle在哪里？

Ubuntu配置

Windows配置

  • 入站规则
  • 出站规则

OpenWRT配置

to finished

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://blog.csdn.net/weixin_45649763/article/details/103338747

https://juejin.cn/post/7108726951304495135

https://icloudnative.io/posts/using-nftables/

  • 分类于 network
  • 需要 3 分钟阅读时间

Nas Disk Speed Test

导言

电脑直接传输特别慢平均10M

群晖DS220j文件传输速度、外网访问速度、moment套件使用情况以及耗电情况。 最高写入速度为105MB/S，最高读取速度为110MB/S。

西数红盘 2T。 145MB/s。

知乎评测: 局域网实际拷贝速度还不错，基本能达到千兆水平。下图是拷贝GB级文件（如电影）的截图，拷贝照片和音乐之类的小文件会慢不少，10MB大小的文件写入速度有60MB/s左右，更小的文件就只有30MB/s了。

排查配置

网口

路由器是Redmi AX3000wifi6 WAN口和LAN口都是千兆口 2000Mbit 3000Mbit

电脑的网口是B450 迫击炮的主板 千兆口

网线

电脑连路由器的的网线是cat.6A的

电脑连墙壁接口的是cat.5e的

网线，DS220J 送的是cat.5e

只要网线够短，cat.5e至少有5Gb/s，一般都不是瓶颈。1

额外测试

网线直连电脑和群晖的机器，用这根CAT.6A，速度也很慢。

(结果第二天就好多了，路由器平均50M，直连能跑满，感觉原因在于路由器缓存转发的问题，端口都是千兆的)

其余测试

检测硬盘

diskgenius

命令行硬盘测速

控制面板 开启ssh

ssh -p 2333 [email protected]
sudo -s

sh-4.4# df -h
Filesystem         Size  Used Avail Use% Mounted on
/dev/md0           2.3G  1.1G  1.2G  50% /
devtmpfs           225M     0  225M   0% /dev
tmpfs              243M   24K  243M   1% /dev/shm
tmpfs              243M   15M  228M   7% /run
tmpfs              243M     0  243M   0% /sys/fs/cgroup
tmpfs              243M  1.5M  241M   1% /tmp
/dev/vg1/volume_1  1.8T  1.5T  289G  85% /volume1
/dev/vg3/volume_3  4.0T  2.0G  4.0T   1% /volume3
/dev/vg3/volume_4  4.0T   89M  4.0T   1% /volume4

# 磁盘读性能
sh-4.4# hdparm -Tt /dev/vg1/volume_1

/dev/vg1/volume_1:
 Timing cached reads:   1092 MB in  2.00 seconds = 545.67 MB/sec
 Timing buffered disk reads: 456 MB in  3.03 seconds = 150.28 MB/sec
sh-4.4# hdparm -Tt /dev/md4

/dev/md4:
 Timing cached reads:   1086 MB in  2.00 seconds = 542.89 MB/sec
 Timing buffered disk reads: 838 MB in  3.00 seconds = 279.23 MB/sec
sh-4.4# hdparm -Tt /dev/mapper/vg3-volume_4

/dev/mapper/vg3-volume_4:
 Timing cached reads:   1076 MB in  2.00 seconds = 537.13 MB/sec
 Timing buffered disk reads: 592 MB in  3.01 seconds = 196.89 MB/sec

 # 磁盘写性能
sh-4.4# dd if=/dev/vg3/volume_3 bs=1024 count=1000000 of=/1Gb.file
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 13.0458 s, 78.5 MB/s
sh-4.4# dd if=/dev/vg1/volume_1 bs=1024 count=1000000 of=/1Gb.file
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB, 977 MiB) copied, 18.837 s, 54.4 MB/s

群晖测网速

群晖的docker里也有speedtest

参考文献

  1. Cat5e，超五类线到底能不能支持千兆？ ↩

  • 分类于 network
  • 需要 2 分钟阅读时间

Synology NAS Configuration

Nas 购买的考虑点

https://post.smzdm.com/p/a5d23w98/

  1. 处理器:建议至少是Intel的双核，ARM的还是不好使。单核性能太弱了。虚拟机，docker什么的就别想了。
  2. 群晖官方套件不支持DS220j，十分不建议尝试。
  3. 内存:尽量8GB组双通道
  4. 网口:群晖的都是1Gb的老千兆(虽然我电脑，路由器网口也是)，但是威联通是2.5Gb的。
  5. M2.SSD加速:是否支持SSD加速
  6. USB口是不是3.2Gen2

群晖 DS220J (本体1200)

控制台与数据访问

  1. PC公用路由器控制：http://find.synology.com或者http://synologynas:5000
  2. QuickConnect：https://QuickConnect.to/shaojiemike or http://222.195.90.2/ (能ping通，就能访问)
  3. 电脑SMB直接访问
    1. \\192.168.31.247 (双斜杠，右键home有选项：映射网络驱动器)
    2. \\tsjNas (需要在局域网下)
    3. \\222.195.90.2/ (需要开启路由器的SMB（137-139，445）端口转发，否则能ping通，但是不能访问)

wireguard 网络配置脚本

使用开机wireguard脚本连接上网

  • 任意盘位置 /volume1/xxx编辑脚本，赋予权限
  • 群晖添加计划：点击任务计划。点击新增 -> 触发的任务 -> 用户定义的脚本(注意选择root用户权限)
  • 也可以选择写入启动文件中 vi /etc/rc
# 设置本地ssh eth0的222.195.90.2的高优先级，不至于开启wg断开ssh
ip ro add default via 222.195.90.254 dev eth0 table eth0-table
# 为了使得除开本地ssh网络走wg，需要删除屏蔽default的wg的DHCP
ip ro d default via 222.195.90.254 dev eth0  src 222.195.90.2 table main
# 防止服务端重启，Nas的wg客户端失联
ip ro a 114.214.233.0/24 via 222.195.90.254 dev eth0  src 222.195.90.2 table main 
# 启动wg
wg-quick up wg1

常见问题与解决方案

删除失效网络硬盘

Win10 无法直接取消，会报错"此连接不存在"，参考文章1

需要删除两项 regedit注册表 计算机\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\##10.0.0.12#homes 和 计算机\HKEY_CURRENT_USER\Network 下对应的盘符即可。

十分不建议组RAID

如果要利用空间不要组RAID，通过添加存储池来使用每个盘。

RAID0也不要组，文件是打散的，虽然读和写块，但是是一个整体。坏一个就全坏了。

先配置存储池和存储空间

然后设置文件夹

再重新映射盘符即可

停用与启用硬盘

若要激活硬盘： 已停用硬盘的分配状态会更改为未初始化，这表示此硬盘未安装 DSM，可以分配给存储池。请执行以下任何操作以激活硬盘：

  1. 从硬盘插槽中移除硬盘，然后将其重新插入硬盘插槽。
  2. 重启系统。
图形化界面控制台很卡顿

原因内存和性能不行，建议升级DS220j+ 额外拓展内存

电脑直接传输特别慢平均10M

群晖DS220j文件传输速度、外网访问速度、moment套件使用情况以及耗电情况。 最高写入速度为105MB/S，最高读取速度为110MB/S。

西数红盘 2T。 145MB/s。

知乎评测: 局域网实际拷贝速度还不错，基本能达到千兆水平。下图是拷贝GB级文件（如电影）的截图，拷贝照片和音乐之类的小文件会慢不少，10MB大小的文件写入速度有60MB/s左右，更小的文件就只有30MB/s了。

正常插在路由器LAN口下，无法找到群晖的IP

很有可能之前设置了静态IP，然后换了网络环境，网络掩码变了自然完全找不到。唯一的办法就是一定要保存和记录下之前的静态IP。

参考文档

  1. 群晖文档 ↩

  • 分类于 network
  • 需要 7 分钟阅读时间

Wireguard

简介

  • WireGuard 是由 Jason Donenfeld 等人用 C 语言编写的一个开源 VPN 协议，被视为下一代 VPN 协议，旨在解决许多困扰 IPSec/IKEv2、OpenVPN 或 L2TP 等其他 VPN 协议的问题。它与 Tinc 和 MeshBird 等现代 VPN 产品有一些相似之处，即加密技术先进、配置简单。
  • 从 2020 年 1 月开始，它已经并入了 Linux 内核的 5.6 版本，这意味着大多数 Linux 发行版的用户将拥有一个开箱即用的 WireGuard。
  • WireGuard 作为一个更先进、更现代的 VPN 协议，比起传统的 IPSec、OpenVPN 等实现，效率更高，配置更简单，并且已经合并入 Linux 内核，使用起来更加方便。

常见VPN方法比较

  • wireguard 精簡、速度極快：
  • 只有 4000 行程式碼，是最精簡的 VPN 協議。对比下 OpenVPN，大约有 10 万行代码。
  • WireGuard 利用内核空间处理来提升性能（更高吞吐和更低延迟），同时避免了不必要的内核和用户空间频繁上下文切换开销。

Wireguard客户端连接Debug

  • 首先，服务端的ip或者域名能ping通
  • 其次端口确定开放> nc -z -v -u 4.shaojiemike.top 51822,wg是udp
  • 修改wg客户端配置文件，限制ip为wg设置的内网段，AllowedIPs = 192.168.31.0/24，10.0.233.1/24.然后ping 192.168.31.1测试
  • 如果还不行，判断为wg的VPN包被中间网关识别并丢弃

配置文件

配置详解参考中文文档

PersistentKeepalive

  • 一端位于 NAT 后面，另一端直接通过公网暴露
  • 这种情况下，最简单的方案是：通过公网暴露的一端作为服务端，另一端指定服务端的公网地址和端口，然后通过 persistent-keepalive 选项维持长连接，让 NAT 记得对应的映射关系。
  • [peer]里设定字段 PersistentKeepalive = 25，表示每隔 25 秒发送一次 ping 来检查连接。

AllowedIPs

虽然AllowedIPs = 0.0.0.0/0与AllowedIPs = 0.0.0.0/1, 128.0.0.0/1包含的都是全部的ip。

但是前者在iptable里为default dev wg1,后者为两条0.0.0.0/1 dev wg1和128.0.0.0/1 dev wg1。

由于路由的ip匹配遵循最长前缀匹配规则，如果路由表里原本有一条efault dev eth0。使用前者会导致混乱。但是使用后者，由于两条的优先级会更高，会屏蔽掉原本的default规则。

前者的iptable修改如下：（macbook上）

> ip route
default via link#18 dev utun3
default via 192.168.233.1 dev en0
10.0.233.5/32 via 10.0.233.5 dev utun3
224.0.0.0/4 dev utun3  scope link
224.0.0.0/4 dev en0  scope link
255.255.255.255/32 dev utun3  scope link
255.255.255.255/32 dev en0  scope link

后者的iptable修改如下

> ip route
0.0.0.0/1 dev utun3  scope link
default via 192.168.233.1 dev en0
default via link#18 dev utun3
10.0.233.5/32 via 10.0.233.5 dev utun3
128.0.0.0/1 dev utun3  scope link
224.0.0.0/4 dev en0  scope link
224.0.0.0/4 dev utun3  scope link
255.255.255.255/32 dev en0  scope link
255.255.255.255/32 dev utun3  scope link

原理

建议看WireGuard 教程：WireGuard 的工作原理 和WireGuard 基础教程：wg-quick 路由策略解读，详细解释了wg是如何修改路由表规则的。

wireguard 运行原理以及配置文件

默认会产生51840的路由table，ip rule优先级较高。可以通过配置文件中添加PostUp来修改最后一个default的路由规则。

root@snode6:/etc/wireguard# cat wg0.conf
[Interface]
Address = 192.168.253.5/32,fd00::aaaa:5/128
PrivateKey = eGj5skRAGJu8d………………1PVfu0lY=
# PublicKey = VWe0wBVztgX………………xd7/kZ2CVJlEvS51c=

#Table必须有，不然默认的还是会修改ip rule
Table = 51820
#DNS = 1.1.1.1 #指定DNS服务器

#启动时运行： %i 是指wg的路由， 默认修改default， metric 一般不用指定
PostUp   = /sbin/ip -4 route replace default dev %i table default metric 1
PostUp   = /sbin/ip -6 route replace default dev %i table default metric 1
#down后运行
PostDown = /sbin/ip -4 route delete  default dev %i table default metric 1
PostDown = /sbin/ip -6 route delete  default dev %i table default metric 1

PostUp会产生下面的规则

root@snode6:/staff/shaojiemike# ip ro show table default
default dev wg0 scope link metric 1

OpenVPN原理

OpenVPN原理通过在main添加all规则来实现

# shaojiemike @ node5 in ~ [22:29:05]
$ ip route show table main
0.0.0.0/1 via 192.168.255.5 dev tun1

clash TUN模式

Macbook上的应用上的ClashX Pro的增强模式类似, 会添加如下配置，将基本所有流量代理（除开0.0.0.0/8）

> ip route
1.0.0.0/8 via 198.18.0.1 dev utun3
2.0.0.0/7 via 198.18.0.1 dev utun3
4.0.0.0/6 via 198.18.0.1 dev utun3
8.0.0.0/5 via 198.18.0.1 dev utun3
16.0.0.0/4 via 198.18.0.1 dev utun3
32.0.0.0/3 via 198.18.0.1 dev utun3
64.0.0.0/2 via 198.18.0.1 dev utun3
128.0.0.0/1 via 198.18.0.1 dev utun3 #前面接受所有的ip，然后转换成198.18.0.1
198.18.0.1/32 via 198.18.0.1 dev utun3 #接受转换后的198.18.0.1，由于最长前缀匹配

明显有代理死循环问题，如何解决？？？

shaojiemike@shaojiemikedeMacBook-Air ~/github/hugoMinos (main*) [10:59:32]
> ip route get 198.18.0.42
198.18.0.42 via 198.18.0.1 dev utun3  src 198.18.0.1
shaojiemike@shaojiemikedeMacBook-Air ~/github/hugoMinos (main*) [10:59:38]
> ip route get 198.18.0.1
198.18.0.1 dev utun3  src 198.18.0.1

Wireguard 环境配置

wireguard-go: 安装客户端 wg-quick up config wireguard-tools: 安装服务端 wg

Wireguard 常见命令

  • 启动wg-quick up wg1
  • 关闭wg-quick down wg1
  • 查看状态 wg显示全部，或者wg show wg1显示wg1

wireguard开机启动

systemctl enable wg-quick@wg1 --now

使用wireguard 代理ipv6请求

  • WireGuard 也支持 IPv6。OpenWRT 服务端，当然要allowed ip fd00::aaaa:5/128、
  • 注意：这是伪需求，为什么ipv6的流量需要走ipv6，不走wg，每个机器可以获得独立的公网ipv6，对于PT做种是很好的。
brainiac1# cat wg-tsj.conf
[Interface]
PrivateKey = xxx
ListenPort = 51828
Address = 10.0.233.7/32, fd00::aaaa:5/128
Table = 51820
#DNS = 1.1.1.1

# 使用iptable修改ipv6的路由规则
PostUp   = /sbin/ip -4 route replace default dev %i table default metric 1
PostUp   = /sbin/ip -6 route replace default dev %i table default metric 1
PostDown = /sbin/ip -4 route delete  default dev %i table default metric 1
PostDown = /sbin/ip -6 route delete  default dev %i table default metric 1

[Peer]
#AllowedIPs = 0.0.0.0/0,::/0
PublicKey = xxx
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = 4.shaojiemike.top:51822
PersistentKeepalive = 30

两次wireguard上网

修改sysctl.conf文件的net.ipv4.ip_forward参数。其值为0,说明禁止进行IP转发；如果是1,则说明IP转发功能已经打开。

需要执行指令sysctl -p 后新的配置才会生效。

两台机器的wireguard配置

注意中间需要NAT转换, 相当于把kunpeng机器的请求，隐藏成snode6的请求。在后一次wireguard转发时，就不会被过滤掉。

PostUp   = iptables -t nat -A POSTROUTING -s 10.1.0.0/24 ! -o %i -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -s 10.1.0.0/24 ! -o %i -j MASQUERADE || true

机器（Nas）使用Wireguard上网

问题场景

由于换了wg服务端，导致nas变成闭环的网络了。最后是通过群晖助手(Synology Assistant / Web Assistant)的设置静态ip才连接上机器，但是iptable被设置乱了。

Synology Assistant can not find nas

静态连接上机器，首先在网页管理页面切换成DHCP（静态ip的DNS解析有误），iptable变成如下

sh-4.4# ip ro
default via 222.195.90.254 dev eth0  src 222.195.90.2
10.0.233.0/24 dev wg1  proto kernel  scope link  src 10.0.233.3
222.195.90.0/24 dev eth0  proto kernel  scope link  src 222.195.90.2

sh-4.4# ip ro s t eth0-table
222.195.90.0/24 via 222.195.90.2 dev eth0

注意iptable的修改是实时生效的。

思路

为了让nas上网我们需要满足两点

  1. 本地ssh eth0的222.195.90.2能访问机器(优先级更高)
  2. 其余网络走wg
# 重要项如下
sh-4.4# ip rule
3:      from 222.195.90.2 lookup eth0-table (ping 和 ssh ip 222.195.90.2的会使用这个规则)
32766:  from all lookup main (ping 和 ssh 其余ip 比如wg的10.0.233.3的会使用这个规则)

# 1. 设置本地ssh eth0的222.195.90.2的高优先级，不至于开启wg断开ssh
# 使用命令添加： ip ro add default via 222.195.90.254 dev eth0 table eth0-table
sh-4.4# ip route show table eth0-table
default via 222.195.90.254 dev eth0
222.195.90.0/24 via 222.195.90.2 dev eth0

# 2. 为了使得除开本地ssh网络走wg，需要删除屏蔽default的wg的DHCP(如果提前删，导致机器ssh连接不上了，重新插拔网线，让DHCP重新配置)：
# 使用命令添加：ip ro d default via 222.195.90.254 dev eth0  src 222.195.90.2 table main，
# 3. 防止服务端重启，Nas的wg客户端失联
# 使用命令添加：ip ro a 114.214.233.0/24 via 222.195.90.254 dev eth0  src 222.195.90.2 table main 
# 4. 测试： ping域名能正常运行

# 其余方法：为了使得除开本地ssh网络走wg，也可以不删除，在DHCP的前面添加wg的网络通路
# 使用命令添加： ip ro add default dev wg1  proto kernel  scope link  src 10.0.233.3 table main
sh-4.4# ip r s t main
default dev wg1  proto kernel  scope link  src 10.0.233.3

使用wg1配置如下：

sh-4.4# cat /etc/wireguard/wg1.conf
[Interface]
PrivateKey = xxx
ListenPort = xxx
Address = 10.0.xxx.xxx/24

Table = 51820
PostUp   = /sbin/ip -4 route replace default dev %i table default metric 1
PostDown = /sbin/ip -4 route delete  default dev %i table default metric 1

[Peer]
PublicKey = xxx
AllowedIPs = 0.0.0.0/1, 128.0.0.0/1
Endpoint = 114.xxx.xxx.xxx:xxx
PersistentKeepalive = 25

问题：服务端重启，Nas的wg客户端失联

要保留没有wg的时候访问服务端的eth0(114.214.233.xxx)的通路

sh-4.4# ip ro s t main
···
114.214.233.0/24 via 222.195.90.254 dev eth0  src 222.195.90.2
···

来自eth0的ssh与ping请求原路返回

源地址为自身IP的包走学校的路由器

目的：需要ssh和ping ipv4成功

修改netplan的配置文件

# shaojiemike @ node5 in ~ [22:29:11]
$ cat /etc/netplan/acsa.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno0:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 202.38.73.217/24
        - 2001:da8:d800:730::217/64
      gateway4: 202.38.73.254
      gateway6: 2001:da8:d800:730::1
      nameservers:
        addresses:
          - 202.38.64.1
      routing-policy:
        - from: 202.38.73.217
          table: 1
          priority: 2
      routes:
        - to: 0.0.0.0/0
          via: 202.38.73.254
          table: 1

$netplan apply

routing-policy会产生

# shaojiemike @ node5 in ~ [22:30:33]
$ ip rule
0:      from all lookup local
2:      from 202.38.73.217 lookup 1
32766:  from all lookup main
32767:  from all lookup default
# 也可以手动添加
ip rule add from 202.38.73.217 table 1 pref 2
或者
ip rule add from 202.38.73.217 lookup 1 pref 2

由于2优先级高，使得ping和ssh的返回信包(源地址为自身机器IP的包)走table1 规则，而不是走

routes使得所有的table1都会走学校的路由器(202.38.73.254)

$ ip route show table 1
default via 202.38.73.254 dev eno0 proto static
# 也可以通过`ip route add`
$ ip route add default via 202.38.73.254 dev eno0 proto static table 1

衍生问题：网络请求的源地址不是自己吗？怎么确定的

开启wg后，网络请求源地址变成了10.0.33.2。不是202.38.73.217

root@node5:/home/shaojiemike# ip ro
10.0.33.0/24 dev wg2 proto kernel scope link src 10.0.33.2

但是外界ping的是202.38.73.217。返回包交换所以会产生源地址为202.38.73.217的包

wireguard 实现翻墙

  • WireGuard 在国内网络环境下会遇到一个致命的问题：UDP 封锁/限速。虽然通过 WireGuard 可以在隧道内传输任何基于 IP 的协议（TCP、UDP、ICMP、SCTP、IPIP、GRE 等），但 WireGuard 隧道本身是通过 UDP 协议进行通信的，而国内运营商根本没有能力和精力根据 TCP 和 UDP 的不同去深度定制不同的 QoS 策略，几乎全部采取一刀切的手段：对 UDP 进行限速甚至封锁。
  • 虽然对 UDP 不友好，但却无力深度检测 TCP 连接的真实性。
  • 将 UDP 连接伪装成 TCP 连接不就蒙混过关了。目前支持将 UDP 流量伪装成 TCP 流量的主流工具是 udp2raw，但是有一款更强大的新工具： Phantun。

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

WireGuard 基础教程：使用 Phantun 将 WireGuard 的 UDP 流量伪装成 TCP

https://nordvpn.com/zh-tw/blog/vpn-xieyi/

https://blog.mozcp.com/wireguard-usage/

  • 分类于 network
  • 需要 1 分钟阅读时间

Localhost

环回地址

  • 环回地址，是指不离开主机的数据包(也就是说，这些数据包不会通过外部网络接口)。
  • 任何发往环回地址的数据包，其处理都在 TCP/IP 协议叠的链路层中实现的。这些数据包不会向下交由网卡（NIC）或者设备驱动程序处理，既不应在电脑系统以外出现，也不可经路由器转发。
  • 环回地址是主机用于向自身发送通信的一个特殊地址，帮助我们在同一台主机上实现client和server的功能。
  • 运用本地环回机制，便可在主机上运行网络服务，期间不须安装实体网络接口卡，也无须将该服务开放予主机所在网络。

localhost

  • localhost 是一个别名，用于指代为环回保留的 IP 地址(环回地址)。
  • IPv4使用 A 类地址的最后一个块（从 127.0.0.1 到 127.255.255）
    • 发送到这些地址（127.0.0.1 到 127.255.255.255）的所有数据包都会返回本机。
  • 而IPv6保留第一个（0:0:0:0:0:0:0:1 - 或 : :1）作为其环回地址。

0.0.0.0 任意ip

  • 0.0.0.0并不是一个真实的的IP地址，它表示本机中所有的IPV4地址。
  • 监听0.0.0.0的端口，就是监听本机中所有IP的端口。
  • 0.0.0.0是不能被ping通的。

localhost 与 127.0.0.1区别

  • localhost(本地主机)不是专门指 127.0.0.1，而是指为环回保留的整个 IP 地址范围。
    • 注意你不能总是使用127.0.0.1进行环回。
    • 仅限 IPv6 的系统不会响应此类请求，因为它们的 localhost 链接到地址::1。
    • 修改/etc/hosts文件即可修改环回的地址。但是十分不建议这样做，很可能导致本地服务崩溃
  • 请求的发送方式不同???
    • 127.0.0.1是通过网卡传输，依赖网卡，并受到网络防火墙和网卡相关的限制。
    • localhost不会解析成ip，也不会占用网卡、网络资源。一般设置程序时本地服务用localhost是最好的。

如何将环回地址某端口上的服务映射到外部网络接口

  • 可以使用ssh转发ssh -L 1313:localhost:8020 [email protected]将服务器localhost:1313上的内容转发到本地8020端口
  • hugo server -D -d ~/test/public默认会部署在localhost上
  • 解决办法hugo server --bind=202.38.72.23 --baseURL=http://202.38.72.23:1313 -D -d ~/test/public

需要进一步的研究学习

暂无

遇到的问题

暂无

开题缘由、总结、反思、吐槽~~

参考文献

https://blog.nnwk.net/article/107