我們使用 Azure VPN 閘道和各個用戶端位置的各種本機網路設備建立站對站 VPN 連線。我們正在嘗試建立新連接，但 IP 範圍與另一端的網路發生衝突。下圖雖然在客戶端有一個鬆散的解釋，因為我沒有他們端的所有細節，但它可能最好地解釋了它，但事實如下：
- 網路 A (192.168.1.0/24) 位於我們的 Azure VPN 閘道後面，由我們負責。
- 網路 B (192.168.2.0/24) 是源自網路 A 的封包的目標網絡，由我們的客戶負責，並託管在私有雲中。
- 網路 C (192.168.1.0/24) 是私有雲內的另一個網絡，與我們的流量無關，只是它代表客戶端私有雲內的 IP 範圍衝突。
Azure 支援人員表示，唯一的補救措施是重新分配衝突網路之一的 IP，因為目前不支援衝突範圍。他們認為，NAT 在隧道兩端都不是可行的解決方案。也不支援在 Azure VPN 閘道後面新增子網路並將流量轉送/NAT 到網路 A。
由於重新分配網路 A 的 IP 的後果，我們不想重新分配它的 IP。毫不奇怪，客戶也不想重新分配其網路（網路 C）的 IP。也許我只是否認，但還有其他人遇到過這種情況並成功解決它嗎沒有重新IP化？如果是這樣，任何支援可參考的解決方案的文件或配置將不勝感激。
預先感謝您的任何幫助。
答案1
- 具體路由
您已寫道，您對A 和B 網路之間的路由感興趣，這並不衝突...如果SonicWall 在此「內部客戶端網路」之間進行路由，並且可以不使用網路C 上的特定IP ，您可以透過以下方式進行路由該網路不是針對整個 192.168.1.0/24，而是針對特定 IP（如 /32）。在路由決策中「更好的匹配獲勝」。在這種情況下，特定流量將從 B 正確路由到 A，而其餘流量將傳遞到網路 C...
根據 VPN 類型，在 SonicWall 上配置可能更容易或更困難（如果可能），但從技術上講，這可能是沒有 NAT 的方式。在最壞的情況下，您可以使用其他裝置終止到 Azure 的 VPN，而 SonicWall 上有靜態路由規則將這些 IP 導向到該附加節點。
這樣，Azure 端將永遠無法從 C 訪問，但根據您所寫的內容，這不會是問題。
- 網路位址轉換
如您所寫，Azure VPN GW 不提供此功能，唯一的選擇可能是在隧道的另一側 - SonicWall 設備上執行此操作。從B、C 端，您可以尋址「遠端」站點，例如任何未使用的IP 範圍（例如172.16.0.0/24），一旦到達SonicWall，它就可以路由到VPN，而在離開節點之前，它將被dNATed/映射到 192.168.1.0/24，同時保留最後一個八位元組值或執行 1:1 映射，列出所有需要的 IP）。這樣，對於 VPN 流量，Azure 端的遠端 IP 將是「正確的」192.168.0.0/24，且 Azure 端將不知道 NAT。
如果您因任何原因無法在SonicWall 上執行此操作，則可以放置另一個能夠執行此操作的設備/在自己的管理下，這將終止VPN 隧道，並且來自本地網路的172.16.0.0/24 流量將成為目標（路由在本地路由器上）。
唯一有問題的是您使用 DNS 應答 192.168.1.0/24 位址和使用 IP 進行識別的憑證的情況。對於 DNS 內容，您需要具有「更新」值的本機 DNS 區域，以便用戶端聯絡「正確」端點。