-
Notifications
You must be signed in to change notification settings - Fork 112
faq
hev edited this page Oct 24, 2022
·
1 revision
NATMap可以打通运营商完全锥型NAT网关的端口,使得通过运营商网关的公网IP:端口能够访问到用户内网的服务。
TCP和UDP协议。默认是TCP协议模式,启用-u
参数为UDP协议模式。
根据数据流转路径的不同,可分为三种运行方式:
- 直接绑定模式,natmap和业务服务端同时运行在分配了私网IP的用户路由器上,natmap负责打通运营商网关的端口映射,业务服务端直接负责侦听并接受处理外部访问请求,用户侧数据无中转。
- 防火墙中转模式,natmap运行在分配了私网IP的用户路由器上,业务服务端运行在其它主机,natmap负责打通运营商网关的端口映射,用户路由器防火墙的端口转发配置负责将外部访问中转至业务服务端处理。业务服务端可以直接获取客户端原始IP:端口信息。
- natmap中转模式,natmap运行在分配了私网IP的用户路由器上,业务服务端运行在其它主机,natmap负责打通运营商网关的端口映射以及侦听并接受外部访问请求,再将外部访问中转至业务服务端处理。业务服务端不能直接获取客户端原始IP:端口信息。
根据数据转发的额外开销程度,由低至高分别是:直接绑定模式 < 防火墙中转模式 < natmap中转模式。natmap中转模式的优势是免除防火墙端口转发配置,使用简便。
NATMap目前支持Linux、BSD、macOS和Windows等系统。
由于natmap和业务应用服务器需要绑定同一个源端口上,因此需要注意的是:
- 在Windows系统上,使用TCP直接绑定模式,TCP应用服务器要确保绑定在局域网的本机IP上,而不能是
0.0.0.0
和::
。UDP直接绑定模式与TCP刚好相反,UDP应用服务器要确保绑定在0.0.0.0
或::
地址上,而不能是局域网的本机IP。 - 在Linux系统上,使用直接绑定模式当应用服务器没有启用
SO_REUSEPORT
特性的情况下,natmap会尝试跨进程打开该特性以允许同时绑定同一端口,但该功能依赖Linux 5.6及以上版本内核,并且要求两者在同一个进程命名空间(即不能跨容器)。
对于TCP、UDP协议的服务,访问服务需要IP:端口信息。在natmap打洞的网络场景中,IP和端口均是动态的,利用域名解析方式访问的一种参考实现是使用DNS的AAAA记录同时记录IPv4地址和端口号,并在客户端侧增加相应的支持。这样只要natmap在建立映射后,调用脚本通过DDNS的API将IP和端口更新到DDNS的AAAA记录中,客户端再通过域名解析即可同时获得IP和端口。
这种将IPv4地址和端口同时编码在DNS AAAA记录中的方式在NATMap中称为IP4P地址格式,目前支持该方式的客户端有:
- frp - https://github.com/heiher/frp
- fsh - https://github.com/heiher/hev-fsh
- wireguard-android - https://github.com/heiher/wireguard-android
IP4P的字段:
2001:0000:0000:0000:0000:XXXX:YYYY:ZZZZ
---- ----
- XXXX: 端口
- YYYY: IPv4高16位
- ZZZZ: IPv4低16位
IP4P使用的IPv6地址段(2001::/32)是保留给Teredo tunneling业务的,但并不会与Teredo业务冲突,因为划线部分在IP4P中恒定为0,而在Teredo中为服务器地址(不可能为0)。因此,识别IP4P的方法是检测前辍是否为:2001::/80
请通过Issue提问: https://github.com/heiher/natmap/issues/new