Que regra do ASA ve o tráfico despois de que o VPN o descifra

A primeira suposición que hai que descartar é que a ACL de criptografía sexa unha política de acceso. Non o é. Nun Cisco ASA, esa lista responde a unha pregunta moi concreta: que paquetes merecen protección, e esa resposta non di nada sobre se o paquete descifrado pode chegar ao servidor detrás da devasa. O acceso decídese máis adiante, mediante unha política de interface, un filtro de política de grupo ou ambos, segundo como se construíse o túnel.

A ACL de criptografía responde a outra pregunta

Unha ACL de criptografía é unha lista de coincidencias. Dille ao túnel que cifrar entre dous pares; un paquete que non coincide simplemente non queda protexido. Ampliala cambia o alcance da protección e nada máis.

Por iso engadir unha subrede alí pode erguer un túnel mentres a aplicación real segue fallando. O túnel está arriba porque agora existe unha coincidencia. A aplicación segue fallando porque nada nesa lista permite nada. Dúas preguntas distintas, respondidas por dúas listas distintas.

Que se salta realmente o axuste de omisión

sysopt connection permit-vpn permite que o tráfico protexido se salte a comprobación da ACL de interface que doutro xeito se aplicaría no lado de entrada. É unha comodidade para despregamentos de VPN e é global. Non toca a política de grupo nin toca un filtro de autorización por usuario.

Lea o valor real en lugar da suposición: show running-config all sysopt imprime o axuste mesmo cando nunca se configurou de forma explícita, e aí é onde comeza moita confusión.

Como o axuste é global, probalo como experimento rápido nunha subrede que falla é un mal intercambio. Todos os demais túneles dese firewall comparten o resultado. Gárdeo para un cambio deliberado cun plan de reversión.

Lea o filtro na dirección descifrada

Unha vpn-filter LAN-to-LAN escríbese desde o punto de vista do túnel, non da interface. A rede remota vai na posición de orixe e a rede local na de destino, porque así é como se ve o paquete despois do descifrado. O mesmo filtro avalíase despois outra vez na dirección oposta antes do cifrado, cos papeis dos enderezos invertidos.

As condicións de porto merecen máis coidado que unha ACL de interface copiada xustamente por ese motivo. Unha regra que permite un porto de destino pode ter un efecto non desexado na dirección inversa, onde unha conexión nova usa ese porto como orixe. Anote que lado pode iniciar, o servizo real e a contraparte que debe permanecer pechada antes de construír a lista.

Confirme que filtro está realmente asociado: show running-config group-policy e show vpn-sessiondb detail l2l xuntos indican que herdou a sesión. Editar unha ACL á que ningunha política fai referencia non cambia nada.

Non reutilice un só obxecto ACL para dous traballos

Unha access-group de interface e unha vpn-filter parecen o mesmo tipo de obxecto e avalíanse en puntos distintos con orientacións de enderezo distintas. Asignar unha lista a ambas invita a un cambio que arranxa o túnel e afrouxa en silencio a interface física.

Mantéñaas separadas, nómbreas polo seu traballo e faga visible a diferenza de dirección nos nomes.

Verifique con conexións novas, en ambas as direccións

Tras un cambio planificado, abra unha conexión nova que deba permitirse e outra que deba denegarse, e logo anote os enderezos, a dirección e a coincidencia de política xunto co resultado. Unha sesión establecida non demostra nada sobre o filtrado de conexións novas, porque xa foi admitida coas regras antigas.

Conte tamén coa inspección. A documentación do fabricante sinala que un filtro VPN comproba a conexión inicial e non cada conexión secundaria que abre un motor de inspección, así que unha canle de control e o seu fluxo de medios asociado poden recibir un trato distinto. Se a aplicación coñece o protocolo, probe o fluxo real en lugar dunha soa sonda de porto.

Un túnel que se volve utilizábel tras unha omisión ampla di que a restrición se eliminou, non que se cumprise. O resultado que paga a pena conservar é un punto de aplicación con nome ao que poida sinalar na próxima revisión.