Enderezos de túnel estáticos en pfSense: preferencia ou reserva?

Dous deseños parecen iguais sobre o papel e compórtanse moi distinto cando unha regra depende deles. Un escribe un enderezo nunha anulación de cliente e confía no enderezo como identidade. O outro pecha por completo a admisión dinámica, de xeito que un extremo ou ten unha asignación única ou non se conecta. Só o segundo converte un enderezo nunha entrada de política que podes defender, e a diferenza paga a pena entendela antes de escribir unha soa regra de cortafogos.

Que promete realmente un enderezo de anulación

Unha anulación específica de cliente leva opcións por cliente, incluído un enderezo de túnel preferido. Netgate describe ese enderezo como unha preferencia e non como unha reserva, o que significa que o conxunto dinámico non cede o enderezo a ninguén máis.

Iso normalmente está ben. Unha colisión é rara, e o cliente normalmente recibe o que pediu, o cal abonda para a comodidade e non abonda para a autorización. Comodidade e autorización son requisitos distintos, e só un deles sobrevive a unha colisión.

Con topoloxía de subrede, o campo toma o enderezo do cliente xunto coa máscara da rede do servidor, así que un enderezo dentro dun túnel 10.90.0.0/24 escríbese como 10.90.0.10/24.

Nada diso reserva o número. Un cliente cuxa anulación non coincide, ou unha sesión duplicada, pode acabar noutro lugar do conxunto, e unha regra baseada no enderezo describe entón alguén que non está alí.

Pechade a vía dinámica cun valor por defecto delimitado

A alternativa é un servidor só estático: cada extremo admitido ten a súa propia identidade e o seu propio enderezo único, e nada máis entra.

Implantalo significa unha anulación DEFAULT limitada a ese único servidor co bloqueo de conexións activado. Un cliente sen unha anulación coincidente non pode entón volver á admisión dinámica ordinaria. Esa soa liña é o que converte unha preferencia nun conxunto pechado.

O alcance importa. Unha anulación por defecto aplicada a cada instancia VPN do equipo bloqueará túneles non relacionados, e esa falla parece un servizo roto máis ca unha decisión de política. Víncaa ao único servidor cuxo modelo de admisión estás cambiando. Despois anota o alcance no rexistro de cambios, porque a persoa seguinte non lembrará a que túnel pertence.

Audita despois todo o conxunto permitido. O bloqueo por defecto non arranxa unha anulación con nome que quedou sen enderezo, e ese extremo simplemente non se conectará sen unha pista clara de por que.

Coincide coa identidade que o servidor usa de verdade

Unha anulación coincide con algo. Nun servidor que compara nomes comúns de certificado, o nome da anulación debe ser ese nome común, non o nome visible da persoa. Copia-o do certificado en lugar da lista de contas.

Un servidor configurado para usar o nome de usuario como nome común compara cunha clave completamente distinta, e unha anulación chamada polo certificado nunca se activará. Le o parámetro en vez de deducilo do que mostra a lista de contas.

Mantén os factores de autenticación adicionais que esixe o despregamento. Un modelo de enderezos pechado cambia quen pode conectarse e que enderezo recibe; non substitúe a comprobación do certificado nin o segundo factor.

Escribe as regras de acceso cando o mapa sexa sólido

Unha vez pechado o mapa de identidade a enderezo, as regras poden referirse a enderezos sen finxir que son persoas. Un alias que agrupa os extremos dunha persoa pode chegar a un servizo concreto mentres outro alias chega a outra cousa. O alias vólvese o obxecto revisable, e o enderezo vólvese un detalle de implementación dentro del.

Mantén explícitos os destinos e os portos. Permitir toda a rede local desde todo o conxunto de túneles é xustamente o deseño que este exercicio debía substituír.

Le as regras flotantes, de grupo e de interface na súa orde real de avaliación, porque un paso amplo anterior anula un paso estreito posterior. Desactivar o reenvío interno entre clientes mantén o tráfico entre iguais na fronteira onde se revisan esas regras. Unha regra que só existe sobre o papel non é aplicación.

Proba os casos negativos

Exercita catro conexións novas: un extremo con nome, un sen ningunha anulación, un servizo que debería ser alcanzable e un que non debería. O extremo non listado é o caso importante, porque é o que o deseño existe para deter. Se se conecta, o bloqueo por defecto non está a facer o seu traballo.

Comproba IPv6 por separado, xa que unha política de enderezos IPv4 non di nada sobre unha segunda pila. Despois confirma que a aplicación aínda autoriza o usuario, porque un enderezo de túnel é un feito de rede e non unha proba de quen está no teclado. As dúas comprobacións pertencen á nota de aceptación.

Por último, planifica a migración. As anulacións novas e as regras estreitas non cambian retroactivamente as sesións xa establecidas, así que os estados existentes teñen que caducar ou borrarse deliberadamente.