什么是内网穿透？一次讲清原理【图文讲解】
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
内网就像一道天然的隔离墙，保护着局域网内的设备，可是这样一个内网也有一个现实的问题，就是没有公网 IP 的主机很难被外界网络直接访问。 而内网穿透，正是为了解决这个问题所诞生的技术，它利用处在公网之中的中转节点建立内外网之间稳定的一条隧道，使得外网的流量能到达藏在 NAT 之后的服务。 一、什么是内网穿透？ 假如，我们在家里的电脑上运行了一个 Web 服务，而电脑的局域网地址是 192.168.1.100，服务监听 3000 端口。手机连上接同一个 Wi-Fi 之后，打开 http://192.168.1.100:3000，就能看到网页。 现在把 Wi-Fi 关掉，改用移动网络再去访问这个地址，这个时候就打不开了。这是因为 192.168.1.100 只在对应的私有网络中才有意义，并不是这台电脑在整个互联网中的唯一地址。你邻居家的电脑，也完全可能使用相同的这个地址。 这就如同不同的小区都可以有“3 栋 201 室”。而在小区里面，楼栋、门牌足可以找到住户；从外地寄快递，只写“3 栋 201 室”，快递员是不知道应该送到哪个小区的。内网访问所遇到的第一个问题，也正是缺少一条从外部到目标设备的可达路径。 内网，一般是指家庭、学校、企业内部所使用的网络。而公网是大量网络互联所形成的、能按照公共路由体系转发数据的网络。家庭中常见的内网 IPv4 地址来自于以下三个私有地址段。 另外，路由器的 WAN 地址也不一定是真正可以入站访问的公网地址，因为运营商有可能在家庭路由器外面又做了一层地址转换。而常见的 100.64.0.0/10 是供运营商级 NAT 等所用的共享地址空间，不能将它当成 RFC 1918 私有地址，也不能将它当成普通的公网地址。 NAT 的全称是 Network Address Translation，即网络地址转换。而家庭路由器一般还会转换 TCP 或 UDP 端口，这样地址和端口一起转换的方式，叫做 NAPT，也常被称为 PAT。 假如电脑从 192.168.1.100:51000 访问公网服务器，而经过路由器之后，服务器看到的来源就可能变为 203.0.113.10:62001。路由器保存好相应的转换状态，响应回来的时候将目的地址及端口转换回电脑的地址及端口。 这里 51000 就是电脑发起这次外连所使用的临时端口，而与本地 Web 服务所监听的 3000 端口，并不是一回事。 如果外部设备突然向路由器的一个端口发起一个新连接而没有相应的映射规则，路由器就缺少将它转给哪台内网设备的依据。即使有映射，防火墙也可能拒绝这次访问。因而这里要解决的是两个不同的问题：NAT 负责地址和端口的转换，而防火墙负责决定哪些流量可以通过。 内网穿透解决的，是当外部设备无法直接连接内网中的服务时，如何运用代理、隧道、地址发现或是中继的机制使二者能通信。 它可以给本地服务一个公网的入口，亦可以让安装了相应客户端的两端形成一个私有的访问通道。而实现之后电脑还是可以使用原来的内网 IP，Web 服务也仍然运行在本机。 就应用而言，变化发生在访问路径上，即外部用户原先没有路可走，而现在可通过一个约定的入口或是通信机制找到所要的服务。 先看一个不涉及到内网穿透的。浏览器访问一个网站，一般先是通过 DNS 得到服务器的地址，然后向该地址的相应端口发起连接。而以采用 TCP 的 HTTPS 为例，客户端完成 TCP 建连及 TLS 握手后，发送 HTTP 请求，服务器返回相应的响应。 这样一个过程能够成立，是由于服务器有可达的地址、目标端口上有服务在监听，而且沿途的策略允许通信。而客户端本身是可以位于 NAT 后面的：它主动发起连接以后，网络设备将为这次通信建立相应的状态。 公网地址解决“数据往哪里送”的问题，而端口对应一个具体的服务，协议规定双方是如何交流的。三者就构成了一次可用的访问。 将网站的服务器换成家里的电脑，就有可能遇到多层障碍，因为电脑是使用私有地址的，而外面没有直接路由；家庭路由器没有端口映射；而且运营商很可能在上游使用CGNAT；主机或是路由器的防火墙也有可能不允许入站连接。 这样的限制可以叠加出现。所以在电脑上“开放 3000 端口”，不等于外部用户已经拥有一条到达它的路径。而将域名解析到一个地址，也只完成了名称到地址的对应，是不会自动建立 NAT 映射或是放行防火墙的。 要按实际的路径一层层去排查，服务是否监听、局域网能否访问、边界设备是如何转发的、上游是否有地址转换。 对于一般的反向隧道方案，可以将过程分为两个动作：内网设备首先主动连接一台可达的公网服务器；而公网服务器将所收到的业务数据，通过这一已建立的通信通道交给内网设备。 理解这其中的 key ，是要分清连接发起方向和数据传输方向，而 TCP 连接，虽然是一端发起的，但是建立以后，双方都能够发送数据。 这就如同家里的人先给服务台打通电话，电话是家里拨出去的，可是接通以后，服务台同样可以说话。只要这通电话保持着，服务台就可以将外面访客的信息告诉家里的人。 这样方案的前提，是内网可以访问所需要的公网地址、端口及协议。而后介绍的 P2P 方案将要尝试建立双方直连的路径。 假定公网服务器已经和内网客户端建立了连接，而外部用户发来的 Web 请求首先到达公网服务器，服务器将这些业务字节交给隧道协议，内网客户端从隧道中读出数据并转交本地 Web 服务。 对于路由器而言，这些数据是已经建立的通信所携带的流量，而路由器不需要去理解它是网页请求、SSH 命令还是文件内容，它只需要根据网络的状态及过滤规则处理外层的数据包。 实际工具可能会复用一条连接中的多个逻辑流，也可能建立独立的工作连接。因而，“一条隧道”是逻辑上的一个表达，不必对应唯一的一条 TCP 连接。 路由器端口映射，是配置一条入站规则的，比如将路由器外侧的 8080 端口映射到内网电脑的 3000 端口。而反向隧道是在一台可达的公网服务器上提供一个入口，然后通过内网主动建立的通道传输业务。 在典型的公网转发的架构之中，有内网客户端、公网服务器、外部访问者三个角色。而要看到数据最终是到了哪里，还要将内网中的目标服务单独画出来。 公网服务器就是一个可以被找到的接待处，它接收外界的连接，确定这个连接是对应哪一个内网的服务，然后将数据交给相应的客户端。 如：服务器上 8080 端口可关联家中的 Web 服务，而另一个端口关联开发板的 SSH 服务。HTTP 代理还可以根据域名等信息选择后端。公网入口与内网服务的关系，是通过配置及会话状态所维护的。 服务器的职责是随着方案的变化而变化的，其中在中继模式下，它承担业务的转发；而在 P2P 模式下，协调服务器可能主要帮助双方交换信息，直连成功后的业务数据将不再经过它。 在常见的网络策略之下，内网的设备是可以发起出站连接的，而外部主动入站受到更多的限制。由客户端先连接服务端，就可以运用已有的出站能力建立一个通信通道。 客户端还要告诉服务端自己是谁、要注册哪些代理、怎样关联目标服务，而服务端，并不是看到一台电脑上线就可以随便访问它的所有端口；可访问的范围是取决于代理的配置及访问策略的。 客户端也不一定安装在目标服务所在的设备上。只要它可以访问那台设备，就可以代为转发。比如：在同一局域网的网关上运行客户端，然后将请求交给不便安装软件的设备。 隧道可以理解成为：使用一种通信机制，承载另一种通信的业务数据。而内网穿透软件将处理通道标识、数据的转发、连接的关闭以及必要的身份验证、加密工作。 这一条通道既可以承载 TCP 字节流，也可以按实现承载 UDP 数据报。而此通道一般不会让用户得到内网中的全部网络能力，譬如：只发布一个 Web 端口，并不意味着访问者能够发现所有的局域网设备 如果需要像接入局域网一样去访问多个网段、多个服务，而且还涉及到虚拟网卡、路由及访问控制等，这就超出了一个端口转发的范围。 图中要分清楚两个端口，7000 用于穿透客户端连接服务端，8080 是提供给外部用户的一个业务入口，而客户端收到业务数据后，再连接本地的 127.0.0.1:3000。 这里假定客户端和Web服务是在同一台电脑上，而如果二者不在此一台设备上，目标地址就应该改为客户端所能到达的内网地址。 客户端启动后，读取服务器的地址、认证信息及代理规则，然后主动去建立连接，而这个连接是经过家庭路由器的，必要时还要经过运营商的NAT。 每一层参与转换的网络设备将要维护相应的状态，使得符合规则的返回流量能够到达客户端。而服务端接收到连接后将作身份验证，并登记客户端所申请的代理。 注册完成之后，客户端和服务端就保持着一条可用的通信通道，而工具一般通过心跳、保活及重连机制来检测链路的状态，以防止设备离线后仍然将流量交给失效的连接。 保活间隔要和实际的网络条件相结合，链路断开后重新建立隧道可恢复后续的访问，而此前中断的业务连接能否继续，要看上层协议是否支持重试、续传或是会话恢复。 控制信息和业务数据可以走不同的连接，也可以复用底层连接，而理解其中的原理，应当将“管理通道”和“承载业务的通道”在逻辑上分清。 外部用户在浏览器中访问 http://198.51.100.20:8080。而浏览器所连接的是公网服务器上的业务端口，而不是直接连接家里电脑的私有地址。 如果公网入口上还配置了域名、HTTPS 以及身份验证，用户所看到的就将是一个普通的网站地址。而服务器如何去找到内网服务，对于浏览器来讲是透明的。 服务端接收到连接之后，会按照配置找到相对应的代理，将这个外部连接和内网侧的工作通道关联起来，然后转发业务数据。 使用 TCP 代理的时候，服务端主要处理的是字节流，不一定理解 HTTP 的请求路径。而使用 HTTP 代理的时候，是可以按照域名、请求头等应用层的信息来进行处理的。代理工作在哪一层，就决定了它能够做哪一些判断。 客户端从隧道中取得数据，连接到目标服务 127.0.0.1:3000，并将数据写入这个本地连接。Web 程序按照原来的方式处理请求，生成页面、JSON 或其它的响应。 这里的 127.0.0.1 始终表示“运行客户端的这台主机”。而如果客户端是位于容器中的话，它通常是指向容器自身；容器外的服务需要使用容器可达的地址。 此外，目标服务看到的连接来源有可能是代理客户端，而不是真实的访问者。保留原始的来源信息，需要结合受信任的转发头或是 PROXY protocol 等机制，并且由后端正确识别。 Web 服务将响应交给内网客户端，客户端通过隧道将之回传，公网服务器再将这些数据写入外部用户的连接。 从逻辑上来看，存在浏览器及公网服务端、隧道两端、内网客户端与目标服务这几段的通信。穿透软件负责将相对应的数据流衔接起来，外部用户才能看到完整的响应。 连接关闭时，软件还要释放所关联的资源；而发生超时、断线或者后端拒绝连接的时候，则应当将失败传递给相应的访问者。能建立隧道，只说明通信基础就绪，并不表示目标服务一定正常。 反向代理是由代理服务器接收到访问，然后再把请求转交给后端。在内网穿透的场景之中，公网代理是需要借助反向隧道等机制，获得到内网后端的可达路径。 比如，在公网部署 Nginx，并将后端写成家中的 192.168.1.100，这个时候是不能直接访问成功的。还需要 VPN、专线、隧道或其他可达条件。而反向代理是负责如何去接待和转发，连接机制是负责让转发真正到达后端。 这样一种组合是适合集中管理多个 Web 入口的，而且可以在公网侧对域名、证书及访问认证作统一的处理。 OpenSSH 的 -R 参数可以在远端服务器是创建监听端口，并将收到的连接通过 SSH 通道转发回本地。 假设本机 Web 服务运行在 3000 端口，公网服务器允许该账号进行远程端口转发，那么可以在内网电脑上运行： -N 表示不执行远程命令，-T 表示不分配终端。-R 中前面的 127.0.0.1:8080 是公网服务器上的监听地址，而后面的 127.0.0.1:3000 是从内网 SSH 客户端一侧访问的目标。两处回环地址是属于两台不同的主机。 此时，在公网服务器本机访问 http://127.0.0.1:8080，就会到达内网 Web 服务。若要提供公网网站入口，可以让同一台服务器上的反向代理接入这个回环端口，并配置 HTTPS 及访问权限。 如果希望远程转发端口直接监听公网接口，则需要配合 GatewayPorts 等服务端设置以及防火墙规则。默认的回环监听是不会自动对外开放的。上面的保活参数是用来发现异常的；自动重连，还要有进程管理器等机制。 FRP 将上述的能力封装成了专门的客户端和服务端，其中内网运行 公网服务器上的 内网电脑上的 两端需要替换成同一个随机令牌，并使用真实服务器地址。然后分别启动： 服务端允许所需入站流量、代理注册成功且本地服务正常后，访问公网服务器的 这里的令牌认证的是 frpc 与 frps 的连接，并不是 Web 访客的登录凭证。示例中的 TLS 也只保护了客户端和服务端之间的隧道，浏览器访问 http://...:8080 仍然是明文 HTTP。实际对外发布的时候，还需要为业务的入口配置好 HTTPS 和用户认证。 FRP 的默认 TLS 加密也不等于已验证了服务端证书，需要通过可信 CA 等配置验证服务端的身份，相关证书配置应按部署环境予以补齐。 Ngrok 提供是的托管的公网接入服务。用户在本地运行一个 agent，由这个 agent 它主动去连接平台，再把平台入口所收到的流量带回本地。公网服务端的部署维护工作由平台承担。 安装好并且完成账号认证之后，发布本地 运行后，使用工具实际显示的公网地址去进行访问。它适合本地项目的演示和 Webhook 调试：远端平台向公网地址发送回调，开发者便可以在本地程序中接收和调试。 选择托管服务的时候，需要结合实际套餐核对可用协议、域名、访问策略和流量条件。这一些限制属于服务产品的配置，并不是隧道原理本身的限制。 服务器转发方案很容易理解，但是全部业务数据都需要经过中间的服务器。P2P 穿透则会借助协调服务交换候选地址，使两端主动发送探测数据，尝试形成可用的直接通信路径。 以常见的 UDP 打洞为例，双方在相近的时间向对方的候选地址发送数据，使得各自的 NAT 建立相对应的映射和过滤状态。如果这一些行为能够配合，那么后续的业务就可以直接往返。 “打洞”利用的是网络设备所允许的映射与过滤行为。它的成功率受两端网络共同的影响，我们不能仅凭一侧地址就做判断。TCP 也有相关的穿透机制，但是不能把 UDP 的步骤直接照搬到 TCP 上去。 如果两端不能建立直连，就可以通过双方都能够到达的中继服务器交换数据。中继增加了服务器带宽开销，却能覆盖一些直连无法完成的场景。 我们可以先尝试直连，然后再回退中继；也可以先用中继建立一个可用的通道，同时继续探测直连。至于采用哪种顺序，以及已有会话能否切换路径，取决于具体实现。 TURN 是一种标准化的中继协议，但是中继服务器未必都会使用 TURN。FRP 的常规 TCP 转发、SSH 隧道和 TURN 属于不同的机制。 “内网穿透”更偏向于应用目标：让原本难以从外部访问的服务能够被访问。“NAT 穿透”则聚焦于跨越地址转换所带来的连接障碍。它们两个存在一定的交集，但是并不是严格的一一对应的关系。 想要理解 NAT 对直连的影响，只需要分别看映射和过滤。其中映射决定内网地址、端口对外呈现成什么地址、端口；而过滤决定哪些外部来源可以经这个映射把数据送进来。 例如，同一个内网 UDP 端口访问两个公网目标时，可能会保留同一个外部映射，也可能获得到不同的映射。与此同时，设备又还可能只接受某些来源的数据。只知道外部端口是多少，并不足以保证对端能够访问它。 很多文章会沿用全锥型、受限锥型、端口受限锥型和对称型这四种传统的叫法。下面用它们帮助理解 UDP 场景中的典型差异。 STUN 的全称是 Session Traversal Utilities for NAT。设备向 STUN 服务器发送请求后，服务器可以在响应当中告诉设备：“我看到你的来源地址和端口是什么。” 例如，设备本地使用 192.168.1.100:50000，服务器所看到的来源却是 203.0.113.10:62001。这样一个外部观察的结果可以作为候选地址，交给另一端进行连通性检查。 但是，如果 NAT 会随目标改变映射，那么另一端看到的结果就会有可能不同。所以 STUN 是一个地址发现和连接检查的工具，还需要与信令交换、连通性检查等机制配合，才能构成完整的穿透方案。 TURN 的全称是 Traversal Using Relays around NAT。客户端向 TURN 服务器申请中继资源，取得一个中继地址，然后再通过服务器与对端交换数据。 与 STUN 主要是帮助发现地址、检查连接不同，TURN 会实际承载业务流量。而只要双方能够按协议使用这条中继路径，就不必要求两端之间成功直连。 这种方式会消耗中继带宽，因此服务端通常需要进行认证、资源配额和流量管理。TURN 本身提供中继能力，业务内容的端到端保密还需要由相应加密协议保证。 ICE 的全称是 Interactive Connectivity Establishment。它将候选地址的收集、双方信息的交换、连通性检查和路径的选定组织为一套流程。 候选地址可以包括本地地址、通过 STUN 得到的服务器反射地址，以及通过 TURN 得到的中继地址。双方交换信息之后，会对候选地址组合进行检查，然后再选定可工作的组合用于通信。 这里的“最合适”需要准确理解：ICE 按优先级、检查结果和提名机制选择路径，并不等于对所有路径进行带宽测速后自动选出最快线路。候选信息通常还要通过应用自身的信令机制交换。 家庭 NAS 可以保存照片、文档和备份。建立一个远程访问路径之后，人在外面也可以读取这些资料。个人使用的时候，亦可以把访问限制在经过认证的设备及账号之间。 公司内部的测试系统、管理后台或是开发环境，是可以通过经授权的通道予以远程访问的。而公网入口将进行身份及权限的验证，内网代理只将明确需要使用的服务予以转发。 可以通过反向 SSH 或者专门的穿透客户端建立一个维护通道。在远端连接对应的入口，就能够查看日志、修改配置或者传输程序。 本地的项目通常只能在开发者电脑或者局域网中打开。而建立了公网入口之后，其他人就可以通过网址查看当前的效果，也可以让外部的平台将 Webhook 回调发送到本地程序。 远程桌面是可以借助直接路径或者中继通道来传输画面、鼠标和键盘操作的。 物联网设备可能连接家庭宽带、企业网络或者是蜂窝网络，而公网地址和网络条件是经常变化的。由设备主动连接管理平台，可以建立设备的身份和在线状态的对应关系。 远程诊断、日志采集及按需维护是可以利用已有通道完成的。对于长期在线的低功耗设备，还需要平衡好心跳频率、流量开销和故障发现速度。 安全性取决于公开了哪些服务、是如何验证身份的，以及数据在哪些链路上是加密的。应当分别检查访客到公网入口、入口到内网客户端、客户端到目标服务这几段路径。 比如，隧道使用 TLS，并不意味着浏览器访问 HTTP 入口也受到了保护；允许某个 frpc 注册代理，也不意味着 Web 访客已经登录。业务账号、访问范围、系统更新和日志同样需要管理。 还要看加密是在哪里终止的。如果 HTTPS 是在公网代理处解密的，那么代理就能够处理明文 HTTP；如需要中继无法读取业务内容，就应采用合适的端到端加密方案。 内网穿透和端口映射是有一定关联的，但是不能直接画等号。路由器端口映射是在网络边界配置入站转发规则；而大家常说的 FRP、SSH 反向隧道，则是通过客户端主动连接公网服务端建立访问路径。 如果已经有可达的公网地址，并且能配置相关的边界设备的话，用端口映射可能就足够了。而如果处于一个不可控的上游 NAT 后面，仅仅配置家用路由器一般无法完成访问。 首先要区分是建连慢还是传输慢。建连的时候，工具要发现地址、交换候选、进行多次探测并等待超时或者回退中继。映射行为复杂、UDP 受限或网络的变化，都将会影响这个过程。 要是连接完成之后仍然慢，则就要检查是不是实际走了中继、两端的带宽是否充足，以及链路延迟和丢包情况。部分工具会复用已经建立好的隧道，所以首次连接与后续连接的耗时可能会不一样。 如果希望自己能够控制公网节点、配置和部署位置，并且愿意去维护服务器，那么 FRP 就比较适合。如果主要目标是尽快为本地的项目获得一个可访问的入口，并且希望减少服务端的维护工作，就可以考虑 Ngrok 这类的托管方案。 至于选哪个，要看自己所需要的协议、访问控制、稳定地址和实际流量，然后再结合当前的服务条件来作判断。自建的成本包含服务器和维护，托管的成本则是与套餐和资源使用有关。 如果服务设备拥有全球可路由的 IPv6 地址，访问者也具备可用的 IPv6 连通性，而且沿途的路由、防火墙和服务监听都是允许访问的话，就可能直接连接，而不必为 IPv4 地址转换的问题增加中继。 但是“设备显示了 IPv6 地址”还不够。链路本地地址不能当作公网地址使用；家庭 IPv6 防火墙也可能会默认拒绝未经请求的入站连接。如果访问端只有 IPv4，或者需要一个固定的入口、统一的认证、隐藏设备地址，隧道或代理仍还是有价值的。 主要是看业务传了多少数据。空闲隧道一般只有很少的控制和保活流量，文件传输、视频和远程桌面才是一大流量的来源。此外还有协议头、加密以及重传等方面的开销。 比如，持续传输 8 Mbps 的视频，一小时的业务数据量约为 8 × 3600 ÷ 8 = 3600 MB，按十进制计算就是 3.6 GB。这是业务量的估算，还没有包括协议开销。 如果这些数据要经过中继，中继一般需要接收一份，然后再发送一份， 而网卡累计收发量和云服务的账单不是一个概念的，是按出站、双向流量还是按带宽计费要看服务商的规则。
阅读原文：原文链接 该文章在 2026/11/13 12:47:06 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
