背景

有时候，因为种种原因，我们希望我们的机器能被其他一些原本访问不到我们的设备访问。
比如:

1. 做微信开发调试的时候，需要配置回调地址，也就是我们能访问微信的服务器，但微信的服务器需要访问我们时缺不行。
2. 我们想要分享一些资料、文件、服务给不在同一个局域网的人。

这些情况下，我们需要的技术方案，被称为 内网穿透。

反穿可选方案

社区中，有很多这类工具。

ssh

最简单的就是 ssh 的方案，只要开启了sshd，本地有ssh就能够实现，既然都在玩服务器了，又有几个没有 ssh 的呢。
使用起来非常简单：

# -R 和 -L 的差别只是翻转了，本身实现的效果是一样的
ssh -R 0.0.0.0:8081:0.0.0.0:8081 root@xx.xx.xx.xx

ps: 如果你发现远端监听的是 127.0.0.1:8081 的话，是由于 sshd 的一个安全配置，vim /etc/ssh/sshd_config , 修改 GatewayPorts: yes 然后 systemctl restart sshd

上面这样，就把服务器的 8081 端口 代理到了本地的 8081。这个方案最大的优点就是 简单 ，在调试时使用十分轻便。
问题有两个： 1. 不够稳定，容易断掉。 2. 只支持端口映射，更复杂的功能不好实现。

另外，ssh 其实是可以直接实现 socks 代理的，这样的目的在于，仅使用一个端口，就能实现对所有端口的访问：

# -f 为后台运行 -N 为不运行任何命令 -D 为动态代理  -q 为 quiet 模式
ssh  -qfND 0.0.0.0:1080 root@xxx.xx.xx.xx

autossh

对于ssh方案而言，最难搞的问题还是 不稳定，于是可以用 autossh 的方案解决。使用起来和 ssh 类似，不过多了一个监听端口：

autossh -M 8082 -fNR 0.0.0.0:8081:0.0.0.0:8081 root@xx.xx.xx.xx

这个方案最大的优势就是 解决了 ssh 断线重连的问题。因此，在开发调试时更加好用，而且 -f 参数支持了后台运行，比较优雅地解决了需要维持终端持续打开的问题。

基本上，在有一些临时性的穿透需求时，这个方案已经十分够用了。对于复杂功能的需求实际上不是这个工具要解决的问题，例如 udp、http、端口复用 等等。

frp

上面说的两种方案，主要是临时使用比较方便，但在功能的丰富度上还是十分不足的，毕竟 ssh 的主业是做加密登录的，端口映射只是副业。 而 frp 是则专门做内网穿透的。
如果希望提供比较稳定的内网穿透服务，那么选择 frp 就是比较好的选择了。

frp 分为 服务端 和 客户端，需要两端部署。通过 .ini 配置文件进行管理。支持 tcp、udp、http、ssl-tcp、ssl-udp、p2p 的配置，还对 http 代理做了一些优化(类似于 nginx 的一些功能)。

关于frp，官方文档介绍的肯定比我详细，可以参考 frp文档

nps

nps 和 frp 是同样定位的应用，两者在功能上也几乎一致，不过值得一提的是，nps自带官方的可视化管理页面，这点比frp在易用性上增加了不少(当然frp也有几个简单的社区版可视化工具)。

同样，详细可以参考 nps文档

实际上，类似的工具还挺多，在 github 上还扒到另一个项目： https://github.com/mmatczuk/go-http-tunnel , 再比如和 nps 类似的 ngrok (ps: 这个项目1.0是开源的，2.0搞成商业项目了，然后1.0就不开发了，有nps代替基本可以不用关注这个项目了)

nps 除了可以做 端口映射，还能做 反向代理 、正向代理 、加密代理

一些其他的想法

上面说的 内网穿透，是解决网络通路的其中一种场景，除了上面这些方案，还有一些其他的方向，举些栗子：

NAT映射

这种解决网络通路的方案，通常用在 网关 处，可以根据 网卡、ip、端口 做响应的转发。可以用 iptables 写 snat 和 dnat 规则。

反向代理

反向代理最常见的就是充当 应用网关，通过对 协议、域名、路径、header 等等做匹配，转发到内网中的不同服务上去。对于提供网络应用的软件来说，这种方式几乎是必然的。

传统应用中，最广泛的反向代理服务器就是 nginx。在云原生逐渐成长起来之后，ambassador、envoy、kong、candy 等应用网关也顺势起飞了。

代理

对大众而言，最常接触到的解决网络通路的场景，还是 代理，为了和反向代理区分，我们不妨叫它 正向代理。

使用正向代理的场景很明确： 当我们的机器 A 无法访问机器 C，但是另一台机器 B 能访问机器 C，同时我们的机器 A 能访问机器 B，那么，机器 A 就可以让机器 B 代理 A 的请求，访问机器 C。

大众最常见的例子是，在国内，想要用手机看油管的视频，就需要安装代理软件。这个场景中，手机就是 机器A，油管的服务器就是机器 C，代理软件连接的服务端就是机器 B。

举个开发场景的例子：
公司开发环境的服务器A在公司内网，并且做了网络白名单，仅有特殊的网段能够访问，你的电脑不在这个特殊网段内，有一台机器B就在这个网段，你能访问这台机器 B，那么你就能通过机器 B 访问开发环境的服务器 A。通常，这个机器 B 可能是一个 跳板机，或者是一个 vpn。

我们通常认为，代理是为了解决 网络不可达 问题的，有些时候，代理也为了解决 不那么可达 的问题 ，俗称 网速慢。

比如在玩游戏这件事上，一些国外服的游戏，在国内玩起来就很慢，类似的还有看视频等场景。这种时候的代理，都是为了 加速，往往会采用 udp 的方案，可以参考 UDPspeeder

如果要自己建立网络代理服务，最常见的方案是 ss 、open VPN , 这相关的资料网络上十分丰富，就不多说。

在 mac/windows/iphone/android 上安装代理客户端比较简单，但是在 linux 上安装代理客户端就相对不那么常见了，之前为了安装 helm，解决过在服务器上安装客户端的问题，详情可参考 如何解决linux下的代理访问

网络相关的内容

网络连通性还有一些其他方面的，平常可能用得比较少。

p2p

是 peer to peer 的缩写，现在最多的应用场景是 p2p内容分发网络，比如大家说的 种子下载。另外，在区块链上，也使用了相同的技术。另一种比较大众的应用场景，就是 语音电话、视频电话 。

p2p 用在私有领域，可以用来作为 安全通信 的技术方案，例如私有部署的即时通信。除了通信，还可以作为安全文件传输的方案，相关信息可以参考 magic-wormhole

nc

在网络转发这件事上，nc 无疑是一个非常精悍而强大的工具。

• 可以用作简单的网络过滤器 (接受和拒绝host)
• 可使用 socks 代理
• 可监听 ssl
• 单向接受或发送
• 命令串联 (类似于 pipeline)
• 模拟延时收发
• 监听 udp / tcp

nc 可以监听 udp 端口， nc -v -lu 60001 ，也可以连接 udp nc -vu 46.46.46.46 60001
nc 可以转发端口 (延时 1s 收发)
nc -v -d 1s -lkp 8888 -c "nc 127.0.0.1 50110"

可以参考文章：linux端口转发的几种常用方法

k8s 开发网络代理

一般我们认为，要访问 k8s 中的服务，有这样几种方案：

1. nodeport
2. loadbalancer
3. ingress

在开发调试阶段，我们有时候想直接访问 k8s 中的服务，但是这个服务在 k8s 中仅有 ClusterIP，单独为这个服务创建 LB 也划不来，这时候可以使用 kubectl port-forward [podname] [local port]:[pod port]，如果遇到需要 port-forward 的数量比较多的时候，这种方式就比较麻烦了，此时需要批量转发，可以参考 kubefwd，也可以参考可视化的项目 kube-forwarder

除了想在本地直接访问集群中的服务，有时候我们也想把集群中某个服务所收到的流量，转发到我们本地端口，这样就可以实现方便地调试。

我们目前使用的方案是 devspace，具体信息可以查看 devspace

其他可以考虑的方案可以查看

• telepresence
• ktunnel
• nocalhost
• okteto