Sophos RED é un rol de sede remota e non un protocolo VPN, por iso comparalo con IPsec ou OpenVPN responde á pregunta equivocada. O dispositivo estende o control dun cortafogos central cara a unha sucursal, e o modo que escollas decide quen fornece a pasarela da sucursal, quen reparte enderezos e que tráfico cruza o túnel. Esas tres respostas pesan máis que os nomes dos modos. Escribilas primeiro converte unha elección de produto nunha decisión de deseño.

RED é un rol, non un protocolo

Un dispositivo RED une unha sucursal a un Sophos Firewall central, e a configuración do cortafogos define en que se converte a sucursal. O túnel é un detalle de implementación desa unión, non un extremo de VPN de propósito xeral que poidas apuntar a calquera par.

Ese planteamento importa porque un RED non é intercambiable cun par IPsec arbitrario. Espera que o cortafogos central o xestione, e os modos admitidos describen canta parte da sucursal asume. Tratalo como un extremo de túnel corrente crea expectativas que o produto nunca prometeu. Tratalo como un rol produce as preguntas que de verdade deciden o deseño.

As tres condicións seguintes cambian a resposta, e todas tratan de propiedade, non de cifrado.

Tres condicións que escollen o modo

Pregunta quen posúe a pasarela da sucursal, quen xestiona DHCP e DNS para os clientes da sucursal e se a saída local a internet debe sobrevivir a unha caída do túnel.

Standard/Unified responde ás tres igual: o cortafogos central posúe a LAN da sucursal, incluídas as tarefas de pasarela e DHCP, e o tráfico cruza o túnel. Standard/Split mantén a xestión central e envía polo túnel só as redes configuradas. Transparent/Split deixa que a rede de sucursal existente se encargue da súa propia pasarela e dos seus enderezos, e redirixe ao túnel só o tráfico seleccionado. Tres modos, tres propietarios distintos.

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

Le primeiro a columna central, porque decide canta parte da sucursal segue funcionando cando o túnel non está.

Quen posúe a pasarela da sucursal e o DHCP

Na disposición unificada a sucursal non ten unha pasarela independente, o que simplifica a configuración e concentra o fallo. Esa concentración está ben cando a sucursal é pequena e o cortafogos central ten alta dispoñibilidade.

Nun despregamento transparente a sucursal conserva o seu encamiñador e o RED sitúase en liña para redirixir tráfico seleccionado. Iso preserva o control local e engade un dispositivo cuxa posición na ruta agora importa para cada fluxo redirixido. Documenta onde está, porque un cambio posterior no encamiñador da sucursal pode saltalo sen avisar. Ningunha das dúas disposicións gaña en xeral; reparten a responsabilidade de forma distinta.

A propiedade dos enderezos é a parte que hai que escribir, porque dous servidores DHCP no mesmo segmento producen fallos intermitentes que se informan como problemas de VPN.

Que ocorre cando cae o túnel

O funcionamento en Split lese a miúdo como unha promesa de que internet local segue funcionando durante un fallo do túnel, e esa lectura non é segura. O comportamento exacto depende do modo escollido, do firmware e do dispositivo, así que pertence aos criterios de aceptación e non a unha suposición.

Decide que debe seguir facendo a sucursal sen túnel: alcanzar impresoras locais, resolver nomes, cobrar pagamentos ou nada en absoluto. Despois proba ese estado a propósito bloqueando o túnel e observando a sucursal. Unha sucursal que perde DNS en silencio é peor que unha que falla ruidosamente, porque a chamada ao soporte chega horas despois. Escribe o resultado observado no rexistro de deseño.

A dependencia central é a mesma en todos os modos: alguén debe posuír a ruta de recuperación do propio dispositivo.

Escribe o contrato de sucursal antes de despregar

Un contrato de sucursal cabe nunha páxina: propietarios, fontes de enderezos, prefixos tunelizados, política de saída e o comportamento en caída que aceptaches.

Logo verifica o resultado despregado e non o previsto. Comproba o enderezo do cliente da sucursal, a súa pasarela predeterminada, que prefixos se resolven polo túnel e que segue respondendo cando o túnel está bloqueado. Compatibilidade, accesibilidade e licenciamento necesitan todos unha comprobación contra a documentación actual do fabricante para o modelo exacto, porque un nome de produto non garante un modo. Garda esa páxina co rexistro do dispositivo para que o seguinte enxeñeiro herde as decisións e non o diagrama.

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

Repite ese bloque co túnel bloqueado, e a diferenza entre as dúas execucións é o comportamento en caída que realmente compraches.

Artigos relacionados