標題有點繞，問題就是在公網出接口上配置了內網某台服務器的端口映射，內網的普通用戶通過內網地址訪問正常，但無法通過公網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