quinta-feira, 29 de novembro de 2007

ARP e ARP Flux

O protocolo ARP (Address Resolution Protocol) é utilizado para mapear endereços IP-para-ethernet e é tão utilizado que é quase impossível encontrar redes que utilizem um outro mecanismo para mapear endereços IP-para-ethernet (por exemplo, o mapeamento estático).


Quando uma estação deseja enviar um pacote para outra estação ou gateway de uma rede, é necessário, além de conhecer o endereço IP de destino, saber qual é o endereço ethernet (MAC address) de destino. Neste momento o protocolo ARP é acionado para encontrar a partir de um endereço IP o endereço ethernet correspondente.

Se o host-192-168-0-9 deseja enviar um datagrama IP para o host-192-168-0-100 então é necessário primeiro conhecer o endereço ethernet (mac address), que no exemplo abaixo é "00:0e:35:50:xx:xx":

host-192-168-0-9:~ $ tcpdump -ni en1 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on en1, link-type EN10MB (Ethernet), capture size 96 bytes
00:28:34.090647 arp who-has 192.168.0.100 tell 192.168.0.9
00:28:34.094124 arp reply 192.168.0.100 is-at 00:0e:35:50:xx:xx

Até aqui tudo normal. 

Quando um host com linux instalado possui duas ou mais interfaces de rede conectadas a um mesmo segmento de rede, podem ocorrer problemas com o mapeamento entre os endereços de camada 2 (ethernet) e camada 3 (IP). Isso ocorre pois o host responderá uma requisição ARP pelas duas interfaces de rede. Este comportamento pode gerar confusão na tabela de ARP do host que disparou a requisição ARP. Este comportamento é chamado de ARP Flux. É importante ressaltar também que este comportamento somente irá ocorrer quando duas ou mais interfaces estiverem conectadas à um mesmo segmento de rede (mesmo domínio de broadcast).

Um exemplo de ARP Flux:

[root@real-client]# arping -I eth0 -c 3 10.10.20.67
ARPING 10.10.20.67 from 10.10.20.33 eth0
Unicast reply from 10.10.20.67 [00:80:C8:7E:71:D4]  11.298ms
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  12.077ms
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.542ms
Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.547ms
Sent 3 probes (1 broadcast(s))
Received 4 response(s)

Note que para um mesmo endereço IP há duas respostas com dois endereços ethernet distintos. Como não é possível saber qual das respostas será processada primeiro pelo host que disparou a requisição é possível que o endereço errado seja incluído na tabela ARP e a comunicação entre os dois hosts não aconteça.

Há basicamente quatro maneiras diferentes de resolver este problema. No kernel 2.4 pode-se utilizar a opção arp_filter do sysctl. Nos kernels 2.2 é necessário utilizar a opção hidden do systcl. Estas duas opções controlam a forma como são tratadas as requisições ARP por interface. 

As outras soluções envolvem a utilização do a ferramenta ip arp e a opção noarp route flag. A ferramenta ip arp e a filtragem do protocolo ARP está documentada aqui.

Como utilizar a opção arp_filter?

Basicamente a utilização da opção arp_filter (/proc/sys/net/ipv4/conf/$DEV/arp_filter) faz com que um host utilize a tabela de roteamento para encontrar por qual interface o mesmo deve encaminhar a resposta de uma requisição ARP, ao invés da opção padrão de encaminhar a resposta por TODAS as interfaces.

De modo geral, a utilização da opção arp_filter resolve o problema de ARP Flux e pode gerar problemas somente em cenários mais complexos onde é necessário controlar de forma mais detalhada as requisições e respostas do protocolo ARP.

Para alterar esta opção podemos utilizar "o bom e velho" echo, por exemplo, para a interface eth0:

user@host-192-168-0-9:~ $ echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter

Para mais informações sobre o protocolo ARP e o problema do ARP Flux, consultar este material (em inglês).

terça-feira, 6 de novembro de 2007

Check Point SPLAT Quick Tips

1) Overlapping Encryption Domains

Quando um servidor Smart Center Server (SCM) é utilizado para gerenciar mais de um firewall Check Point, podem existir problemas com a sobreposição do domínio da VPN (Encryption Domain ou enc dom). Neste caso é necessário definir manualmente o enc dom para que não haja esta sobreposição que poderá gerar problemas quando for utilizado o acesso remoto via Secure Client. Para verificar quais os gateways possuem sobreposição, devemos utilizar o comando (no SPLAT):

[Expert@smc-mgmt]# vpn overlap_encdom
The objects fw-01 and fw-02 have overlapping encryption domains.
The overlapping domain is:
10.10.0.0 - 10.10.255.255

Para mais detalhes consultar o sk32252.

2) Pen Drive USB no SPLAT

Para montar um pen drive no Check Point SecurePlatform utilizar o procedimento:

[Expert@fw]# mkdir /mnt/usb
[Expert@fw]# modprobe usb-storage
[Expert@fw]# mount -t vfat /dev/sdb1 /mnt/usb

Enjoy!