web-dev-qa-db-ja.com

UbuntuがARPリクエストに応答しない

Linuxマシンで、説明できない動作が発生します。着信ARP要求が表示されますが、私のマシンでは応答されません。イーサネットケーブルをWindows10マシンに接続すると、これらのARP要求に応答します。

また、ターゲット192.168.1.106をnmapしようとすると、このデバイスのトラフィックをキャプチャできないことに気付きました。着信ARP要求は表示されますが、発信パケットはまったく表示されません。ターゲット（およびインターフェイス）を切り替えると、nmapからの発信トラフィックが表示されます。これがARPの問題と関係があるかどうかはわかりません。 ARP応答がない場合、nmapスキャンはどのように機能するのでしょうか...

私はいくつかのインターフェースを備えたUbuntu16.04マシンを持っています。私はそれらのIPを自分で設定しました。 ARP要求を送信するデバイスは、enp0s25インターフェイスに接続されています。 ifconfigコマンドの出力は、次のようになります。

enp0s25   Link encap:Ethernet  HWaddr b0:5a:da:ee:38:cd  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::3f90:bbf0:85e2:6423/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6314 errors:0 dropped:0 overruns:0 frame:0
          TX packets:603 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:404096 (404.0 KB)  TX bytes:50704 (50.7 KB)
          Interrupt:20 Memory:d2100000-d2120000 

enx00249b1963d4 Link encap:Ethernet  HWaddr 00:24:9b:19:63:d4  
          inet addr:192.168.1.99  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::5ecb:670e:5bd1:7ac1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:393532 errors:0 dropped:0 overruns:0 frame:0
          TX packets:393429 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:19874193 (19.8 MB)  TX bytes:30957637 (30.9 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:141121 errors:0 dropped:0 overruns:0 frame:0
          TX packets:141121 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7408865 (7.4 MB)  TX bytes:7408865 (7.4 MB)

wlp61s0   Link encap:Ethernet  HWaddr a4:c4:94:5c:a3:aa  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2600:1007:b000:743e:265b:1fb5:bb6c:2e5/64 Scope:Global
          inet6 addr: fe80::e5a4:4dcb:ed06:e981/64 Scope:Link
          inet6 addr: 2600:1007:b00e:643d:244c:2307:f4ac:1b16/64 Scope:Global
          inet6 addr: 2600:1007:b000:743e:244c:2307:f4ac:1b16/64 Scope:Global
          inet6 addr: 2600:1007:b00e:643d:c233:8501:765e:d4f6/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14764 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6658 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13720070 (13.7 MB)  TX bytes:822384 (822.3 KB)

tcpdumpを設定すると、これは出力のスニペットです。

14:58:49.666404 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:50.676781 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:52.666512 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:54.666590 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:55.676786 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:57.666634 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:58:59.666768 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:00.676963 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:02.666846 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:04.666932 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:05.677240 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:07.667045 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42
14:59:09.667172 ARP, Request who-has 192.168.1.100 (Broadcast) tell 192.168.1.106, length 42

私はすでにいくつかの調査を行いましたが、問題を解決するために必要なものを見つける（または理解する）ことができませんでした。それが役立つ場合は、コマンドip rule showおよびip route show table localの出力です。このサイトの別の質問でこれを見つけましたが、この情報を使用できませんでした。

john@john:~$ ip rule show
0:  from all lookup local 
32766:  from all lookup main 
32767:  from all lookup default 
john@john:~$
john@john:~$
john@john:~$ ip route show table local
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope Host  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope Host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.1.0 dev wlp61s0  proto kernel  scope link  src 192.168.1.2 
broadcast 192.168.1.0 dev enx00249b1963d4  proto kernel  scope link  src 192.168.1.99 
broadcast 192.168.1.0 dev enp0s25  proto kernel  scope link  src 192.168.1.100 
local 192.168.1.2 dev wlp61s0  proto kernel  scope Host  src 192.168.1.2 
local 192.168.1.99 dev enx00249b1963d4  proto kernel  scope Host  src 192.168.1.99 
local 192.168.1.100 dev enp0s25  proto kernel  scope Host  src 192.168.1.100 
broadcast 192.168.1.255 dev wlp61s0  proto kernel  scope link  src 192.168.1.2 
broadcast 192.168.1.255 dev enx00249b1963d4  proto kernel  scope link  src 192.168.1.99 
broadcast 192.168.1.255 dev enp0s25  proto kernel  scope link  src 192.168.1.100
debiannetworkingipnetwork-interfacearp
2
JRsz

だからあなたの質問のいくつかの技術的側面に取り組むことを試みます。

最大の技術的問題は、2つのイーサネットと1つのwifiネットワークインターフェイスに同じネットブロックがあることです。それはあなたのルーティングを台無しにします。

また、wifiインターフェースのMACアドレス間でのシフトが速すぎるようです。それはあなたの現在の接続に干渉します（そしてそれらをシャットダウンします）。

Wi-Fiが認証されると、新しいMACアドレスをスプーフィングしたら、（スプーフィングの前に）インターフェイスを停止し、（スプーフィングの後で）再度立ち上げて、新しいMACアドレスを使用したすべての認証プロセスを再度実行する必要があります。それ以外の場合、APは、インターフェイスが認証されていることを認識しないため、処理を停止します。

警告：一部の機器/セットアップ/ブランドでは、古いMACが見えなくなるために、しばらく待つか、同じ新しいMACでプロセスを数回繰り返す必要があります（キャッシュなど）。まれなWi-Fiドライバーでは、Wi-Fiのブランドを識別するMACアドレスの最初の3バイトを変更すると、ドライバーが気に入らない場合があるため、スプーフィングできるのは下位3バイトのみです。

さらに、IPv6アドレスがMACアドレスの外部に流出しています。プロバイダーがIPv6を提供していて、すでにいくつかのIPv6アドレスを想定しているため、Linuxの場合と同様に、これにより問題が発生します。デフォルトでは、IPv6がIPv4よりも優先されます。さらに、そのような出血は、ネットワーク管理者があなたをすぐに気付かせてしまいます。考えられる回避策は、MACアドレスをスプーフィングしているときにIPv6を完全に無効にすることです。

さらに、インターフェースの名前は、realtekベースのチップセットを使用していることを示しています。安価ですが、品質は低く、接続の安定性に問題があることがわかっています。ラリンクまたはアセロスの特定のモデルは、この種の活動にはるかに適しています。関連項目を参照 ASUS USB-N13アダプターを使用したWi-Fiの問題

PS。明らかに、水晶玉はありません。これは、システムが実行しているアクティビティの種類を示す一連の手がかりがまとめられているためです。よりあいまいな操作を行うために、動作の悪いユーティリティを使用した場合の結果をよりよく理解することをお勧めします。

3
Rui F Ribeiro