Split dns cisco настройка
Система распределения доменных имен DNS и протокол динамической настройки узла DHCP являются очень важными для сетей, особенно для сети Интернет, так как позволяют настроить доступ к интернету, сконфигурировать браузер и т.д. На предыдущих уроках мы уже рассматривали настройку DHCP-сервера, так что не будем терять время и приступим к уроку.
Сегодня мы рассмотрим три темы: работу DNS, настройку DNS и проблемы, которые могут встретиться при использовании этой системы, а также настройку и проблемы DHCP. Перед тем, как двинуться дальше, мы должны рассмотреть несколько вещей. Они не являются частью тематики курса CCNA, но нужны для понимания базовых понятий того, как осуществляется хостинг нового веб-сайта. Если вас интересует создание сайтов, вы хотите узнать о HTML, CSS, PHP, Java-script, хочу сказать, что я собираюсь сделать новую серию видеоуроков о том, как создавать сайты. Однако учитывая, что я занимаюсь этим в свободное от основной работы время, эта серия выйдет ещё не скоро. Пока же я хочу рассказать о некоторых основах сайтостроительства, касающихся не столько разработки сайтов, сколько хостинга и сетевого обеспечения работы веб-страниц.
Существует два типа DNS-серверов: приватный, или внутренний, и публичный, или внешний. В первом случае у нас может быть сеть из 100 компьютеров, которые нуждаются в локальном доменном имени. Например, для использования файлового сервера компании, который расположен на хосте с неким IP-адресом, вам не нужно будет набирать и помнить этот адрес, если вы будете пользоваться простым доменным именем fileserver. При этом администратор сети может поменять IP-адрес файлового сервера в любое время, и это никак не отразится на пользователях локальной сети.
Существует очень популярный публичный резольвер, которым пользуются все – это Google DNS, который имеет IP-адрес 8.8.8.8. Google имеет множество резольверов, которые хранят в своих кешах огромное количество адресов самых разных ресурсов, поэтому обращение к Google и получение ответа происходит намного быстрее. А теперь давайте перейдем к рассмотрению DHCP.
Если вы помните, мы уже говорили об этом протоколе в одном из первых видеоуроков. DHCP организует процесс получения устройством IP-адреса и других параметров, которые нужны для работы в сети по протоколам TCP/IP. Устройства Cisco используют сервер DHCP, параметры которого настраиваются в режиме глобальной конфигурации роутера. Для этого используется команда ip dhcp pool , с помощью которой на роутере настраивается DHCP-пул, затем команда network , указывающая, для какой именно подсети он настраивается. В качестве идентификатора сети используется IP-адрес сети /24 и маска подсети 255.255.255.0. Слеш 24 указывает на то, что в сети может быть 254 возможных адресов, приписанные к данному DHCP-пулу.
Далее необходимо указать default router, который представляет собой IP-адрес шлюза по умолчанию, и указать сам DNS –сервер, обозначив его IP-адрес. Например, если в качестве DNS-сервера указать адрес 8.8.8.8, то DHCP сообщит этот адрес всем клиентам пула.
Предположим, в вашей сети 192.168.1.0 имеется DHSP-сервер, файловый сервер и веб-сервер. Тогда эти устройства будут иметь последний октет IP-адреса соответственно .1, .2 и .3. Допустим, у вас появился новый клиент, который обращается к DHCP-серверу с запросом на получение IP-адреса. При этом сервер не должен присвоить ему адреса .2 и .3, потому что они уже заняты другими устройствами. В данном случае нужен запрет на те адреса, которые нельзя присваивать новым устройствам, входящим в сеть.
Приведу пример, как можно реализовать данный запрет. В этом случае задается диапазон IP-адресов, которые DHCP-сервер не должен присваивать клиентам. Я покажу вам этот процесс в программе Packet Tracer. Вы видите топологию сети, в которой первый роутер играет роль DHCP-сервера.
Таким образом, нам нужен механизм, позволяющий создавать несколько пулов для работы с устройствами, расположенными в разных подсетях. Для организации работы DHCP-сервера с несколькими подсетями нужно зайти в настройки роутера и присвоить его интерфейсам IP-адреса, которые я обозначил на схеме.
Сначала я вхожу в глобальный режим настроек и ввожу команду hostname DHCP_server, после чего присваиваю интерфейсу f0/0 IP-адрес командой ip address 192.168.1.1 255.255.255.0 и добавляю команду no shutdown. Интерфейсу f0/1 присваивается адрес 192.168.2.1.
Теперь создадим пул IP-адресов. Для этого используется команда ip dhcp pool, в которой нужно указать название пула, чтобы затем перейти в режим подкоманд созданного пула, указать диапазон свободных IP-адресов пула и пассивный сервер DHCP-relay.
Итак, я создаю пул под названием NET1 с помощью команды ip dhcp pool NET1, нажимаю «Ввод» и перехожу к подкомандам. Система выдает подсказку, какие параметры можно настроить.
Можно указать роутер по умолчанию default-router, имя DNS-сервера dns-server, команда exit позволяет выйти из настроек DHCP-пула, параметр network позволяет указать номер сети и маску, команда no отменяет все изменения и сбрасывает к настройкам по умолчанию, а option позволяет указать функции Raw DHCP.
Начнем с того, что укажем роутер по умолчанию, то есть укажем IP-адрес 192.168.1.1. Это означает, что если компьютер PC0 или PC1 захочет получить IP-адрес, он должен будет обратиться к шлюзу, который имеет этот адрес. Этот параметр вводится командой default-router 192.168.1.1. Далее нужно указать, для какой сети настроен данный пул. Для этого используется команда network 192.168.1.0 255.255.255.0.
Теперь нужно указать DNS-сервер, который на нашей схеме имеет IP-адрес 192.168.1.2. Для этого я ввожу команду dns-server 192.168.1.2 без указания маски подсети.
Закончив настройку DHCP-сервера, перейдем к настройке DNS-сервера. Для этого я щелкаю по иконке этого устройства и захожу на вкладку IP configuration. В данном случае используется статический IP-адрес 192.168.1.2, адрес шлюза по умолчанию 192.168.1.1, а в качестве DNS-сервера устройство указывает само себя, то есть IP-адрес 192.168.1.2.
Теперь можно перейти к настройкам веб-сервера. Я точно также захожу в настройки IP и ввожу нужные параметры.
Теперь я перейду к компьютеру PC0 и настрою DHCP. Для этого я отправлю запрос, и как видите, DHCP тут же автоматически ответит компьютеру, заполнив строки информацией. Таким образом PC0 получит свой IP-адрес 192.168.1.4
Данный адрес с последним октетом .4 был автоматически сконфигурирован с учетом того, что в сети уже присутствуют устройства с адресами .1, .2 и .3. Однако если вы вручную присвоите IP-адрес какому-либо устройству в этой сети, может возникнуть IP-конфликт, потому что DHCP-сервер не будет знать, что вы уже присвоили компьютеру, например, адрес 192.168.1.3, и может автоматически присвоить этот же адрес другому устройству.
Перейдем к компьютеру PC1 и проделаем то же самое. Мы видим, что сервер присвоил ему следующий доступный IP-адрес 192.168.1.12, шлюз по умолчанию имеет адрес 192.168.1.1, а DNS-сервер — 192.168.1.2.
Я проделаю то же самое с PC1, и как видите, нажатие на кнопку Go не приводит ни к какому результату. Позвольте мне снова подключить DNS-сервер к свитчу и еще раз запустить браузер компьютера PC0. Технически, если информация о сайте сохранилась в кеше браузера, вам не нужна связь с DNS-сервером, чтобы получить доступ к этому сайту, потому что компьютер автоматически обратится напрямую к веб-серверу.
Обратимся снова к нашему DHCP-серверу и организуем пул для второй сети, в которой находится компьютер PC2, я назову эту сеть NET2. Для этого я последовательно ввожу команды ip dhcp pool NET2 и network 192.168.3.0 255.255.255.0. Затем я ввожу IP-адрес DNS-сервера, общий для обеих сетей — 192.168.1.2 и назначаю роутер по умолчанию. Поскольку дело касается сети 3.0, в качестве default router я указываю второй роутер Router1 с IP-адресом 192.168.3.2.
В данном случае APIPA назначила компьютеру случайный IP-адрес 169.254.133.157. Это нормально и мы знаем, почему так произошло. Однако нам нужно, чтобы Router1, получив запрос на IP-адрес, отправил его по сети дальше к DHCP-серверу, то есть нам нужно, чтобы этот роутер выполнял роль пассивного сервера DHCP-relay. Перед тем, как заняться его настройкой, вернемся к первому роутеру DHCP-server и включим функцию RIP-маршрутизации.
Затем перейдем ко второму роутеру Router1 и выполним аналогичные настройки, чтобы оба эти устройства могли связываться по протоколу RIP.
Теперь нужно настроить внешний интерфейс f0/1, указав для него вспомогательный адрес helper-address. Команда helper-address служит для пересылки широковещательного DHCP-запроса на указанный адрес, в нашем случае это 192.168.2.1.
Теперь любой DHCP-запрос компьютера PC2 будет автоматически пересылаться DHCP-серверу. Попробуем еще раз включить DHCP, и непонятно почему, но наш компьютер снова использует APIPA – запрос с DHCP-серверу остался без ответа.
Попробуем разобраться с проблемой, для этого я захожу в настройки Router1 и ввожу команду ping 192.168.2.1. Пинг не проходит, поэтому я по-быстрому проверю интерфейсы DHCP-сервера, используя команду show ip int brief, и обнаруживаю ошибку. Да, я бы не сдал экзамен с такими знаниями! Поэтому, ребята, нужно практиковаться, чтобы не делать подобных ошибок. Сейчас я её исправлю.
Я забыл использовать в настройках DHCP-сервера важную команду, и сейчас введу её для интерфейса f0/1: ip add 192.168.2.1 255.255.255.0. Это просто досадная ошибка, которую я исправил. Теперь снова заходим в настройки PC2 и включаем DHCP. Что, опять? Запрос снова не проходит!
Я снова проверяю настройки Router1. C таблицей маршрутизации все в порядке, все нужные записи присутствуют, в чем же проблема? Вспомогательный адрес тоже назначен правильно. Ну ничего, в конце концов я найду причину.
Я снова возвращаюсь к настройкам DHCP-сервера и ввожу команду show ip route. Выясняется, что маршрута не существует, потому что я не указал версию протокола. Я исправляю эту ошибку, и теперь все должно заработать.
Я возвращаюсь к PC2 и снова включаю DHCP – теперь все нормально, компьютер получает IP-адрес 192.168.3.6, присвоенный ему DHCP-сервером. Из-за своей невнимательности я допустил ошибку и потратил время на её поиск, так что прошу меня простить.
Вот таким образом работает пассивный сервер DHCP-relay, который использует helper-address. Как видите, все очень просто и понимание изложенной темы не должно представлять для вас особых сложностей. Владение основами DNS и DHCP очень важно для подключения ваших компьютеров к сети.
Как я уже говорил, мы приближаемся к концу тематики, необходимой для сдачи первого экзамена CCNA, нам осталось еще несколько важных видеоуроков, в частности, ASL, NAT и PAT. Прошу не беспокоиться по поводу несовместимости видеоуроков старой и новой версий CCNA – я своевременно добавляю новые серии и удаляю не нужные, так что вы будете изучать только актуальные темы.
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Cisco router можно настроить в качестве кеширующего DNS сервера. Это удобно в небольших офисах, где нет серверов Windows и AD.
Общий вид команд выглядит следующим образом:
ip domain lookup - включает трансляцию имён в ip адреса основанную на dns. Этот параметр включен по умолчанию. Часто его выключают чтобы маршрутизатор не "зависал" при вводе ошибочной команды, но для нашей цели его необходимо включить.
ip name-server - этот параметр задаёт адрес одного или нескольких серверов имён (dns). Приоритет определяется сверху вниз.
ip domain name - задаёт имя домена по умолчанию для пользователей Cisco IOS software для разрешения "неопознаных" доменных имён (имена без суффикса.
ip dns server - включаем собственно кеширующий DNS сервер на циске
Конструкция ip host name1 192.168.0.11 работает подобно файлу hosts в windows.
Проверка:
show ip dns view
Предыдущий конфиг приводит к тому, что роутер будет отвечать на все запросы DNS: как изнутри так и снаружи.
Для того, чтобы DNS сервер отвечал только на внутренние запросы у нас есть два пути:
Приведём здесь стандартный ACL, который в том числе запрещает доступ к нашему DNS через внешний интерфейс, и при этом разрешает DNS-запросы наружу:
В данном случае мы можем использовать функционал Split DNS:
Step Five
The last step is setting your router to use the view-list defined above and activating the DNS service.
You’ll need to adjust the above to suit your environment but once done you should have split DNS!
We recently deployed a remote office in China, where we were tunneling all traffic back to a central location to be filtered by a proxy. It didn’t take long for complaints of slowness to start coming in, and understandably so. At the time we had no way of filtering the traffic through a local proxy, but this later changed and we were able to take advantage of Websense in the cloud (look for a future article on this). We ended up sending Internet traffic out locally from the site, filtered by a Websense agent and expected all of the complaints to disappear. But they didn’t. After looking into the issue one of our engineers found that we didn’t think about how DNS traffic would flow in this setup. While Internet traffic itself was leaving the site locally, DNS traffic was still coming back to the US for resolution. This presents two main problems:
- The DNS request/response had to come back to the US, which takes about 300 ms RTT. That’s 300 ms extra time added on to however long it takes to load your site.
- Since the DNS request was taking place in the US, any website that uses a service like Akamai or some other geographical load balancing was serving up the sites closest to the US. So you wind up with Internet traffic leaving the office in China locally, and then still coming all the way back to the ‘best’ server closest to where the DNS resolution was done in the US. Really no better then you were to start.
This presented a problem. How do we perform DNS lookups for all of the Internet sites using some local Chinese ISP DNS, while still sending DNS requests for internal sites and websites to our own internal corporate servers. A quick google turned up a Cisco feature called split DNS which did exactly this.
The concept behind split DNS is pretty straightforward. Cisco allows you to setup multiple DNS views, each with a different DNS server, that directs traffic based on certain parameters that you pick. To make this work you also end up changing your clients to point to the router interfaces themselves for DNS servers, and the router then forwards on the request to the appropriate DNS server depending on the criteria you set. In our case we were using the Cisco router for DHCP as well, so we modified the Cisco DHCP scope to include the router itself as the DNS server.
Привет habr! В данной заметке хотел бы обсудить тему пересечения адресных пространств при предоставлении доступа удалённым пользователям. Буду рассматривать удалённый доступ средствами VPN-клиента Cisco AnyConnect. В качестве VPN-концентратора рассмотрим Cisco ASA. Примеры, описываемые в этой статье, были сконфигурированы на ASA5505 с версией программного обеспечения 9.1(6)6. Используемая версия клиента Anyconnect – 4.1. В качестве подключаемых по VPN клиентских устройств использовались персональные компьютеры с ОС Windows 7 и 8.1.
У многих сотрудников, желающих работать удалённо, для подключения к Интернет дома используются SOHO-маршрутизаторы, и очень часто маршрутизаторы установлены с заводскими настройками. А, как известно, в подавляющем большинстве случаев заводские настройки предполагают LAN-подсеть 192.168.0.0/24 или 192.168.1.0/24. Как показывает практика, вероятность наличия в центральном офисе (далее ЦО) компании сетей 192.168.0.0/24 и 192.168.1.0/24 велика. Получается пересечение адресных пространств. В данной заметке рассмотрю три варианта настроек подключений к ЦО через AnyConnect, выделю плюсы и минусы каждого варианта и опишу, как будет работать доступ в случае пересечении адресных пространств.
Первый вариант – самый простой. Заключается в отказе от Split tunneling (как мы помним Split tunneling позволяет указать, какой трафик нужно заворачивать в туннель, а какой не нужно). В данном случае абсолютно весь трафик заворачивается в VPN туннель. Данное поведение настраивается директивой split-tunnel-policy tunnelall в групповой политике VPN-подключения. При отключенном Split tunneling во время установления соединения из таблицы маршрутизации подключаемого устройства исчезает маршрут в локальную сеть и появляется новый маршрут по умолчанию с лучшей метрикой. Ниже примеры вывода route print windows-компьютера до установленного VPN-соединения и после подключения:
При этом, выход в Интернет для подключаемого устройства мы можем организовать только через Интернет-канал офиса, к которому пользователь и подключился. Заметим, при настроенном выходе в Интернет через ЦО, канал будет утилизироваться трафиком удалённого пользователя вдвое больше.
Для настройки Интернет доступа для удалённых подключений на Cisco ASA достаточно соблюсти два нюанса. Первый нюанс – корректно настроить dynamic nat|pat для пула адресов, выдаваемых AnyConnect. Пример настройки nat:
Второй нюанс – не забыть включить опцию same-security-traffic permit intra-interface.
Данная опция позволяет пакетам уходить с того же интерфейса, на который трафик был получен.
- Простота настройки;
- Единое поведение для всех удалённых пользователей вне зависимости от сетевых настроек подключаемого устройства.
- Необходимость настройки Интернет доступа для подключаемых пользователей через Интернет канал ЦО, и, как следствие, двойная утилизация канала ЦО Интернет-трафиком удалённого пользователя;
- Подключаемое устройство теряет доступ к собственной локальной сети. Например, сетевой принтер или сетевое хранилище в локальной сети становятся недоступны для пользователя во время сессии AnyConnect.
Второй вариант – использование политик Split tunneling. Политики Split tunneling бывают двух видов: Split Include и Split Exclude. В первом случае необходимо указать, какие сети нужно туннелировать, во втором – наоборот, указывается, какие сети не нужно заворачивать в туннель.
По нашему опыту Split Include используется наиболее часто. В этом случае необходимо настроить список доступа, который будет определять, какие именно сети нужно туннелировать. Пример настройки:
В случае пересечения адресных пространств удалённый пользователь попросту теряет доступ к своей локальной сети. То есть, если у пользователя локальная сеть 192.168.0.0/24 или 192.168.1.0/24, трафик к хостам данных сетей будет заворачиваться в туннель. При этом, Интернет-доступ для удалённого пользователя останется через локального Интернет-провайдера. По нашему опыту данная настройка устраивает пользователей в большинстве случаев.
Split Tunneling вида Split Exclude, наоборот, позволяет удалённым пользователям сохранить доступ к собственной локальной сети в любом случае. Безусловно, в случае пересечения адресных пространств доступ в конфликтную сеть ЦО работать не будет. Ниже приведём пример настройки Split Exclude. В список доступа в этом случае будем включать сети, которые не нужно туннелировать. В примере мы не будем туннелировать диапазоны публичных адресов (это обеспечит выход в Интернет с использованием локального Интернет-провайдера), а также не будем туннелировать сеть вида 0.0.0.0/255.255.255.255, описывающую в настройках ASA локальную сеть клиента. Запись сети 0.0.0.0/255.255.255.255 помогает достичь универсальности: не зависимо от того, какая именно сеть у пользователя является локальной, доступ к ней всегда будет работать.
Однако, для того, чтобы доступ пользователя в собственную локальную сеть работал, нужно не забыть ещё один нюанс. В настройках клиента Anyconnect в явном виде должна быть указана опция Allow local (LAN) access:
Эту опцию можно выставлять централизованно в настройках профиля клиента Anyconnect на Cisco ASA:
- Выход в Интернет можно настроить через локального провайдера. Здесь же хочется оговориться: для обеспечения максимального уровня безопасности рекомендуется организовывать выход в Интернет удалённых пользователей всё же через корпоративные шлюзы, мсэ и web-прокси серверы. Но на практике, данным требованием многие пренебрегают;
- Для пользователей, у которых нет пересечения адресных пространств с ЦО, доступ в локальную сеть работает без проблем.
- Для пользователей, у которых происходит пересечение адресных пространств с ЦО, теряется доступ в локальную сеть. Split Exclude помогает избежать потери доступа в локальную сеть, но в этом случае будет утерян доступ в конфликтную сеть ЦО.
Предположим, наша задача организовать доступ таким образом, чтобы даже у пользователей, имеющих пересечение адресного пространства, всегда работал доступ как в конфликтную сеть ЦО, так и в собственную локальную сеть. Для этого нам потребуется транслировать конфликтную сеть ЦО в другую сеть для удалённых пользователей. Например, конфликтная сеть 192.168.1.0/24. Настроим трансляцию всей сети 192.168.1.0/24 в некоторую другую сеть 192.168.25.0/24. Тогда удалённые пользователи, желающие подключиться к хосту в ЦО с адресом, например, 192.168.1.10, должны будут использовать для подключения транслированный адрес 192.168.25.10. На ASA описываемую конструкцию можно настроить с помощью правил twice NAT следующим образом:
Конечно, работать с IP адресами для конечных пользователей не удобно. Тем более в описываемом случае придётся помнить, что чтобы попасть на хост 192.168.1.10, нужно использовать адрес 192.168.25.10 (то есть приходится запоминать уже два IP-адреса). На помощь приходит DNS и функция DNS doctoring на ASA. DNS doctoring позволяет изменять IP-адрес в DNS-ответах в соответствии с правилами NAT. Пример работы DNS Doctoring представлен на рисунке ниже:
Замечание 1: для использования функции DNS doctoring на ASA должны быть включена инспекция DNS:
Замечание 2: для использования функции DNS doctoring подключаемый по VPN клиент должен использовать внутренний корпоративный DNS-сервер (находящийся за ASA).
На ASA при настройке DNS doctoring есть нюанс. DNS doctoring не всегда можно настроить в правиле Twice NAT. Опция dns в правиле NAT становится не доступна, как только после source static появляется директива destination static:
Данное поведение задокументировано на сайте Cisco.
Если мы не будем использовать destination static, конфликтная сеть ЦО 192.168.1.0/24 будет транслироваться в новую сеть 192.168.25.0/24 всегда, а не только для удалённых сотрудников. Это поведение не приемлемо. Чтобы этого не происходило, мы должны поставить правило трансляции конфликтной сети в конец правил NAT. При этом вышестоящие правила трансляции, касающиеся конфликтной сети, мы должны модернизировать таким образом, чтобы правила срабатывали всегда, кроме случая обмена данными с удалёнными пользователями. В данном случае порядок правил NAT имеет решающее значение, поэтому, очень кратко напомню порядок правил NAT для ASA версии IOS 8.3 и выше. Правила NAT выполняются в порядке трёх секций:
Секция 1. Twice NAT в порядке конфигурации
- Static
- Dynamic
- Cначала, где меньше IP адресов для трансляции
- Сначала младшие номера IP
- По алфавиту (по названию Obj gr)
Приведу пример. Для организации выхода в Интернет из конфликтной сети ЦО, как правило, требуется наличие соответствующего правила dynamic nat|pat. Если dynamic nat|pat настроено с помощью Network Object Nat, придётся модифицировать настройку к виду Twice NAT. Это необходимо, чтобы иметь возможность добавить в правило директиву destination static (получаем так называемый Policy NAT). Правило dynamic pat нужно поставить выше правила nat для удалённых пользователей. Это можно сделать разными способами: указать позицию правил в явном виде в секции 1, перенести правило nat для удалённых пользователей в секцию 3 after auto и т.д. Пример настройки:
Если мы используем Split tunneling вида Split Include, не забываем в соответствующем списке доступа указать именно транслированную сеть net-25:
- Все преимущества использования Split Tunneling присущи третьему варианту;
- Для пользователей, у которых происходит пересечение адресных пространств с ЦО появляется возможность получить доступ в конфликтную сеть ЦО, сохраняя при этом доступ к собственной локальной сети.
- Сложность конфигурирования. При использовании DNS doctoring необходимо модифицировать правила трансляции адресов, касающиеся конфликтных сетей.
- без Split Tunneling;
- с использованием Split Tunneling двух видов: Split Include и Split Exclude;
- с использованием Split Tunneling совместно с правилами NAT и опцией DNS doctoring.
Жду Ваши комментарии. Может быть, кто-то сможет поделиться своим опытом или другим способом решения проблемы пересечения адресных пространств.
Step Four
This step involves configuring a DNS view-list that forwards requests based on the name list above. Anything that doesn’t match a name list is forwarded to the default.
А как правильно назначить
Step One
The first step is to configure the default resolvers on the router. You might already have these in place especially if your router is already in use.
I use Google Public DNS so here’s my configuration:
Комментарии
ip domain name это именно
ip domain name это именно доменное имя, т.е. не включает в себя имя роутера
3BALL
Server0
IP address 172.18.0.253
Mask 255.255.255.0
Def gate 172.18.0.1
Server1
IP address 172.18.0.254
Mask 255.255.255.0
Def gate 172.18.0.1
Server2
IP address 172.18.0.252
Mask 255.255.255.0
Def gate 172.18.0.1
12BALL
SW0, SW1, SW2, SW3
Vlan 100
Name Servers
Vlan 101
Name IT
Vlan 102
Name Manager
4BALL
SW0
Int fa0/1
Description Servers
Switchport access vlan 100
Switchport mode access
Int fa0/11
Description IT
Switchport access vlan 101
Switchport mode access
Int fa0/12
Description IT
Switchport access vlan 101
Switchport mode access
Int fa0/2
Description Servers
Switchport access vlan 100
Switchport mode access
4BALL
SW2
Int fa0/1
Description Manager
Switchport access vlan 102
Switchport mode access
Int fa0/2
Description Manager
Switchport access vlan 102
Switchport mode access
SW3
Int fa0/1
Description Manager
Switchport access vlan 102
Switchport mode access
Int fa0/2
Description Manager
Switchport access vlan 102
Switchport mode access
2BALL
SW1
Gig0/1
Description Management
Switchport trunk allowed vlan 1,100-102,252
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 1,100-102,252
Switchport mode trunk (gig0/2 прописать 2 раза)
2BALL
SW2
Gig0/1
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
2BALL
SW3
Gig0/1
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
Gig0/2
Description Management
Switchport trunk allowed vlan 100-102
Switchport mode trunk
6BALL
SW1
Vtp domain YktSkills
Vtp password ykt2015
Vtp version 2
Vtp mode client
6BALL
SW2, SW3
Vtp password ykt2015
Vtp version 2
Vtp mode client
3BALL
SW0
Vtp domain YktSkills
Vtp password ykt2015
Vtp version 2
3BALL (можно не писать)
Server0, Server1, Server2
Default Gateway 172.18.0.1
8BALL
Server2/вкладка DNS/ создаем
R0/address 10.10.0.1 (жмем add)
SW0/address 10.10.0.2
SW1/address 10.10.0.3
SW2/address 10.10.0.4
SW3/address 10.10.0.5
Dns/address 172.18.0.254
ftp/address 172.18.0.252
web/address 172.18.0.253
1BALL (можно пропустить)
PC6 переключить на DHCP
4BALL
SW0, SW1, SW2, SW3
Spanning-tree mode rapid-pvst
2BALL
R0
Int fa0/0.100
Description Servers
Encapsulation dot1Q 100
Ip address 172.18.0.20 255.255.255.0
2BALL
Int fa0/0.101
Description IT
Encapsulation dot1Q 101
Ip address 172.18.0.21 255.255.255.0
2BALL
Int fa0/0.102
Description Manager
Encapsulation dot1Q 102
Ip address 172.18.2.24 255.255.255.0
1BALL
Int fa0/0.252
Description Manager
Encapsulation dot1Q 252
Ip address 10.10.1.8 255.255.255.0
2BALL
PC6
IP 10.10.0.6
MASK 255.255.0.0
Def Get 10.10.0.1
5BALL
R0
Ip dhcp pool Manager
Network 172.18.2.0 255.255.255.0
Default-router 172.18.2.1
Ip dhcp pool IT
Network 172.18.1.0 255.255.255.0
Default-router 172.18.1.1
2BALL
R0
Ip dhcp pool IT
Network 172.18.1.0 255.255.255.0
Default-router 172.18.1.1
Ip dhcp excluded-address 172.18.1.1
Ip dhcp pool Manager
Network 172.18.2.0 255.255.255.0
Default-router 172.18.2.1
Ip dhcp excluded-address 172.18.2.1
At home I have a Cisco 867VAE router that acts as the gateway between my home network and the Internet. It also provides site-to-site VPN between my home network and services I have inside the Amazon Web Services (AWS) cloud.
For a while now I’ve been providing DNS resolution using a BIND DNS server running on a home server as I had a requirement to send DNS resolution requests to different upstream resolvers based on the domain and at the time of implementation the router I had didn’t have this capability.
As I have however had the Cisco router for a while I’ve decided it’s time to enable DNS resolution in the Cisco router and move this service here.
Here’s how I’ve done this.
Step Three
This step involves configuring the domains that you want to use your non-default DNS view. For example, a basic configuration that forwards Netflix to Unblock-Us is as follows:
If you have configured extra DNS views above then you’ll need to extra DNS name-lists by incrementing the ID.
Step Two
This step involves configuring your DNS views. DNS views determine the resolvers that will be used.
In this case I have two views - one for domains I’m pointing to Unblock-Us and another for all other requests.
Obviously you need to change the DNS view to suit your environment.
Читайте также: