Dous grupos de clientes, un servidor: onde aplicar a política

Pór dous grupos de clientes en subredes diferentes parece illamento, e non o é. Os enderezos describen de onde parece vir un paquete, mentres que o permiso é unha decisión que toma quen o reenvía. Esa pregunta respóndea a configuración e non a máscara, así que decida que compoñente reenvía o tráfico entre pares antes de escribir calquera regra.

Unha subrede é unha etiqueta, non unha regra

Asignar un conxunto por grupo dálle enderezos lexibles e nada máis. Un cliente que acepta unha ruta adicional gañou alcanzabilidade, e a alcanzabilidade non é autorización. O permiso para falar está na decisión de reenvío, que pode vivir no daemon ou no núcleo segundo como estea configurado o servidor.

A propiedade do enderezo é o que fai que un prefixo sexa utilizábel como selector de grupo. Cada identidade autenticada debe corresponder a un enderezo ou rango previsible, e esa correspondencia falla en canto varios dispositivos comparten unha credencial e unha asignación. Resolva a identidade e a concorrencia antes de confiar nun prefixo de orixe, porque unha política que adiviña que máquina chama autoriza a equivocada no peor momento.

Escolla a ruta que transporta o tráfico entre pares

Cando o daemon reenvía paquetes entre pares dentro do seu propio proceso, eses paquetes nunca chegan ao gancho de reenvío do host, así que unha regra do núcleo non os pode ver. Desactive ese reenvío interno e o núcleo convértese no punto de reenvío, onde se aplican as regras de reenvío ordinarias.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

As canles de datos descargadas e os servidores xestionados polo produto publican os seus propios modelos de aplicación, así que confirme cal executa en lugar de supoñer o comportamento da comunidade. O fallo que paga a pena evitar é unha regra que parece correcta nunha revisión e nunca se consulta en tempo de execución.

Escriba a matriz antes de escribir regras

Unha matriz curta é máis doada de revisar que un conxunto de regras, e é o contrato que a implementación debe cumprir: pares do mesmo grupo permitidos, pares entre grupos denegados, ambos os grupos permitidos cara a un servizo compartido con nome, todo o demais denegado. Escriba esas catro liñas antes de abrir un editor de devasas. Un revisor que non le a sintaxe das regras aínda pode comprobar a matriz. Logo a implementación só ten que coincidir coas liñas.

Manteña as tres clases de destino separadas mentres a escribe. Un servizo no host de VPN é entrada local, outro cliente é tránsito entre pares e unha máquina detrás da pasarela é unha ruta de reenvío distinta. Unha regra xenerosa pode conceder as tres por accidente, e así é como unha política de grupo se converte nunha rede plana con pasos extra. Escriba a clase xunto a cada fila para que a intención sobreviva á próxima edición.

Pon as regras onde sobreviven

Engada as decisións no mesmo lugar onde se mantén o resto da devasa, antes de calquera regra permisiva que doutro xeito as tragaría. A orde das regras forma parte da política, e unha regra correcta colocada despois dunha aceptación ampla non aplica nada. Anote os números de regra antes e despois do cambio. Unha política que existe nun editor pero non no conxunto de regras en execución é un plan, non un control.

Decida que ocorre cos fluxos que xa existen cando cambia a política, porque unha sesión aberta antes do cambio pode seguir executándose despois. Se un membro que marcha debe perder o acceso de inmediato, o conxunto de regras precisa unha forma de terminar ese estado en lugar de esperar a que a conexión se peche soa.

Faga persistentes as regras mediante o mecanismo que posúe o resto da devasa, e rexistre a matriz ao seu carón. Unha política non rexistrada volve derivarse da memoria durante o seguinte incidente, normalmente por alguén con présa.

Demostra desde ambos os lados

Probe a alcanzabilidade dentro do mesmo grupo, o fallo entre grupos e o servizo compartido desde un cliente de cada grupo. Unha única proba desde un único cliente demostra a metade da matriz, e a metade que deixa fóra adoita ser a equivocada. Repita a dirección de denegación dúas veces, porque unha sesión na caché pode ocultar un erro de aplicación. Rexistre que par probou para que a seguinte persoa non o repita.

Repita a comprobación en IPv6 se o túnel o transporta, e manteña a autenticación normal das aplicacións. Un prefixo de orixe non é unha conta, así que pasar a política de rede non significa que un servizo deba confiar en quen chama.