@terrancesiu 对，我现在是双线，以前用联通地址往下分，移动出去的话就 snpt 。某一天换成 fd 试试了，两边 snpt

@piero66 墙内家宽接 asn 不现实，要用地址的话也没必要，偷一段就是了，更隐私，而且有生之年不会分出去。

@allin1 不是所有东西都能装扩展……或者说基本上只有 pc 能装扩展。

@zwy100e72 webrtc 能同时拿到内部和外部地址。一个有点现实的场景就是，墙外网页能直接拿到墙内 v6 。当然，如果访问个墙内接口也能拿，但是那就是针对性的了。

至于防火墙，我个人是不爱开，虽然开起来也很容易，但是这种东西除非实在守不住……还是让设备通达比较好。

@kenneth104 感谢回复。
> a1 ，隐私有啥问题，或者说有啥隐私？
webrtc leak ，特别是某不作恶的公司干掉 webrtc 选项以后
> a2 ，ban 掉外网 v6 ，就不会对外 P2P
(d)不考虑
> a3 ，自动获取 v6+ddns
a3 这个 ddns 没难度啊，复杂的网络指的是……我的另一个帖子那种程度。
相反，在 b3 做 ddns 需要算一下（我用算的，所有 ddns 托管在路由器上）
a3 的实际问题，简单的说就是，局域网内同时有真地址和 fd 地址，在边界处做 snpt/dnpt ，实际上没过边界的话不可以互相访问，ddns 解析到在自己家的公网也不行。解决起来也不困难，内部访问根本不需要走 ipv6 。

不是难道还有打算二层直通的吗
交换机和路由器……
算了
请个网工吧，请不要和网工抢饭碗

看你的小鸡的线路
感觉最近联通亚太优质线路比较少

对于 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 之类的。
甚至可以自己总结名单（

@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 早就不在顶上了
再说 没搞错的话 那次着火的是腾讯