Publicar um serviço interno através de uma VPN site-to-site ASA
Cinco verificações ordenadas para expor um serviço interno através de uma VPN site-to-site ASA: intervalo protegido, modelo de origem, tradução, âmbito da porta, caminho de resposta.
Publicar um serviço que vive atrás de uma VPN site-to-site é uma única tarefa com cinco pontos de falha, e eles falham numa ordem fixa. O túnel sobe, a tradução coincide, a filial responde e a resposta volta pelo mesmo caminho. Quando qualquer um deles está errado, o navegador mostra a mesma coisa: uma ligação que fica pendurada ou é reiniciada. Percorra a lista de cima para baixo e pare na primeira verificação que falhar.
Verificação 1: o túnel protege o endereço de origem
Comece por um túnel que já transporta tráfego e depois confirme que o endereço que pretende publicar está dentro do intervalo protegido. Num ASA esse intervalo vem da ACL de criptografia ou das rotas de um VTI, e tem de cobrir o endereço real da origem, não a sub-rede que a filial usa para gestão. Um seletor que falha a origem dá-lhe um túnel de pé e um fluxo que nunca entra nele.
Confirme com os contadores do túnel e a tabela de rotas antes de tocar na tradução. Se a origem não for alcançável a partir do hub através do túnel, nada mais adiante nesta lista o pode reparar.
Pare aqui se o intervalo protegido e o endereço de origem não coincidirem.
Verificação 2: decida que origem a filial vai ver
A filial vê o endereço original do cliente ou um endereço traduzido, e essa escolha decide o caminho de retorno. Preservar o endereço do cliente lê-se mais limpo nos registos da origem, mas então a filial tem de devolver as respostas dos clientes públicos pelo túnel; uma rota predefinida normal de internet envia-as para o outro lado e a ligação morre numa direção. Traduzir a origem para um endereço que a filial já encaminha pelo túnel elimina esse requisito.
A tradução também altera o que a origem pode registar e com o que as regras baseadas na origem podem coincidir. Se a aplicação precisa de saber a pessoa por trás de um pedido, isso pertence a um proxy inverso autenticado, não a uma decisão de NAT.
Verificação 3: escreva a tradução contra as interfaces reais
Um ASA avalia as regras de tradução por ordem e informa qual coincidiu, por isso o par de interfaces dentro da regra não é cosmético. Uma regra escrita para um caminho de fora para dentro não coincide com um fluxo cuja entrada e saída diferem das que assumiu.
O caminho que está a construir tem quatro troços, e os quatro têm de 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 os intervalos dessa tabela como marcadores de posição. O importante é que o tuplo depois da tradução seja um endereço que a filial aceita pelo túnel, e que o mapeamento inverso exista no estado de NAT para que a resposta seja restaurada à saída.
Verificação 4: limite a regra de acesso à porta publicada
Publique a porta, não o anfitrião. Uma regra que permite a origem em todos os serviços transforma uma aplicação publicada num caminho para tudo o que a origem executa, incluindo a interface de gestão que manteve fora da internet de propósito. Permita a porta publicada desde a origem traduzida até à origem e deixe os serviços administrativos no seu caminho apenas por VPN.
Verifique a ordem das regras ao mesmo tempo. Uma permissão ampla acima da sua regra específica torna a regra específica invisível.
Verificação 5: rastreie um pedido e a sua resposta
Não comece por um navegador, porque um navegador esconde qual troço falhou. Rastreie o fluxo no hub e leia o resultado antes de mudar o que quer que seja.
packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2lO rastreio nomeia a tradução que coincidiu, a regra de acesso que permitiu ou negou o fluxo e se o pacote foi encaminhado para o túnel. Se mostrar o fluxo a sair por uma interface que não esperava, o par de interfaces da regra de NAT está errado. Se mostrar uma negação, a ordem das regras está errada. Se chegar ao túnel mas a origem nunca responder, o problema é o caminho de retorno da filial.
Depois envie um pedido real de fora e confirme que a resposta volta pelo mesmo túnel. Registe a entrada publicada, a tradução, o par de endereços protegido e a rota de retorno como o registo de publicação.