NAT 規則阻止埠 1433 上的 TCP 流量
我們有一個託管在 AWS 上的 SQL 伺服器，它不能直接在 Internet 上訪問，它依賴於 NAT 框將流量路由到它。
我們正在嘗試建立一個從這台伺服器到 AWS 之外的另一個伺服器的連結 SQL 伺服器，這需要兩個 SQL 伺服器在埠 1433 TCP 上相互通信。
iptable 中的相關部分如下所示：
目標 prot 源目標
DNAT udp 隨時隨地 udp dpt:ms-sql-m to:172.10.10.10:1434
DNAT tcp 隨時隨地 tcp dpt:ms-sql-s to:172.10.10.10:1433
根據我們自己的測試，我們知道我們可以將任何伺服器連結到 AWS 上的伺服器，但反之則不行。
有什麼看起來不對嗎？當我們的 intfra 工程師“刪除並添加相同的規則”時，問題開始出現。這有什麼線索嗎？訂單是否相關？
使用tracetcp我們發現以下內容：
在 aws sql server ’tracetcp.exe 183.23.53.22 1433’ 上執行此命令，其中 ip 是另一個外部託管伺服器的 IP，它會在 1 跳內到達目的地，但它也會在無視任何隨機的情況下執行相同的操作我們試過的IP地址。
就好像我們在 1433 以外的另一個埠上執行了相同的命令，它會首先命中 NAT 框，然後執行許多躍點
檢查您的 iptables 規則
iptables-save並重新發布它們。驗證您的 DNAT 規則是否有某種方法可以排除源自網路內部的流量，例如-i <extif>、! -i <intif>或! -s 172.10.10.10。我強烈懷疑它會將您的數據包重新發送回內部源伺服器。
可能是您在埠 1433 上有一個正在執行的代理，這可能會導致您描述的行為。代理會立即接受與內部機器的連接，這就是為什麼您會得到如此短的 2 毫秒響應。
此外，您的數據包沒有離開您的 LAN 的一個很好的指標是回复時間如此短（1-4 毫秒）。如果您不小心啟動了任何代理程序，請嘗試檢查您的 NAT 框，如果沒有，請嘗試禁用埠 1433 (tcp) 的 DNAT 規則以查看問題是否仍然存在。
此外，“不能直接在 Internet 上訪問，它依賴 NAT 框將流量路由到它”的說法是矛盾的，因為機器可以在 Internet 上訪問，但在特定埠上，通過該埠進行 NAT 轉換， 對？
如果您真的想保護您的服務免受外界影響，那麼考慮某種 VPN 可能是一個聰明的主意？或者，如果您想要一個更簡單的解決方案（但不如 VPN 安全），您可能只允許從已知的遠端 IP 地址訪問該 NAT 埠（在某些情況下攻擊者可以欺騙）。