惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
DataBreaches.Net
S
Schneier on Security
T
The Exploit Database - CXSecurity.com
Webroot Blog
Webroot Blog
AI
AI
P
Palo Alto Networks Blog
Attack and Defense Labs
Attack and Defense Labs
WordPress大学
WordPress大学
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
Spread Privacy
Spread Privacy
T
Tor Project blog
罗磊的独立博客
小众软件
小众软件
S
Security Affairs
酷 壳 – CoolShell
酷 壳 – CoolShell
量子位
Apple Machine Learning Research
Apple Machine Learning Research
T
Threatpost
NISL@THU
NISL@THU
博客园_首页
PCI Perspectives
PCI Perspectives
大猫的无限游戏
大猫的无限游戏
IT之家
IT之家
N
News and Events Feed by Topic
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Forbes - Security
Forbes - Security
博客园 - 叶小钗
D
Darknet – Hacking Tools, Hacker News & Cyber Security
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Last Week in AI
Last Week in AI
L
LINUX DO - 热门话题
T
Threat Research - Cisco Blogs
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
腾讯CDC
Security Latest
Security Latest
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
The Cloudflare Blog
A
About on SuperTechFans
爱范儿
爱范儿
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
TaoSecurity Blog
TaoSecurity Blog
宝玉的分享
宝玉的分享
G
GRAHAM CLULEY
雷峰网
雷峰网
F
Full Disclosure
I
Intezer
Cloudbric
Cloudbric
博客园 - 三生石上(FineUI控件)
U
Unit 42

蚊帐

用树莓派给 iMac 加上 Face ID 链接 小米 YU7 三个月驾乘体验 波分单线复用笑传之Custom Combo Broadband 新柏石KNX协议智能家居网关接入 HomeAssistant 广东联通 IPTV 鉴权&抓源脚本(以及碎碎念) 广东电信 IPTV 自助鉴权 + 获取播放列表 为什么我们要拒绝 PON 方案的 FTTR 把 Windows 11/10 不完全转换为 Windows Server 2022 高通410随身WiFi的进阶USB网络共享和IPv6配置 ThinkBook 14+ 锐龙版上手体验 ArchLinux + KDE 一周使用小结 修复 Edge/Chrome 在 GNOME 分数缩放下的窗口位置问题 轻松抓取并解析广东电信 IPTV 全部直播源 虚拟显示器终极解决方案 IndirectDisplay 基于PVE的新网络架构 - 踩坑回顾 蚊子
双方无公网状态下 RouterOS 基于 WireGuard 的组网方案
蚊子 · 2025-01-24 · via 蚊帐

双方无公网状态下 RouterOS 基于 WireGuard 的组网方案

目前各大运营商都在收紧 IPv4 公网分配,而 IPv6 却并不是随处可见(如校园、公司等场景)。在大部分场景下,获得 Full Cone NAT (下称 NAT1)的机会反而相对较多。

我们都知道 WireGuard 是一个基于 UDP 协议的隧道协议,通过 STUN 客户端简单地打个洞就可以在单方 NAT1 的情况下建立隧道,此类教程在 Linux 上已比比皆是,但 RouterOS 有没有 STUN Client 呢?

某人:没有 但是他有docker(

好的,一语惊醒梦中人,这个没毛病。不过其实在打洞这个场景下,无论是 RouterOS 的容器,还是同子网的另一个 Linux 机器,地位是相同的。

那么现在摆在我们面前的还有两个问题:

  1. 怎么确保代打完洞之后,这个端口的数据包发给 RouterOS 上的 WG Server 而不是流向打洞的客户端?
  2. IP 和端口变化了的话,另外一个 peer 怎么获取新的 Endpoint?

省流:

  • /ip/firewall/nat/add action=redirect chain=dstnat dst-port=13231 protocol=udp to-ports=13231 把流量截留住
  • 用 NATMap 的 IP4P 格式把 IP 和端口写到 AAAA 记录里,然后写一个 RouterOS Script 解析并更新。
  • 如果两端都是 Full Cone NAT,你甚至不需要担心这个问题,因为当单端 IP 变更的时候,WireGuard 会继续尝试连接另外一端,而另外一端只要握手成功,就会自动把 Current Endpoint 更新过来。只要不是两边同时掉线,你不需要重新打洞,也不需要更换 IP。

如果你懂得相关知识,想要自己实现,那么看到这就OK了。

如果你想要直接用我整好的容器和脚本,请接着往下看。


由于我的情况是双端 Full Cone NAT,所以我只需要在第一次的时候手动打洞一下,懒得写脚本,谁遇上了可以自己搓一个,我先溜了拜拜(