我处于受限制的networking中，并且在OpenVPN P_CONTROL_HARD_RESET_CLIENT_V2之后，我的连接到我的OpenVPN服务器（TCP / 443）的尝试被TCP RST欺骗中断。 我logging了双方的stream量，并注意到双方都收到了连接重置，但是双方实际上都没有产生连接重置，即RST是从防火墙中注入的。
有没有办法掩饰OpenVPN看起来更像是正常的HTTPSstream量？
我find了一个解决scheme，并希望分享。
正如其他地方所述，防火墙可能会阻止VPN连接和stream量，例如通过阻塞端口或执行深度包检测（DPI）由OpenVPN创build的连接和stream量。
在第一种情况下，使用不同的端口（例如https端口443）就足够了，但是对于以后的版本来说，更精确的方法是必要的。
DPI现在被越来越多的防火墙所使用，包括中国的“长城”。 显而易见的解决scheme是将VPNstream量伪装成其他一些stream量，即防火墙不阻塞。 HTTPS使用的SSL / TLS是一个完美的select，因为内容在握手之后被encryption，使得防火墙无法识别传输的数据。
为了在SSL / TLS连接内传输 OpenVPNstream量，可以使用类似stunnel的SSL隧道，如此处所述。 它更加降低了连接性能，但是使得防火墙无法区分通过安全连接访问网站的用户或使用VPN的用户（请注意，防火墙在超时或数据量限制之后可能会中断连接） 。
另一个解决scheme，不会导致性能受到打击， 这里解释。 这种方法使用同一端口回复两个到同一服务器的连接，使用OpenVPN的function，允许OpenVPN服务器将非OpenVPNstream量转发到同一台服务器上的另一个应用程序。 第一个连接将是默认的HTTPS连接，防火墙不会阻止此连接，因为防火墙会将TLS握手标识为有效的通信。 在远程站点上，OpenVPN将此stream量转发到启用了SSL的nginx服务器，该服务器将回复并设置TLS连接。 build立连接之后，OpenVPN连接将看起来像encryption数据，它是TLS连接到nginxnetworking服务器的一部分，但是将由OpenVPN服务器正确标识。
我还没有testing第二个连接，但是我预计它会比第一个解决scheme的稳健性差，因为nginx连接可能在某个时候closures，使得OpenVPNstream量突出。