ARP

IP 주소는 아는데 MAC 주소를 모를 때 물어보는 프로토콜.

• 호스트 A 가 192.168.1.20 에 보내려 한다

• ① A: "192.168.1.20 인 사람 누구? MAC 알려줘" (브로드캐스트)

• ② B: "나야. 내 MAC 은 aa:bb:cc:..." (유니캐스트 응답)

• ③ A 가 ARP 테이블에 캐싱하고 프레임을 보낸다

왜 필요한가 — 계층이 다르다

• IP 주소 — 논리 주소. 어느 네트워크인지를 나타낸다 (3계층)

• MAC 주소 — 물리 주소. 실제로 프레임을 받을 장치를 지목한다 (2계층)

• 최종 목적지가 멀리 있어도, 당장 프레임을 넘길 '다음 장치' 의 MAC 이 필요하다

목적지가 다른 서브넷이면

호스트는 목적지가 같은 서브넷인지 먼저 판정한다 (마스크로 AND)

• 같다 — → 목적지 IP 로 ARP → 그 MAC 으로 직접 전송 다르다 → 게이트웨이 IP 로 ARP → 게이트웨이 MAC 으로 전송

  • (IP 헤더의 목적지는 최종 목적지 그대로, MAC 만 게이트웨이)

이 때문에 게이트웨이가 다른 서브넷에 있으면 ARP를 보낼 수 없어 외부 통신이 전면 불가해진다.

ARP 테이블

arp -a          # 캐시 확인
ip neigh        # 리눅스

항목은 일정 시간 후 만료된다 (보통 수십 초~수 분)
→ MAC 이 바뀌어도(장비 교체·페일오버) 결국 갱신된다

ARP 스푸핑

ARP 에는 인증이 없다 — 응답을 위조하면 트래픽을 가로챌 수 있다 "192.168.1.1 은 내 MAC 이야" 라고 거짓 응답 → 게이트웨이 행세

대응: 정적 ARP 항목, 스위치의 Dynamic ARP Inspection, 암호화(TLS)

면접 함정

• ❌ "ARP는 라우터를 넘어간다" → 브로드캐스트라 같은 세그먼트 안에서만이다.
• ❌ "목적지가 멀면 목적지 MAC을 ARP" → 게이트웨이 MAC을 구한다.

Gratuitous ARP

묻지도 않았는데 스스로 보내는 ARP

• "192.168.1.1 은 내 MAC 이야" 를 브로드캐스트

정상 용도

• IP 충돌 감지 (같은 IP 를 쓰는 장비가 있는지)
• 페일오버 시 새 장비가 트래픽을 넘겨받는다는 통지
  • (VRRP·keepalived 가 이걸 쓴다)

악용하면 ARP 스푸핑이 된다

왜 페일오버에 필요한가

액티브 장비가 죽고 스탠바이가 같은 가상 IP 를 이어받아도, 주변 장비의 ARP 캐시에는 여전히 옛 MAC 이 남아 있다

• 트래픽이 죽은 장비로 계속 간다

Gratuitous ARP 를 보내 캐시를 강제로 갱신시킨다

• 이걸 안 보내면 캐시 만료(수십 초~수 분) 까지 장애가 지속된다

진단

ip neigh                    # ARP 캐시
ip neigh flush all          # 캐시 비우기 (문제 재현·검증용)
tcpdump -i eth0 arp         # ARP 패킷 관찰

incomplete 상태가 보이면 상대가 응답하지 않는 것이다

• 상대가 꺼져 있거나, 다른 서브넷이거나, 방화벽이 막고 있다

IPv6에는 ARP가 없다

NDP(Neighbor Discovery Protocol) 가 대신한다 브로드캐스트가 아니라 '요청된 노드 멀티캐스트' 를 써서 관심 없는 호스트는 인터럽트조차 받지 않는다