Acontece que apenas adicionando exclusões nat, isso desativou a dns doctoring. Essencialmente, todo o tráfego da interface externa que está no pool VPN vpn precisa ser identificado como no-nat para falar corretamente com as interfaces dmz e interna.
* Atualização, acontece que adicionando exclusões nat não impediram que o dns doctoring fosse acionado, resolvendo o problema.
Portanto, tenho um último problema pendente com a nossa configuração de VPN para o nosso escritório.
Eu posso vpn com sucesso e ser alocado um ip 192.168.7.1 na interface externa. Eu posso então ssh para qualquer uma das nossas máquinas no interior 192.168.x.x range sem qualquer problema. No entanto, quando eu faço um pedido de dns para uma das nossas máquinas hospedadas dmz para o nosso servidor dns interno em 192.168.1.1, a resposta do dns é manipulada para me dar o ip público no intervalo 91.xxx, não o ip 10.1.16.34.
10.1.0.x
192.168.x.x dmz 91.x.x.x
[inside | cisco asa 5510| outside]
|
|allocated 192.168.7.x
|
|
[cisco vpn client]
Aqui estão as linhas pertinentes da nossa configuração do IOS.
access-list inside_nat0 extended permit ip 192.168.0.0 255.255.240.0 10.1.16.0 255.255.252.0 access-list inside_nat0 extended permit ip 192.168.7.0 255.255.255.224 192.168.0.0 255.255.240.0 access-list inside_nat0 extended permit ip 192.168.0.0 255.255.240.0 192.168.7.0 255.255.255.224 //added to fix access-list outside_nat0 extended permit ip 192.168.7.0 255.255.255.224 10.1.16.0 255.255.252.0 access-list outside_nat0 extended permit ip 10.1.16.0 255.255.252.0 192.168.7.0 255.255.255.224 nat (inside) 0 access-list inside_nat0 nat (inside) 1 0.0.0.0 0.0.0.0 nat (outside) 1 192.168.7.0 255.255.255.224 nat (dmz) 2 0.0.0.0 0.0.0.0 //added to fix nat (outside) 0 access-list outside_nat0 nat (dmz) 0 access-list outside_nat0 static (dmz,outside) 91.x.x.x 10.1.16.34 netmask 255.255.255.255 dns tcp 1000 100 udp 1000
! class-map inspection_default match default-inspection-traffic ! ! policy-map type inspect dns preset_dns_map parameters message-length maximum 512 policy-map global_policy class inspection_default inspect dns preset_dns_map inspect ftp inspect h323 h225 inspect h323 ras inspect rsh inspect rtsp inspect esmtp inspect sqlnet inspect skinny inspect sunrpc inspect xdmcp inspect sip inspect netbios inspect tftp inspect icmp ! service-policy global_policy global
Bem, o cliente está na interface externa - a manipulação do DNS está se comportando exatamente como deveria, na verdade.
Você realmente precisa do tratamento de DNS ativado nessa tradução? Você está servindo DNS público a partir de um servidor interno com os endereços internos, e apenas ter um médico pega esse endereço ao sair pela porta?
Se não, basta cortar o dns da sua linha static e está tudo pronto.
Nesse caso, considere a configuração de um servidor DNS que apenas atenda ao DNS público.
Se você está preparado para manter o doutorado habilitado, posso pensar em uma solução alternativa feia que deve ser feita: duas traduções estáticas de política - uma para quando o destino é interno com a desmarcação do DNS; ativado. Como eu disse: feio.