フォーラムは定期的に問題を提起します1つの物理セグメントに同じIPアドレスを含むネットワークの操作。これは、ネットワーク上でのいわゆるIPアドレスの競合を引き起こします。多くのそのようなフォーラムを読んだ後、誰もがそのようなプロセスを正しく理解しているわけではないことが明らかになり、多くの人が事実として、真実からはほど遠いさまざまなフィクションや推測を偽り始めます。少し前まで、この問題はシステム管理者の1つの優れたリソースで活発に議論されていました。この点で、どういうわけか緊急の状況を明らかにすることが必要となった。フォーラムの形式は、質問と回答からなるチェーンの交換であり、記事ではすべてについて順番に話すことができます。
ネットワークおよびネットワークプロトコルでのIPアドレスの競合
制御できる唯一のものネットワークアドレスの複製は、ARPアドレス変換プロトコルです。このすべての相互作用は、特定の形式で提示できます。新しいIPアドレスを受信すると、ホストAは特別な自発的なARP要求ブローカーを送信します。このプロセス全体がDNSサーバーのIPアドレスの影響を受けないことを理解することが重要です。リクエストは特別な形式の情報転送であり、SPAおよびTRAフィールドには独自のアドレスが含まれます。この要求に対する応答を受け取った場合、これはネットワーク上のIPアドレスの競合です。回答がない場合は、アドレスの重複もなく、ネットワーク内で一意です。さらに興味深いのは、答えが出たときにネットワークで何が起こるかということです。
ネットワークにリクエストを送信するノードが取得いわゆる攻撃ノードのステータス、および要求に応答したノードが攻撃ノードのステータスを受け取ります。この競合を検出する過程で、それらのそれぞれに何が起こりますか？
攻撃ノードについて考えてみましょう。 動的IPアドレスが設定されておらず、構成が手動で行われた場合、応答の受信後、アドレスの初期化はリセットされます。つまり、ノードは競合するアドレスをインターフェースに割り当てることができません。これはシステムログに記録され、画面にエラーが表示されます。アドレスがDHCPを介して構成されている場合、クライアントは、特別なDHCPOFFERパケットでDHCPサーバーから受信したアドレスの競合をチェックします。 DHCPOFFERからのアドレスが重複していることが判明した場合、クライアントが要求に対する応答を受信した後、特別なDHCPDECLINEパケットがDHCPサーバーに送信されます。サービスの実装に応じて、このアドレスは障害としてマークされ、その後、空きアドレスのリストから削除する必要があります。その後、クライアントはDHCPDISCOVERパケットを送信して、サーバーからIPアドレスを取得しようとします。
これで、IPアドレスの競合を考慮することができます攻撃されたノードの側からのネットワーク。フィールドがSPAの場合、ノードは競合を示します。この事実は特別なイベントログにも記録され、ユーザーにはエラーが通知されます。この場合、競合の原因となったIPアドレスは攻撃されたノードから削除されません。対立が確立された後、既存の対立を解決するためのメカニズムが機能し始めます。この場合の問題の本質は次のとおりです。1つの自発的な要求を送信した後、セグメントのすべてのクライアントが特定のスキームに従って要求を送信します。その結果、3つのフレームの順次交換から画像が取得されます。
リクエストによるデータ交換と応答は、アドレスが初期化されたときにのみ行われます。たとえば、ノードがネットワークに接続される前に競合するアドレス用に構成されていた場合、電源がオンになった後、自発的なデータ交換は行われません。この点で、ネットワーク上の両方のノードはこの競合するアドレスを使用しますが、新しいARP要求があるたびに、両方のノードが競合するアドレスに関するエラーを生成します。
