家用公网服务架设指引
和联通斗智斗勇的第10010天 大家都是有IPv6的公网地址的,所以: 这块长话短说,先抛出一个大前提:喜欢动手折腾的同学,能接受自购企业级光猫(中兴、华为等等均可)最好,恩山论坛上有备受推崇的几个型号及各种对比,我就不赘述了。 如果你一定要坚持光猫是运营商提供服务的载体,安装/调试/维护它是运营商工作的一部分,我只想提两个要点: 第一,投诉不能当时解决问题,但绝对是解决问题的唯一手段。 虽然某些运营商工作人员非常敷衍,但还是希望大家理性投诉,一个大的原则是先礼后兵,不要越级(投诉):你不能让认真工作的人突然莫名其妙被领导敲打一下(甚至被扣钱),这很离谱。 经过了长达3个多月的拉锯战,问题终于得以解决1,下面列举我实际的投诉(中国联通)顺序,供大家参考: 要有长期作战的准备,因为直到投诉到工信部之前,可能还是之前总联系你的几个客服(话务员)和安装师傅在和你绕来绕去,反复让你描述同样的问题,再复述完全不一致的问题给你听,或者直接问你: 您家宽带是上不了网了是吗? 希望大家与人为善,因为他们也很无奈,case 来了就要接,想找技术好的人找不着。这就是GQ现状啊。 第二,光猫当换则换。 当你申请装宽带时,如果当地运营商有陈旧的存货,而你又没有提出要求,是可能优先给你装旧光猫的。 这些光猫的IPv6支持形同虚设。没错,你点进去(管理员账户)有相关的设置,但只能分配一个地址给你。 然后你就可以在IPv6的海洋中遨游了:你只能访问IPv6的服务而不能提供任何服务,因为光猫的内置防火墙规则给你干得死死的2,又或者给设备发放地址的前缀有问题。 这些光猫有些共通特点: 由于OMV没有特别爽的照片管理应用,所以我在NAS上安装了PhotoPrism(下简称PP)。 那么就催生了我对网络的以下几个需求: 下面分别展开叙述。 先把域名托管到CF,这个不做赘述了。 然后开启一个ddns-go服务: Token的获取方式: 这步很简单,只要让域名走CF的代理就可以。 CF在全球范围内运营维护了大量同时支持IPv4/v6的边缘节点,并在其上应用负载均衡。经过这样的设置后,哪怕客户端的网络环境只支持IPv4,CF也会将其发送的请求代理到客户端附近的边缘节点上,而这些节点支持IPv6,这样就实现了 中国联通在上游禁用了以下端口(欢迎评论补充其他情况): 我们在第1步中配置域名走了CF的代理,但CF的代理仅在特定的几个端口上生效,因此只能充分利用它们。 比如,我决定用 操作指引:Dashboard → Rules → Origin Rules → Create rule Caddy需要自行编译以增加对CF的支持,过程不再赘述,详见我配置NAS的post中的对应部分。 先去CF拿个给Caddy用的token。过程和第0步中描述的类似,详细配置如下: 有了token后可以参照Caddy官方文档配置daemon的环境变量。 然后写好 这里详细解释一下为什么要在Caddy中禁用自动重定向到HTTPS: 重启Caddy生效: 操作指引:Dashboard → Rules → Redirect Rules → Create rule 具体的设置就很简单了,匹配规则等和Origin Rules类似,按照页面指引填写并保存即可。太长不看
光猫篇
路由器篇
CF篇
0. 域名绑定动态IPv6地址
services:
ddns-go:
image: jeessy/ddns-go
restart: always
network_mode: "host"
volumes:
- ./ddns-go:/root
1. 在IPv4下访问

4 to 6。2. 端口映射
/photo子路径指向我NAS上的PP服务,并使用CF的2053端口来代理访问PP的HTTP请求:
3. Caddy反向代理

/etc/caddy/Caddyfile:{
auto_https disable_redirects
}
nas.bigdick.live:2053 {
reverse_proxy :2342
tls {
dns cloudflare {env.CF_API_TOKEN}
}
}80和443端口都被运营商在上游禁用了2步中同时转发HTTP和HTTPS的请求到两个不同的端口,则需要两个Origin Rules,复杂且不经济systemctl daemon-reload
systemctl restart caddy4. 使用CF将HTTP请求重定向至HTTPS
telnet去获取密码,但命令都打错了,大怒,叫我再下一个工单去问管理员密码