診断コマンドが「嘘をつく」とき：カーネルパラメータが隠蔽するネットワークの真実
ネットワークエンジニアの端くれなら、一度は経験があるはずだ。本番環境で急激なレイテンシが発生し、必死に ping や traceroute を叩く。しかし、パケットは淀みなく流れ、RTT も極めて正常。目の前のデータは「正常」を示しているのに、アプリケーション層ではタイムアウトが多発している。
この乖離こそが、OSのカーネルパラメータとネットワークスタックの深淵が仕掛ける罠だ。今日は、教科書的なマニュアルには決して書かれていない、NOCの現場で培った「カーネルの制約と診断」の話をしよう。
1. ファイルディスクリプタと一時ポートの「飽和点」
大規模なマイクロサービス構成では、監視エージェントやサイドカープロキシが膨大な socket を消費する。ここで見落としがちなのが、ulimit によるファイルディスクリプタ（FD）制限と、net.ipv4.ip_local_port_range による一時ポートの枯渇だ。
診断ツールが connect() に失敗する場合、多くは「ネットワークがダウンしている」のではなく、ephemeral port が使い果たされ、TIME_WAIT 状態のソケットがポート空間を占拠しているケースがほとんどだ。
推奨するカーネルチューニングの勘所
単に範囲を広げるだけでは不十分だ。高負荷環境では、再利用のポリシーを最適化する必要がある。
# 一時ポートの範囲を拡張する（デフォルトは通常 32768-60999 程度）
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
# TIME_WAIT ソケットの再利用を許可する（リスクを理解した上で有効化せよ）
# 接続元がNAT配下の場合は特に有効だが、厳密なTCPシーケンス制御を求めるなら注意が必要
sysctl -w net.ipv4.tcp_tw_reuse=1
# ファイルディスクリプタの上限をプロセス単位で引き上げる
# /etc/security/limits.conf に追記
* soft nofile 65536
* hard nofile 655362. パケットレベルの「死角」を可視化する
traceroute を実行したとき、UDPやICMPが特定のホップで遮断されることがある。これはファイアウォールの制限かもしれないが、多くの場合、カーネルが ICMP rate limiting を行っていることによる「見せかけの消失」だ。
特に TCP SYN を用いた traceroute を行う際、カーネルの tcp_max_syn_backlog が小さいと、診断パケット自身がドロップされる。インフラアーキテクトが自身の診断ツールをDoS攻撃の一部として検知してしまうという、皮肉な事故だ。
診断精度を高めるTCPバッファチューニング
高トラフィックな環境で、診断コマンドが「正常なバッファリング」を維持できるようにするには、以下のカーネルパラメータが鍵を握る。
# TCPの受信バッファの最小・デフォルト・最大値を設定
# 高速なバックボーンであれば、最大値を 16MB 以上に引き上げるのが鉄則
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# TCP SYN パケットのキュー長を増やす（診断の安定化に寄与）
sysctl -w net.ipv4.tcp_max_syn_backlog=40963. TLSハンドシェイクの最適化とレイテンシの正体
現代のネットワーク診断において、レイテンシの真犯人は TCP ではなく TLS ハンドシェイクであることも多い。特に TLS 1.3 では 1-RTT でハンドシェイクが完了するが、証明書の検証や OCSP Stapling の遅延が、nslookup や dig では決して見えない「アプリケーション層の遅延」を引き起こす。
もし、貴方の診断コマンドが特定のFQDNに対してだけ異常に遅いなら、それはネットワークではなく、DNSキャッシュの汚染か、あるいは背後の PKI インフラの応答速度を疑うべきだ。
効率的な診断のためのワンライナー
dig を用いて、DNS解決から接続までのステップを詳細に計測するには、以下のようなアプローチが有効だ。
# DNS解決のレイテンシを計測
time dig @8.8.8.8 example.com +short
# TCPハンドシェイクのRTTのみを抽出する（ssコマンドを活用）
# 通信相手との実際のレイテンシを確認するための強力なツール
ss -itn dst 192.0.2.1 | grep rtt現場のエンジニアへ：コマンドは「問い」であり「答え」ではない
我々が CLI で叩く ping や ss は、単なるコマンドではない。それはOSに対して「今のネットワークの状態はどうなっている？」と投げかける「問い」だ。しかし、カーネルパラメータという名のフィルターを通した先にある回答は、往々にして歪んでいる。
トラブルシューティングの本質は、コマンドの結果を鵜呑みにすることではなく、そのコマンドが実行される際にOS内部で何が起きているかを想像することにある。
ファイルディスクリプタが枯渇しているのか。SYNパケットがバックログで溢れているのか。あるいは、TCPウィンドウサイズがボトルネックとなっているのか。これらを頭の中でトレースできるようになった時、初めて貴方は「ネットワークの全体像」を捉えたと言えるだろう。
さあ、次は tcpdump を片手に、その目でパケットの断末魔を覗きに行こう。現場からは以上だ。
コメント