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 trocam redes sem uma seleção de caminhos complexa.

O procedimento curto e seguro é o seguinte:

Documentar a rede de trânsito, as LAN locais, o peer, os prefixos esperados e o caminho de retorno.
Preparar um backup da configuração e um acesso de gestão independente.
Verificar a acessibilidade IP direta entre os endereços de trânsito.
Em Administration > Device access, permitir Dynamic Routing apenas para a zona do peer ou através de uma exceção restrita.
Em Routing > RIP, selecionar RIPv2 e, inicialmente, manter os timers globais inalterados.
Adicionar a rede de trânsito e as LAN locais em RIP Networks.
Definir as interfaces LAN como Passive mode através de Override interface configuration.
Alinhar com o peer a versão e a autenticação da interface de trânsito.
Em Routing > Information > RIP, verificar o estado e as rotas aprendidas.
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 devem permanecer desativados até que sejam conhecidos todos os prefixos anunciados e os respetivos caminhos de retorno. Uma redistribuição abrangente pode propagar inadvertidamente rotas Connected ou Static por todo o domínio de routing RIP.

Este procedimento aborda RIPv2 para IPv4 em Gateway Mode. O RIPv1 é considerado apenas para a ligação a equipamentos antigos. 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 a rota com a métrica mais baixa. 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 relativamente 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 é muitas vezes mais simples. Com vários caminhos redundantes, necessidade de convergência rápida ou redes internas maiores, o OSPF é geralmente mais adequado. O BGP destina-se a arquiteturas com sistemas autónomos, operadores ou seleção de rotas controlada de forma específica.

O RIP não substitui uma regra de firewall nem monitoriza a qualidade das aplicações. Se o caminho tiver de ser selecionado com base na origem, no serviço, na aplicação, na latência, no jitter ou na perda de pacotes, é necessária uma rota SD-WAN.

Distinguir RIPv1 de RIPv2

Para novas configurações, deve utilizar-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.

Em RIP version, o SFOS disponibiliza estas três opções:

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 ser útil durante uma transição controlada, mas continua a aceitar atualizações RIPv1. Assim que todos os peers utilizarem RIPv2, as versões de envio e receção devem ser definidas como V2.

Compreender RIP Networks e Passive Mode

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

No exemplo, são adicionadas à 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 o RIP na interface ligada ao peer.
A LAN é anunciada como uma rede local alcançável.
Passive mode na interface LAN impede a firewall de enviar atualizações RIP nessa interface.

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

Planear a topologia de exemplo

O exemplo utilizado ao longo do artigo liga duas LAN:

Firewall A: IP de trânsito 198.51.100.1/30, LAN local 10.10.10.0/24
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á reservado para documentação. A rede de trânsito, os IP de trânsito, os prefixos LAN e os hosts de teste devem ser substituídos de forma consistente pelos valores do ambiente real. Os endereços de documentação não devem ser utilizados sem alterações numa configuração de produção. 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. Só este caminho de ida e volta permite tráfego encaminhado sem Source NAT.

Antes da alteração, devem ser documentados a interface, a zona, as rotas existentes, a Route Precedence, a métrica esperada e um host de teste acessível. Um backup da configuração atualizado e um caminho de gestão independente do novo routing permitem uma reversão controlada.

Permitir Dynamic Routing de forma restrita

Em Administration > Device access, deve verificar-se primeiro em que zonas Dynamic Routing está atualmente permitido. No exemplo, Dynamic Routing é permitido exclusivamente na zona de trânsito dedicada ou através de uma exceção ACL restrita ao peer.

A matriz Device Access aplica-se a toda a zona. Numa zona de trânsito dedicada e de confiança, Dynamic Routing pode ser ativado para essa zona. Se o acesso tiver de ficar limitado a um peer ou a uma rede de trânsito específicos, a caixa da zona deve permanecer desmarcada e deve ser criada, em Local service ACL exception rule, uma exceção Allow restrita à origem e ao serviço. Uma permissão simultânea para toda a zona anularia essa restrição. O artigo Device Access e Local Service ACL explica esta distinção.

Esta permissão aplica-se aos pacotes RIP destinados à firewall e não pode ser substituída por uma regra de firewall normal. Em contrapartida, o fluxo de dados entre 10.10.10.0/24 e 10.20.20.0/24 continua a exigir regras de firewall normais. Dynamic Routing não deve ser ativado na zona LAN apenas porque a LAN é anunciada como RIP Network. O estado efetivo de Device Access deve ser documentado antes da alteração; não se deve pressupor uma configuração predefinida genérica.

Configurar RIPv2 no WebAdmin

O exemplo utiliza uma segunda Sophos Firewall no lado B. Com duas Sophos Firewalls, a configuração é replicada no peer; apenas o IP de trânsito e a LAN local são diferentes. Num router de outro fabricante, devem configurar-se RIPv2, rede de trânsito, LAN local, Passive Mode e eventual autenticação através das funções equivalentes desse equipamento.

1. Definir os valores globais

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

Definir RIP version como V2.
Manter Default metric no valor predefinido existente 1.
Manter Administrative distance no valor predefinido existente 120.
Manter inicialmente Update, Timeout e Garbage em 30, 180 e 120 segundos.
Manter Default information originate desativado.
Não ativar qualquer redistribuição.
Guardar com Apply.

Default information originate anuncia uma rota predefinida no domínio de routing RIP. Só faz sentido quando esta firewall deve ser deliberadamente a saída para todos os destinos desconhecidos e tanto o caminho de retorno como o comportamento em caso de falha foram planeados.

O valor predefinido de Default metric para rotas redistribuídas é 1; são permitidos valores de 1 a 16. O valor predefinido de Administrative distance é 120, com um intervalo permitido de 1 a 255. Sem um projeto de routing documentado, ambos os valores devem permanecer inalterados.

Os valores predefinidos de Update, Timeout e Garbage são 30, 180 e 120 segundos. O SFOS aceita, para cada um destes timers, valores de 5 a 2147483647 segundos. O exemplo mantém os valores predefinidos; só devem ser escolhidos valores diferentes com um plano comum de timers e falhas para ambos os peers.

2. Adicionar RIP Networks

Em Routing > RIP > RIP Networks > Add, adicionar estas redes locais à Firewall A:

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

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

Antes de guardar, deve verificar-se qual a interface local abrangida por cada Network. Uma Network demasiado ampla pode ativar o RIP noutras interfaces e incluir no processo redes diretamente ligadas adicionais.

3. Definir Interface Overrides

Em Routing > RIP > Override interface configuration, selecionar a interface envolvida através de Select interface.

Para a interface de trânsito:

Send version: V2
Receive version: V2
Passive mode: desativado
Split horizon: manter o estado anterior documentado; por predefinição, o SFOS desativa esta opção
Poisoned reverse: disponível apenas quando Split Horizon está ativado e desativado por predefinição
Authentication: verificar o estado anterior efetivo e configurar deliberadamente ambos os lados de forma idêntica

Para a interface LAN:

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

Guardar a seleção com Save. 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 os prefixos nem as métricas. Por isso, os segmentos de trânsito devem permanecer limitados aos routers previstos. A ajuda pública da CLI do SFOS 22 e a ajuda do WebAdmin apresentam informações contraditórias sobre o estado predefinido da autenticação. Por esse motivo, não se pressupõe aqui qualquer estado predefinido: devem verificar-se ambas as interfaces de trânsito e configurá-las depois, de forma deliberada e idêntica.

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

4. Replicar a configuração no peer

Na Firewall B, definir de forma idêntica a versão, os timers e a autenticação. Utilizar 198.51.100.0/30 e 10.20.20.0/24 como Networks e definir a interface ligada à LAN local como passiva.

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.

Por que motivo este guia utiliza o WebAdmin para as alterações

O SFOS disponibiliza uma CLI de RIP em 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP. No entanto, a ajuda pública da CLI do SFOS 22 contém comandos de autenticação incorretamente concatenados e não documenta todos os comandos necessários para guardar e verificar a configuração. Não se deduz deste material qualquer sintaxe não confirmada. Por isso, a configuração e a reversão são efetuadas através dos campos documentados do WebAdmin. A CLI é utilizada apenas para diagnósticos de suporte em modo de leitura que estejam documentados para a versão instalada do SFOS.

Regras de firewall, NAT e Route Precedence

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

Numa rede de locais 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.

Dentro do RIP, o SFOS mantém, para cada destino, a rota com a menor métrica de saltos. Isso não prova, por si só, que este seja também o caminho ativo em todo o sistema. Quando existe uma rota estática, SD-WAN ou VPN concorrente, o caminho efetivamente selecionado deve ser verificado em Diagnostics > Tools > Route lookup. A Route Precedence não deve ser alterada globalmente para um único teste RIP.

Validar o RIP e o caminho de dados real

Na validação, verificam-se separadamente três questões: as rotas são trocadas, é selecionada a rota correta e o tráfego de dados funciona?

Verificar Routes e Status

Em Routing > Information > RIP > Routes, a Firewall A deve mostrar a rede 10.20.20.0/24 com 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, devem comparar-se nas duas firewalls:

as interfaces envolvidas
as versões RIP enviadas e recebidas
os timers Update, Timeout e Garbage
as fontes de routing e a redistribuição
os campos From, Tag e Time da rota
os filtros de atualização de entrada e saída, caso estejam definidos
o nome da Key Chain, caso esteja configurada
Bad Packets e Bad Routes

Uma rota RIP visível confirma a troca de rotas, mas não confirma que o SFOS a seleciona ou que encaminha tráfego de dados através dela. A vista de estado não comprova o segredo utilizado; este tem de ser gerido e verificado de forma controlada em ambos os peers.

Testar Route Lookup e o tráfego

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.
No peer B, verificar o destino 10.10.10.10.
A partir do cliente 10.10.10.10, iniciar uma ligação real e permitida ao servidor 10.20.20.10.
Em Log viewer, verificar a origem, o destino, o serviço, Firewall Rule ID, Action e uma eventual NAT Rule ID.
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.

Delimitar erros de forma sistemática

Não aparece nenhuma rota RIP

Primeiro, deve verificar-se a acessibilidade direta entre os endereços de trânsito. Em seguida, Dynamic Routing tem de estar permitido na zona correta do peer, uma RIP Network tem de corresponder à interface local e as versões de envio e receção têm de ser compatíveis. Quando é utilizada autenticação, o método e o segredo têm de coincidir.

Se os contadores Bad Packets ou Bad Routes aumentarem em Status, devem comparar-se a versão, a autenticação, a sub-rede e a configuração do peer. Se os contadores permanecerem inalterados e as vistas de diagnóstico não mostrarem tráfego RIP proveniente do peer, devem verificar-se primeiro a atribuição da interface e a Local Service ACL. Só depois se devem alterar os valores globais do RIP.

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

Nesse caso, a troca do protocolo está a funcionar. O Route Lookup mostra qual o caminho realmente ativo. A métrica RIP compara caminhos RIP; por si só, não decide entre todas as fontes de routing.

Não se deve 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 num sentido

O peer precisa da rota de retorno e ambas as firewalls precisam de regras adequadas. Devem verificar-se também o NAT, os caminhos assimétricos e o gateway predefinido do host. A existência do caminho de ida não comprova o caminho de retorno.

A rota desaparece e volta a aparecer

Se não forem recebidas atualizações antes de terminar o valor de Timeout configurado, a rota torna-se inválida. Durante o período Garbage, o SFOS anuncia-a como inacessível com a métrica 16 e elimina-a depois. Por isso, devem comparar-se a acessibilidade, o estado do peer e os valores de Update, Timeout e Garbage em ambos os lados antes de alterar os timers.

São anunciadas redes inesperadas

Devem verificar-se individualmente RIP Networks, Default information originate e cada opção de redistribuição. A redistribuição pode abranger mais rotas Connected ou Static do que as LAN previstas neste exemplo. A função deve permanecer desativada até serem conhecidos todos os prefixos que devem efetivamente ser distribuídos.

Reverter a alteração em segurança

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

A reversão começa pelo caminho de substituição, não pela remoção das rotas RIP ativas:

Ativar uma rota estática ou dinâmica alternativa e validá-la com Route Lookup, acesso de gestão e tráfego bidirecional real.
Desativar a redistribuição recentemente ativada e Default information originate, caso tenham feito deliberadamente parte do teste; em seguida, verificar novamente os prefixos esperados.
Remover as RIP Networks locais uma a uma e verificar os caminhos de ida e de retorno após cada passo.
Repor os Interface Overrides e as definições globais de RIP no estado anterior documentado.
Remover Dynamic Routing da zona de trânsito ou a exceção ACL em último lugar, e apenas se nenhum vizinho OSPF, BGP ou PIM também precisar dessa permissão.
Por fim, voltar a verificar Route Lookup, regras, acesso de gestão e tráfego real.

Não se devem remover simultaneamente o RIP e o caminho de substituição. Deve manter-se aberta uma sessão de administrador existente até o caminho de retorno estar confirmado.

Verificação para aprovação

Ambas as firewalls mostram as rotas RIP esperadas, com o Next Hop correto e uma métrica plausível.
O Route Lookup confirma os caminhos de ida e de retorno previstos.
Não aparecem prefixos inesperados nem redistribuição involuntária.
São aplicadas regras de firewall restritas e com registo, sem SNAT involuntário.
Um serviço real funciona nos dois sentidos.
O caminho de substituição e a reversão estão documentados e podem ser executados.