maybeonly

对于 tcp 和 udp ，ip6tables 可以实现和 iptables 一样的 nat 。
对于 http 类服务，根据需求，还可以选择 http 代理的模式做反向代理。
以及，建议还是用不同的域名区分不同的服务，毕竟就算是 ipv4 ，也可以用 host 区分（ http 服务），就算不同的域名也可以加端口。

路由器上组播收下来电视上装 kodi ，也只有这么用了

北京移动，每月 20 ，价格合理，童叟无欺。
既然加钱，可以考虑换商宽，更现实的是两条宽带一起用。

@maybeonly #18 勘误，最后应该是打 mark

@povsister #23 这个真的能做出来，在 mangle/PREROUTING 直接打 mark 走某个路由过掉，并且自己配置好防火墙，不要因为 status 不对之类的原因丢掉就好了。或者更骚的，可以在防火墙丢弃原来的数据包之前在 mangle/PREROUTING 直接 TEE 过去（谨慎使用，小心爆炸）。而且虽然我是自己搓的主路由，但是里边也是存在一些不对称路由的，比如梯子选出口，dns 分流。

@bluaze #29 upnp 发现用的组播（ ssdp ），如果是二层直通的话基本上是可以到达的。如果旁路网关做 nat 的话，还要看旁路网关实现的是 nat 几。

所以从几个地方看，他的旁路至少在没过墙的时候没有 nat ，如果是直接走路由表或者 dae 那种基于包的转发的话，普通回包是可以到达的（不过墙）。
不过我自己是有海外站从家里的 git 上拉代码，所以嘛。

最后就是说，设计良好、运维得当的主路由是没那么容易挂的。旁路由要么是条件所限没办法用主路由，要么就是个过度的学习阶段。旁路由结构反而复杂，如果旁路由都真的搞明白了，也就有能力上主路由了才对。

除了 ipv6 ，还有一些事情是旁路由无论如何做不出来的，比如我家有两条宽带。
另一个想到的场景，就是隔壁帖子的家里一大堆 docker ，既然在自己家起了那么多 docker ，难道还用端口映射嘛？就算 docker 的 v6 稀烂，至少把 v4 宣告出来/主路由静态指下去吧，然后到边界处统一做 nat 就好了。毕竟好多 docker 也是需要墙外资源/镜像的。

@povsister
你知道的我很讨厌旁路由
但是确定的内网 ip 和端口的话只要匹配来自这个 ip:port 的数据包直接转发给主路由
还是做得出来的
不过如果能做这个，大概也就不会用旁路由了

搞好的主路由其实没那么脆弱
很多时候被弄坏了都是因为把调度整个搞坏了

只需要访问墙内的设备，方案有
1) 采用不同的 ssid/vlan
2) 在入口网关上根据 mac/ip 打 tag ，走不同的路由表

她这个看着也不像是不同的设备（光猫和路由器）设置相同的 ssid
相同 ssid 的话，连接确实会随机连上，但是如果信号不是特别差、网络正常的话是不会跳来跳去的
她这个看着像已经连上的网络被主动断开，视频里说的负载过高是靠谱的
这种问题手机上开个 wifi analyzer 很快就能看出来

更倾向于装维不会/不想弄客户的路由器，现在的手机都普遍随机 mac 地址了

自建递归是为了解决 dns 分流的问题的。
因为 dns 列表永远不可能准确，而 ip 列表可以相对准确。
原理就是可以通过 ip 列表路由出站的 dns 请求，然后对于有境内权威的域名认为他可以使用境内解析。

当然自建递归解析性能会下降，一个可行的方案就是对于已知的白名单直接丢给运营商 dns 。
至于墙外？一样可以用已知的黑名单丢给（走隧道的） 1111 或者 8888 之类的。
甚至可以自己总结名单（