（小ネタ）NLBへ疎通確認する時はレイヤ4（トランスポート層）のコマンドを使用してほしい

NLBはレイヤー4（トランスポート層）のロードバランサーです。レイヤー3(ネットワーク層)で動作するpingには応答しない(無視する)という動作をします。

#AWS

#Network Load Balancer（NLB）

おつまみ

2024.01.24

NLBへpingで疎通確認できない?

こんにちは！AWS事業本部のおつまみです。

みなさん、NLBへ疎通確認したいと思ったことはありますか？私はあります。
先日構築したNLBに対して「pingが通らない」と問い合わせがきました。

「そもそもNLBに対して、pingって通るのか？」と疑問に思ったので、今回は調査した結果を共有します！

いきなり結論

NLBはレイヤ4（トランスポート層）のロードバランサーである。
pingコマンドはレイヤ3（ネットワーク層）プロトコルであるICMPを使用しているため、通常は疎通確認に利用できない。
NLBへ疎通確認をするときは、telnetやnc（netcat）コマンドを使用しよう。

NLBをおさらい

まずNLBがどこの層で動作するロードバランサーか理解する必要があります。

NLBはOSI参照モデルの中でいうレイヤ4（トランスポート層）で動作しています。
そのため、NLBは、IPアドレスに基づくトラフィックのルーティングにTCPやUDPを利用します。

一方、pingコマンドはICMPを使用しているため、レイヤ3（ネットワーク層）のプロトコルです。

そのため、TCPやUDPに基づいてトラフィックを処理するNLBに対して、pingコマンドを用いた疎通確認は適していません。
他にも疎通コマンドとしてtracepathコマンドなどが挙げられますが、こちらもICMPやUDPを使ってパスの発見を行うため、NLBの疎通確認に適していません。

よって、NLBで疎通確認をするためには、レイヤ4（トランスポート層）であるTCPやUDPを使うコマンドで疎通確認するようにしましょう。
たとえば、TCPを使う場合は、telnetやnc（netcat）コマンドを使用することで確認が可能となります。

では、さっそく検証して確認してみます！

確認してみた

構成図

今回検証する構成です。

NLBにはセキュリティグループをアタッチしており、右側にある instance のSecurityGroupからのポート25番のみ許可しています。
右側にある instance にSession Managerでログインし、NLBのDNS名に対して各コマンドを実行していきたいと思います。

レイヤ3（ネットワーク層）の場合

pingコマンド

[root@ip-xx-xx-xx-xx ~]# ping [NLBのDNS名]
PING [NLBのDNS名] (xx.xx.xx.xx) 56(84) bytes of data.

このまま応答がなく、返ってきませんでした。

tracepathコマンド

[root@ip-xx-xx-xx-xx ~]# tracepath [NLBのDNS名] -p 25
 1?: [LOCALHOST]                      pmtu 9001
 1:  no reply
 2:  no reply

「no reply」のメッセージが返ってきているため、その先のネットワークノードがICMP応答を返していないことを意味しています。

レイヤ3（ネットワーク層）の場合は、応答がないことを確認できました。

レイヤ4（ネットワーク層）の場合

telnetコマンド

[root@ip-xx-xx-xx-xx ~]# telnet [NLBのDNS名] 25
Trying yy.yy.yy.yy...
Connected to [NLBのDNS名].
Escape character is '^]'.
220 ip-zz-zz-zz-zz.ap-northeast-1.compute.internal ESMTP Postfix

「Connected to」のメッセージが返ってきているため、接続成功したことを意味しています。
なおyy.yy.yy.yyはNLBを名前解決した結果のIPアドレス、zz-zz-zz-zzはNLBのターゲットにしているインスタンスのIPアドレスとなります。
今回はPostfixをインストールしたSMTPサーバであったため、SMTPサーバ応答をしていることがわかります。

ncコマンド

[root@ip-xx-xx-xx-xx ~]# nc -vz [NLBのDNS名] 25
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to yy.yy.yy.yy:25.
Ncat: 0 bytes sent, 0 bytes received in 0.06 seconds.

こちらも「Connected to」のメッセージが返ってきているため、接続成功したことを意味しています。
NLBを名前解決した結果のIPアドレスyy.yy.yy.yy に対してポート25で接続できたことを意味しています。

レイヤ4（ネットワーク層）を利用するコマンドの場合は、応答することを確認できました。
検証は以上となります！

（追記）NLBのセキュリティグループでICMPを開けても、pingコマンドは通らない。

ブログ投稿後に社内からありがたいフィードバックをもらいました。

NLBの主たる機能は「L4のロードバランシング」ではありますが、NLB自体がIPアドレスを持つ機器である以上 L3 (IP/ICMP) の処理は行なっており、本来は ping (ICMP echo) に応答することは可能なはず。応答することは可能であるけれども、仕様として「ping の要求を受けても応答しない (無視する)」という動作をする、というのが実際のところなのではないかと思います。オンプレの物理ロードバランサーでは、pingに応答するものもありますし、設定によってpingに応答する/応答しないを切り替えることができるものもあります。

そこでNLBのセキュリティグループでICMPを開けたら、pingコマンドも通るのか確認してみました。

インバウンドルールで以下のルールを追加します。

タイプ	プロトコル	ポート範囲	送信元	備考
ICMP	ICMP	すべて	instanceのSecurityGroup	Ping疎通用

この状態で再度ping,tracepathコマンドを実行しましたが、結果は変わりませんでした。。

どうやらNLBの仕様として、設定済みのリスナーに一致しないネットワークトラフィックは意図しないトラフィックとしてターゲットに転送せずにドロップするようです。

設定済みのリスナーに送信されるすべてのネットワークトラフィックが、意図されたトラフィックとして分類されます。設定済みのリスナーに一致しないネットワークトラフィックが、意図しないトラフィックとして分類されます。Type 3 以外の ICMP リクエストも、意図しないトラフィックとみなされます。Network Load Balancer は、意図しないトラフィックをターゲットに転送せずにドロップします。

出典：Network Load Balancer のリスナー - Elastic Load Balancing

Pingで使われれるのはICMPのType 8　（ICMPエコー要求／エコー応答）であるため、セキュリティグループで許可したとしても通信できないみたいでした。

なおALBはセキュリティグループで穴あけすると、ping応答を返してくれます。