Publicar un servicio interno por una VPN de sitio a sitio con ASA
Cinco comprobaciones ordenadas para exponer un servicio interno a través de una VPN de sitio a sitio con ASA: rango protegido, modelo de origen, traducción, alcance del puerto, ruta de respuesta.
Publicar un servicio que vive detrás de una VPN de sitio a sitio es una sola tarea con cinco puntos de fallo, y fallan en un orden fijo. El túnel se levanta, la traducción coincide, la sucursal responde y la respuesta vuelve por el mismo camino. Cuando cualquiera de esos está mal, el navegador muestra lo mismo: una conexión que se cuelga o se reinicia. Recorra la lista de arriba abajo y deténgase en la primera comprobación que falle.
Comprobación 1: el túnel protege la dirección de origen
Empiece por un túnel que ya pasa tráfico y luego confirme que la dirección que piensa publicar está dentro del rango protegido. En un ASA ese rango proviene de la ACL de criptografía o de las rutas de un VTI, y debe cubrir la dirección real del origen, no la subred que la sucursal usa para gestión. Un selector que no da con el origen le deja un túnel levantado y un flujo que nunca entra en él.
Confírmelo con los contadores del túnel y la tabla de rutas antes de tocar la traducción. Si no se llega al origen desde el concentrador a través del túnel, nada más adelante en esta lista puede repararlo.
Deténgase aquí si el rango protegido y la dirección de origen no coinciden.
Comprobación 2: decida qué origen verá la sucursal
La sucursal ve la dirección original del cliente o una traducida, y esa elección decide la ruta de vuelta. Conservar la dirección del cliente se lee más limpio en los registros del origen, pero entonces la sucursal debe devolver las respuestas de los clientes públicos por el túnel; una ruta por defecto normal de internet las envía al otro lado y la conexión muere en una dirección. Traducir el origen a una dirección que la sucursal ya encamina por el túnel elimina ese requisito.
La traducción también cambia lo que el origen puede registrar y con qué pueden coincidir las reglas basadas en origen. Si la aplicación necesita saber la persona detrás de una petición, eso corresponde a un proxy inverso autenticado, no a una decisión de NAT.
Comprobación 3: escriba la traducción contra las interfaces reales
Un ASA evalúa las reglas de traducción en orden e informa cuál coincidió, así que el par de interfaces dentro de la regla no es cosmético. Una regla escrita para un camino de fuera a dentro no coincidirá con un flujo cuya entrada y salida difieren de las que supuso.
El camino que construye tiene cuatro tramos, y los cuatro deben coincidir:
| Leg | Source | Destination |
|---|---|---|
| Request from the internet | 198.51.100.25 | 203.0.113.20:443 |
| After destination translation | 198.51.100.25 | 10.60.20.10:443 |
| After source translation toward the tunnel | 10.10.250.10 | 10.60.20.10:443 |
| Branch reply | 10.60.20.10 | 10.10.250.10 |
| Restored reply to the client | 203.0.113.20 | 198.51.100.25 |
Trate los rangos de esa tabla como marcadores de posición. Lo importante es que la tupla después de la traducción sea una dirección que la sucursal acepte por el túnel, y que el mapeo inverso exista en el estado de NAT para que la respuesta se restaure a la salida.
Comprobación 4: limite la regla de acceso al puerto publicado
Publique el puerto, no el host. Una regla que permite el origen en todos los servicios convierte una aplicación publicada en un camino hacia todo lo que ejecuta el origen, incluida la interfaz de gestión que mantuvo fuera de internet a propósito. Permita el puerto publicado desde el origen traducido hasta el origen y deje los servicios administrativos en su camino solo por VPN.
Compruebe el orden de las reglas al mismo tiempo. Un permiso amplio por encima de su regla específica hace invisible la regla específica.
Comprobación 5: rastree una petición y su respuesta
No empiece con un navegador, porque un navegador oculta qué tramo falló. Rastree el flujo en el concentrador y lea el resultado antes de cambiar nada.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lEl rastreo nombra la traducción que coincidió, la regla de acceso que permitió o denegó el flujo y si el paquete se encaminó al túnel. Si muestra el flujo saliendo por una interfaz que no esperaba, el par de interfaces de la regla de NAT es incorrecto. Si muestra una denegación, el orden de las reglas es incorrecto. Si llega al túnel pero el origen nunca responde, el problema es la ruta de vuelta de la sucursal.
Después envíe una petición real desde fuera y confirme que la respuesta vuelve por el mismo túnel. Registre la entrada publicada, la traducción, el par de direcciones protegido y la ruta de vuelta como el registro de publicación.