Un selector IPsec amplo non é permiso para cada servizo

Dous extremos acordan protexer toda unha subrede, e alguén le ese acordo como permiso para chegar a cada servizo dentro dela. Ese é o mito: o selector di que tráfico o túnel está disposto a transportar e non di nada sobre que servizos permite a organización. Un par de dispositivos poden negociar lexitimamente un rango de enderezos amplo mentres a política de acceso dentro del permite dous portos, e ambas as afirmacións seguen sendo certas ao mesmo tempo.

A cobertura protexida non é autorización

Un selector de tráfico forma parte do acordo do túnel. Restrinxe ou confirma o que cifrarán os extremos entre si, e un selector amplo adoita ser o máis sinxelo de operar cando os dous lados teñen moitos fluxos que transportar. O filtro de servizos é outro control noutro punto do camiño, e decide que se pode usar realmente unha vez descifrado o paquete. Quitar o filtro para que pase unha proba converte unha decisión de política nun accidente.

Manteña os dous rexistros separados no documento de deseño, porque un lector que só ve o selector inferirá unha autorización que nunca se concedeu. Dúas liñas nun rexistro de cambios evítano e levan menos tempo que a discusión que segue.

Describa un fluxo desde ambos os extremos

Anote o iniciador, o respondedor, a orixe e o destino tal como se presentan, o protocolo e ambos os portos. Despois inverta cada unha desas etiquetas para o outro extremo, porque o porto de orixe efémero dun cliente pasa a ser o porto de destino dunha resposta e a rede remota convértese na local. Unha configuración copiada dun lado ao outro sen esa inversión é a forma en que os filtros acaban permitindo exactamente a dirección equivocada. Escriba a táboa unha vez e construa ambos os filtros a partir dela.

Acorde o modelo de selección antes de copiar nada, porque un deseño baseado en políticas e un deseño baseado en rutas expresan a mesma intención mediante obxectos distintos. Escriba o nome do modelo xunto ao fluxo, ou o seguinte enxeñeiro pasará unha tarde emparellando obxectos que nunca foron comparables.

Atope o filtro que realmente se aplica

Nun ASA, o filtro VPN é unha ACL asociada a unha política de grupo e aplicada ao tráfico despois do descifrado e antes da cifraxe. A documentación de políticas de grupo de Cisco tamén describe a herdanza, incluído un valor a nivel de usuario que substitúe o valor da política de grupo. Así que a ACL que editou pode non ser a ACL que goberna a sesión que ten diante. O mesmo ocorre co obxecto de usuario, que pode impoñerse ao grupo sen deixar moito rastro visible.

Inspeccione a sesión efectiva en lugar do obxecto que recorda ter cambiado, e anote que obxecto de política a proporciona. Ese único paso resolve unha cantidade sorprendente de informes do tipo o filtro é correcto pero non funciona.

Dirección, portos e o caso inverso

A convención documentada sitúa a rede remota, ou os enderezos asignados aos clientes remotos, na posición de orixe e a rede local na posición de destino, coas respostas expresadas intercambiando as posicións dos enderezos. As regras de portos apoian sobre esa convención e merecen máis coidado que os enderezos.

O modelo documentado pode permitir que unha regra de porto de destino afecte a unha iniciación inversa que usa ese mesmo porto de orixe, o que significa que o filtro non é simplemente unha regra de petición unidireccional con respostas inofensivas. Razoe explicitamente ambas as direccións de iniciación e inclúa o caso que pretende denegar.

A mesma documentación limita o filtro ás conexións iniciais, así que non é unha aplicación universal de cada canal secundario que abre unha aplicación inspeccionada. Cando a política completa necesita esa cobertura, pertence a un límite aparte en lugar de a unha ACL estirada máis alá do seu propósito.

Probe tres casos antes de dalo por terminado

Acepte o fluxo previsto, rexeite un servizo que a política prohibe e exercite o caso de dirección inversa que razoou. Execúteos baixo un plan aprobado coas mesmas identidades e selectores que vai despregar. Unha proba que só mostra que o servizo permitido funciona demostra o túnel, non a política.

Manteña a cobertura negociada e a decisión de acceso como dous rexistros, porque explicar que permite unha VPN require ambos.