Характеристика Cisco Packet Tracer

 

Cisco Packet Tracer - это программное обеспечение для эмуляции сетей, построенных на оборудовании Cisco. Данное ПО спроектировано в том числе и для выполнения лабораторных работ курса CCNA. Низкое, по сравнение с GNS3, потребление ресурсов хост-компьютера, а также наличие всего необходимого функционала позволяет достаточно эффективно использовать Cisco Packet Tracer в процессе подготовки к работе. Необходимые для выполнения практических заданий топологии собираются за считанные минуты, что позволяет приступить к выполнению работы практически сразу.

Cisco Packet Tracer является очень удобным инструментом с достаточно широкими возможностями для построения комплексных проектов. Согласно официальной спецификации данное программное обеспечение обладает всем необходимым функционалом для получения практических навыков. Можно утверждать, что на данный момент эта информация не совсем достоверна, так как в новом издании CCNA Security была добавлена новая тема Cisco ASA. Поддержка эмуляции данного оборудования отсутствует в Cisco Packet Tracer. Не смотря на это, его использование возможно для большей части практического курса CCNA Security.

Системные требования Минимальные / Рекомендуемые:

· Центральный процессор: Intel Pentium 300 MHz or equivalent / Intel Pentium II 500 MHz

· Оперативная память: 96 MB / 256 MB

· Свободное место на жестком диске: 250 MB / 300 MB

Из описания технических требований можно легко понять, что данное программное обеспечения является не требовательным. Это дает возможность использовать Cisco Packer Tracer для отработки практических навыков курса CCNA практически на любом современном компьютере.

Возможности и поддержка протоколов согласно технического описания Cisco Packet Tracer:

·  FTP, SMTP, POP3, HTTP, TFTP, Telnet, SSH, DNS, DHCP, NTP, SNMP, AAA, ISR VOIP, SCCP config and calls ISR command support, Call Manager Express;

· TCP and UDP, TCP Nagle Algorithm & IP Fragmentation, RTP;

· BGP, IPv4, ICMP, ARP, IPv6, ICMPv6, IPSec, RIPv1/v2/ng, Multi-Area OSPF, EIGRP, Static Routing, Route Redistribution, Multilayer Switching, L3 QoS, NAT, CBAL, Zone-based policy firewall and Intrusion Protection System on the ISR, GRE VPN, IPSec VPN;

· Ethernet (802.3), 802.11, HDLC, Frame Relay, PPP, PPPoE, STP, RSTP, VTP, DTP, CDP, 802.1q, PAgP, L2 QoS, SLARP, Simple WEP, WPA, EAP.

Возможно использование на следующих операционных системах: Windows XP; Vista (Vista Basic, Vista Premium); Windows 7; and Linux (Ubuntu, Fedora).

 

Элементы базы DNS

 

Элементы базы DNS часто называют RR (сокращение от Resource Record). Базовый формат записи выглядит так:

[имя] [время] [класс] тип данные

Имя может быть относительным или абсолютным (FQDN — Fully Qualified Domain Name). Если имя относительное, то к нему автоматически добавляется имя текущего домена. Например, если в домене listsoft.ru описать имя «www», то полное имя будет интерпретироваться как "www.listsoft.ru." Если это имя указать как "www.listsoft.ru" (без последней точки), то оно будет считаться относительным и будет интерпретировано как "www.listsoft.ru.listsoft.ru."

Время задает интервал времени в секундах, в течение которого данные могут сохраняться в кэше сервера.

Класс определяет класс сети. Практически всегда это будет IN, обозначающее INternet.

Тип может быть одним из следующих: SOA — определяет DNS зону NS — сервер имен для зоны A — преобразование имени в IP-адрес PTR — преобразование IP-адреса в имя MX — почтовая станция CNAME — имена машины HINFO — описание "железа" компьютера TXT — комментарии или какая-то другая информация.

Есть также некоторые другие типы, но они намного менее распространены.

В записях можно использовать символы # и; для комментариев, @ для обозначения текущего домена, () — скобки — для написания данных на нескольких строках. Кроме того, можно использовать метасимвол * в имени. Порядок записей не имеет значения за одним исключением: запись SOA должна идти первой. Дальнейшие записи считаются относящимися к той же зоне, пока не встретится новая запись SOA. Как правило, после записи зоны указывают записи DNS-серверов, а остальные записи располагают по алфавиту, но это не обязательно.

Для рассмотрения записей, первой описывается зону: mycompany.ru. IN SOA ns.mycompany.ru. admin.mycompany.ru. (1001; serial 21600; Refresh — 6 часов 1800; Retry — 30 мин 1209600; Expire — 2 недели 432000); Minimum — 5 дней.

Сначала идет имя домена: mycompany.ru. Вместо имени также можно поставить знак @. ns.mycompany.ru. — основной сервер имен admin.mycompany.ru. — почтовый адрес администратора в формате имя(точка)машина, затем в круглых скобках идут поля, необходимые для правильного "восприятия" вашей зоны другими серверами. Первое число — serial — является "версией" файла зоны. При внесении изменений это число нужно увеличить — если вторичный сервер увидит, что его версия зоны меньше, чем у первичного сервера, то он перечитает данные. Типичной ошибкой является обновление зоны без обновления этого числа. Очень удобно в качестве serial использовать текущую дату, например, 2003040401 — 4 апреля 2003 года, первое обновление. Refresh говорит вторичным серверам, как часто они должны проверять значение serial.

Retry говорит о том, как часто вторичный сервер должен пытаться прочитать данные, если первичный сервер не отвечает.

Expire говорит вторичным серверам, в течение какого времени они должны обслуживать домен, если первичный сервер не отвечает. По истечении этого времени вторичные сервера будут считать свои данные устаревшими. Minimum задает время жизни записей по умолчанию для данной зоны.

Далее рассмотрим сервера имен, обслуживающие домен: mycompany.ru. IN NS ns.mycompany.ru. mycompany.ru. IN NS ns.provider.ru.. Так как имя зоны совпадает с указанным в поле имя записи SOA, то его можно оставить пустым.

Дальше идут записи A, описывающие ваши компьютеры и позволяющие преобразовать имена в IP-адреса. major IN A 192.168.0.1 colonel IN A 192.168.0.2 IN HINFO "2xPIV-1.7 Win2K" general.mycompany.ru. IN A 192.168.0.3. Здесь имена могут быть относительные или "абсолютные", можно добавить записи о конфигурации машины (пропущенное имя в записи HINFO говорит о том, что имеется в виду предыдущее имя). Также нужно добавить записи localhost. IN A 127.0.0.1 localhost IN CNAME localhost. mycompany.ru. IN A 192.168.0.1 Первая отдает адрес 127.0.0.1 любой машине, запросившей имя localhost, вторая — localhost.mycompany.ru, а третья говорит, куда послать клиента, который хочет попасть на mycompany.ru

Записи CNAME позволяют дать машинам удобные или значащие имена. Например: ftp IN CNAME general говорит, что ftp.mycompany.ru живет по адресу 192.168.0.3. CNAME удобно использовать, если нужно поменять имя машины, но оставить доступ для клиентов, которые помнят старое имя. Удобный трюк с использованием CNAME заключается в назначении коротких имен часто используемым адресам. Например, прописав ls IN CNAME www.listsoft.ru., возможно заходить на ListSoft просто набирая ls в качестве адреса.

Записи MX нужны для того, чтобы указать, куда пересылать почту. В этих записях добавляется приоритет — чем он меньше, тем выше приоритет машины. Приоритеты нужны для того, чтобы можно было задать несколько записей и перенаправить почту на альтернативный сервер, если основной не работает. MX запись должна быть указана для домена в целом и, возможно, для каждой машины в отдельности. Сложного тут тоже ничего нет за одним исключением: очень часто встречается неправильно использование метасимвола "*". Запись "*.mycompany.ru." означает не "любая машина домена mycompany.ru", а "любая машина, которая еще не была описана". Причем, даже если использовалась не MX, а, например, A-запись, то звездочка все равно не будет работать для этой машины. Метасимволы нужны только для того чтобы принимать почту для сети, находящейся за брандмауэром и чтобы пересылать почту в сети, не подключенные к Интернету (например, работающие через UUCP). Так как записи DNS меняются довольно редко, то имеет смысл прописать MX записи для всех машин, описанных записями A. mycompany.ru. IN MX 10 relay mycompany.ru. IN MX 20 mycompany.ru. mycompany.ru. IN MX 30 mail.provider.ru. general.mycompany.ru. IN A 192.168.0.3 IN MX 10 mycompany.ru.

На этом создание файла зоны считается законченным. Но остается более увлекательное занятие: описание реверсной зоны. Если предыдущий файл позволяет определить IP-адрес по имени, то теперь надо сделать так, чтобы по IP-адресу можно было "вычислить" имя. Отсутствие реверсной зоны является довольно типичной ошибкой и может приводить к самым разным ошибкам — начиная от сбоев FTP-серверов и заканчивая классификацией отправленных писем как спама.

Для обратного преобразования используются записи PTR, они пишутся в отдельном специальном домене верхнего уровня, с названием IN-ADDR.ARPA. Домен этот был создан для того, чтобы и для прямого, и для обратного преобразований можно было использовать одни и те же программные модули. "Мнемонические" имена пишутся слева направо: www.listsoft.ru означает, что www находится в listsoft, а listsoft — в ru. IP-адреса пишутся наоборот: 195.242.9.4 означает, что машина 4 находится в подсети 9, которая является частью 195.242 И для сохранения "единого стиля" адресов для обратного преобразования используются имена вида 4.9.242.195.IN-ADDR.ARPA (обратите внимание, что IP-адрес записан в обратном порядке).

Для создания еще одного файла зоны (для зоны, например, 0.168.192.IN-ADDR.ARPA), в него копируется запись SOA (а заодно и NS), после чего пишется: 1 IN PTR major.mycompany.ru. 2 IN PTR colonel.mycompany.ru. Можно задавать не только относительные, но и абсолютные имена: 3.0.168.192.IN-ADDR.ARPA. IN PTR general.mycompany.ru.

Право на ведение "прямого" домена не зависит от провайдера — его выдает организация, ведающая распределением имен в нужном вам домене. Пул IP-адресов находится в ведении провайдера, и именно провайдер делегирует (или не делегирует) права на ведение реверсной зоны. В связи с тем, что зачастую клиентам выдается не целая сеть класса «C», а ее часть, то и реверсная зона находится на сервере провайдера. И для этого необходимо наладить с ним взаимодействие в области обновления данных.

Иерархичность DNS-серверов

 

При установке клиенту указывается как минимум один DNS-сервер (как правило, их два) — его адрес выдается провайдером. Клиент посылает запрос этому серверу. Сервер, получив запрос, либо отвечает (если ответ ему известен), либо пересылает запрос на "вышестоящий" сервер (если он известен) или на корневой (каждому DNS-серверу известны адреса корневых DNS-серверов). Так выглядит "восходящая иерархия". Затем запрос начинает спускаться вниз — корневой сервер пересылает запрос серверу первого уровня, тот — серверу второго уровня и т.д. Таким образом, каждый DNS-сервер работает всегда либо знает ответ, либо знает, у кого спросить.

Помимо "вертикальных связей", у серверов есть еще и "горизонтальные" отношения — "первичный — вторичный". Если предположить, что сервер, обслуживающий какой-то домен и работающий "без страховки" вдруг перестанет быть доступным, то все машины, расположенные в этом домене, окажутся недоступны. Именно поэтому при регистрации домена второго уровня существует требование указать минимум два сервера DNS, которые будут этот домен обслуживать.

DNS-сервера бывают рекурсивные и нерекурсивные. Первые всегда возвращают клиенту ответ — они самостоятельно отслеживают отсылки к другим DNS-серверам и опрашивают их. Нерекурсивные сервера возвращают клиенту эти отсылки, так что клиент должен самостоятельно опрашивать указанный сервер. Рекурсивные сервера удобно использовать на низких уровнях, в частности, в локальных сетях. Они кэшируют все промежуточные ответы, и при последующих запросах ответы будут возвращаться намного быстрее. Нерекурсивные сервера обычно стоят на верхних ступенях иерархии — поскольку они получают очень много запросов, то для кэширования ответов никаких ресурсов не хватит.

Полезным свойством DNS является умение использовать "пересыльщиков" (forwarders). DNS-сервер самостоятельно опрашивает другие сервера и находит нужный ответ, но если сеть подключена к Интернету по медленной (например, dial-up) линии, то этот процесс может занимать довольно много времени. Вместо этого можно перенаправлять все запросы, на сервер провайдера, а затем принимать его ответ. Использование "пересыльщиков" может оказаться интересным и для больших компаний с несколькими сетями: в каждой сети можно поставить относительно слабый DNS-сервер, указав в качестве "пересыльщика" более мощную машину, подключенную по быстрой линии. При этом все ответы будут кэшироваться на этом мощном сервере, что ускорит разрешение имен для целой сети.

Для каждого домена администратор ведет базу данных DNS. Эта база данных представляет собой набор простых текстовых файлов, расположенных на основном (первичном) сервере DNS (вторичные сервера периодически копируют к себе эти файлы). В файлах конфигурации сервера указывается, в каком именно файле содержатся описания каких зон, и является ли сервер первичным или вторичным для этой зоны.