2015-06-02 66 views
0

通過試驗Azure負載平衡集,似乎x-forwarded-for報頭未被使用(正如在常規負載均衡器中預期的那樣),而是它們保留原始客戶端IP。Azure負載均衡集保留了客戶端IP

例如爲:

app.get('/my-ip', function(req, res) { 
    winston.log('/my-ip', 'x-forwarded', req.headers['x-forwarded-for'] || 'none', 'remoteAddress', req.connection.remoteAddress || 'none'); 
    res.end(); 
}); 

有了結果:

/my-ip x-forwarded none remoteAddress MY_CORRECT_IP 

可這種行爲進行確認和依靠?

回答

3

你正在混淆代理與負載平衡。代理使用x轉發,負載均衡器不(默認情況下)。負載均衡器在OSI堆棧中的較低級別工作(儘管您可能會發現各種稱爲負載均衡器的事情實際上並非如此)。

這裏的關鍵區別在於,代理實際上會在您將HTTP請求轉發給其過程標頭之前,將其解析爲HTTP請求。負載均衡器不必(儘管可以)。他們只是重新路由數據包。一些更高級的負載均衡器支持添加此標頭,但它絕不是默認配置。代理默認情況下通常會打開此標題,並支持刪除它。

負載均衡器通常不需要此頭的原因是負載均衡器基本上是一個路由器,因此它默認維護數據包的原始源IP信息。另一方面,代理充當原始請求的目的地,然後它向新目的地發出新請求,因此原始分組信息通常會丟失。就像,如果你在郵件轉發機構工作,並且你打開了人們的郵件,閱讀它,然後把它放在一個新的信封和你的回信地址。

+0

+1這不是代理。這裏有一些額外的有用信息:https://azure.microsoft.com/en-us/documentation/articles/load-balancer-overview/ –

+0

感謝您的澄清,我習慣了Amazon ELB,它使用x轉發 – SyBer

+0

@SyBer - 當您將負載平衡配置爲在不同類型的協議之間進行轉換時,Amazon ELB僅使用X-Forwarded-for。例如,HTTPS轉換爲HTTP。請參閱:http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html「當您將TCP(第4層)用於前端和後端連接時,您的負載平衡器將請求轉發到後端實例而不修改標頭。「然後「使用此配置,您將不會收到會話粘性或X-Forwarded標頭的cookie」,或者您明確啓用它。 –