弹霄博科

书接前文优雅解决国内安装 Ollama 下载慢及卡顿的问题，我们在安装 Ollama 之后，还需要下载模型才能开始 AI 的学习和使用。有些模型并没有上架 Ollama 官方库，需要我们从 Hugging Face 或者 ModelScope 上面下载。AI 的模型动辄十几个 GB 或者几十个 GB，由于网络环境的原因，从这些站点拉取模型往往非常缓慢。 那么我们如何减小因为网络带来的阻碍呢？ CNB.cool 是腾讯云为开发者提供的下一代开发平台，基于 Docker 生态，把环境、缓存、插件一并纳入声明式管理，用更聪明的方式重新定义软件构建。它既是 Git 仓库，也是高性能开发和构建环境（支持 GPU）。 同时，CNB.cool 的仓库原生支持 Docker Model，玩法非常丰富。 模型不落地所谓“模型不落地”，即直接在云端环境使用高性能 GPU 进行模型的推理和微调，无需将巨大的模型文件拉取到本地电脑。 CNB.cool 提供了 H20 和 L40 的 GPU 资源，单次使用时长最大支持 4 小时。 cnb:arch:amd64:gpu：amd64...

我们在中国香港的网络服务商使用 AS-SET 自动生成前缀过滤器，这是当前主流且相对安全的做法：上游会根据客户提供的 AS-SET，从 IRR 数据库中解析可接受的 route / route6，从而自动生成 BGP import policy。 在 HEX NET 中，目前有两类地址资源： 1、IPv6：由 RIPE NCC 分配2、IPv4：来自 ARIN 的 44NET IPv6 地址的 IRR 对象由我维护在 RIPE 和 ALTDB 中；而 44NET 的 IPv4 地址由其管理员维护在 RADB。这俩 AS-SET 有不同的名字，并且在不同的数据库中。 123whois -h filtergen.level3.net "RADB::AS-SKYWOLF-HK" | grep 209574ERROR: Can't find an AS macro or AS set object called AS209574:AS-HEXNET in source APNIC !...

IPv6 在实践中多使用 GUA 地址。对于多运营商环境，我们一般不会为客户端分配多个运营商的 IPv6 地址，需要给用户分配一个相对固定的地址，并通过出口网关类设备来调度用户使用哪家运营商出网。 在一些厂商中，这个功能被称为“前缀替换”，实际上这也是一种 NAT。RouteOS 没有明确的给出这个功能，但是可以通过 IPv6 Firewall 中的 netmap NAT 来实现这个功能。 配置如下： 123456789/ipv6 pooladd name=pool_v6_local prefix=2a05:dfc1:7111:1a::/64 prefix-length=64/ipv6 addressadd address=::1 from-pool=pool_v6_local interface=br_main/ipv6 firewall natadd action=netmap chain=srcnat out-interface=pppoe-cmnet-out src-address=\ 2a05:dfc1:7111:1a::/64...

写技术博客这件事，本身并不难，难的是写完之后的自我校对。 尤其是当文章偏技术、偏流程时，很容易出现一些问题： 描述不够准确，概念混用 行文逻辑不够顺畅，段落之间衔接生硬 有明显的错别字或语病，却在发布后才被发现 如果只是个人博客，改了也就改了；但一旦博客接入了自动部署、同步到多个平台，这些“小问题”就会被不断放大。 于是我开始思考一个问题： 既然代码可以在 PR 阶段做自动化检查，那文章能不能也来一次？ 这篇文章，记录的是我在博客写作流程中，引入 AI 自动审稿 的一次实践。 写作流程背景：把文章当成“代码”来管理我的博客采用的是一套比较常见的工程化写作流程： 日常写作在一个独立的 写作分支 内容定稿后，通过 PR 合并到 main 分支 main 分支触发自动部署，完成博客发布 这个流程在“交付”层面已经很成熟，但始终缺少一个关键环节： PR 阶段只有内容变更，没有质量反馈。 代码 PR 至少还有：Lint，Test，安全扫描。而文章 PR，基本只能靠人工阅读。 于是目标就变得很明确了： 在 PR 阶段，引入一个 AI...

其实这趟香港之行，从年初就已经躺在我的计划表里了。结果在我的墨迹下，香港之行就这样从“下个月”变成了“今年一定要去”，最后由于还剩两个月签证过期，才落在了年末。 直到 12 月中旬，我终于用一种非常“特种兵”的方式，把这件事给完成了。 这篇更像是一份行程底稿。没有小红书式的“必吃榜”“避雷合集”，更多是时间点、路径和一些当下的感受记录。它不一定适合第一次去香港、想慢慢逛的人，但如果你和我一样，只想在有限的时间里，想看一点不一样的香港，那么或许可以当作一个参考。 等下一次再来，再在这份骨架上，把细节一点点补全。 出行准备下次再来，应该会选在夏天。 我是 Base...

平时我们使用 VSCode 进行远程开发时，但远程开发过程中，GitHub 的 Copilot 似乎是失效的，它无法激活 MCP 扩展，会一直卡在运行中，直到超时。 解决方案： 使用 cmd+shift+p 打开指令面板 Preferences: Open Remote Settings (JSON) (SSH: …) 将文件更新为 123456{ "remote.extensionKind": { "GitHub.copilot": ["ui"], "GitHub.copilot-chat": ["ui"] }} 保存配置，使用 cmd+shift+p 打开指令面板 Developer: Reload window 这时你的 Copiot 将正常工作。 题图使用 Gemini 生成。

问题回放我在 CCR 2004 和 CHR 之间运行了一个 eBGP 会话，ROS 版本均为 7.20.5 以下是 CCR 的配置： 12345678routing bgp instanceadd as=0001 disabled=no name=bgp-instance-0001 router-id=1.1.1.1/routing bgp connectionadd afi=ip as=0001 input.affinity=alone input.filter=chain_from_hex \ instance=bgp-instance-0001 local.address=1.1.1.1 local.role=ebgp \ name=bgp-01 output.affinity=alone remote.address=1.1.1.2 remote.as=0000 \ routing-table=main 通过这个 BGP 会话，CHR 向我（CCR2004）通告了完整的路由表，此时我需要引入 input...

背景和拓扑本次问题发生在一条跨公网建立的 IPSec VPN 隧道中，双方运营商均为相同运营商，设备分别为： 本端：MikroTik CCR 2004（ROS） 对端：山石网科防火墙（Hillstone FW） 双方均为专线，具有公网 IPv4 地址，通过 IKEv1 野蛮模式（Aggressive Mode） 建立 IPSec 隧道。协商参数正常，SA（Phase 1/2）均稳定，无重协商情况，DPD 正常。 是一个典型的 Site to Site IPSec 场景，其中两台虚拟机 A、B 均可互相 Ping 通，往返时延较低，ICMP 无丢包。 问题现象ICMP 正常，但实际业务流量有明显异常。 1、从本端的虚拟机 A SSH 登录到 对端虚拟机 B 时，连接能够建立，但交互过程持续卡顿。在命令行中表现为输入延迟、屏幕回显缓慢，不到断线程度，但体验极差。 2、尝试虚拟机 AB 之间进行 iperf3 打流，发现很小而且时断时续。双端正常的带宽应该是 50Mbps。 初步排查ICMP 正常，但是业务流程异常这个现象，可能是 MTU...

Ollama 是一款功能完善的本地大型语言模型运行平台，能够让用户在本地环境中快速部署和运行多种主流 LLM 模型。官方安装包托管在 GitHub，但在国内部分运营商在下载安装过程中可能出现下载速度缓慢、连接中断甚至安装过程卡住的问题。 为了改善这一体验，我们在 cnb.cool 上构建了一个自动化同步流水线，定期从 Ollama 官方源拉取最新的安装包并同步到国内节点，使用户能够以更高的速度和稳定性完成下载。同时，我们对 Linux 平台的安装脚本进行了适配与重写，无需手动修改官方脚本中的源地址，即可直接使用与官方一致的安装命令完成安装过程。在保证一致性的前提下，提供了更适合国内环境的顺畅安装体验。 项目地址：https://cnb.cool/hex/ollama 欢迎大家 Star 这个项目。 同步规则 定期同步：每 30 分钟自动检查上游官方仓库是否有新版本发布，如有版本更新自动同步。 仅同步稳定版：只同步官方发布的稳定版本，不包含预发布版本。 安全可控：同步脚本开源，同步过程中只拉取 GitHub 中的 Release 文件，保证 Hash...

在某些场景下，我们会使用 Nginx 反向代理将内部业务系统发布到公网。通常一台 Nginx 服务器会代理并承载多个网站，这也使其成为互联网扫描器和恶意请求的重点目标。 互联网上的一些扫描器会采集和映射 IP 资产情报，包括域名与 IP 的关联关系、所属机构和地理位置等信息，从而进行资产识别或构建攻击面。此外，部分未绑定 Host 的恶意请求也会直接针对服务器 IP 发起访问探测。 为降低此类风险，我们需要对“直接通过 IP 访问 Nginx”这一行为进行限制和防护，以避免被恶意收集、分析或利用，从而有效保障代理站点和源业务系统的资产安全与服务稳定。 最终实现效果，使用 IP 通过 HTTP 方式访问 Nginx 被阻断，通过 HTTPS 方式访问握手失败。 配置方式，配置 Nginx 的 Default Server： 123456789server { listen 80 default_server; listen [::]:80 default_server; listen 443 ssl default_server; listen...