Como limitar o acceso entre dúas oficinas conectadas por VPN

Un túnel de sitio a sitio responde unha pregunta, se as dúas oficinas poden intercambiar paquetes, e deixa aberta a importante: que dispositivo da sucursal pode chegar a que servizo central. Tratar o túnel como confianza mutua é a forma en que un portátil de invitado acaba na mesma ruta que o servidor financeiro. A solución non é un túnel mellor, senón unha lista de permisos explícita aplicada tras o descifrado. Este manual leva esa lista da definición a unha denegación probada.

Traballe nesta orde e non amplíe a ruta do túnel ata que pasen os pasos de política seguintes.

Escriba a matriz antes de tocar a pasarela

Unha fila útil nomea tres cousas: un grupo de orixe, un host ou rede de servizo de destino, e o protocolo e o porto que a aplicación usa realmente. A sucursal e o centro de datos non son entradas. O DNS privado e os servizos de autenticación merecen filas propias só cando a aplicación non pode funcionar sen eles.

Agrupe as orixes por rol e non por comodidade de subrede: persoal, invitados, administración. Cando os tres comparten unha LAN plana, a pasarela non pode distinguilos na capa de rede, así que os controis de identidade ou a segmentación deben ir primeiro. Despois poña a matriz por escrito cun responsable e unha data de revisión en cada fila.

Aplíqueo onde se descifran os paquetes

As regras que permiten IKE e ESP só constrúen o túnel exterior. O tráfico interior chega en claro á interface do túnel, e aí é onde vai a lista de permisos: unha cadea de reenvío no dispositivo que descifra, descarte predeterminado, unha regra por fila da matriz. Nas pasarelas Linux iso significa reenvío habilitado e regras de filtrado no dispositivo do túnel, non no enlace físico, como explica a guía de reenvío de strongSwan.

Os selectores de tráfico son unha decisión de encamiñamento, non de autorización. Un selector amplo que cobre as dúas subredes pode ser correcto para o encamiñamento mentres a devasa segue permitindo só TCP 443 cara a un host. O selector négociase para o túnel e describe que pode entrar nel, non que pode usar un dispositivo concreto. Nunca amplíe unha regra de devasa porque o selector sexa amplo.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT e subredes superpostas cambian as regras

Cando a pasarela da sucursal traduce cada host a un único enderezo antes do túnel, cada fila baseada na orixe colapsa nese único enderezo. Ou deixe de traducir o tráfico do túnel, ou acepte que as regras deben apoiarse noutra cousa, como o enderezo de orixe orixinal rexistrado antes da tradución. O extremo remoto ten o mesmo problema, porque o host de destino ve o enderezo posterior ao NAT e non o orixinal.

Os rangos superpostos son a outra trampa. Dúas oficinas que usan ambas 192.168.1.0/24 non se poden describir nunha soa táboa de política sen mapear un lado, e un mapaxe non substitúe un endereitamento que non colisiona. Corrixa o plan antes de escribir regras que terá que desfacer despois.

Demostre unha denegación, non só un éxito

Probar só a aplicación permitida demostra moi pouco, porque unha regra permisiva nalgún punto anterior produce o mesmo resultado.

Desde un dispositivo corrente da sucursal, chegue ao servizo previsto e confirme que toda a sesión funciona. Despois probe un destino que debe permanecer pechado, como un porto administrativo nun servidor co que a sucursal non ten nada que ver, e lea o contador ou a entrada de rexistro que o descartou. Desactivar o conxunto de regras para comprobar se funciona invalida a proba e deixa a pasarela aberta mentres mira.

Manteña a lista viva

As aplicacións móvense, e unha regra que sobrevive á súa aplicación convértese nun burato que ninguén posúe. Ate a data de revisión á fila e cambie o alcance do selector e a regra de devasa no mesmo paso de mantemento cando un servizo cambie de enderezo.

As restricións a nivel de host seguen importando detrás do túnel: a devasa propia do servidor debería aceptar o rango da sucursal só para o servizo que publica. Dúas capas que coinciden son máis fáciles de auditar que unha soa na que se confía por completo.