eSTK.me 是一款基于 STK Applets 技术的智能消费者 eSIM 卡(Consumer eSIM),相比传统的可插拔 eSIM 产品(如 eSIM.me 和 5ber.eSIM),eSTK.me 有着更多的功能和更好的用户体验。简单来说,如果你拥有 2 张 eSTK.me 的 eSIM 卡,你已经“eSIM 毕业”了。
eSTK.me 暂未公开销售,预计 2024 年 4 月开放预定。
目前市面上销售的可插拔消费者 eSIM 卡分为三种:
Unlike our ‘RED’ and ‘GREEN’ counterparts, we prioritize returning all freedom and privacy back to the customer while meeting GSMA requirements.
– eSTK.me
除上述特殊功能外,eSTK.me 使用方法与常规 eSIM 卡无异,也可以使用系统自带 LPA 或外置读卡器配置。
如图为 eSTK.me v2.3.0-a1 固件的 STK 菜单。用户可以使用手机的 STK(即 SIM Toolkit,SIM 卡应用)访问 eSTK.me eSIM 卡的菜单,进行配置、查询余额等操作。
1 | eSTK.me STK Menu |
eSTK.me 支持远程 LPA(rLPA)配置,用户可以在具有公网 IP 的 VPS 上自建 rLPA 服务器,与 eSIM 进行通信。
需求如下:
@estkme:“有 request 说建议我加上域名功能,但是我感觉麻烦.jpg”
vEID 用于伪装其他供应商的 EID,从而借用其他供应商的 Android App 来管理 eSTK.me eSIM 卡。不过,现在 eSTK.me 和开源的 OpenEUICC 达成了合作,写入对应的 ARA-M 后可以直接用 OpenEUICC 进行管理。
eSTK.me 提供了 STK 管理菜单(LUIe),但有些 eSIM Profile 也有自己的菜单。启用 STK 直通后,用户可以访问到 Profile 的菜单。重启 eSIM 卡片后,即可恢复到 eSTK.me 的菜单。
当 eSIM 卡上没有任何 Profile 时,eSTK.me 会伪装一个合法的 eSIM 配置,以便用户仍然能访问 STK 菜单。
当下 eSTK.me 发行了以下版本:
在已知 PDF 密码的前提下,可以简单地使用 pikepdf 库导出为一个干净的 PDF 文件。
1 | import pikepdf |
以这条笔记为例,其笔记 id 为 65e2c4fb00000000030367bd
。
找到页面 Open Graph 协议的视频标签
1 | <meta name="og:video" content=""> |
里面的 content
属性就是含水印视频的 URL,格式如下
1 | https://sns-video-hw.xhscdn.com/stream/110/259/01e5e2b96c2b17eb010371038dfdd2b1c0_259.mp4 |
页面源代码中搜索 originVideoKey
,找到如下 JSON 字段
1 | { |
其中的 \u002F
是 Unicode 编码的 /
,你可以用 jq
命令来解码。
1 | ~ % echo '{"originVideoKey":"spectrum\u002F1040g35830vr3bg1860005o6qr60o57fr83a7isg"}' | jq |
然后拼接在 https://sns-video-bd.xhscdn.com/
的尾部,得到无水印视频 URL
1 | https://sns-video-bd.xhscdn.com/spectrum/1040g35830vr3bg1860005o6qr60o57fr83a7isg |
网上的小红书解析工具会返回一个路径为 258
的 URL,与上述 URL 不同,但是仍然有效,不知道是怎么构造出来的。对比两个 URL 的差异如下:
1 | 不同位 1 1111 1 |
1 | import requests |
/etc/ntp.conf
, static password of privileged “support” account and hardcoded “arubasecretadmin” account in /etc/passwd
. The most important part is:By chance, I obtained a brand new Aruba 650 controller with full licenses, at a few years ago with an irresistible price. The licensing mechanism is complete off-line, which means that all necessary information is hashed/encoded as a part of the license key, including the serial number, feature set, expiration date, and so on.
AR00XXXXX
XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX-XXX
1 | filename: ArubaOS_6xx_6.4.4.25_79899 |
By simply running binwalk -re --dd=".*" ArubaOS_6xx_6.4.4.25_79899
, we can extract the firmware from the image.
1 | DECIMAL HEXADECIMAL DESCRIPTION |
Then, do the same thing for the extracted ELF file 200
: binwalk -e 200
, now we obtained a compressed file 5B4000.7z
. On Windows 10, we can use Bandizip to extract it, and we got a core_image_files.tar
, which is the root filesystem of the ArubaOS. This step seems cannot be done on macOS, for unknown reasons. The file tree is attached.
As for its name, core_image_files/mswitch/bin/licensemgr
, it seems to be the license manager of the ArubaOS. Based on the existing knowledge and with the help of ChatGPT, we can perform deobfucation to some extent.
1 | filename: licensemgr |
By looking into IDA, we have the pseudo code as follows:
1 | _BYTE *__fastcall _license_user_to_base64(char *a1, int a2) |
With the help of ChatGPT, we obtained the following deobfuscated code, with some comments generated by ChatGPT as well:
1 | // Function to convert a string to base64 with certain conditions |
So basically, it removes the hyphens from the input string, and adds padding for making it as a valid base64 string. By checking XREF information, we can found that this function is called by _license_decrypt_bundle_key
, _license_decrypt_feature_key
and _license_decrypt_platform_key
.
Let’s focus on _license_decrypt_bundle_key
first, it first calls _license_user_to_base64
to convert the input string to base64, then calls _license_str_to_byte
to convert the base64 string to byte array and check format validity, and finally calls _license_decrypt
to decrypt the byte array.
1 | license_decrypt((int)licenseInBytes, lic_b64_length_int_64 / 2, (int)output, 51) |
Since then I stucked, the _license_base64_dec
is so complicated.
eSIM (embedded-SIM, eUICC) 是一种嵌入式可编程的 SIM 卡,集成在设备主板或模块上,可以通过 LPA (Local Profile Assistants) 进行管理。eSIM 与 SoftSIM 不是同一个东西,但都是虚拟 SIM 卡的实现,两者都可以通过 OTA (Over-The-Air) 进行更新。
几天前 Apple 发布了国行 iPad(第 10 代)无线局域网 + 蜂窝网络机型(A3162),支持 eSIM,但是反向锁区,只能在境内激活中国大陆运营商(中国联通)的 eSIM Profile,在境外需要开启定位才能激活境外运营商的 eSIM Profile。借此机会也了解到一个新东西:eSIM 转物理 USIM。
早期这项技术被用于以下场景:
除此之外,我们可以使用 eUICC 测试白卡写入境外运营商的 eSIM Profile,畅游 Internet 或接收短信验证码(接码)。
5ber.eSIM(¥180)和 eSIM.me(€70)都提供 eSIM 实体卡片,用户可以使用它们的 Android App 将 eSIM Profile 下载至实体卡中(无需读卡器),然后插入手机、CPE 等设备使用。但这两家均软件限制了 Profile 的写入次数,并以此收费。
风险提示
eUICC Identifier(简称:EID)是 eUICC (embedded UICC) 的全球唯一物理标识(类似于网卡的 MAC 地址),存储在 eUICC 的 ECASD (eUICC Controlling Authority Security Domain) 中,主要用于 eUICC 卡管理和远程配置。EID 可以被读取但不能被更改,在远程配置中和 ICCID 一起共同关联某个 Profile 信息。
下图是 GSMA SGP.29 规范对于 EID 的格式定义。
淘宝店“速易卡科技”提供的 eUICC 成品卡片价格 ¥60 包邮,仅为 5ber.eSIM 的 ⅓,购买暗号“安卓esim”。还提供 USB-C 接口的 eUICC 读卡器、Nano SIM (4FF) to Mini SIM (2FF) 转接板、eSIM (MFF2) to Nano SIM (4FF) 转接板、植锡、ST33 芯片等。
注意:由于 iOS 区域限制,速易卡科技销售的 eUICC 白卡不能在国行 iPhone 中使用。外版(水货)iPhone 不受影响。
eSTK.me 当前仅销售工程样品 (ES 版),售价为 HKD$ 75,约合人民币 70 元。
eSTK.me 调用 USIM 卡的 Applet 实现在 iOS 内自助切换 Profile。写卡仍然需要借助硬件读卡器或者兼容 eSIM 的 Android 手机。支持国行 iPhone。
eSTK.me(固件 v2.x 及以后的版本)基于 ETSI 的 Bearer Independent Protocol (BIP) 协议,使得 eUICC 通过基带与远程服务器建立 TCP 连接,手动实现了 eSIM Profile 的远程配置(类似于 M2M 的形式)。本质上是让 STK 直接联网读写 APDU,而不是通过手机的 LPA 进行管理。因此,eSTK.me 是目前市面上唯一可以在 iOS 上实现自主写卡和 eSIM Profile 管理的解决方案。
eSTK.me 还支持以下特色功能
注意:由于缺失“China CI”,以上所有品牌(5ber.eSIM、eSIM.me 和速易卡科技等)发行的 eUICC 卡片均不能写入中国大陆运营商的 eSIM Profile。具体原因参见下文 Certificate Issuer (CI) 证书颁发者。
注意:不要购买 M2M eUICC。M2M eUICC 与 Consumer eUICC(消费者 eSIM)都属于标准的 GSMA eSIM 实现,但 M2M eUICC 不能写入 Consumer eSIM Profile,只能通过原厂的 OTA 平台进行云管理,仅用于集中管理 IoT 场景(例如共享单车)。若读者想进一步了解 M2M 和 Consumer eSIM 区别,可以参考下文部分的参考文献。
群友 @Lockestek 订购了一盒 FRU 为 4XC1L91362 的 Thales eSIM 卡:
已经验证过的可以在 Windows 10 上激活 eUICC 的 WWAN 模块:
根据笔者测试,L850-GL LTE WWAN 模块搭配 eUICC 可以
对于使用 7 代 Intel CPU 以上且主板集成了 USIM 插槽的 ThinkPad 用户,也可以购买以下支持 eSIM 的 WWAN 模组:
注意:
注意:除了下列运营商,其他区域运营商(如香港)通常需要 KYC(客户身份审查)认证,需要提供护照等实名身份信息。
常见的用于接收验证码的境外 Pay As You Go (PAYG) 现收现付 eSIM:
注意:苹果用户激活 iMessage 和 FaceTime 时需要发送短信,会产生费用。
部分运营商例如英国 Giffgaff 不直接提供 QR Code 和 eSIM Activation Code,只能使用运营商自有的 App 写入到手机中,不能加载至外部 eUICC。但是根据这个帖子,Giffgaff 用户可以在手机上进行 MITM 抓包,查看 URL 为 https://publicapi.giffgaff.com/gateway/graphql
的请求 body,其中的 lpaString
字段即 Giffgaff 的 eSIM Activation Code。Telegram 用户 @kkkwatt 提供了一份 Frida 的脚本:点 Giffgaff App 的“安装 eSIM 按钮”时 Frida 会在终端输出激活码。
Giffgaff 现在可以使用中国大陆 IP 直接订购 eSIM,无需实体卡板转换、无需通过中介办理。Giffgaff PAYG 是目前持有成本最低、无需实名 KYC 的 eSIM 方案。
注意:
详细的式定义可以参考 GSMA SGP.22。MOC 字段意思为 Mandatory, Optional or Conditional。
常见格式如下:
1 | LPA:1${SM-DP+_ADDRESS}${MATCHING_ID} |
SM-DP+_ADDRESS
即 Subscription Manager Data Preparation Address,是运营商侧的 eSIM 配置服务器地址。MATCHING_ID
则用于匹配对应的 eSIM Profile,可以理解为传递至 SM-DP+ 的 Bearer Token。为了方便用户,运营商一般会将 eSIM Activation Code 转换为 QR Code。终端扫描 QR Code 后,会自动将字符串写入到 eUICC 中。
如图是 Remote eSIM Provisioning (RSP) 的过程图,来源自 Android 文档。
MATCHING_ID
字段是可选的。例如 T-Mobile 绑定 eSIM 卡的 EID,所以在下载时无需提供 MATCHING_ID
。
SM-DP+ OID
字段一般不会出现。
Android 设备可以使用以下方式管理 eUICC 卡片:
2A2FA878BC7C3354C2CF82935A5945A3EDAE4AFA
(目前仅 eSTK.me 发行的 eUICC 卡片支持自定义 ARA-M)国行 Android 手机不一定双卡都支持 OMAPI,可以使用 eUICC Probe 检测各卡槽是否支持 OMAPI。
PC/SC 读卡器需要搭配以下 LPA 使用:
速易卡科技销售的读卡器(Alcor Micro USB Smart Card Reader)可以在 macOS Sonoma 和 Windows 10 下免驱使用。如果出现 APDU library init error
或 SCardTransmit() failed: 8010002f
,请手动安装 Alcor Micro USB Smart Card Reader 驱动。
执行如下命令运行 LPAdesktop:
1 | java -jar LPA-1.0.0.0-jar-with-dependencies.jar |
如果你的 macOS Sonoma 无法识别第三方读卡器,可以尝试安装 ACSCCID 驱动。
出厂预置了 SIM 插槽且已经安装了对应 WWAN 网卡(例如 L850-GL, L860-GL 等)的 ThinkPad/HP/Dell 笔记本用户,可以使用 Windows 10/11 系统自带的 LPA 管理 eSIM:Use an eSIM to get a cellular data connection on your Windows PC
淘宝上有网店销售 M.2 (NGFF) 转 USB 的 WWAN 转接卡,集成了 SIM 卡插槽。可以搭配 eUICC 卡和支持 eSIM 的 Fibocom(广和通)或 Quectel(移远)的 4G/5G WWAN 模块使用。部分转接卡存在兼容性问题。
eUICCManager
,可能可以使用 Android 原生的 LPA 管理 eSIM。已知国行小米 13 刷入 MIUI 国际版,可以使用系统内置 LPA 管理 5ber.eSIM 的 eUICC(ST33 白卡同理)。根据这篇博客和这篇博客,eSIM.me 的 App(即 LPA)使用 Open Mobile API (OMAPI) 与 UICC 进行通信,而非标准的 eUICC API。5ber.eSIM 也是如此。这也正是它们产品的使用场景:在不支持原生 eSIM 管理(LPA)的设备上使用 eSIM。
eUICC 使用 ARA-M 字段储存 Android 开发者证书的 SHA-1 或者 SHA-256 值,从而告知 Android 系统来自哪个开发者的应用可以访问自身,容许第三方 App 提权获得 Carrier Privileges。因此,用户只能使用特定的 App 通过 OMAPI 管理 eUICC。eSTK.me 可以宣告五种 ARA-M SHA-1,因此同时支持 5ber.eSIM、eSIM.me 和 EasyUICC 等 App。
OMAPI 是 Android 为外置安全组件(Secure Element,SE)提供的标准接口。eUICC 是智能卡(Smart Card)的一种,因此用 OMAPI 与 eUICC 通信是 by design 的,算不上 hack。至于 eSIM.me 想因此起诉 5ber.eSIM,就是另一回事了。
在 macOS Sonoma 上使用 LPA 操作 eUICC 时可能会遇到以下错误:
SCardTransmit() failed: 80100016
SCARD_E_NOT_TRANSACTED
这是 Apple 自行开发的 USB CCID 智能卡读卡器驱动在 macOS Sonoma 上的 bug。详细内容请参考以下内容:
建议更新至最新的 macOS Sonoma 14.4 Beta,或遵照上文替换读卡器驱动。
目前没有正式渠道获取小批量原装 Consumer eSIM 的途径,因为搞不到 GSMA 证书。你可以通过速易卡科技和 eSTK.me 购买匠人手作。
eUICC Manufacturer (EUM) 是 eUICC 卡片的制造商,通过 EID 的 8 位前缀进行区分。
你可以在 eUICC Manual 查询已知的 EUM 信息。
阅读本章节之前,建议先阅读 GSMA: eSIM 白皮书(中文翻译)。
你可以在 eUICC Manual 查询到已知的 CI 信息。
根据 GSMA 信息,目前消费者 eSIM 的证书颁发者有 DigiCert 和 WISeKey。
根据 PKI 数字证书在 eSIM 安全上的应用研究 | 中国联通研究院:GSMA 特别准许国内运营商自己选择 CI,CA 证书签发者必须是工业与信息化部公布的具有电子认证服务行政许可的认证机构,目前,三家运营商各自有 CA,国内的电信终端产业协会 (TAF) 也是具备为 eSIM 平台及 EUM 颁发证书的 CA。
根据 eSTK.me 和速易卡科技的信息,目前市面上存在同时支持 GSMA 和国内 CI 的 eUICC 卡片(内置了 CI 的根证书),可以同时写入国内运营商和国外运营商的 eSIM Profile。比如说,前文提到的 iPad 10 (A3162) 国行版。
ES9+.InitiateAuthentication
函数的定义:SM-DP+ 会返回 serverCertificate
给 LPA。因此,若 eUICC 拥有任意国内运营商的 CI,即可写入所有国内运营商的 eSIM Profile。
你可以使用 Infineon LPA、LPAc 或 EasyEUICC 读取 eSIM 中的 euiccCiPKIdListForVerification
和 euiccCiPKIdListForSigning
信息,对比 RSP 所支持的 CI,从而判断此 eSIM 卡片是否支持该 RSP(以及使用该 RSP 的运营商)。
根据上述内容整理得到国内运营商 RSP 与 CI 的对应关系,持有列表中任意 CI 即可写入该运营商 eSIM Profile:
中国信通院:www.esimtest.chinattl.cn
148030fc246c02ff222106125a8d6bda990afbe9
16b5d16048e3ea02bd4b606e5f77a4bf20808d83
665a1433d67c1a2c5db8b52c967f10a057ba5cb2
f54172bdf98a95d65cbeb88a38a1c11d800a85c3
中国移动:esim.yhdzd.chinamobile.com:8001
148030fc246c02ff222106125a8d6bda990afbe9
16b5d16048e3ea02bd4b606e5f77a4bf20808d83
cdf6d1c0a7b07f98a861b6e378b82f648d99663e
d3ef83fc503f9c6ec4b7f6ae055b7f1373d4ab1e
中国电信:esimapple.crm.189.cn
148030fc246c02ff222106125a8d6bda990afbe9
3bd3f57b34f44436e08f028b5101c0e0a9b0986e
16b5d16048e3ea02bd4b606e5f77a4bf20808d83
4eb94ea05b451a729cc5272ddf66f481701a05c9
cdf6d1c0a7b07f98a861b6e378b82f648d99663e
d3ef83fc503f9c6ec4b7f6ae055b7f1373d4ab1e
中国联通:esim.wo.com.cn
148030fc246c02ff222106125a8d6bda990afbe9
3bd3f57b34f44436e08f028b5101c0e0a9b0986e
16b5d16048e3ea02bd4b606e5f77a4bf20808d83
cdf6d1c0a7b07f98a861b6e378b82f648d99663e
d3ef83fc503f9c6ec4b7f6ae055b7f1373d4ab1e
只有中国移动的 RSP 是有端口的。
申请 eUICC 证书请联系证书签发主管单位。
首先 RouterOS 诞生已经有 20 年了,不是什么新鲜事物。对于城中村黑宽带、简易公共 Wi-Fi 覆盖和网吧等用户场景,可以以较低的成本搭建一套可靠的网络,并基本满足运营需求。自从 2015 年提速降费政策出台、2017 年工信部发文《关于清理规范互联网网络接入服务市场的通知》,黑宽带和付费 Wi-Fi 热点项目基本消失殆尽了。所以你会发现简体中文互联网里关于这个东西的资料和讨论,大部分是处于 2005 至 2015 年之间。
闲鱼上成堆的 RouterBoard 从何而来?漂洋过海的洋垃圾 AP(Ruckus、Aruba 和 Xirrus)又流向何处?
答案是“黑灰产”,高情商的说法为“工作室”。RouterOS 可轻易实现多 VLAN 匹配多 VPN 出口,配合脚本控制还能实现自动重拨号、批量更换 SSID 等需求;而 Ruckus、Aruba 等品牌的高密 AP 可提供单接入点接入上百终端的能力,并将 SSID 绑定至特定 VLAN。不过如今 OTG 集成供电和网卡的方案也成熟了,传统的无线接入方案也就慢慢落幕了。
RouterOS 的防火墙配置参数看着晦涩难懂,本质上是 Linux Kernel 的 Netfiler。至于 RouterOS Script 则是 MikroTik 自创的脚本语言,虽然语法完备但很奇怪,也没有语法检查或自动补全。如果是家庭用户,我不建议接触 RouterOS,你将在上面浪费非常多的时间,并且这种 domain knowledge 离开了 MikroTik 生态毫无意义。如果你自认为是一个时间和精力充沛,很多有钱有闲的极客,有着一定的网络知识,和一定的英文阅读能力,那么你可以选择它。
RouterOS 其实也有像 ArubaOS 那样完备的 User Guide,但 RouterOS 相关的中文社群一般以“伸手”、“回帖可见”为主,真正懂技术的人太少。写到这里,不禁想起一代传奇人物 Clowwindy 的一段话:
最适合这个民族的其实是一群小白围着大大转,大大通过小白的夸奖获得自我满足,然后小白的吃喝拉撒都包给大大解决的模式。通过这个项目我感觉我已经彻底认识到这个民族的前面为什么会有一堵墙了。没有墙哪来的大大。所以到处都是什么附件回帖可见,等级多少用户组可见,一个论坛一个大大供小白跪舔,不需要政府造墙,网民也会自发造墙。这尼玛连做个翻墙软件都要造墙,真是令人叹为观止。这是一个造了几千年墙的保守的农耕民族,缺乏对别人的基本尊重,不愿意分享,喜欢遮遮掩掩,喜欢小圈子抱团,大概这些传统是改不掉了吧。
– Clowwindy
当然,中文互联网也有像 YuSong 和 StarYu 这样的博主,算是一股清流了。
MikroTik Training Center(MTC)是 MikroTik 官方授权的培训机构,一般为代理商(公司)和从事弱电外包的个人。“MTCXX”只不过是 MikroTik 仿效 Cisco 的“CCXX“弄的一套培训体系,课程时长仅 2~3 天,本质上除了名称相似以外,不能一同而论。
MTC’s are not affiliated with each other and with MikroTik in any form
MTC 之间不存在任何关联,也不与 MikroTik 存在任何形式的关联。
简单玩玩的话可以在虚拟机中运行 RouterOS CHR,或者之前 StarYu 发布的已激活 RouterOS v6/v7 ova 镜像。手头充裕的可以购买 hAP ax2 (C52iG-5HaxD2HaxD-TC),一款支持 PoE-in 和 DC 双路供电,双链 Wi-Fi 6 的 5 口千兆紧凑型路由。hAP ac2 (RBD52G-5HacD2HnD-TC) 和 hEX (RB750Gr3) 也是不错的选择,性能足够应付千兆宽带场景,只不过硬件平台太老了,二手价格也不便宜,不如 600 块买新的 hAP ax2。
当然 MikroTik 和 Ubnt 这种起码正常的用户还能正常的买到正常的规格的产品,没有过分的缩水也没有过分的对私溢价,理客中一点说,确实他们的定位都算是在家用和商用中间,你的家用网络“进化”路线短期内到这里可能就是终点(毕竟就预算而言要不加个 0 已经买不到什么更贵的了),但是就长期或者对路由的性能产生足够高的需求后,你很可能会去折腾别的东西。
– 知乎匿名用户
MikroTik 的产品定价介于高端家用和低端商用之间,多出的那点成本你就当做是买 RouterOS 授权吧。如果是 TP-Link、小米在 2023 年以 100 块钱卖 MT7621 的路由器,人们早就骂娘了;但是 Ubnt EdgeRouter X (ER-X) 和 MikroTik hEX (RB750Gr3) 以 300 块钱的价格卖给你,你还是觉得香,这就是品牌溢价和洗脑的力量。
ER-X 这东西早些年在某 C 开头的论坛被捧成“弱电箱神器”,一堆人花 3-400 买回来发现看不懂英文、不会用,最后刷成 OpenWrt 或者 200 块钱挂闲鱼二手的比比皆是。距离 2015 年 ER-X 发布已经过去 8 年,其在淘宝等平台仍然维持 300+ 的售价。而你只需要花 200 就能买到基于高通 IPQ6000 的 Redmi AX1800,还能刷上 LEDE,高下立判。
EdgeRouter 的系统是 EdgeOS,底层基于 debian,用起来很舒适,在当年(2015 年)能提供精简的配置页面和流量可视化,确实惊艳。EdgeOS 是基于 Vyatta v6.3 的闭源产品,后来发展为了 VyOS,社区逐渐壮大,被 NTT、Vodafone 等运营商和 big tech 用于生产环境。
自 2017 年发布 ER-4 后,Ubiquiti 彻底抛弃了 EdgeRouter 产品线,转向颜值更高的 Unifi 产品。全球企业无线市场仍然是 Cisco、Aruba 和 Ruckus 为主,Ubiquiti 只能在 SOHO 和 SMB 市场混口饭吃。从 Gartner 每年发布的 Enterprise Wired and Wireless LAN Infrastructure 可以看到 Ubnt 和 TP-Link 在企业 WLAN 领域差不多打个平手。但 2020 年之后 Ubiquiti 就没上榜了。TP-Link 的 Omada 系列则在海外风生水起,其对标 Aruba 的 OfficeConnect,结合了 SDN 和云管理,提供软件控制器(类似于 Aruba Mobility Controller Virtual Appliance 和 Cisco vWLC)、硬件控制器(硬 AC)和云管理(类似于 Aruba Central)三种部署方式。
其实早在 2017 年香橼机构就痛批 Ubiquiti:
Ubiquiti’s investor filings are full of fluff and buzz words.
Ubiquiti 的投资者文件充满了空话套话。
The company claims market leading technology despite little R&D spending.
该公司声称其技术处于市场领先地位,但研发支出很少。
Major industry players appear not to recognize Ubiquiti as a competitor.
主要的行业参与者似乎不承认 Ubiquiti 是一个竞争对手。
除此之外,被某 C 和某 S 开头的社区吹到天花乱坠的、UI 花里胡哨的 UniFi Controller 本质上只是给 MikroTik 的垃圾 CAPsMAN 配上了好看点的前端交互,仅起到下发配置的作用,懂得都懂。
RouterOS v7 开始支持 RESTful API 了,这意味着即使你不会 RouterOS Script,也可以通过 Python、Go、Rust 等语言来实现自动化操作。当然,如果你愿意花一点时间适应语法,RouterOS Script 其实也能轻松上手。
多多参考官方文档,少看中文社区。官方文档虽然有些地方不够详细,但是基本上能解决 90% 的问题。中文社区的回答往往是瞎 jb 指导,或者知其然不知其所以然。尤其需要注意 RouterOS v6 与 v7 的配置不兼容,发布时间较早的文章可能已经过时了。
网络设备是“基础设施”,它们的配置应该是“一劳永逸”的,而不是“一劳永逸”的去维护。如果你的网络设备配置需要经常变动、追版本更新,那么你的设备或者架构一定是有问题的。MikroTik 也被称为 BugTik,就是因为 bug 太多。从 RouterOS 的 ChangeLog 可以看出,每个版本都有大量的 bugfix,而且 bugfix 之后又会引入新的 bug,永无止境。所以我建议,只要没遇到明显 bug 或安全问题,就不要轻易升级版本。
1 | # 作用域内使用变量,并拼接字符串 |
看到这里,你已经掌握了 RouterOS 脚本的基本语法。如果你曾经有过编程经验,那么应该能快速写出实现自己各种需求的脚本了。
熟练使用 RouterOS Script,可以实现很多有意思的功能。除了基本的计划任务(Scheduler),RouterOS 还在很多点位埋了 trigger 点位,当属性状态发生变化时可以
fetch
调用外部的 HTTP API,实现更新 DDNS、备份、消息通知等功能address-list
:实现动态的黑、白名单控制列举一些常用的点位:
下面分享一些我觉得不错的使用场景。
在互联网上直接暴露关键服务的端口,例如 Winbox,会有很高的风险。端口敲门是种 stateful 的保护机制,只有在特定的端口顺序被连接后,才会允许访问关键服务的端口。例如,只有在 1234、5678、9012 这三个端口被敲击后,才会允许访问 Winbox 的 8291 端口。
端口敲门的一种特例是单包授权(Single Packet Authorization),只需要发送一个特定的 UDP 或 TCP 包,就可以修改 RouterOS 的 address-list
,从而允许访问关键服务的端口。例如,只有在 1234 端口收到特定的 UDP 包后,才会允许访问 Winbox 的 8291 端口。
1 | # 将来自 WAN 的敲门的源 IP 加入白名单,过期时间 30 分钟 |
如果想实现多个敲门端口,可以建立多个 address-list
,然后在后续 filter
规则中 match 前序 address-list
,例如:
1 | /ip firewall mangle add chain=input in-interface-list=WAN protocol=tcp dst-port=1234 action=add-src-to-address-list address-list=login-candidate address-list-timeout=30m |
注意:最好采用随机端口作为敲门序列,不要使用单调递增或递减的端口号,否则可能会被端口扫描器触发。
参考资料
用 Firewall/Filter
的 content
字段识别 Winbox 和网页登录失败的内容,然后使用两个 address-list
依次记录失败的 IP,并最终将其加入黑名单。原理和端口敲门是完全一致的。
对于 SSH 爆破,这里使用的是 SSH 验证时的固定报文长度。
MikroTik Telegram bot - wife detector
MikroTik 官方整的活,使用计划任务轮询 Wi-Fi 接口的 registeration-table
,如果发现妻子手机的 MAC 地址出现,就通过 Telegram Bot API 发送消息。
1 | /tool fetch mode=https http-method=get url="https://api.telegram.org/bot[token]/sendMessage&chat_id=[chat_id]&text=[text]" keep-result=no |
Mobile Wi-Fi with GPS Tracking using MikroTik’s LtAP
集成了 GPS 和 LTE 的 MikroTik LtAP 使用计划任务上报坐标信息。
注意:中国大陆的地图服务使用了 GCJ-02 坐标系,又称为火星坐标系,需要将通过 GPS 获取的 WGS-84 坐标转换为 GCJ-02 坐标,否则会有几百米的偏移。
家用无线路由器一般有个 WPS 按钮,按下后就可以为位于 WPS 配对模式下的终端授权接入,无需输入密码。在 hAP ac2 等产品上也可以找到这个物理按键。有没有更便捷的方案,无需用户执行额外操作,就能实现 Wi-Fi 授权呢?
我们可以借助终端的 RSSI 信号强度来判断其是否在一定物理距离内,从而实现 Wi-Fi 近场认证。具体思路如下:
access-list
限制只有信号强度大于 -30dB
的终端才能鉴权。registration-table
,如果发现新的终端接入,就将其 MAC 地址加入可信的 VLAN。Wi-Fi 近场认证仅适用于访客和公共场所的防长期蹭网场景,对于家庭网络,建议使用 WPA2/WPA3 PSK。
关于本方案能否用于异构的无线网络,即使用 MikroTik 的 AP 做认证,用其他厂商(如 Ruckus 和 Aruba)的 AP 做接入,我没有测试过,但是理论上是可行的。实现本方案需要满足以下条件:
access-list
可以为不同接口单独设置,包括 CAP 的远程无线接口在内。因此可以为场所内不同位置的 AP 配置不同的 RSSI 阈值。
使用 /system backup
备份,使用 /tool e-mail
以邮件形式发送。
1 | :local url "https://api.example.com" |
每个下发的任务需要有一个独立的 id(UUID 或自增整数),当 RouterOS 执行完成或者失败后,需要将结果与任务 id 回传,也就是 Callback。
MikroTik 官方频道发布的手把手教学,基于 Druvis-Timma/Mikrotik。
实现思路和云平台管理一样,使用 while
循环每 5 秒轮询 Telegram Bot 的 getUpdates
接口,执行特定 userID
的命令,然后使用 sendMessage
接口上报执行结果。
对于用户发送的命令,这个项目没有直接运行,而是调用了 /system/ssh-exec
执行。其实是为了获取执行结果,因为 /system/script/run
只能返回执行是否成功,而不能返回执行结果。不过在新版本的 RouterOS 中提供了 :execute
函数,可以后台获取代码并并存储结果至文件或变量。
1 | :local fun ([:system ssh-exec 0.0.0.0 $command as-value]->"output"); |
将连接时间超过 1h 的终端加入黑名单。
1 | # 拉黑 |
RouterOS 的 CLI、Web 和 Console 只允许输入 ASCII 字符,无法直接输入中文字符。但是可以接受按 Byte 输入的 UTF-8 hex 字符串,因此可以使用 Python 或第三方工具生成 SSID。
1 | import re |
1 | /interface wireless set [find name="wlan1"] ssid="\e4\b8\ad\e6\96\87" |
RouterOS 可以为物理无线接口(master)添加 Virtual AP(slave)接口,实现广播多个 SSID。但是 SSID 以较低速率广播,会降低整个无线网络空口的吞吐量。Andrew von Nagy 制作了一张表,展示了不同 SSID 数量对吞吐量的影响。
两地机器使用 Site-to-Site VPN 互联,与协议无关,可以是 IPSec、IPIP、VXLAN 中的任何一种。DDNS 的实时性是很差的,因为 DNS 的本质是递归解析,而各级 DNS 服务器都有缓存,且不一定遵守 TTL。除此之外,使用 DDNS 还会将具体的 IP 与域名关联,有隐私风险。如果用户场景比较简单,只有这一路特定协议的 VPN,那么可以巧妙利用防火墙的 address-list
功能,实现动态更新对端 IP。具体思路如下:
address-list
,并将其标记为 endpointCandidate
,并设置超时时间。remote-address
为 endpointCandidate
。1 | :local endpointCandidate [/ipv6/firewall/address-list/get [find list=endpointCandidate] address] |
注意:从防火墙 address-list
中获取的 IP 是带有 CIDR 后缀的,需要使用 :pick
去掉后缀。
不过即使这样,也会存在短暂的业务中断。若想追求高可用,需要建立至少两条 tunnel,为每条 tunnel 按优先级配置 distance
,并使用 check-gateway
选项,实现自动切换。
1 | b2fa79b02f9d873b78dc0b50f3a0fa5f35d7cbbc65b530706deb1ba0cf0d2e9f ROS-6.46.8-X64-L6-6G.zip |
1 | efe0e56008c4247251f760afcb9c5f4b ROS-6.46.8-X64-L6-6G.zip |
就已发布的产品来看,仅 RB4011iGS+5HacQ2HnD-IN 为 4x4 MIMO 的设备,其余的产品线如 hAP、cAP 和 wAP 一般是 dual chain。不少产品搭配了 PoE-in 和 PoE-out,新出的 hAP ax lite 甚至支持 5V USB-C 接口供电 —— 不过这仍然是一个失败的产品,没有人会在 2023 年为一个 2x2 MIMO 的 2.4G only Wi-Fi 6 路由买单。在纯 2.4G 下,802.11ax 比 802.11b/g/n 有更高的调制速率,但也依赖于更高的 CCQ (Client Connection Quality),当周边环境有 Wi-Fi 干扰时,其吞吐性能不会比 802.11n 更好。
mAP 和 mAP lite 是个很棒的设计,小巧的外观,通过 MicroUSB 和 PoE 供电,非常适合经常旅行的人。不过这两款产品都是 2.4G only,接口仅 100Mbps,属实拉胯,自 2016 年发布至今,售价仍然高达 200 多元,性价比极低。
Audience 是 MikroTik 无线路由的高端系列,三频(5G + 5G + 2.4G)。一开始只支持 802.11ac wave 1,后来以 DLC 的形式加入了 802.11ac wave 2。这产品也相当失败,国内没见谁用过,只能搜到代理商的软文。产品定位过高,软件质量却跟不上。
自 RouterOS v7.13 始,老旧的 Wi-Fi 5 (802.11ac wave 1) 设备将加入 802.11ac wave 2 支持(例如 hAP ac^2 , cAP ac),支持 802.11ac wave 2 和无缝漫游) 802.11ac wave 2 与 wave 1 的对比可以参考华为文档,主要提升如下:
Controlled Access Point system Manager (CAPsMAN) 是 RouterOS 生态里的无线控制器,已经集成到了 RouterOS 中。
CAPsMAN 有以下几个特点:
缺点:
一些不太“智能”的客户端可能会始终连接到某个 AP 上,直至信号 RSSI 低至其预设值,这种现象被称为粘滞客户端(sticky client)。低速客户端会占用无线空口,劣化整个无线网的性能。Wi-Fi 漫游是由客户端主导的行为,而 RouterOS 并不支持 802.11k/v/r 中的任何一种漫游辅助技术。目前在 Aruba 上,可以通过 Client Match 来解决这个问题,但 MikroTik 并没有类似的功能,只能通过 access-list
根据 RSSI 断开弱信号客户端。在运行了 CAPsMAN 的 RouterOS 上,也可以用脚本监测各个接口的客户端数量以及客户端速率,并动态地踢除低速客户端。
就个人而言,写 RouterOS Script 是个很痛苦的过程,不仅没有 IDE support,语法也很奇怪,需要不断地查官方文档。最痛苦的是其没有类似 ESLint 这样的语法检查工具,运行时错误也不会抛出日志,bug 无从查起,只能手动打 log 断点。所幸 RouterOS 7 已经支持 RESTful API,可以通过 Python 等语言来编写脚本。
TP-Link、Ubiquiti UniFi 和二手的 Aruba Instant 更适合一般家庭场景。华为与 Cisco 虽然性能爆炸但配置过于繁琐,且涉及到 License 问题,成本也高很多。MikroTik 的无线产品系列兼容性差,配置繁琐,性价比也低,不推荐。
MikroTik 的 Nv2 类似 Ubiquiti 的 Airmax,是一种基于 TDMA(时分多址)的无线协议,用于点对点(PtP)和点对多点(PtMP)场景,在一些地广人稀、布线不方便的地区比较常见。折腾无线的读者对网桥和 CPE 这两个东西应该不陌生,常见于某些场景,例如塔吊、图传、电梯监控等场景,一般基于 802.11 Wi-Fi 协议。相对于 802.11 协议,Nv2 jitter 较小,用少量的延迟开销(几毫秒)换取更高、更稳定的无线性能。配置起来比较简单,没有什么参数,只需要设置好频率、带宽、SSID、加密方式等即可。在主控端可以分配上行和下行带宽、配置 pre-shared key 等。
用 RouterOS 自带的 Bandwidth Test 工具测试 UDP 流,使用一对 wAP ac,在室内无干扰环境下 5G 2x2 能获得 ~500Mbps 单向 UDP 吞吐,延迟始终保持在 3~4ms,不会出现传统 Wi-Fi 网络高达数百 ms 的抖动。
Their use of their own proprietary drivers over the years, leading to issues that are reported on the forum for years, never being fixed…
“If caps-man could control a good radio… It would be incredible!” I say this and hear it daily from MSPs I work with… As we credit back clients to replace their radios…多年来,他们使用自己的专有驱动程序,导致论坛上报告的问题多年来从未得到解决…
“如果 caps-man 可以控制一个好的无线电……那就太不可思议了!” 我每天都会听到与我一起工作的 MSP 这样说……当我们赊账给客户以更换他们的无线电设备时…
https://forum.mikrotik.com/viewtopic.php?t=181376#p899228
Don’t buy Mikrotik if you need these features. Sadly it’s that simple…
如果您需要这些(无线)功能,就不要购买 Mikrotik。很遗憾,就是这么简单…
https://forum.mikrotik.com/viewtopic.php?t=163696#p806431
Having managed over a thousand APs, we gave Mikrotik a shot. They are about as simple as Wi-Fi can get in terms of its functionality. Just a small step below Ubiquiti, which is also garbage for large installs. Omnidirectional, 2.4Ghz, 5Ghz, that’s it. You get 20-30 devices per band before signal starts to go down the crapper. They don’t even have something as standard as beamforming or roaming. They can’t handle any interference from other APs, much less noise like in industry (think 3 phase motors or heavy machinery).
Compare a \$100 wAP ac to say … a \$200 Ruckus R310. The Ruckus can easily handle 150 devices without missing a beat. Easier to manage, way more functionality.
Mikrotik APs are really only meant for very small installs. You go big, even medium business, much less enterprise, you go hardcore Cisco/Meraki, Aruba (not the Instant-On garbage, the real ones that are like \$800/AP), or Ruckus.
Heck, a \$500 Ruckus R710 was able to handle over 300 clients in a conference hall without any issues. You would need to buy nearly 15 WAP ACs to handle that kind of load, and in reality, it wouldn’t work well due to all the noise.
Mikrotik makes great routers and switches. Point to Points are reliable. Their APs suck though for anything more than a small or medium sized house.
在管理了上千个无线接入点之后,我们给 Mikrotik 提供了一个机会。就其功能而言,Mikrotik 是最简单的 Wi-Fi 产品。只比 Ubiquiti 低一小步,而 Ubiquiti 也是大型安装的垃圾。全向、2.4Ghz、5Ghz,仅此而已。在信号开始衰减之前,每个频段只能连接 20-30 台设备。它们甚至没有标准的波束成形或漫游功能。它们无法处理来自其他无线接入点的任何干扰,更不用说像工业领域那样的噪音了(想想三相电机或重型机械)。
将 100 美元的 wAP ac 与 200 美元的 Ruckus R310 相比。Ruckus 可以轻松处理 150 台设备,而不会有任何闪失。管理更方便,功能更强大。
Mikrotik 接入点实际上只适用于小规模部署。如果要大规模,甚至是中等规模,更不用说企业级设备了,就必须使用 Cisco/Meraki、Aruba(不是那种垃圾的 Instant-On,真正的 AP 要 800 美元)或 Ruckus。
500 美元的 Ruckus R710 能够在一个会议厅内处理 300 多个客户,而不会出现任何问题。你需要购买近 15 台 wAP AC 才能处理这样的负载,而实际上,由于信号太强,效果并不好。
Mikrotik 的路由器和交换机都很出色。点对点设备非常可靠。但他们的无线接入点对于中小型住宅来说就太差劲了。
https://www.reddit.com/r/mikrotik/comments/13gkudo/comment/jk12m8x/
]]>It doesn’t scale well, is difficult to configure, troubleshoot, & manage, and doesn’t perform well in dense or dirty RF environments.
I manage a community of around 40 buildings that has Mikrotik APs and the first lesson learned was how poorly CAPsMAN handles more than a handful of APs, and it’s been all downhill from there. We’ve lost countless engineering hours troubleshooting and trying to solve customer complaints, and finally just started swapping them out 1 for 1 with <another vendor>, and that instantly solves 99% of complaints.
它不能很好地扩展,难以配置、排除故障和管理,在高密度或嘈杂的射频环境中表现不佳。
我管理着一个拥有 Mikrotik 接入点的社区,该社区约有 40 栋楼宇,我学到的第一教训就是 CAPsMAN 处理接入点的能力有多差。我们在排除故障和解决客户投诉方面浪费了无数的工程时间,最后我们开始用另一家供应商把它们一个一个地换掉,这样就立即解决了 99% 的投诉。
https://www.reddit.com/r/mikrotik/comments/13gkudo/comment/jk0gv9w/
1 | [admin@rb5009] > int mon pppo |
用 MikroTik 自带的工具监测接口流量,在 qBittorrent 的 PT 流量(大包)单向跑满(考虑到内网损耗)1G 带宽情况下,数据包速率仅 83.7 kpps。根据测试报告,MikroTik 基于 MT7621A 的 RB750Gr3 在配置了 25 条 ip filter 时仍能保持 92.9 kpps 的速度。在家用环境追求小包(64 Byte)转发性能毫无意义,根本不存在大流量小包场景。
YouTube 2160p30 的推荐上传码率为 35–45 Mbps,而 YouTube 又会将视频用 H.264(avc1) 和 vp9 再压制一次用于分发。以 LG 的 OLED 展示片 为例,用 yt-dlp 查看所有播放格式的码率,同时也用 ffmpeg 做检验,最高清的 2160p60 HDR 的 vp9 视频流码率仅为 27.5 Mbps。
1 | ffmpeg -i '.\2020 LG OLED l The Black 4K HDR 60fps [njX2bu-_Vw4].f337.webm' -hide_banner |
根据网友数据,80-90 块钱的斐讯 N1 跑 Shadowsocks 的 aes-128-cbf 能到 300Mbps,aes-256-cbf 能到 200Mbps,chacha20 近 400Mbps,v2ray 的 VMess 也能跑 200Mbps。所以完全没必要跟风购买什么电犀牛 r86s 和 GL.iNet 之类的电子垃圾。
数据中心网络有个概念是东西向和南北向,放到家庭网的 context 中就是内网和外网。内网传输追求大带宽低延迟,但一般来说有 2.5G/10G 接口的高配 NAS 都不止一个端口,用 SFP+ DAC 或 AOC 电缆连接 NAS 与电脑即可,无需额外部署一个中间设备。对于配备了多个 1G 电口的 NAS,也可以通过 bonding 和 SMBv3 的 multichannel 聚合多个接口进行传输。
2.5GbE 是于 2016 年正式发布的以太网标准,目的是在现有的 Cat5e 和 Cat6 布线基础上上无痛从 1GbE 升级到 2.5/5GbE。如今淘宝和闲鱼平台上可以轻松以 100 元内成本获得双口 10GbE 网卡,京东上也能买到 200 元价位的 HASIVO 万兆交换机。铠装光缆和光电复合缆技术也已成熟,部署价格远比某些假洋鬼子品牌(如某三个字的日本商圈名和 X 线)还低。
SMZDM 和小红书上不少人拿 ESXi/PVE 装 RouterOS/OpenWRT/LEDE,顶上再跑一堆 docker,性能打折不说,遇到配置失误或硬盘 0e 全部炸掉,总共就那么几台设备,还划分几个 VLAN,十分搞笑。
目前 Power over Ethernet (PoE) 以太网供电技术就三个标准、四档(表格来源):
双空间流(Spatial Stream,SS)的 AP 的运行功率一般低于 10w。即使是 4x4 MU-MIMO 的 Ubnt U6 Pro 最大功率也不过 13W。802.3af 标准的交换机足以满足需求。
PoE+/PoE++ 的需求仅限于这几种情况:
消费者市场的 PoE 交换机大概分为以下三类:
100 元价位的 5 口千兆 PoE+ 交换机(不带 VLAN 等 L2、L3 网管功能)首选:
型号 | 总功率 | 厂商 | 标准 |
---|---|---|---|
TL-SG105P | 30W | TP-Link | 802.3af/at |
TL-SG105PE | 65W | TP-Link | 802.3af/at |
SG-105PL | 65W | 水星 | 802.3af/at |
均为无风扇金属外壳,安静、散热良好、开箱即用。
TP-Link 和水星是同一家公司,所以哪个便宜买哪个。笔者购买了多台,运行四年来没有出现任何问题。Tagged VLAN 流量也能 passthrough,不用担心。
其他的推荐:
前文已经提到了, YouTube 上 2160p60 HDR 的码率仅为 30Mbps 左右。除了家里有上百台设备,或者喜欢通过 Wi-Fi 连接进行 PT 下载的人,对于正常用户来说 2x2 802.11ac/ax 的 AP 足够用了。
2x2 802.11ac 考虑到协议开销和重传等情况,最佳吞吐可达 500Mbps,实际试用中 200-300Mbps,应付 4K 串流和无线备份也绰绰有余。
现阶段 RTC (Real-time Communication) 技术已经相当成熟,Wi-Fi 漫游场景下,STA 始终位于同一个 L2 域内,漫游时从上层应用来看只不过出现了短暂的丢包。即使是用户手动关闭 Wi-Fi,回退到 4G/5G 网络,也不会导致通话中断。某些国产 Android 系统(如小米)甚至支持网络加速,可以为微信等应用同时启用 Wi-Fi 和 4G/5G 网络。
]]>OpenAI is not available in your country
ChatGPT 最近很火,但不幸地是 OpenAI 屏蔽了中国地区和常见数据中心 IP 来源。这意味着,如果你在国内,想要使用 ChatGPT,除了需要一张外币信用卡/借记卡,还需要一个可以访问 OpenAI 的代理 IP。WARP 是 Cloudflare 提供的免费 VPN 服务,基于 WireGuard 协议,VPN 对端为启用了 anycast 的 Cloudflare CDN。WARP 的 IP 不在一些服务商的黑名单内,所以可以借助 WARP 来正常访问 ChatGPT 和 OpenAI 相关接口,以及其他流媒体服务(以解锁本地内容的版权限制),比如 Netflix、Hulu、Disney+。
一般来说我们无法在中国境内使用 WARP,但可以使用自有的境外 VPS 将代理流量路由至 WARP。基本思路是:将 WireGuard 的 Cloudflare WARP “转换”为 Socks5 协议,作为 V2Ray/Shadowsocks 的出站连接。
WARP 提供了官方的 Linux Client,内置了 proxy mode
,可以将 WARP 转换为 Socks5 代理。但这个 Socks5 代理只能 bind 在 localhost
,对于跑在 docker 里的 V2Ray/Shadowsocks 来说,无法直接使用。我们可以使用 socat
或 rinetd
建立一条本地的端口转发,具体过程略。
一些基于旧版内核的系统无法安装 warp 官方 Linux 客户端,例如 Oracle Linux 或者 RHEL。 Github - Mon-ius/Docker-Warp-Socks 是基于 ubuntu:22.04
base image 构建的一个内置 WireGuard 和 warp-cli 的容器,可以直接下载使用,不会弄脏宿主机。
香港地区是无法使用 warp-cli 创建的 WireGuard 配置连接的,必须使用官方的 Linux 客户端。
1 | # 注册设备 |
Shadowsocks 并不能像 V2Ray 那样 chaining,而 V2Ray 本身支持 Shadowsocks 协议,所以只需将 Shadowsocks 配置为 inbound object 即可,无需单独运行一个实例。
入站部分配置如下:
1 | "inbounds": [ |
V2Ray 默认使用第一条 outbound 作为出站路由,因此无需打 tag 也可正常使用。出站部分配置如下:
1 | "outbounds": [ |
至此配置完成,拓扑如下:
1 | Client <-- SS/V2Ray --> VPS <-- WARP --> Cloudflare Edge <--> Internet |
docker 网络默认是 bridge mode,将所有容器接在 docker0
的 L2 bridge 下,通过宿主机 NAT 访问外部网络。可以将 v2ray 容器运行在 host mode,这样 outbound address 可以直接使用 127.0.0.1,无需配置额外的端口转发。
访问任意托管在 Cloudflare CDN 下的网站的 /cdn-cgi/trace
路径,例如 https://1.1.1.1/cdn-cgi/trace
,可以获得如下格式信息:
1 | fl=Cloudflare WebServer Instance |
如果 WARP 字段数值为 on
,则说明 WARP 已经成功启用。如果为 plus
,则说明当前使用的是 WARP+ 或者 Zero Trust 团队版账号。
外观小巧精致,像一枚大号的白色围棋棋子。金属面有激光蚀刻的 Apple Logo。很容易沾染指纹和划痕,但是不影响使用。使用 CR2032 电池,预计寿命一年。更换也比较方便,将 AirTag 放在两只手心,逆时针转动金属面,即可打开电池仓。
本质上 AirTag 是一个低功耗蓝牙信标(BLE Beacon),定时广播自己的设备 ID,以及电池电量。当附近任意用户的 Apple 设备(iPhone、MacBook 等)收到其广播的信息,便会匿名上传至苹果服务器,以实现定位。使用具备 UWB 功能的 iPhone,则可以近距离精确定位 AirTag 位置。
使用 AirTag 跟踪托运行李挺方便的,不用再担忧行李是否被遗落在中转机场,不用焦急地等在行李传送带前。打开 Find My App,看着绿色箭头下方的数字越变越小,随后行李也出现在眼前。前些天在法兰克福机场转机时,托运行李被汉莎遗落在了机场。幸亏有了 AirTag 的帮助,才得以确定行李的大致位置,最后顺利寻回。
AirTag 的缺陷也很明显:
自 iOS 17 始,你可以与除自己外的最多五位借用人共享一个 AirTag 或其他物品,即每个物品共六位用户共享。感谢不愿意透露 ID 的匿名网友指正。
]]>Spec 参数一般般吧
遥控器取消了数字输入,只提供了基本操作按钮:方向键、音量键、确定、返回、首页、设置等。从设计上,厂家默认用户只会使用互联网串流平台和第三方机顶盒,而忽略了模拟电视和 DTMB 地面波用户。
机身净重 5.7kg,相较于传统电视来说确实轻薄了许多,但内部结构支撑不足,轻触边框即可看到电视背部扭曲变形,屏幕显示出现光影。壁挂式安装下,整机仅通过两颗螺丝固定,太脆弱了点。包装内连 HDMI 线都没送一根,厂商为了节省成本开始在各种地方减配。
考虑到如此低端的硬件,其操作系统也是卡的不行,从开机到首屏完全加载需要近 1 分钟时间。瀑布流的页面布局,没有提供精简界面,对老龄用户极不友好。
TCL/雷鸟禁止了第三方应用的安装,需要通过 adb 来手动实现
adb connect <电视机 IP>
连接至电视adb shell setprop persist.TCL.debug.installapk 1
adb shell setprop persist.tcl.installapk.enable 1
adb install <安装包名>
来手动侧载第三方 apk 了早期的 HTPC[^1] 玩家们对于 Kodi 应该不陌生。如今图形库和软硬件技术都获得了足够的替身,一些具有较高易用性的媒体资源管理系统,如 Plex、Jellyfin、Infuse Pro 和 Emby 变得流行起来。笔者平时使用 Plex,所以写一些关于 Plex 的东西。
[^1]: Home Theater PC,即家庭影院电脑。早些年流媒体软件和智能电视系统不那么易用时,人们用一台独立的小型计算机连接投影或电视作为显示终端,直接播放媒体文件。
不同于 Infuse Pro 和 Kodi 这样的本地应用,Plex 是一整套基于客户端/服务器(C/S)的解决方案。
原则上 Plex Media Server 需要绑定至一个 Plex 账号才可以使用,作为身份验证和远程管理的途径。对于可信的内网场景,可以关闭本地网段的身份验证:Settings > Server > Network > List of IP addresses and networks that are allowed without auth
。注意:任何来自此网段的用户都可以修改媒体服务器的设置。如非必要,切勿开启此功能。
Plex 的定位就是家庭和朋友间的资源库分享,身份验证只有开启(基于 Plex 官方账号)和关闭(免验证)两种情况,没有单独的账号注册机制,只有简易的 PIN 码。
Emby 可以使用 API 配合 Telegram Bot 进行用户管理,因此成为了搭建公益服的首选。
Emby 公益服一般用便宜大碗的月抛 Azure、AWS 服务器搭配阿里云盘、OneDrive 等云服务,极少数采用大盘鸡(大容量硬盘的服务器),服务可用率很灵(“灵车”的“灵”)。部分公益服为了限制用户人数,推出了充值、每日签到、答题考试等手段。
建议智商在线的读者,远离公益服,保持初心:你 TM 是来看电影的,不是来浪费时间签到做题赚积分的!
Scanner 即扫描器,用于解析本地媒体文件的文件名、目录结构以及本地的海报和 .nfo
元信息文件等。
“元数据”(Metadata)即媒体文件的封面图、简介、评分、创作团队信息等字段。Plex、Jellyfin 和 Emby 等媒体服务器从第三方的媒体数据库,如 TheTVDB、TMDB 和 IMDb,将云端信息与本地媒体文件相匹配,以实现海报墙、关键词搜索、预告片展示等功能。所谓 Agent 其实就是爬虫。
“刮削”一词的来源应该是 scraping,对应 Emby 的 metadata scraper。依我看这个翻译实在是很糟糕,就像 socket 翻成套接字一样,毫无文化。
Metadata Agent 的相关设定十分迷惑,建议保持默认设置。默认设置下,其行为如下:
For the majority of apps, both VOBSUB and PGS subtitles will require the video to be transcoded to “burn in” the subtitles for streaming.
[Source]
考虑到 Web 和客户端的解码能力和性能,Plex 默认会使用 FFmpeg 对视频进行实时转码,再串流至播放终端。即使 “Disable video stream transcoding”,对于终端无法解码或是开启了“固化字幕”(burn-in subtitle)的情况,服务端仍然会调用 FFmpeg 进行转码。
当服务器过载时,Plex 会提示“该服务器没有足够性能用于转化视频”。
Plex 官方维护了一份 Plex NAS 官方兼容性列表(Plex NAS Compatibility List),可以从以下地址获取:
从列表中可以得知,ARM 架构的 NAS 服务器(无论是 QNAP 还是 Synology)一般不支持硬件解码,完全依赖 CPU 软解;采用 x86 或 x64 CPU 的 NAS 一般至少提供 1080P 规格的硬件加速能力。
Plex 的硬件解码属于 Plex Pass 会员的专属功能,必须以 $4.99(每月)或 $119.99(终身)的价格订阅 Plex Pass 通行证才可以享受。黑五(Black Friday)期间 Plex Pass 促销 25% OFF,约合人民币 610 即可购入。
推荐几个免费的流媒体网站吧。
]]>1 | :global ip [:resolve vpn.example.com] |
获取公网 IP。
1 | :global ip [([/tool/fetch "http://myip.dnsomatic.com/" output=user as-value]->"data")] |
获取网页 response body。
1 | :global result [([/tool/fetch "http://example.com" output=user as-value]->"data")] |
配置 NTP 服务器。
1 | /system ntp client |
正值双十一,写篇文章劝退一下想购买 QNAP 的读者。笔者自 2013 年起使用 NAS 和服务器产品,于 2019 年至今依次购入了 3 台 amd64 和 arm64 架构的 QNAP NAS。
QTS 系统应用商店内的 App 资源极其少,且某些 App 的版本远远落后于官方版本。因此用户不得不从软件厂商或第三方应用商店下载未经 QNAP 签名的安装包 (.qpkg
)。
QNAP 最新版本固件为 QTS 5.0 系列,该固件与 ZeroTier、qBittorrent 等大量 App 不兼容,并会在升级后自动禁用相关 App。如此重大的系统功能变更却未在固件更新页面给予任何警告,说明 QNAP 对终端用户的使用体验毫无责任感。
成品 NAS(如 Synology 和 QNAP)相对于 DIY 方案,唯一的优势在于易用性 (Usability),让小白也能从搭建、管理私有云。但 QTS 的本地化 (i18n) 相较于群晖做的很差,技术名词翻译生硬,以至于英文版 Web UI 比中文版更加直观。
根据官方新闻稿,QTS 5.0 于 2021 年 10 月 4 日推出,主要内容为更新 Linux 内核,通过 QVPN 3.0 提供 WireGuard 界面。截至 2023 年 9 月,QVPN 3 仅支持基于 x86 的型号,或者特定 arm 型号(TS-133/TS-233/TS-433/TS-435XeU)。
QNAP 所发布的移动端 App 可通过以下链接访问。只需看看各个 App 的评分和评论就知道 QNAP 的移动端适配与用户体验是多么的糟糕。
QuMagie 新版本已经移除了相册备份功能,变成了纯粹的相册浏览器。欢迎观看评论区小剧场。
QTS Web API 的接口设计不仅安全性低,且传输时夹带了大量冗余信息。例如 QuMagie、QFile 等 API 仅仅使用 URL 参数里的 sid
字段来鉴权。通过浏览器调试工具可以发现,仅仅登录到 QTS Web UI 就需要发送几十个请求,且每个接口返回值被包裹在一大串 XML 格式的设备信息里。考虑到国内家庭宽带的网络质量,远程访问 NAS 的用户体验简直是灾难。
当下 iOS 和 Android 在存储高质量图像和视频时,会优先采用 HEIF (High Efficiency Image Format) 和 HEVC (High Efficiency Video Coding) 编码格式。如需在 QNAP App 上预览,必须通过 QNAP Software Store 购买价值 $12 的 CAYIN MediaSign Player Plus License。该授权信息绑定至设备序列号而非账号,无法转移。
当然,这也不能全怪 QNAP,毕竟 HEVC 确实是需要专利授权的。不过,不用 QuMagie 和 QPhotos 对生活影响也不大,毕竟照片拍完基本就不会再看了。
群晖的 Synology Drive App 提供了类似公有云网盘的界面,配合 Synology Office 实现协同办公。其产品定位类似 Google Drive,提供客户端和网页端,可以在线编辑、预览数据。
QNAP 没有网盘应用,其名为 QSync 的产品提供了类似 DropBox 的文件同步功能,但却有着很大的局限性:
.Qsync
隐藏目录内,默认情况下无法通过 SMB 直接访问。只可以通过 File Station 间接访问 QSync 目录,没有单独的 Web 界面,也不能实现协同办公。QNAP 提供了名为 Hybrid Backup Sync (HBS) 的文件同步工具,支持“本地-本地”、“NAS-NAS”和“本地-公有云”的数据同步与备份。实际使用发现,对于 Two-way Sync 双向同步作业,HBS 3 无法识别目录重命名操作,因而会删除原有目录,并重新传输目录内容,非常愚蠢。
HBS 3 的“NAS-NAS”间数据同步使用名为 Real-time Remote Replication (RTRR) 的服务,基于 TCP 8899 进行文件传输,支持在线压缩、速率控制和 ACL。然而在广域网(WAN)下,其传输性能极易因链路抖动伴随的丢包而遭受损失,传输速率甚至不如使用公有云的对象存储服务进行文件中转。
总的来说,QNAP HBS3 还不如 rclone。
看到这里你一定以为我恰了群晖的饭。
给大家看看群晖 Synology 于 2022 年 11 月最新发布的售价 $620(约 ¥4400)的 DS923+ 是个什么乐色:
2022 年 6 月发布的售价 $699(约 ¥5000)的 DS1522+ 采用了相同的 CPU,内存升级为 8G,网口升级为 4 个,但依然舍不得加入原生万兆或 2.5G 支持。
再看看两年前发布的 $170(约 ¥1200)的 DS220j:
以及 $300(约 ¥2780)DS220+:
看看群晖 2023 年新发布的 $299.99(约 ¥2800)的 DS224+:
根据 V2EX@chowdpa02k413 的使用心得,绿联 NAS 的系统 UGOS 也是个大坑。以下是他的文章:
当然,事实并非如此。只需要购买搭载 CP2102N 和 CH340 芯片的 USB-TTL 线即可。依次连接 GND、RXD 和 TXD,无需连接 VCC。
Serial 参数如下
如有需要,也可以根据图纸 DIY 一根 AP-CBL-SER。
]]>耗时约两天来熟悉 macOS 平台的快捷键和操作风格,已经可以做到在 macOS 和 RDP 远程 Windows 之间无缝切换键位。Command + C
与 Control + C
语义区分的设计确实很不错,在 terminal 环境下复制文本时尤其方便。
MacBook Pro 14” 搭载了环境光传感器,可以根据外部光源强度自动调节键盘背光和屏幕亮度,且键盘背光可以设置延时熄灭。
部分 App 例如 OneDrive、微信、QQ 等会常驻 menu bar。当 menu bar 图标过多时,会被刘海遮住,且无法交互。虽然可以通过 Dozer 或 Bartender 整理或隐藏部分图标,但效果并不理想。
50% 亮度浏览网页和 PDF 近三小时,电池消耗 25%。也就是说满电状态下可以支撑一整个白天的办公时间。
使用 18W、20W、65W PD 协议的电源搭配 USB-C 或 Magsafe 3 磁吸线或均可为其充电,为移动办公场景提供了无限续航。
如果不愿忍受以杀猪价出售的 Apple 官方配件,也可以考虑选购几十块钱的 100W Type-C 数据线搭配第三方 PD 充电头进行充电,相对还是比较良心了。官方的 67W 和 96W 充电器又大又笨重,价格还是市面上 PD 协议 65W 充电头的 2~3 倍。唯独 M1 Max 用户可能不得不选购官方 140W USB-C 电源以获得最大性能。
作为一个 Android 用户,从此出门只需要带上一根 C-C 线和 PD 充电头,还是挺香的。
为了节约成本,在中国发售的 MacBook 使用两孔国标插脚,导致电脑金属外壳产生静电。推特简中圈有一篇关于 MacBook 静电很知名的推文描述了未接地处理的 MacBook 在特定环境下可能对人体产生伤害。苹果适配器的插脚是可更换的,可以从网上购买适用于澳洲的三孔插脚(形状与国标三孔一致),或者国标三孔电源延长线使用。
MacBook M1 Pro 的 200GB/s LPDDR5-6400 内存配合 macOS 激进的 Swap 策略和约 5GB/s 的 SSD,使得 16GB 丐版足以应付除影视制作以外的需求。
在预算允许的范围内,建议升级至更大内存。毕竟 MacBook 的主板高度集成化,无法自由更换内存和 SSD。
在前台运行 QQ、微信、Telegram、Teams、KeePassXC、Notion,Chrome 打开约 40 个 tabs 并开启 25 个插件,其中 uBlocks Origin 加载了大量规则,内存占用约 16GB,未使用 Swap。
配合 Steam Link,我们能以毫秒级的延迟在局域网内串流运行于 Windows 上的游戏。能感受到轻微的操作延迟,但对于非 FPS 类游戏来说足够了。
Steam 启动器当前尚未适配 Apple Silicon,因此页面滚动时有明显的钝感。
Apple Silicon 已经发布了近 2 年,软件生态仍然不太乐观。虽然 Mac App Store (MAS) 渠道可以下载 iPad/iPhone 版 App,但绝大部分应用并未对桌面使用进行适配。出于开发者自身原因,很多常用应用也并未在 MAS 上线,例如 Chrome、Firefox 和网易云音乐等。
所幸的是,一些生产力工具,例如 Jetbrains、VSCode、Zotero、Adobe、FFmpeg 都已经适配了 Apple Silicon 芯片,无需 Resotta 2 转译即可运行,对电池续航很友好。
基于苹果用户“人傻钱多”的用户画像,MAS 和第三方软件渠道存在大量付费但用户体验一般的应用。而往往存在更好的开源、免费替代品。这里举一些例子:
airport
和 Wireless DiagnosticsCommand + Shift + 4
和 Command + Shift + 5
在这里可以看到一些已经提供原生 Apple Silicon ARM 架构支持的软件列表。
Microsoft RDP Client 尚未支持 UDP 传输,因此 RDP 操作体验相比 Windows 平台上还是差了一丁点。
Terminal 默认字体为 SF Mono Regular 11,在 XDR Display 下的显示效果极为优雅。macOS Monterey 集成了多种 shell 环境,默认使用 zsh,搭配 zsh-syntax-highlighting 插件效果极佳。
Homebrew 则是必备的 macOS 包管理器了,用来安装一些 Linux 下的工具和开发环境都很方便。
峰值亮度 1600 nits 的 120Hz XDR 显示器搭配位于键盘左右侧的双扬声器带来的 Spatial Audio 能提供身临其境的观影体验。在 YouTube 上观看 LG 发布的 4K/8K@60FPS HDR 资源,画面细节与色彩让人仿佛在观看位于眼前的实物。
不幸的是,因为不支持基于硬件的 DRM,Firefox 和 Chrome 无法在此平台上观看 Netflix 和 Disney+ 等流媒体平台。macOS 自带的 Safari 则可以正常观看。
Apple 原厂非人为故障有限保修为 1 年。我选择额外加价购买了 3 年的 AppleCare+,因为较薄的屏幕很容易因为合盖时键盘上有颗粒物而破碎,其 Type-C 接口频繁插拔也容易松动。音响位于键盘左右两侧,很容易进液。
AppleCare+ 提供每 12 个月内两次意外维修,且覆盖机器本体和包装内附带配件,即MagSafe 3 磁吸线和充电头。尽管 AppleCare+ 有一定的免赔额,考虑到 MacBook 主板芯片的高度集成化和 XDR 显示屏,还是有必要购买这份意外保的。
开启了 Time Machine,每小时自动备份到 NAS。配置流程挺傻瓜的,选择备份目的地(外接硬盘或 SMB 共享)即可。支持备份至多个位置,例如同时备份至 NAS 和 USB 外接硬盘。
BackBlaze Backup 特点是联网即备份,但在上传带宽有限的环境下使用体验不佳。当然 BackBlaze B2 还是很不错的,相比 AWS S3 便宜很多,存储费用 $5/TB 每月。
1080P 的 FaceTime 摄像头确实清晰,通话音质也很高。拨打 FaceTime 视频时,上行带宽开销(码率)约为 2.5Mbps,无论画质、音质、应用性能还是用户体验都能秒杀微信。
根据 Apple 技术支持确认,macOS Big Sur 和 Monterey 暂时不支持 VPN Split-tunnel,因此无法实现 VPN 分流。使用自建 WireGuard 和 OpenConnect 服务时需要调整相应配置。
Clash 和 V2Ray 等基于 Socks 协议的代理工具不受影响。
MacBook Pro 关机状态下触碰键盘任意键均会执行开机操作,我们可以借助 KeyboardCleanerTool 暂时冻结键盘输入。
]]>不同监管域的频段和传输功率限制不同,其中最为自由的是澳大利亚(AU)和美国(US)。macOS 会基于 802.11d 协议确定自己的所属监管域,只扫描合法的 Wi-Fi 信道,导致设备无法连接特定 AP。
要查看当前 SSID 的详细信息,按住 option
键并单击 Menu Bar 的 Wi-Fi 图标。
要查看周围所有 SSID 的详细信息,需要通过 airport
工具。为了获取 Country Code 和 BSSID,必须使用 root
权限执行扫描。
1 | 创建符号链接以方便后续使用 |
根据网上贴文,将 Security & Privacy - Location Services - System Services - Networking & Services
取消勾选,并重启,即可避免 macOS 被锁定至某个监管域。
经过测试,此方法可以避免 macOS 基于 Wi-Fi 和 BLE 信息来获取当前设备经纬度,锁在设备物理位置所处的监管域。但似乎 macOS 仍然会根据初次扫描的结果来决定一个监管域。
]]>以 mkcert
为例,为 example.com
创建证书:
1 | mkcert example.com |
得到 example.com.pem
(公钥)和 example.com-key.pem
(私钥)等两个文件,并提示会在 2024 年过期。
1 | Created a new certificate valid for the following names 📜 |
调用 openssl 包合并公钥私钥为单个 PKCS12 证书 example.com.p12
,导出密码可以不填写。
1 | openssl pkcs12 -export -clcerts -in example.com.pem -inkey example.com-key.pem -out example.com.p12 |
在 RDP 服务所在的电脑上,双击证书导入至 本地计算机 - 个人
存储区。随后,在证书的详细信息页面获取证书指纹(Fingerprint),也就是一串 SHA-1 哈希值。按下 Win + X
键,以管理员身份运行 Powershell,并输入下列命令以指定 RDP 证书。
1 | wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="<证书指纹>" |
再使用 RDP 客户端建立连接,即可看到 RDP 服务已经应用指定的证书了。
]]>tl;dr: 仅部分国行旗舰机如小米数字、小米 Mix 系列可以使用 Google Wallet 进行 NFC 支付。
注意:Google Pay 应用现已更名为 Google Wallet。在过去 10 年里 Google 多次修改了其支付应用名称,涉及 Google Pay、Google Wallet 和 Android Pay。
众所周知,中国特供版安卓系统有别于 Android,进行了彻底的本地化改造,如 Google 框架被阉割、FCM (Firebase Cloud Messaging)[^1] 服务被限制。网上也有很多误导性的言论,鼓吹一加 (OnePlus) 或者刷 MIUI EEA/Global 固件。
国行安卓手机的 Google 服务现状如下:
注意:如果你的系统不自带 Google 服务框架,那么即使手动安装成功,也未必能启动 Google Wallet 的 NFC 支付。
FCM 推送服务 (mtalk.google.com
) 在中国大陆处于堪用状态,其域名 DNS 解析并没有被污染,但解析到的服务器位于台湾 Google Cloud,而中国大陆的国际互联网链路质量很差,以至于大部分国产手机厂商选择禁用或限制 FCM 服务来节约电量。
经过亲身实践,在 MIUI 上唯一的解决方案是使用下列 adb 命令禁用 MIUI 的电源管理功能 [^2]。操作后,电量消耗会比往常稍微大一些,但是海外应用如 Gmail、Instagram、YouTube 和 Twitter (X) 均可以正常接收推送。如果你是一个全天候开启 VPN 的用户,那么耗电量的增加可以忽略不计。
1 | adb shell pm disable-user com.miui.powerkeeper |
注意:此方法可能不适用于小米澎湃 OS。
经过实践,建行 Visa 双标卡、Visa 单标卡和中行 Master 单标卡均可以绑定至 Google Pay 用于 Play Store 购物或服务订购。
但是:Google Wallet 在中国大陆区域没有合作银行,所有中国大陆银行发行的信用卡和储蓄卡均不支持 Google Wallet 非接触式付款 (基于 NFC 的 Contactless Payment)。
幸运的是,海外高街银行、网络银行发行的储蓄卡和信用卡是可以绑定到 Google Wallet 并用于 NFC 付款的,例如 Starling,Curve,Chase 和 Revolut 等。所以国行 Android 在海外是可以使用 Google Wallet NFC 支付的,无需进行 root 等操作。
无法完成感应式付款设置
设置您的卡时出了问题。请重试或添加其他卡。
Starling 和 Lloyds(小马卡)虽然支持 Google Wallet,但仍有大量用户反映无法绑定的问题。根据评论区信息,请将手机显示语言修改为英文,然后再进行绑定。绑定成功后可以再改回中文使用。如果仍然无法绑定,建议搭配 Curve 套娃使用。
这里以 MIUI 13 为例,列出开启 Google Wallet 非接触式支付的必要条件。
设置 - 账号与同步
页面,开启 Google 基础服务
。设置 - 连接与共享 - 默认钱包
页面,设置为 使用 HCE 钱包
。设置 - 连接与共享 - 非接触付款
页面,将 默认付款应用
设置为 Google Pay
。以上条件缺一不可。
完成上述设定后,国行 Android 用户即可像高贵的 Apple 用户一样,在海外使用手机调用 Visa/Master 信用卡付款了。近期的使用体验中,Google Wallet 在 POS 机和自助结账机上表现良好,与实体银行卡支付体验一致。
Apple Pay 不支持绑定中国大陆发行的非银联卡。
以银联 Visa 卡或其他银联与其他支付网络合作的双标卡信息绑定 Apple Pay,最终绑定到您的设备上的设备卡片将为 62 开头的银联单标卡。
不幸的是,Apple Pay(中国)只能绑定国内银行卡的银联通道。不过,可以使用 Curve 来解决这个问题。Curve 是一家第三方结算机构,发行 Master 借记卡。用户需要将自己的 Visa/Master 储蓄卡或信用卡绑定在 Curve 上,直接使用 Curve 卡片进行消费。此时只需要将 Curve 卡片添加至 Apple Pay,即可在线下使用 NFC 支付。
[^1]: FCM 的前身是 Google Cloud Messaging (GCM),已经在 2018 年弃用。早期有关 Android 推送服务的文章会使用 GCM。
[^2]: 为广告而生,从使用到干掉大陆版 MIUI
[^3]: https://discussionschinese.apple.com/thread/253247136
刷小红书时看到一条使用虚假护照信息进行诈骗的帖子。评论区有网友指出了机读码对应的证件持有人姓名,虽然没有给出具体思路,但考虑到中国人姓名字符集的多样性,不难猜出这是某种国标汉字编码到 ASCII 字符的映射。
如图所示,护照资料页下方的两行黑色 ASCII 字符串即为机读码 (Machine Readable Zone, MRZ)。其中位于第二行后半部分的、长度为 4 的整数倍的英文字符串是经过编码后的持有人姓名,最多可以储存三个汉字。将汉字的 GB2132 的每个 byte 的两位以十六进制分别映射到字母表中,即可获得对应机读码字符串。例如:"张" -> "\xd5\xc5" (GB2312) -> [d, 5, c, 5] (hex) -> [14, 6, 13, 6] (10) -> NFMF (MRZ)
。
可以通过下面的 Python 代码实现汉字与机读码互转。
1 | import re |
1980 年,中国发布了第一个汉字编码标准,也即 GB2312 ,全称 《信息交换用汉字编码字符集·基本集》,通常简称 GB (“国标”汉语拼音首字母), 共收录了 6763 个常用的汉字和字符,此标准于次年5月实施,它满足了日常 99% 汉字的使用需求。
由于有些汉字是在 GB2312 标准发布之后才简化的,还有一些人名、繁体字、日语和朝鲜语中的汉字也没有包括在内,所以,在 GB2312 的基础上添加了这部分字符,就形成了 GBK ,全称 《汉字内码扩展规范》,共收录了两万多个汉字和字符,它完全兼容 GB2312。
GBK 于 1995 年发布,不过它只是 “技术规范指导性文件”,并不属于国家标准。GB18030 全称《信息技术 中文编码字符集》 ,共收录七万多个汉字和字符, 它在 GBK 的基础上增加了中日韩语中的汉字 和 少数名族的文字及字符,完全兼容 GB2312,基本兼容 GBK。
查询字符编码时意外地发现 GBK 和 GB18030 对于 GB2312 完全兼容,因此上文给出的 Python 代码很不严谨,护照可能使用了 GB18030 作为机读码编码。
]]>US
– Restricted Regulatory Domain – USJP
– Restricted Regulatory Domain – JapanIL
– Restricted Regulatory Domain – IsraelRW
or UNRST
– Rest of the World (Unrestricted)echo -n "<CC>-<SN>" | sha1sum | tr -d " -"
来计算 CCODE 后部分的哈希值。a, e, i, o, u
a
may only be followed by an e
.e
may only be followed by an a
or an i
.i
may not be followed by another i
.o
may only be followed by an i
or a u
.u
may only be followed by an a
.问:对于给定的长度 $n$,存在多少种不同的字符串排列?
根据题意可以绘出一个有向图。
计算得出各节点的出度和入度。
1 | // outdegree |
1 | // indegree |
1, 2, 5
时答案分别为 5, 10, 68
。因为结果需要对大素数取模,而数据取值范围并不大,所以说明答案呈指数级增长。笔试时很不幸地抽中这道 hard 难度的 DP 题,没能写出来。事后发现当作模拟题来写其实也行,从 $n=1$ 的状态向上依次计算即可。
1 | def countVowelPermutation(self, n: int) -> int: |
至于 DP 的标准解法,关键在于得出状态转移方程。从前序状态的值计算得到当前状态值。
1 | // https://github.com/grandyang/leetcode/issues/1220 |
问:源点经过任意次位移,是否有可能到达目标点?
递归搜索的思路很简单,但会因为递归次数过多而栈溢出或因为搜索空间过大而超时。
1 | bool reachingPoints(int sx, int sy, int tx, int ty) { |
根据点的状态转移关系,我们可以将目标点尽量逼近源点,然后只需对剩下一个轴坐标做判断即可。
1 | bool reachingPoints(int sx, int sy, int tx, int ty) { |
严格按照本文说明,仅需 15 分钟即可完成所有操作。
首先从 Cloudflare/Cloudflared 下载编译好的二进制,解压至本地。
1 | # 1. 登录到账号 |
如果你没有 Cloudflare 账号,或者 Cloudflare 账号没有域名,则可以通过下方命令进行测试,会自动生成一个临时的 URL 用于访问。
1 | .\cloudflared.exe tunnel --url rdp://127.0.0.1:3389 |
这里的 --url
参数为 service URL,用于指定要代理的服务,格式为 <协议头>://<IP>:<端口>
。一些样例如下:
1 | # RDP |
Cloudflare Tunnel 可以用于中转任意 TCP 服务,也可以用于映射至内网其他服务,具体细节可以参考官方文档。暂时不支持 UDP 服务。
客户端侧比较简单,下载编译好的二进制后
1 | .\cloudflared.exe access rdp --hostname <域名> --url localhost:<映射至本地的端口> |
随后,在 RDP 客户端中填写 localhost:<本地端口>
即可访问到远程桌面了。
注意:如果此处端口使用 3389
,Windows 自带的 RDP 客户端会阻止连接。我们可以
127.0.0.2
,它其实是 127.0.0.1
的另一个别名。我们可以将其注册为系统服务于后台运行,免去手动运行 daemon 的烦恼。参考此页面。
注册为系统服务
1 | .\cloudflared.exe service install |
C:\Users\%USERNAME%\.cloudflared\
目录下有一个形如 6ff42ae2-765d-4adf-8112-31c55c1551ef.json
的文件,为刚刚所创建的隧道的鉴权信息。在同目录下创建 config.yaml
,内容如下
1 | # 隧道的 UUID |
配置 DNS 记录(需要使用自己的域名)
1 | .\cloudflared.exe tunnel route dns <NAME> <DOMAIN> |
修改注册表(regedit.exe
),配置启动参数:在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
找到 Cloudflared
,将 ImagePath
修改为 <cloudflared.exe 绝对路径> --config=<YAML 配置文件绝对路径> tunnel run
。
通过命令行或任务管理器重启 Cloudflared 服务即可完成。
1 | # 需要管理员权限 |
只需将 ImagePath
修改为 <cloudflared.exe 绝对路径> access rdp --hostname <域名> --url localhost:<映射至本地的端口>
,然后重启 cloudflared
服务。
mkcert 生成自签名的证书 host.pem
和 host-key.pem
改成同样的名字 host.pem
和 host.key
,使用 Windows 自带的 certutil
,合并为 host.pfx
文件。
1 | certutil -mergepfx host.pem host.pfx |
将 host.pfx
导入至 certmgr
的 Personal 目录。复制该证书的 SHA-1 指纹(thumbnail),使用 Windows 自带的 rdpsign
进行签名。
1 | rdpsign /sha256 <sha1 hash> test.rdp |
RemoteApp 是基于 Windows RDP 的增强功能,将远端的程序以本地程序的形式显示,效果和 VMware 的 Unity Mode 相似。
从这里下载 RemoteApp Tool,添加本地程序(例如 Chrome, VMWare 等),并为之生成 .rdp
文件即可。全程傻瓜化操作,十分简单。注意 hostname 和端口需要修改为前文对应的客户端侧地址。
播放 YouTube 视频、打字都很流畅。快速滚动页面时可能会有一些掉帧;快速拖动窗口会存在少量拖影和延迟。
以 RemoteApp 形式运行应用时,部分 pop-up 菜单的显示效果不理想,可能会出现短暂的黑色或阴影部分。
RDP 服务端优化:修改组策略(gpedit.msc
),找到 计算机配置 -> 管理模板 -> Windows 组件 -> 远程桌面服务 -> 远程桌面会话主机 -> 远程会话环境
。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations
路径下新建 DWMFRAMEINTERVAL
,值设为十进制 15
。在 1080p 分辨率下,修改前测试为 22 fps,修改后测试为 33 fps,提升 50%。RDP 客户端优化
从本地到 Cloudflare DC 到远端计算机的 RTT 约为 60 ms
。经过上述优化,在 16-bit 色彩、1080p 分辨率和自动画质的设置下,流畅性与本机应用近乎一致。
最后,为什么使用 RDP 而非 VNC 呢?
正如前面提到的 VNC 协议是基于像素的。尽管这带来了极大的灵活性,可以显示任何类型的桌面,但它的效率往往不如那些更好地理解底层图形布局(例如: X11)或桌面(例如:RDP)的解决方案。这些协议以更简单的形式(例如:打开窗口)发送图形原语或高级命令,而 VNC 的 RFB 协议尽管支持压缩但只能是发送原始像素数据。
Oracle Cloud 是由甲骨文驱动的公有云产品,其 Free Tier 计划包含了 20GB 的对象存储服务。由于其可用区位于海外,跨境访问对象存储时用户体验很不理想。我们可以使用 Cloudflare Workers 搭建反向代理,并配合缓存以节省开销。
直通模式下,Cloudflare Workers 直接转发请求和响应。
1 | const REGION = ""; |
缓存模式下,先使用 Cache API 将请求缓存于 Cloudflare 的 CDN ,再返回响应正文。
1 | const REGION = ""; |
首先扫盲一下什么是 NAS:NAS 即 Network Attached Storage,严格来说是网络附加存储服务器,通过网络提供 NFS, SMB/CIFS 和 HTTP (WebDAV/S3) 文件读写服务。但在当前语境下,咱们聊的 NAS 指的是集 BT 下载、DLNA 等流媒体服务、远程文件访问、VPN 和 Docker(你最好有)、KVM 虚拟化为一体、并且有原厂售后的小型家用服务器。严格来说就是群晖 (Synology) 和威联通 (QNAP) 这两家的产品。华硕、铁威马、Orico 家的东西不在考虑范围内。附上两张 NAS 阵营表情(转载自网络),娱乐一下。
群晖 (Synology) 和威联通 (QNAP) 总部都位于台湾,但前者的本地化 (localization) 做的明显比后者好,无论是帮助文档、软件的 UI/UX 还是云中转隧道服务。特别需要注意的是,群晖在大陆的销售活动实施控价销售,在非官方促销活动时,从淘宝、天猫和京东等平台查看的售价要高于实际经销商售价的几百至几千不等。不少经销商会选择在闲鱼发布低价商品吸引客群,并引流到淘宝店。
群晖在亚马逊美国(美亚)的价格比国内低 20-30%,即使算上关税和运费也比国内目录价便宜几百上千。但需要注意的是海淘群晖无法在大陆享受保修服务,部分淘宝商家可以代为邮寄至香港保修。不得不说群晖真是 3C 电子的一朵奇葩,产品从上架到下架 (End of Sale),绝不降价(目录价)。如果想入正版白群晖,要么忍受官方直营店的高价,要么冒着一定风险去闲鱼找代理商。
威联通的研发部门位于台湾,仅生产、售前、售后服务位于上海。其产品本地化做的很差,UI/UE 设计技术和品味处于落后于当前世界 4-5 年的水平。并且,近几年来 QNAP 的操作系统 QTS 被多次发现安全漏洞,且出现了大规模的在野利用(备用链接) 如 Deadbolt 和 QLocker,导致受害者的数据丢失、设备沦为挖矿工具。不过,这并不意味着群晖就很安全。仅 2021 年内,群晖被发现了 30 多个中、高危漏洞。铭记:没有绝对安全的系统。
首先最重要的是硬盘插槽 (Bay) 数量
其次是 CPU 架构
一般仅纯粹作为文件存储用途(SMB、iSCSI 和 SAN)的低端家用型号和企业机架型号会采用 ARM 架构的 CPU。
对于预算极度有限的用户,我推荐威联通 (QNAP) 的这两款:
不过本着买新不买旧的原则,手头略有富余的消费者还可以考虑威联通的 TS-230 (RTD1296@2G DDR4, 1300 元左右) 和群晖的 DS220J (RTD1296@512M DDR4, 1100 元左右),两者硬件配置除内存外基本一致。不过,在 2022 年使用 512MB 内存的产品是一种怎样的痛苦体验呢?
不建议购买群晖、威联通的机架式 (Rack Mount) NAS,原因有几点
最重要的一点往往被大家忽略:搭建家庭 NAS 最大的支出是硬盘而非 NAS 本身。截止至 2024 年,全新店保或国行联保的 >= 8TB 机械盘仍然位于 100~120/TB 的价格区间。
希捷酷狼 (Seagate Ironwolf) 和西部数据红盘 (WD Red) 都属于高价格、高利润的垃圾,切勿购买。奸商们为了利润会各种坑蒙拐骗劝你购买这两种 NAS 专用盘。
Backblaze 是一家云存储服务商,每季度会发布其自有数据中心的硬盘故障统计。由于其使用的硬盘数量和种类都足够大,对于 NAS 用户来说有很大的参考价值。2021 年的 Backblaze 硬盘故障率报告已经发布,如下图所示。可以说在大容量 HDD 的品质上,希捷 (Seagate) 惨不忍睹。日立(HGST)已经被西部数据 (Western Digital, WD) 收购了,而 WD Ultrastar 系列数据中心企业盘似乎全部出自原 HGST 产线,品控相当不错。
我个人推荐购买 WD Ultrastar 和希捷银河 (Seagate Exos) 这两个系列的硬盘,国行经销商(非京东、淘宝官方店)的购买价格约为 110-130 元/TB。目前自用的多块 HC320 8T (HUS728T8TALE6L4) 运行两年来未出现过任何问题。考虑到 Backblaze 的数据,咱还是别买希捷了吧。
新浪微博上有极个别“摄影博主”以高于市场价数百元的价格出售“绝对好价”的硬盘和NAS。在此提醒各位:不要相信“好心”博主的报价。
在此列举(仅列举,非推荐)几家圈内知名代理商的淘宝店。这几家店价格基本一致,哪家售后好买哪家就行。
目前全新国行 HC320 8TB 价格约为 950 元;二手矿盘 HC550 16T 价格约为 900 元。
群晖的 DSM 和威联通的 QTS 均提供了 SSD 加速(又名为 SSD Cache、SSD 快取),将一块或多块 SSD 作为缓存盘组为 RAID 1(读或读写缓存)或 RAID 0(读缓存),加快其他机械硬盘的读写。从安全和厂家的技术实力的角度来看,切勿开启“读写缓存”。一旦 SSD 读写缓存损坏,将导致所开启了写入缓存的机械硬盘数据丢失(无法读取),且无法恢复。
?
,可见开发过程十分粗糙。目前已经放弃,转用 rclone 和 OneDrive。买 NAS 是一个从满足到受气的过程:收到包裹后满心欢喜,看什么都觉得新鲜;使用一段时间后觉得索然无味,还不如用回 OneDrive;到了后期遇到各种 Bug 和反人类的 UI/UE 设计,以 ticket 为武器向售后发泄怒火。
家庭用户买 NAS,无非为了以下几点需求,但都有对应的替代品
如果你有一定技术能力,搭建一台运行 VMware ESXi/PVE 的服务器是最理想的。当然,群晖和威联通卖的就是成套解决方案,对于不那么折腾、不那么挑剔的一般家庭用户(非设计师、非程序员)来说,成品 NAS 产品最适合不过了。
]]>RouterOS 7.1 RC 4
192.168.88.0/24
1 | ip/dns/static/add name=music.163.com address=59.111.160.195 disabled=no |
Useful RegEx patterns:
.*[^\d](\d+\.\d+\.\d+\.\d+/\d+).*
add address=$1 disabled=no list=netease
1 | ip/firewall/address-list/ |
1 | ip/firewall/mangle/add chain=prerouting action=mark-routing new-routing-mark=to-vpn passthrough=yes dst-address=!192.168.88.0/24 dst-address-type=!local dst-address-list=netease in-interface=bridge log=no log-prefix="" |
AP-XX
, AP-1XX
, AP-2XX
and AP-3XX
, since the newer models are unified models (including AP-203X
, AP-365
, AP-367
and latest SKUs).According to the naming schema of Aruba, the CAP stands for Campus AP that used for centralized management, and the IAP stands for Instant AP, which has the ability to self-manage by creating an ad-hoc cluster.
Aruba said that the regulation domain and the IAP/CAP model was constant when an AP was manufactured, however, it’s a trick on the software layer.
Thanks to @shalzz who provide a copy of the Aruba Instant sourcecode, so that we have the opportunity to go deep into.
Inside of the aruba-ap-310-master\sap\flash\ap60_flash_common.h
, you can find the following snippet.
1 | /* country-code = mfg offset + 512 bytes */ |
Now the answer is clear, the format of CCODE is
1 | CCODE-<Regulatory Domain>-<SHA1(<Regulatory Domain>-<Serial Number>)> |
You can find a CCODE calculator here: Aruba Country Code (CCODE) Generator.
Here is the list of regulatory domain.
US
- Restricted Regulatory Domain - USJP
- Restricted Regulatory Domain - JapanIL
- Restricted Regulatory Domain - IsraelRW
or UNRST
- Rest of the World (Unrestricted)Let’s move on to flash the CCODE.
<ENTER>
to interrupt the boot process.proginv system ccode <YOUR_CCODE>
.invent -w
.dhcp
, or you can use setenv ipaddr <ipaddr>
and setenv netmask <netmaskip>
to assign a valid IP address manually.setenv serverip [TFTP_Server]
.upgrade os 0 ArubaInstant_xxx_6.x.x.x-4.x.x.x_5xxxx
, the file must exists on the TFTP directory. To change the boot partition, see here. By default, partition 0 is the boot partition, while partition 1 is the recovery partition.upgrade os 1 ArubaInstant_xxx_6.x.x.x-4.x.x.x_5xxxx
.factory_reset
.saveenv
.reset
.See more AP boot commands at Managing AP Console Settings.
Aruba used host their firmwares on
1 | http://d2vxf1j0rhr3p0.cloudfront.net/fwfiles/[firmware_filename] |
but was frozen since Feb 2022 due to the migration of Aruba Support Portal (ASP). The new URL is
1 | http://common.cloud.hpe.com/ccssvc/ccs-system-firmware-registry/IAP/[firmware_filename] |
You may also interested in the following articles:
今日在对文件进行归档操作时,NAS 警告 “The server is busy or the network is disconnected”.
刷新页面后,提示 Connection reset
,而在此期间文件可以通过 Samba 正常访问,通过 SSH 查看到 CPU 与 IO 的各项指标都正常,执行 dmesg
查看内核消息缓冲区,也未发现异常情况。通过 vi
查看各应用日志时,终端出现 write error in swap file
报错,但检查发现 swap
分区基本是空的,内存也空闲 10G 以上,不该出现此错误。
1 | [~] # uptime |
通过 CLI 执行 reboot
重启服务器后,访问 File Station 提示 System Message: network disconnected / Timeout
。手动断开 HybridMount 中的云服务挂载后,在执行文件系统检查(基于 e2fsck
)时发生错误 “Unmounting volume failed”。
通过报错信息查询到一篇帮助文档:Examination Failed(Cannot unmount disk) Error,通过 CLI 进行文件系统检查的指令顺序摘录如下:
1 | 停止各项应用服务 |
执行 umount
操作时,出现 error writing /etc/mtab.tmp: No space left on device
报错。由于存储池当前剩余空间超过 1TB,因此问题应该出现在系统挂载点上。使用 df
命令查看各挂载文件系统的使用状态,发现根目录使用率 100%。
1 | [admin@nonPointer ~]# df -h |
参考 What do I do when my root filesystem is full?,使用 du
查看 /
下各目录的使用情况。
1 | [~] # sudo du -hsx /* |
发现问题所在:名为 PT
的目录应该位于 /share/PT
路径,而不该出现在 /
。查看后发现目录存放有部分今天通过 QBittorrent 移动的数据文件,应该是对 Qbittorrent 的文件进行分类存放时,目标路径填写了 /PT
而非 /share/PT
,导致 rootfs 被填满。手动删除目录后重启系统,发现 /share/PT
路径依然存在,推测原因是没有从 Qbittorrent WebUI 移除对应种子。手动移除后再次重启系统,成功完成文件系统检查,未见系统异常。至此问题得到解决,通过此事也发现 QTS 的一项安全性隐患:所有 QNAP App 都以 admin
(在 QTS 中相当于 root
)的最高权限运行。在此也警告各位用户:谨慎安装由第三方分发的 QPKG 应用,把控好供应链安全。
Environment
- 前端:React + Antd
- 后端:PHP + MySQL
appleboy/scp-action@master
,就能将 Node.js 项目的 dist
目录打包后再上传至生产环境,节约了不少时间。值得注意的是,当 source path 填写为 dist/
时,文件将被部署到远程目录的 path/dist/
下。在 scp
中可以使用 dist/*
来解决这个问题,在此插件中可以指定 strip_components: 1
来去除前导路径元素(推荐),或者在 nginx 中修改根目录至 wwwroot/dist
。不建议修改 nginx 的 wwwroot
配置,这将导致 lnmp 无法更新 Let’s Encrypt 证书(也可以在 nginx 中为 .well-known
路径单独指定根目录)。Access-Control-Allow-Origin: *
,但 Fetch 请求不允许这种掩耳盗铃的操作。解决办法是动态指定参数或者将前端域名写死。OPTIONS
,因此需要设置 Access-Control-Allow-Methods: POST, GET, OPTIONS
。根据 Issue #251 · whatwg/fetch 的讨论中,当 Fetch 的 withCredentials = true
时(跨域请求携带目标域的 Cookies),此处不允许通配符,因此应当避免使用 Access-Control-Allow-Methods: *
。此规则同样也适用于 Access-Control-Allow-Methods
,因此应当手动声明后端允许的 request header,例如 form-data
。Access-Control-Allow-Credentials: true
,才能使后端接受前端跨域发送的 Cookies。set-cookie
(并非 http-only
),导致浏览器无法存储用户凭据。前端同学试了 axios 和 Webpack Proxy 也没有什么头绪。对此有两个临时解决方案:sessionId
直接塞在登录接口的 data
字段里回传给前端,然后手动设置 cookie(或者存储至 SessionStorage 中)。POST
的请求,浏览器自己会响应 set-cookie
的字段。类别
标记
作用域
https://example.com/path1/
目录的 Cookie 将不被发送目的地址为 https://example.com/path2/
的请求所携带)用途
限制
sessionStorage
localStorage
[^1]: 以上内容摘自 MDN Web Docs
[^2]: 浏览器同源策略 - MDN Web Docs
]]>总的来说,ERLite-3 洋垃圾相比 ER-X 有着非常高的性价比(见下表,数据来源),内置 DPI 深度包审计便于流控,且具有更高的大包吞吐性能。
Packets | ERLite-3 | ER-X |
---|---|---|
1518 bytes | 3 Gbps / 240,000 pps | 1 Gbps / 80,000 pps |
64 bytes | 490 Mbps / 730,000 pps | 957 Mbps / 1,400,000 pps |
sudo ./mkeosimg ER-e100.v1.xxxxxxx.tar
将下载的固件包转换至 .img
格式的磁盘镜像。dd
命令或 ImageUSB 等工具将镜像烧录至 U 盘。支持 802.11k 协议的无线接入点(AP)可以为运行 Windows 10 的设备提供邻区报告。邻区报告涵盖了邻区接入点信息,能够让客户端对其周围无线电环境有更好的认识。 Windows 10 利用此功能来缩短移动终端在漫游前扫描周边待漫游的目的接入点列表的时间。
支持 802.11v 协议的接入点现在可以引导 Windows 10 设备漫游至被认为能提供更好的 WLAN 链路质量的接入点。Windows 10 设备现在可以接受并响应 BSS 漫游管理帧,可以在支持 802.11v 的 WLAN 网络下改进链路质量。
快速 BSS 漫游减少了 Windows 10 设备在支持 802.11r 的网络下所需要的漫游时间。这里的时间减少得益于漫游时与先前的 AP 只需交换更少的数据帧。通过减少终端在接入点间漫游过程后进行数据传输前的等待,一些延迟敏感型的业务质量得到了提升,例如 Skype 通话。Windows 10 的快速 BSS 漫游当前仅支持位于 802.1X 身份认证的 WLAN 网络,而不支持预共享密钥(PSK)和开放型(Open)无线网络。
得益于 802.11k、802.11v 以及 802.11r 技术的结合,Windows 10 利用已有的行业标准来改善用户的 WLAN 漫游体验。VoIP 应用程序现在可以为移动中的用户提供更好的通话质量。
并非所有的 Windows 10 设备都支持 802.11k、802.11v 以及 802.11r。系统的硬件驱动必须支持这些特性能正常工作于 Windows 10。请与你的设备制造商联系以确认你的设备是否支持这些 WLAN 漫游特性。除了客户端一侧的支持,所处的 WLAN 网络(包括 AC 和 AP)必须也支持这些 WLAN 漫游特性。请与你的网络管理员一起确认这些功能是否被无线网络设备支持并已经被启用。
当 802.11r 在当前设备或 WLAN 上不被支持时,Windows 10 仍然提供粘滞密钥缓存(OKC)。
这三项特性都依赖于接入点侧的支持,否则将不可用。
本文翻译自 Fast Roaming with 802.11k, 802.11v, and 802.11r - Windows Drivers | Microsoft Docs
]]>团队协作是软件工程中最重要的部分,人们为提高协作效率开发了各种协同工具以及工作流(Workflow)。工作流是一系列工作过程的标准化描述,核心是人;协同工具则是对工作流的辅助,在特定的工作流下提高协作效率,作用于事物。实际过程中,很多开发者局限于对协作工具的使用,而忽视了编码流程的规范,反而导致协作工具成为了开发过程中的阻力,使用效果适得其反。例如,不及时更新 Issue 状态,或者将正在开发的 Axure RP 原型设计稿导出为文件而不是提供在线访问。
有些公司没有协同工作的概念,使用微信、QQ 等公共即时聊天工具作为沟通方式。这不仅为工作环境引入了外部的干扰(非工作内容),也带来了安全隐患(信息泄露、不可控因素)。电子邮件也曾是主流的内部沟通方式,因为其低时效性的特点,比较适合异步通讯(例如缺陷跟踪、事务通知),而不再适合节奏较快的工作环境。现在,企业微信、钉钉、Slack 等平台被广泛使用,解决了传统 IM 的一些缺陷,也引入了电子邮件的群发通知功能。尤其是其可作为 SaaS 以订阅方式提供,也可以进行私有化部署,比较灵活。
对于进行同一项工作且存在异地分支的团队,定期的电话会议是很有必要的。成员之间可以互相提供开发建议,统一工作进度和节奏。
代码审查(Code Review)是敏捷开发中很重要的一个部分,每位开发者所提交的代码都将被至少一位开发者进行审计,有效改善了代码质量以及潜在的安全隐患。除此之外,新手程序员能通过 Code Review 的讨论过程学习到一些开发技巧和项目结构,能够更快的融入团队。
在我看来,开发需求较紧张时,开发人员可能会放弃单元测试以及模糊测试,而试图将测试任务甩给 QA 团队甚至永久地搁置。尤其是当项目管理不接触具体开发工作,无法对开发周期做出准确估计时,为开发者下发“加班加点加新功能”的任务会造成非常严重的后果(较差的代码质量)。
为项目团队维护一份知识库还是挺重要的,不仅便于开发人员理解项目的系统架构,还有助于提高接口测试与沟通效率。
对于编写 API 开发文档,可以使用 Swagger、ApiDocJS 或是由阿里妈妈 MUX 团队出品的 RAP2,嫌麻烦也可以选择 Markdown 或者 Github Wiki(如果项目 Repo 位于 Github)。Swagger 和 RAP2 是非内联形式的独立文档系统,文档数据独立于项目代码,不限制 API 语言类型。ApiDocJS 则是一个内联文档系统(inline documentation),提供从代码注释自动生成静态文档的能力,受编程语言类型的限制。由于文档编写于代码注释,会对项目代码有影响。其所生成的静态页面可以单独部署至 Web 服务器或者进行本地访问。
知识库可以视项目大小选择 Github Wiki 或者 DokuWiki。Github Wiki 可以直接使用 Markdown 进行编写并通过 Git 管理,使用起来较方便,适合项目内小范围使用,但有局限性:只能为有此 Github repo 访问权限的用户提供访问。而 DokuWiki 作为一个轻型的 Wiki 系统,在权限管理上更加自由,允许匿名编辑和访问,也可以通过插件来对接 LDAP 进行集中认证,比较适合公司内部使用。诸如 Confluence 这样的文档协作解决方案也很不错,但是相对的,成本也很高。当然,相比于研发人员的工资,这些生产力工具还是值得企业去选购的。
“所见即所得”的开发模式只适合于 WordPress 这样抽象后的 CMS 表层设计。对于一个从零开发的具体产品来说,还是得有一套预定义的设计规范。包括但不限于:色彩搭配、字体样式、界面布局以及中英文混合排版规范。除此之外,编码规范也很重要,例如接口命名风格、RESTful API 样式以及代码缩进定义。在规范下协作,能很大程度上降低开发人员间的沟通成本,提高团队协作效率。
]]>Confluence 是由澳大利亚软件公司 Atlassian 出品的一款在线文档协作平台,提供跨平台的移动客户端,可以方便地与 Jira、Google Drive 等平台进行对接,形成一个完整的敏捷开发工作流,被广泛应用于公司内部知识库的构建。作为商用软件,其授权价格不菲,但以 10 美元的价格提供 10 用户的 Starter Package,支持本地部署或云服务,且提供持续一年的维护,对于小团队来说是个很不错的选择。
同类产品有 DokuWiki。作为一款开源免费的文档解决方案,相比于 Confluence 来说界面比较简陋,扩展性也没有那么强,适合仅做内部文档用途的场景。
Confluence 版本:6.15.8
1 | CPU Model : Intel(R) Xeon(R) E-2176M CPU @ 2.70GHz |
作为开发者,请支持正版软件!
1 | # 为二进制包添加可执行权限 |
输入字母 o
然后回车,继续安装。
1 | ... |
输入 1
并回车进行快速安装,或者输入 2
进行自定义安装以手动指定程序安装路径及数据存放目录。
1 | ... |
默认 HTTP 端口为 8090
,Tomcat 管理端口为 8000
。关于 Atlassian 产品的端口使用说明可以参考 Ports used by Atlassian。
1 | ... |
回车,继续安装。
1 | ... |
输入 n
,暂时不运行 Confluence 服务。
1 | Installation of Confluence 6.15.8 is complete |
当看到上述文字时,Confluence 服务已经安装完成了,接下来需要进行进一步配置与产品激活。
将下载得到的 atlassian-agent.jar
补丁文件上传至服务器的一个固定位置,演示时我将其放在了 /opt/atlassian
目录下。
1 | scp atlassian-agent.jar [USER]@[SERVER_HOSTNAME]:/opt/atlassian/ |
然后修改 Confluence 的启动环境变量文件(位于 Confluence 安装目录下的 bin/setenv.sh
),添加一行 CATALINA_OPTS="-javaagent:/opt/atlassian/atlassian-agent.jar ${CATALINA_OPTS}"
。
1 | ... |
随后将 MySQL JDBC 驱动上传至 Confluence 安装目录的 confluence/WEB-INF/lib/
路径下。
接下来,我们运行 Confluence 服务,并查看补丁是否安装成功。
1 | # 启动 Confluence 服务 |
当在日志中发现 agent working
字段时,即意味着补丁已经正确安装并运行。
1 | 29-Aug-2019 13:52:37.568 INFO |
接下来我们将对 Confluence 进行初始化配置。访问 http://[SERVER_IP]:8090/
进入安装向导,如果页面语言为英文,可以通过页面右上角下拉框进行切换。当进行至输入 License 步骤时,将页面上方格式为 XXXX-XXXX-XXXX-XXXX
的服务器 ID 复制,随后手动执行补丁以获取序列号。
1 | # 查看帮助信息 |
1 | # 生成 Confluence License |
将补丁生成的 License 拷贝,粘贴至页面,即可进行后续的数据库配置步骤。
The database collation utf8_general_ci
is not supported by Confluence. You need to use utf8_bin
.
Confluence 必须使用 utf8_bin
字符集的 MySQL 数据库,而 MySQL 默认数据库字符集为 utf8_general_ci
,可以通过以下命令解决。
1 | DROP DATABASE [DB_NAME] # 删除之前错误创建的数据库 |
新建页面模板的中文字符串显示乱码。
这是因为 MySQL 默认的字符集为 Latin1
,需要将其修改为 utf8
。修改 MySQL 配置文件如下,并重启 MySQL 服务即可解决。
1 | [mysqld] |
Your database must use READ-COMMITTED
as the default isolation level.
Confluence 要求使用 READ-COMMITTED
作为 MySQL 默认的事务隔离级别,修改 MySQL 配置文件如下并重启 MySQL 服务即可。
1 | [mysqld] |
[^1]: Confluence 安装及破解 - qinjj 的博客
https://www.qinjj.tech/2019/01/04/confluence%20install/
[^2]: Confluence 中文乱码解决思路和方法
http://moheqionglin.com/site/blogs/26/detail.html
思想理论对于编码实践有着极其重要的指导作用。
月初逛论坛时看到一条回复:
标题:前端的技术更新换代速度是不是有点快? - V2EX
@xuanbg:MVC 模式还是 76 年提出来的呢,前端的同学用上才几年。。。
大概十多年前,互联网还没有前端开发者这个概念。由于当时网站基本使用表格布局或 Flash,而不是如今的 DIV + CSS 的布局,前端开发工作基本由后端完成。许多站点通过将前端代码硬编码于后端代码,配合 iframe
和后端语言的 include
语句,构造标准的表格式单页。
Web 2.0 技术之后,UGC 内容逐渐成为主流,前端技术也不再局限于简单的表格布局,各种技术栈百花齐放,诞生了 jQuery、Dojo 等一系列开源 JavaScript 框架。CSS3 与 HTML5 标准的出现也极大地推动了前端技术栈的发展,人们开发出各种炫酷的交互动画,甚至可以通过 WebGL 实时渲染 3D 模型。Bootstrap 等前端 UI Kit 的出现则将前段开发者们从手写代码中拯救了出来,模块化的响应式布局成为主流,Web 前端页面的基本构建逐渐变得简易上手,由此也催生了一大批前端培训班。
在我看来,一个优秀的前端工程师除了掌握各种 Web 技术与开发框架之外,还需要具有一定的审美能力与设计理念。对于 to B 的产品可能不需要考虑太多用户体验上的需求,但是如果是面向普通用户,用户体验很大程度上影响了用户留存与活跃时间。
慢下来,提高代码质量。
没经验没能力的软件开发团队一开始就冲刺/加班加点地加新功能,几个月后就慢下来了,所有时间都在修 bug,没精力去加新功能。
—— 软件开发过程中,先慢下来,才能将来跑得更快
前期开发过程中缺少 Code Review 及自测等评估环节,加上一些不合理的产品设计,我们耗费了大量的时间在变更需求和寻找代码缺陷上。和一位曾在某一线手机厂商工作的朋友聊起工作流,其公司生产环境代码小版本一月一更,大版本甚至一年才发布一次。当然,处于开发期的项目迭代本就应该比维护期的项目快许多,但是如果不使用 CI/CD 以及自动化测试等解决方案,后期推进将变得非常困难。
预留数据审查中间件,做好安全措施。
如果发现一个产品在安全(包括但不限于权限管理)方便不讲究了,说明他们内部在为 KPI 赶进度了。因为安全领域是花费最大却看不到成果的地方。
—— Weibo@老毒师
2018 年是区块链的风口,但不知有多少交易所和私链因为代码缺陷所致的安全问题而崩盘,无论是运营者还是用户都损失惨重。但就目前看来,各个项目(除了互联网金融方向)的开发过程中仍然是业务线优先,安全、风控最后。在我们的项目初期,前端未考虑对用户做防呆设计以及数据预过滤,后端也基本未对接口数据做鉴权或合法性校验。作为一个暴露在公网的在线服务,是非常危险的。
产品需求一定要明确,做好任务进度可视化。
在前段时间的课设中,我们尝试应用了 Github Kanban 作为敏捷开发管理工具,对项目进度进行把控。作为一个辅助工具,它并不具有什么魔幻能力,但却能直观地掌控项目的功能粒度上的开发进度,优化需求下发流程。使用 IM(如微信、蓝信等即时聊天工具)及电子邮件作为需求下发方式的形式是一个没有缓冲区的 [生产者-消费者] 问题。通过引入看板作为缓冲区,开发者完成手头任务后即可查看后续需求,产品经理也无须为此在群里 at 全体成员,打断所有人正在处理的事情。这不仅可以避免开发人员工作时间不饱和,还有助于提升开发效率。
要想理解 WLAN 漫游技术,首先要区分 SSID、BSSID 与 ESSID。
CMCC
、ChinaNet
,会显示在客户端的 WLAN 列表中,用来表示不同的无线网络。在开始讲解 WLAN 漫游技术前,先引用 Cisco WLAN 漫游白皮书中的一句话[^2]:
Keep in mind that the client is always the one that decides to roam to a specific AP, and the WLC/AP cannot decide this for the client. The roaming event is initiated by the wireless client once it considers it should roam.
始终牢记:无线客户端才是决定 WLAN 漫游的主体,而无线接入点控制器、无线接入点则不是。仅当无线客户端认为有必要进行漫游时,漫游事件才会发生。
一般意义上的 WLAN 漫游架构无非以下几种形式
在本文中,我们将主要讲解由 802.11k/v/r/w 快速过渡漫游技术驱动的 AC + AP 组网架构的 WLAN 环境。
注意:以下部分内容原文节选、整理、翻译自思科《802.11 无线局域网漫游和思科统一无线网络快速安全漫游白皮书》及思科《Enterprise Mobility 8.1 Design Guide》[^3][^4]。
802.11k 辅助漫游技术允许 11k 兼容的无线客户端向当前关联 AP 请求可作为漫游目的地的邻居 AP 列表,AP 将返回客户端一个包含了位于当前 WLAN 漫游域内的相邻接入点的 BSSID 、所处频道以及其他信息。一般而言,列表中的频道与当前关联 AP 与无线客户端的链路处于相同频带(2.4Ghz 或 5Ghz)。双列表配置(dual-list configuration)则可以同时返回两个频带的结果。使用 802.11k 辅助漫游技术,可以避免客户端主动扫描全部频道,有助于降低客户端漫游过程中探查(Probe)漫游目的 AP 的时间开销。
802.11v 网络辅助节能技术可以使无线客户端在网络闲置状态下进入待机状态,延长移动设备的电池寿命。除此之外,802.11v 还可以用于实现接入点的负载均衡功能,将客户端从高负载的接入点引导至低负载接入点。当然,负载均衡服务不一定需要依赖 802.11v,例如 Aruba ARM Client Match 客户端匹配功能。
802.11r 快速过渡漫游技术旨在当客户端与当前 WLAN 漫游域的第一个客户端建立连接后,后续的漫游过程将不再需要重新与待关联接入点进行一次完整的鉴权操作。
802.11r 漫游分为两种方式:[^3]
对于 802.11r,有以下几点需要注意
有人指出 WLAN 漫游本质上是一个无线电问题[^6],这种说法其实是有失偏颇的。2.4GHz、5GHz 频段是公共频段,相比运营商所使用的频段有更多的外部干扰和合规限制(功率、DFS 等)。此外,由于 2.4GHz 频带在中国区域可用频段仅有 1-13 共计十三个频段,实际上覆盖时一般只选取 1、6、11 这三个频段进行交替覆盖,频谱资源稀缺。对于对 50ms 内低时延快速漫游没有业务需求(如 VoWiFi)的用户,直接购买普通无线路由进行交叉覆盖即可;对于进阶级家用用户,不要去购买标榜 Mesh、电竞级路由的智商税产品,经济可靠的 AC + AP 或 Unified AP 才是最好的选择,例如新华三、TP-Link、信锐、锐捷的消费级接入点;对于专业级家庭用户,动辄组 Home Lab 搞家庭 CEPH 或给家里划分好几个 VLAN 做二层隔离的计网发烧友,企业级的无线覆盖产品,例如 Aruba Instant、Cisco Meraki 以及 Ruckus 无疑是最好的解决方案。
[^1]: 【WLAN从入门到精通-基础篇】第6期——WLAN常用概念 - 华为企业互动社区
https://forum.huawei.com/enterprise/zh/thread-318127-1-1.html
[^2]: 802.11 WLAN Roaming and Fast-Secure Roaming on CUWN - Cisco
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html
[^3]: Enterprise Mobility 8.1 Design Guide - 802.11r, 802.11k, 802.11v, 802.11w Fast Transition Roaming [Cisco 5500 Series Wireless Controllers]
https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-1/Enterprise-Mobility-8-1-Design-Guide/Enterprise_Mobility_8-1_Deployment_Guide/Chapter-11.html
[^4]: 802.11 无线局域网漫游和思科统一无线网络快速安全漫游
https://www.cisco.com/web/CN/products/products_netsol/wireless/pdf/cco_whitepaper_01_v2.pdf
[^5]: 802.11r 无线交互
https://zhuanlan.zhihu.com/p/52967573
[^6]: 多个无线 AP 怎么实现无缝漫游? - 知乎用户的回答 - 知乎
https://www.zhihu.com/question/19751226/answer/159397304
最近不少 PT 站开始效仿币圈,将讨论群组从 QQ / 微信转移至了 Telegram。这里整理了一份部分 PT 站点相关的 Telegram 群组链接和频道。部分网站例如 HDfans 红豆饭仍然在使用 QQ 群作为主要的通知工具。
Telegram 是由俄罗斯开发者创立的跨平台聊天软件,支持以下特性:
注意:
豆瓣资源下载大师官方出品的影视推荐 & PT 资讯分享频道
https://t.me/doubanchannel
北邮人 BYRPT 官方服务器状态频道
https://t.me/byr_status
馒头 MTeam 官方频道
https://t.me/M_Team
馒头 MTeam Sweety Torrents 种子 RSS 频道
https://t.me/sweety_notify
馒头 MTeam 免费种子上下车提醒 非官方频道
https://t.me/mt_tor
馒头 MTeam 种子 RSS 非官方频道
http://t.me/mteam_torrents
梦想 PTDream &梦想家 PTDreamPlus 官方频道
https://t.me/PTDream_Channel
家园 HDHome 官方频道
https://t.me/HDHOMEORG
我堡 OurBits Torrents 官方种子 RSS 官方频道
https://t.me/OurBits_RSS
PT 之家 PTHome Torrents 种子 RSS 非官方频道
https://t.me/pthome_torrents
影客 Yingk Torrents 种子 RSS 非官方频道
https://t.me/yingk_rss
朋友 Keepfrds 官方频道
https://t.me/LetUsKeepFriendsForever
朋友 Keepfrds 种子 RSS 非官方频道
https://t.me/joinchat/AAAAAEkFWJAJOKKu8ucBiA
北邮人 BYRPT 故障汇报官方机器人
https://t.me/byr_report_bot
瓷器 HDChina 官方 Telegram 群邀请 Bot
https://t.me/hdchina_group_bot
Zoiper 是一套非常成熟的 VoIP 客户端解决方案,跨 Windows、macOS、Android、iOS 甚至 Windows Phone 全平台。
宝利通公司出品的多媒体会议客户端,支持 SIP 和 H.323 协议,跨 iOS 和 Android 平台,是目前我在用的一款对 H.323 支持比较好的客户端。
第一次运行会提示输入宝利通网关地址,跳过此页面即可设置自己的语音网关。
一款功能非常强大的 SIP 软电话客户端,仅支持 Android。采用了 Android 4.x 时代的设计风格,简单粗暴。
FreeSWITCH 是一个跨平台的开源电话软交换系统,与 Asterisk 类似,常被用于开发各类视频会议系统、客服系统、电话转接等服务。FreeSWITCH 可以被当作一个 PBX(Private Branch eXchange)作为内部电话交换机使用,也可以对接第三方 SIP 落地网关,将语音业务延伸至传统语音通信网,实现电话业务的内外网互通。
运行环境:Microsoft Azure A3 (4 vCPU, 7 GB RAM)
操作系统:Windows Server 2016
连接方式:客户端 (4G / WLAN) <-> Internet <-> Azure (10.0.0.0/24)
FreeSwitchConsole.exe
添加至防火墙放行列表。/conf/sip_profiles
目录下的 external.xml
及 internal.xml
,将value
字段修改为 Azure 实例的公网 IP 地址(如下方所示)。1 | <param name="ext-rtp-ip" value="[external_ip]"/> |
/conf/directory/default
目录下配置分机号(did)及密码;默认分机号为 1000
至 1019
,密码为 $${default_password}
即 1234
。详细分机设置及电话会议号码如下表所示[^3]号码 | 说明 |
---|---|
9664 | 保持音乐 |
9196 | echo,回音测试 |
9195 | echo,回音测试,延迟5秒 |
9197 | milliwatte extension,铃音生成 |
9198 | TGML 铃音生成示例 |
5000 | 示例IVR |
4000 | 听取语音信箱 |
33xx | 电话会议,48K(其中xx可为00-99,下同) |
32xx | 电话会议,32K |
31xx | 电话会议,16K |
30xx | 电话会议,8K |
2000-2002 | 呼叫组 |
1000-1019 | 默认分机号 |
从 /conf/vars.xml
修改默认密码(注意:如果不修改此处的默认密码,通话连接将会被系统强制延迟[^1])
为 Azure 实例的网络安全组根据需要放行入站端口,如下表所示[^2]
FireWall Ports | Network Protocol | Application Protocol | Description |
---|---|---|---|
1719 | UDP | H.323 Gatekeeper RAS port | |
1720 | TCP | H.323 Call Signaling | |
3478 | UDP | STUN service | 用于 NAT 穿透 |
3479 | UDP | STUN service | 用于 NAT 穿透 |
5002 | TCP | MLP protocol server | |
5003 | UDP | Neighborhood service | |
5060 | UDP & TCP | SIP UAS | 用于 SIP 信令 (标准 SIP 端口,对于默认 ”Internal” 配置文件) |
5070 | UDP & TCP | SIP UAS | 用于 SIP 信令 (对于默认 “NAT” 配置文件) |
5080 | UDP & TCP | SIP UAS | 用于 SIP 信令 (对于默认 “External” 配置文件) |
8021 | TCP | ESL | 用于 mod_event_socket |
16384-32768 | UDP | RTP/ RTCP multimedia streaming | 用于 SIP、交换以及其他协议的语音或视频的数据传输 |
5066 | TCP | Websocket | 用于 WebRTC |
7443 | TCP | Websocket | 用于 WebRTC |
以管理员身份运行 FreeSwitch
。
使用之前所填写的登录凭据在 SIP 客户端上进行注册,例如在 Zoiper 上,使用 [用户名]@[PBX/VoIP 运营商]
,如 1000@[服务器地址]
,密码为 1234
。
考虑到 NAT 对于连接可能构成影响,需要启用 SIP 客户端的 STUN 并使用 TCP 而非 UDP 进行连接。与此同时,对于客户端也应该配置为“始终允许后台运行”和“允许无限制地使用数据连接”,并开启“自动运行”。
[^1]: FreeSWITCH very slow - Stack OverFlow
[^2]: Firewall - FreeSWITCH - Confluence
[^3]: FreeSWITCH 初步
[^4]: 百问 FreeSWITCH
学校宿舍实施工作日 11:00 PM – 06:00 AM 断电策略,不利于赶 Deadline 以及 PT 下载;除此之外,整栋楼数百千瓦负载的通断无疑会产生浪涌,对于磁盘阵列和显示器都有着潜在危害。为此,在宿舍购置一台 UPS 不间断电源是很有必要的——不仅能在断电后为笔记本及移动设备充电,还能对接 NAS 和 HTPC 实现自动关机,更能提供 AVR 稳压,过滤电压突波,避免珍贵的数据和设备遭到损失。
常规 UPS 从工作原理上大致可分为三种:
考虑到宿舍环境以及学生的经济能力,建议选购后备式 UPS 或在线互动式 UPS,兼顾成本与低噪音。
UPS 从供电时间上大致可分为两种:
大部分学生宿舍均不允许存放蓄电池,且蓄电池连接线缆时如有不规范操作可能产生电弧并引发火灾,因此不建议在宿舍使用外接电池的 UPS 或是购置逆变器 + 蓄电池自行组装 UPS。
对于 UPS 功率的选择,一般按 UPS 标注功率等于 60% 实际负载来算:例如实际负载 600W,选购 1000VA 的 UPS。
目前市场上可以购买到民用 UPS 品牌以 APC(施耐德电气)、山特、克雷士为主。综合比对下来,作为法国品牌的 APC 电气方案比较专业成熟,相对而言价格也较另外两家国产 UPS 厂商贵出几倍,一般提供两年的保修;山特在京东和淘宝的口碑不错,价格也很实惠,一般提供三年保修。
如果手头比较拮据,可以考虑在闲鱼、转转等二手平台购买不含电池的品牌空机 UPS,然后自行从官方等渠道购买替换电池搭配使用。
经过均衡对比,我选择的是 APC 的 BR1000G-CN 在线互动式 UPS,提供最大 600W 负载和 50分钟(100W)的延时。对于 Windows 平台,APC 提供 PowerChute 软件,通过 USB 连接 UPS 进行高级管理,实现定时静音、自动关机等功能;对于 Unix 平台,有开源的 APCUPSD 提供支持。
如有关于宿舍 UPS 不间断电源选购的疑问,欢迎留言。
安装 Ubuntu 时并未自动安装连接 Hyper-V Manager 的驱动。
sudo apt updatesudo apt install linux-cloud-tools-virtual
安装后即可从 Hyper-V 管理器中查看到 Guest OS 的 IP 地址。
]]>PT (Private Tracker) 是一种基于私有 BT Tracker 服务器的资源传播形式,经授权的用户使用受允许的客户端进行种子制作与下载。相较于传统 BT 和 emule,PT 站往往采取了严格的邀请制度以及免责制度来规避法律风险,同时要求用户客户端开启传输加密以绕过运营商的检测策略。当然,从实际上来说 PT 站的运营、使用仍然是违反了各国版权法的。
许多高清爱好者聚集在 PT 站,发布翻录的蓝光原盘、CD 资源以及录制的高清卫星电视讯号;得益于 Netflix、HBO、Apple TV 等高清流媒体在线视频平台的发展,近年也出现了一些 WEB-DL (Download from Web) 资源。
你可以从 PT 站下载到:
目前国内使用的 PT 站源码主要为基于浙江大学 xiazuojie 团队所开发的开源整站项目 NexusPHP,基于 PHP + MySQL + memcached。个别站点使用 Discuz! 进行二次开发。
日前,@burpheart 基于上游项目,开发了新版的 NexuxPHP Safe。其修复了一些已知的安全漏洞,并加入了一些增强用户体验的小功能。
2022 年更新:@burpheart 似乎逐步淡出了项目维护。目前项目迁移至 xiaomlove/nexusphp,由 @xiaomlove 为主的开发者继续维护。
U2 和某些教育网 PT 站(如北邮人)的研发能力是相当高的,基于原版 NexusPHP 做了很多功能和安全改进,对于新版本客户端也持欢迎态度。某些公网 PT 站属于 one-man 站点,Tracker 经常炸,技术 Bug 修老久,把网络问题甩锅 GFW 等等。建议大家谨慎选择注册用户数小于 1 万或每周活跃用户数小于 1 千的 PT 站。
历史比较悠久了,仅供参考:
根据网络环境和用户群体,国内 PT 站可以划分为两个系别:教育网 PT 站 和 公网 PT 站。
以北邮人(北京邮电大学)、蒲公英(西北工业大学)、极速之星(北京理工大学)和六维空间(东北大学)为主。
高校校园网提供的 IPv4 网络一般是有计费及限速策略的,由校方向电信、联通、移动、鹏博士等运营商采购带宽并在出口实施自动分流。而为了推广 IPv6 业务,各高校所接入的中国教育网(CERNET)的 IPv6 网络一般是不计费且不限速的,因此组建一个依托于 IPv6 的免费资源分享网络有着很大意义。
一般来说,教育网 PT 站的原创影视资源较少,大部分为转载资源。Coursera、Udacity 等公开课资源(WEB-DL)、考研视频、电子书等内容较多,此外,北邮人等站点还提供一些诸如 Steam 游戏数据备份文件,这样学生就不用担心被几十个 G 的 Steam 游戏更新榨干网费了。
目前来看教育网 PT 站或多或少获得了学校网络中心的技术和政策支持,所以才能存留至今。部分教育网 PT 站仅允许 IPv6 或仅归属于教育网单位的 IPv6 访问,因此对于公众来说访问有些难度。可以通过 Hurricane Electric 提供的 IPv6 TunnelBroker 隧道,或者基于有 IPv6 网络的 VPS 搭建代理来中转 tracker 的流量。
从分享率和发种规范来看,教育网 PT 站十分宽松,但保种率可能不如公网 PT 站高,资源也没那么丰富。但对于追热门电影和美剧的轻度用户来说还是足够了。建议初次接触 PT 的用户先从教育网 PT 站(如北邮人、蒲公英)养号,之后通过官方邀请帖等渠道间接进入公网 PT 站。
传说中国有五大公网 PT 站:HDS、TTG、HDC、CHD、HDR,也有三大 PT 站的说法,即 CHDbits、HDChina、TTG。经过 2013 年 4 月 26 日世界版权日风波(“中国版权第一案”的思路网侵权案,又称“426”事件),HDStar(思路网)管理组(站长”雪还是白的“等人)被捕入狱,剩下的站点也多多少少受到了一些影响,有些直接关闭了,有的则隐没了。
距离版权日风波已经过去了七八年,现在国内 PT 站又呈现出繁荣景象。一方面国内电视剧集的分级制度迟迟未推出,而 Netflix、HBO、Disney+、Apple TV+ 等境外流媒体业务的订阅费用也居高不下。另一方面,国内百兆、千兆家庭宽带已经覆盖到了三四线城市甚至是县城,养一个 PT 账号的成本已经相当低了。
以影视资源为主的有:
hdchina.club
域名,于 2017 年初重新启用 hdchina.org
域名。资源方面,官方制作组(HDCTV 和 HDChina)的 Netflix、HBO 剧集,原盘,录制的电视剧比较多。.tar.gz
格式文件,分别为 2023-11-28-170{马赛克}
、 2023-11-29{马赛克}
、 2023-11-29{马赛克}
和 website.tar.gz
。 不难推测这是数据库以及 NexusPHP 和种子目录的备份。与此同时,管理员 @nilaoda_cn 和 @duoluo1234 的 Telegram 账号状态仍然显示为“last seen a long time ago”。hdchina.org
域名到期,并进入续约宽限期(Renewal Grace Period)。可见域名实控人失联。教育网 PT,部分 tracker 可能仅允许教育网或 IPv6 连接。入站门槛较低,可以凭借 edu 教育域名的邮箱进行注册,也可以通过校内用户发起邀请。对分享率和种子规范的限制比较宽松。
以动漫资源为主的有
以音频资源为主的有
其他
援引一份 @Rhilip 的数据,按官方种占比倒序排序。数据源日期为 2018/4/10,但仍具备一定参考价值。考虑到对于同一份资源,某些官方组会采用不同色彩配置和编码压制不同版本,如 HEVC/H.264 或 SDR/HDR 等,所以官方种占比值只起到参考作用。
教育网 PT 以转载资源为主,一般在资源发布后的一天内就能在教育网 PT 站下载到来自公网 PT 站的热门电影和电视剧资源。在资源丰富度和种子活跃度(seeder 人数)上,公网 PT 站具备显著优势。
站点 | 官方组标识 | 官方组发种数 | 统计种子总数 | 官方种占比 |
---|---|---|---|---|
HDSky | HDSky, HDS, HDS3D, HDSTV, HDSWEB, HDSPad, HDSCD | 32502 | 60467 | 53.75% |
CHDBits | CHDBits, CHD, CHDTV, CHDPAD , CHDWEB , CHDHKTV | 15419 | 30537 | 50.49% |
HDChina | HDChina, HDCTV, iHD, HDWinG, HDWTV, OpenMV, HDC | 13562 | 29099 | 46.61% |
HDHome | HDHome , HDH, HDHTV, HDHPad | 12672 | 31043 | 40.82% |
HDTime | HDTime, HDT, Vtime, PADTime | 3524 | 12103 | 29.12% |
CMCT | CMCT, CMCTA, CMCTV | 10609 | 41046 | 25.85% |
HDCity | NoVA, NoPA, NoTA, NoXA | 2444 | 9750 | 25.07% |
TCCF | BMDru | 4340 | 21251 | 20.42% |
Ourbits | OurBits , OurTV, iLoveHD, iLoveTV | 5075 | 25432 | 19.96% |
JoyHD | JoyHD | 1090 | 6726 | 16.21% |
NYPT | NYHD, NYPAD, NYTV, NYPT | 1863 | 25655 | 7.26% |
HDU | HDU | 1090 | 15852 | 6.88% |
Hyperay | Hyper, PureTV, HyPad, Tron, geek, TronTV, Neon | 816 | 12148 | 6.72% |
NWSUAF6 | MTTV | 2305 | 38978 | 5.91% |
TTG | Wiki, TTG, DoA, NGB | 11066 | 196604 | 5.63% |
Mteam | MTeam, MTeamPAD, MTeam3D, MTeamTV | 10002 | 204982 | 4.88% |
SJTU | PuTao | 2005 | 62723 | 3.20% |
BYR | BYRHD, BYRPAD, BYRTV | 2185 | 79643 | 2.74% |
TJUPT | TJUPT | 593 | 40133 | 1.48% |
NPU | npuer | 727 | 68434 | 1.06% |
对于用户,无论是公网 PT 站还是教育网 PT 站,往往都有以下要求:
>=50GB
的上传下载量。部分教育网 PT 站可能没有新手考核要求。大部分站点都有邀请考核制度,需要在一个月时间内达成一定的上传量、下载量、魔力值(做种获得的积分)和平均做种时间。部分站点考核不计算魔力值所兑换的上传量,建议老老实实下载热门种子并做种。
邀请者通常可以消耗数倍的魔力值来兑换一个无需新手考核的邀请码。被邀请人也可以付费捐赠(几百元不等)来免除新手考核。
通过新手考核后,用户可以通过提高分享率和上传、下载量来提高自己的用户等级。有些站点会在升级时赠送一定的邀请码。通常在达到一个较高等级后,用户可以获得长时间不登录也不会被封号的特权。
想快速提高上传和下载量,最快的办法就是租用 Seedbox 或大盘鸡(大盘机,指代硬盘很大的服务器)。Seedbox 即专用于跑 BT/PT 的服务器,一般位于海外(德国、罗马尼亚、荷兰)等地。
注意,有些 PT 站对于 Seedbox、VPS 和独立服务器有严格的使用限制,如图为 HDChina 的 Seedbox 规则。
此时混 PT 只为偶尔下几个资源,而不是那么注重参与了。你可以使用 RSS 订阅功能,订阅感兴趣的资源分类,配合 Plex 或 Infuse 等媒体中心软件,实现自动下载和元信息整理。无需再花精力在折腾 PT 上。
不同网站对于 BT 客户端的兼容性不同。尤其是 BitTorrent v2 协议推出后,与旧版本的客户端均不兼容。因此部分 PT 站会拒绝较新版本的 BT 软件。此外,普通的 PT 下载器如 Free Download Manager (FDM)、迅雷、Aria2c 以及 qBittorrent-enhanced 是被严格禁止的。
安装 JUnit 插件
File -> settings -> Plugins -> Browse repositories -> JUnit -> JUnit Generator V2.0
,安装后需重启 Intellij IDEA。
为当前项目添加依赖
File -> Project Structure -> Libraries
,找到 Jetbrain Intellij IDEA 的安装目录下的 lib
文件夹,添加 hamcrest-core-1.3.jar
、junit-4.12.jar
以及 junit.jar
。
为待测试类添加测试样例
在待测类中按 ALT + INSERT
,选中 JUnit Test
。
cscript ospp.vbs /dstatus
查看当前在册授权cscript ospp.vbs /unpkey:[Last 5 chars of license]
注销授权基于 VMware Workstation 15 Pro 安装的 macOS Mojave 显示分辨率始终为 1024 x 768
,安装 VMware Tools 与 SwitchResX 均未解决问题。
打开 Terminal,执行 /Library/Application\ Support/VMware\ Tools/vmware-resolutionSet [width] [height]
,最大支持 8192 x 8192
。
由于虚拟机黑苹果最高只支持 128MB 显存,请不要将分辨率调过高,以免卡顿、花屏。
]]>.
修改为 .abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
即可。]]>https://github.com/Wind4/vlmcsd/releases
下载 latest releasetar -xzvf binaries.tar.gz
解压各 KMS 激活密钥见 KMS 客户端安装密钥 | Microsoft Docs
slmgr /skms [服务器地址]
slmgr /ato
slmgr /xpr
注意:
1. 仅 VOL 批量许可版本的 Windows 支持 KMS 激活
2. KMS 激活有效期为 180 天(半年),到期系统会自动向 KMS 服务器更新状态。
3. 不可激活旗舰版 Windows 7
4. 手动安装密钥 slmgr /ipk xxxxx-xxxxx-xxxxx-xxxxx
5. Windows 下载见 MSDN 我告诉你
cscript ospp.vbs /sethst:[服务器地址]
cscript ospp.vbs /act
cscript ospp.vbs /dstatus
注意:
1. 仅 VOL 批量许可版本的 Office 支持 KMS 激活https://otp.landian.la/en-us/
2. Office 下载见 Office Tool Plus
]]>CON
/dev/tty
1 | freopen("CON", "r", stdin); |
1 | freopen("/dev/tty", "r", stdin); |
/etc/sysctl.conf
,修改以下条目。1 | net.ipv6.conf.all.disable_ipv6 = 0 |
sysctl -p
刷新设置文件/etc/network/interfaces
1 | auto he-ipv6 |
ifup he-ipv6
启用隧道add tunnel sit0 failed: No buffer space available
隧道已经存在,执行 ip tun del he-ipv6
删除已经存在的隧道。
add tunnel "sit0" failed: No buffer space available
系统 IPv6 被禁用或者未更新配置文件,检查 /etc/sysctl.conf
中有无禁用 IPv6 的命令
Netflix 账号全球通用,流媒体内容取决于用户 IP 地址来源区域。通常来说,“解锁” Netflix 外区服务有两种方式,分别是全局代理和智能解析。前者最稳定但会影响其他应用的访问速度,后者较灵活,但配置过程繁琐,不适用于全平台。本方案通过配置策略路由,极大降低了对其他网络服务的影响并同时具有全局代理的稳定性。
Netflix 采取了多种方式进行代理检测,包括但不限于 IP 地址检测与 DNS 解析比对。其中 DNS 解析测试服务运行于运用了 Anycast 技术的 AWS EC2 上。因此最保险的方法是路由全部 Netflix 与 AWS 的 IP 段。
使用正则表达式对 IPv4 地址段进行提取。
[0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}[.][0-9]{1,3}/[0-9]{1,3}
使用一段简单的 C 程序将地址段整理成 [IP]/[子网掩码]
的形式。
1 |
|
然后进行人工整理与去重至两百条以内,并加上 route =
头部,得到最终的配置片段。
1 | # Netflix |
0.10.5 及之前版本 OCServ 需要修改 src/vpn.h
来支持超过96行(OCServ默认值)但不超过 200 行(Cisco 客户端最大值)的路由表:
#define MAX_CONFIG_ENTRIES 96
,96 改为 200 以上。0.10.6 及之后版本 OCServ 不需要修改,参考 https://gitlab.com/ocserv/ocserv/issues/17
根据 Cisco 官方文档,no-route
和 route
不能同时使用。
You can specify either split-include or split-exclude, but you cannot specify both options.
对于 Netflix 以及 AWS 服务的流量将全部被路由至远程服务器进行中转,但使用 Netflix 进行观看与下载时所产生的流量会走本地直连。Netflix Open Connect 计划使得 Netflix 与 ISP 进行合作,通过应用 CDN 下沉解决方案,减小 Netflix 与运营商的网络负载和建设成本,而这些 CDN 服务器地址并非 Netflix 所属,而是归属地 ISP 的地址,因此数据是由归属地 CDN 直接传输到本地。
本方案有效降低了服务器的网络负载,对于不同平台具有普适性作用。对于有前置路由的网络场景,可以在路由上直接写入精确的路由表,提高服务运行效率。
]]>环境:Ubuntu 16.04 x64
版本:OCServ 0.10.11-1build1
今日重置了阿里云 ECS 后,选择从 APT 源直接安装 OCServ 而非从官网手动下载安装,随后便发生了一些诡异事情。
service ocserv start
所启动的 OCServ 服务在 IPv4 网络中进行连接时,尽管网络状态良好,仍然回退到了 TLS 链路。而使用 ocserv
命令直接启动服务却能正常建立 DTLS 连接。
使用 lsof -i:443
检查 443 号端口监听状态时发现,前者会由 systemd
与 ocserv-main
共四个进程监听 IPv6 协议类型上的 443 号端口的 UDP/TCP,而后者由 ocserv
共两个进程监听 IPv4 协议类型上的 443 号端口的 UDP/TCP。
查看 /etc/init.d/ocserv
文件发现,OCserv Daemon 在启动时会正确调用位于 /etc/ocserv/ocserv.conf
的配置文件,但却没有根据配置文件中的设定进行监听。
早在 2016 年便有人指出这个缺陷(现已修复),而阿里云 APT 源中的包版本较老,所以没有修复此问题。
Try to go to “/lib/systemd/system/” and modify the file of “ocserv.service”,
1.use vim to change two lines,
2.Remove the line of “Requires=ocserv.socket”
3.Remove the line of “Also=ocserv.socket”
4.save the file,
execute “systemctl daemon-reload”,
then reload the service “service ocserv start”
/lib/systemd/system/ocserv.service
,移除 Requires=ocserv.socket
和 Also=ocserv.socket
systemctl daemon-reload
service ocserv start
服务重启后,DTLS 连接可以正常建立,且未与 OpenVZ-BBR 冲突,至此问题得到了完美解决。
使用 apt remove ocserv
移除旧版本的 OCServ,从 OCServ 项目官网 下载最新版本的 OCServ,然后手动安装。