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:

LegSourceDestination
Request from the internet198.51.100.25203.0.113.20:443
After destination translation198.51.100.2510.60.20.10:443
After source translation toward the tunnel10.10.250.1010.60.20.10:443
Branch reply10.60.20.1010.10.250.10
Restored reply to the client203.0.113.20198.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 l2l

O 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.

Artigos relacionados