A10网络用传统的NAT方式替代H3C的DNS-MAP功能

　　相信大家在做链路均衡相关的项目中，往往会碰到用户有如下要求：对于内网服务器向外发布的域名，除了让公网用户来访问之外，内网用户也同样用域名方式来访问服务器。但是内网用户的访问往往会出问题，当公网用户用域名正常访问的时候，内网用户却访问不了应用，这是什么原因呢?我们来逐一分析两种情况。

　　1、外网用户通过域名访问的情况，见下图：

　　

　　如上图所示，当公网客户端2.2.2.2通过dns解析出内网服务器192.168.1.100对外域名对应的公网IP为1.1.1.1以后，会主动向1.1.1.1发出访问，整个访问可分为4个过程，每个过程的IP地址情况见上图。在上图4个过程中，我们可以看到1，2过程为从外到内的请求，3，4过程为从内到外的应答。整个过程符合TCP协议建立的过程，因此可以顺利访问。

　　2、内网用户通过域名访问的情况，如下图：

　　

　　大家应该发现了，第二种情况中，只存在3步。当内网用户通过域名解析出公网IP以后，会和第一种情况中一样发起第1过程第2过程，但是和第一种不同的是，服务器会直接把应答返回给内网用户，而内网用户接受到应答后会怎么处理?内网用户是对1.1.1.1发起的请求，所以内网用户自然会等待源地址为1.1.1.1的应答，结果却收到源地址是192.168.1.100的应答，明显和期待的不一致，所以内网用户会直接丢弃掉这个应答。这个也是为什么都是用域名进行访问，从外网来的用户可以正常访问，而内网用户却无法访问的根本原因所在。

　　那么，如果解决这个问题呢?以前针对内网用户如何用公网域名访问本地私网内的SERVER这样的解决方法，一般是在内网建立DNS服务器，内网用户的dns服务器都统一指向内网的DNS服务器，而内网DNS在收到争对内网server的域名解析请求之后，会直接将内网server的内网IP解析给内网用户，这样内网用户就会直接访问server的内网IP地址，所以不会出现像提到的因为访问server的公网IP而产生的访问失败。

　　而如果用户内网没有DNS服务器怎么办呢?H3C的防火墙有个专门的功能，叫DNS-MAP，功能很简单，也很实用，就是用来解决这个问题，原理很简单，当内网用户向公网的DNS发出域名解析请求之后，DNS服务器会进行应答，应答包中包含了域名对应的公网IP，而DNS-MAP功能则可以修改这个应答包，将包中包含的公网IP直接替换为服务器的内网IP地址以后返回给用户，从而实现了与内网架设了DNS服务器一样的效果。当然这种功能也有局限：可以设置的域名是有数量的。

　　我在一个链路均衡项目的上线中，就遇到了用A10替换H3C防火墙的情况，其中H3C防火墙上就192.168.1.254配置了DNS-MAP。当时用A10替换之后，就发现了内网用户无法再用域名的方式访问内网的server了，因为开始的时候用户并没有给我们全部的H3C防火墙配置，所以我们也没有看到启用DNS-MAP功能。后来当内网用户用域名访问不了server以后才发现。那么这个时候在A10上有哪些方式可以解决这个问题呢?

　　1、GSLB方式

　　这种方式需要和公网域名供应商配合，将所有访问的请求都通过CNAME别名或者NS委派的方式转发到A10上，而由A10来进行地址解析。这种方式的优点是支持智能域名解析，缺点是需要协调域名供应商协同解决，客户也不一定会愿意配合。

　　2、aflex脚本方式

　　用这种方式实现对DNS请求包的拦截，将所有关于域名的应答中的公网IP替换为内网IP，这样就直接实现了与DNS-MAP一样的功能。优点是不需要用户配合，缺点是设备需要所有的DNS包，所以对设备的性能会有一定的影响。

　　由于当时用户要求必须马上解决这个问题，而第1种和第2种方式又都需要花费时间，所以我直接采用了第3种方式，也是最简单的一种方式：就用NAT来解决这个问题。

　　3、NAT方式

　　

　　这种方式最为简单，和原来过程中最大的差别，在于第2过程的时候，A10对请求的源地址进行了地址转换，从192.168.1.50，改成了A10的接口地址192.168.1.254，这样，服务器会将所有的应答都先返回给A10，而不会直接返回给用户，而在第4个过程中，A10会将应答的源地址从192.168.1.254改回1.1.1.1，这样用户也可以正常接收这个应答了。当然，我们只需要对内网用户发来的请求进行地址转换，而外网来的请求就不需要了，所以最好能够使用ACL对请求进行分类，外网来的不处理，内网来的进行NAT。