* Обновление, выяснилось, что добавление дополнительных исключений nat остановило запуск dns doctoring, решив проблему.

Итак, у меня есть еще одна нерешенная проблема с настройкой vpn в нашем офисе.

Я могу успешно войти в VPN и получить IP-адрес 192.168.7.1 на внешнем интерфейсе. Затем я могу без проблем подключиться к любой из наших машин в диапазоне 192.168.xx по ssh. Однако, когда я делаю запрос DNS для одной из наших машин, размещенных в dmz, на наш внутренний DNS-сервер на 192.168.1.1, ответ DNS подделывается, чтобы предоставить мне общедоступный IP-адрес в диапазоне 91.xxx, а не 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]

Вот подходящие строки из нашей конфигурации 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
answer

Что ж, клиент находится на внешнем интерфейсе - лечение DNS действительно работает точно так, как задумано.

Вам действительно нужно включить лечение DNS для этого перевода? Вы обслуживаете общедоступный DNS с внутреннего сервера с внутренними адресами, и вам просто нужно лечить этот адрес на выходе?

Если нет, то просто оторвите dnsшнур, staticи все готово.

Если это так, подумайте о настройке DNS-сервера, который просто обслуживает общедоступный DNS.

Если вы настроены на сохранение включенного лечения, я могу придумать один уродливый обходной путь, который должен это сделать: два статических преобразования политики - один для случаев, когда пункт назначения является внутренним с отключенным лечением DNS, а затем более низкий приоритет с включенным лечением. Как я уже сказал: некрасиво.

Оказывается, просто добавление дополнительных исключений nat отключило лечение DNS. По сути, весь трафик с внешнего интерфейса, который находится в пуле IP-адресов vpn, должен быть идентифицирован как no-nat, чтобы правильно взаимодействовать с dmz и внутренними интерфейсами.