Google Cloud テクニカル サポートからの DNS パケットの欠落に関する話

Google ブログ編集者より: Google Cloud Technical Solutions (TSE) のエンジニアがサポート リクエストをどのように処理するか疑問に思ったことはありますか? TSE テクニカル サポート エンジニアは、ユーザーから報告された問題の原因を特定し、修正する責任を負います。 これらの問題の中には非常に単純なものもありますが、場合によっては、一度に複数のエンジニアの対応が必要なチケットに遭遇することがあります。 この記事では、東証従業員の XNUMX 人が、最近の実践で得た XNUMX つの非常に厄介な問題について語ります。 DNSパケットが欠落している場合。 このストーリーでは、エンジニアがどのようにして状況を解決することができたのか、またエラーの修正中にどのような新しいことを学んだのかを見ていきます。 このストーリーが根深いバグについて理解していただくだけでなく、Google Cloud にサポート チケットを提出するプロセスについても理解していただけることを願っています。

トラブルシューティングは科学でもあり、芸術でもあります。 すべては、システムの非標準的な動作の理由について仮説を立てることから始まり、その後、システムの強度がテストされます。 ただし、仮説を立てる前に、問題を明確に定義し、正確に定式化する必要があります。 質問が曖昧すぎる場合は、すべてを慎重に分析する必要があります。 これはトラブルシューティングの「技術」です。

Google Cloud では、ユーザーのプライバシーを保証するために最善を尽くしているため、このようなプロセスは飛躍的に複雑になります。 このため、TSE エンジニアはシステムを編集するためのアクセス権を持たず、ユーザーほど広範な構成を表示することもできません。 したがって、仮説をテストするために、私たち (エンジニア) はシステムをすぐに変更することはできません。

一部のユーザーは、当社が自動車サービスの整備士のようにすべてを修正し、単に仮想マシンの ID を送信すると信じていますが、実際には、プロセスは会話形式で行われます。つまり、情報を収集し、仮説を立てて確認 (または反駁) し、そして最終的に、意思決定の問題はクライアントとのコミュニケーションに基づいて決定されます。

問題の問題

今日はグッドエンディングの物語をご紹介します。 提案された訴訟の解決が成功した理由の XNUMX つは、問題が非常に詳細かつ正確に説明されたことです。 以下に、最初のチケットのコピーが表示されます (機密情報を隠すために編集されています)。

このメッセージには、私たちにとって有益な情報がたくさん含まれています。

• 特定の VM が指定されました
• 問題自体は示されています - DNS が機能しません
• 問題が現れる場所 (VM とコンテナー) が示されます。
• 問題を特定するためにユーザーが実行した手順が示されます。

このリクエストは「P1: 重大な影響 - 運用環境でサービスが使用できない」として登録されました。これは、「Follow the Sun」スキームに従って状況を 24 時間 7 日継続的に監視することを意味します (詳細については、こちらをご覧ください) ユーザーリクエストの優先順位)、タイムゾーンが変わるたびに、あるテクニカル サポート チームから別のテクニカル サポート チームに移動します。 実際、この問題がチューリッヒの私たちのチームに届いた時には、すでに世界中を駆け巡っていました。 この時点までに、ユーザーは緩和策を講じていましたが、根本原因がまだ発見されていなかったため、運用環境で同じ状況が繰り返されることを恐れていました。

チケットがチューリッヒに到着するまでに、すでに次の情報が手元にありました。

• コンテント /etc/hosts
• コンテント /etc/resolv.conf
• 出力 iptables-save
• チームで組み立てた ngrep pcapファイル

このデータにより、「調査」とトラブルシューティングの段階を開始する準備が整いました。

私たちの最初の一歩

まず、メタデータ サーバーのログとステータスをチェックし、正しく動作していることを確認しました。 メタデータ サーバーは IP アドレス 169.254.169.254 に応答し、とりわけドメイン名の制御を担当します。 また、ファイアウォールが VM で正しく動作し、パケットをブロックしないことも再確認しました。

それはある種の奇妙な問題でした。nmap チェックは、UDP パケットの損失に関する私たちの主な仮説を否定しました。そこで、私たちはさらにいくつかのオプションとそれらをチェックする方法を頭の中で考え出しました。

• パケットは選択的にドロップされますか? => iptables ルールを確認する
• 小さすぎませんか？ MTU? => 出力を確認する ip a show
• この問題は UDP パケットのみに影響しますか、それとも TCP にも影響しますか? => 走り去ってください dig +tcp
• dig で生成されたパケットは返されますか? => 走り去ってください tcpdump
• libdns は正しく動作していますか? => 走り去ってください strace 双方向のパケットの送信を確認する

ここでは、ユーザーに電話して問題をライブでトラブルシューティングすることにします。

通話中に、いくつかのことを確認できます。

• いくつかのチェックを行った後、iptables ルールを理由のリストから除外しました。
• ネットワーク インターフェイスとルーティング テーブルをチェックし、MTU が正しいことを再確認します。
• 私たちはそれを発見します dig +tcp google.com (TCP) は正常に動作しますが、 dig google.com (UDP) が機能しない
• 走り去ってしまった tcpdump 作業中に dig、UDP パケットが返されていることがわかります。
• 私たちは車で走り去ります strace dig google.com そして、dig がどのように正しく呼び出しているかがわかります sendmsg() и recvms()ただし、XNUMX 番目の処理はタイムアウトによって中断されます。

残念ながら、シフトの終わりが近づいたため、問題を次のタイムゾーンにエスカレーションする必要があります。 しかし、このリクエストは私たちのチームの関心を呼び起こし、同僚は、scrapy Python モジュールを使用して最初の DNS パッケージを作成することを提案しました。

from scapy.all import *

answer = sr1(IP(dst="169.254.169.254")/UDP(dport=53)/DNS(rd=1,qd=DNSQR(qname="google.com")),verbose=0)
print ("169.254.169.254", answer[DNS].summary())

このフラグメントは DNS パケットを作成し、リクエストをメタデータ サーバーに送信します。

ユーザーがコードを実行すると、DNS 応答が返され、アプリケーションがそれを受信して​​、ネットワーク レベルで問題がないことを確認します。

もう一度「世界一周」した後、リクエストはチームに戻り、私はそれを完全に自分に転送します。リクエストがあちこちに巡回するのをやめた方がユーザーにとって便利だと考えました。

それまでの間、ユーザーはシステム イメージのスナップショットを提供することに同意していただきます。 これは非常に良いニュースです。自分でシステムをテストできるため、トラブルシューティングがはるかに速くなります。ユーザーにコマンドの実行、結果の送信、分析を依頼する必要がなくなり、すべてを自分で行うことができるからです。

同僚は私を少し羨ましがるようになりました。 昼食をとりながら改宗について話し合いますが、何が起こっているのか誰も知りません。 幸いなことに、ユーザー自身はすでに影響を軽減するための措置を講じており、急いでいないため、問題を分析する時間があります。 イメージがあるので、興味のあるテストを実行できます。 素晴らしい！

一歩後退する

システム エンジニアの職に対する面接で最も人気のある質問の XNUMX つは次のとおりです。 www.google.com? 受験者はシェルからユーザー空間、システム カーネル、そしてネットワークに至るまですべてを説明する必要があるため、この質問は素晴らしいものです。 笑ってしまいます。面接での質問が実生活でも役立つことがあります...

この人事に関する質問を現在の問題に適用することにしました。 大まかに言えば、DNS 名を決定しようとすると、次のことが起こります。

1. アプリケーションは libdns などのシステム ライブラリを呼び出します。
2. libdns は、どの DNS サーバーに接続する必要があるシステム構成をチェックします (図では、これは 169.254.169.254、メタデータ サーバーです)。
3. libdns は、システム コールを使用して UDP ソケット (SOKET_DGRAM) を作成し、DNS クエリを含む UDP パケットを両方向に送信します。
4. sysctl インターフェイスを介して、UDP スタックをカーネル レベルで設定できます。
5. カーネルはハードウェアと対話し、ネットワーク インターフェイスを介してネットワーク上にパケットを送信します。
6. ハイパーバイザーは、メタデータ サーバーとの通信時にパケットを捕捉して送信します。
7. メタデータ サーバーは、その魔法によって DNS 名を決定し、同じ方法を使用して応答を返します。

私たちがすでに検討した仮説を思い出してください。

仮説: 壊れたライブラリ

• テスト 1: システムで strace を実行し、dig が正しいシステム コールを呼び出すことを確認します。
• 結果: 正しいシステムコールが呼び出されます。
• テスト 2: srapy を使用して、システム ライブラリをバイパスして名前を決定できるかどうかを確認する
• 結果: できます
• テスト 3: libdns パッケージと md5sum ライブラリ ファイルに対して rpm –V を実行します。
• 結果: ライブラリ コードは、動作しているオペレーティング システムのコードと完全に同一です。
• テスト 4: この動作を行わずにユーザーのルート システム イメージを VM にマウントし、chroot を実行し、DNS が機能するかどうかを確認します。
• 結果: DNS は正しく動作します

テストに基づいた結論: 問題はライブラリにありません

仮説：DNS設定に誤りがある

• テスト 1: tcpdump をチェックし、dig の実行後に DNS パケットが正しく送信および返されるかどうかを確認します。
• 結果: パケットは正しく送信されます。
• テスト 2: サーバーを再確認する /etc/nsswitch.conf и /etc/resolv.conf
• 結果: すべて正しい

テストに基づいた結論: 問題はDNS設定にありません

仮説: 炉心損傷

• テスト: 新しいカーネルをインストールし、署名を確認し、再起動します。
• 結果: 同様の動作

テストに基づいた結論: カーネルは損傷していません

仮説: ユーザー ネットワーク (またはハイパーバイザー ネットワーク インターフェイス) の誤った動作

• テスト 1: ファイアウォール設定を確認する
• 結果: ファイアウォールはホストと GCP の両方で DNS パケットを通過させます。
• テスト 2: トラフィックをインターセプトし、DNS リクエストの送信と返信の正確さを監視します。
• 結果: tcpdump は、ホストが戻りパケットを受信したことを確認します。

テストに基づいた結論: 問題はネットワークにありません

仮説: メタデータ サーバーが機能していない

• テスト 1: メタデータ サーバーのログに異常がないか確認する
• 結果: ログに異常はありません
• テスト 2: メタデータ サーバーをバイパスする dig @8.8.8.8
• 結果: メタデータ サーバーを使用しなくても解像度が壊れる

テストに基づいた結論: 問題はメタデータ サーバーにありません

ボトムライン： を除くすべてのサブシステムをテストしました ランタイム設定！

カーネルのランタイム設定の詳細

カーネル実行環境を構成するには、コマンド ライン オプション (grub) または sysctl インターフェイスを使用できます。 覗いてみた /etc/sysctl.conf 考えてみると、いくつかのカスタム設定を発見しました。 何かを掴んだような気がして、ネットワークや TCP 以外の設定をすべて破棄し、山の設定だけを残しました。 net.core。 次に、VM 内のホスト権限のある場所に移動し、原因が見つかるまで、壊れた VM に設定を XNUMX つずつ適用し始めました。

net.core.rmem_default = 2147483647

これが、DNS を破壊する構成です。 凶器を見つけました。 しかし、なぜこのようなことが起こっているのでしょうか? まだ動機が必要でした。

基本的な DNS パケット バッファ サイズは次のように設定されます。 net.core.rmem_default。 一般的な値は約 200KiB ですが、サーバーが大量の DNS パケットを受信する場合は、バッファ サイズを増やすことをお勧めします。 新しいパケットの到着時にバッファがいっぱいになると、たとえばアプリケーションの処理速度が十分でないために、パケットが失われ始めます。 私たちのクライアントは、DNS パケットを通じてメトリクスを収集するアプリケーションを使用していたため、データ損失を恐れてバッファ サイズを正しく増やしました。 彼が設定した値は、可能な最大値である 231-1 でした (231 に設定すると、カーネルは「無効な引数」を返します)。

突然、なぜ nmap と scapy が正しく動作するのかに気づきました。それらは生のソケットを使用しているからです。 raw ソケットは通常のソケットとは異なります。iptables をバイパスし、バッファリングされません。

しかし、なぜ「バッファが大きすぎる」ことが問題を引き起こすのでしょうか? 明らかに意図したとおりに機能しません。

この時点で、複数のカーネルと複数のディストリビューションで問題を再現できました。 この問題はすでに 3.x カーネルで発生していましたが、今回は 5.x カーネルでも発生しました。

確かに、起動時に

sysctl -w net.core.rmem_default=$((2**31-1))

DNS が機能しなくなりました。

単純な二分探索アルゴリズムを通じて動作する値を探し始めたところ、システムが 2147481343 で動作することがわかりました。しかし、この数値は私にとって意味のない数値のセットでした。 私がクライアントにこの番号を試してみることを提案したところ、システムは google.com では動作するが、他のドメインでは依然としてエラーが発生するという答えが返ってきたので、調査を続けました。

インストールしました ドロップウォッチ、これはもっと早くから使われるべきだったツールです。このツールは、パケットがカーネル内のどこに到達するかを正確に示します。 犯人は関数だった udp_queue_rcv_skb。 カーネルソースをダウンロードしていくつか追加しました 関数 printk パケットがどこで終わるのかを正確に追跡します。 すぐに最適な条件が見つかりました ifそして、しばらくそれをただ見つめていました。そのとき、すべてが最終的に全体像にまとまったからです。231-1、意味のない数字、機能しないドメイン...それは、次のコードの一部でした。 __udp_enqueue_schedule_skb:

if (rmem > (size + sk->sk_rcvbuf))
		goto uncharge_drop;

ご注意ください：

• rmem int型です
• size u16 (符号なし XNUMX ビット int) 型で、パケット サイズを格納します。
• sk->sk_rcybuf これは int 型であり、定義上、次の値に等しいバッファ サイズを格納します。 net.core.rmem_default

時 sk_rcvbuf 231 に近づくと、パケット サイズを合計すると次のようになります。 整数オーバーフロー。 また、これは int であるため、その値は負になるため、条件は false であるべきときに true になります (これについて詳しくは、次の URL を参照してください)。 リンク).

このエラーはキャストするという簡単な方法で修正できます。 unsigned int。 修正を適用してシステムを再起動すると、DNS が再び機能しました。

勝利の味

私は調査結果をクライアントに転送して送信しました LKML カーネルパッチ。 満足しています。パズルのすべてのピースがはまり、観察した内容をなぜ観察したのか正確に説明できます。そして最も重要なことに、チームワークのおかげで問題の解決策を見つけることができました。

このケースはまれであることが判明し、幸いなことに、ユーザーからそのような複雑なリクエストを受け取ることはめったにありません。

出所： habr.com