Proxy ARP는 정상적인 NIC 설정에서도 영향을 주는가?

Proxy ARP 때문에 자다 일어난 썰

 

○ 발단 그리고 현상

      IPSec VPN 연결한 서비스에 이슈가 있어 방화벽 장비 벤더 교체 테스트를 수행하게 되었다.

      무사히 테스트를 마치고 자고 있는데 팀원한테 연락이 온다.

      특정 서버들이 생사 감시가 왔다 갔다 하면서 서비스도 조금 이상하단다.

○ Divide and Conquer

      Divide and Conquer 차례다.

      조사해보니 낮에 VPN mgmt 대역의 여러 대 중 3대만 그렇단다.

      다행히도 2대는 운영 종료 서비스가 있고 그나마 1대는 특정 사업소에서만 사용하는 서비스란다.

      일단 3대 모두 동일 네트워크 대역에 있었으며 IP가 낯이 익은 게....

      낮에 테스트 작업했던 VPN을 연결한 mgmt 대역이다.

      방화벽 config 이슈일 것 같았다.

○ IP 관리시스템에서 특이점

      해당 대역 IP의 미사용 IP의 ARP가 모두 하나의 mac으로 보이며 OUI는 낮에 mgmt 연결한 방화벽 벤더다.

      감이 온다.

○ 조치해보자

      방화벽 config를 보니 역시 mgmt 인터페이스에 proxyarp기능이 켜져 있었다.

      off 후 모든 게 정상이 되었다.

○ 누구의 문제인가?

      OS 측 : ifconfig 및 route -rn 정상 확인.

      NW 측 : 어.... NW 잘못임. 이건 뭐.. 맞음......

○ Proxy ARP는 정상적인 NIC 설정에서도 영향을 주는가?

      준다.

      다만 Gateway가 아닌 장비가 Proxy ARP 기능이 켜져 있을 때만 서비스 영향이 있을 것이다.

      만약 클라이언트가 서버 1(10.10.10.10)과 통신하고자 할 시점에 (파란색 라인)

      마침, 우연히도, 백본에서 서버 1에 대한 arp 정보가 없다면

      당연히 arp broadcast가 발생할 것이고 (초록색, 빨간색)

      서버 1은 당연히 자신의 IP이니 자신이 10.10.10.10을 가지고 있다고 응답하고

      방화벽은 Proxy ARP 기능 때문에 10.10.10.10을 가지고 있다고 응답할 터이니

      백본에서는 패킷을 방화벽으로 던져야 할지 서버로 던져야 할지 헷갈리게 될 것이다.

      따라서 서비스에도 영향을 줄 수 있는 상황이 발생한다.

 

 

○ 결론

      GW를 가지지 아니한 장비를 기존 네트워크에 연결할 때 Proxy ARP를 꼭 다시 보자.

      Cisco 장비 Catalyst, Nexus, ASA는 거의 default enable이다.