求助一个奇怪的网络问题，希望有细心人能看明白，并且给推断一下原因，有奖解决

cloudq

日照无线 发表于 2018-6-30 08:59
应该是服务器端NAT问题与ipsec穿透共同造成的，如果服务器能PING 通是能PING通服务器的网关，并不是服务器 ...

我为啥说要细心人呢，因为有很多人还没完全看明白就开始猜测

1.47.104.193.111 这个ip并不是服务器的网关，也不是任何接口地址，而是1:1映射的ip地址，如果阿里云服务器172.31.4.51关机，这个地址就不通了，因为你对47.104.193.111的访问其实是 172.31.4.51回应的，而47.104.193.111这个地址并不是防火墙物理接口的地址，很多人理解不了这一点

2. 1:1 nat一直有效，为啥我说他一直有效呢？因为当我访问不了47.104.193.111的时候，任何其他人只要不是和我同一个公网ip的都能访问

所以我只能说你理解的比其他用户多一些，但你依然不是仔细人,一切全从自己想象角度出发的

cloudq

chen7362 发表于 2018-6-30 11:51
老哥，你在17楼说的          “这不奇怪，因为rap的ipsec隧道并没有通，但奇怪的是和rap同一个局域网里 ...

PC的任何数据包均不走RAP,除非是和rap直接通信的，凡是走出同一个L2网段的数据包，均和RAP无任何联系

难道你PC1去访问一个三层地址，还关PC2屁事？这就是同一个道理，你现在整个概念混乱，基础底层知识太不扎实

cloudq

日照无线 发表于 2018-6-30 09:17
IPSEC封装时，是把IPSEC的源目地址也一起封装了，外边虽然加了IP包头信息，１：１NAT网关也做了地址转换， ...

这是一个关键，但还是太笼统，随后我仔细写个分析出来再继续说

cloudq

日照无线 发表于 2018-6-30 09:17
IPSEC封装时，是把IPSEC的源目地址也一起封装了，外边虽然加了IP包头信息，１：１NAT网关也做了地址转换， ...

来现在开始从头分析一下这个过程


当RAP未建立ipsec 隧道的时候
1.整个192.168.100.xx网段的pc包括RAP访问远程服务器47.104.193.111，到了home router之后，源ip被转换为home router 外网ip（此ip非公网ip)
2.当数据包到了运营商边缘路由器的时候home router 外网ip再次被S-nat(NAPT)为 111.37.21.67,这个ip才是公网ip,而且此ip在远端VMC也是可以看到的
3.当数据包到了阿里云防火墙的时候，防火墙把目的ip 47.104.193.111 Dst-nat 到172.31.4.51；这时候整个访问过程变成了111.37.21.67 访问 172.31.4.51


数据包回去的时候整个过程是相反的
1.源ip 172.31.4.51 发送返回数据包给 111.37.21.67
2.到了阿里云防火墙，源172.31.4.51变成47.104.193.111 ，此时数据包变成47.104.193.111发给111.37.21.67
3.到了与运营商边缘路由器的时候，再做一次dst-nat(其实是利用的源src-nat的nat表),整个过程变成了47.104.193.111发给home router外网ip(此ip非固定，非公网ip)
4.home router内部再改一次目的地址 将源47.104.193.111过来的数据包变成访问192.168.100.xx的数据包
至此整个访问过程完成.


这位叫日照无线的朋友，你如果的确是有能力，而且又吃透了工作原理，你就来写一下并且分析一下rap启动ipsec 隧道之后的 192.168.100.xx的pc访问47.104.193.111的过程，请注意的一点是所有pc的默认网关均是home router,也就是说他们决不会走rap去传送数据包的.

cloudq

chen7362 发表于 2018-6-30 11:51
老哥，你在17楼说的          “这不奇怪，因为rap的ipsec隧道并没有通，但奇怪的是和rap同一个局域网里 ...

来现在开始从头分析一下这个过程


当RAP未建立ipsec 隧道的时候
1.整个192.168.100.xx网段的pc包括RAP访问远程服务器47.104.193.111，到了home router之后，源ip被转换为home router 外网ip（此ip非公网ip)
2.当数据包到了运营商边缘路由器的时候home router 外网ip再次被S-nat(NAPT)为 111.37.21.67,这个ip才是公网ip,而且此ip在远端VMC也是可以看到的
3.当数据包到了阿里云防火墙的时候，防火墙把目的ip 47.104.193.111 Dst-nat 到172.31.4.51；这时候整个访问过程变成了111.37.21.67 访问 172.31.4.51


数据包回去的时候整个过程是相反的
1.源ip 172.31.4.51 发送返回数据包给 111.37.21.67
2.到了阿里云防火墙，源172.31.4.51变成47.104.193.111 ，此时数据包变成47.104.193.111发给111.37.21.67
3.到了与运营商边缘路由器的时候，再做一次dst-nat(其实是利用的源src-nat的nat表),整个过程变成了47.104.193.111发给home router外网ip(此ip非固定，非公网ip)
4.home router内部再改一次目的地址 将源47.104.193.111过来的数据包变成访问192.168.100.xx的数据包
至此整个访问过程完成.


这位朋友，你就别给我东一榔头西一棒槌的扯东扯西了，你如果的确是有能力，而且又吃透了工作原理，你就来写一下并且分析一下rap启动ipsec 隧道之后的 192.168.100.xx的pc访问47.104.193.111的过程，请注意的一点是所有pc的默认网关均是home router,也就是说他们决不会走rap去传送数据包的.

cloudq

日照无线 发表于 2018-6-30 08:59
应该是服务器端NAT问题与ipsec穿透共同造成的，如果服务器能PING 通是能PING通服务器的网关，并不是服务器 ...

千万不要认为47.104.193.111是配置在任何接口上的，这是真实的1:1 nat 我把172.31.4.51给你关机，你就再也ping不通他了，你现在就可以访问到47.104.193.111，这是真实案例

chen7362

cloudq 发表于 2018-6-30 12:41
PC的任何数据包均不走RAP,除非是和rap直接通信的，凡是走出同一个L2网段的数据包，均和RAP无任何联系

...

我从没说过PC的包会和RAP有关系，PC的包对外又不会经RAP，我就是在愚蠢这个不至于看不出来。

chen7362

cloudq 发表于 2018-6-30 12:59
来现在开始从头分析一下这个过程

水平如此就吃透这些东西

隧道之后的 pc访问47.104.193.111的过程    无非就是未建立隧道前的过程。

cloudq

chen7362 发表于 2018-7-1 12:07
水平如此就吃透这些东西

隧道之后的 pc访问47.104.193.111的过程    无非就是未建立隧道前的过程。

不管怎样能静心坐下来分析就是好样的，稍后我仔细看看再给继续讨论

cloudq

来我现在挨个回答各个问题
1.运营商边缘路由器是一大堆人共享，他不会给任何人做任何映射，他上面唯一能给你保证的就是只有src-nat,就是把你这一大堆各种乱七八糟的私有内网ip做NAPT出去变成公网IP
2.不光是运营商边缘路由器，还有整个一路的各种防火墙都可能给你屏蔽掉关键的协议以及端口，比如UDP 4500 500 GRE协议等等，这一点也不奇怪，后面我会告知如何去判断这些，其实作为一个合格的网络工程师，自己很容易想各种办法去测试这些，比如用telnet测试tcp端口，用netcat测试udp端口，再不行，直接从对端建立ROS服务，这边发起连接可以测试出中间这一路是否对某些协议做出了限制
我目前主要用到的协议时GRE 以及UDP 4500,所以我暂时就测试到底从我这边的pc客户端能否突破层层封堵到达对方


UDP 4500 用netcat协议测试是通的，当然你不能过分相信netcat的测试结果，毕竟udp协议的测试和tcp不太一样，tcp测试结果基本是100%可信的，udp这个随后我会在对端用ros建立测试环境，同时测试gre协议的连通性.
C:\netcat>nc -vuz 47.104.193.111 69
47.104.193.111: inverse host lookup failed: h_errno 11004: NO_DATA
(UNKNOWN) [47.104.193.111] 69 (tftp) open
C:\netcat>nc -vuz 47.104.193.111 4500
47.104.193.111: inverse host lookup failed: h_errno 11004: NO_DATA
(UNKNOWN) [47.104.193.111] 4500 (ipsec-msft) open


以上是不是回答了你第二段所有的问题，也就是究竟边缘路由器有何策略？这些一方面是不必去操心，一方面你也无法知晓，你唯一能知道的就是他做了src-nat(napt),其他的需要你自己测试了，而且不仅限于边缘路由器，整个到达最终目的ip的这一路的防火墙，路由器均如此.

3.我再回答一下关于你最后一段话，你可能理解不了为什么可以ping通但无法访问，这其实很容易理解，因为只要对端47.104.193.111所在的防火墙或者路由器，有合理的设置(具体啥设置你可以猜一猜，呵呵),他是可以代为响应icmp的，
但他无法代为响应那些tcp服务，比如web ssh,所以最终体现为可以ping通47.104.193.111 但无法web ssh上去


这里再同时解释一下为啥我无法web ssh上去，而其他ip这时间里可以上去呢？因为VMC服务器172.31.4.51把和RAP同一个公网ip所有发来的数据包都当做是rap发来的，给回传到错误地方去了(你猜他都给传哪里去了？) 而其他公网ip的，因为他们没去和rap一样去VMC上捅篓子，所以VMC正常的把数据包发回了，所以可以访问，RAP在VMC上捅的篓子造成所有和他一个公网ip的全部跟着遭殃，这就是结果，呵呵！

cloudq

最后再说一下如何用netcat测试udp服务端口，但不可过分相信这个测试，因为TCP的工作机制，tcp测试是可以100%确认正确的，UDP确不一定，所以最好自己通过其他方法测试一下，比如我远程测试了UDP端口69(tftp),但我测试远程tftp服务器上的文件确失败了，这问题现在还没考虑明白中.


下文是网上的连接
http://blog.51cto.com/kusorz/1749878

• 从netcat官方网站下载最新的netcat（NC的Windows版本）；
• 将程序解压到所需目录；
  
• 在cmd下切换到上述解压目录后，再使用指令测试目标服务器UDP端口的连通性：

  C:\>nc -vuz 1.1.1.1 5555 1.1.1.1: inverse host lookup failed: h_errno 11004: NO_DATA (UNKNOWN) [1.1.1.1] 5555(?) open C:\windows\system32>nc -vuz 1.1.1.1 5566 1.1.1.1: inverse host lookup failed: h_errno 11004: NO_DATA (UNKNOWN) [1.1.1.1] 5566(ntp) open

  如上所示，如果返回结果中，端口号后面的括号中返回的是？号，则说明相应的UDP端口访问失败；如果返回的是具体的协议类型，则说明相应的UDP端口访问正常。
  
  

chen7362

cloudq 发表于 2018-7-1 16:10
最后再说一下如何用netcat测试udp服务端口，但不可过分相信这个测试，因为TCP的工作机制，tcp测试是可以100 ...

谢谢 谢谢，多了解了一个工具的用法。