2019

Windows Terminal 试用小记

为了对水果近年来在 T2 问题上的倒行逆施表示反抗,我最近开始研究 Windows 下工作的可能性,由于 WSL 的完成度日渐提高,我使用 macOS 工作的最大理由已经消失,不过由于 conemu 等第三方终端总是感觉性能不好,刷新率和响应速度都和 iTerm 有肉眼可见的差距,在 Windows 下工作总觉得手感差点。不过 Windows Terminal 于近日宣布 feature complete,距离预定于明年初发布的 v1.0 只剩下 bug fix 工作,感觉是时候尝试一下,于是我老人家终于下定决心花了一晚上时间把我的 LTSC 系统升级到半年频道(Windows Terminal 使用了 conhost 的一些新 API,要求系统版本在 1903 build 18362 以上)

但是和 VS Code 发布之初类似,Windows Terminal 现在也只有 json 格式配置文件,没有 GUI 配置,不得不说这个还是挺劝退的,目前 WT 的文档非常的不齐全,组织的还比较混乱, 还全部直接扔在 Github 源码里,Github 本身不是一个便于阅读文档的地方,翻文档就很累,虽然微软提供了一个完整的 config sample ,但是由于太长了人类可读性也不是很好,有时候找半天不如直接 Google 搜关键词最后从某 issue 的角落里抄来一句能用的配置,个人还是很烦这种不得要领又无序可循的感觉,这也是我写本文的一个原因。

近期由于某地方需要一个能推路由且平台兼容性好一点的 VPN(wg 和 IPSec 之类都因为需要本机配路由或是兼容问题不想在 Windows 平台折腾)于是盯上了 openvpn,然后又由于懒得自己折腾 CA,又稍微看了看 openvpn 的收费版本 openvpn access server(简称 ovpnas 或 oas),在不激活的情况下,oas 支持两个设备同时连接,个人自己用其实是够了的,但是我出于好奇搜了一下有没有相关破解,并发现这个所谓的破解就是个 .egg 文件,听说将其替换就能绕过未激活版本的设备限制,于是又稍微花了点时间研究这个所谓的破解是怎么实现的。

声明:本文基于技术研究角度,笔者不支持对商业软件的破解行为,也不会传播相关破解补丁

从内网第二网关配置浅谈 ARP Flux 问题

TLDR :在同一个广播域内存在多个路由器/转发器如 VPN 网关、DR 模式的 IPVS 时,需注意内网主机的 ARP 配置,否则默认配置下 Linux 内核会使用所有可用 IP 进行 ARP ,可能引起被称为 ARP Flux 的混乱现象,一个典型现象为:网卡会使用绑定在其他网卡上的 IP 地址进行收发包。net.ipv4.conf.all.arp_ignore,net.ipv4.conf.all.arp_announce,net.ipv4.conf.all.arp_filter 等参数可以调整这一行为

背景,内网一台虚拟机用 wireguard 和外部一个 CN2 出口打了隧道,希望将这台虚拟机配置为内网 VPN 网关,其他机器将任意 IP 的路由指向此虚拟机(以下简称 gw)即可实现走 CN2 访问目的 IP。

在实际操作中,发现一个现象,按照上述流程配置过 iptables 和路由规则后,有时仍会发现内网的包不会按照预期转发到 gw 的 wghub 接口,此时在 gw 抓包会发现内网其他主机发来的包不是从 ethA 进入,查看内网其他主机的 ARP ,发现 ARP 缓存是错误的,ip neigh flush all 后使用 arping 进行测试,发现无论请求 192.168.0.a 还是 192.168.0.b,gw 都会同时将两张网卡的 MAC 地址作为响应,且响应返回时先后顺序固定,因此不明就里的客户端就会取第一个响应记录到 ARP 表。

TL; DR:本文主要从 socket 的关闭方式谈到 socket 的 SO_LINGER 属性,进一步分析 nginx 关于 lingering 的配置和源码,浅谈如何避免 socket 关闭时可能出现的一些问题。

在 Unix 上,一个连接实际上对应的是内核里的一个 fd, sockfd = socket(int socket_family, int socket_type, int protocol) ,因此 socket 的关闭实际上是使用 close() 调用将其当作一个普通 fd 进行关闭;但是对于 TCP 连接,可以使用 shutdown() 系统调用,将其当作一个全双工连接进行关闭后再使用 close() 进行销毁,两种方式在行为上略有区别。