LOGO OA教程 ERP教程 模切知识交流 PMS教程 CRM教程 开发文档 其他文档  
 
网站管理员

[点晴永久免费OA]对内网不能用外网地址访问内部服务器

admin
2013年10月24日 18:11 本文热度 11400
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,然后调头,不走出口,直接再回到内网,以支持用公网地址访问。

该文章在 2022/7/13 18:52:18 编辑过
关键字查询
相关文章
正在查询...
点晴ERP是一款针对中小制造业的专业生产管理软件系统,系统成熟度和易用性得到了国内大量中小企业的青睐。
点晴PMS码头管理系统主要针对港口码头集装箱与散货日常运作、调度、堆场、车队、财务费用、相关报表等业务管理,结合码头的业务特点,围绕调度、堆场作业而开发的。集技术的先进性、管理的有效性于一体,是物流码头及其他港口类企业的高效ERP管理信息系统。
点晴WMS仓储管理系统提供了货物产品管理,销售管理,采购管理,仓储管理,仓库管理,保质期管理,货位管理,库位管理,生产管理,WMS管理系统,标签打印,条形码,二维码管理,批号管理软件。
点晴免费OA是一款软件和通用服务都免费,不限功能、不限时间、不限用户的免费OA协同办公管理系统。
Copyright 2010-2024 ClickSun All Rights Reserved