Zenn
Microsoft (有志)Publicationへの投稿
🐡

kube-proxy の NAT を追いかける (結局わからん)

skmkzyk
2022/04/29に公開
Kubernetes
AKS
tech

前回 で今回の環境は Cluster IP の Service は kube-proxy が iptables を利用して実装されてることまではなんとなくわかった。
んで、じゃあ packet 見てみよう、と思ったのが今回。
DNAT はわかったんだけど戻りのパケットがどうなるんだというところ。
結果は分からずじまいだったんですが。

たぶん わかった

利用したのはまず Azure Kubernetes Service (AKS) クラスター ノードへの接続 - Azure Kubernetes Service。
node にログインするようなときにこれが使えるらしい。
なんか root のはずなんだけど root じゃないらしくて困るときもある。

$ kubectl debug node/aks-nodepool1-19344272-vmss000000 -it --image=mcr.microsoft.com/dotnet/runtime-deps:6.0

んで、apt-get update して apt-get install tcpdump したら始めましょう。
手癖で tcpdump -nni までは入れて、bridge interface がいっぱいあってめんどいので any で。
今回は DNS の packet を取りたいので port 53 でいきます。

# tcpdump -nni any port 53
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

そのうえで、kubectl exec -it dnsutils -- bash からの nslookup www.microsoft.com を別のタブで実行してみます。
nslookup の結果はどうでもいいので今回は省きます。

定番なんですが、.default.svc.cluster.local. などの suffix が勝手について名前解決を試すので NXDOMAIN が返ってきます。
それを何回か繰り返して。

13:26:12.660361 azvb3c61c3cba9 In  IP 172.16.10.26.56340 > 10.0.0.10.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.660391 eth0  Out IP 172.16.10.26.56340 > 172.16.10.42.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.660392 enP41928s1 Out IP 172.16.10.26.56340 > 172.16.10.42.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.662061 eth0  In  IP 172.16.10.42.53 > 172.16.10.26.56340: 60959 NXDomain*- 0/1/0 (154)
13:26:12.662088 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.56340: 60959 NXDomain*- 0/1/0 (154)

13:26:12.662226 azvb3c61c3cba9 In  IP 172.16.10.26.44371 > 10.0.0.10.53: 420+ A? www.microsoft.com.svc.cluster.local. (53)
13:26:12.662239 azv6ebe157cbbf Out IP 172.16.10.26.44371 > 172.16.10.9.53: 420+ A? www.microsoft.com.svc.cluster.local. (53)
13:26:12.662521 azv6ebe157cbbf In  IP 172.16.10.9.53 > 172.16.10.26.44371: 420 NXDomain*- 0/1/0 (146)
13:26:12.662537 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.44371: 420 NXDomain*- 0/1/0 (146)

13:26:12.662673 azvb3c61c3cba9 In  IP 172.16.10.26.50203 > 10.0.0.10.53: 61120+ A? www.microsoft.com.cluster.local. (49)
13:26:12.662687 eth0  Out IP 172.16.10.26.50203 > 172.16.10.42.53: 61120+ A? www.microsoft.com.cluster.local. (49)
13:26:12.662688 enP41928s1 Out IP 172.16.10.26.50203 > 172.16.10.42.53: 61120+ A? www.microsoft.com.cluster.local. (49)
13:26:12.663702 eth0  In  IP 172.16.10.42.53 > 172.16.10.26.50203: 61120 NXDomain*- 0/1/0 (142)
13:26:12.663707 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.50203: 61120 NXDomain*- 0/1/0 (142)

13:26:12.663823 azvb3c61c3cba9 In  IP 172.16.10.26.40521 > 10.0.0.10.53: 41270+ A? www.microsoft.com.bghzd2pmox0etaxh3ooqtev5hc.ix.internal.cloudapp.net. (87)
13:26:12.663840 eth0  Out IP 172.16.10.26.40521 > 172.16.10.42.53: 41270+ A? www.microsoft.com.bghzd2pmox0etaxh3ooqtev5hc.ix.internal.cloudapp.net. (87)
13:26:12.663841 enP41928s1 Out IP 172.16.10.26.40521 > 172.16.10.42.53: 41270+ A? www.microsoft.com.bghzd2pmox0etaxh3ooqtev5hc.ix.internal.cloudapp.net. (87)
13:26:12.668362 eth0  In  IP 172.16.10.42.53 > 172.16.10.26.40521: 41270 NXDomain 0/1/0 (197)
13:26:12.668385 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.40521: 41270 NXDomain 0/1/0 (197)

ここで初めてちゃんと名前解決が完了しています。

13:26:12.668603 azvb3c61c3cba9 In  IP 172.16.10.26.43951 > 10.0.0.10.53: 9034+ A? www.microsoft.com. (35)
13:26:12.668620 eth0  Out IP 172.16.10.26.43951 > 172.16.10.42.53: 9034+ A? www.microsoft.com. (35)
13:26:12.668621 enP41928s1 Out IP 172.16.10.26.43951 > 172.16.10.42.53: 9034+ A? www.microsoft.com. (35)
13:26:12.671646 eth0  In  IP 172.16.10.42.53 > 172.16.10.26.43951: 9034 4/0/0 CNAME www.microsoft.com-c-3.edgekey.net., CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net., CNAME e13678.dscb.akamaiedge.net., A 23.195.153.175 (340)
13:26:12.671672 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.43951: 9034 4/0/0 CNAME www.microsoft.com-c-3.edgekey.net., CNAME www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net., CNAME e13678.dscb.akamaiedge.net., A 23.195.153.175 (340)

で、よく見ると、4 行の時と 5 行の時があると。

4 行の時はこれ。(再掲)

13:26:12.662226 azvb3c61c3cba9 In  IP 172.16.10.26.44371 > 10.0.0.10.53: 420+ A? www.microsoft.com.svc.cluster.local. (53)
13:26:12.662239 azv6ebe157cbbf Out IP 172.16.10.26.44371 > 172.16.10.9.53: 420+ A? www.microsoft.com.svc.cluster.local. (53)
13:26:12.662521 azv6ebe157cbbf In  IP 172.16.10.9.53 > 172.16.10.26.44371: 420 NXDomain*- 0/1/0 (146)
13:26:12.662537 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.44371: 420 NXDomain*- 0/1/0 (146)

5 行の時はこれ。(再掲)

13:26:12.660361 azvb3c61c3cba9 In  IP 172.16.10.26.56340 > 10.0.0.10.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.660391 eth0  Out IP 172.16.10.26.56340 > 172.16.10.42.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.660392 enP41928s1 Out IP 172.16.10.26.56340 > 172.16.10.42.53: 60959+ A? www.microsoft.com.default.svc.cluster.local. (61)
13:26:12.662061 eth0  In  IP 172.16.10.42.53 > 172.16.10.26.56340: 60959 NXDomain*- 0/1/0 (154)
13:26:12.662088 azvb3c61c3cba9 Out IP 10.0.0.10.53 > 172.16.10.26.56340: 60959 NXDomain*- 0/1/0 (154)

iptables の振り分けの後、node の中の coredns に振り分けられたか否かで分かれるようです。
この環境は coredns が 2 つあるので、結果としても半分ずつくらいに見えます。
今回の tcpdump は aks-nodepool1-19344272-vmss000000 で実行しているので、172.16.10.9 宛は自 node の中、172.16.10.42 宛は隣の node です。

$ kubectl get po -n kube-system -l k8s-app=kube-dns -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP             NODE                                NOMINATED NODE   READINESS GATES
coredns-69c47794-6xnlq   1/1     Running   0          22h     172.16.10.9    aks-nodepool1-19344272-vmss000000   <none>           <none>
coredns-69c47794-cgn9k   1/1     Running   0          7d12h   172.16.10.42   aks-nodepool1-19344272-vmss000001   <none>           <none>

こっから NAT の様子をちゃんと見ていきたいのですが、

  • 172.16.10.26.56340 > 10.0.0.10.53
  • 172.16.10.26.56340 > 172.16.10.42.53

となって外に出ていこうとしています。
iptables によって 10.0.0.10 (Service の Cluster IP) から 172.16.10.42 (coredns pod の IP) に DNAT されています。

んで、戻りについても、

  • 172.16.10.42.53 > 172.16.10.26.56340
  • 10.0.0.10.53 > 172.16.10.26.56340

となっていて先ほどとは逆に SNAT かかっているんですがだれがこれをやってるのかがわからん。

ちなみに enP41928s1 は eth0 の slave らしいんだけどこれもなんでなのかわからん。
本当といろんなことが起こってて奥が深い。。

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:3a:c8:f9:cb brd ff:ff:ff:ff:ff:ff
3: enP41928s1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master eth0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:3a:c8:f9:cb brd ff:ff:ff:ff:ff:ff

ちなみにちなみに、# nslookup www.microsoft.com. と最後に . 込みで nslookup を実行すると .default.svc.cluster.local. などの suffix を試さないので一発で名前解決できます。
コマンドの出力は何も変わらないのでわからないと思いますが。。

おしまい。。

Microsoft (有志)
Microsoft (有志)Publication

Microsoft Azureをはじめとする最新技術情報をお届けします。 ※このPublicationは日本マイクロソフトまたは米Microsoft所属社員による個人の見解であり、所属する組織の公式見解ではありません。 ※Publicationに参加希望の社員は @07JP27までご連絡ください。

Discussion