Proxy
使用 3rd-party API 時如何解決 IP 白名單？
我們使用的服務的 API 將拒絕請求，除非源 IP 先前已被列入白名單。他們只給了我們 3 個插槽，這是一個問題，因為我們有超過 3 台機器需要使用 API。
解決此問題的最常用技術是什麼？
*注意：*我不會嘗試違反 3rd-party API 的條款和條件。我們正在使用ResellerClub，我聯繫他們要求更多插槽，但他們回答：
我請求您將您的伺服器路由到幾組 IP。
因此這個問題。
想法：
- 我在想我們可以通過執行一種充當中間人的代理來解決這個問題。我們沒有向第 3 方發出 API 請求，而是向我們的代理髮出請求，該代理將請求反彈給第 3 方，因此所有請求似乎都來自他們眼中的一個 IP。有沒有做這種事情的通用軟體？這樣做似乎比下面的想法更簡單，但我錯了嗎？
- 我應該研究使用“一個 NAT 實例”嗎？例如http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html。它看起來很複雜 - 沒有更簡單的解決方案嗎？（執行具有額外網路複雜性的額外實例是一種恥辱）。
- 既然我們使用了 Docker，那麼Weave是否相關？
- 我們可以將靜態 IP 附加到 VPC 網關嗎？我看到使用 AWS Storage Gateway （來源）是可能的——但不確定正常的 vpc igw 嗎？
**我們的架構：**我們使用 AWS 並讓我們的實例在 ELB 後面執行的 VPC 中。我們經常在事先不知道 IP 地址的情況下啟動新實例。我們在所有機器上執行相同的軟體。這些機器執行 CoreOS，我們的應用程序在 Docker 容器中執行。
一個相當常見的基礎設施是一個實際應用程序伺服器都沒有公共 IPv4 IP 地址的基礎設施，它們將位於負載平衡器後面的 RFC 1918 專用網路範圍內，並且它們發出的任何傳出請求都是：
- 通過 NAT 網關路由，呈現單一源 IP 地址的外觀
- 必須通過代理伺服器進行，該代理伺服器在私有 IP 範圍和更大的網際網路之間架起橋樑
我想我會發布更新，因為該項目現在使用 NAT 實例成功完成。
我應該研究使用“一個 NAT 實例”嗎？它看起來很複雜 - 沒有更簡單的解決方案嗎？
現在 NAT 實例已全部設置完畢，最初的複雜感覺已經過去，實際上感覺非常簡單 - 甚至比以前更乾淨（因為被迫使用私有子網是一種安全性提升）。
AWS 的官方 NAT 實例設置說明執行良好：http ://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html 。我們使用 Amazon 提供的 AMI 來啟動 NAT 實例。經歷了這個過程，它讓我意識到它是多麼的“行業標準”，甚至可能是“最佳實踐”。
缺點：
- NAT 實例成為單點故障。由於來自我們網路伺服器的所有外部流量都通過它進行路由，如果它失敗，實例將無法訪問網際網路以接收軟體更新，呼叫外部 API（例如支付網關），我們將無法通過 SSH 訪問實例。
- 執行額外的機器需要花錢，而且需要更多的維護。（
t2.small不是很貴，而且庫存的 AMI 不需要修改，所以不是一個巨大的維護負擔）。- 實例將具有較慢的外部網路連接。（到目前為止，我還沒有註意到差異）。
- 我們不能直接通過 SSH 進入實例，我們需要通過 NAT 實例（使用 SSH 代理）。這聽起來比現在更糟。如果你花幾分鐘編輯
.ssh/config和閱讀“ProxyCommand”，你可以讓事情 100% 透明，這樣使用就ssh server1可以了。- 我們不能再通過使用它的公共 IP（或擁有特定機器的 DNS 記錄）來測試集群中的特定伺服器。這是你很快克服的事情。如果您確實需要確保使用一台機器，一種解決方法是創建一個新的 ELB，並且只將您想要定位的機器放入實例池中。