來看下這樣的一個架構，web服務器默認路由指向FW，web服務器前有一個standard load balancer，web服務器是它的後端池，LB上配置了80端口的規則，web服務器本身沒有公網IP，再這樣的架構下，有兩個問題
Web服務器是否能訪問internet
在internet通過standard lb是否能訪問web服務器上的nginx
我們一個個來看，standard lb後端的服務器，默認是不能訪問internet的，那麼如果它的默認路由指向Firewall呢？
經過測試發現，訪問完全沒有問題
那麼，第二個問題呢，首先來看下LB的配置，其實很簡單
可以看到只是簡單配置了一個80的規則
但是測試發現，lb的ip一直沒辦法ping通
但是，在把指向FW的默認路由去掉之後，我們發現可以ping通了
這是爲什麼呢？其實微軟的文檔已經給了我們解釋
這種現象叫非對稱路由，理解上其實很簡單，因爲入站的時候是通過LB進來的，但是回去的時候因爲默認路由的原因，卻要從FW出去，FW上沒有這個會話，就回導致把包丟掉
非對稱路由
非對稱路由是指數據包採用一條路徑發往目標，並採用另一條路徑返回到源。 如果子網的默認路由轉到防火牆的專用 IP 地址，並且使用的是公共負載均衡器，則會出現非對稱路由問題。 在這種情況下，將通過負載均衡器的公共 IP 地址接收傳入的負載均衡器流量，但返回路徑將通過防火牆的專用 IP 地址。 由於防火牆是有狀態的，並且無法識別此類已建立的會話，因此會丟棄返回的數據包。
這個問題其實也是可以有辦法解決的，官網的解釋是說，如果防火牆後邊跟的是public lb，則需要創建一個到防火牆public ip的UDR規則，下一條是internet，否則azure會通過默認路由發給防火牆的private ip，同時流量的入口也不能是LB，而應該是FW
下邊我們就來試下，整個流量是這樣的FW -> Public Standard LB -> WEB
首先，先在FW上配置到LB的NAT規則
但是測試發現，端口連不上
接下來再試下添加到FW 公網IP的路由
這次終於訪問成功了
