标题有点绕，问题就是在公网出接口上配置了内网某台服务器的端口映射，内网的普通用户通过内网地址访问正常，但无法通过公网IP进行正常访问，拓扑图如下：
上图以出接口地址100.100.100.100:80映射为192.168.1.11:80为例，实际问题为192.168.1.100与192.168.1.110无法通过100.100.100.100:80进行访问，但通过互联网访问映射端口正常。
问题原因分析
假设以192.168.1.100通过公网访问192.168.1.11:80的话，这里假设访问的源端口是10000，目标端口是80，主机发起web请求，那么访问目标就是100.100.100.100:80即数据包分析如下：
192.168.1.100:10000—>100.100.100.100:80
数据包最终会被路由到防火墙上，防火墙检查访问的目的地址，匹配到它的端口映射策略，将目标地址改为对192.168.1.11的访问，建立起一个针对目标ip地址转换的NAT会话表：
192.168.1.100:10000—>192.168.1.11:80
然后数据包到会被转发到192.168.1.11服务器上并会响应192.168.1.100主机的请求，将上述访问的源目ip地址及端口进行倒转，并将数据包交给它的网关处理，拓扑中即为USG防火墙：
192.168.1.11:80—>192.168.1.100:10000
网关发现目标ip地址是192.168.1.100，是在路由表中的内网直连地址，就会将数据包直接路由到主机上，主机接收到数据包，检查数据包的源ip和端口是192.168.1.11:80，发现其本身并没有这样一个http会话与之相匹配，就是说主机并没有主动发起对192.168.1.11:80的访问，实际发起的是对100.100.100.100:80的访问，那么主机就会丢弃这个数据包，导致内网用户通过域名或者公网ip地址访问自己的内网服务器不通的现象。
192.168.1.11:80—>192.168.1.100:10000
发生上述问题的原因，就是因为网关发现响应数据包的目的ip地址是内网一个可直接路由的地址，就会直接在内网进行路由转发。然而这并不是一个BUG，任何设备只要做了端口映射，都绕不开这个问题，因为TCP/IP协议栈就是这样工作的，有的设备在你做端口映射的时候，偷偷地把端口回流的问题也给你解决了。然而你也不要以为它们帮你做了端口回流，你就认为那些设备是好设备，感觉好高端，那你错了，我很少见企业级设备偷偷地帮你解决这个问题的(不是说没有，一般是应用层网络设备有这个)，都是需要你主动去处理解决，这也体现了它们设备高度可定制性及专业性。
问题解决方案
实际解决这个问题也很简单，即在192.168.1.100:10000访问192.168.1.11:80的时候，不走内网路由，再做一次回流的NAT映射即可。
回流NAT映射验证
参考: 转载 https://www.xj123.info/8094.html
https://blog.51cto.com/11555417/2288036
http://www.360doc.com/content/18/0419/01/11935121_746788625.shtml
https://blog.csdn.net/weixin_30376509/article/details/97982837?utm_medium=distribute.pc_aggpage_search_result.none-task-blog-2~all~first_rank_v2~rank_v28-1-97982837.nonecase&utm_term=%E9%98%B2%E7%81%AB%E5%A2%99%E5%81%9A%E5%9B%9E%E6%B5%81%E9%85%8D%E7%BD%AE&spm=1000.2123.3001.4430