北京移动，每月 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 之类的。
甚至可以自己总结名单（

@AS58453 签什么字，签字就是你自己的问题了。直接按条款处理，特别是自己不急的时候。不知道上次广州移动一刀切的最后怎么收场的。

专线用户还含糊什么
直接索赔

@chenbin36255
emmmm 直连用 fakeip 就更奇怪了
所以说有可靠 ip 列表的前提下用路由表直接分流啊
路由表本来就可以让一部分流量直接过去的
科学网关坏掉为什么会全家断网？因为大部分梯子都是为了单机而不是路由器上用的
所以他们实际上做了调度器+隧道的组合，而良好的路由器上运行的梯子应该把调度器和隧道分开，
甚至把不过梯部分和梯子调度器进一步分开。
关于这方面的问题，我的解决方案是 /t/1034955

@povsister 这是一个可以考虑的权衡方向。不过我选择不告诉境内我在解析什么，怕反炸上门。

分流说白了都是名单问题。
dns 真的很难有可靠的名单，简单一点的话有相对可靠的墙内 ip 列表（前不久还刚刚修理了一下我家用的版本）
我的做法是：自建递归（我用了 bind ，用什么都行），然后 53 端口根据 ip 列表走 ip 分流。
考虑到性能问题，前面还有一层 dnsmasq ，把简单的墙内白名单指向运营商，把简单的墙内黑名单指向可信 dns

原理的话，dns 解析都是递归的，从根域名开始。
省略根、.com 的解析过程：
比如解析 www.baidu.com ，拿到 ns1.baidu.com 之后，你的递归会给 ns1.baidu.com ，也就是 110.242.68.134 发送请求，这个请求是通过直连发出去的，那么他看到的当然就是你的墙内 ip 。
又如解析 www.google.com ，每一步都是通过梯子出去，墙内完全不知道你在解析什么……最后 google 看见的你的请求来源也是梯子出口的 ip 。

我的玩法比他精巧不？ fakeip 还是算了，太假，个人表示不喜欢。

@luoshengdu logo 早就不在顶上了
再说 没搞错的话 那次着火的是腾讯

跑递归/缓存还是权威啊？
前者的话，国内给公众服务要许可证的，给自己用的话我有个 bind ，除非路由器硬件坏了/电力问题，现在在 n100 ，j1900 也跑过也没都问题，系统是 rockylinux9
而且同一个路由器上不知道有多少 dnsmasq 了，肯定两位数，虽然功能不同，但是都稳定啊
权威的话，我家权威在免费的龟壳上，还有美国某廉价小鸡上，只回对应自己域名的请求，也都很稳

顺便说，跳反炸也不一定是 dns 的问题，也许路由表没配置好没走梯子呢？
而且自己家递归的话，要有可靠的墙内路由表，然后把递归查询墙外 ip 的请求路由到梯子上
然后稳定性就应该没问题了，性能的话，慢慢优化吧

宣告 ip 只是为了能让人访问这个 ip
当这个 ip 不需要作为目的地址被访问的时候，就不需要宣告。
像中间路由器的 ip 就有这种情况，反正你也没机会访问他，他只是用这个 ip 做源地址发一个 icmp 响应罢了

至于不同 as 之间的互联，有公开能查到的，也有查不到的
查不到可能是私下宣告的，也可能采用其他方法互联，如偷线路
当然 trace 的话还有一种可能，没减 ttl ，导致中间设备被隐藏；或者由于路径不同，有些 ip 并不在以为的位置上

我家是移动+联通，自己搓的双公网双栈。
连出是移动+广电的 ip 静态路由走移动，默认走联通。
连入做了 conntrack ，从哪个口进来回哪边。
v6 同理，用联通的地址段做 slaac ，移动的出口上做了 snpt/dnpt 。