求助一个奇怪的网络问题，希望有细心人能看明白，并且给推断一下原因，有奖解决
本帖最后由 cloudq 于 2018-6-28 20:18 编辑求助一个奇怪的网络问题，希望有细心人能看明白，并且给推断一下原因，有奖解决，能找到原因并且最终解决该现象的朋友，赠送Aerohive品牌无线AP一台，具体看下图，如果还有不明白之处，可以留言我给做详细解答:
1. 192.168.100.xx/24 本地局域网，RAP 和PC都在这个局域网，局域网网关为192.168.100.222位于Home Router上
2.111.37.21.67是home router最终从运营商的网络出去后的公网ip,远端的服务器上也会看到是这个公网ip在访问自己的服务
3. 47.104.193.111 是托管在公网的服务器，可以远程通过WEB SSH等多种服务访问，该IP和服务器物理上的172.31.4.51 IP存在1:1的dst-nat关系.
4. 172.31.4.52 是服务器的loopback 口ip192.168.11.x/24网段这个网段平时不存在，只有RAP发起ipsec vpn之后 他的路由表中才会出现，这个网段在服务器上也没有 但ipsec tunnel口的ip 172.16.200.xx居然在路由表里看不到，但RAP上面的确存在一个172.16.200.xx ip
~ # ifconfig
tun0 Link encap:UNSPECHWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:172.16.200.29P-t-P:172.16.200.29Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICASTMTU:1300Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:19 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:64
RX bytes:0 (0.0 B)TX bytes:6094 (5.9 KiB)
~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
47.104.193.111192.168.100.222 255.255.255.255 UGH -3 0 0 br0
172.31.4.52 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
0.0.0.0 192.168.100.222 0.0.0.0 UG -3 0 0 br0
5.现在问题就是平时192.168.100.xx网段的pc可以任意访问47.104.193.111上面的web ssh等服务，只要RAP建立ipsec隧道，PC立刻无法访问47.104.193.111上的任何服务了，但依然可以ping通47.104.193.111，这时候找了一个其他地区的网友测试，他是可以正常访问47.104.193.111上的服务的，而我本地就不能访问，当我断开RAP的时候等几分钟后一切恢复正常访问.
本帖最后由 cloudq 于 2018-7-1 16:00 编辑
来我现在挨个回答各个问题
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) 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) 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的全部跟着遭殃，这就是结果，呵呵！
帮顶
此处省略1000字 本帖最后由 scdzylq 于 2018-6-28 20:11 编辑
有点儿不明白，VPN连接后相当于连接到了另外一个局域网（192.168.11.X/24）怎么没有网关？可不可以为VPN后你这台PC只能与192.168.11.X/24网段的其它PC通信（同一个局域网），如果要与其它网段通信，要不要用到网关呢？我是这么觉得的。是不是要再设置一下网关呢？ 本帖最后由 scdzylq 于 2018-6-28 20:17 编辑
172.16.200.29/32这个不是代表一个主机吗？
Destination Gateway Genmask Flags Metric Ref Use Iface
47.104.193.111192.168.100.222 255.255.255.255 UGH -3 0 0 br0 #是不是代表访问47.104.193.111/32这台主机的下一跳是192.168.100.222
172.31.4.52 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 #环回口
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 #直连网络
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 br0 #这是VPN后的路由，是不是需要设置网关才能访问47.X.X.X主机的服务呢？
我也刚学网工 个人的想法也不知道对不对
scdzylq 发表于 2018-6-28 20:12
172.16.200.29/32这个不是代表一个主机吗？
tunnel 的ip都是32位掩码，你如果回去仔细看看你pppoe拨号后获得的ip也是这样的 scdzylq 发表于 2018-6-28 20:09
有点儿不明白，VPN连接后相当于连接到了另外一个局域网（192.168.11.X/24）怎么没有网关？可不可以为VPN后 ...
192.168.11.x这个网络其实可能根本都不存在，是因为对端某些设置造成的，但其实是否存在这个网络基本没啥影响 scdzylq 发表于 2018-6-28 20:09
有点儿不明白，VPN连接后相当于连接到了另外一个局域网（192.168.11.X/24）怎么没有网关？可不可以为VPN后 ...
你对网关的理解还是太肤浅，网关只是一条默认路由，有没有网关并不影响整个路由过程，只要你有合理的路由表即可，你对网络的理解，我看你很难吃透这里面的问题，慢慢看看吧 cloudq 发表于 2018-6-28 20:16
你对网关的理解还是太肤浅，网关只是一条默认路由，有没有网关并不影响整个路由过程，只要你有合理的路由 ...
跟着大神学呀 我也才开始学网工 积极参与嘛 scdzylq 发表于 2018-6-28 20:19
跟着大神学呀 我也才开始学网工 积极参与嘛
慢慢来吧，你先看看下面这个问题，这个问题目前已经找到原因，你自己仔细看看，能找到原因并且解决，你就算更进一步了
http://www.anywlan.com/thread-433943-1-1.html 其他地区网友测试时，他是不是ipsec啊？另外可不可以这样，RAP建立ipsec隧道后不能访问了，但可以ping通47，一边持续ping47，一边此时把111.37.21.67断开，看看能否继续通？ chen7362 发表于 2018-6-29 11:43
其他地区网友测试时，他是不是ipsec啊？另外可不可以这样，RAP建立ipsec隧道后不能访问了，但可以ping通47 ...
其他地区网友测试的时候还是我这边建立的ipsec, 其实说白了，谁建立ipsec,谁那边整个网络就都访问不了web ssh这些服务了,很明显和发起ipsec的公网ip有关，凡是属于这公网ip的一律无法访问，只能ping 本帖最后由 cloudq 于 2018-6-29 12:27 编辑
chen7362 发表于 2018-6-29 11:43
其他地区网友测试时，他是不是ipsec啊？另外可不可以这样，RAP建立ipsec隧道后不能访问了，但可以ping通47 ...
你要注意一点并不是建立ipsec的设备无法访问了，是建立ipsec的整个网段的pc无法访问了,还有就是ipsec只是建立了隧道，其实还并未和对面真正连通，那是我下一步想要解决的问题.
比如建立ipsec的设备是192.168.100.201,但这时候整个192.168.100.xx的pc都访问不了公网47那边的web ssh以及其他服务了，但还都能ping的通47