ネットワークの謎を解く: リバースエンジニアリングの技術
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
ネットワーク エンジニアの役割は進化していますが、目を丸くして「これはネットワーク自動化の記事ではありません」と言う前に、私の意見を聞いてください。 ネットワークの自動化がこの変化の一部であることを説明する素晴らしい記事がいくつかありますが、数年前に VAR の世界を離れ、いくつかの大企業で内部的に働いて以来、私の実際の日常の仕事はより集中し、さらに XNUMX つ: 分析です。
分析はデータの収集と解釈であり、ネットワーク分析は特にアプリケーションのパフォーマンスに関するネットワーク インフラストラクチャからのデータの収集と分析です。 私は常に比較的伝統的なネットワーク エンジニアの役割を担ってきたので、データが好きという理由だけでデータの分析に関心があるわけではありません。 代わりに、その情報を使用して、パターン、相関関係、および何かを見つけたいと考えています。 有意義で実用的な 何らかの方法でネットワークを改善します。
過去数年間の変化により、データセンターのコア カットオーバーを構成する方法よりも、ネットワークで日常的に実際に何が起こっているかを理解することに重点を置く必要がありました。 これは、特に、アプリケーション配信、情報セキュリティ、およびキャパシティ プランニングの貧弱なトラブルシューティングに関係していました。 そして、そのすべてにネットワーク データ分析が必要でした。
大企業に就職して間もなく、チームのハイパフォーマンス コンピューティング クラスタを管理している科学者から電子メールを受け取りました。 毎晩ほぼ同じ時間に、外部の顧客へのデータ送信が失敗し、回復するのに何分もかかりました。 これらの科学者は、XNUMX 日を通して膨大な量の大気データを収集し、レポート、生データ、またはその両方を購入した顧客について分析しました。 これらの顧客の一部は、非常に時間に敏感な情報を FTP 経由で取得する非常に大規模な科学機関でした。
クラスターを管理するアプリケーションは、ラックの上部にあるベア メタル サーバー上にあり、独自の接続を介してクラスターに接続されていましたが、管理目的と完成したレポートを提供するために LAN にも接続されていました。 障害は複数の顧客で発生していたので、問題が顧客側にあることを却下しました. それは私たちのものでなければなりませんでした。 ホストの XNUMX つ、クラスター コントローラー、またはネットワーク パスのどこかで何かが発生していました。
主任科学者はインシデントの所有権を取得し、アプリケーションとサーバーが正しく動作しているかどうかを確認しました。 彼の側ではすべて問題ないように見えたので、彼はネットワークの問題を疑いました。 競合する可能性のあるネットワーク アクティビティを簡単に特定することはできなかったので、パス内のすべてのネットワーク デバイスの構成を調べることから始めました。 スイッチ、ファイアウォール、およびルーターにログインしましたが、問題はありませんでした。
ここで何が起こっていたのですか？ ログが答えを明らかにします。 当時持っていたソフトウェアを使用すると、ごく少数のデバイスからごくわずかな情報しか収集していないことがわかりました。 他に見るべきものはあまりありませんでした。 ある種の意味のある情報が必要でした。 確かに、リアルタイムで何が起こっているかを確認するために一晩中デバイスを探し回ることもできましたが、何かを簡単に関連付けることができないことはわかっていました。 代わりに、ネットワーク上のすべてのものから収集するようにデータ収集ツールを構成しました。 一部のデバイスでは SNMP を構成し、他のデバイスでは NETFLOW を構成しました。どちらもサポートしていないデバイスについては、それらの IP に対して継続的に ping を実行し、開いているポートをスキャンするように収集ツールを構成しました。
数日間の電話、グーグル、主任科学者とのチャットの後、ある顧客は非常に焦り、インポートがほぼ毎晩失敗したことに腹を立てました. これは注目を集める問題となり、私にとって最優先事項になりました。 データ収集ソフトウェア用のストレージ容量を増やし、XNUMX 週間実行させました。 結果を調べてみると、毎晩ほぼ同じ時間、つまり問題が発生した時間に、アプリケーション コントローラーの CPU に異常なスパイクが見られました。 これは良いスタートでしたが、主任科学者がサーバー自体でこれを引き起こす原因を見つけることができる理由はありませんでした. ネットワーク リンクには異常な輻輳は見られず、パス内のどのスイッチも異常をまったく示しませんでした。
私たちの収集ツールは平凡だったので、私はこの新しいデータすべてを自分で調べるのにかなりの時間を費やさなければなりませんでした。 私の同僚は、CPU、リンク、およびメモリの使用率を検索し、ある種の巧妙な電子メール コネクタを介してグラフ形式で表示するスクリプトを作成してくれました。 すべての時間と労力を費やした結果、毎晩 CPU スパイクが発生しているアクセス スイッチを指摘する赤いフラグが表示されました。 スイッチにログインすると、アップタイムが前夜の運命的な時間に再起動の可能性が高いことを反映していることがわかりました.
仕事を離れる前に、スイッチを交換し、IP アドレスが監視ダッシュボードのウィジェットの XNUMX つであることを確認し、単純な永続的な ping を設定しました。 私の同僚は、ping が落ちた場合に電子メールを送信するスクリプトを作成し、CPU が急上昇した場合にアラートを送信するように監視ソフトウェアをセットアップしました。 がっかりしたことに、翌朝、ping がドロップしたことと、収集ソフトウェアから CPU が急上昇したことを通知する電子メールが届きました。 スイッチを確認しました - オンになっていました。 稼働時間を確認しましたが、真夜中に再起動したことがわかりました。 その答えはデータにあると確信しました。 しかし、それを掘り下げるのは非常に面倒で、顧客にとっては時間がかかりすぎました。 どこかに、私たちが見つけられなかったパターンまたは相関関係があったに違いないので、私たちは探し続けました. これを行うためのより良い方法が必要でしたが、今のところ、ソフトウェアとカスタム スクリプトを使用してできる限り最善を尽くしました。 すると、何かが見つかりました。 なじみのない IP アドレスにある不明なデバイスは、スイッチが再起動したときに非常におしゃべりになりました。 重複したアドレスではなく、同じサブネット上でもありませんでしたが、毎晩同じ時間に発生したものでした.
デバイスの追跡は簡単でした。 DNS ではなく、DHCP での予約でした。 それは、毎晩作動していたバックアップ AC のコントローラーであることが判明しました。 これは通常は問題になりませんが、サーバー ルームに行くと、AC ユニットがスイッチと同じ PDU に接続されていることがわかりました。 PDU には他に何もありませんでした。
AC ユニットが起動すると、スイッチが再起動する回路に十分なドレインがありました。 少なくともそれが私たちの理論でした。 スイッチを別の PDU に移動し、HVAC 担当者に電話をかけました。 その夜、スイッチは再起動しませんでした。私の理解では、HVAC 担当者がセンサーの問題を発見し、電気技師が電源の問題を修正しました。
これを理解するには、大量のデータを収集してインテリジェントに分析する必要がありました。 それは、ネットワーク エンジニアの同僚と私が最近エンタープライズ IT で働いている場所です。 確かに、ファイアウォールのアップグレードや MDF スイッチの交換は時折ありますが、ほとんどの場合、データを収集して分析し、アプリケーションのパフォーマンスのトラブルシューティングを行ったり、情報セキュリティ タスクに取り組んだりしています。
ネットワーク エンジニアの役割が、プログラマーやデータ サイエンティストになる必要があるほど変化しているとは思いません。一時的な情報。
NetBrain 最近、この分析の課題に取り組むことを目的とした非常に有望なテクノロジーを発表しました。 実行可能ファイル Runbooks。 基本的に、 Runbook は、ネットワーク データを自動的に収集して分析する方法を提供します。 これら以来 Runbooks は (プログラマーも非プログラマーも同様に) 適応させることができ、あらゆるネットワーク機能の分析を実行するために使用できます。 以下の例は、 Runbook これは、OSPF ルーティング設計を分析するために書かれました。