不能用公网地址访问内网服务器的详解

究竟为什么内网不能用公网地址访问内网服务器。不是任何设备都存在此问题，拿cisco的设备来说，不同版本的ios，有的就没有这个问题，而有的版本就有问题，netscreen的防火墙也没有这个问题，关键是开发者有没有意识到这个问题，通过修改ios，完全可以避免。对于这个问题，解决方法是有，比如内网dns欺骗、pix上得alias等等，但是究竟为什么有些设备不支持呢？今天我斗胆发个贴，因为有些结论纯粹靠想，也没有设备进行试验，所以希望大家跟贴讨论，达到抛砖引玉的目的，谢谢了先！
以下所有内容均针对出口是以太网的情况，对于串口接入，不会出现这种问题。
本地出口地址是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，然后调头，不走出口，直接再回到内网，以支持用公网地址访问。

总结：
从客户端发过来的数据是先路由后NAT，从互联网测发过来的包（返回包）是先NAT后路由。

下面为一实例：

路由器内网PC通过公网IP访问映射的内网SERVER案例

一、 组网：




二、 问题描述：
拓朴如上图，内网PC与内网所在的SERVER在同一个网段,现在内网SERVER对公网用户提供WWW和FTP服务,在公网上有相应的域名。现在要求内网PC可以同时通过公网域名、公网IP和私网IP来访问内网的这台SERVER。
三、 过程分析：
内网主机通过公网域名来访问映射的SERVER在AR路由器上都是通过NAT DNS-MAP来实现的，但不能同时通过公网IP和私网IP来访问SERVER。如果在设备内网口配置NAT SERVER则可以把访问公网地址转换成私网地址，然后向SERVER发起连接，但源地址还是内网主机的地址，此时SERVER给PC回应报文时就不会走路由器，直接发到了内网PC上，内网PC认为不是自己要访问的地址，会把这个报文丢弃，因此会导致连接中断。如果让SERVER把报文回给路由器，路由器再根据NAT SESSION就可以正确转发给PC了。
四、 解决方法：
在内网接口配置一个NAT OUTBOUND 3000就可以了。具体配置如下:
[H3C]dis cu
#
sysname H3C
#
clock timezone gmt+08:004 add 08:00:00
#
cpu-usage cycle 1min
#
connection-limit disable
connection-limit default action deny
connection-limit default amount upper-limit 50 lower-limit 20
#
web set-package force flash:/http.zip
#
radius scheme system
#
domain system
#
local-user admin
password cipher .]@USE=B,53Q=^Q`MAF4<1!!
service-type telnet terminal
level 3
service-type ftp
#
acl number 2000
rule 0 permit source 192.168.1.0 0.0.0.255
rule 1 deny
#
acl number 3000
rule 0 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.1.2 0
#
interface Aux0
async mode flow
#
interface Ethernet1/0
ip address 192.168.1.1 255.255.255.0
nat outbound 3000
nat server protocol tcp global 200.0.0.2 ftp inside 192.168.1.2 ftp
#
interface Ethernet1/1
#
interface Ethernet1/2
#
interface Ethernet1/3
#
interface Ethernet1/4
#
interface Ethernet1/5
#
interface Ethernet1/6
#
interface Ethernet1/7
#
interface Ethernet1/8
#
interface Ethernet2/0
ip address 200.0.0.2 255.255.255.0
nat outbound 2000
nat server protocol tcp global 200.0.0.2 ftp inside 192.168.1.2 ftp
#
interface Ethernet3/0
#
interface NULL0
#
FTP server enable
#
ip route-static 0.0.0.0 0.0.0.0 200.0.0.1 preference 60
#
user-interface con 0
user-interface aux 0
user-interface vty 0 4
authentication-mode scheme
#
return
[H3C]
五、 说明
1、本案例适用于R系列、AR系列、MSR系列路由器。
2、R系列路由器在使用此案例时内网口需要undo ip fast-forwarding，并且在使用FTP映射时，客户端只能使用主动模式去访问。