Configurar e validar RIP na Sophos Firewall

O RIP distribui automaticamente rotas IPv4 entre routers. Na Sophos Firewall, o protocolo é indicado sobretudo para domínios de routing pequenos ou existentes, nos quais poucos routers precisam de trocar redes sem uma seleção de caminho complexa.

O procedimento curto e seguro é o seguinte:

1. Documentar a rede de trânsito, as LAN locais, o peer, os prefixos esperados e o caminho de retorno.
2. Preparar um backup da configuração e um acesso de gestão independente.
3. Testar a acessibilidade IP direta entre os endereços de trânsito.
4. Em Administration > Device access, permitir Dynamic Routing apenas para a zona do peer ou através de uma exceção restrita.
5. Em Routing > RIP, selecionar RIPv2 e, inicialmente, manter os timers globais inalterados.
6. Adicionar a rede de trânsito e as LAN locais em RIP Networks.
7. Definir as interfaces LAN como Passive mode através de Override interface configuration.
8. Alinhar com o peer a versão e a autenticação da interface de trânsito.
9. Em Routing > Information > RIP, verificar o estado e as rotas aprendidas.
10. Testar Route Lookup, Firewall Rule ID e um serviço bidirecional real.

⚠️ Default information originate e a redistribuição de Connected, Static, OSPF ou BGP permanecem desativados até serem conhecidos todos os prefixos anunciados e os respetivos caminhos de retorno. Uma redistribuição ampla pode propagar inesperadamente rotas de gestão, trânsito, blackhole ou outras rotas internas por todo o domínio RIP.

Este procedimento aborda RIPv2 para IPv4 em Gateway Mode. O RIPv1 é referido apenas como um caso de interoperabilidade legacy. A Sophos Firewall não suporta RIP em Transparent Mode.

Quando o RIP é adequado e quando não é

O RIP é um protocolo de vetor de distância. Avalia um caminho pelo número de saltos entre routers. É preferida uma rota com uma métrica inferior. São alcançáveis no máximo 15 saltos; a métrica 16 significa que o destino está inacessível.

Este modelo simples é vantajoso quando:

• estão envolvidos apenas alguns routers,
• a topologia é pequena e amplamente estável,
• um peer existente suporta apenas RIP,
• a manutenção automática das rotas é mais importante do que uma convergência rápida e uma política complexa.

Para um único caminho fixo, uma rota estática é frequentemente mais simples. Com vários caminhos redundantes, convergência rápida ou redes internas maiores, o OSPF é normalmente o protocolo mais adequado. O BGP pertence a designs com sistemas autónomos, operadores ou uma política de routing deliberada.

O RIP não substitui uma regra de firewall nem monitoriza a qualidade das aplicações. Uma rota SD-WAN é a camada adequada para selecionar por origem, serviço, aplicação, latência, jitter ou perda de pacotes.

Distinguir RIPv1 de RIPv2

Para novas configurações utiliza-se RIPv2. Este protocolo transporta máscaras de sub-rede e suporta autenticação. O RIPv1 é classful, não transporta máscaras de sub-rede e não suporta autenticação na Sophos Firewall.

O SFOS oferece, entre outras, estas opções globais:

• Send V2 and receive both: enviar RIPv2 e receber RIPv1 e RIPv2
• V1: enviar e receber RIPv1
• V2: enviar e receber RIPv2

No exemplo, ambos os peers utilizam RIPv2. Send V2 and receive both pode facilitar uma transição controlada, mas alarga os dados de entrada aceites. Assim que todos os peers utilizarem RIPv2, tanto o envio como a receção são limitados a V2.

Compreender RIP Networks e Passive Mode

Uma RIP Network não é a rede de destino remota. A entrada ativa RIP nas interfaces locais cujo endereço IP corresponde à rede indicada. Desta forma, a rede diretamente ligada entra no processo RIP e pode ser anunciada.

No exemplo, são introduzidas na Firewall A tanto a rede de trânsito 198.51.100.0/30 como a LAN local 10.10.10.0/24:

• A rede de trânsito ativa RIP na interface voltada para o peer.
• A LAN é anunciada como uma rede local alcançável.
• Passive mode na interface LAN impede a firewall de enviar atualizações RIP nessa rede.

Passive Mode não remove a LAN do processo de routing. Apenas impede o envio de anúncios RIP através dessa interface. Além disso, Dynamic Routing permanece desativado na zona de clientes, para que estes não possam enviar atualizações de routing à firewall.

A Default metric global é a métrica inicial das rotas redistribuídas. O valor predefinido é 1. Administrative distance decide entre fontes de routing concorrentes; a Sophos utiliza por predefinição 120 para RIP. Estes valores não são alterados sem um motivo documentado.

Os timers predefinidos são:

• Update: 30 segundos
• Timeout: 180 segundos
• Garbage: 120 segundos

Os timers são coordenados em todos os peers. Valores reduzidos de forma agressiva podem fazer com que as rotas sejam desnecessariamente removidas e reaprendidas durante perdas de pacotes ou carga elevada.

Planear a topologia de exemplo

O exemplo contínuo liga duas LAN:

• Firewall A: IP de trânsito 198.51.100.1/30, LAN local 10.10.10.0/24
• Router ou Firewall B: IP de trânsito 198.51.100.2/30, LAN local 10.20.20.0/24
• Rede de trânsito: 198.51.100.0/30
• Cliente de teste A: 10.10.10.10
• Servidor de teste B: 10.20.20.10

198.51.100.0/24 está reservada para documentação. Num ambiente real, os endereços de trânsito, as interfaces, as zonas e os prefixos LAN são substituídos em conjunto. Os dois IP de trânsito têm de estar diretamente acessíveis.

A Firewall A deve aprender 10.20.20.0/24 através de 198.51.100.2. O peer deve aprender 10.10.10.0/24 através de 198.51.100.1. Apenas este caminho de ida e retorno permite tráfego encaminhado sem source NAT.

Antes da alteração, documentam-se a interface, a zona, as rotas existentes, Route Precedence, a métrica esperada e um host de teste acessível. Um backup da configuração atual e um caminho de gestão independente do novo routing facilitam a recuperação.

Permitir Dynamic Routing de forma restrita

Em Administration > Device access, Dynamic Routing está desativado por predefinição para todas as zonas. No exemplo, é permitido apenas na zona da interface de trânsito.

A matriz de Device Access aplica-se a toda a zona. Se outras interfaces não fidedignas partilharem essa zona, é preferível uma Local Service ACL Exception restrita para a rede de trânsito e o peer previsto. Device Access e Local Service ACL explica esta separação.

Esta permissão diz respeito a pacotes RIP destinados à firewall. O fluxo de dados entre 10.10.10.0/24 e 10.20.20.0/24 continua a precisar de regras de firewall normais. Dynamic Routing não é ativado na zona LAN apenas porque a LAN é anunciada como RIP Network.

Configurar RIPv2 no WebAdmin

A configuração é espelhada em ambos os peers. Apenas o IP de trânsito e a LAN local são diferentes.

1. Definir os valores globais

Abrir as definições globais em Routing > RIP:

1. Definir RIP version como V2.
2. Manter Default metric no valor predefinido existente 1.
3. Manter Administrative distance no valor predefinido existente 120.
4. Manter inicialmente Update, Timeout e Garbage em 30, 180 e 120 segundos.
5. Manter Default information originate desativado.
6. Não ativar qualquer redistribuição.
7. Guardar as alterações.

Default information originate anuncia uma rota predefinida no domínio RIP. Só é adequado quando esta firewall deve servir deliberadamente de saída para todos os destinos desconhecidos e foram planeados tanto o caminho de retorno como o cenário de falha.

2. Adicionar RIP Networks

Em Routing > RIP > RIP Networks > Add, introduzir estas redes locais na Firewall A:

1. 198.51.100.0 com a máscara de sub-rede 255.255.255.252
2. 10.10.10.0 com a máscara de sub-rede 255.255.255.0

No peer B, introduzir a mesma rede de trânsito e 10.20.20.0/24.

Antes de guardar, verificar qual a interface local que corresponde a cada Network. Uma Network demasiado ampla pode ativar RIP em interfaces adicionais e incluir no processo mais redes diretamente ligadas.

3. Definir Interface Overrides

Em Routing > RIP > Override interface configuration, selecionar as interfaces participantes.

Para a interface de trânsito:

• Send version: V2
• Receive version: V2
• Passive mode: desativado
• Split horizon: adequado ao design peer e hub
• Authentication: idêntica em ambos os lados quando utilizada

Para a interface LAN:

• Send version: V2
• Receive version: V2
• Passive mode: ativado

O RIPv2 suporta autenticação em texto simples e MD5. O texto simples não protege a palavra-passe. O MD5 autentica as atualizações de routing, mas não cifra prefixos nem métricas. Por isso, os segmentos de trânsito permanecem limitados aos routers previstos. Para designs novos, com proteção mais forte ou maiores, é normalmente mais adequado um protocolo de routing mais moderno através de um transporte controlado.

Split horizon impede normalmente que uma rota aprendida através de uma interface seja novamente anunciada pela mesma interface. Poisoned reverse pode anunciá-la aí explicitamente com a métrica 16 como inacessível. Estas opções só são alteradas quando exigido pela topologia hub, spoke ou multi-access e são testadas em conjunto com o peer.

4. Espelhar a configuração no peer

No Router ou Firewall B são definidos a mesma versão, os mesmos timers e a mesma autenticação. Utilizam-se 198.51.100.0/30 e 10.20.20.0/24 como Networks, e a interface para a LAN recetora é colocada em modo passivo.

Uma configuração unilateral não é suficiente. Sem o anúncio da rede de retorno, a Firewall A pode aprender a LAN remota, mas as respostas não encontram o caminho de volta.

Regras de firewall, NAT e Route Precedence

Para o teste, ambas as firewalls necessitam de regras restritas e com logging para os serviços realmente necessários entre 10.10.10.0/24 e 10.20.20.0/24. Criar corretamente regras de firewall explica o funcionamento das regras.

Numa rede de sites com routing normal, source NAT permanece desativado. Ambos os lados devem ver o endereço de origem real e conhecer o caminho de retorno através de RIP. O SNAT pode ocultar rotas de retorno em falta e dificultar análises posteriores e o controlo de acesso.

Uma rota RIP aprendida não ganha necessariamente de forma automática. Os prefixos mais longos têm prioridade; em seguida, também contam a fonte de routing, Administrative Distance e a Route Precedence global. Quando uma rota estática, SD-WAN ou VPN concorre, Diagnostics > Tools > Route lookup mostra o caminho efetivamente selecionado. Route Precedence não é alterada globalmente para um único teste RIP.

Validar RIP e o caminho de dados real

A validação separa a troca de routing, a rota selecionada e o fluxo de dados.

Verificar Routes e Status

Em Routing > Information > RIP > Routes, a Firewall A deve mostrar a rede 10.20.20.0/24 com o next hop 198.51.100.2 e uma métrica plausível. O peer B deve conhecer 10.10.10.0/24 através de 198.51.100.1.

Em Routing > Information > RIP > Status, comparar:

• as interfaces participantes
• as versões RIP enviadas e recebidas
• os timers Update, Timeout e Garbage
• as fontes de routing e a redistribuição
• Bad Packets e Bad Routes
• a autenticação ou Key Chain utilizada

Uma entrada visível confirma a troca RIP, mas ainda não que essa rota seja selecionada ou que o tráfego de dados passe.

Testar Route Lookup e o tráfego

1. Na Firewall A, verificar o destino 10.20.20.10 em Diagnostics > Tools > Route lookup. O next hop e a interface devem corresponder ao caminho de trânsito.
2. No peer B, verificar o destino 10.10.10.10.
3. A partir do cliente 10.10.10.10, iniciar uma ligação real permitida ao servidor 10.20.20.10.
4. Em Log viewer, verificar origem, destino, serviço, Firewall Rule ID, Action e uma eventual NAT Rule ID.
5. Em Diagnostics > Packet capture, confirmar que o pedido e a resposta atravessam as interfaces esperadas.

O procedimento completo é descrito em Testar uma regra de firewall com Log Viewer e Packet Capture.

Para um teste apenas de leitura do control plane, é possível filtrar brevemente os pacotes RIP na Device Console:

tcpdump 'udp port 520'

Terminar a saída com Ctrl+C. São esperadas atualizações entre os dois endereços de trânsito. Por outro lado, pacotes RIP provenientes de uma LAN de clientes indicam, neste exemplo, um limite incorreto de interface ou Device Access.

Na Advanced Shell, os logs fornecem contexto adicional:

cd /log
tail -f ripd.log

ripd.log mostra eventos específicos do protocolo. zebra.log ajuda a determinar se uma rota aprendida dinamicamente foi instalada no stack de routing. Terminar a saída em direto com Ctrl+C; em seguida pode utilizar-se tail -f zebra.log. Ficheiros de serviço e de log da Sophos Firewall classifica outros ficheiros.

Delimitar erros de forma sistemática

Não aparece nenhuma rota RIP

Primeiro, testar a acessibilidade direta entre os endereços de trânsito. Depois, Dynamic Routing deve estar ativo na zona correta do peer, uma RIP Network deve corresponder à interface local e devem existir versões compatíveis de envio e receção. Quando é utilizada autenticação, o método e o segredo devem coincidir.

tcpdump 'udp port 520' distingue pacotes em falta de atualizações rejeitadas ou inutilizáveis. Se os contadores Bad Packets ou Bad Routes aumentarem em Status, comparar a versão, a autenticação, a sub-rede e a configuração do peer.

A rota aparece em RIP, mas não é utilizada

Nesse caso, a troca do protocolo está a funcionar. Route Lookup mostra se ganha um prefixo mais específico, uma rota estática, SD-WAN, VPN ou outra Administrative Distance. A métrica RIP, por si só, não decide entre todas as fontes de routing.

Não remover a Route Precedence global nem uma rota de produção existente antes de documentar o respetivo efeito noutras redes.

O tráfego funciona apenas numa direção

O peer necessita da rota de retorno e ambas as firewalls de regras adequadas. Verificar também NAT, caminhos assimétricos e o gateway do host. Um caminho de ida existente não comprova o caminho de retorno.

A rota desaparece e volta a aparecer

Uma ligação de trânsito instável, perda de pacotes, reinícios do peer, timers diferentes ou erros de autenticação podem acionar o timeout. Comparar os valores Update, Timeout e Garbage em ambos os lados. Não reduzir os timers com base numa suspeita; comprovar primeiro o caminho dos pacotes e o estado do peer.

São anunciadas redes inesperadas

Verificar individualmente RIP Networks, Default information originate e cada opção de redistribuição. Redistribute connected pode incluir mais interfaces do que apenas a LAN planeada. Redistribute static também pode distribuir rotas blackhole ou de gestão. A função permanece desativada até existir uma lista completa de prefixos e uma estratégia de filtragem.

Testar HA e failover de forma controlada

Num cluster HA, após um failover planeado, voltar a verificar no Primary atual:

• RIP Status e as interfaces participantes
• as rotas aprendidas e a respetiva idade
• Route Lookup para ambas as LAN
• ripd.log e zebra.log no nó que processou o evento
• uma nova ligação de teste bidirecional

O teste é realizado numa janela de manutenção. Este artigo não promete uma convergência RIP sem interrupções nem a preservação das sessões existentes. Os logs são armazenados por nó de processamento e, por isso, são recolhidos de ambos os appliances quando necessário.

Reverter a alteração em segurança

Antes de remover RIP, deve existir um caminho alternativo ou uma janela de manutenção planeada para cada rede de destino aprendida.

A reversão é efetuada pela ordem inversa:

1. Desativar a redistribuição recém-ativada e Default information originate se tiverem feito deliberadamente parte do teste.
2. Remover as RIP Networks locais.
3. Repor os Interface Overrides no estado anterior documentado.
4. Reverter as definições RIP globais.
5. Remover Dynamic Routing da zona de trânsito ou a exceção ACL apenas se nenhum neighbor OSPF, BGP ou PIM também necessitar dela.
6. Ativar de forma controlada a rota estática ou dinâmica alternativa.
7. Voltar a verificar Route Lookup, regras, acesso de gestão e tráfego real.

Não remover RIP e o caminho de substituição ao mesmo tempo. Manter uma sessão de administrador existente aberta até o caminho de retorno estar confirmado.

Lista de verificação

• Gateway Mode, interfaces, zonas e endereços de trânsito estão documentados.
• Estão disponíveis um backup e um acesso de gestão independente.
• Os dois IP de trânsito conseguem alcançar-se diretamente.
• Dynamic Routing está permitido apenas para a zona do peer ou uma exceção restrita.
• Ambos os lados utilizam valores RIPv2 e de autenticação compatíveis.
• As RIP Networks correspondem apenas às interfaces locais previstas.
• As interfaces LAN de clientes utilizam Passive Mode.
• Default Route Origination e redistribuição são ativados apenas de forma deliberada.
• Routes e Status mostram os prefixos, next hops e timers esperados.
• Route Lookup confirma os caminhos de ida e retorno selecionados.
• As regras de firewall são restritas, têm logging e não incluem SNAT não intencional.
• Um serviço real funciona de forma bidirecional.
• O rollback e o teste HA estão documentados.

FAQ