HTTPS为什么可以穿越NAT端口映射设备？

Posted 2021-04-30 车小胖谈网络

以下斜体部分是来自读者的问题

HTTPS为什么可以穿越NAT端口映射设备？

我的理解是：当一个TCP连接到达端口映射设备（比如防火墙）时，该设备从实现原理上可以看作是作为后端服务器和前端客户端之间的中间人角色。无论是前期的三次握手类的控制连接，还是后续的数据传输，中间人都与前后端分别陆续完成上述步骤。那么问题来了，HTTPS类的TCP在三次握手后，后续开始证书传输、对称密钥生成等。这个过程涉及到私钥密钥身份认证。而我的防火墙上并没有额外配置证书之类的配置，也没有在客户端添加防火墙证书的操作，就是简单的在防火墙上配置了一个某内部服务器的443的端口映射。结果就通了，想不明白。

 

作者 车小胖

名词解释

NAT  NetworkAddress Translation

PAT   Port Address Translation

CDN   Content Delivery Network

 

之所以产生这个理解偏差，可能是因为不熟悉端口映射（PAT）工作原理而造成的。

为了更好地理解PAT的工作原理，先问自己几个问题：

Q1: 为何事先在NAT设备做端口映射？

Q2: 为何不把公网IP直接配置在https服务器上，而是把公网IP配置在NAT设备上？

Q3: 端口映射（PAT）工作在哪层？

Q4：客户端的TCP连接终结（Termination）在哪里？

 

以下是问题的回答

A1: 只有公网IP才可以在互联网上被用户访问，而服务器的私有IP无法被互联网用户访问，假设公司的公网IP = 1.1.1.1，服务器IP = 10.0.0.1，端口映射将产生这个静态表项。

NAT设备公网IP	NAT设备端口号	服务器私有IP	服务器端口号
1.1.1.1	443	10.0.0.1	443

 

NAT设备一旦接收目的IP + 端口号为1.1.1.1:443的报文，就会转换为10.0.0.1:443，并将转换好的IP报文继续转发给服务器。

A2：如果把公网IP直接配置在https服务器上，那么公网IP就被https服务器独占了，工作在别的端口号的服务器，如21、80、445端口就无法被互联网用户访问。

而在NAT设备上做21、80、443、445端口映射，可以将这些端口分别映射到特定的服务器上。

NAT设备公网IP	NAT设备端口号	服务器私有IP	服务器端口号
1.1.1.1	443	10.0.0.1	443
1.1.1.1	21	10.0.0.2	21
1.1.1.1	80	10.0.0.3	80
1.1.1.1	445	10.0.0.4	445

 

A3：端口映射工作在三四层，三层为IP，四层为TCP/UDP。

 

 

如上图，在NAT设备眼里，TLS及应用层的http仅仅是货物，NAT设备对这些货物并不关心是什么，更不会尝试去理解或修改。

同理，客户端的TLS安全会话也是终结在https服务器上，所以和安全有关的话题，如安全加密组件协商、数字证书认证、服务器的私钥签名、RSA交换密钥算法、DH交换密钥算法等等，都是在客户端与服务器之间进行的，无需NAT设备的参与，所以NAT设备无需任何TLS安全有关的配置，仅仅做好自己本职工作即可。

 

目测题主是把端口映射与前置代理服务器混淆了。

首先来解释一下什么是前置代理服务器？

前置

如上图所示，在https服务器前方，有一个https 代理服务器（proxy），这里的前方的意思是，反向代理服务器比https服务器更靠近客户端，此谓前置。

 

反向代理

通常意义上的代理，是为客户端服务的，作为客户端的全权代理，和服务器建立TCP连接，并将从服务器获取的网页，再转交给客户端，此谓代理服务器。

而反向代理，恰恰相反，是为服务器服务的，此谓反向代理。

当客户端访问服务器的流量经过前置反向代理时，反向代理直接终结该TCP连接，接下来再直接终结TLS安全会话，仿佛自己就是真正的服务器一般。

有同学会问，为何客户端访问服务器的流量会先经过前置反向代理？

上文其实已经解释过了，因为反向代理的位置在服务器的前方。

 

解释完前置反向代理服务器，就会发现，反向代理服务器既然以服务器的名义与客户端建立TLS安全会话，那逃避不了的话题就是，反向代理究竟需不需要服务器的私钥与公钥证书？

当然需要，反向代理作为一个中间人，获得了服务器的合法的授权。

 

前置反向代理与服务器的部署场景有

1） 在一个机房

这种部署场景，希望前置反向代理提供安全防护服务，只有443端口的流量才能到达服务器，而其它所有的流量都无法到达服务器，可以避免服务器安全漏洞而产生的风险。

2） 相距很遥远的距离

这种就是CDN的部署场景，为的是CDN服务器更靠近用户，可以提高用户响应的速度。

CDN服务器（反向代理）与服务器，在客户端请求连接之前，TLS安全会话已经建立，这样大大缩短TLS安全会话的建立时间，间接提高用户响应。

 

还有一种部署场景，http服务器不支持TLS安全会话，希望前置反向代理服务器能够提供安全会话服务。

 

如上图所示，反向代理服务器分别与客户端、服务器分别建立TCP连接，步骤如下：

1 客户端与反向代理建立TCP连接（443）

2客户端与反向代理建立TLS安全会话 （使用服务器的私钥、公钥完成认证）

3 将http里的URL提取出来

4 反向代理服务器与服务器建立TCP连接（80）

5 将步骤3的URL发给服务器

6 服务器返回请求的网页内容

7 反向代理服务器将网页内容，使用TLS安全加密发给客户端

8 客户端将TLS加密内容解密出来，获得了明文的网页内容，并呈现在浏览器上。

 

由于反向代理服务器与服务器之间的TCP连接上，没有TLS安全加密保护，所以HTTP的内容是以明文方式传输，如果这些内容在互联网上传输，则容易被窃取、泄露，这是一个安全隐患。

通常这种方式，反向代理服务器与服务器位于一个机房，由于明文流量在公司内部传输，这样就大大减轻了流量被窃取的可能。

欢迎扫码关注：