Proxy ARP

Proxy 라는 용어는 네트웍에서 자주 사용되는 단어이다.

대표적으로 Proxy Server 등을 들수 있는데 가장 먼저 Proxy 라는 단어의 의미부터 명확히 짚고갈 필요가 있다.

Proxy 의 사전적 의미는 '대리(인)' 이다.

즉, 남을 대신해 자신이 대신 수행해 준다는 의미인데

라우터는 Host 에서 보내온 ARP Request 를 보고 목적지 IP가 자기 자신이 아니더라도 자신이 도달 가능한 경로라고 판단할 경우(라우팅 테이블에 등록되어있는 목적지) 자신의 MAC 주소로 대신 응답해 주는 기능이다.

 

실제 상용망에 있었던 사례를 살펴보자.

 

위의 구성과 완전히 동일하지는 않았으나 대략 비슷하다.

여기서 주의깊게 봐야 할 부분은 PC1에서 GW의 IP를 R1의 IP로 오설정 한 부분이다.

실제 망에서도 이와같이 GW IP가 잘못 설정된 상태로 몇년을 정상적으로 운영중이였으며, 우연한 기회에 발견하였다.

GW IP 설정이 잘못되었는데 어떻게 그동안 운영이 가능했을까!!!

 

바로 R2의 Fa0/1 인터페이스에 Proxy ARP 기능이 enable 되어있었기 때문이다.
※ Cisco 모델은 모든 인터페이스에 Proxy ARP 기능이 디폴트로 enable 되어있음

 

PC1 에서 외부 네트웍과 통신하기 위해 GW IP로 ARP Request를 브로드캐스트 전송하면 R2는 이 패킷을 수신하는데, 비록 목적지 IP가 자신이 아니지만 내가 도달할 수 있는 경로이므로 나에게 보내줘도 된다는 의미로 자신의 MAC 주소 (Fa0/1 인터페이스 MAC 주소)로 ARP Response 응답한다.

당연한 얘기지만 R2에서 10.1.1.1 경로에 대해 라우팅 테이블에 등록되어 있지 않다면 Proxy ARP 가 동작하지 않는다.

 

테스트 환경은 Packet Tracer 6.0 을 사용했는데 GNS3에서는 Host의 GW를 아예 다른 네트웍으로 선언이 불가하므로 Packet Tracer를 선택했으며, Packet Tracer에서도 Proxy ARP 기능은 정상 동작하므로 테스트에 문제없다.

 

우선 R2 fa0/1 MAC Address를 확인하자.

 

PC1에서 그림과 같이 IP/GW 설정을 한 후 PC0으로 ping 테스트를 시도하면 이상없이 잘된다.

그리고, R2가 자신의 MAC 주소로 대신 응답해준 것을 arp 테이블로 확인 가능하다.

 

이번에는 R2의 f0/1 인터페이스에서 no proxy arp로 Proxy ARP를 disable 하고 PC1에서 다시 ping 10.1.1.10을 해보자.

(그전에 PC1에서 arp -d 로 arp 테이블을 clear 시켜야 한다.) 당연히 ping 은 안된다.

 

두번째는 스태틱 라우팅과 Proxy ARP 관계를 알아보자~

테스트 구성도는 아래 그림과 같다.

이 테스트에서 중요한 부분은 R1에서 R2의 10.1.1.1로 ping이 갈 수 있도록 R1에서 static route를 지정해 주는데 이때 next hop을 자신의 output 인터페이스로 지정한다. 

(output 인터페이스가 아닌 상대방 인터페이스 IP를 지정할 경우 Proxy ARP는 발생하지 않음)

 

R1에서 ping 10.1.1.1 을 하면 정상적으로 성공한다.

R1에서 arp 테이블을 확인하면 10.1.1.1에 대해 R2 f0/0 인터페이스의 MAC 주소로 등록되어 있다.

즉, R1에서 목적지 10.1.1.1에 대한 ARP Request 패킷을 송신하면, R2에서는 자신이 10.1.1.1에 도달할 수 있다고 판단하고, 자기 자신의 MAC 주소로 대신 응답해 준 것이다. 

 

이번에도 당연한 얘기지만 R2의 f0/0 인터페이스에서 Proxy ARP를 disable 시키면 R1에서 10.1.1.1로 ping이 실패한다.

즉, 스태틱 라우팅을 사용할 경우에는 Proxy ARP 기능을 disable 되어있으면 절대 안된다는 의미이다!

 

이번에는 조금 다른 테스트를 해보자.

웹에서 Proxy ARP 를 검색하여 찾아보면 이런 설명이 되어있다.

"Proxy ARP를 사용하면 Host에서 GW IP를 설정하지 않더라도 외부 네트웍과 통신이 이루어진다."

과연 이 말이 맞는 말일까?

 

결론부터 얘기하자면 위의 설명은 잘못 되었으나 100% 틀린 말은 아니다!

아래 구성도를 보자. 

 

Host A에 GW IP가 설정되어 있지 않은 상태에서 ping 2.2.2.10 을 입력하면 어떻게 되는가?

목적지 IP가 자신의 네트웍 대역과 틀리므로 GW에게 ARP Request 를 던져야 하는데 GW IP가

설정되어 있지 않기때문에 ARP Request 패킷을 생성할 수가 없다.

 

즉, ARP Request 패킷이 라우터에게 도달할 수 없으며, OS 커널단에서 바로 Drop 된다.

그리고 Host A는 Destination host unreachable 라는 ICMP 메시지를 화면에 던져준다.

 

여기서 키 포인트는 ARP Request 패킷이 라우터까지 도달 할수 있느냐 없느냐의 유무이다.

다시말해 동일한 구성에서 강제로라도 ARP Request 가 라우터까지 갈 수 있다면 라우터의 Proxy ARP 기능을 이용하여 외부 네트웍과 통신이 가능하다는 말이다.

위의 구성도에서 Host A의 서브넷 정보만 수정된 구성도를 다시 보자. 

 

Host A의 서브넷마스크가 라우터와 동일하지가 않다. 상용망에서는 일반적으로 이와같이 구성하는 일은 없으나 테스트를 위해 일단 보자.

 

이 구성도에서는 Host A에서 ping 1.1.2.10 이 성공한다.

Host A의 서브넷마스크는 16bit 이므로 목적지 1.1.2.10 에 대해서도 같은 네트웍이라고 판단한다.

따라서 ARP Request 를 Broadcast 하고 이를 수신한 라우터는 자신의 MAC 주소로 응답을 해주게 된다.

이렇게 강제로 ARP Request 를 라우터까지 도달하게 하여 통신을 할 수는 있지만 일반적인 구성이 아니므로 그냥 참고만 하자.