O Sophos RED é uma função de local remoto e não um protocolo VPN, por isso compará-lo com IPsec ou OpenVPN responde à pergunta errada. O dispositivo estende o controle de um firewall central a uma filial, e o modo que escolhe decide quem fornece o gateway da filial, quem distribui endereços e que tráfego atravessa o túnel. Essas três respostas pesam mais do que os nomes dos modos. Escrevê-las primeiro transforma uma escolha de produto numa decisão de projeto.

RED é uma função, não um protocolo

Um dispositivo RED liga uma filial a um Sophos Firewall central, e a configuração do firewall define o que a filial se torna. O túnel é um detalhe de implementação dessa ligação, não um ponto final de VPN de uso geral que se possa apontar a qualquer par.

Esse enquadramento importa porque um RED não é intercambiável com um par IPsec arbitrário. Ele espera que o firewall central o administre, e os modos suportados descrevem quanto da filial ele assume. Tratá-lo como um ponto final de túnel comum cria expectativas que o produto nunca prometeu. Tratá-lo como uma função produz as perguntas que de fato decidem o projeto.

As três condições abaixo mudam a resposta, e todas tratam de propriedade, não de criptografia.

Três condições que escolhem o modo

Pergunte quem possui o gateway da filial, quem opera DHCP e DNS para os clientes da filial, e se a saída local para a internet precisa sobreviver a uma falha do túnel.

Standard/Unified responde às três da mesma forma: o firewall central possui a LAN da filial, incluindo tarefas de gateway e DHCP, e o tráfego atravessa o túnel. Standard/Split mantém a gestão central e envia pelo túnel apenas as redes configuradas. Transparent/Split deixa a rede de filial existente cuidar do próprio gateway e dos próprios endereços, e redireciona para o túnel apenas o tráfego selecionado. Três modos, três proprietários diferentes.

ModeBranch gateway and DHCPTraffic through the tunnel
Standard/UnifiedCentral firewall owns bothAll branch traffic
Standard/SplitCentral firewall owns bothOnly the configured networks
Transparent/SplitThe existing branch router keeps bothOnly the selected flows

Leia primeiro a coluna do meio, porque ela decide quanto da filial ainda funciona quando o túnel desaparece.

Quem possui o gateway da filial e o DHCP

Na disposição unificada a filial não tem gateway independente, o que simplifica a configuração e concentra a falha. Essa concentração é aceitável quando a filial é pequena e o firewall central tem alta disponibilidade.

Numa implantação transparente a filial mantém o seu roteador e o RED fica em linha para redirecionar o tráfego selecionado. Isso preserva o controle local e acrescenta um dispositivo cuja posição no caminho agora importa para cada fluxo redirecionado. Documente onde ele fica, porque uma alteração posterior no roteador da filial pode contorná-lo em silêncio. Nenhuma das disposições vence em geral; elas distribuem a responsabilidade de forma diferente.

A propriedade dos endereços é a parte que precisa ser escrita, porque dois servidores DHCP no mesmo segmento produzem falhas intermitentes que são reportadas como problemas de VPN.

O que acontece quando o túnel cai

A operação em Split é muitas vezes lida como a promessa de que a internet local continua a funcionar durante uma falha do túnel, e essa leitura não é segura. O comportamento exato depende do modo escolhido, do firmware e do dispositivo, portanto pertence aos critérios de aceitação e não a uma suposição.

Decida o que a filial ainda precisa fazer sem túnel: alcançar impressoras locais, resolver nomes, receber pagamentos ou nada. Depois teste esse estado de propósito, bloqueando o túnel e observando a filial. Uma filial que perde DNS em silêncio é pior do que uma que falha em voz alta, porque a chamada ao suporte chega horas depois. Escreva o resultado observado no registo de projeto.

A dependência central é a mesma em todos os modos: alguém tem de possuir o caminho de recuperação do próprio dispositivo.

Escreva o contrato da filial antes de implantar

Um contrato de filial cabe numa página: proprietários, fontes de endereços, prefixos tunelizados, política de saída e o comportamento em falha que aceitou.

Depois verifique o resultado implantado e não o previsto. Confirme o endereço do cliente da filial, o seu gateway predefinido, que prefixos são resolvidos pelo túnel e o que ainda responde quando o túnel está bloqueado. Compatibilidade, alcance e licenciamento precisam todos de verificação contra a documentação atual do fornecedor para o modelo exato, porque um nome de produto não garante um modo. Guarde essa página com o registo do dispositivo, para que o próximo engenheiro herde as decisões e não o diagrama.

ip -br addr
ip route
traceroute -n 10.80.4.10
dig +short intranet.corp.example

Repita esse bloco com o túnel bloqueado, e a diferença entre as duas execuções é o comportamento em falha que realmente comprou.

Artigos relacionados