Pagina Principal ARTIGOS Network SRX Chassis Cluster with Redundant LACP LAG trunk

Proxy-Arp - O que é e como funciona

topologia-proxy-arp

O Proxy ARP é uma variação do ARP. Ele possibilita que uma organização possua somente um endereço IP para suas diversas redes.

 

Nesse caso, todas as redes estão conectadas a um router. Quando um host quiser se comunicar com um host de outra rede (sem saber seu endereço MAC), ele irá despejar um pacote com o número IP do host destino. Mas nesse caso o pacote é interceptado primeiramente pelo router, que retorna ao host destino seu próprio endereço MAC. A informação subseqüente será então orientada para o router, que a redirecionará para o host destino, de acordo com a sua própria tabela de endereços.

 

 

 

O Proxy-arp é um método onde um determinado host, que pode ser um router ou firewall por exemplo, responde um arp request em nome de outro host. Este protocolo (RFC-1027 http://www.ietf.org/rfc/rfc1027.txt) foi desenvolvido no final dos anos 80 pelo Departamento de Ciências da Computação da Universidade do Texas em Austin por necessidade deste em segmentar sua rede de computadores. Porém, naquela época, nem todos os devices de rede podiam ter seus endereços de redes subnetados, ou seja, um endereço classe A não poderia ser dividido em duas, três, doze, etc ... redes diferentes pois o dispositivo somente reconhecia a classe de seu IP.


Com o método de Proxy-ARP, foi possível que com um endereço de classe A configurado em diversos hosts com máscara padrão para esta classe fossem segmentados por routers ou firewalls que tivessem o método de Proxy-ARP implementado. Como exemplo de seu funcionamento, temos a topologia abaixo, onde o device Router possui o proxy-arp habilitado com o comando “ip proxy arp” na interface Ethernet0. Este comando é habilitado por default em devices Cisco, e é recomendado que esteja sempre desabilitado caso seu uso não seja necessário.

http://i479.photobucket.com/albums/r.../topologia.gif

O host A (172.16.10.100) na subnet A quer enviar pacotes para o host D (172.16.20.200) na subnet B. Como mostrado no diagrama, o host A possui máscara de rede classe B (255.255.0.0). Isso significa que o host A acredita estar em uma rede diretamente conectada com toda rede 172.16.0.0/16. Quando o host A necessita se comunicar com qualquer device que acredita estar diretamente conectado, ele envia um ARP request (o famoso pacote "Who has IP_x.x.x.x ? Tell to x.x.x.x).


Porém, como um arp request é um pacote broadcast, e por default routers não propagam broadcast, este request nunca chegará ao host D. Porém, como o device Router conhece a subnet onde o host D está, o Router em si irá responder o arp-request enviado para o IP 172.16.20.200, como sendo o mac-address 00-00-0c-94-36-ab, e todos os pacotes enviados do host A para o host D terão o fluxo host_A->Router->host_D. Porém, tudo isso será transparente para o host A e host D.


  • Host A necessita enviar um pacote para o host D;
  • Host A envia um arp-request querendo saber o mac-address do host D 172.16.20.200
  • Router recebe o arp-request, e o responde que o IP 172.16.20.200 possui o mac-address 00-00-0c-94-36-ab;
  • Host A envia um pacote para o mac-address 00-00-0c-94-36-ab;
  • Router recebe o pacote e encaminha ao host D;
  • Host D recebe o pacote com o campo origem IP 172.16.10.100, mac-address 00-00-0c-94-36-cd;
  • Como o host D conhece o conceito de subnet e sabe que o host A está em outra subnet, este envia a resposta para o IP 172.16.10.100 ao seu default-gateway 172.16.20.99;
  • Router encaminha o pacote ao host A como origem 172.16.20.200, mac-address 00-00-0c-94-36-ab.




Bem, tudo isso é muito confuso a parece não ser muito necessário nos dias de hoje. Porém há ainda muitas redes onde utilizam sistemas legados ou falsos dispositivos que são vendidos como “TCP/IP enabled” como catracas eletrônicas, relógios de ponto, PLCs entre outros, e nesses casos a utilização de proxy arp se faz necessário. Mas a utlização de tal método possui mais desvantagens do que vantagens. Entre as desvantagens podemos citar o aumento de tráfego ARP em determinado segmento de rede, podendo até mesmo causar issues de high cpu nos routers. Outra desvantagem é que os computadores que não tem configuração de subnet necessitarão de grandes tabelas ARP. Um outro ponto é a segurança, uma vez que em um cenário desses fica fácil a utilização da técnica em spoofing.


No exemplo de debug abaixo, foi utilizado a topologia acima com os mesmos Ips. O primeiro comando ping à partir do HOST_A foi dado com o proxy-arp desabilitado no device ROUTER. Notem que o ROUTER recebe os ARP Request, porém não envia nenhuma resposta. No segundo ping, o proxy-arp está habilitado na interface diretamente conectada ao HOST_A. o ROUTER envia o arp reply logo em seguida que recebe o arp request do HOST_A.


[ROUTER]
ROUTER(config)#int f1/0
ROUTER(config-if)#no ip proxy-arp
*Feb 13 22:36:04.719: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:24.227: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:26.287: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:28.287: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:30.291: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:32.295: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0

ROUTER(config-if)#ip proxy-arp
*Feb 13 22:36:57.791: IP ARP: rcvd req src 172.16.10.100 c801.1f95.0010, dst 172.16.20.200 FastEthernet1/0
*Feb 13 22:36:57.795: IP ARP: sent rep src 172.16.20.200 ca02.1f95.001c, dst 172.16.10.100 c801.1f95.0010 FastEthernet1/0

[HOST_A]
HOST_A#ping 172.16.20.200

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.200, timeout is 2 seconds:

*Mar 1 00:26:02.855: IP ARP: creating incomplete entry for IP address: 172.16.20.200 interface FastEthernet1/0
*Mar 1 00:26:02.859: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:04.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:06.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:08.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
*Mar 1 00:26:10.855: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0.
Success rate is 0 percent (0/5)

HOST_A#ping 172.16.20.200

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.20.200, timeout is 2 seconds:

*Mar 1 00:26:36.419: IP ARP: sent req src 172.16.10.100 c801.1f95.0010,
dst 172.16.20.200 0000.0000.0000 FastEthernet1/0
*Mar 1 00:26:36.475: IP ARP: rcvd rep src 172.16.20.200 ca02.1f95.001c, dst 172.16.10.100 FastEthernet1/0.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 56/163/200 ms

 

Fontes:

http://pt.wikipedia.org/wiki/Proxy_arp

https://under-linux.org/entry.php?b=546

.