Windows静的 arp 登録

WindowsのPCからサーバにPINGを打つと飛んだり飛ばなかったり・・・
同じセグメント同士なので飛ばない理由がわからない。

■環境
[PC設定]
IP : 192.168.1.201
mask : 255.255.255.0
GW : 192.168.1.1
mac : cc-cc-cc-cc-cc-bb

[サーバ]
IP : 192.168.1.11
mask : 255.255.255.0
GW : 192.168.1.1
mac : cc-cc-cc-cc-cc-aa

[ルーター]
IP : 192.168.1.1(セカンダリIP : 192.168.1.2)
mac : cc-cc-cc-cc-cc-zz

PC(192.168.1.201)からサーバ(192.168.1.11)へtracerouteをかけると
なぜかルーターのセカンダリIP(192.168.1.2)を参照している。意味不明である。
とりあえず切り分けとして以下を行った。

■PCにて切り分け
ゲートウェイ削除　結果：変わらず
再起動　結果：変わらず
arp情報削除(コマンドプロンプトでarp -d)　結果：変わらず

arp -aコマンドでPINGを飛ばしたいサーバー(192.168.1.11)を確認すると
ルーターらしきmacアドレスが表示される。

不思議です。とは言え上位のスイッチやルーターは管理部署が
違うので手が出せない。

ってことでIPアドレスとmacアドレスを固定(静的)で設定する
ことにしました。

■静的arp設定その1(arp -s)
[PCにて確認]
コマンドプロンプトを管理者権限で実行してmacアドレステーブルを確認。
C:/＞arp -a
192.168.1.11 cc-cc-cc-cc-cc-zz 動的

[PCにて設定変更]
C:/＞arp -s 192.168.1.11 cc-cc-cc-cc-cc-aa
C:/＞arp -a
192.168.1.11 cc-cc-cc-cc-cc-aa 静的

[サーバーにて確認]
C:/＞arp -a
192.168.1.201 cc-cc-cc-cc-cc-zz 動的

[サーバーにて設定変更]
C:/＞arp -s 192.168.1.201 cc-cc-cc-cc-cc-bb
C:/＞arp -a
192.168.1.201 cc-cc-cc-cc-cc-bb 静的

PCだけじゃなくサーバーのMACアドレスもGWに向いていたので変更。
そしてお互い無事にPINGが飛ぶようになりました！！
OSのバージョンによってはarp -sコマンドでmacアドレスの登録ができないようです。
その場合は以下コマンドで。

■静的arp設定その2(netsh)
[PCにて設定変更]
C:/＞netsh
netsh＞interface ipv4
netsh interface ipv4＞set neighbors "インターフェース名" "192.168.1.11" "cc-cc-cc-cc-cc-aa"
netsh interface ipv4＞

"インターフェース名"は設定したいNICの名前を入力します。
イーサネットとかローカルエリア接続が多いですかね。
ipconfig /allで確認すればわかります。

[PCにて設定確認]
netsh interface ipv4＞show neighbors

[PCにて設定削除]
netsh interface ipv4＞delete neighbors "インターフェース名" "192.168.1.11" "cc-cc-cc-cc-cc-aa"

末端の機器でMAC登録やルーティングを設定するのはおすすめしませんが
どうしてもというときは是非。

Comments

初めまして
本記事ですが、状況としては以下のようになってるかと思います
・サーバーはルーターの外側にある
・ルーターでサーバのIPアドレスをNATして同じセグメントにあるように見せかけている
・ルータのアクティブはプライマリ側

1.PCがサーバに対して通信しようとした際、サーバIPに対するarpリクエストを発信（ブロードキャスト）
2.プライマリルータとセカンダリルータがそれぞれarpリクエストに応答
3.応答が先着したセカンダリルータのarpリクエストに従ってPCのarpテーブルを更新（サーバ→セカンダリルータの持つMACアドレス）
4.PCからサーバ宛ての通信がarpテーブルに従ってセカンダリルータへ転送
5.セカンダリルータはNATしてサーバに転送（NATテーブルを更新）
6.サーバーが通信を応答、自身のルーティングとarpテーブルに従ってプライマリルータに転送
7.プライマリルータはNATテーブルに乗ってない応答の通信が来たので不正な通信として破棄
ということかと。

時々つながったりするのは3の時点でプライマリのルータのarp応答が先着して正しい経路で通信できる（プアライマリルータにNATテーブルが更新されて7の時点で通信が破棄されない）からですね。
このような冗長化したルータで同じセグメントのIPアドレスへのNATを行う構成の場合、スタンバイルータがarpリクエストに対して応答しない機能を持つルータを使用しなければなりません

管理する部署の方々に「お前らの設計はクソだ」と言ってあげてください。

Posted by GLM at 2023年11月02日 20:19