1. 導言
絕大多數業務場景都是需要知道客戶端IP的
在k8s中運行的業務專案，如何獲取到客戶端真實IP？
本文總結了通行的2種方式
要答案的直接看方式一、方式二和總結
SEO 關鍵字
nginx ingress客戶端真實ip
kubernets獲取客戶端真實ip
rke獲取客戶端真實ip
rancher獲取客戶端真實ip
本文由 www.iamle.com 流水理魚 原創，wx公眾號同名
1.1 流量鏈路介紹
7層轉發鏈路 Client(客戶端) > Nginx > K8s Ingress(Nginx ingress)
4層轉發鏈路 Client(客戶端) > 公有云LB > K8s Ingress(Nginx ingress)
ps: 實際業務會串聯更多層級的轉發，WAF、CDN、Api Gateway一般是http 7層轉發，LB一般是4層tcp轉發
1.2 準備whoami探針
whomai是一個go撰寫的除錯探針工具，回顯http頭資訊
在k8s中部署一個containous/whoami用來作為探針，配置好ingress公網和訪問，這樣客戶端web訪問可以看到基本的http頭資訊，方便除錯
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: whoami
namespace: default
labels:
app: whoami
spec:
replicas: 1
selector:
matchLabels:
app: whoami
template:
metadata:
labels:
app: whoami
spec:
containers:
- image: containous/whoami
imagePullPolicy: Always
name: whoami
ports:
- containerPort: 80
name: 80tcp02
protocol: TCP
dnsPolicy: ClusterFirst
restartPolicy: Always
EOF
ps：ingress自行增加
客戶端web訪問，回顯http頭示例
Hostname: whoami-65b8cc4b-6vwns
IP: 127.0.0.1
IP: 10.42.2.12
RemoteAddr: 10.42.1.0:47850
GET / HTTP/1.1
Host: whoami.iamle.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en-US;q=0.8,en;q=0.7,zh-TW;q=0.6,la;q=0.5
Cookie: _ga=GA1.2.30707523.1570429261;
Dnt: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
X-Forwarded-For: 8.8.8.8, 10.0.0.1
X-Forwarded-Host: whoami.iamle.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-Forwarded-For: 8.8.8.8
X-Original-Uri: /
X-Real-Ip: 8.8.8.8
X-Request-Id: 3852c9780589ffba4c1f9f2785691d5f
X-Scheme: https
2. 兩種方式 7層http頭X-Forwarded-For透傳 和 4層Proxy Protocol透傳
獲得客戶端真實IP有針對7層和針對4層兩種方式
2.1 7層http頭X-Forwarded-For透傳介紹
http作業在網路第7層,http中有個X-Forwarded-For欄位
大部分CDN、WAF、LB用X-Forwarded-For欄位來存客戶端IP，也有用X-Real-Ip欄位，cloudflare、百度云加速還擴展了CF-Connecting-IP欄位
標準資料為
X-Forwareded-For：Client，proxy1，proxy2，proxy3……
第一個ip是客戶端ip，后面的proxy為路過一層就加一層的ip
這里的proxy可以是WAF、CDN、LB、Api Gateway等
2.2 4層Proxy Protocol透傳
tcp作業在網路第4層,Proxy Protocol就是在tcp中增加一個小的報頭，用來存盤額外的資訊
代理協議即 Proxy Protocol,是haproxy的作者Willy Tarreau于2010年開發和設計的一個Internet協議，通過為tcp添加一個很小的頭資訊，來方便的傳遞客戶端資訊（協議堆疊、源IP、目的IP、源埠、目的埠等)，在網路情況復雜又需要獲取客戶IP時非常有用，
其本質是在三次握手結束后由代理在連接中插入了一個攜帶了原始連接四元組資訊的資料包，
目前 proxy protocol有兩個版本，v1僅支持human-readable報頭格式（ASCIII碼），v2需同時支持human-readable和二進制格式，即需要兼容v1格式
proxy protocol的接收端必須在接收到完整有效的 proxy protocol 頭部后才能開始處理連接資料，因此對于服務器的同一個監聽埠，不存在兼容帶proxy protocol包的連接和不帶proxy protocol包的連接，如果服務器接收到的第一個資料包不符合proxy protocol的格式，那么服務器會直接終止連接，
Proxy protocol是比較新的協議，但目前已經有很多軟體支持，如haproxy、nginx、apache、squid、mysql等等，要使用proxy protocol需要兩個角色sender和receiver,sender在與receiver之間建立連接后，會先發送一個帶有客戶資訊的tcp header,因為更改了tcp協議頭，需receiver也支持proxy protocol，否則不能識別tcp包頭，導致無法成功建立連接，
nginx是從1.5.12起開始支持的
3. 方式一 X-Forwarded-For配置
適用于7層http轉發
3.1 NGINX Ingress Controller X-Forwarded-For配置
查看NGINX Ingress Controller的ConfigMaps配置檔案，可以找到以下配置項
use-forwarded-headers
如果為true，NGINX會將傳入的 X-Forwarded-* 頭傳遞給upstreams，當NGINX位于另一個正在設定這些標頭的 L7 proxy / load balancer 之后時，請使用此選項，
如果為false，NGINX會忽略傳入的 X-Forwarded-* 頭，用它看到的請求資訊填充它們，如果NGINX直接暴露在互聯網上，或者它在基于 L3/packet-based load balancer 后面，并且不改變資料包中的源IP，請使用此選項，
ps： NGINX Ingress Controller直接暴露互聯網也就是Edge模式不能開啟為true，否則會有偽造ip的安全問題，也就是k8s有公網ip，直接讓客戶端訪問，本配置不要設為true！
forwarded-for-header
設定標頭欄位以標識客戶端的原始IP地址， 默認: X-Forwarded-For
ps：如果 NGINX Ingress Controller 在CDN，WAF，LB等后面，設定從頭的哪個欄位獲取IP，默認是X-Forwarded-For
這個配置應該和use-forwarded-headers配合使用
compute-full-forwarded-for
將遠程地址附加到 X-Forwarded-For 標頭，而不是替換它， 啟用此選項后，upstreams應用程式將根據其自己的受信任代理串列提取客戶端IP
修改configmap nginx-configuration配置
kubectl -n ingress-nginx edit cm nginx-configuration
在apiVersion: v1下，kind: ConfigMap上加入
data:
compute-full-forwarded-for: "true"
forwarded-for-header: "X-Forwarded-For"
use-forwarded-headers: "true"
或者直接apply附加配置
kubectl apply -f - <<EOF
apiVersion: v1
data:
compute-full-forwarded-for: "true"
forwarded-for-header: X-Forwarded-For
use-forwarded-headers: "true"
kind: ConfigMap
metadata:
labels:
app: ingress-nginx
name: nginx-configuration
namespace: ingress-nginx
EOF
ps：如果nginx-configuration不在namespace ingress-nginx中就在namespace kube-system中找
3.2 Nginx作為邊緣節點(Edge)配置
作為Edge需要重寫remote_addr，保證了客戶端IP不會被偽造
必須：X-Forwarded-For 重寫為 $remote_addr
非必須擴展：X-Real-IP 重寫為 $remote_addr
upstream wwek-k8s {
server 8.8.8.8:443;
server 8.8.8.7:443;
server 8.8.8.6:443;
}
map $http_upgrade $connection_upgrade {
default Upgrade;
'' close;
}
server {
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
location / {
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass https://wwek-k8s;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 900s;
proxy_buffering off;
}
}
3.3 X-Forwarded-For是否可以偽造
客戶端是否能偽造IP，取決于邊緣節點（Edge）是如何處理X-Forwarded-For欄位的，
客戶端直接連接的首個proxy節點都叫做邊緣節點（Edge），不管是網關、CDN、LB等只要這一層是直接接入客戶端訪問的，那么他就是一個邊緣節點，
不重寫-不安全的邊緣節點（Edge）
邊緣節點如果是透傳http頭中的X-Forwarded-For欄位，那么這個就是不安全的，客戶端可以在http中實作包含X-Forwarded-For欄位值，這個值又被透傳了，
#不安全
X-Forwareded-For：Client(Edge不重寫，只透傳)，proxy1，proxy2，proxy3……
重寫-安全的邊緣節點（Edge）
邊緣節點（Edge）如果重寫remote_addr到X-Forwarded-For，那么這就是安全的，邊緣節點（Edge）獲取的remote_addr就是客戶端的真實IP
#安全
X-Forwareded-For：Client(Edge獲取的remote_addr)，proxy1，proxy2，proxy3……
4. 方式二 Proxy Protocol 配置實體
適用于4層tcp轉發
公有云的負載均衡LB一般都支持Proxy Protocol
查看NGINX Ingress Controller的ConfigMaps配置檔案，可以找到如何配置Proxy Protocol
use-proxy-protocol
啟用或禁用roxy Protocol，以接收通過代理服務器和負載均衡器（例如HAProxy和Amazon Elastic Load Balancer（ELB））傳遞的客戶端連接（真實IP地址）資訊，
NGINX Ingress Controller 作為receiver角色 Proxy Protocol配置
kubectl -n ingress-nginx edit cm nginx-configuration
在apiVersion: v1下，kind: ConfigMap上加入
data:
use-proxy-protocol: "true"
或者直接apply附加配置
kubectl apply -f - <<EOF
apiVersion: v1
data:
use-proxy-protocol: "true"
kind: ConfigMap
metadata:
labels:
app: ingress-nginx
name: nginx-configuration
namespace: ingress-nginx
EOF
ps： 注意需要上一層LB支持Proxy Protocol，才能這么配置，否則會導致無法鏈接
5. 總結
7層http頭X-Forwarded-For透傳
鏈路proxy有透傳X-Forwarded-For
訪問鏈路上多層proxy，任意一個節點不支持Proxy Protocol
4層協議Proxy Protocol透傳
上下游可控都支持Proxy Protocol協議
鏈路proxy中丟失了http頭
https反向代理http(某些情況下由于Keep-alive導致不是每次請求都傳遞x-forword-for
應該用那種方式？
7層用X-Forwarded-For，4層用Proxy Protocol
如果鏈路的邊緣節點(Edge)X-Forwarded-For欄位是安全的，建議用X-Forwarded-For
如果鏈路proxy全路徑都支持Proxy Protocol，那么建議用Proxy Protocol
如果有4層tcp業務應用，那么獲取客戶端IP就的用Proxy Protocol
總之搞清楚了這2種方式的原理按照場景選擇
5. 參考
- HTTP HeadersX-Forwarded-For https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-Forwarded-For
- [ Proxy Protocol Introduction https://www.haproxy.com/blog/haproxy/Proxy Protocol/ ](https://www.haproxy.com/blog/haproxy/Proxy Protocol/)
- NGINX Ingress Controller ConfigMaps https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-forwarded-headers
- Configuring NGINX to Accept the PROXY Protocol https://docs.nginx.com/nginx/admin-guide/load-balancer/using-proxy-protocol/#configuring-nginx-to-accept-the-proxy-protocol
- nginx Module ngx_http_realip_module https://nginx.org/en/docs/http/ngx_http_realip_module.html
- rancher K8s Ingress Controllers https://rancher.com/docs/rke/latest/en/config-options/add-ons/ingress-controllers/
- rancher Set Up Load Balancer and Ingress Controller within Rancher https://rancher.com/docs/rancher/v2.x/en/k8s-in-rancher/load-balancers-and-ingress/
- aliyun負載均衡 如何獲取客戶端真實IP https://help.aliyun.com/document_detail/54007.html
- aliyun全站加速 獲取客戶端真實IP https://help.aliyun.com/document_detail/119658.html
- 騰訊云高防IP 獲取客戶端真實IP https://cloud.tencent.com/document/product/1014/31124
- How does Cloudflare handle HTTP Request headers?
本文首發于流水理魚博客，如要轉載請注明出處，
歡迎關注我的公眾號：流水理魚（liushuiliyu），全堆疊、云原生、團隊管理交流，
如果您對相關文章感興趣，也可以關注我的博客：www.iamle.com 上面有更多內容
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/27843.html
標籤：其他
上一篇：Python高級工程師進階之路