Publicar un servizo interno por unha VPN de sitio a sitio con ASA

Publicar un servizo que vive detrás dunha VPN de sitio a sitio é unha soa tarefa con cinco puntos de fallo, e fallan nunha orde fixa. O túnel levanta, a tradución coincide, a sucursal responde e a resposta volve polo mesmo camiño. Cando calquera deses está mal, o navegador amosa o mesmo: unha conexión que se colga ou se reinicia. Percorra a lista de arriba abaixo e detéñase na primeira comprobación que falle.

Comprobación 1: o túnel protexe o enderezo de orixe

Comece por un túnel que xa pasa tráfico e despois confirme que o enderezo que pensa publicar está dentro do rango protexido. Nun ASA ese rango vén da ACL de cifrado ou das rutas dun VTI, e debe cubrir o enderezo real da orixe, non a subrede que a sucursal usa para xestión. Un selector que non dá coa orixe déixalle un túnel levantado e un fluxo que nunca entra nel.

Confírmoo cos contadores do túnel e a táboa de rutas antes de tocar a tradución. Se non se chega á orixe desde o concentrador a través do túnel, nada máis adiante nesta lista pode repoñelo.

Detéñase aquí se o rango protexido e o enderezo de orixe non coinciden.

Comprobación 2: decida que orixe verá a sucursal

A sucursal ve o enderezo orixinal do cliente ou un traducido, e esa escolla decide a ruta de volta. Conservar o enderezo do cliente lese máis limpo nos rexistros da orixe, pero entón a sucursal debe devolver as respostas dos clientes públicos polo túnel; unha ruta por defecto normal de internet envíaas cara ao outro lado e a conexión morre nunha dirección. Traducir a orixe a un enderezo que a sucursal xa encamiña polo túnel elimina ese requisito.

A tradución tamén cambia o que a orixe pode rexistrar e con que poden coincidir as regras baseadas en orixe. Se a aplicación necesita saber a persoa detrás dunha petición, iso corresponde a un proxy inverso autenticado, non a unha decisión de NAT.

Comprobación 3: escriba a tradución contra as interfaces reais

Un ASA avalía as regras de tradución en orde e informa cal coincidiu, así que o par de interfaces dentro da regra non é cosmético. Unha regra escrita para un camiño de fóra a dentro non coincidirá cun fluxo cuxa entrada e saída difiren das que supuxo.

O camiño que constrúe ten catro tramos, e os catro deben coincidir:

Trate os rangos desa táboa como marcadores de posición. O importante é que a tupla despois da tradución sexa un enderezo que a sucursal acepta polo túnel, e que o mapeo inverso exista no estado de NAT para que a resposta se restaure á saída.

Comprobación 4: limite a regra de acceso ao porto publicado

Publique o porto, non o host. Unha regra que permite a orixe en todos os servizos converte unha aplicación publicada nun camiño cara a todo o que executa a orixe, incluída a interface de xestión que mantivo fóra de internet a propósito. Permita o porto publicado desde a orixe traducida ata a orixe e deixe os servizos administrativos no seu camiño só por VPN.

Comprobe a orde das regras ao mesmo tempo. Un permiso amplo por riba da súa regra específica fai invisible a regra específica.

Comprobación 5: rastrexar unha petición e a súa resposta

Non comece cun navegador, porque un navegador agocha que tramo fallou. Rastree o fluxo no concentrador e lea o 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 l2l

O rastrexo nomea a tradución que coincidiu, a regra de acceso que permitiu ou denegou o fluxo e se o paquete se encamiñou ao túnel. Se amosa o fluxo saíndo por unha interface que non esperaba, o par de interfaces da regra de NAT é incorrecto. Se amosa unha denegación, a orde das regras é incorrecta. Se chega ao túnel pero a orixe nunca responde, o problema é a ruta de volta da sucursal.

Despois envíe unha petición real desde fóra e confirme que a resposta volve polo mesmo túnel. Rexistre a entrada publicada, a tradución, o par de enderezos protexido e a ruta de volta como o rexistro de publicación.