Un poco de planificación de configuración de 'cinturón y tirantes'
Antecedentes:
Tenemos un enlace VPN de sitio a sitio exitoso a nuestro centro de datos remoto.
La red remota 'protegida' también es el rango de red IP que se abre a través del firewall como puntos finales de Internet.
Así : Usamos la VPN para poder acceder a puntos finales no públicos.
Planteamiento del problema :
Si el enlace VPN está inactivo, el ASA elimina el tráfico, a pesar de que los puntos finales de Internet todavía deberían estar disponibles a través del firewall remoto.
Pregunta :
¿Cómo puedo configurar la VPN para 'pasar' el tráfico como tráfico saliente normal, cuando la VPN está inactiva?
Aquí están los segmentos pertinentes de la configuración.
crypto map vpn-crypto-map 20 match address remdc-vpn-acl
crypto map vpn-crypto-map 20 set peer a.b.c.d
crypto map vpn-crypto-map 20 set transform-set remdc-ipsec-proposal-set
crypto map vpn-crypto-map interface outside
La ACL para el tráfico coincidente es muy primitiva: especifica las dos redes, privada y remota, expresadas como objetos de red.
access-list remdc-vpn-acl extended permit ip object <private> object <remote> log
Y un diagrama primitivo.
INTERNET
x
x
REM DC 203.000.113.000/24 xx HQ 192.168.001.000/24
x
+---------------+ x +-----------+
| REMOTE DC | xx | |
| ASA e xxx | ASA 5505 |
+----------+ | xx | +-----------------+
^ | e<-------------------------------------+ |
| | | xxxx | |
| | e xxxx | ~ |
| | | xx | | |
| | | xx +----vpn----+
| | | x |
\-------vpn-------------vpn--------------------------------------/
| | xxx
+---------------+ xx
xxx
xx
xxxx
e = public Internet x
server endpoint
Gracias
Robar
Actualización 01
Una ACL más precisa se ha discutido en los comentarios a continuación (con agradecimiento)
Puedo imaginar dos ACLS. (A) que permite TODOS a la red remota y luego niega los puntos finales que ya están disponibles en Internet. y (B) que abre solo la gestión / instrumentación según sea necesario.
El problema con (B) es que expresar puntos finales como WMI y Windows RPC no es práctico sin modificar la configuración estándar del servidor)
Entonces, quizás (A) es el mejor enfoque que se convierte en un inverso de la configuración del firewall remoto .
Actualización 02
Mike ha pedido ver más de la configuración de ios del ASA.
Lo que sigue es para el HQ ASA que está en el sitio HQ. El DC remoto está bajo el control del proveedor del centro de datos, por lo que no puedo comentar exactamente cómo se puede configurar.
Bueno, no hay mucho que mostrar: hay una ruta predeterminada a la puerta de enlace de Internet y no hay otras rutas específicas.
route outside 0.0.0.0 0.0.0.0 HQInetGateway 1
Las interfaces son muy básicas. Solo configuración básica de IPv4 y vlans para dividir el grupo en 1 interfaz externa y 1 interfaz interna.
interface Vlan1
nameif inside
security-level 100
ip address 10.30.2.5 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 194.28.139.162 255.255.255.0
!
Saludos, Rob
Respuestas:
Ahora soy de la opinión de que esto no es práctico; al menos en nuestro escenario particular.
El esquema se complica aún más por el hecho de que ACL selecciona el tráfico "hacia el túnel" entre HQ y RemoteDC, (por lo que podemos hacerlo tan complicado como queramos), pero en el "camino" inverso (por así decirlo) El concentrador VPN en el extremo remoto está seleccionando toda la red HQ como la red protegida.
El resultado es que estos no se equilibran y parece que las xlate hacia adelante y hacia atrás no coinciden. Similar a tener rutas hacia adelante y hacia atrás que causan fallas en el tráfico porque NAT está en juego en algún momento.
Esencialmente, esto se está descartando como "riesgo técnico demasiado alto" y requiere mucha más evaluación y posiblemente más control sobre el extremo remoto antes de que se convierta en una solución.
Gracias a todos los que vieron esto.
fuente
Si tiene o puede instalar un enrutador en el interior de cada ASA, puede crear un túnel GRE encriptado y usar enrutamiento o una estática flotante para fallar a Internet.
fuente