豆丁微信公众号
君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
思科路由器PPOE client+NAT解决地址回流问题测试
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='http://www.docin.com/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您好，欢迎光临本站!&&&
还没有帐号？ 赶紧
NAT网络回流现象解释，内网使用服务器的外网IP登陆
UID：245602
在线时间354小时
黑豆294威望7391贡献值0交易币0红豆2
hi大家好，今天我们来讨论一个很多人都找不到答案得问题：究竟为什么内网不能用公网地址访问内网服务器。不是任何设备都存在此问题，拿cisco的设备来说，不同版本的ios，有的就没有这个问题，而有的版本就有问题，netscreen的防火墙也没有这个问题，关键是开发者有没有意识到这个问题，通过修改ios，完全可以避免。对于这个问题，解决方法是有，比如内网dns欺骗、pix上得alias等等，但是究竟为什么有些设备不支持呢？今天我斗胆发个贴，因为有些结论纯粹靠想，也没有设备进行试验，所以希望大家跟贴讨论，达到抛砖引玉的目的，谢谢了先！&&&&以下所有内容均针对出口是以太网的情况，对于串口接入，不会出现这种问题。&&&&如图，这个图是本贴的初始图，大圈是本地路由器，和他相连的是isp路由器，和isp相连的是internet上随便一个路由器。&&&&本地出口地址是5。5。5。1，isp对端是5。5。5。2（掩码没写，稍后会分别讨论）。1。1。1。1和1。1。1。2是内网两台服务器的内网地址，被静态映射到公网上的5。5。5。4和5。5。5。5。 内网的pc全部被pat到出口上。本地路由器一条缺省路由到isp对端。&&我想这个拓扑应该是非常普遍的了，我认为就是因为这个非常普遍的拓扑，造成了很多人所反应的“内网不能通过公网地址访问内网服务器”这个问题。我认为这个问题的关键原因就在于掩码，就是在3层上做文章。&&&&&&&&第一节&&先来看看一般情况下，这个环境的掩码的规划。假设isp分配一段8地址子网给本地，这样isp路由器接口和本地路由器接口共占用2个，网络地址、广播地址共占用2个，可用的一共4个，掩码是248。对于图示的拓扑，假设本地路由器出口掩码是248（内网pc的pat地址相应的也就是掩码为248），被映射的两个地址掩码也是248，这个最普遍的掩码规划，结果是：服务器、内网pc的pat地址、本地出口地址全部处于同一个网段。我们分析一个包的来龙去脉，来看看到底内网pc通过公网地址可否访问到内网服务器。&&假设内网一台pc1。1。1。111发出ping 5。5。5。4（服务器的公网地址）请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4就位于自己的出口网段（假设出口为以太口），所以直接通过arp广播请求5。5。5。4的mac地址，问题出现了，谁会应答这个请求呢？没有人，所以，这种情况下（所有公网地址在同网段）当然不会通。不但内网访问服务器不行，服务器之间通过公网地址访问也不会通。&&结论一：只要出口地址和服务器映射的公网地址在同网段，就有问题。&&&&&&&&&&第二节&&&&基于上面的讨论，我们知道了只要出口地址和服务器映射的公网地址在同网段，就会发生“无人应答”的必然结果，所以我们这次改变掩码规划，将出口掩码变长，变为252（isp掩码也要相应改变）。在这里首先声明一个要点，就是nat池的地址可以和出口不在同网段，以前有帖子也讨论过，我自己一开始也迷惑，后来想明白了，只要isp路由器上有这些地址的路由就可以，下一条是本地路由器，这样本地路由器便可以接受到这些包。&&我们再次分析一个包的流程。内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，这一次，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。1加上端口号（假设端口号是8888），isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。1，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。5。4正在被静态映射到内网的1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。1，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。&&我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。1（加端口号），发出reply包，源地址1。1。1。1，目的地址5。5。5。1:8888，本地路由器收到后，先给路由引擎，发现5。5。5。1就是出口地址，问题又来了，包的目的就是出口，而不是经过出口，这时候路由器该怎么办呢？假如是从外向内来的包访问5。5。5。1:8888，这时候会先提交个nat引擎，做nat转换。但是这是从内向外发出的包，要先提交给路由引擎，我认为此时，由于收到的包是从内向外的，目的直接就是针对出口来的，而出口并没有开启什么端口，除非为了web管理，或者telnet管理开启80或23端口，所以路由器会丢弃，因为没有得到应答。&&结论二：只要出口地址和内网pc的pat地址同网段，同样会有问题&&&&&&&&&&第三节&&&&我们再变更掩码方案，使得内网pc的pat地址和服务器映射地址同网段，但和出口不同网段。假设内网pc的pat地址为5。5。5。6（和服务器地址同网段）&&我们再次分析一个包，内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。6加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。6，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。5。4正在被静态映射到内网的1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。6，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。&&我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。6（加端口号），发出reply包，源地址1。1。1。1，目的地址5。5。5。6，本地路由器收到后，先给路由引擎，发现5。5。5。6不在本地任何端口下，所以走了缺省路由，发给isp，并在nat表中生成一条记录，将1。1。1。1转换为5。5。5。4，isp接受到包源地址变为5。5。5。4，目的地址是5。5。5。6，通过检查路由表，发现5。5。5。6这个地址的路由下一条应该是5。5。5。1，也就是本地路由器，所以包又被发回来了，经过一次往返，本地收到了这个包，首先提交给nat引擎，发现目的地址5。5。5。6在nat表中对应着内网pc1。1。1。111，所以将5。5。5。6替换成1。1。1。111，源地址不变，还是5。5。5。4，然后提交给路由引擎，路由器在2层将包发给1。1。1。111，这时，1。1。1。111这台主机收到了从5。5。5。4返回的包，而他一开始ping请求包，就是发给5。5。5。4这个公网地址的，所以ping通了！！！！&&&&结论三：内网pc的pat地址和服务器公网地址同网段，同时和出口地址不同网段，这样没有问题。&&&&&&&&&&第四节&&&&本贴的高潮部分已经达到，至此，只剩下一种情况，就是内网pat地址、服务器公网地址、出口地址全部不在同网段。假设出口掩码252，服务器公网地址段掩码248，内网pc的pat地址改为5。5。5。254，这样三种地址都不在同网段。而且isp也必须有服务器公网地址和内网pc的pat地址的路由，下一条是5。5。5。1我们再次分析一个包，内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。254加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。254，它检查它的路由表，发现5。5。5。4路由下一条是5。5。5。1，也就是本地路由器，所以又将此包发给本地路由器，经过了一次往返后，本地收到这个包，首先接受nat引擎的过虑，发现5。5。5。4正在被静态映射到内网的1。1。1。1的主机，所以改变目的地址为1。1。1。1，源地址还是5。5。5。254，这样就交给了路由引擎，查看路由表，1。1。1。1的路由当然有了，通过2层直接发给1。1。1。1，至此，去程的包分析完毕。&&我们再分析回程的包。服务器1。1。1。1收到包后，准备回应给5。5。5。254（加端口号），发出reply包，源地址1。1。1。1，目的地址5。5。5。254，本地路由器收到后，先给路由引擎，发现5。5。5。254不在本地任何端口下，所以走了缺省路由，发给isp，并在nat表中生成一条记录，将1。1。1。1转换为5。5。5。4，isp接受到包源地址变为5。5。5。4，目的地址是5。5。5。254，通过检查路由表，发现5。5。5。254这个地址的路由下一条应该是5。5。5。1，也就是本地路由器，所以包又被发回来了，经过一次往返，本地收到了这个包，首先提交给nat引擎，发现目的地址5。5。5。254:某个端口，在nat表中对应着内网pc1。1。1。111，所以将5。5。5。254替换成1。1。1。111，源地址不变，还是5。5。5。4，然后提交给路由引擎，路由器在2层将包发给1。1。1。111，这时，1。1。1。111这台主机收到了从5。5。5。4返回的包，而他一开始ping请求包，就是发给5。5。5。4这个公网地址的，所以ping通了！！！！&&&&&&结论四：三种地址全部不在同网段，没有问题。&&&&&&&&&&&&&&&&综上所述，得到了4个结论：&&结论一：只要出口地址和服务器映射的公网地址在同网段，就有问题。结论二：只要出口地址和内网pc的pat地址同网段，同样会有问题。结论三：内网pc的pat地址和服务器公网地址同网段，同时和出口地址不同网段，这样没有问题。结论四：三种地址全部不在同网段，没有问题。&&可以简单的发现，前两个是充分条件，只要满足了其中一个，就会出现问题，而现在大多数的接入都符合前两个情况，而几乎没有人“多此一举”的去改变掩码规划，所以造成如此多的普遍现象：内网不能用公网地址访问内网服务器！！！！！&&出口地址只要不和其他两种地址同网段，就可以保证不出问题。&&至此，已经探讨了问题的原因。此过程中我还得到了一个推论和一个待验证的问题。&&推论：如果nat池中的公网地址和出口地址不同网段，不管在内网还是公网ping nat池中未参与转换的公网地址，会出现环路，包在本地和isp之间来回往返。&&&&待验证的问题：对于第三节和第四节，如果只在本地出口变长掩码，isp端不作任何改变，会怎么样？以第三节的环境来说：我们再次分析一个包，内网pc1。1。1。111发出ping 5。5。5。4请求，包源地址1。1。1。111，目的地址5。5。5。4，路由器收到这个包后，检查路由表，发现5。5。5。4不在本地的任何接口，所以走了缺省路由，将包发给了isp对端口，并在本地nat表中生成一条项目，记录内网地址1。1。1。111被转换成公网地址5。5。5。6加上端口号，isp接受到的包，目的地址是5。5。5。4，源地址变成了5。5。5。6，它检查它的路由表，由于此时isp的接口掩码没有变长，还是248，所以，它发现5。5。5。4路由就在它自己的接口上，所以直接在接口发arp请求5。5。5。4的mac地址，此时，按理说，没人会应答（除非本地开了代理arp），但是有一次偶尔发现在路由器上show arp，会发现有些奇怪的条目，ip地址都是nat池中的地址，mac地址不管ip多少，都是本地出口的mac地址，这样的话，即使arp请求的地址不和出口同段，一样会得到应答，不知道这个对不对。&&&&对这个问题的解决方法，在ios层面，一般是利用修改dns回包中的payload实现的，将dns返回的公网地址，修改成内网地址，这样直接通过内网通信，就不会有问题了。对于直接用公网ip访问的包，会在路由器内部先nat，然后调头，不走出口，直接再回到内网，以支持用公网地址访问。&&写了这么多，不知道各位有没有耐心看完，不管怎么样，请大家多发表评论，谢谢！
UID：455131
在线时间0小时
发帖141299
黑豆-2859威望-2709贡献值0交易币0红豆0
楼主分析得非常好，用gns搭建环境测试了一下：1.第一种情况：出口地址和服务器映射的公网地址在同网段A.内网服务器可以ping通5.5.5.4的，但tcp会话有问题B.抓包发现虽然ping通，其实ping包没有达到内网1.1.1.2服务器，C.抓包发现5.5.5.1接口会发gratuitous arp广播包，告诉别人5.5.5.4的mac是它自己D.内网与5.5.5.4所有通讯都达到不了1.1.1.2，所以失败2.第二种情况：出口地址和内网pc的pat地址同网段A.从内网主机1.1.1.111 ping 5.5.5.4，ping不通B.抓包发送ping包已经到达1.1.1.2，源地址为5.5.5.1，并且1.1.1.2也回了包C.确实数据包到达了5.5.5.2，并且5.5.5.2回了一个redirect，下面是系统日志：*Mar
1 00:43:00.971: ICMP: redirect sent to 5.5.5.1 for dest 5.5.5.4, use gw 5.5.5.1----测试觉得后面两种情况与楼主分析的情况一样3.待验证的问题：如果只在本地出口变长掩码，isp端不作任何改变A.这时内网没有做静态NAT主机，无法ping通和telnet 5.5.5.4B.发现isp路由器发出了arp请求包，请求内网动态NAT的地址对应的mac，但是没有得到应答C.没有出现楼主所说的奇怪arp条目
UID：455131
在线时间0小时
发帖141299
黑豆-2859威望-2709贡献值0交易币0红豆0
也遇到这个问题,仔细看看.
UID：455131
在线时间0小时
发帖141299
黑豆-2859威望-2709贡献值0交易币0红豆0
也遇到了，谢谢楼主，
UID：455131
在线时间0小时
发帖141299
黑豆-2859威望-2709贡献值0交易币0红豆0
瞎扯，还是NAT的问题。
访问内容超出本站范围，不能确定是否安全
限100 字节
您目前还是游客，请
&回复后跳转到最后一页
版权所有 Time now is:07-21 13:54
Gzip enabled试论nat转换方式下的src-nat、dst-nat和映射、回流的关系
我的图书馆
试论nat转换方式下的src-nat、dst-nat和映射、回流的关系
src-nat是源地址转换,其作用是将ip数据包的源地址转换成另外一个地址,
首先我们说一下snat中几个参数的含义,
action，这是说明用的哪种转换方式,通常我们用masqurade，nat这两种,在特殊情况下用accept(主要是内网中有公网地址存在的情况)方法，
protocol说明对哪些传输协进行转换(通常有tcp,udp等),out-interface说明通过哪一个网卡进行转换(通常是外网卡outside)，to-src-address是将源地址伪装成哪些地址(可以是一个也可以是很多个),to-src-pot是将源端口伪装成哪些端口(可以是一个也可以是很多个),dst-address是指发向哪些主机的数据包要进行伪装(可以一个可以多个)，dst-port是指发向哪些端口的数据包进行伪装(可以一个可以多个)，src-address是指对哪些源地址进行伪装(可以一个可以多个),src-port是指从哪些源端口发出的数据包进行伪装(可以一个可以多个)
下面的论述中,ACTION(转换方式)都是以NAT为例.再综合网上其它的相关资料，以我现有的理解，和具体的试验,再作些补充：要做src-nat，除了指明协议\端口\转换成什么地址外,还要谈到是在那块网卡(接口)上做这个“源地址地址转换”。比如，要让内网的电脑通过routeros访问外网，那么就由与公网连接的网卡做snat，在添加src-nat规则时，general页的out. interface就应选"外网卡",当然,用默认设置"all"也就包含了"外网卡",但这不利于理解src-nat理解了src-nat ,dst-nat就很好理解了,src-nat是Routeros将内网电脑发出的数据包的地址中的源地址进行转换然后发往外网,在数据包中,被转换的地址是源地址,所以叫源地址转换.而dst-nat则刚好相反,它是Routeros将公网发来的数据包的地址中的目的地址进行转换(当然这个目的地址就是routeros的公网ip),然后发给内网的电脑,在数据包中,被转换的地址是目的地址,所以叫目的地址转换.同样,dst-nat除了指定转换后的地址外,也将涉及是在那块网卡(接口)上进行,例如,要将公网发给routeros的a端口的数据包转给内网ip为b的c端口,那么设置好a\b\c的值后,在dst-nat规则general页的in.interface里,应选择与b地址网段相连的网卡(接口),显然这是一块内网卡,当然,用默认设置"all"也就包含了这块"内网卡",但这不利于理解DST-nat.到这里可以明白什么是端口映射了,它就是dst-nat中的一条转换规则.再来谈"回流",引用一段文字--"什么叫回流呢，就是当内网有服务映射到网关后,内网主机也可以用网关外部地址访问"由上面的定义可以清楚"回流"要完成的操作:1\内网电脑向Routeros发送目的地址为公网ip的数据包（当然这个IP就是Routeros的公网IP）. 2\Routeros通过源地址转换规则(SRC-NAT)中选定的A网卡(接口)将数据包地址中的源地址转换为公网IP(目的地址不变,仍为公网IP) 3\routeros通过目的地址转换规则(DST-NAT)中选定的B网卡(接口)将数据包地址中的目的地址转换为内网地址,然后发给相应的内网电脑.但是问题来了,如果A网卡(接口)将数据包地址转换后就往公网发送,那么数据包就无法再回到路由器并转发给内网了.如果能让数据包不出路由器,在路由器内完成SRC-NAT和DST-NAT这两种地址转换,那么就可以实现回流了.呵呵,让A=B就可以实现了.就是说,添加一条SRC-NAT和一条DST-NAT规则,而这两条规则中所指定的网卡都是与内网相连的同一块网卡.上面的论述，在1WAN2LAN,动态拨号环境下，测试验证，没有出现矛盾。当然动态拨号时,外网卡应选"PPPOE-OUT"，还要编写相应的脚本，动态更新to src.address,这比较麻烦，所以动态拨号用户的地址转换方式一般选“masqurade”不足之处欢迎大家指正。希望理解masqurade的朋友来发个贴,帮大家释疑一下.转载请注明 文章来自: 北京电脑维修网( ,详文参考：
[转]&[转]&[转]&[转]&[转]&[转]&
喜欢该文的人也喜欢单位有3个域名，用量很大，2014年开始本人研究部署了Bind+DLZ +Mysql的三机智能多链路DNS，非常好用，优点是：
1、使用Mysql管理记录，配置、管理、查询方便。
2、自动判断运营商，返回指定IP，实现智能多链路。目前我们单位有电信、移动、教育网专线和固定IP，通过Bind的View，判断请求源IP自动返回对应运营商的服务IP。很好很强大也很实用。
3、根据配置自动为内网分配对应的运营商解析。。。我单位内网用户较多，有一个不少见的需求，内网部分用户要使用电信专线、部分用户要使用移动专线，然而走电信的就得用电信DNS解析、走移动就得用移动DNS解析，同样的，Bind的View也很好的解决了这个问题。
然而、、、、、今天突然让我崩溃了，有2、3个域名外网访问部分出错、打不开网页。我仔细研究，发现外网被解析成了内网IP。。。如下图：
这让我很头疼呀，仔细分析，把Bind从Dump缓存、Config文件、ACL文件全部翻了个遍，没发现问题。。。。。这个问题的状况是这样的：只有2、3个域名有这个问题，其它子域名（近几十个）都没问题。。。。
很奇葩，我都有点怀疑跟服务器有没有关系呀。。。。。
折腾2、3天没搞定，也没想通。。。今天晚上从路由器入手打算再走一遍，我手头有3个路由器，一行行看配置，终于找到点眉头，被解析错误的地址，我在其中一个路由器上做了NAT回流。。。
好吧，什么是NAT回流？这里简单讲讲，详细的大家上网搜吧，就是我做了nat server，比如：&nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any。这时外网用户通过X.X.X.X的公网IP、内网用户通过192.168.200.57的IP分别可以访问对应的服务，当然主要是用DNS了，但是如果我内网里有人用X.X.X.X的公网IP去访问呢？这时正常、默认的NAT配置是访问不了了，详细我也不说了，搜到这篇文章的兴许就是这个故障，这时就要做一个NAT回流，让路由器从内网过来的访问公网IP请求能够像在外网一样访问，这时配置NAT回流就可以，我是这样弄的（路由器是H3C的）：
1、先搞个回流的ACL。。。我的故障就在这里了，一会说。
&acl number 3010&rule 5 permit ip source 172.16.0.0 0.0.255.255&rule 6 permit ip source 172.17.0.0 0.0.255.255&rule 7 permit ip source 172.21.0.0 0.0.255.255&rule 8 permit ip source 172.22.0.0 0.0.255.255&rule 15 permit ip source 192.168.0.0 0.0.255.255&rule 100 deny ip
2、在内网接口上配置，注意是内网，而不是外网。
interface GigabitEthernet2/2/0&port link-mode route&nat outbound 3010&nat server protocol icmp global X.X.X.X inside 192.168.200.57&nat server protocol tcp global X.X.X.X any inside 192.168.200.57 any&ip address 10.10.248.1 255.255.255.252
那为什么这个回流会导致外网解析到了内网IP呢？？？原因是我在做Acl的时候，当时只是为了测试一下这个200.57的业务内网用公网IP访问，就简单的内网IP都给Permit了，这个配置NAT回流是可以了，但由于没有匹配目标IP，导致所有包都能回流，导致内网的DNS回传给外网DNS服务器的响应包识别为是内网地址段来的，就丢了个内网IP给人家运营商服务器。。。把上面Acl改完善就OK了，完整的应该是这样：
&rule 5 permit ip source 172.16.0.0 0.0.255.255 destination 192.168.200.57 0&rule 6 permit ip source 172.17.0.0 0.0.255.255 destination 192.168.200.57 0&rule 7 permit ip source 172.21.0.0 0.0.255.255 destination 192.168.200.57 0&rule 8 permit ip source 172.22.0.0 0.0.255.255 destination 192.168.200.57 0&rule 100 deny ip
也就是严格匹配内网地址段 to 内网需要NAT回流的服务器内网地址。。。这样对这台的NAT回流也正常（内网用它的公网IP也可以访问）、同时也不会出现BIND解析出错的问题。。。
当然如果你不提供像我的这个智能BIND解析服务，那你就像上面那个笼统的ACL也是可以的。。。我这是两个功能在一起就冲突了的。
后来发现，其实光ACL也没用，还是会这样呀。。。。。苦苦研究一个多月，最终在厂商工程师的帮助下解决了问题，原来是路由器的DNS-ALG在作怪，H3C路由器V5平台下ALG功能默认是开启的，而V7下默认是关闭了就没这问题。我的是V5，得手动关闭一下：系统视图下：undo alg dns
解决问题了。。。。OK，那么alg dns是什么鬼呢？来看看：
NAT ALG 功能，仅在要通过NAT 设备进行DNS、FTP、SIP 和RTSP 等应用（如DNS 服务器在公网中，需要在内网中使用域名访问位于内网的服务器时）时，需要配置NAT ALG 功能。使能ALG 功能可以使NAT 设备识别被封装在报文数据部分的IP 地址或端口信息，并根据动态形成的NAT 地址（或同时包括端口号）映射表项进行替换，使报文正常穿越NAT。
所以呢，nat&server只在inbound生效，应该是报文从内网返回命中内敛口，出去了返回的是私网解析。。。
至此，该问题彻底解决。。。
阅读(...) 评论()AR151-S2路由设置域内NAT回流 – A LITTLE FROG
目的：内网服务器经过AR路由映射端口到外网，AR路由默认无端口回流，直接导致在内网内使用域名（或者外网IP）加端口方式访问内网服务器时失败（而在外网使用域名+端口访问内网服务
器时正常）。解决此问题的关键是配置回流。AR路由半残废，无法设置nat enable命令。网上很多方法，但是均有前提条件，要求路由外网IP是固定IP。
使用此方法能解决动态IP问题：
AR 配置域内nat/nat 回流/内网中用公网ip访问内网服务器
1. 首先配置端口映射：IP业务—nat—内部服务器，保存
2. 获取当前配置：
i. 右上角 保存
ii. 系统管理 & 升级维护 & 设备重启，单击“导出配置文件”，备份当前配置文件到本地计算机
3. 确定外网口和内网口
a) 查看自己的接口名称：dis ip int brief
b) 静态ip、动态ip上网的，看GigabitEthernet 或Ethernet开头的，有公网ip的接口
c) 拨号上网的，dialer xx 是公网口
d) 内网口，看接口的ip为192.168.x.x或172.16.x.x.或10.x.x.x
4. 通过刚刚第2步获取的配置文件，挑出外网口及内网口的配置
然后开始工作。
Login authentication
Username:wanlp
-----------------------------------------------------------------------------
User last login information:
-----------------------------------------------------------------------------
Access Type: Web
IP-Address : 192.168.1.246
21:53:39+08:00
-----------------------------------------------------------------------------
&Huawei&sys
Enter system view, return user view with Ctrl+Z.
[Huawei]int vlanif1 //选择内网口
[Huawei-Vlanif1]nat server protocol tcp global interface Dialer 1 17990 inside 192.168.1.110 17990
//将17990端口从Dialer 1口（拨号口）回流到内网IP192.168.1.110，下同
[Huawei-Vlanif1]nat server protocol tcp global interface Dialer 1 1024 inside 192.168.1.222 443
[Huawei-Vlanif1] nat server protocol tcp global interface Dialer 1 443 inside 192.168.1.110 443
Warning:The port is well-known(1~1023) port. If you continue it may cause functi on failure. Are you sure to continue?[Y/N]:y
[Huawei-Vlanif1] nat outbound 2999
[Huawei-Vlanif1]
实际上，以上步骤可以直接在WEB端完成：IP业务-NAT-内部服务器
在建立内部服务器时，配对进行，如图：
请注意，这里还要设置（划红线那个，需要设置）：
版权声明: 若无特殊说明，本文之图文均为原创，任何组织及个人未经同意禁止转载或制作各类出版物，包括但不限于本站图片、文字及影音。