我想做同樣的事情。我有很長的CIDR格式的IP地址列表,並將其轉換爲正則表達式以便在.htaccess文件中使用,這似乎不是正確的做法。而且你知道,就處理器負載而言,.htaccess中的正則表達式甚至不在iptables可以完成的整數位操作的同一個星系中。但我不認爲有可能爲此使用iptables。 Iptables在內核中運行,並且在讀取任何頭文件之前,它會在低級別阻塞傳入的IP地址。
就我而言,我只使用負載平衡器作爲處理https請求的便捷方式,我並不需要在多個webserver實例之間平衡負載。所以我一直在考慮的是用nginx反向代理運行一個單獨的實例來處理我的apache web服務器的https,並像AWS負載平衡器一樣添加X_FORWARDED頭。這樣我就可以在運行nginx的實例上使用iptables,而且我不必碰觸我的apache配置或負載均衡器後面運行的webapps。
您失去了負載平衡器本身的多個IP地址的冗餘度,以及與AWS Cloud Front的集成以平衡後端負載,但您可以使用iptables並且可以卸載從apache處理靜態內容,也許改善您的響應時間。由於簡單的請求處理,nginx被認爲比apache輕得多,所以在這種情況下你不需要太多肌肉。我想知道AWS負載平衡器實際上只是運行nginx的實例。如果您查看定價,負載平衡器的小時成本與t2.small linux實例大致相同。
我還沒有嘗試過這個,因爲nginx配置對我來說是全新的,它需要購買和安裝SSL證書,而不是使用非常簡單和方便的證書管理器。
不知AWS會考慮用戶的功能要求,以便能夠使用iptables配置負載均衡器...
更新:我剛剛發佈this在AWS EC2論壇。
更新2:我向AWS要求的一項功能要求爲負載平衡器配置iptables得到了解答,並解釋瞭如何使用網絡ACL阻止源自列表中的任何CIDR的請求到達負載平衡器。對我而言,這是一個很好的解決方案。 OP正在尋找一種不特定於AWS的解決方案,但這不符合該標準。如果在逆向代理服務器後面有一些問題,那麼根本不可能使用該服務器的iptables樣式防火牆來阻止基於原始IP地址的傳入請求 - 防火牆需要決定是否阻止請求遠在它讀取標題之前,這是唯一可以找到原始請求地址的地方。如果您使用AWS,則可以使用網絡ACL。否則,您需要完全控制執行反向代理的服務器,並將防火牆規則放在該服務器上。
嗨布魯斯,謝謝你的回答。但正如我所提到的,實際上我已經在使用.htaccess來阻止(作爲迄今爲止的最後一招)。但我想要的是(不要使用.htaccess和)正確使用防火牆(iptables),而是。 –