pingへの応答を担当するLinuxプロセスは何ですか？

Linuxベースのプロセスコントローラーがあり、それをpingできないポイントまでロックすることがあります（つまり、pingを実行でき、ネットワーク設定を変更しないとpingできなくなります）。

pingに実際に応答するのはどのプロセス/システムの責任ですか？このプロセスはクラッシュしているようです。

network-interface ping icmp

— イッツォ
ソース

pingに応答していないときに、まだsshできますか？または、既存のSSHセッションがロックアップしますか？

— ピーター

@PeterCordesシステム全体がロックされ、再起動を強制するまで基本的にレンガです。

— イッツォ

OK、それは通常、マシンがpingに応答しなくなる唯一の方法です。pingの動作は停止したが、他の機能が動作し続けた場合、ユーザー空間がホースで接続され、すべてがディスクI / OでデッドディスクまたはNFSマウントなどにブロックされても動作するため、奇妙です。モニターをシステムに接続して、ロックするときにコンソールメッセージがあるかどうかを確認してください。（そして、魔法のSysRQキーボードシーケンスを使用して情報をダンプしたり、読み取り専用を再マウントしたりできる場合は、ディスクを強制同期+リブートします。

— Peter Cordes

質問は興味深いものですが、pingはシステムの問題の原因ではなく、不安定なシステムの結果です。ログを確認して、何が問題なのかを理解してください。

— ペドロロビト

@PedroLobito具体的に何をログに記録しますか？

— イッツォ

回答:

カーネルネットワークスタックは、pingコマンドによって送信されたICMPメッセージを処理しています。

ネットワークの問題やフィルタリング、およびホストベースのフィルタリング/レート制限/ブラックホールなどに加えて、応答が得られない場合。これは、おそらくICMPトラフィックのためではなく、一時的またはカーネルクラッシュ（まれに発生する可能性がある）でマシンが過負荷になる可能性があることを意味します（障害のあるハードウェアなど）。サーバーがどのように物事を支えているかを見るために、サーバーの寿命の初めに良いテストになることができます）。カーネルクラッシュの後半の場合、ログファイルまたはコンソールに十分な情報が必要です。

また、pingほとんどの場合、サービスがオンラインかどうかをチェックするのに間違ったツールであることに注意してください。さまざまな理由によりますが、主に、定義により実際のアプリケーショントラフィックを模倣しないためです。たとえば、ウェブサーバーがまだ稼働していることを確認する必要がある場合、代わりにHTTPクエリ（TCPポート80または443）を実行する必要があります。メールサーバーを確認する必要がある場合は、SMTPクエリ（TCPポート25）を実行します。 DNSサーバー、UDP 、およびポート53へのTCPクエリなど。

— パトリック・メヴゼク
ソース

@Outurnate他のアプリケーションサービステストは失敗するか、タイムアウトになるため、観察される最終結果は同じになります。pingトラブルシューティングで非常に多くの誤検知を作成するため、使用に反対する講義の機会を見逃すことはありません。ユーザーがpingの正確な動作を知らず、誤解を招く結果をもたらす方法を他のユーザーに固執する必要があると思います。

— パトリックMevzek

ほとんどの過負荷状況では、まだ応答するのはカーネルによって行われるものだけです。つまり、マシンは通常、過負荷に関係なくpingに応答します。閉じたポートに到達しようとすると、TCPのRSTおよびUDPの場合のICMPエラーで応答します。そして、開いているTCPポートに到達しようとする最初の数回の試行で、ハンドシェイクが完了します。ディスク障害は、ほぼ同じ症状を引き起こす可能性があります。

— カスペルド

@kasperd（非常に）過負荷のサーバー（具体的にはスワップサーバー）がICMPリクエストに応答しないのを見ました。そしてもちろん、他にも何もありません。カーネルはクラッシュせず、ディスクI / Oの処理で忙しかった。

— パトリックメヴゼク

@Nachtうん。ネットワークインターフェイスはHWデバイスです。そのため、それとインターフェースするカーネルドライバーがあります。次に、2番目の層が汎用管理/通信APIを提供します。（これはネットワークに固有のものではありません：オーディオ開発者向けのALSAがあり、ビデオ出力はKMS APIを使用し、USBには{U、E、X} HCIがあり、usb_storage、usbhidなど）ネットワークルーティングテーブル、ファイアウォールルール（iptables経由））、ハンドシェイク、パケットアセンブリ、再送信などはすべてカーネル内にあります。ICMPはそれ自体に対するプロトコルであり、ペイロードも「応答する」または「応答しない」以上の処理もないため、カーネルはICMP応答を最小限のオーバーヘッドで直接処理します。

— FeRD

@Nacht：基本的なコンピューターアーキテクチャに関するものではありません。それは実装の選択です。マイクロカーネルは、OSプロセスでICMPを処理します。

— MSalters

pingへの応答を担当するユーザーランドプロセスはありません。Pingは、ICMPエコーパケットを送信するための単なるユーティリティです。これらはカーネルのネットワークスタックによって受信および処理されます

— 絶望的
ソース

カーネル自体（ユーザープロセスではない）は、ICMPエコー要求メッセージへの応答としてICMPエコー応答メッセージを送信します。そのため、ホストがpingへの応答を停止した場合、通常は次の理由のいずれかが原因です。

あなたとpingされるホスト間のネットワーク接続が切断された可能性があります。ケーブル自体の物理的損傷、ワイヤレスの場合のノイズ、ルートテーブルの破損、DDoS攻撃を受けている、間に問題のあるルーター/スイッチなど、さまざまな理由が考えられます。この場合、トラブルシューティングを開始します。使用してethtool(8)、iwconfig(8)、route(8)、ping(8)そのルータ、tcpdump(8)ターゲットホスト上など。
ターゲットホスト（またはユーザーとターゲットホストの間にあるルーター/ファイアウォール）のファイアウォール設定が、pingの量（またはトラフィックトラフィックの量）を制限している可能性があります。またfail2ban(8)、オンデマンドでのファイアウォール処理などのツールが原因である可能性もあります。参照してくださいiptables(8)確認すること。
ターゲットホストでソフトウェア/ハードウェアの誤動作が発生しました。ターゲットホスト上のネットワークカーネルモジュールのOOPSが発生したり、混乱したり、カーネル全体がPANIC化されたりする場合があります。dmesg(8)ターゲットホストでinについてのメッセージが表示されるか、物理コンソールの画面出力として表示されます（物理アクセスが実用的でない場合は、シリアルコンソールを備えた別のマシンが役立ちます）。カーネルOOPS / PANICが問題である場合またはwatchdog(8)、ヘルパードライバーを使用してシステムのロックアップを調整することもできます。または、ハードウェア部品を変更できます。

— マティヤ・ナリス
ソース

興味のある方のために、ICMPエコー要求を処理するための関連カーネルコードを以下に示します。

— ルスラン

また、非常に高い負荷（特にCPU）に言及する必要があります

— ギルヘルムベルナル

@GuilhermeBernalいいえ、非常に高いCPUユーザー負荷（数千単位）でもICMP損失は発生しません（ユーザープロセスが実行される前にカーネルで処理されるため）。ローエンドのハードウェアとの組み合わせで非常に高いネットワークPPS率は、パケットロスが発生する可能性がありますが、そのようなDDoS攻撃は、「ネットワーク接続」に該当

— マティヤNalis