TP-Link System Log에서 발견한 ARP Conflict 문제 해결기

연구실에 온프레미스를 운영하다보면 여러 특이한 상황들을 마주하게 된다.

 

 

연구실에서는 Raspberry Pi에 S3를 오픈소스로 구축하여 운영 중인데, 어느날 갑자기 동작하지 않았다.

 

이유가 무엇인지를 몰랐으나, log를 보다보니 찾을 수 있었던 것을 기록해보고자 한다.

 

 

tp-link의 System Log에서 발견한 에러

 

 

처음 봤을 때는 ARP attack packets이라고 보여서, 외부 공격이라 생각하고 급한 대로 전원을 내렸다.

 

생각해보니, ARP(Address Resolution Protocol)은 같은 LAN 내부에서 IP 주소와 MAC 주소를 대응시키는 프로토콜이므로

인터넷 외부에서 직접 들어온 공격이 아닌, LAN 내부의 문제겠구나라고 생각하게 되었다.

 

 

즉, 어딘가 MAC 주소와 관련된 오탐 가능성을 의심했다.

 

 

먼저 확인한 것은 TP-Link 기준 "Network - LAN"의 Address Reservation을 확인했다.

 

연구실에서는 각 장비의 MAC 주소를 기준으로 IP 주소를 고정 할당하여 관리하고 있었기 때문이다.

 

MAC 주소 끝자리에 주목

 

 

그러면서, 앞선 로그에서 Firewall 쪽에서 오류가 감지되고 있었으니 무엇이 문제일까 하고

Firewall - Anti ARP Spoofing - IP-MAC Binding 탭으로 가서 해당 라즈베리파이의 MAC 주소를 따라가 보았는데,

 

마지막 자리가 다르다.

 

마지막 MAC Address가 잘못 설정되어있는 것이었다.

 

RPi에서 MAC Address를 직접 확인해본 결과는 다음과 같았다.

참고로 "device interrupt 117" 은 오류 코드가 아니라 eth0 에 할당된 IRQ 번호이며, 이번 문제와는 관계가 없었다.

 

 

또한, (다행히도) 온프레미스에서 운영중인 모든 RPi에 대하여 MAC Address에 대한 정보들을 문서화 하였기에 금방 찾을 수 있었다.

 

 

왜 이런 상황이 발생했는지도 중요하다.

 

이런 상황이 발생한 이유는 다음과 같이 정리가 되었다.

 

1. 최근 네트워크 공유기에 문제가 생겨서 공유기를 Shut-Down 진행하였음.

2. 이와 함께 S3 자체도 접속이 안되는 문제가 발생

 

3. (추정) 과거 S3 서버를 설정하는 과정에서 WLAN을 사용한 적이 있었음.

- 당시 wlan0의 MAC 주소가 Firewall의 IP-MAC Binding에 등록되었을 가능성이 있음

- 이후 현재는 Ethernet(eth0)을 통해 통신하고 있었기 때문에 실제 패킷의 MAC 주소와 Firewall에 등록된 MAC 주소가 달랐던 것

- TP-Link의 Anti ARP Spoofing 정책이 이를 비정상 트래픽으로 판단한 것으로 추정

 

4. 정상적으로 MAC 주소를 업데이트하니 접속이 가능해짐

 

이렇게 정리해볼 수 있을 것 같다.

 

 

 

이번 장애를 통해 얻은 결론은,

 

• DHCP Address Reservation과 Firewall의 IP-MAC Binding은 서로 목적이 다른 별개의 설정이라는 것
• Firewall의 IP-MAC Binding 정보가 실제 장비가 사용하는 IP/MAC 정보와 일치하지 않으면
  정상 장치의 트래픽도 ARP Spoofing 방어 정책에 의해 차단될 수 있다는 것
• 장비의 IP, MAC, 인터페이스 정보를 문서화해 둔 덕분에 실제 값과 설정값을 빠르게 비교할 수 있었다는 것

 

 

 

앞으로 연구실 온프레미스 환경을 다루며 발생했던 일들을 꼼꼼히 기록해보겠다.

 

 

 

 

긴글 읽어주셔서 감사합니다.