Windows, 因为网吧都用 Windows, 去网吧的人基本都是打游戏的，很少见网吧客户机用 Mac 或者 Linux 的。

没有做环境复现和抓包，下列是我的猜测，仅供参考：

假设有下列环境：

- 外网主机 ext: 203.0.113.101
- 光猫 gateway：WAN IP: 198.51.100.101 ，LAN IP: 192.168.1.1
- 你的内网手机 phone：LAN IP: 192.168.1.101
- 你的内网 srv: Web Server: LAN IP: 192.168.1.102

光猫配置的 DNAT: 198.51.100.101:28080 -> 192.168.1.102:80

从外网主机 ext 连接内网 srv:

1. ext 发出封包给有公网 IP 的光猫 gateway：

IP[SRC=203.0.113.101(ext), DST=198.51.100.101(gateway)] TCP[SPORT=53103(random), DPORT=28080]

2. gateway 收到封包，做 DNAT 修改目的 IP 地址和目的端口，然后发给 srv：

IP[SRC=203.0.113.101(ext), DST=192.168.1.102(srv)] TCP[SPORT=53103, DPORT=80]

3. srv 收到封包，然后回复：

IP[SRC=192.168.1.102(srv), DST=203.0.113.101(ext)] TCP[SPORT=80, DPORT=53103]

4. srv 发出的 reply packet 首先到达 gateway ，gateway 默认对 LAN-to-WAN 流量做 SNAT ，因为这个封包的地址匹配一条之前配置的端口转发规则，所以 SPORT 也会改回去：

IP[SRC=198.51.100.101(gateway), DST=203.0.113.101(ext)] TCP[SPORT=28080, DPORT=53103]

5. 外网主机 ext 收到 reply packet, 在它看来这就好像是 gateway 的 28080 端口直接发给它的，根本感觉不到内网 srv 的存在。

从内网主机 phone 通过公网 IP 198.51.100.101 和映射端口 28080 连接内网 srv:

1. phone 发出封包给 gateway:

IP[SRC=192.168.1.101(phone), DST=198.51.100.101(gateway)] TCP[SPORT=48131(random), DPORT=28080]

2. gateway 收到封包，修改目的地址，然后发给 srv:

IP[SRC=192.168.1.101(phone), DST=192.168.1.102(srv)] TCP[SPORT=48131, DPORT=80]

3. srv 收到封包，然后回复：

IP[SRC=192.168.1.102(srv), DST=192.168.1.101(phone)] TCP[SPORT=80, DPORT=48131]

4. 根据 srv 的路由规则，这个封包不需交给 gateway 转发，可以直接通过以太网发给 phone, srv 对 phone 的 IP 地址做 ARP 解析，然后构造以太帧交给网卡.

5. phone 收到这个封包，TCP session 由一个四元组 （ SRC_IP, DST_IP, SRC_PORT, DST_PORT ）确定，由于 sender 和最初的 DST 198.51.100.101 (gateway) 不一致，所以 phone 的 os 不认为这是之前那个 TCP session 的 reply ，所以丢弃封包。

解决方法其一，配置光猫（网关设备）的 hairpin NAT ，什么是 hairpin NAT: https://help.mikrotik.com/docs/display/ROS/NAT#NAT-HairpinNAT

hairpin NAT 正确配置之后，在以上的第二步 (gateway to srv) 的过程中，封包的 SRC IP 也会被修改，那么 srv 的 reply 封包的 DST IP 就会变成 gateway 的，而不是最初的 real sender, 再由 gateway 发给 real sender.

在家的时候用你本地电脑 mtr 那个公网 IP 试试看看输出，另外不知道是否方便提供一下网络拓扑（包括群晖接的是光猫 LAN 口还是路由器的 LAN 口，光猫是否工作在桥接模式，各个机器的 IP 地址等）。

线下聊，用方言沟通，会比较安全。

你的这种状态，事出有因，主要是因为每次（假设你有正当理由）请假的时候领导总是为难你，再加上从字里行间中看起来你自己性格稍微有点软弱。

我的看法，该请的请，尤其是重要的事，尤其是家人需要你陪伴过节的时候。你努力工作，不就是为了自己能过得开心一些吗？切勿舍近求远，忘记本心。我们公司的保洁每天都需要来清理垃圾，她请假都完全没问题，任何人都可以在自己需要的时候请假，如果公司少了你就不转了，那不是你的问题。

有啊，你就等收破烂的来了就给他。听到喇叭喊 “回收，旧彩电、旧冰箱、旧空调、旧电脑、旧电瓶、旧电风扇、旧洗衣机……”，你就给他就行了。

不是所有的 warning 都需要严肃对待吧，有的只是 linter 太过敏感了，例如 ([[nodiscard]])，改为 static member function 的建议等，可以配置一下 linter ，屏蔽一些规则, 让它少输出一些 warning 。

现在的充电头和电子设备基本都是通过协商来确定充电参数（电压、电流）了吧？

让一台电脑通过远程桌面访问另一台。

阿里云的数据就直接备份到阿里云啊，原汤化原食。在里面搜索看关键字 “快照”，“块存储”，“OSS” 之类的。

既然传文本（姑且假设这里的“文本”指 ASCII 编码范围内的文本，不是指 Unicode ）是 OK 的，那你可以把 Pod 里面的二进制 base64 编码成 ASCII 编码的文本内容（存到文件中），然后再把文件传出来，然后再 base64 解码得到最初的二进制。

这也太难了吧

小米 ax3000 符合内置天线的要求，只不过是 ax 的不是 be 的。

最近我买了一件合身的新衣服，照着镜子感觉还挺合适的，盼头说不上，至少能让自己开心一小会儿吧。

lwn.net

偏向于 Linux 以及自由软件周边的新闻。

https://www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode 这篇文章介绍了七层反向代理和 四层反向代理的区别，七层反向代理的转发器需要解析 HTTP 报文，重新发送 HTTP 报文，所以才需要证书。

四层的不需要。就好像你家的路由器也在转发你访问任意网站的流量，但是它不需要证书。

例如通过 nginx 就可以配一个端口转发，把本机 443 端口转发到 任意一个网站的 的 IP 的 443 端口，配置也很简单： https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/

请你复习一遍 OSI 网络参照模型，HTTP 协议位于应用层。

另外如果你愿意你甚至可以把任意一个域名（例如 example.com ）解析为 127.0.0.1 ，然后通过 https://example.com 访问本机 443 端口提供的这个网站，只需要做一个 TCP 转发 (127.0.0.1:443 -> <remote-ip>:443)。类似的名称（功能）：虚拟 IP ，端口转发，4 层反向代理，都可以做到这一点。你想想 Kubernetes Service 的 ClusterIP 是怎么实现的。

中间人攻击不存在，除非中间人能解密 HTTPS 流量，或者你信任了中间人签发的根证书。

1. 把每个小表格文件自己转成 csv 格式，或者让运维给你 csv 格式的，文件名编好顺序，例如 1.csv, 2.csv, ..., N.csv ；
2. 把每个文件的第一行去掉，但是要留一份出来单独保存，例如 head.csv;
3. 确保每个 csv 文件的最后一个字符一定是有且仅有一个换行符，然后按顺序合并下列文件 head.csv, 1.csv, ..., N.csv;