ネットワークの謎を解く: リバースエンジニアリングの技術
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
「ネットワークの問題ではありません!」私と同じように、アプリケーションの問題をトラブルシューティングするときにそう主張する人もいるでしょう。唯一の問題は、慎重にネットワークを診断した後、本当にネットワークに問題があることが判明する場合があるということです。
ネットワーク エンジニアの間での冗談は、コンピュータに関連する何かに問題があると、誰もがファイアウォールのせいにするということです。 確かに、これは面白いかもしれませんが、ネットワーク エンジニアがネットワーク診断を行う際に最もイライラすることの XNUMX つでもあります。 私たちは、ネットワーク経由で ping を実行することは得意ですが、アプリケーションのトラブルシューティングは暗闇の中で撮影するように感じることがあります。
ほんの数か月前、科学機器の監視に使用されているレガシー アプリケーションのトラブルシューティングを支援するために開発者の XNUMX 人が開始した電子メール チェーンに私がタグ付けされました。 アプリケーションはメインの場所では問題なく動作しましたが、これは新しいサイトであり、何かが間違っていました。
彼らが私を連れてくる前にアプリケーションのトラブルシューティングに時間を割いていたと聞いて驚いた.
アクセス リストや MTU 設定などの基本事項を確認しましたが、メイン サイトでは発生した症状がなかったため、何を調べればよいかわかりませんでした。両方のサイトは同じように構成されていたため、私の考えでは、これで解決するはずでした。アプリケーション自体のログには役立つ情報は何も示されなかったので、再び発生するのを待ってデバイスにリアルタイムでログインする以外に、ネットワーク診断を行うことはほとんどありませんでした。
インシデント発生時に関連情報を収集することは、特に数百のスイッチ、数十のルーターとファイアウォールで構成されるネットワークでは非常に困難になることがあります。 たとえば、アプリケーションが通過するレイヤー 2 パスをトレースすることは、traceroute がレイヤー 3 のみを参照するため、ほぼ不可能です。また、フローのレイヤー 3 情報を確認する場合でも、一度に一方向のみです。
また、リアルタイムでトラブルシューティングを行う上で重要なのは、インターフェースエラー、デュプレックスの不一致、CRCエラーなど、パスに沿ったネットワークデバイス情報です。デバイスごとに手動で確認することで、これらの情報の一部を取得できますが、そのためには CLI ユーザーが問題を報告したときにすぐに対応できます。
当時私たちが持っていたアドホック ネットワーク診断方法だけを使用して、デバイスを製造ラインから外し、直接接続した状態でテストを実行することでトラブルシューティングを続けました。アプリケーションは完璧に動作しました。すべてを製造ラインに戻した後、アプリケーションは失敗しました。イライラしたと言うのは控えめな表現でしょう。
しかし、今回は私が対処していたので、科学者がアプリケーションを再び使い始めたときに、パケット キャプチャによってすぐに問題が明らかになりました。問題は非常に単純でしたが、ネットワーク診断中にチェックしようとは思いませんでした。
私はアプリケーションがどのように動作するのかを知りませんでした。また、すべての電話会議を通じて、開発者が作成したものではない古いプログラムを維持するために最善を尽くしていることを知りました。
マルチキャストを使用していましたが、誰も知りませんでした。
ここで、自動化されたインテントベースのネットワーク診断が、現実の問題をトラブルシューティングするネットワーク エンジニアにとって救世主となり得ます。ネットワーク モニターは持っていましたが、ネットワーク特性を継続的に監視し、ベースライン構成と照合し、ITSM および監視ツールによってトリガーされて、チケット内のインシデント発生時にネットワーク診断などの重要な情報を自動的に取得できるメカニズムが必要でした。幸い、インテント (コード不要の実行可能な自動化ユニット) を使用できます。これには、ルーティング テーブル、インターフェイス統計、一時的なネットワーク情報、さらにはインシデント発生時にアプリケーションがたどるパスに関するデータを自動的に配信する手順が含まれています。これを自分で対話的に実行することも、セルフサービス ボットを使用して実行することもできます。
アプリケーションが使用されるのはメイン サイトだけだったので、これは考えられませんでした。 しかし、レイヤ 3 の境界を越えて別の場所で使用されるようになったため、ネットワークとアプリケーションは、通信が機能するようにマルチキャストを適切に構成する必要がありました。
修復はネットワーク診断に比べると比較的簡単で、経営陣は、この古いアプリケーションを新しいサイトで動作させることができたことに満足していました。なぜそんなに時間がかかったのかと疑問に思う人はいませんでしたが、それは、これが古いアプリケーションであることがすでに認識されていたからだと思います。
解決までに非常に長い時間がかかることは気にしませんでしたが、問題が発生したときに必要なデータを簡単に取得できる方法があればいいのにと思いました。 実際、そのようなツールは、日常のネットワーク運用の問題のトラブルシューティングには非常に貴重です。
よりスマートなネットワーク診断
NetBrainのプラットフォームにより、ネットワーク エンジニアは、アプリケーションがネットワークを通過する経路を簡単に視覚化できます。さらに、Auto Intent を使用して、ほとんどまたはまったく情報のない漠然としたトラブル チケットをマップ上に自動的に表示し、キューに届く非常に貴重なネットワーク診断情報を収集するための適切なインテントを自動的に提供できます。
結局、アプリケーションの問題を修正することはロケット科学ではありませんでした。 私たちが直面する多くの問題は、非常に一般的な問題の結果であることが多いことを学びました。 ただし、問題が単純であっても、適切なツールがなければ、問題を見つけるのは非常に困難です。
Intent-Based Network Automation ネットワーク エンジニアとして、 動的ネットワーク マッピング そして、ネットワーク、接続性、アプリケーションのパフォーマンスのリアルタイム診断とトラブルシューティングのためのオーバーレイ インテントは、最終的にはネットワークではないことをきっぱりと証明するのに役立ちます。もちろん、ネットワークである場合は除きます。