* Обновление, оказалось, что добавление дополнительных исключений nat остановило запуск днс-врачевания, решив проблему.
Итак, у меня есть еще одна нерешенная проблема с настройкой vpn в нашем офисе.
Я могу успешно войти в VPN и получить IP-адрес 192.168.7.1 на внешнем интерфейсе. Затем я могу без проблем подключиться к любой из наших машин в диапазоне 192.168.x.x по ssh. Однако, когда я делаю запрос DNS для одной из наших машин, размещенных в dmz, на наш внутренний DNS-сервер на 192.168.1.1, ответ DNS подделывается, чтобы предоставить мне общедоступный IP-адрес в диапазоне 91.x.x.x, а не 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
Оказывается, просто добавление дополнительных исключений nat отключило лечение DNS. По сути, весь трафик с внешнего интерфейса, который находится в пуле ip-адресов vpn, должен быть идентифицирован как no-nat для правильного взаимодействия с dmz и внутренними интерфейсами.
Что ж, клиент находится на внешнем интерфейсе - лечение DNS действительно работает точно так, как задумано.
Вам действительно нужно включить лечение DNS для этого перевода? Вы обслуживаете общедоступный DNS с внутреннего сервера с внутренними адресами и просто хотите, чтобы врачи перехватили этот адрес на выходе?
Если нет, то просто порви dns от твоего static линия, и все готово.
Если это так, подумайте о настройке DNS-сервера, который просто обслуживает общедоступный DNS.
Если вы настроены на сохранение включенного лечения, я могу придумать один уродливый обходной путь, который должен это сделать: два статических преобразования политики - один для случаев, когда пункт назначения является внутренним с отключенным лечением DNS, а затем более низкий приоритет с включенным лечением. Как я уже сказал: некрасиво.