ARP 테이블 (IP 충돌, ARP 스푸핑, 네트워크 진단)

ARP 테이블 분석:** IP와 MAC 주소 매칭 오류 해결 방법

네트워크 담당자라면 한 번쯤 겪어봤을 상황이 있습니다. 특정 PC만 유독 간헐적으로 인터넷이 끊기고, 재부팅하면 잠깐 되다가 또 끊기는 그 상황입니다. 저도 사무실에서 정확히 이런 일을 겪었습니다. 처음엔 NIC 불량이나 케이블 접촉 불량을 의심했고, 케이블을 교체하고 NIC 드라이버도 재설치했지만 증상은 재현됐습니다. 결국 진짜 원인은 ARP 테이블 안에 숨어 있었습니다. 그때 솔직히 느낀 것은, 하드웨어 문제를 먼저 의심하는 관성이 얼마나 시간을 낭비하게 만드는지였습니다.

IP 충돌이 만들어내는 ARP 테이블의 이상 징후

일반적으로 네트워크 문제가 생기면 케이블이나 공유기부터 확인한다고 알려져 있지만, 제 경험상 ARP 테이블을 먼저 들여다보는 것이 훨씬 빠른 경우가 많습니다. 물론 이걸 처음부터 알았던 것은 아니었습니다. 케이블, 드라이버, 공유기를 모두 점검한 뒤에야 "혹시 ARP가 문제일까?"라는 생각이 떠올랐습니다. 이 순서가 뒤집혔다면 훨씬 빨리 해결할 수 있었을 것입니다.

ARP(Address Resolution Protocol)란 IP 주소를 물리적 주소인 MAC 주소로 변환해주는 프로토콜입니다. 쉽게 말해, 같은 네트워크 안에서 "이 IP를 가진 장치가 어디 있냐?"고 물어보고 답을 받아 주소록에 기록해두는 과정입니다. 이 주소록이 바로 ARP 테이블이고, arp -a 명령어 하나로 현재 상태를 바로 조회할 수 있습니다.

별 기대 없이 arp -a를 쳐봤는데, 동일한 IP에 서로 다른 MAC 주소 두 개가 매핑되어 있는 것을 발견했습니다. 이게 바로 IP 충돌(IP Conflict) 상황의 전형적인 흔적입니다. IP 충돌이란 동일한 IP 주소를 두 개 이상의 장치가 동시에 사용하면서 서로의 통신을 방해하는 현상으로, 이 경우 패킷이 어느 장치로 가야 할지 결정하지 못하면서 통신이 불규칙하게 끊기게 됩니다. "이게 설마 이것 때문이었어?"라는 생각이 들 정도로 어이없이 단순한 원인이었습니다.

원인을 더 파고들기 위해 Wireshark로 패킷을 캡처했습니다. ARP 필터를 걸고 트래픽을 살펴보니, 두 호스트가 동시에 동일 IP에 대한 ARP Reply를 보내고 있었습니다. ARP Reply란 "이 IP는 내 것이고, 내 MAC 주소는 이것"이라고 응답하는 패킷입니다. 두 장치가 동시에 자신이 주인이라고 주장하니 네트워크가 혼란스러워질 수밖에 없었습니다.

원인은 DHCP 서버 설정 오류였습니다. DHCP 서버가 동일한 IP를 두 장치에 이중 할당한 것이었습니다. 이 부분이 개인적으로 답답했던 지점입니다. DHCP 서버가 중복 할당을 방지하는 메커니즘을 제대로 갖추고 있어야 함에도 불구하고, 설정 실수 하나로 이런 일이 생긴다는 사실이 프로토콜과 구현체 사이의 간극을 실감하게 해줬습니다. 해결 과정은 다음과 같았습니다. DHCP 서버의 주소 풀(Address Pool) 범위를 재조정하여 중복 할당 구간을 제거했고, 충돌 장치 중 하나에 고정 IP(Static IP)를 수동으로 부여했습니다. 그리고 arp -d * 명령어로 ARP 캐시 전체를 초기화했습니다.

arp -d *를 실행한 순간 문제가 즉시 해소됐습니다. 솔직히 이건 예상 밖이었습니다. 캐시를 지운다는 게 이렇게 즉각적인 효과를 낼 줄은 몰랐거든요. 동시에 "왜 이렇게 간단한 명령어를 나는 제일 나중에 써봤지?"라는 자책도 함께 들었습니다.

이때 Gratuitous ARP라는 개념도 처음 실습하게 됐습니다. Gratuitous ARP란 자신의 IP와 MAC 주소를 스스로 브로드캐스트하여 네트워크에 공지하는 패킷입니다. 장치가 네트워크에 처음 연결될 때 이 패킷을 보내는데, 만약 같은 IP를 가진 다른 장치가 이미 있다면 충돌 신호를 감지할 수 있습니다. 즉, Gratuitous ARP를 모니터링하면 IP 충돌을 사전에 탐지하는 조기 경보 시스템으로 활용할 수 있다는 것을 이때 몸으로 배웠습니다. 이 개념을 미리 알았더라면 최초 진단 시간을 훨씬 줄일 수 있었을 것입니다. 이후로는 새 장치를 네트워크에 추가할 때 Gratuitous ARP 모니터링을 루틴으로 넣는 습관이 생겼습니다.

ARP 스푸핑과 프로토콜의 구조적 취약점

IP 충돌 문제를 해결하고 나서 ARP 프로토콜 자체에 대해 다시 생각하게 됐습니다. 일반적으로 내부망은 외부 공격보다 안전하다고 알려져 있지만, ARP의 구조를 들여다보면 그렇게 낙관할 수만은 없습니다. 오히려 내부망이기 때문에 더 위험할 수 있다는 역설이 있습니다.

ARP는 1982년 RFC 826으로 표준화된 프로토콜입니다. 제정 당시 설계 철학은 단순함과 효율성이었습니다. 덕분에 별도의 인증 메커니즘 없이 누구든 ARP Reply를 보내면 상대방의 ARP 테이블이 덮어써지는 구조가 됩니다. 당시에는 내부망 보안 위협을 크게 상정하지 않았기 때문에 이 설계가 큰 문제가 되지 않았습니다. 하지만 저는 이 부분에서 개인적으로 비판적인 시각을 갖게 됐습니다. 40년이 넘은 프로토콜 설계가 그대로 유지되고 있다는 사실 자체가 네트워크 업계의 하위 호환성 집착이 보안보다 얼마나 앞서는지를 보여주는 사례입니다. 인증 없이 누구나 덮어쓸 수 있는 구조는, 현재 기준으로 보면 설계 결함에 가깝습니다.

ARP 스푸핑(ARP Spoofing)이란 공격자가 위조된 ARP Reply를 지속적으로 전송하여 피해자의 ARP 테이블에 잘못된 MAC 주소를 심는 공격 방식입니다. 이를 통해 같은 네트워크에 연결된 두 장치 사이의 트래픽을 공격자가 중간에서 가로채는 MITM(Man-In-The-Middle) 공격, 즉 중간자 공격으로 이어집니다. 특히 사무실이나 카페처럼 여러 사람이 같은 네트워크에 연결된 환경에서 이 공격은 매우 현실적인 위협입니다. 카페 와이파이를 아무 생각 없이 쓰는 사람들이 얼마나 많은지 생각하면 섬뜩해지는 부분입니다.

Wireshark만 있어도 ARP 스푸핑 징후를 어렵지 않게 확인할 수 있습니다. ARP 필터로 캡처하다 보면 특정 MAC 주소에서 비정상적으로 많은 ARP Reply가 쏟아지는 패턴이 눈에 띕니다. 이걸 처음 봤을 때 "이게 공격이구나"가 아니라 "뭔가 이상하다"는 감으로 먼저 알아챘다는 게 솔직한 경험담입니다. 보안 지식이 부족하더라도 "이 패턴은 뭔가 정상이 아니다"라는 감을 키우는 것이 실무에서는 더 중요하다는 생각을 이때 처음 했습니다.

보완책이 아예 없는 것은 아닙니다. Cisco 스위치 환경에서는 DAI(Dynamic ARP Inspection)를 적용할 수 있습니다. DAI란 스위치가 DHCP 스누핑 바인딩 테이블을 기준으로 ARP 패킷의 유효성을 검사하여 위조된 패킷을 차단하는 기능입니다. 802.1X 인증 역시 포트 단위로 접근을 제어하는 강력한 방법입니다.

다만 제 경험상 이건 좀 다릅니다. 레거시 장비가 섞인 실제 환경에서 DAI나 802.1X를 전면 적용하기란 생각보다 훨씬 복잡합니다. 구형 NIC나 오래된 프린터처럼 표준을 제대로 따르지 않는 장비들이 반드시 문제를 일으킵니다. 저도 802.1X 도입을 시도했다가 구형 복합기가 인증을 통과하지 못해 결국 해당 포트만 예외 처리를 해야 했습니다. 그 예외가 쌓이기 시작하면 결국 보안 정책 자체가 구멍이 뚫립니다. 프로토콜의 단순함이 곧 취약점이 되는 현실이 여기서도 드러납니다. 이상적인 설계와 현실 운영 사이의 간극이 이만큼 크다는 점을, 직접 부딪혀보기 전에는 잘 모릅니다.

마치며

ARP 테이블은 단순한 주소 매핑 기록이 아닙니다. 네트워크에서 뭔가 이상하다 싶으면 가장 먼저 열어봐야 하는 진단 창구입니다. 케이블을 뽑았다 꽂기 전에, 재부팅 버튼 누르기 전에, arp -a 한 줄 먼저 실행해보십시오. 문제의 윤곽이 생각보다 빨리 보입니다. 더 나아가 Wireshark로 ARP 패킷을 직접 캡처해보는 경험을 한 번이라도 해두면, 네트워크 문제를 바라보는 시각 자체가 달라집니다. 그리고 ARP의 구조적 취약점을 이해하고 나면, 내부망 보안에 대한 경각심도 자연스럽게 높아집니다. 저는 이 경험이 "보안은 경계 밖에서만 오는 게 아니다"라는 감각을 처음으로 갖게 해준 계기였습니다.

---

출처 및 참고 자료

• RFC 826. (1982). An Ethernet Address Resolution Protocol. IETF. https://www.rfc-editor.org/rfc/rfc826
• Cisco. (2024). Dynamic ARP Inspection Configuration Guide. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x\_3560x/software/release/15-0\_2\_se/configuration/guide/3750xscg/swdynarp.html
• Microsoft. (2024). Arp command documentation. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp
• NetworkLessons.com. (2024). ARP (Address Resolution Protocol) Explained. https://networklessons.com/cisco/ccna-routing-switching/arp-address-resolution-protocol
• Cheswick, W., Bellovin, S., & Rubin, A. (2003). Firewalls and Internet Security. Addison-Wesley.
• ARPwatch Tool. https://ee.lbl.gov/
• IEEE 802.1Q — Virtual LANs Standard. https://www.ieee802.org/1/pages/802.1Q.html