無法透過 PfSense 防火牆後面的同一伺服器上的 HTTPS 存取網域

無法透過 PfSense 防火牆後面的同一伺服器上的 HTTPS 存取網域

我在具有多個網域的伺服器上託管一個平台,例如 example.com 和 anotherexample.com。我正在該伺服器上執行 Spring Boot 後端,它使用網域 example.com 並嘗試與 anotherexample.com 進行通訊。我的問題是我似乎無法透過 HTTPS 連接到其他網域,它甚至無法連線。我嘗試了以下返回不同結果的測試:

  1. curl在不在防火牆後面的計算機上使用https://anotherexample.com,完美運作
  2. curl在伺服器上使用,而是使用http://anotherexample.com,完美運作
  3. curl在伺服器上使用https://anotherexample.com,沒有響應,最終超時
  4. curl在防火牆上使用https://anotherexample.com,沒有響應,最終超時
  5. 在伺服器上使用openssl s_client -connect anotherexample.com:443 -servername anotherexample.com,無回應​​,最終超時
  6. /etc/hosts在伺服器上更改為127.0.0.1 anotherexample.com,運行時 openssl s_client -connect anotherexample.com:443 -servername anotherexample.com,我得到回應。

導致我無法連接到防火牆後面的電腦上託管的任何網域的問題可能是什麼,是否是伺服器(Ubuntu 22.04)或 PfSense 防火牆(2.7.2)上的設定錯誤。


我的架構如下:

  • PfSense 防火牆使用 NAT 來確保公用 IP 到達伺服器的內部 IP
  • 伺服器運行 NGINX,連接埠 80 和 443 開啟。證書透過 LetsEncrypt 完成並在瀏覽器中完美運行

答案1

這很正常;當來源和實際目標位於同一子網路(或實際上是相同系統)時,DNAT(「連接埠轉送」)不起作用。許多早期的帖子都涉及與家庭網關相同的問題(搜尋“NAT Hairpin”),但它同樣適用於包括 pfSense 在內的任何 NAT 實現,因此請搜尋早期的帖子以獲取完整的解釋;基本問題是防火牆只能在一個方向上重寫資料包,而不能在另一個方向上重寫資料包。

常見的解決方法是讓 pfSense 也重寫來源 IP 位址,讓 Web 伺服器看起來好像連線實際上來自防火牆而不是自身。為此,請啟用NAT反射在你的防火牆中。在其他地方,它被稱為“NAT 環回”、“NAT 髮夾”,或只是一個沒有特定名稱的自訂 SNAT 規則。

請注意,這會對效能產生輕微影響,因為每個資料包都必須透過乙太網路到達 pfSense回來,而不是能夠完全留在機器內。如果您使用基於 IP 的訪問,您的 Web 應用程式還需要預期防火牆 IP。

所以我個人會推薦所有網域的 /etc/hosts條目127.0.0.1而不是依賴 NAT 反射。

相關內容