V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  maybeonly  ›  全部回复第 5 页 / 共 10 页
回复总数  195
1  2  3  4  5  6  7  8  9  10  
@eh5
1. 既然想着共存了,改 conntrack 确实不是好事情,不过似乎可以(部分)绕过 conntrack ?
当时考虑的是在入口和出口分别捕包,然后在出口处发现符合条件的报文后反查刚刚从入口抓过来的数据包,可能用到的匹配条件有:protocol+dst ip & port/id, length, 应该还有 ip 报文的 id 。
抓到该端口相关的东西后续由 ebpf 完成 nat ,不再经过内核。
2. 对于碎片,考虑发 icmpv6 type2 或者 icmp type3 回去?不确定能起多大作用。

由于我太懒了,以上全部都停留在设想,具体能实现到什么程度,在真实网络环境中运行咋样,以及对性能的影响,也只能说停留在设想中了。。。
p.s. ctrl+c 掉程序没有清理 tc 钩子,下次重启进程得手工删 tc 。。。

再次感谢楼主。
很多年前在本站某网友的影响下设置为 254 ,就渐渐成为习惯了
直到今天我家内网有 7 个/24 了还是这样
曾经某一天有了 v6 ,突然发现,这 192.168.0.254 是网关,那 v6 网关是多少?
1. 用 2001:db8::fe ?嗯,有点奇怪,但是其实是问题最小的。(实际上在用这个)
2. 用 2001:db8::1 ?啊,那 192.168.0.1 怎么办?
3. 用 2001:db8::ffff:ffff:ffff:fffe ?*,输入这种地址要死了。
4. 肯定有人说,用 fe80::1 呀?这个,路由没问题,但是如果需要连接到网关呢?(实际上也配置了 fe80::1 ,并不矛盾)
你看,用.1 就这些鸟问题。

有个问题是,有没有机会和现有的 ipt/nft 创建的 dnat 规则甚至 snat 结合使用呢?
有考虑过自己搓一个,用 ipt/nft 写 snat ,对于匹配某些东西的 snat 到某些特定的源端口(范围),然后在出口侧抓住这些内核 nat 过的源端口,对与这些源端口相关的报文/连接/端口进行 full cone 的……不过不知道能实现到什么程度,以及代价到底怎么样
再赞一遍。
p.s. 用 netns 测试了 v4 ,好像没有理睬用 ip l s mtu 设置的 mtu ,设置为 1480 仍然是按照 1500 拆包的
用单个 wg 的话
给自己发 4 个配置文件,然后起 4 个 wg 隧道
假如四个 wg 客户端 ip 分别是 198.51.100.1-198.51.100.4 ,接口分别是 wg1-wg4
那么可以加路由
ip r a default dev wg1 table 1001
...
ip r a default dev wg4 table 1004
然后加规则
ip ru a f 198.51.100.1 table 1001
...
ip ru a f 198.51.100.4 table 1004
然后加出口 nat 规则(可能需要适当调整一下,比如结合默认路由的 srcip )
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.25 -j SNAT --to 198.51.100.1
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.33 -j SNAT --to 198.51.100.2
iptables -t nat -A POSTROUTING -m statistic --mode random --probability 0.5 -j SNAT --to 198.51.100.3
iptables -t nat -A POSTROUTING -j SNAT --to 198.51.100.4
然后就可以把不同的连接丢到不同的 wg 上了……
必要时调整 rp_fillter 。

如果用多个 wg ,或者其他 vpn ,可以考虑类似 ecmp 的实现,或者分别随机打标签……
单个 wg 不能这么做是因为客户端地址是同一个的话,wg 这种三层 vpn 没办法路由到不同的客户端去。
确实是天天 vpn 回家,然后出国策略什么的都在家里路由器上
不过呢
家里挂了就很难受
分配 fd 开头的私网 v6 然后做 nat/snpt
298 天前
回复了 s82kd92l 创建的主题 宽带症候群 移动最近线路是不是有点炸啊
移动去什么北美
香港,新加坡,日本
它不香吗
北美的话推荐用联通
北京移动也有一批“神秘 ip”是这么处理的
实测只影响家宽和蜂窝网
idc 还是普通路由
问题是,
谁同你 peer 呢?
344 天前
回复了 prayzzz 创建的主题 宽带症候群 移动宽带师傅要求上门拍照
二百多 GB 就上门拍照啊?也太事儿了吧
旁路由的 wan 口接主路由的 lan 的话,就相当于二级路由,
* 对在这个路由器下面的设备来说,这个设备就是主路由,
* 但是对于接到原本的主路由上的其他设备来说,绝大多数情况下无法使用这个旁路由
@neos2014
不管用 openvpn 还是 wg 还是其他东西,都可以这样指定 vpn 客户端的下一跳(在 vpn 服务器上):

ip ru add from vpn 网段 table xxx
ip r a default via 旁路由 table xxx
会把所有流量转发给下一跳(你的例子是旁路网关),所以翻墙策略都是可用的
必要时可能还要 snat 一下,取决于下一跳的配置:iptables -t nat -A POSTROUTING -s vpn 网段 -o 去下一跳的网卡通常是内网网卡 -j SNAT --to 一个下一跳接受的内网 ip

命令都是手敲的如有报错敬请见谅

tailscale 其实是多点互联用的……这里只做出口的话,openvpn server 就相当于 exitnode 了
同 2 楼,基于 linux 一般发行版自己搭一个
按照自己的喜好添加模块扩展功能
~~极其稳定~~ (虽然结果上是这样没错)
极其考验设计和实现
我家情况类似,联通+移动,常年 openvpn 回家
基于 rockylinux 的软路由做核心路由器
1. ddns:用自己的域名开策略解析啊。维护两个子域名(我都有公网所以都是双栈,其实一个双栈一个只有 AAAA 也没问题),然后自建了一个策略解析 dns 服务器,也可以买国内的带策略解析服务的 dns 服务。udp 跨不跨运营商体验云泥之别。
内网如果忘了关 vpn 的话,建议再加个内网 dnsmasq 记录直接把 vpn 域名劫持到 vpn 服务器上。
不想搞这么复杂就弄两个 ddns ,自己手工选择。
2. 翻墙:这种事情……旁路由的话得 vpn 出来指向旁路由,虽然也不是做不到就是了。ip ru add from vpn 网段 table xxx ,ip r a default via 旁路由 table xxx ,大概这样,必要时可能还要 snat 一下。主路由都这么复杂了干嘛还念念不忘旁路由呢?
3. 为什么这里没有用 wg ?
a. openvpn 支持两种协议,爱开 tcp 就开 tcp ,爱开 udp 就开 udp 。
b. wg 只在连接的时候解析一次域名,当然会有保活检测,这里还需要一个网络变化重新解析域名的。比如我手机也是联通+移动双卡,切换网络甚至回家之后就希望用新的 ip 连(会比较快)。不知道有没有合适的客户端。跨运营商这种事情真的就是中国特色。
c. 2024 年了,越来越多的设备都有硬件 aes ,没必要死磕 cpu 去算 chacha20 。
b+. 为什么回家还要开 vpn 呢?还是中国特色,总有恶心的 app 想通过运营商接口偷窥我手机号,直接给他个 vpn ,嘿嘿。
桥接解君愁。北京联通打电话就可以要求桥接。
另外家宽普通线路不支持 v6 的话是可以投诉的。
用什么协议? v4 ,v6 还是双栈? dns 解析正常吗?
不可能没有任何提示的,如果有,说明 vpn 客户端不太靠谱,不管换不换协议,先把客户端换了。
我用 openvpn 每次都能连上
2023-12-25 08:46:01 +08:00
回复了 jingrs489 创建的主题 宽带症候群 请教: ipv6 是不是也有公网、内网地址之分?
@keegan fe80::开头的 ipv6 地址不是通常说的“内网地址”,而是“本地链路地址”,对应 ipv4 的 169.254/16
地位等同于 ipv4 的 192.168/16 (以及其他两段)的地址的 ipv6 是 fc00::/7 ,但是在分配的时候有一些额外的“要求”(并且实践的时候时不时被无视)
区别是,fe80::的地址不能被路由转发(尽管可以做为下一跳地址)
临时地址也不一定是内网地址

关于 ipv6 特殊地址 ref:
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
https://zh.wikipedia.org/wiki/IPv6#%E7%89%B9%E6%AE%8A%E4%BD%8D%E5%9D%80
1  2  3  4  5  6  7  8  9  10  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5544 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 08:00 · PVG 16:00 · LAX 00:00 · JFK 03:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.