路由器端口映射后 公网正常访问 而局域网无法通过公网IP访问

您所在的位置:网站首页 公网ip能不能上谷歌 路由器端口映射后 公网正常访问 而局域网无法通过公网IP访问

路由器端口映射后 公网正常访问 而局域网无法通过公网IP访问

2024-07-10 10:26| 来源: 网络整理| 查看: 265



转载:http://blog.csdn.net/yxwmzouzou/article/details/18089291

问题:在NR289-E 路由器对8010端口进行映射(虚拟服务),映射到我自己的电脑的80端口,设置成功后,但在本机上(即192.168.1.80这台PC机)访问域名和外网ip时,都是无法打开,还以为是映射不成功或是被路由器屏蔽了呢!

一直没法解决,只好因vpn功能,让别人访问。

不管它了,字翻·墙的时候无意间试了试,发现能访问,于是经过确认才知道外网可以访问,内网不能访问。

在王龙找到一个叫 a龙的QQ网友,给了详细的解释。

 

 

本来就是这样,不是你的问题。所有类似你这样的做法,都是外网可以访问,内网不能访问。

简单说明一下:

假设你的外网IP为 202.1.1.1 内网有2台192.168.1.10  192.168.1.11

做了IP地址映射  202.1.1.1:80->192.168.1.10:80

1。公网PC1访问你的站点

PC1:X->202.1.1.1:80   (1个session 包含:[source ip:source  port , desti p:dest port]4个参数 ) 地址转换后:  pc1:x->192.168.1.0:80

192.168.1.0 到数据后,发数据给源站点

192.168.10:80->pc1:x  经过地址转换 202.1.1.1:80->pc1:x

所以外网可以访问你映射的站点.

2。如果在内网访问

192.168.1.11:x->202.1.1.1:80  地址转换后 192.168.1.11:x->192.168.1.10:80 到达站点

站点返回数据:

192.168.1.10:80->192.168.1.11:x 这里是关键:192.168.1.10检查后发现目标ip为192.168.1.11为同一网段, 所以直接把数据发给192.168.1.11,不再通过202.1.1.1转发。

但是,192.168.1.11是向202.1.1.1发起连接,并没有和192.168.1.10连接,所以将丢弃192.168.1.10发回的数据。

也就是说 192.168.1.11访问202.1.1.1永远也连接不上。

===========

转载:http://www.netingcn.com/route-nat.html

前段时间在公司的路由器上配置把公网IP映射到局域网中的一台电脑,映射为web服务器,在公司外面可以使用公网IP正常访问web服务,但公司内部使用公网IP确无法访问web服务。最开始以为是路由器配置问题,多次排查配置,没有发现问题;然后想到会不会是本机路由表的问题,尝试设置一些静态路由,问题依然没有解决;最后终于在网上找到类似的问题,原因是路由器硬件的问题,路由器不支持数据回流造成。

关于“数据回流”介绍,在网上看到一篇很好的文章以下转帖。原文地址:http://www.5mwl.com/thread-17384-1-1.html 回流是什么?最简单的一个实例: 网吧内网一台主机192.168.0.2建了个WEB服务站点端口80,然后在网关(其内网地址是192.168.0.1、公网地址为218.4.218.4)上映射80端口到192.168.0.2的80端口,这样INTERNET上就能以http://218.4.218.4:80的地址访问到192.168.0.2的WEB站点了。然后出现了个问题,在同网吧的另一台电脑192.168.0.3上,键入http://218.4.218.4:80,却无法访问该WEB站点。就这个现象,我们就称之为“不支持回流”了,这里指的是网关上的映射方式不支持回流,所以说“回流”一说,是针对映射方式而言的。

现在我们来看常规情况下,是为什么会发生这种情况的

过程如下: 192.168.0.3要请求访问218.4.218.4的80端口,根据它掌握的路由表,它本身是不知道电脑218.4.218.4在哪里的,所以把将这个数据包发送给它的默认路由,即电脑192.168.0.1。注意:这个数据包的源地址是192.168.0.3、源端口假设是1025、目标地址是218.4.218.4、目标端口是80、SYN标志位为1、这是建立TCP连接的第一次握手。如果“把目标地址为218.4.218.4的数据包发给了192.168.0.1”你听起来觉得有点矛盾,那么我解释一下:其实这个数据包的目标IP地址是218.4.218.4,目标MAC地址却是192.168.0.1的电脑192.168.0.1接收到了这份数据包(因为它的身份是路由器,所以允许接收和转发目标地址不是自已、MAC地址却是自已接口 MAC地址的数据包),它分析这个数据包的目标地址,发现这个数据包是需要中转到电脑192.168.0.2:80去的,于是它把这个数据包转发给了电脑 192.168.0.2:80。注意:这个数据包的源地址是192.168.0.3、源端口是1025、目标地址为192.168.0.2、目标端口为80、SYN标志位为1。我们要注意这个数据包在转发后发生了变化了,即目标地址变了。电脑192.168.0.2顺利接到了数据包,它马上作出回应,发送一个数据包给电脑192.168.0.3。注意:这个数据包的源地址是192.168.0.2、源端口是80、目标地址192.168.0.3、目标端口为1025、SYN标志位为1、ACK标志位为1、这是建立TCP连接的第二次握手。电脑192.168.0.3顺利接到了数据包,然而它发现这是一个来自192.168.0.2:80的回应,因为ACK标志位值为1摆在那里呢。它想不起来什么时候给192.168.0.2:80这个目标对象发送过SYN请求,它认为这是一个错误的数据包,于是决定把这个数据包丢弃。然后继续等待 218.4.218.4:80的回应,一直等到超时。而电脑192.168.0.2这边,它等192.168.0.3:1025的第三次握手请求包发送过来,以便建立一个TCP的连接。同样也没有结果,一直等到超时。三次握手在规定的时间内没有完成,访问宣布流产了。

那么怎么样才能正常访问呢?也就是说怎么样形成“回流”呢? 玄机在于电脑192.168.0.1把第一次握手的那个数据包在转发时,不仅要修改目标地址和端口,也要修改源地址和端口,我们来看一下情况会有什么不同:电脑192.168.0.1接收到了这份数据包(因为它的身份是路由器,所以允许接收和转发目标IP地址不是自已、MAC地址却是自已接口MAC地址的数据包),它分析这个数据包的目标地址,发现这个数据包是需要中转到电脑192.168.0.2:80去的,于是它把这个数据包通过自已的5201端口转发给了电脑192.168.0.2:80,并在内存里面记录下来了,192.168.0.1:5201已定位给了192.168.0.3:1025。注意:这个数据包的源地址是192.168.0.1、源端口是5201、目标地址为192.168.0.2、目标端口为80、SYN标志位为1。电脑192.168.0.2顺利接到了数据包,它马上作出回应,发送一个数据包给电脑192.168.0.1。注意:这个数据包的源地址是192.168.0.2、源端口是80、目标地址192.168.0.1、目标端口为5201、SYN标志位为1、ACK标志位为1、这是建立TCP连接的第二次握手。电脑192.168.0.1顺利接到了数据包,检查内存记录发现,这个数据包真正的收货人是192.168.0.3:1025,于是它把这个数据包转发给192.168.0.3。注意:这个数据包的的源地址是218.4.218.4、源端口为80、目标地址为192.168.0.3、目标端口为1025。我们要注意这个数据包在转发后发生变化了,即源地址变了。这很重要!为什么会变,因为在它心目当中,192.168.0.2:80早已定位给了218.4.218.4:80,映射规则使然。电脑192.168.0.3顺利接到了数据包,发现期待已久的218.4.218.4:80终于有了回音,它兴奋不已的发出第三次的握手请求。注意:这个数据包的源地址是192.168.0.3、源端口是1025、目标地址是218.4.218.4、目标端口是80、ACK标志位为1、这是建立TCP连接的第三次握手。跟前面的数据包一样,这个数据包会从192.168.0.1那里中转给192.168.0.2以后192.168.0.2:80和192.168.0.3:1025之间来往通信的数据包,全部由192.168.0.1负责中转,“回流”构成了

===========   [精华] NAT后无法在内网通过外部IP访问内部服务的问题的详细说明(原创) http://www.chinaunix.net 作者:fushuyong  发表于:2005-05-11 09:41:20【发表评论】 【查看原文】 【网络技术讨论区】【关闭】 最近,到处看到有人问这个问题,怎么以前没人问,现在这么多人问呢?前两天我还在华为的论坛上仔细的说了这个问题,现在复制到这边来。希望能帮助大家理解这个问题。      这是个理论问题,我们先从NAT讲起:NAT有两种基本类型,一种是SNAT(Source NAT),一种是DNAT(Dest. NAT).SNAT即源NAT是改变数据包的IP层中的源IP地址,一般是用来将不合法的IP外出请求转换成合法的IP的外出请求,就是普通的用一个或者几个合法IP来带动一整个非法IP段接入。 DNAT即目的NAT,就是改变数据包的目标IP地址,使得能对数据包重新定向,可以用做负载均衡或者用于将外部的服务请求重定向到内网的非法IP的服务器上。        好了,罗嗦了一通,大致就是这样了。 那么之所以会出现无法在DNAT的内部网络通过DNAT服务的外部IP地址来访问的情况,是因为,如果服务从内部请求,那么经过DNAT转换后,将目标IP改写成内网的IP地址,譬如172.16.10.254,而请求的机器的IP是 172.16.10.100,数据包被网关172.16.10.1顺利的重定向到172.16.10.254的服务端口,然后,192.16.10.254根据请求发送回应给目的IP地址,就是172.16.10.100,但是,问题出现了,因为172.16.10.100请求的地址是外部IP 假设是221.232.34.56,所以他等待着221.232.34.56的回应,而172.16.10.254的回应请求被看做是非法的,被丢弃了。这就是问题的所在了。       呵呵,写的有点混乱,不好意思。不知道大家明白没有.那么如何解决这个问题,我说个用iptables实现的例子,     #我们先把发向外网IP221.232.34.56 80号端口的数据重定向到172.16.10.254 理论上来讲,如果只要从外网访问,这就完成了。     iptables -t nat -A PREROUTING -p tcp -d 221.232.34.56 --dport 80 -j DNAT --to-destination 172.16.10.254      #解决内网通过外网IP访问的情况     iptables -t nat -A POSTROUTING -p tcp -d 172.16.10.254 --dport 80 -j SNAT --to-source 172.16.10.1     我们将内网的请求强行送回到网关172.16.10.1,依靠网关在内核建立的状态表再转发到真实的请求地址172.16.10.100.     当然,这并不是最好的解决方法,最好的解决方法是将服务器放在另外一个网段,也就是说所谓的DMZ(解除武装区),这样就不会出现上面所说的问题了。     如果大家还不清楚,给个参考文档:     http://iptables-tutorial.frozentux.net/iptables-tutorial.html#DNATTARGET           就先说到这里了,我要去上班了。 http://www.chinaunix.net/old_jh/30/372269.html ============ http://cn.club.vmall.com/thread-1746375-1-1.html 路由器回流(端口映射特例) 回流是什么?最简单的一个实例: 网吧内网一台主机192.168.0.2建了个WEB服务站点端口80,然后在网关(其内网地址是192.168.0.1、公网地址为218.4.218.4)上映射80端口到192.168.0.2的80端口,这样INTERNET上就能以 http://218.4.218.4:80的地址访问到192.168.0.2的WEB站点了。 然后出现了个问题,在同网吧的另一台电脑192.168.0.3上,键入 http://218.4.218.4:80,却无法访问该WEB站点。 就这个现象,我们就称之为“不支持回流”了,这里指的是网关上的映射方式不支持回流,所以说“回流”一说,是针对映射方式而言的。 现在我们来看常规情况下,是为什么会发生这种情况的 我以前对iptables特别感兴趣的时候,曾对这个问题非常迷惑不解,直到去年为了考试,学习网络基础的时候才搞明白这个事情 过程如下: 192.168.0.3要请求访问218.4.218.4的80端口,根据它掌握的路由表,它本身是不知道电脑218.4.218.4在哪里的,所以把将这个数据包发送给它的默认路由,即电脑192.168.0.1。 注意:这个数据包的源地址是192.168.0.3、源端口假设是1025、目标地址是218.4.218.4、目标端口是80、SYN标志位为1、这是建立TCP连接的第一次握手。 如果“把目标地址为218.4.218.4的数据包发给了192.168.0.1”你听起来觉得有点矛盾,那么我解释一下:其实这个数据包的目标IP地址是218.4.218.4,目标MAC地址却是192.168.0.1的 @苍星归来 电脑192.168.0.1接收到了这份数据包(因为它的身份是路由器,所以允许接收和转发目标地址不是自已、MAC地址却是自已接口 MAC地址的数据包),它分析这个数据包的目标地址,发现这个数据包是需要中转到电脑192.168.0.2:80去的,于是它把这个数据包转发给了电脑 192.168.0.2:80。 注意:这个数据包的源地址是192.168.0.3、源端口是1025、目标地址为192.168.0.2、目标端口为80、SYN标志位为1。我们要注意这个数据包在转发后发生了变化了,即目标地址变了。 电脑192.168.0.2顺利接到了数据包,它马上作出回应,发送一个数据包给电脑192.168.0.3。 注意:这个数据包的源地址是192.168.0.2、源端口是80、目标地址192.168.0.3、目标端口为1025、SYN标志位为1、ACK标志位为1、这是建立TCP连接的第二次握手。 电脑192.168.0.3顺利接到了数据包,然而它发现这是一个来自192.168.0.2:80的回应,因为ACK标志位值为1摆在那里呢。它想不起来什么时候给192.168.0.2:80这个目标对象发送过SYN请求,它认为这是一个错误的数据包,于是决定把这个数据包丢弃。然后继续等待 218.4.218.4:80的回应,一直等到超时。 而电脑192.168.0.2这边,它等192.168.0.3:1025的第三次握手请求包发送过来,以便建立一个TCP的连接。同样也没有结果,一直等到超时。三次握手在规定的时间内没有完成,访问宣布流产了。 那么怎么样才能正常访问呢?也就是说怎么样形成“回流”呢? 玄机在于电脑192.168.0.1把第一次握手的那个数据包在转发时,不仅要修改目标地址和端口,也要修改源地址和端口,我们来看一下情况会有什么不同: 电脑192.168.0.1接收到了这份数据包(因为它的身份是路由器,所以允许接收和转发目标IP地址不是自已、MAC地址却是自已接口MAC地址的数据包),它分析这个数据包的目标地址,发现这个数据包是需要中转到电脑192.168.0.2:80去的,于是它把这个数据包通过自已的5201端口转发给了电脑192.168.0.2:80,并在内存里面记录下来了,192.168.0.1:5201已定位给了192.168.0.3:1025。 注意:这个数据包的源地址是192.168.0.1、源端口是5201、目标地址为192.168.0.2、目标端口为80、SYN标志位为1。 电脑192.168.0.2顺利接到了数据包,它马上作出回应,发送一个数据包给电脑192.168.0.1。 注意:这个数据包的源地址是192.168.0.2、源端口是80、目标地址192.168.0.1、目标端口为5201、SYN标志位为1、ACK标志位为1、这是建立TCP连接的第二次握手。 电脑192.168.0.1顺利接到了数据包,检查内存记录发现,这个数据包真正的收货人是192.168.0.3:1025,于是它把这个数据包转发给192.168.0.3。 注意:这个数据包的的源地址是218.4.218.4、源端口为80、目标地址为192.168.0.3、目标端口为1025。我们要注意这个数据包在转发后发生变化了,即源地址变了。这很重要!为什么会变,因为在它心目当中,192.168.0.2:80早已定位给了218.4.218.4:80,映射规则使然。 电脑192.168.0.3顺利接到了数据包,发现期待已久的218.4.218.4:80终于有了回音,它兴奋不已的发出第三次的握手请求。 注意:这个数据包的源地址是192.168.0.3、源端口是1025、目标地址是218.4.218.4、目标端口是80、ACK标志位为1、这是建立TCP连接的第三次握手。 跟前面的数据包一样,这个数据包会从192.168.0.1那里中转给192.168.0.2 以后192.168.0.2:80和192.168.0.3:1025之间来往通信的数据包,全部由192.168.0.1负责中转,“回流”构成了


【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3