关于机场在公司连不上的离奇排查记录
前几天朋友换了个新机场，速度快延迟低，我在家里白嫖用得那叫一个舒坦。结果到了公司就开始玄学——死活连不上。
开始以为是常见问题，按照惯例把能查的都查了一遍:
- 系统时间？ 去 time.is 对过了，误差不到 0.3s
- 路由追踪？ traceroute 到入口 IP，一路畅通无阻
- 端口封禁？ 试了好几个节点,都是同样的症状（就它家全军覆没，备用机场是好的）
这就很诡异了。配置文件在家里能用,到公司就不行,但网络层面又看不出任何问题。难道是公司网络有什么深层检测?但其他机场的备用节点又能正常使用...
就这样用了几天备用节点,心里一直觉得不对劲。直到今天突发奇想,盯着配置文件看了半天,注意到了那个 obfs-host 参数:
爱奇艺的域名...做混淆倒是挺合理的,毕竟流量大看起来正常。但转念一想——等等,公司不会把视频网站封了吧?
抱着试一试的心态,直接 curl 测试了一下:
结果屏幕上赫然出现:
真相大白。
不是端口被封,不是协议被识别,不是时间不同步,也不是路由问题——单纯是因为公司防火墙把爱奇艺域名拉黑了,而机场的混淆恰好用的是这个域名。
所以这几天的现象就是:客户端尝试连接 → 防火墙看到 iqiyi.com → 直接阻断 → 连接失败。跟代理本身、加密协议、什么深度包检测都没关系,就是撞在了一个意想不到的应用层策略上。
排查问题有时候就是这样,技术上越复杂的方向查得越细,反而忽略了最简单的可能性。谁能想到机场会因为混淆域名"太正常"而翻车呢?
这个 case 算是记一笔了——以后遇到类似问题,记得先 curl 一下混淆域名看看...
前几天朋友换了个新机场，速度快延迟低，我在家里白嫖用得那叫一个舒坦。结果到了公司就开始玄学——死活连不上。
开始以为是常见问题，按照惯例把能查的都查了一遍:
- 系统时间？ 去 time.is 对过了，误差不到 0.3s
- 路由追踪？ traceroute 到入口 IP，一路畅通无阻
- 端口封禁？ 试了好几个节点,都是同样的症状（就它家全军覆没，备用机场是好的）
这就很诡异了。配置文件在家里能用,到公司就不行,但网络层面又看不出任何问题。难道是公司网络有什么深层检测?但其他机场的备用节点又能正常使用...
就这样用了几天备用节点,心里一直觉得不对劲。直到今天突发奇想,盯着配置文件看了半天,注意到了那个 obfs-host 参数:
{
"tag": "高级 专线 香港 08",
"type": "shadowsocks",
"server": "[REDACTED]",
"server_port": 14xxx,
"method": "chacha20-ietf-poly1305",
"password": "[REDACTED]",
"plugin": "obfs-local",
"plugin_opts": "obfs=http;obfs-host=[REDACTED].iqiyi.com", // 注: [0-9a-f]{10}.iqiyi.com
"network": "tcp",
"udp_over_tcp": false,
"detour": "direct"
}
爱奇艺的域名...做混淆倒是挺合理的,毕竟流量大看起来正常。但转念一想——等等,公司不会把视频网站封了吧?
抱着试一试的心态,直接 curl 测试了一下:
curl -vv [REDACTED].iqiyi.com:14xxx --resolve [REDACTED].iqiyi.com:14xxx:[REDACTED]
结果屏幕上赫然出现:
<body><div class="message-container">
<div class="logo"></div>
<h1>FortiGate Application Control</h1>
<h3>Application Blocked</h3>
<p>You have attempted to use an application that violates your Internet usage policy.</p>
<table><tbody>
<tr>
<td>Application</td>
<td>iQiyi</td>
</tr>
<tr>
<td>Category</td>
<td>Video/Audio</td>
</tr>
<tr>
<td>URL</td>
<td>http://[REDACTED].iqiyi.com/</td>
</tr>
<tr>
<td>Policy</td>
<td>[REDACTED]</td>
</tr>
</tbody></table>
</div></body>
真相大白。
不是端口被封,不是协议被识别,不是时间不同步,也不是路由问题——单纯是因为公司防火墙把爱奇艺域名拉黑了,而机场的混淆恰好用的是这个域名。
所以这几天的现象就是:客户端尝试连接 → 防火墙看到 iqiyi.com → 直接阻断 → 连接失败。跟代理本身、加密协议、什么深度包检测都没关系,就是撞在了一个意想不到的应用层策略上。
排查问题有时候就是这样,技术上越复杂的方向查得越细,反而忽略了最简单的可能性。谁能想到机场会因为混淆域名"太正常"而翻车呢?
这个 case 算是记一笔了——以后遇到类似问题,记得先 curl 一下混淆域名看看...
🤣28🤯5❤1
Forwarded from Howard's 碎碎念 (Howard)
https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/
在翻 Windows Shim Database 时看到的一篇文章
商业软件靠兼容性赢得市场
Windows 升级一直要保持向后兼容导致 API 不能变
在翻 Windows Shim Database 时看到的一篇文章
商业软件靠兼容性赢得市场
Windows 升级一直要保持向后兼容导致 API 不能变
Joel on Software
How Microsoft Lost the API War
Here’s a theory you hear a lot these days: “Microsoft is finished. As soon as Linux makes some inroads on the desktop and web applications replace desktop applications, the mighty empir…
Forwarded from 橘橘橘子汁 & 🍊
https://github.com/LLM-Red-Team/qwen-free-api/issues/82
https://github.com/LLM-Red-Team/kimi-free-api/blob/5c114bf5926fcdced096f583953d7e86e9433672/src/api/routes/chat.ts#L40
啧，6k star 的项目就这么简单地藏毒藏了一年才有人发现
是谁在觉得开源软件有安全保障呢
https://github.com/LLM-Red-Team/kimi-free-api/blob/5c114bf5926fcdced096f583953d7e86e9433672/src/api/routes/chat.ts#L40
啧，6k star 的项目就这么简单地藏毒藏了一年才有人发现
是谁在觉得开源软件有安全保障呢
🤔4
关于 K5Web 握手失败的一次记录
TL;DR: Maybe Chromium 干的，根本原因是波特率不对，直接原因尚不明确（F12 观察 K5Web 在
若干天前新入手了一个 UV-K6, 既然是 K6 那自然是需要刷机的，遂打开 K5Web 插上写频线点连接——握手失败。
怀疑没插好——在拆机后肉眼可见的插紧后问题仍然存在；
怀疑写频线坏了——今天新买的写频线到了，换了一根问题仍然存在；
总不能是主机坏了吧，应该不至于。
由于手上没有 Windows 环境，没法用官方的写频软件交叉验证，只能继续对着 K5Web 怀疑人生。
然后突发奇想看看 stty 情况。
注意到 stty 多了一些 flag, 但波特率仍然是 9600 。
不对啊，我印象里记得网上 k5prog-win 的截图波特率应该是 38400 。
于是抱着试一试的想法，我执行了
stty -F /dev/ttyUSB0 38400 raw -echo
然后，它就握手成功了？？！
所以根本原因就是波特率不匹配，不清楚是 K5Web 的问题还是 Chromium 的问题。
附上本次案发的 Chromium 版本号
Version 142.0.7444.59 (Official Build) Arch Linux (64-bit)
果然匪夷所思的问题背后都有令人意想不到的原因。
TL;DR: Maybe Chromium 干的，根本原因是波特率不对，直接原因尚不明确（F12 观察 K5Web 在
SerialPort.open 时是有传入 { baudRate: 38400 } 的，这个应该是 Chromium for Linux 的问题）。若干天前新入手了一个 UV-K6, 既然是 K6 那自然是需要刷机的，遂打开 K5Web 插上写频线点连接——握手失败。
怀疑没插好——在拆机后肉眼可见的插紧后问题仍然存在；
怀疑写频线坏了——今天新买的写频线到了，换了一根问题仍然存在；
总不能是主机坏了吧，应该不至于。
由于手上没有 Windows 环境，没法用官方的写频软件交叉验证，只能继续对着 K5Web 怀疑人生。
然后突发奇想看看 stty 情况。
# 重新插拔写频线并刷新 K5Web 页面
sulfate@arch ~> stty -F /dev/ttyUSB0
speed 9600 baud; line = 0;
-brkint -imaxbel
# 点击 K5 Web 上的连接
sulfate@arch ~> stty -F /dev/ttyUSB0
speed 9600 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel
-opost
-isig -icanon -echo -echoe
注意到 stty 多了一些 flag, 但波特率仍然是 9600 。
不对啊，我印象里记得网上 k5prog-win 的截图波特率应该是 38400 。
于是抱着试一试的想法，我执行了
stty -F /dev/ttyUSB0 38400 raw -echo
然后，它就握手成功了？？！
所以根本原因就是波特率不匹配，不清楚是 K5Web 的问题还是 Chromium 的问题。
附上本次案发的 Chromium 版本号
Version 142.0.7444.59 (Official Build) Arch Linux (64-bit)
果然匪夷所思的问题背后都有令人意想不到的原因。
Vicicode
K5Web
一款 K5/K6 在线写频工具，使用应第一时间备份配置及校准数据，提供信道管理、设置管理、备份还原、固件升级等功能。
🤯5
Forwarded from 灵车漂移 (无羽の翼 (｢ • ̀ω•́ )｢)
每日消费电子观察
华擎 可能在搞点很新的东西？B650 转 X670 扩展卡曝光 两个PCIe 4.0 x4 M.2 、 三个USB-A、一个USB-C （10Gbps）、 两个SATA 一个10GbE网口 来源（游侠网、VideoCardZ、Level1Techs） 华擎不愧是妖板厂，从来没有让我们失望。 如果这卡能变成通用扩展卡就更好了（想🍑
论AMD南桥如何装在Intel主板上
https://b23.tv/BV1AXv4BvE4T
https://b23.tv/BV1AXv4BvE4T
Bilibili
论AMD南桥如何装在Intel主板上_哔哩哔哩_bilibili
AMD南桥其实是一个标准PCIe设备，可以用在任何平台；此视频中基于AMD南桥制作的扩展卡已在立创开源硬件平台开源:AMD B650南桥扩展卡 - 立创开源硬件平台；此视频简单记录了折腾的过程, 视频播放量 133221、弹幕量 423、点赞数 6031、投硬币枚数 3672、收藏人数 3923、转发人数 2291, 视频作者 铁甲依然在__, 作者简介 硬件设计交流群：879825200，相关视频：华擎妖板再现，六插槽同时支持D4和D5内存。，无视英特尔！主板厂商自行支持PCIe 4.0，Intel1…
🤯12