@zealic
wg/zt 本身是不适合魔法场景的，过墙能力太差，ros 容器限制又太多，OP 的场景也是旁路由单独跑。

另外，旁路由模式不代表无法 fasttrack 呀，在 L3 拓扑上旁路由就是正常的下一跳，不加 mangle 的情况下是可以正常 fasttrack 的，LAN to ROS ，旁路由 to ROS wan 都可以正常 fasttrack

@zealic
mangle 如果要干预路由决策，需要 mark routing ，会直接导致 fasttrack 失效。
实际性能会比路由表更低，路由表查询的代价比跑一遍 firewall 的 slowpath 要低太多了。

@jdjingdian
fullcone NAT 只支持 UDP 完全没问题啊。。TCP 各级路由基本都是 stateful tracking ，fullcone 意义在哪？
另外 EoIP ，IPIP ros 本身不是有么。。

组网的思路要打开，当下互联网协议基本僵化到只剩下 TCP 和 UDP 能用了，99.9%的需求*ray+tproxy 可以通杀。

没有

@TigerBest
国内教程一言难尽，很多都是照猫画虎没抓到问题本质。
一般来说关了 DHCP 是最稳妥的，因为“TP 这种硬路由”你没办法很精细的控制它的固件行为，如果他把物理 WAN 口上的地址划进路由表还设置了错误的 metric ，那你上网就会有各种奇奇怪怪的问题。

另外，在正确设置路由的情况，只需要把 LAN 的范围错开光猫的地址范围，哪怕不开 DHCP ，一样可以通过手动给接口添加 IP ，达到直接从路由器下访问光猫管理页的目的，压根不需要连光猫的 WiFi 才能管理。前提是你的路由器要能够进行路由表/防火墙的精细设置。
https://i.imgur.com/8foJjW3.png

了解一下逻辑接口和物理接口。
光猫，DHCP 下发地址在路由器的物理 WAN 口上（还得假设路由器接光猫的 DHCP ）

但是路由器拨号走的 pppoe 逻辑接口，这个逻辑接口只是隶属于物理 WAN 口。
而你的内网 192.168.1.0/24 在 LAN 上，通过路由器 NAT 从 pppoe 逻辑接口走默认路由上网，都不是一个接口，何况 tplink 的路由表里压根没有光猫的 192.168.1.1 的路由（拨号模式下，压根不吃你光猫 DHCP 给的地址），这能有什么冲突的？

不信你试试桥接还能不能在路由器下访问光猫管理页面，肯定访问不到吧。

如果不要求全屋制冷的情况下，中央空调远不如每个房间一个挂机省电。
以及，一般有一个最低功率，看你两个房间要的制冷量，如果不比这个高多少，那肯定 1-2 个房间区别不大

家用监控请不要碰任何和“智能/云”沾边的东西。除非你信任 7x24 监控你家的云服务商的良心。

@EGOISTK21 这个不能算误判，你考虑下 packet path ，你会发现是合理的。ROS 的 conn-track 是 stateful 的，对于 TCP 来说双向的数据报文都被 track 到，tcp 进入 establish 状态后路由器才会正常转发报文。
非对称路由在有状态防火墙上吃瘪是常事，我倒是不建议你粗暴的把这个规则去掉。input 链上的规则还是很重要的。

你以为的股市
大环境，公司的发展和价值
实际的股市
大庄家割韭菜的镰刀

除非真的兵荒马乱企业倒闭了，现在的股市就是资本家的数字游戏。

@haixinsc 一天 1T 进去真不冤

旁路由模式推荐将旁路由和网关放在一个独立的网段内，否则下行流量（即由网关返回的响应）会直接由旁路由回复给 LAN 内的设备，造成非对称路由。
这在某些情况下可能会造成意想不到的问题。你这个 case 看起来就像是这样。

拓扑配置，可借鉴我自用的类似方案 https://github.com/povsister/v2ray-core

给你参考下我这正确配置的情况

curl -o /dev/null -s -w "DNS Lookup Time: %{time_namelookup}\nConnect Time: %{time_connect}\nPre-transfer Time: %{time_pretransfer}\nStart Transfer Time: %{time_starttransfer}\nTotal Time: %{time_total}\n" https://google.com

* Host google.com:443 was resolved.
* IPv6: (none)
* IPv4: 172.217.174.110
* Trying 172.217.174.110:443...
* Connected to google.com (172.217.174.110) port 443

DNS Lookup Time: 0.004620
Connect Time: 0.006571
Pre-transfer Time: 0.328742
Start Transfer Time: 0.416287
Total Time: 0.428822

t/1039732

你进 116.226 的竞技场了。无解，安分一阵子重新拨号看能不能把你提出来吧。
另外你这个“玩了几天 PT”，上传量多少啊？我一周 200G PT ，这已经一年多了都没事。

取决于有没有自己的护城河，没有门槛的行业不存在你说的这种情况

互联网增长基本见顶了，业务狂奔消停后，大厂 SRE 岗会逐渐开始受重视。
但 SRE 本身是个系统性工程，现在国内问题是很难找到这么一个足够高 level 的人去统领全局。

外企来说，从我呆过两年的 HPE 来看，如果你的位子不够高，其实很难拉到那么多资源去做 SRE 建设。
微服务稳定性和健壮性其实算是最基础的，SRE 是要从可观测入手，搭建一整套服务的观测-诊断-应急处理预案-长期稳定性指标监控，进一步到变更管理，日常巡检等等。要做的事情太多了。

简单不等于把后路堵死，软件解决方案最好是可迭代的。

你表述的应该是：是否要为了尽善尽美的解决问题，而把系统复杂度拉的太高

这个老生常谈的问题了，自己拿 占用资源 - 工时 - 可扩展性 去权衡吧。每个项目都有每个项目的要求。

#6 说的很对，很多搞外挂的，自身也是高手，而且外挂不同平台的骚操作都不一样。

当然，你如果就想整点易语言抄基址的玩意当我没说。