Читайте также:
|
Существует специальная системная команда ping, что дает возможность проверить соединение в сети на основе TCP / IP.
Данная команда отправляет запрос протокола ICMP указанному ресурсу в сети и фиксирует результат, поступающий в ответ от этого узла.
Иными словами, команда ping позволяет определить время, затрачиваемое при передаче данных от одного клиента к другому, т.е. от конкретного ПК пользователя к конкретно указанного сервера, ресурса и наоборот.
Чем меньше время задержки, тем быстрее происходит соединение между двумя узлами.
Рис.22.1 Пример локальной одноранговой сети.
Когда настройка завершена, выполняется ping-процесс. Например, запускается с PC1 и проверять наличие связи с PC5.
Можно произвольно выбирать, откуда запускать ping-процесс, главное, чтобы выполнялось условие: пакеты должны обязательно пересылаться через коммутатор. Для этого производится двойной щелчок по нужной рабочей станции, в открывшемся окне выбирается вкладка «Рабочий стол», далее – «Командная строка». Откроется окно командной строки:
Рис.22.2 Окно командной строки.
Здесь предлагается ввести команду, что нужно сделать:
«PC> ping 192.168.1.3»
нажимается клавиши Enter. Если все настроено, верно, то появляется следующая информация, представленную на рисунке 22.3
Рис.22.3 Результат выполнение команды «ping»
Также Packet Tracer позволяет выполнять команду «ping» значительно быстрее и удобнее. Для этого, выбирается на боковой панели сообщение Далее нужно кликнуть мышкой по компьютеру от кого будет передавать команда «ping» и еще раз щелкнуть по компьютеру, до которого будет выполнять команда «ping». В результате будет выполнена команда «ping», результат отобразиться в нижнем правом углу. Для более детального отображения результата выполнения команды выберите «Переключить окно списка PDU».
Рис. 22.4 Моделирование отправки пакета.
В Packet Tracer предусмотрен режим моделирования, в котором подробно описывается и показывается, как работает утилита Ping. Поэтому необходимо перейти в «simulftion», нажав на одноименный значок в нижнем левом углу рабочей области, или по комбинации клавиш Shift+S. Откроется «Панель моделирования», в которой будут отображаться все события, связанные с выполнения ping-процесса. Теперь необходимо повторить запуск ping-процесса. После его запуска можно сдвинуть «Панель моделирования», чтобы на схеме спроектированной сети наблюдать за отправкой/приемкой пакетов.
23.1. Конфигурирование сервера доменных имён DNS
Различают 3 режима работы сервера DNS: master (primary). Данный режим используется администратором зоны, файлы баз данных ведутся вручную на этом сервере. Данный сервер является абсолютным авторитетным источником информации для данной зоны;
slave (secondary). Данный режим используется по просьбе администратора зоны, которая автоматически регулярно копируется с master 6 сервера. Данный сервер является авторитетным источником информации для данной зоны;
hint Для каждой зоны, обслуживаемой данным сервером, может быть выбран тот или иной режим. Обычно для зоны “.” все сервера конфигурируются по типу hint, что позволяет кэшировать все запросы пользовательских рабочих станций на время жизни конкретной записи DNS. Это значительно ускоряет обработку локальных запросов. (caching). Режим кэширования всех запросов, попадающих в определённую зону, обычно “.”, т.е. кэшируются все запросы. Такой сервер обычно используется для ускорения работы с сетью. База данных DNS для каждого домена в простейшем случае представляет собой набор текстовых файлов, которые системный администратор ведет на главном сервере имен этого домена. В этих файлах содержатся директивы синтаксического анализатора ($ORIGN, $TTL) и записи о ресурсах. Установка ПО сервера DNS Наиболее популярным ПО, реализующим сервис DNS, является сервер bind При установке сервера автоматически создается конфигурация для кэширующего сервера зоны «.» и для первичных серверов локальных зон.. Пакет bind поставляется практически со всеми дистрибутивами Linux и xBSD. Во FreeBSD демон BIND называется named. Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён. В зависимости от способа конфигурации зоны на сервере файлы зон могут располагаться в подкаталогах master, slave или dynamic иерархии /etc/namedb. Эти файлы содержат DNS информацию, которую и будет сообщать в ответ на запросы сервер имен. Для больших зон, содержащих миллионы записей, используются специальные модули хранения, которые могут сохранять данные зон в реляционных БД (PostgreSQL) либо на сервере LDAP. Запуск BIND Так как сервер имён BIND устанавливается по умолчанию, его на- стройка сравнительно проста. Стандартная конфигурация named запускает простой кэширующий сервер в ограниченной среде chroot. Для одноразового запуска демона в этой конфигурации используйте команду # /etc/rc.d/named forcestart Чтобы демон named запускался во время загрузки, поместите в /etc/rc.conf следующую строку: named_enable="YES" 7 Разнообразные опции запуска named во FreeBSD описаны в переменных named_* файла /etc/defaults/rc.conf. Конфигурирование сервера DNS. Настройка BIND версий 8 и 9. При запуске программа named читает файл /etc/namedb/named.conf и таким образом настраивается. Рассматривать все варианты конструкций в файле настройки named.conf, не имеет смысла, а потому сосредоточимся только на наиболее часто встречающихся вариантах и наиболее привлекательных особенностях. При этом многие вопросы, связанные с безопасностью, динамическим обновлением и другими новыми возможностями оставим для отдельного обсуждения. Официальный (Authoritative) сервер зоны. В руководстве по BIND данная конфигурация обозначена как "Authoritative-only server". Смысл ее заключается в том, что демонст- рируется настройка сервера, который обслуживает запросы от любого хоста Сети, но только к той зоне, за которую он официально отвечает. В терминологии BIND 4.х такой сервер именовался как "primary" для зоны, а в терминологии BIND 8.х- 9.х он именуется как "master". Его файл настройки будет выглядеть следующем образом: options { directory "/etc/namedb";// Working directory pid-file "named.pid"; // Put pid file in working allow-query { any; }; // This is default recursion no; // Do not provide recursion service }; zone "." { type hint; file "root.hint"; }; zone "0.0.127.in-addr.arpa" { type master; file "0.0.127.in-addr.arpa"; notify no; }; zone "example.com" { type master; file "example.com"; allow-transfer { 192.168.4.14; 192.168.5.53; }; }; Сначала обратим внимание на отличие в описании опций директивы "options". Во-первых, с запросами к данному серверу позволено обращаться 8 любому хосту Сети, что логично, т.к. никто другой, кроме официального сервера, в полном объеме за данную зону не отвечает (опция "allow-query"). Есть, конечно, вспомогательные сервера, но они только дублируют master сервер. Вносить изменения в описание зоны можно только на primary master сервере. Именно поэтому при выходе из строя primary master сервера время обслуживания запросов вспомогательными серверами ограничено. Предполагается, что при отказе primary master данные вспомогательных серверов не будут соответствовать исходному описанию зоны, а потому обслуживание запросов лучше прекратить. Во-вторых, данный сервер не обслуживает запросы рекурсивно. Он только отвечает на запросы к своей зоне (опция "recursion"). Последнее означает, что в отличие от кэширующего сервера, который принимает запросы от клиентов (resolver-ов), опрашивает серверы доменных имен и потом отвечает клиентам, наш сервер запросы клиентов, которые не касаются зоны его ответственности, обслуживать не будет. Описание корневых (root) серверов и обратной зоны для 127.0.0.1 такое же, как и для кэширующего сервера. При описании зоны ответственности (директива "zone "example.com") в качестве первого параметра указано имя зоны ("example.com") в фигурных скобках определены опции: тип сервера - master, т.е. официальный сервер зоны; файл описания зоны - file "example.com"; список вспомогательных серверов - "allow-transfer { 192.168.4.14; 192.168.5.53 };". Собственно, опция "allow-transfer" задает список серверов, которым разрешено копировать зону. Официальными вспомогательными серверами они станут только в том случае, если они таковыми были определены в заявке (для доменов второго уровня - корпоративных доменов, например), либо приписаны таковыми при делегировании зоны более глубокого уровня. Если не установить ограничения на копирование зоны, или указать "any", то любой сервер может скопировать зону, и не только сервер. Из соображений безопасности настоятельно рекомендуется прописывать адреса серверов, которым можно копировать зону.
Дата добавления: 2015-09-11; просмотров: 119 | Поможем написать вашу работу | Нарушение авторских прав |