Retransmissão DHCP do ASA sobre uma VPN site a site: um guia passo a passo

A retransmissão funciona em três etapas e apenas a do meio atravessa a VPN. Um cliente difunde no segmento da filial, o ASA converte essa difusão numa solicitação unicast ao servidor DHCP, e o servidor responde ao endereço de retransmissão e não ao cliente. Percorra as etapas nessa ordem e a maioria dos casos de «a retransmissão está quebrada» resume-se a uma política em falta ou a uma linha setroute mal lida.

Etapa um: ative a retransmissão na interface voltada ao cliente

No ASA da filial, a retransmissão é uma propriedade da interface que olha para os clientes. O servidor pode ser declarado globalmente com a sua interface alcançável, ou sob essa interface voltada ao cliente para que a tabela de rotas escolha a saída. Essas duas formas não são intercambiáveis, e copiar a errada é o primeiro ponto onde um guia se desvia.

Verifique a configuração em execução antes de mudar qualquer coisa: qual interface tem a retransmissão ativada, qual forma de servidor está presente e se setroute está associado à interface do cliente. Se o ASA também executa um servidor DHCP para outro segmento, pare e leia a lista de restrições; servidor e retransmissão não podem estar ativos ao mesmo tempo no mesmo equipamento.

A retransmissão coloca o seu próprio endereço voltado ao cliente no campo de endereço de gateway. É esse endereço que o servidor vai responder, por isso tem de ser alcançável a partir do site remoto através do túnel, não apenas localmente.

Etapa dois: leve o tráfego gerado pelo ASA pelo túnel

Este é o passo que as pessoas saltam. Uma VPN site a site baseada em políticas costuma ser construída para o tráfego entre sub-redes, e o pedido de retransmissão é gerado pelo próprio ASA. Se a lista de acesso do túnel e o mapa criptográfico só corresponderem a fluxos de host da filial para a sub-rede do servidor, o pacote de retransmissão pode nunca entrar no túnel. Verifique a lista de acesso nos dois sentidos, não apenas a linha da filial para o servidor.

Confirme que o tráfego interessante cobre a origem de retransmissão do ASA e o endereço do servidor, e que o sentido de retorno também é permitido. Num desenho baseado em VTI a decisão de encaminhamento é mais simples, mas o suporte de retransmissão sobre VTI chegou numa versão específica; o guia de DHCP do ASA indica a 9.14(1), por isso verifique a imagem antes de copiar um exemplo VTI para um equipamento mais antigo.

Um ping do ASA ao servidor prova pouco por si só. Pode ter sucesso por outro caminho, com outro endereço de origem ou sob uma política que os pacotes da retransmissão não cumprem.

Etapa três: leia a resposta e a opção setroute

O RFC 2131 diz que o servidor envia a resposta para o endereço no campo giaddr quando esse campo não é zero. Portanto, o caminho de retorno tem de encaminhar para o endereço de retransmissão, e a política do túnel tem de permitir o sentido do servidor para a retransmissão. Se o pedido passou mas a oferta nunca chega, é aqui que se deve olhar.

Depois separe duas coisas que soam iguais. A palavra-chave setroute altera ou acrescenta a opção de router predefinido que o ASA entrega ao cliente. Não instala uma rota no ASA e não cria política de VPN. Um cliente que obtém um endereço mas não alcança nada costuma ter um problema de setroute ou de âmbito, não de túnel. Teste-o com um cliente sem gateway estático e observe que router predefinido aparece na oferta.

Leia a oferta do início ao fim: endereço oferecido, máscara, router predefinido, DNS e tempo de concessão. Depois deixe a concessão renovar. Uma retransmissão que funciona uma vez e falha na renovação costuma ter um problema de âmbito, de concessão ou de caminho de retorno que a primeira troca escondeu.

O que verifico antes de dizer que está resolvido

Comece pelo cliente e capture a difusão, depois confirme que o ASA a retransmitiu com o seu próprio endereço como giaddr. Do lado remoto, confirme que o servidor viu esse pedido e escolheu um âmbito que corresponde à filial. De volta à filial, confirme que o cliente aceitou a oferta e alcança o seu gateway.

Se alguma etapa estiver silenciosa, verifique a política ou a rota correspondente em vez de acrescentar outra instrução de retransmissão. A configuração da retransmissão costuma já estar correta quando alguém escala o caso; o que mudou foi a política do túnel ou a rota de retorno.

Escreva as três etapas no registo de alterações: interface voltada ao cliente, política de VPN que cobre o tráfego de retransmissão e a rota de retorno do servidor para giaddr. É esse registo que torna a próxima construção de uma filial um trabalho repetível em vez de uma sessão de depuração. Também diz ao engenheiro seguinte que saída de comando recolher primeiro.