%20%E3%81%AE%E5%A5%87%E5%A6%99%E3%81%AA%E7%82%B9.png)
AKS ポッド/コンテナーをオンプレミス ネットワークに接続する際に問題が発生しています。
172.16.20.0/22
および名前空間に仮想ネットワークがあります172.16.24.0/29
。これらには 2 つのサブネットがあり、それぞれに上記の範囲のいずれかがサブネット範囲として設定されています。
AKS クラスターは172.16.20.0/22
サブネットにバインドされており、各ノードとポッドはその範囲内の IP アドレスを取得しています。また、一時的なデバッグのために、このサブネットに通常の VM を追加しました。
サブネットには172.16.24.0/29
、そのサブネットをオンプレミス ネットワークに接続する仮想ネットワーク ゲートウェイ (このサブネットには IP がありません) があります。VN ゲートウェイには、アドレス空間 を持つ一致するローカル ネットワーク ゲートウェイがあります。ローカル ネットワークには、ポート 25 でリッスンする172.17.151.0/24
SMTP サーバーが にあります。172.17.151.254
デバッグ用に起動した VM では、SMTP サーバーに問題なく接続できます。また、SMTP サーバーから VM に問題なく ping することもできます。ただし、ポッドからは SMTP に接続できず ( でテスト済みnetcat -zv 172.17.151.254 25
)、SMTP サーバーからポッドの IP アドレスに ping することもできません。
どちらのサブネットにもネットワーク セキュリティ グループ (NSG) が接続されていないため、NSG ルールの構成が間違っている可能性はありません。接続が失敗する原因は他に何があるでしょうか? ポッドは、サブネット内の DHCP サーバーから同じ基本的なネットワーク構成を取得します。
- 172.16.20.0/22 IPアドレス
- 172.16.20.1 をデフォルトゲートウェイとして設定
Azure VNG に接続しているオンプレミス デバイスを保守している IT スタッフがデバッグを手伝ってくれました。彼らによると、 への SMTP 接続を開始すると、172.17.151.254
パケットが到着し、サーバーからの応答パッケージが VPN トンネルに戻るのが見られるとのことなので、応答パケットは Azure のどこかでドロップされているようです。編集: IT スタッフとのさらなるデバッグ セッション中に、動作不良のポッドから送信されたパケットの送信元 IP がではなく で
あることに気付きました。はポッドが実行されている VMSS ノードの IP なので、これは理にかなっているかもしれませんが、そのノードの内部ルーティングが正しく構成されていないことを意味します。172.17.20.5
172.16.20.21
172.17.20.5
それとも、これが失敗する原因となっている Kubernetes 固有の何かでしょうか?
これまで試したこと:
- VM 上:
172.16.20.21
(ポッド) への ping: 正常に動作 - VM上: ping
172.17.151.254
: 正常に動作します - VM 上:
tracert 172.17.151.254
1 ホップで成功します (デフォルト ゲートウェイを通過するときに、少なくとも 2 ホップが表示される必要がありますか?) - ポッド上:
172.16.20.4
(vm) への ping: 正常に動作 - ポッド上: へのping
172.17.151.254
: 失敗 - ポッド上:
traceroute 172.17.151.254
ホップが表示されずに失敗する - オンプレミスの VPN デバイス:
172.16.20.4
(vm) への ping: 正常に動作 - オンプレミスの VPN デバイス:
172.16.20.21
(ポッド) への ping: 失敗
追加情報:
ifconfig -a
ポッドから:
eth0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 172.16.20.21 netmask 255.255.252.0 broadcast 0.0.0.0
ether de:c7:74:e3:c5:24 txqueuelen 1000 (Ethernet)
RX packets 386868 bytes 35746728 (34.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 511891 bytes 43865660 (41.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 5 bytes 504 (504.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5 bytes 504 (504.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
route
ポッドからの出力:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.20.1 0.0.0.0 UG 0 0 0 eth0
172.16.20.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
ipconfig /all
デバッグ VM から:
Windows IP Configuration
Host Name . . . . . . . . . . . . : debug-vm
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : nedz0ha4spbubmi5cnxgsnswdh.ax.internal.cloudapp.net
Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
Physical Address. . . . . . . . . : 00-0D-3A-2D-DC-BA
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::e9bb:fede:66cc:398c%6(Preferred)
IPv4 Address. . . . . . . . . . . : 172.16.20.4(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.252.0
Lease Obtained. . . . . . . . . . : Friday, August 28, 2020 7:15:08 AM
Lease Expires . . . . . . . . . . : Friday, October 8, 2156 1:20:49 PM
Default Gateway . . . . . . . . . : 172.16.20.1
DHCP Server . . . . . . . . . . . : 168.63.129.16
DHCPv6 IAID . . . . . . . . . . . : 100666682
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-DA-67-54-00-0D-3A-2D-DC-BA
DNS Servers . . . . . . . . . . . : 168.63.129.16
NetBIOS over Tcpip. . . . . . . . : Enabled
route print
デバッグVMから:
===========================================================================
Interface List
6...00 0d 3a 2d dc ba ......Microsoft Hyper-V Network Adapter
1...........................Software Loopback Interface 1
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.16.20.1 172.16.20.4 10
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
168.63.129.16 255.255.255.255 172.16.20.1 172.16.20.4 11
169.254.169.254 255.255.255.255 172.16.20.1 172.16.20.4 11
172.16.20.0 255.255.252.0 On-link 172.16.20.4 266
172.16.20.4 255.255.255.255 On-link 172.16.20.4 266
172.16.23.255 255.255.255.255 On-link 172.16.20.4 266
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 172.16.20.4 266
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 172.16.20.4 266
===========================================================================
Persistent Routes:
None
IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
1 331 ::1/128 On-link
6 266 fe80::/64 On-link
6 266 fe80::e9bb:fede:66cc:398c/128
On-link
1 331 ff00::/8 On-link
6 266 ff00::/8 On-link
===========================================================================
Persistent Routes:
None
答え1
この問題は、Microsoft サポートの協力を得て徹底的にトラブルシューティングを行った結果発見されました。
根本的な原因は、 の SMTP サーバー (VPN エンドポイント) の IP アドレスであり172.17.151.254
、これは K8S ノードで構成された のデフォルトの Docker ブリッジ ネットワークと重複しています172.17.0.0/16
。この側面は私が起動したデバッグ VM には存在しなかったため、そこでは問題は発生しませんでした。
教訓: 172.17.0.0/16
AKS を使用するときは範囲から遠ざかる