内网安全网关是我们在零信任上的一个探索，最终目标是安全的访问受保护的内网应用， 一些实际的应用场景比如远程办公，公有云VPC，数据中心访问等。 相比较传统的VPN而言，数据平面会更加轻量级，更加安全，也更加灵活一些。
本文主要包括以下内容：
- 内网安全网关的起源，为什么做这个软件
- 一些产品的特点，包括产品上的和技术上的
- 现状以及未来，实际应用场景，未来希望解决哪些问题
内网安全网关始于一款内网穿透软件，核心技术是保持不变的，但是我们都知道内网穿透是存在安全隐患，几乎所有公司都禁止在内部使用的，所以只能ToC。 ToC又会存在非常大的监管风险，比如某个用户私自搭建了一个黄色网站，部署在家里的服务器当中，然后使用内网穿透软件暴露你的域名给别人提供服务，这种场景出问题必然是法律问题。
所以为了解决这两个问题，我们做了以下方面的思考：首先ToC肯定是不行了，监管不过来，我相信大部分用户是合法使用的，但是只需要用户非法使用，那就存在巨大的风险。
于是ToB就是一个不得不走的路，但是正如前面所说存在安全风险，但是这仅限于公司对员工自己的限制，公司对自身是没那么多限制的，如果通过批准，由运维同事去实施，那么其实也还是可以接受的。 不能接受的是非企业内部员工也能访问得了内部系统。
因此就需要考虑访问前先认证的方式，以往使用的是VPN的方式通过VPN客户端进行了一次认证，我们参考零信任的一些思路，实现了身份认证，具体细节可以参考下一节的内容。
以上便是我们从内网穿透发展成为内网安全网关的一些思考，在遇到问题，解决问题的过程当中寻找无限乐趣。
我们的核心理念是参考的零信任，核心产品思路是减少内网端口暴露面，应用需要先认证再访问，最终的目的就是为了安全的访问受保护的内网，那么需要解决两个技术问题：
- 第一，如何解决内网连通性的问题
- 第二，如何做到相对安全
为了解决内网连通性的问题，我们引入了反向代理的技术，通过在内网部署我们的内网连接器，内网连接器是作为客户端的，主动与我们的公网网关建立长连接，不监听任何端口，因此减少了暴露面。然后通过公网网关反向代理到内网连接器，再由内网连接器与内网应用建立连接，转发数据。
这样就解决了第一个连通性的问题，那么对外暴露的就只有公网网关，那么为了保证安全，需要在公网网关上做认证，我们支持的协议包括四层的TCP，UDP协议和七层的HTTP，HTTPS，两者的认证方式有些差异，但是可以当成一样去理解
我们对所有入栈策略都使用DROP，当员工通过安全终端访问身份认证中心，身份认证通过之后，会下发该员工的身份信息到公网网关，然后员工流量到来前，在公网网关进行认证。然后再按照第一步的流程流量逐步转发到内网应用。
以下是我们实施的一个具体案例的系统架构，希望读者通过该架构能够更好的理解我们的思路。
我们已经在一些个人创业者上做了一些实践，当前阶段我们希望能够解决更大规模，更加复杂场景的问题，未来会在物联网，容器云，公有云互联等场景上进行新的探索。如果您对我们的内网安全网关感兴趣，可以点击以下连接了解更多信息。