☰

우분투는 ARP 요청에 응답하지 않습니다

tag-icon • tag-icon debian networking ip network-interface arp
우분투는 ARP 요청에 응답하지 않습니다

내 Linux 박스에서 설명할 수 없는 동작이 발생하고 있습니다. 들어오는 ARP 요청이 표시되지만 내 컴퓨터가 응답하지 않습니다. 이더넷 케이블을 Windows 10 컴퓨터에 연결하면 이러한 ARP 요청에 응답합니다.

또한 대상을 nmap하려고 할 때 해당 장치의 트래픽을 캡처할 수 없다는 사실도 발견했습니다 192.168.1.106. 들어오는 ARP 요청은 표시되지만 나가는 패킷은 전혀 없습니다. 대상(및 인터페이스)을 전환하면 nmap에서 나가는 트래픽이 표시됩니다. 이것이 ARP 문제와 관련이 있는지 확실하지 않습니다. ARP 응답이 없는 경우 nmap 스캔이 어떻게 작동해야 하는지에 대한 아이디어가 있었습니다...

여러 인터페이스가 있는 Ubuntu 16.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

답변1

따라서 문제의 몇 가지 기술적인 측면을 해결해 보십시오.

가장 큰 기술적 문제는 두 개의 이더넷과 하나의 Wi-Fi 네트워크 인터페이스에 동일한 네트워크 블록이 있다는 것입니다. 이로 인해 라우팅이 엉망이 됩니다.

또한 Wi-Fi 인터페이스에서 MAC 주소 간을 너무 빠르게 전환하는 것 같습니다. 이로 인해 현재 연결이 방해를 받고 종료됩니다.

Wi-Fi가 인증되었으므로 새 MAC 주소를 스푸핑한 후에는 인터페이스를 중단하고(스푸핑 전) 다시 백업한 다음(스푸핑 후) 새 MAC 주소 확인 프로세스를 통해 모든 인증을 다시 수행해야 합니다. 그렇지 않으면 AP는 귀하의 인터페이스가 인증되었는지 모르기 때문에 귀하와의 거래를 중단합니다.

참고: 일부 장치/설정/브랜드에서는 이전 MAC이 사용되지 않도록(캐시, 기타) 동일한 새 MAC를 사용하여 잠시 기다리거나 프로세스를 몇 번 반복해야 합니다. 일부 드문 Wi-Fi 드라이버의 경우 드라이버가 Wi-Fi 브랜드를 식별하는 MAC 주소의 처음 3바이트를 변경하는 것을 좋아하지 않을 수 있으므로 하위 3바이트만 스푸핑할 수 있습니다.

또한 IPv6 주소가 MAC 주소 이상으로 유출되고 있습니다. 기본적으로 IPv6가 IPv4보다 우선하는 Linux에서와 마찬가지로 공급자가 IPv6을 제공하고 여러 IPv6 주소를 가정했기 때문에 이로 인해 문제가 발생할 수 있습니다. 게다가 이런 종류의 유혈 사태는 모든 네트워크 관리자에게 귀하가 나쁜 짓을 하고 있다는 사실을 금세 명백히 드러낼 것입니다. 가능한 해결 방법 중 하나는 MAC 주소를 스푸핑할 때 IPv6을 완전히 비활성화하는 것입니다.

또한 인터페이스 이름은 Realtek 기반 칩셋을 사용하고 있음을 나타냅니다. 저렴하지만 품질이 낮고 연결 안정성 문제를 일으키는 것으로 알려져 있습니다. Ralink 또는 atheros의 특정 모델은 이러한 유형의 활동에 더 적합합니다. 관련 보기ASUS USB-N13 어댑터를 사용한 Wi-Fi 문제

추신. 분명히 수정구슬은 없습니다. 이는 시스템이 수행하는 활동 유형을 나타내기 위해 함께 제공되는 일련의 단서 때문입니다. 더 모호한 작업을 수행하기 위해 성능이 낮은 유틸리티를 사용하는 경우의 결과를 더 잘 이해하려고 노력하는 것이 좋습니다.

관련 정보