O Ubuntu não responde aos pedidos ARP

Question

Eu tenho um comportamento na minha máquina Linux que não consigo explicar. Eu vejo solicitações ARP recebidas, mas elas não são respondidas pela minha máquina. Quando eu conecto o cabo Ethernet em uma máquina Windows 10, essas solicitações ARP estão sendo respondidas.

Também percebi que não consigo capturar o tráfego nesse dispositivo quando tento nmapear o destino 192.168.1.106 . Eu vejo solicitações ARP de entrada, mas nenhum pacote de saída. Quando mudo o alvo (e a interface), vejo o tráfego de saída do nmap. Eu não sei se isso tem algo a ver com o problema ARP. Eu só tive essa idéia porque sem uma resposta ARP como é uma varredura nmap deveria funcionar ...

Eu tenho uma máquina Ubuntu 16.04 com algumas interfaces. Eu configurei os IPs para eles mesmos. O dispositivo que envia solicitações ARP está conectado à interface enp0s25 . A saída do comando ifconfig produz isso:

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)

Quando configuro tcpdump , este é um fragmento da saída:

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

Já fiz algumas pesquisas, mas não consegui encontrar (ou entender) o que preciso para resolver meu problema. Se isso ajudar, esta é a saída dos comandos ip rule show e ip route show table local . Achei isso em outra pergunta neste site, mas não consegui usar essa informação.

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

    

Answer 1

Então, tente lidar com os vários aspectos técnicos da sua pergunta.

O maior problema técnico é ter o mesmo netblock em suas duas interfaces de rede ethernet e wi-fi. Isso vai atrapalhar seu roteamento.

Eu também vejo que você parece estar mudando muito rápido entre os endereços MAC na interface wifi. Isso interferirá nas suas conexões atuais (e as desligará).

Como o wifi é autenticado, uma vez que você falsifica um novo endereço MAC, você precisa derrubar sua interface (antes de falsificar) e colocá-la novamente (depois de falsificar), passando novamente por todo o processo de autenticação com o novo endereço MAC . Caso contrário, o AP parar de lidar com você, pois não sabe que sua interface está sendo autenticada.

Advertências: em alguns equipamentos / setup / marcas é necessário aguardar algum tempo ou repetir o processo algumas vezes com o mesmo novo MAC, para que o antigo MAC fique fora de cena (caches, outros). Em alguns drivers de Wi-Fi mais raros, o driver pode não gostar se você alterar os três primeiros bytes do endereço MAC que identificam a marca do Wi-Fi, para que você possa apenas falsificar os três bytes inferiores.

Além disso, seus endereços IPv6 estão indo para fora de seus endereços MAC. Como o seu provedor está dando IPv6 e você já está assumindo vários endereços IPv6, isso vai lhe dar problemas, como no Linux, IPv6 por padrão tem precedência sobre o IPv4. Além disso, esse sangramento deixará rapidamente qualquer administrador de rede atender a sua falta. Um possível trabalho é desabilitar o IPv6 ao mesmo tempo em que você está atraindo endereços MAC.

Além disso, o nome da sua interface indica que você está usando um chipset baseado em realtek. Embora barato, sua qualidade é baixa, e eles são conhecidos por dar problemas de estabilidade de conexão. Certos modelos de ralink ou atheros são muito melhores para esse tipo de atividade. consulte problemas Wi-Fi relacionados usando o adaptador ASUS USB-N13

PS. Obviamente, não há bolas de cristal. É devido a um conjunto de pistas que destacam o tipo de atividades que o seu sistema está fazendo. Eu aconselho a tentar entender melhor quais são as conseqüências de usar utilitários menos bem comportados para fazer operações mais obscuras.