Hereda unha subrede VPN o nivel de seguridade da interface ASA?

Unha subrede VPN descifrada nunca herda o nivel de seguridade dunha interface. Comprobe sysopt connection permit-vpn, o filtro de grupo e o acceso de xestión por separado.

Alguén pregunta se a subrede VPN da sucursal ten «nivel de seguridade 0 ou 100» no ASA, e a pregunta xa contén o erro. O nivel de seguridade é unha propiedade dunha interface local e asígnase de 0 a 100 na configuración da interface. Unha subrede remota que chega por un túnel non adquire ningún, escríbase como se escriba o crypto map. Por iso a pregunta non ten resposta numérica.

A pregunta práctica que segue é mellor: que política admite a sucursal cara ao servidor e cal a mantén lonxe do propio cortafuegos. Son dúas respostas, e o procedemento de abaixo sepáraas.

Os niveis de seguridade pertencen ás interfaces

Execute show running-config interface e verá security-level baixo cada interface física ou interface VLAN, non baixo o grupo de túnel nin o crypto map. O permiso predeterminado de maior a menor avalíase entre esas interfaces, e por iso o número cambia o comportamento da inspección e da ACL implícita na ruta á que pertence.

Nun fluxo VPN descifrado, a entrada segue a ser a interface outside onde termina o túnel, e a saída é a interface inside cara ao servidor. Anote ambas antes de tocar nada. Ese único paso elimina a maior parte da confusión, porque converte unha pregunta abstracta de confianza nun par de interfaces.

A omisión da ACL ten unha fronteira con nome

sysopt connection permit-vpn é o axuste que a xente recorda a medias cando di que o tráfico VPN ignora as ACL. Si omite a ACL da interface para o tráfico que cualifica como tráfico VPN, e a guía de parámetros 9.x limítao por interface e dirección en lugar de declarar unha excepción global.

Comprobe que está configurado antes de razoar de memoria:

  • show running-config all sysopt para ver o valor efectivo, non só as liñas que non son predeterminadas.
  • show running-config access-group para ver que ACL se aplica a que interface e dirección.
  • show vpn-sessiondb detail l2l para confirmar que grupo de túnel e que filtro usa realmente a sesión.

Desactivar ese axuste para endurecer o acceso VPN é un cambio con grande alcance. Volve someter cada fluxo VPN que cualifica á ACL exterior, o que adoita romper túneles que funcionaban de formas sen relación coa sucursal pola que lle preguntaron.

Lea o filtro asociado á sesión

O control real por túnel é o filtro VPN: unha ACL referenciada pola política de grupo ou polo nome de usuario, aplicada despois do descifrado e antes do cifrado. Un filtro a nivel de usuario substitúe o valor a nivel de grupo, así que dúas persoas do mesmo grupo de túnel poden ter un acceso efectivo distinto.

Confirme a precedencia en lugar de supoñela. show running-config group-policy <name> mostra o valor do grupo, e show running-config username <name> mostra se existe un valor por usuario. Se existen ambos, gaña o valor do usuario. Despois compare as entradas desa ACL co fluxo que lle interesa, na dirección en que avalía o filtro.

Un filtro que permite o servidor de aplicacións non di nada sobre a xestión. Son regras separadas nunha ruta separada.

Verifique un permiso e unha denegación

Packet-tracer é a forma máis rápida de ver a decisión sen esperar a que un usuario a reporte. Délle o fluxo do lado descifrado e deixe que nomee as etapas de ACL, NAT e inspección polas que pasa.

  1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
  2. Lea a liña do resultado: nomea a ACL que permitiu ou descartou o paquete.
  3. Repita co destino administrativo na interface inside e confirme unha denegación.
  4. Repita unha vez máis despois de calquera cambio, para que queden rexistrados tanto o estado anterior como o posterior.

Despois verifique con tráfico real: unha solicitude de aplicación correcta desde a sucursal e un intento SSH fallido cara ao ASA. Packet-tracer modela a ruta; un fluxo en vivo demostra que o modelo coincidía.

Reverta o cambio que o fixo funcionar

Se a solución foi desactivar a omisión da ACL ou ampliar un filtro, conserve a configuración anterior. Unha captura show run dos obxectos afectados, gardada antes do cambio, abonda para restauralos; a configuración do ASA está orientada a liñas, así que reverter significa volver introducir as liñas antigas, non restaurar un ficheiro.

Rexiste o par de interfaces, o filtro efectivo, o nome da ACL de packet-tracer e os comandos exactos que cambiou. Ese rexistro converte a seguinte revisión nunha comprobación de cinco minutos en lugar doutro debate sobre niveis de confianza.

Artigos relacionados