服務器獲取真實客戶端 IP

0x01 先查個問題

測試環境微信支付通道提示網絡環境未能經過安全驗證，請稍後再試，出現這種狀況通常首要 想到多是雙方網絡交互中微信方驗參與咱們出現不一致，翻了下手冊肯定是這類問題開始排查環節

1. 可能獲取真實IP方式錯誤

   1. getenv('HTTP_CLIENT_IP')
   2. getenv('HTTP_X_FORWARDED_FOR')
   3. getenv('REMOTE_ADDR')
   4. filter_var($remote_ip, FILTER_VALIDATE_IP)
   5. 已經依次獲取並過濾
   6. 固程序沒有任何問題，往上發散

2. 是否反向代理

   通過反向代理後，因爲在客戶端和web服務器之間增長了中間層，所以web服務器沒法直接拿到客戶端的ip，只能經過$remote_addr變量拿到的將是反向代理服務器的ip地址，檢查不存在此類問題，再往上，擅長網絡通訊工程的同窗表示毫不認輸

3. 可能NAT分配出口IP，或負載均衡服務分發出現異常

   1. 先拿到我本地內網外網IP 方便以後問題排查

   # 本機IP
   ifconfig | grep -A 1 "en" | grep broadcast | cut -d " " -f 2
   # 外網IP
   curl --silent http://icanhazip.com
   複製代碼

   2. 檢查與80端口創建鏈接目標都有誰

   netstat -tn|grep 80|akw '{print $5}'|awk -F '{print $1}' | grep [本地IP]
   複製代碼

   這裏出現問題，居然沒有個人IP，再以nginx $remote_addr拿到的IP做爲參考，這是nginx最後一次握手的IP,$remote_addr = 10.168.0.0/16 段

   在nginx處打印$remote_addr，並在server_name添加當前機器ip，分別以負載均衡IP與本地IP作測試，最終肯定問題出如今負載均衡服務器出現異常

---

0x02 LNMP棧拿真實IP

LNMP棧內PHP全部得到到的TCP操做信息都是由前面Nginx經過fastcgi傳遞給它的，就好比$_SERVER['REMOTE_ADDR']由include fastcgi.conf;引進，其等於nginx的$remote_addr

Nginx中的幾個變量：

• $remote_addr

  表明客戶端的IP，但它的值不是由客戶端提供的，而是服務端根據客戶端的ip指定的，icanhazip的原理也是這樣， 當你的瀏覽器訪問某個網站時，假設中間沒有任何代理，那麼網站的web服務器就會把remote_addr設爲你在公網暴露的IP，若是你用了某個代理，那麼你的瀏覽器會先訪問這個代理，而後再由這個代理轉發到網站，這樣web服務器就會把remote_addr設爲這臺代理機器的IP, 除非代理將你的IP附在請求header中一塊兒轉交給web服務器。

• $proxy_add_x_forwarded_for

  $proxy_add_x_forwarded_for變量包含客戶端請求頭中的"X-Forwarded-For"，與$remote_addr兩部分，他們之間用逗號分開。X-Forwarded-For（簡稱XFF），X-Forwarded-For 是一個 HTTP 擴展頭部。RFC 2616 協議並無對它的定義，它最開始是由 Squid 這個緩存代理軟件引入，用來表示 HTTP 請求端真實 IP。現在它已經成爲事實上的標準，被各大HTTP 代理、負載均衡等轉發服務普遍使用，並被寫入 RFC 7239（Forwarded HTTP Extension` 標準之中。

• $proxy_set_header

  已在排查問題中說明，可設置代理後 header

  proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  複製代碼

• X-Real-IP

  通常好比X-Real-IP這一個自定義頭部字段，一般被 HTTP 代理用來表示與它產生TCP 鏈接的設備 IP，這個設備多是其餘代理，也多是真正的請求端，這個要看通過代理的層級次數或是是否始終將真實IP一路傳下來。（牢記：任何客戶端傳上來的東西都是不可信的）

當多層代理或使用CDN時，若是代理服務器不把用戶的真實IP傳遞下去，那麼服務器將永遠不可能獲取到用戶的真實IP。

0x03 用戶的真實IP從何而來

1. 寬帶供應商提供獨立IP 好比家裏電信寬帶上網，電信給分配了公網ip，那麼一個請求通過的ip路徑以下：

   

   
   這種狀況下，119.147.19.234 會把獲得的116.1.2.3附加到頭信息中傳給10.168.0.0/32,所以這種狀況下，咱們取得的用戶ip則爲:116.1.2.3。 若是119.110.0.0/16沒有把116.1.2.3附加到頭信息中傳給業務服務器，業務服務器就只能取上上一級ip地址

2. 寬帶供應商不能提供獨立IP

   寬帶提供商沒有足夠的公網ip，分配的是個內網ip，好比長寬等小的isp。請求路徑則可能以下：

   

   這種狀況下獲得的用戶ip，就是211.162.78.1。 這種狀況下，就可能出現一個ip對應有數十上百個用戶的狀況了

3. 手機2g上網

網絡提供商無法直接提供ip給單個用戶終端，以中國移動cmwap上網爲例，所以請求路徑可能爲：

這種狀況下獲得的用戶ip，就是 202.96.75.1。2008年的時候整個廣東聯通就三個手機上網的公網ip，所以這種狀況下，同一ip出現數十萬用戶也是正常的。

4. 有幾萬或數十萬員工的公司

   這種也會出現來自同一ip的超多用戶，可能達到幾萬人，但出口IP可能就那麼幾個。

---

0x04 NAT [Network Address Translation]

中文意思是網絡地址轉換，它容許一個總體機構以一個公用IP地址出如今Internet上。

NAT在 OSI參考模型的網絡層 (第3層), 它是一種把內部私有網絡地址（IP地址）翻譯成合法網絡IP地址的技術。NAT可讓那些使用私有地址的內部網絡鏈接到Internet或其它IP網絡上。NAT路由器在將內部網絡的數據包發送到公用網絡時，在IP包的報頭把私有地址轉換成合法的IP地址。

RFC1918 規定了三塊專有的地址，做爲私有的內部組網使用

• A類：10.0.0.0 — 10.255.255.255 10.0.0.0/8
• B類：172.16.0.0 — 172.31.255.255 172.16.0.0/12
• C類：192.168.0.0 — 192.168.255.255 192.168.0.0/16

這三塊私有地址自己是可路由的，只是公網上的路由器不會轉發這三塊私有地址的流量；當一個公司內部配置了這些私有地址後，內部的計算機在和外網通訊時，公司的邊界路由會經過NAT或者PAT技術，將內部的私有地址轉換成外網IP，外部看到的源地址是公司邊界路由轉換過的公網IP地址，這在某種意義上也增長了內部網絡的安全性

這個過程是經過NAT中的本地址與全局地址映射條目來實現的，因此事先要在NAT路由器上配置這樣的映射條目。

經過這種方式一個 公網 IP 底下能夠發私有的 IP 地址。

---

0x05 IPV6 來了？

寫這篇文章的時候看到有個推送，表示阿里全面應用IPV6,這件事的意義還挺重大的

咱們知道，一段 IPv4 標準的 IP 地址，一共由 4 X 8 = 32 位二進制數字組成，理論上存在 2^32 個 IP 地址。等於 4,294,967,296 ， 42 億多個 IPv4 的地址。

參考世界互聯網用戶統計報告，全球如今大概有4,208,571,287人在上網，也就是說已經快到ipv4地址設計的最大IP數了

不過不用擔憂，前面提到的 NAT，讓 IPv4 公網 IP 哪怕用完了也能湊合過。

到了 IPv6 ，相比 IPv4 最大的提高，就是位數大大增長，變成了 8 個 4 位的十六進制數字。也就是說有 2^128個 IPv6 地址。地球上的每粒沙子都分一個也管夠

存儲2^128字節理論上什麼概念呢，在當今的量子水平下，假設計算設備可以操做在原子一級，每公斤質量可存儲大約10的25次方bits，存儲2的128次方的字節大約須要272 trillion = 2720000億公斤。

最後，週末愉快，北京聯通已經支持ipv6了,我在望京測試，能夠拿到 ipv6地址