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.

Os routers trocam atualizações de routing periodicamente. O router que as recebe integra as alterações na sua tabela de routing, aumenta a métrica do caminho em 1 e utiliza o remetente como Next Hop.

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.

Se ambas as firewalls enviarem atualizações RIP pela interface de trânsito, mas apenas a Firewall A permitir as atualizações recebidas, a aprendizagem de rotas torna-se unilateral: A recebe as atualizações de B e aprende 10.20.20.0/24 através de 198.51.100.2. B continua a enviar as suas atualizações, mas descarta as recebidas de A porque em B falta a permissão para Dynamic Routing. Assim, B não aprende através de RIP a rota para 10.10.10.0/24 anunciada por A.

Trata-se de uma assimetria na troca de informações de routing (plano de controlo), não de uma prova de uma falha específica do tráfego de dados. Devem verificar-se ambos os lados em Routing > Information > RIP > Routes e confirmar a permissão efetiva de receção na firewall que não aprende rotas. Qualquer correção deve ficar limitada à zona real do peer ou a uma exceção ACL restrita; não se deve permitir o acesso genérico a partir da WAN. Em seguida, devem verificar-se separadamente Route Lookup, regras de firewall, NAT e os caminhos reais de ida e retorno.

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 gera e anuncia uma rota predefinida no domínio de routing RIP e está desativado por predefinição. 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.

Administrative distance ajuda o router a escolher a melhor rota entre fontes de routing concorrentes; a métrica RIP compara, por sua vez, caminhos dentro do RIP.

Os valores predefinidos de Update, Timeout e Garbage são 30, 180 e 120 segundos. Update determina o intervalo entre duas atualizações periódicas de routing. A documentação oficial do SFOS 22.0 indica de 5 a 2147483647 segundos para cada um destes três timers; a do SFOS 23.0 indica de 1 a 32767 segundos para cada um e designa Timeout como Time-out. São valores documentados por versão, não uma garantia de validação das entradas numa compilação testada. 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.

Se a redistribuição for deliberadamente necessária, ativar apenas as fontes planeadas em Routing > RIP: Redistribute connected para rotas diretamente ligadas, Redistribute static para rotas estáticas, Redistribute OSPF para rotas OSPF e Redistribute BGP para rotas BGP. Definir a métrica de redistribuição correspondente a cada fonte ativada; os quatro campos permitem de 0 a 16, ao contrário de Default metric global. Escolher os valores de acordo com o projeto de routing documentado, sem copiar um valor genérico. Guardar com Apply e verificar depois os prefixos esperados e inesperados e o caminho de retorno, como descrito abaixo. No exemplo, as quatro fontes permanecem desativadas.

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.

Send e Receive permitem, de forma independente, V1, V2 ou ambas as versões. A seleção de cada interface substitui RIP version global. Send tem V2 como valor predefinido; a versão de receção V2 escolhida abaixo é uma configuração deliberada do exemplo, não uma afirmação sobre o valor predefinido de Receive. Passive mode está desativado por predefinição e é ativado expressamente para a LAN.

Para uma ligação RIPv2 deliberadamente autenticada, ativar Authentication e introduzir uma palavra-passe; a configuração deve coincidir em ambos os peers. Se for selecionada autenticação para uma interface RIPv1, esta envia atualizações de routing, mas não aceita rotas. Quando se selecionam ambas as versões, o RIPv2 continua a funcionar com autenticação. A Sophos recomenda configurar o RIPv1 numa interface diferente da utilizada para RIPv2 autenticado.

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 acesso documentado à CLI varia consoante a versão: a ajuda do SFOS 22.0 indica 3. Route Configuration > 1. Configure Unicast Routing > 1. Configure RIP, o prompt rip> e, em seguida, enable. A ajuda do SFOS 23.0 indica, por sua vez, 3. Route Configuration > 1. Configure Unicast Routing, o prompt router# e, em seguida, router#configure terminal. A entrada router rip da tabela é um comando CLI, não uma seleção adicional do menu. Trata-se de uma comparação dos acessos documentados, não de uma sequência de configuração executável.

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. A ajuda do SFOS 23.0 também continua ambígua quanto aos contextos da CLI para autenticação e ao exemplo MD5. A correção dos exemplos de texto simples não torna automaticamente os restantes comandos numa sequência fiável. Não se deduzem deste material sintaxe não confirmada nem passos para mudar de contexto ou guardar.

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.