ПОЛНОЕ РУКОВОДСТВО

Alena Kabelova
Libor Dostalek
a kolektiv
Velky pruvodce protokoly TCP/IP
a systemem DNS
3. aktualizovane a rozsirene vydani
Computer Press
Praha

Л.ДОСТАЛЕК
А. КАБЕЛОВА
ТСРЛР и DIMS
в теории
и на практике
Полное руководство
Санкт-Петербург, 2006

Досталек Л., Кабелова А.
TCP/IP и DNS в теории и на практике. Полное руководство / Пер. с чеш. Рус.
изд. под ред. М. В. Финкова и А. В. Анисимова. Серия «Полное руководство». —
СПб.: Наука и Техника, 2006. — 608 с, ил.
ISBN 5-94387-280-9
Серия «Полное руководство»
Данная книга представляет собой великолепное руководство по TCP/IP и DNS, содержащее
в себе как их общее систематизированное описание в рамках принятых современных
стандартов, так и рассмотрение их практических реализаций. Авторы книги подробно,
с большим количеством характерных примеров рассказывают о том, как работают протоколы
семейства TCP/IP и служба DNS, об их функциях и особенностях.
Наряду с формальным, систематизированным описанием, большое внимание в книге
уделяется практическим аспектам работы с TCP/IP и DNS. Разбираются реальные ситуации,
описываются необходимые инструменты, даются профессиональные рекомендации по
решению тех или иных проблем (для Windows/Linux(Unix) и IOS — операционной системы
CISCO). Необходимо отметить ярко выраженный аналитический подход, на котором
построена книга и в рамках которого изложение материала ведется не «сухим», академическим языком
(кроме случаев, когда это необходимо), а насыщено разносторонними аналитическими
отступлениями. Значительное внимание уделено механизмам безопасности и уязвимостям
TCP/IP и DNS.
Книга написана специалистами с мировым именем. Будет несомненно полезна как сетевым
администраторам и программистам, занимающимся созданием сетевых приложений, так
и всем заинтересованным читателям. Может использоваться в качестве учебного пособия.
ISBN 5-94387-280-9
9 м785943"872808
Контактные телефоны издательства:
(812) 567 70 25, (812) 567 70 26, (044) 516 38 66
Официальный сайт: www.nit.com.ru
© Перевод на русский язык, Наука и техника, 2006
© Издание на русском языке, Наука и техника. 2006
Оформление О. В. Рудневой
Copyright © Computer Press. Velky pruvodce protokoly TCP/IP a systemem DNS,
by Alena Kabelova and Libor Dostalek, ISBN: 80-7226-675-6. All rights reserved.
OOO «Наука и Техника»
198097, Санкт-Петербург, ул. Маршала Говорова, 29
Подписано в печать 20.01.2006. Формат 70x100 716.
Бумага газетная. Печать офсетная. Объем 38 п. л.
Тираж 3 000 экз. Заказ № 518
Отпечатано с готовых диапозитивов в ОАО «Техническая книга»
190005, Санкт-Петербург, Измайловский пр., 29

Содержание
ВВЕДЕНИЕ 21
В. 1. СЕТЕВЫЕ ПРОТОКОЛЫ И МОДЕЛИ ВЗАИМОДЕЙСТВИЯ ОТКРЫТЫХ СИСТЕМ 22
8.2. МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ ISO OSI 25
8.2.1. Физический уровень 25
8.2.2. Канальный уровень 27
8.2.3. Сетевой уровень 28
8.2.4. Транспортный уровень 30
8.2.5. Сеансовый уровень 32
8.2.6. Уровень представления 33
8.2.7. Прикладной уровень 33
8.3. СТЕК ПРОТОКОЛОВ TCP/IP 34
8.3.1. Протокол IP (Internet Protocol) 34
8.3.2. Протоколы TCP и UDP 35
8.3.3. Протоколы приложений 35
8.4. СПОСОБЫ ПЕРЕДАЧИ ИНФОРМАЦИИ 37
8.4.1. Синхронная передача данных 37
8.4.2. Пакетная передача данных 38
8.4.3. Асинхронная передача данных 39
8.5. ВИРТУАЛЬНАЯ ЦЕПЬ 39
8.5.1. Концепция виртуальной цепи 39
8.5.2. Постоянные и коммутируемые виртуальные цепи 42
ГЛАВА 1. МАРШРУТИЗАТОРЫ CISCO И СЕТЕВАЯ БЕЗОПАСНОСТЬ -
КАК ЭТО ВЫГЛЯДИТ НА ПРАКТИКЕ 43

TCP/IP и DNS в теории и на практике. Полное руководство
1.1. МАРШРУТИЗАТОРЫ CISCO: ВИД СПЕРЕДИ, СБОКУ, СВЕРХУ И... ИЗНУТРИ 44
1.2. ИДЕНТИФИКАЦИЯ ИНТЕРФЕЙСА 47
1.3. КАБЕЛИ 48
1.4. ПАМЯТЬ МАРШРУТИЗАТОРА:ТИПЫ, НАЗНАЧЕНИЕ, ОСОБЕННОСТИ ДОСТУПА 49
1.5. КОНСОЛЬ 50
1.6. КОМАНДЫ 53
1.6.1. Методика и синтаксис использования команд 53
1.6.2. Непривилегированный режим (режим пользователя) —
стоит на страже правопорядка.
Команды доступные в этом режиме 55
1.6.3. Привилегированный режим (режим администратора) 56
1.7. КОНФИГУРИРОВАНИЕ МАРШРУТИЗАТОРА. КАК ЭТО ДЕЛАЕТСЯ 56
Файл конфигурации 56
Защита конфигурационного файла CISCO 59
Возможность настройки маршрутизатора через Web
и безопасность 60
Программа ConfjgMaker 61
1.8. ОТЛАДКА. МОНИТОРИНГ ПРОИСХОДЯЩИХ СОБЫТИЙ 62
ГЛАВА 2. СЕТЕВЫЕ МОНИТОРЫ. АНАЛИЗ СТАБИЛЬНОСТИ
И БЕЗОПАСНОСТИ СЕТИ. ПЕРЕХВАТ ДАННЫХ 64
2.1. СЕТЕВЫЕ МОНИТОРЫ - ОРУЖИЕ АДМИНИСТРАТОРА ИЛИ ВЗЛОМЩИКА? 65
2.2. ПАКЕТНЫЕ ДРАЙВЕРЫ, КОММУТАТОРЫ И КОНЦЕНТРАТОРЫ.
ВОПРОСЫ БЕЗОПАСНОСТИ ПЕРЕДАЧИ ДАННЫХ ПО СЕТИ 66
2.3. MS NETWORK MONITOR - ПРОГРАММА ПЕРЕХВАТА
ДЛЯ СЕРВЕРНЫХ ОПЕРАЦИОННЫХ СИСТЕМ 69
2.3.1. Перехват кадров с данными 69
2.3.2. Просмотр захваченных кадров 73
2.3.3. Фильтр захваченных кадров 75
2.4. ПРОГРАММА ETHEREAL - ПЕРЕХВАТ ДАННЫХ ПОД ПОЛЬЗОВАТЕЛЬСКИМИ
ОПЕРАЦИОННЫМИ СИСТЕМАМИ (WINDOWS 2000/XP) 76
ГЛАВА 3. ФИЗИЧЕСКИЙ УРОВЕНЬ - КАНАЛ ПЕРЕДАЧИ ДАННЫХ,
БЕЗОПАСНОСТЬ, СТАНДАРТЫ 79
Глобальные сети (WAN) 80
Локальные сети (LAN) 81
3.1. ПОСЛЕДОВАТЕЛЬНЫЕ ЛИНИИ 81
Последовательная и параллельная передача данных 82
Симметрический и асимметрический сигнал 82
6

Содержание
Синхронная и асинхронная передача 82
Протоколы V.24.V.35 и Х.21 85
Нуль-модемное соединение 88
3.2. МОДЕМЫ. АНАЛОГОВЫЕ ЛИНИИ 89
3.2.1. Назначение и принцип работы 89
3.2.2. Соединение модемов через провайдера 90
Dial-up-соединение 90
Выделенные линии 90
3.2.3. «Автоматические» модемы. Использование АТ-команд
для «прямого» управления модемом 91
3.2.4. Синхронная передача и асинхронная 93
3.2.5. Базовая полоса и голосовая полоса 93
3.2.6. Скорость передачи 95
3.2.7. Аппаратное сжатие данных.
Особенности разных технологий 96
3.2.8. Обнаружение и коррекция ошибок 97
3.3. ЦИФРОВЫЕ ЛИНИИ 98
3.3.1. ISDN 98
Начальный интерфейс 99
Высокоуровневые протоколы и сигнализация 102
3.3.2. Линии Е* 104
3.4. ЛОКАЛЬНЫЕ СЕТИ (LAN, LOCAL AREA NETWORK) 105
3.4.1. Кабели 105
Категории кабелей 105
Обжимка витой пары 107
Оптические кабели 108
3.4.2. Ethernet (10 Мбит/с) 112
3.4.3. Fast Ethernet (100 Мбит/с) 114
3.4.4. Gigabit Ethernet (1 Гбит/с) 114
3.4.5. FDDI (Fiber Distributed Data Interface) 115
3.5. БЕСПРОВОДНЫЕ ЛИНИИ GSM 115
Протоколы, стандарты, безопасность в сетях GSM 115
Подключение компьютера к Интернету через сеть GSM 120
GPRS (General Packet Radio Service) —
не путать с глобальным позиционированием 122

TCP/IP и DNS в теории и на практике. Полное руководство
ГЛАВА 4. КАНАЛЬНЫЙ УРОВЕНЬ. ПРОТОКОЛЫ, СТАНДАРТЫ, БЕЗОПАСНОСТЬ... 123
4.1. ПРОТОКОЛ SLIP 124
4.2. CSLIP - УСОВЕРШЕНСТВОВАННЫЙ SLIP 126
Появилось сжатие заголовков 126
Как происходит сжатие на практике 128
4.3. ПРОТОКОЛ HDLC - ОТЕЦ РРР 131
4.3.1. Описание и режимы работы протокола 131
4.3.2. Формат кадра HDLC 132
Поле Флаг 133
Поле адреса 133
Контрольная сумма (Checksum) 133
Поле данных и тип передаваемого протокола 134
Управляющее поле 134
4.3.3. Типы HDLC-кадров, их особенности и назначение 135
Информационный кадр (l-frame, l-кадр) 135
Суперкадр (S-frame, S-кадр) 136
Непронумерованный кадр (U-frame, U-кадр) 137
4.3.4. Обобщенная информация о протоколе HDLC 138
4.4. ПРОТОКОЛ РРР (POINT-TO-POINT PROTOCOL) -
САМОЕ РАСПРОСТРАНЕННОЕ РЕШЕНИЕ 139
4.4.1. Общее описание 139
Основные функции РРР 139
Формат РРР-кадра 140
Протоколы — составляющие РРР 141
4.4.2. Набор номера по телефонной линии «изнутри» —
сточки зрения РРР 142
4.4.3. Протокол LCP — ответственный за управление связью
в РРР 143
Назначение протокола LCP.
Выбор алгоритма аутентификации 143
Формат LCP-кадра 145
Разбираем пример кадра РРР-соединения 147
4.4.4. Управление доступом. РРР-Аутентификация 150
Протокол РАР 152
Протоколы типа CHAP 152
Расширяемый протокол аутентификации Extensible
Authentication Protocol (EAP) ' 154
Протокол Radius решает проблемы аутентификации 156
8

Содержание
4.4.5. Протокол управления обратным звонком — СВСР
(Call-Back Control Protocol) 156
4.4.6. Дополнительные (вспомогательные) протоколы
семейства РРР 159
Многоканальный протокол «точка-точка» —
Multiline Protocol (MP) 159
Протоколы ВАР (Bandwidth Allocation Protocol)
и ВАСР (Bandwidth Allocation Control Protocol) 161
Протокол управления сжатием —
Compression Control Protocol (CCP) 163
Протокол управления шифрованием —
РРР Encryption Control Protocol (ECP) 164
4.4.7. IPCR Протокол сетевого уровня, входящий в группу
протоколов РРР 165
4.5. FRAME RELAY - ПРОТОКОЛ КАНАЛЬНОГО УРОВНЯ ДЛЯ ГЛОБАЛЬНЫХ СЕТЕЙ 167
Общее описание технологии 167
Кадр протокола Frame Relay 172
Перегруженная сеть. Переполнение канала 174
IP no Frame Relay 176
LMI 177
Конфигурация Frame Relay на маршрутизаторах CISCO 178
Резюме 178
4.6. ЛОКАЛЬНАЯ СЕТЬ (LOCAL AREA NETWORKS, LAN) И ПРОТОКОЛ ETHERNET 179
Обзор основных технологий локальных сетей 179
Технология Ethernet 181
4.7. БЕСПРОВОДНЫЕ ЛОКАЛЬНЫЕ СЕТИ
(WIRELESS LOCAL AREA NETWORKS, WLAN) 191
4.7.1. Обзор технологий беспроводных локальных сетей 191
4.7.2. Типичная конфигурация WLAN 194
Access Point — АР 194
Магистральное соединение точка-точка 195
Одноранговые сети 194
Роуминг (несколько точек доступа) 195
4.7.3. Антенны 196
4.7.4. Безопасность WLAN 197
Wired Equivalent Privacy (WEP) 197
Служба Установки ID — Service Set ID (SSID) 197
IEEE 802.1X 198
4.7.5. Фиксированный беспроводный доступ
(Fixed Wireless Access, FWA). 199
9

TCP/IP и DNS в теории и на практике. Полное руководство
Обзор технологии 199
Отличия между FWA и WLAN 199
Основные преимущества FWA 200
ГЛАВА 5. ПРОТОКОЛ IP (INTERNET PROTOCOL) 201
5.1. НАЗНАЧЕНИЕ И ФУНКЦИИ ПРОТОКОЛА IP 202
Функции и особенности IP 202
Вспомогательные протоколы, входящие в состав IP 203
Маршрутизатор и обработка IP-дейтаграмм 204
5.2. УСТРОЙСТВО IP-ДЕЙТАГРАММЫ 208
5.3. ПРОТОКОЛ МЕЖСЕТЕВЫХ УПРАВЛЯЮЩИХ СООБЩЕНИЙ
(INTERENT CONTROL MESSAGE PROTOCOL, ICMP) 214
5.3.1. Общая информация 214
Назначение протокола ICMP 214
Какие бывают ICMP-сообщения 215
5.3.2. Разбираем отдельные ICMP-сообщения 217
Сообщение Echo 217
Недоставляемая IP-дейтаграмма (Undeliverable IP datagram).... 217
Подавление источником (Source Quench) 217
Перенаправление (Redirect) 218
Поиск маршрутизаторов с помощью ICMP 218
Время вышло (Time exceeded) 219
Запрос маски адреса подсети (Address mask request) 221
Синхронизация времени 221
5.4. ФРАГМЕНТАЦИЯ IP-ДЕЙТАГРАММ И УЯЗВИМОСТИ, ЕЮ ОБУСЛОВЛЕННЫЕ 222
Размер фрагментов 222
Фрагментирование дейтаграмм маршрутизаторами 223
Уязвимость механизма фрагментации 226
5.5. ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ IP-ЗАГОЛОВКА -
ПОДВОДНЫЕ КАМНИ БЕЗОПАСНОСТИ 227
5.5.1. Какие они есть 227
5.5.2. Запись маршрута (Record Route) 228
5.5.3. Временная метка (Timestamp) 231
5.5.4. Маршрутизация от источника (Source Routing).
Скрытые возможности атаки на сеть 233
Жесткая и свободная маршрутизации от источника 233
Атака на сеть 235
5.5.5. Опция IP Router Alert (опция тревоги) 236
10

Содержание
5.6. ПРОТОКОЛЫ ARP И RARP 237
5.6.1. Общее описание стандартного ARP 237
Протокол ARP и устройство его заголовка 237
Схема работы ARP 238
5.6.2. Безопасность средствами ARP. Фильтр ARP 241
5.6.3. ARP-прокси 242
5.6.4. Протокол RARP(Reverse ARP) 243
5.7. ПРОТОКОЛ IGMP (INTERNET GROUP MANAGEMENT PROTOCOL) 244
5.8. МУЛЬТИКАСТИНГ И КАНАЛЬНЫЙ ПРОТОКОЛ 248
ГЛАВА 6. IP-АДРЕСА 251
6.1. ЧТО ТАКОЕ IP-АДРЕС И КАКОЙ У НЕГО ФОРМАТ 252
6.2. КЛАССЫ И СПЕЦИАЛЬНЫЕ АДРЕСА 253
Классы IP-адресов 253
Специальные IP-адреса 255
6.3. ПОДСЕТИ И МАСКИ СЕТИ 256
Почему стандартных механизмов IPv4 недостаточно
для адресации 256
Подсети и маски 257
Использование постоянных и переменных сетевых масок ....262
6.4. МЕХАНИЗМ БЕСКЛАССОВОЙ МЕЖДОМЕННОЙ МАРШРУТИЗАЦИИ CIDR 265
Бесклассовая адресация 265
Суперсети, автономные системы 266
ГЛАВА 7. МАРШРУТИЗАЦИЯ 275
7.1. ПРОДВИЖЕНИЕ (FORWARDING) И ЭКРАНИРОВАНИЕ (SCREENING) 276
7.2. МАРШРУТИЗАЦИЯ 278
7.2.1. Как это происходит 278
7.2.2. Обработка таблицы маршрутизации 281
7.3. РАБОТА С ТАБЛИЦАМИ МАРШРУТИЗАЦИИ 282
7.3.1. Таблицы маршрутизации
в разных операционных системах и устройствах 283
Таблица маршрутизации в Windows NT 283
Таблица маршрутизации в Windows Server 2000/2003 284
Таблица маршрутизации в UNIX/Linux 284
Таблица маршрутизации на маршрутизаторах CISCO 285
7.3.2. Редактирование таблицы маршрутизации 286

TCP/IP и DNS в теории и на практике. Полное руководство
Работа со статическими записями в таблице
маршрутизации 287
Управление таблицей маршрутизации по протоколу SNMP...288
Объединение (aggregation) нескольких записей 289
7.4. ПРОТОКОЛЫ МАРШРУТИЗАЦИИ 290
LSPnRVP 290
IPG (Interior Gateway Protocol)
и EGP (Exterior Gateway Protocol) 292
Отметка протокола маршрутизации
в таблице маршрутизации. Перераспределение 293
7.5. НЕЙТРАЛЬНЫЕ ТОЧКИ ОБМЕНА (NEUTRAL EXCHANGE POINT (NIX)) 293
ГЛАВА8. ПРОТОКОЛ IP, ВЕРСИЯ 6 295
8.1. ОСОБЕННОСТИ ПРОТОКОЛА IPv6 296
Что нового появилось в протоколе IPv6 296
Заголовок IPv6 297
8.2. ИСПОЛЬЗОВАНИЕ ДОПОЛНИТЕЛЬНЫХ ЗАГОЛОВКОВ В IP-ДЕЙТАГРАММАХ 300
Опции перехода (Hop-by-Hop Options) 302
Заголовок маршрутизации 304
Фрагментация ^6-дейтаграмм. Заголовки фрагментации....306
Заголовок аутентификации (протокол АН) 307
Заголовок безопасности (Протокол ESP) 307
8.3. ПРОТОКОЛ ICMPv6 308
Отображение (mapping) IP-адреса в канальный адрес 310
Определение адреса маршрутизатора в локальной сети 314
Перенаправление (Redirect) 317
8.4. IPv6-АДРЕСА... 318
Правила написания адресов 319
Групповые адреса (Multicasts) 320
Индивидуальные адреса 321
IPv6 и операционные системы семейства Windows 323
ГЛАВА 9. ПРОТОКОЛ УПРАВЛЕНИЯ ПЕРЕДАЧЕЙ
(TRANSMISSION CONTROL PROTOCOL, TCP) 325
9.1. TCP-СЕГМЕНТЫ 328
9.2. ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ TCP-ЗАГОЛОВКА 333
9.3. ПРИМЕР TCP-СЕГМЕНТА ИЗ СЕТИ (NETWORK MONITOR) 335
9.4. УСТАНОВКА И ЗАВЕРШЕНИЕ TCP-СОЕДИНЕНИЯ 336
9.4.1. Установка соединения 336
12

Содержание
9.4.2. Завершение соединения 342
9.4.3. Разрыв соединения 344
9.5. ОПРЕДЕЛЕНИЕ СОСТОЯНИЯ СОЕДИНЕНИЯ 345
9.6. МЕТОДЫ ЗАДЕРЖКИ ОТВЕТА 347
9.7. ТЕХНИКА ОКНА 350
9.8. ПЕРЕГРУЗКА СЕТИ 353
9.8.1. Медленный старт 354
9.8.2. Предотвращение перегрузки 355
9.8.3. Потеря сегмента 356
9.9. ОПЦИЯ РАСШИРЕНИЯ ОКНА (INCREASE WINDOW OPTION) 358
ГЛАВА 10. ПРОТОКОЛ UDP (USER DATAGRAM PROTOCOL) 360
10.1. ПРОТОКОЛ UDP И ЕГО ОСОБЕННОСТИ 361
Общее описание протокола 361
Структура UDP-заголовка 362
Пример UDP-дейтаграммы 364
10.2. ФРАГМЕНТАЦИЯ 365
10.3. ШИРОКОВЕЩАНИЕ И ГРУППОВЫЕ РАССЫЛКИ -
ОТЛИЧИТЕЛЬНАЯ ОСОБЕННОСТЬ ПРОТОКОЛА UDP 365
10.4. ЧЕГО НЕ «УМЕЕТ» UDP 366
10.5. СРАВНЕНИЕ UDP И TCP 366
ГЛАВА 11. СЛУЖБА ИМЕН DNS 368
11.1. ДОМЕНЫ И ПОДДОМЕНЫ 370
11.2. СИНТАКСИС ИМЕНИ 372
11.3. ОБРАТНЫЕ ДОМЕНЫ 373
11.4. ДОМЕН 0.0.127.IN-ADDR.ARPA 375
11.5. ДОМЕННЫЕ ЗОНЫ 375
Что такое зона 375
Специальные Зоны 376
11.6. ЗАРЕЗЕРВИРОВАННЫЕ ДОМЕНЫ И ПСЕВДОДОМЕНЫ 376
11.7. ЗАПРОСЫ DNS (РАЗРЕШЕНИЯ ИМЕНИ) 377
Запросы и их обработка 377
Как работают резолверы 378
Транспортные протоколы, используемые DNS.
Особенности работы с перегруженными DNS-серверами 381
Технология Round Robin 382
11.8. ПРАКТИКА НАСТРОЙКИ РЕЗОЛВЕРОВ 383

TCP/IP и DNS в теории и на практике. Полное руководство
Конфигурация резолвера в Unix 383
Конфигурация резолвера в Windows 384
11.9. СЕРВЕР ИМЕН 388
Типы серверов имен 388
Работа серверов имен 391
11.10. FORWARD-СЕРВЕРЫ 393
ГЛАВА 12. ПРОТОКОЛ DNS 395
12.1. ЗАПИСИ РЕСУРСОВ 396
12.2. ПРОТОКОЛ DNS 398
12.3. ОПЕРАЦИЯ DNS QUERY (ЗАПРОС) 399
12.3.1. Формат пакета DNS-запроса 399
12.3.2. Заголовок пакета запроса DNS query 400
12.3.3. Секция вопроса 402
12.3.4. Секция ответа, авторитетные серверы и дополнительная
информация 405
12.3.5. Сжатие 406
12.3.6. Инверсный (обратный) запрос 409
12.3.7. Методы передачи ресурсных записей в DNS-пакете 409
12.4. ПРИМЕРЫ ОБЩЕНИЯ DNS-КЛИЕНТА И DNS-CEPBEPA 409
Практика использования программы NSLOOKUP
для мониторинга DNS-серверов 422
ГЛАВА 13. РАСШИРЕННЫЕ ФУНКЦИИ ПРОТОКОЛА DNS 427
13.1. ОПЕРАЦИЯ DNS UPDATE 428
13.1.1. Общее описание 428
13.1.2. Формат DNS-пакета для операции UPDATE 430
Секция заголовка 431
Секция зоны 432
Секция условия (Prerequisite Section) 432
Секция обновления 433
Секция дополнительных данных 434
13.1.3. Файл журнала 434
13.1.4. Замечания 435
13.2. ОПЕРАЦИЯ DNS NOTIFY 435
Операция уведомления DNS Notify 435
Сообщение Notify 436
14

Содержание
13.3. ВОЗРАСТАЮЩАЯ ПЕРЕДАЧА ЗОНЫ 439
Формат запроса 440
Формат ответа 441
Генеральная уборка 441
Примеры 441
13.4. ОТРИЦАТЕЛЬНОЕ КЭШИРОВАНИЕ (DNS NCACHE) 444
Какие отрицательные ответы будут храниться в памяти? 444
Сколько времени отрицательные ответы
хранятся в памяти? 445
Поле MINIMUM (Минимум) в SOA-записи 445
Сохранение правил отрицательных ответов 446
ГЛАВА 14. РЕАЛИЗАЦИЯ СЕРВЕРА ИМЕН 447
14.1. НЕМНОГО ПРЕДЫСТОРИИ 448
14.2. БАЗАДАННЫХОЫЗИЕЕЗАПИСИ 451
14.2.1. Синтаксис базы данных DNS 451
14.2.2. Формат записей в базе данных DNS 453
Запись SOA 453
Записи типа А 455
Записи типа CNAME 456
Записи типа HINFO и ТХТ 457
Записи типа NS 457
Записи типа MX 458
Записи типа PTR 459
Записи типа SRV 461
14.2.3. Специальные команды для работы с записями DNS 464
Команда SORIGIN 464
Команда $INCLUDE 465
14.2.4. Реализация в Windows Server 2000/2003 465
14.3. BIND НОВОГО ПОКОЛЕНИЯ (ВЕРСИИ 8 И 9) 471
14.4. КОНФИГУРАЦИОННЫЙ ФАЙЛ BIND 473
14.4.1. Команды конфигурационного файла 474
14.4.2. Примеры конфигурирования name server 474
Кеширующий name server (Caching-only name server) 475
Авторитетный name server 475
14.4.3. Использование комментариев 477
14.4.4 Команда acl 478
15

TCP/IP и DNS в теории и на практике. Полное руководство
14.4.5. Список IP-адресов 478
14.4.6. Команда controls 479
14.4.7. Команда include 480
14.4.8. Команда key 480
14.4.9. Команда logging — протоколирование нестандартных
ситуаций 481
Описание команды logging 481
Создание канала протоколирования 483
14.4.10. Команда options — настройка глобальных опций
DNS-сервера 485
14.4.11. Команда server 488
14.4.12. Команда trusted-keys 488
14.4.13. Команда view 489
14.4.14. Команда zone 493
Общее описание команды и ее назначения 493
14.5. ПАРАМЕТРЫ КОМАНДЫ OPTIONS 495
14.5.1. Спецификация файлов 495
Параметр directory 495
Параметр named-xfer 496
Параметр dump-file 496
Параметр pid-file 496
Параметр statistics-file 496
14.5.2. Параметры типа boolean 496
Параметр auth-nxdomain 496
Параметр fetch-glue 497
Параметр multiple-cnames 497
Параметр notify 497
Параметр recursion 497
14.5.3. Перенаправление Forwarding 498
Параметр forward 498
Параметр forwarders 498
14.5.4. Контроль имен (check-names) 498
14.5.5. Управление доступом (Access Control) 499
Параметр allow-query 499
Параметр allow transfer 499
14.5.6. Сетевые интерфейсы 500
16

Содержание
Параметр listen-on 500
Параметр Nsten-on-verz.e6 500
14.5.7. Передача данных зоны 500
Параметр max-transfer-time-in 500
Параметр transfer-format 500
Параметр transfers-in 501
Параметр transfers-out 501
Параметр transfers-per-ns 501
14.5.8. Временные интервалы 501
Параметр clean-Interval 501
Параметр statics-Interval 501
14.6. КОМАНДЫ РЕДАКТИРОВАНИЯ ФАЙЛОВ ЗОНЫ.
СПЕЦИАЛЬНЫЕ ВОЗМОЖНОСТИ BIND 9 502
14.6.1. Команда $TTL 502
14.6.2. Команда $GENERATE 502
14.6.3 Lightweight resolver 503
14.6.4. Команда Iwres 504
14.7 ИНСТРУМЕНТЫ ДЛЯ ОТЛАДКИ И УПРАВЛЕНИЯ DNS 505
14.7.1. Способы контроля над конфигурированием 505
14.7.2. Проверка конфигурационных файлов 506
Программа named-checkconf 506
Программа named-checkzone 507
14.7.3. Программа nslookup — оптимальный выбор
для тестирования DNS 507
Общее описание программы 507
Режим отладки 511
Уровень режима отладки debug 511
Уровень режима отладки d2 513
Замена сервера имен, используемого по умолчанию 516
Запись зоны 516
Имитация запросов от сервера имен 517
Наиболее часто встречаемые сообщения об ошибках
программы nslookup 517
14.7.4. Прочие программы, предназначенные для проверки DNS 518
Программа Dnswalk 518
Программа Dig 519
14.8. ДИСТАНЦИОННОЕ УПРАВЛЕНИЕ СЕРВЕРОМ ИМЕН. ПРОГРАММА RNDC 521

TCP/IP и DNS в теории и на практике: Полное руководство
Общее описание и методика использования 521
Обзор команд программы rndc 523
14.9. СИГНАЛЫ 524
Методика использования сигналов 524
Сигнал HUP 524
Сигналит 524
Сигнал ЮТ 526
Сигнал KILL 527
Сигнал TERM 527
Сигналы USR1 и USR2 527
14.10.ДЕСЯТЬ НАИБОЛЕЕ ЧАСТО НАРУШАЕМЫХ ПРАВИЛ В КОНФИГУРАЦИИ DNS 528
ГЛАВА 15. РЕГИСТРАЦИЯ И ДЕЛЕГИРОВАНИЕ ДОМЕНОВ 530
15.1. МЕТОДИКА ДЕЛЕГИРОВАНИЯ ДОМЕНОВ 531
15.2. ПРИМЕР 1. ДЕЛЕГИРОВАНИЕ ДОМЕНА: СТАНДАРТНАЯ СИТУАЦИЯ 532
Сервер ns . сompany .tld 532
...Сервер ns . provider. net 533
Сервер ns .manager-tld. tld 534
15.3. ПРИМЕР 2. РАСШИРЕНИЕ КОМПАНИИ 534
Сервер п s . с ompany. с от 535
Сервер ns .branch, company, tld 535
15.4. РЕГИСТРАЦИЯ ДОМЕНА 536
ГЛАВА 16. ДЕЛЕГИРОВАНИЕ И РЕГИСТРАЦИЯ ОБРАТНЫХ ДОМЕНОВ 539
16.1. ВИДЫ И ТИПЫ ОБРАТНЫХ ДОМЕНОВ 540
16.2. ПРИМЕР ДЕЛЕГИРОВАНИЯ ОБРАТНОГО ДОМЕНА 541
16.2.1. Конфигурационные файлы 541
Сервер ns . firma.cz 542
Сервер ns .provider.net 543
Сервер ns . ripe. net (авторитетный сервер
для вышестоящего домена) 543
16.2.2. Описание 543
16.2.3. Конфигурационные файлы (продолжение) 545
Сервер ns . firma.cz 545
Сервер ns . cbu. firma.cz 546
16.3. РЕГИСТРАЦИЯ ОБРАТНОГО ДОМЕНА 546
18

Содержание
ГЛАВА 17. ИНТЕРНЕТ-РЕЕСТРЫ 549
17.1. МЕЖДУНАРОДНЫЕ ОРГАНИЗАЦИИ 550
17.2. РЕГИОНАЛЬНЫЕ ИНТЕРНЕТ-РЕЕСТРЫ (RIR) 552
17.3. КОДЫ СТРАН И RIR 553
17.4. 1Ру4-АДРЕСАИНОМЕРААС 563
17.5. ИНТЕРНЕТ-РЕЕСТРЫ ИЛИ КАК ПОЛУЧИТЬ В УПРАВЛЕНИЕ ЧАСТЬ ИНТЕРНЕТА 564
17.5.1 Регистрация локального интернет-реестра (LIR) 564
17.5.2. Когда договор заключен 565
17.5.3. Базы данных RIPE 565
Объект Inetnum 566
Объект Domain (Домен) 567
Объекты Person (Персона) и Ро1е(Роль) 567
Объект Aut-num 568
Объект маршрутизации 569
Объект Mntner 569
Просмотр содержимого базы данных 570
17.5.4. Связь с RIPE 571
Изменение базы данных 572
Как добавить объект в базу данных 572
Как модифицировать объект базы данных 574
Как удалить объект 575
17.5.5. Назначение IP-адресов и номеров автономных систем.
Регистрация обратных доменов 575
17.5.6. Распределение адресного пространства 575
17.5.7. Защита и контроль над изменениями в базе RIPE.
Уведомление и авторизация объектов 577
17.6. ДЕЛЕГИРОВАНИЕ ДОМЕНОВ ВТОРОГО УРОВНЯ 579
ГЛАВА 18. DNS В ЗАКРЫТЫХ КОРПОРАТИВНЫХ СЕТЯХ 580
18.1. ЗАКРЫТЫЕ КОРПОРАТИВНЫЕ СЕТИ И СВЯЗАННЫЕ С НИМИ DNS-ПРОБЛЕМЫ 581
18.2. КОРНЕВОЙ DNS-CEPBEP В WINDOWS SERVER 2000/2003 584
ГЛАВА 19. DNS И FIREWALL 585
19.1. ОБЩАЯ DNS: ДЛЯ ИНТЕРНЕТА И ЛОКАЛЬНОЙ СЕТИ 587
19.1.1. Трансляция всего Интернета по локальной сети 588
19.1.2. По локальной сети передаются только внутренние адреса. ...591
19.2. СЕРВЕР ИМЕН, ИНСТАЛЛИРОВАННЫЙ НА БРАНДМАУЭРЕ 593
19

Содержание
19.2.1. Преобразование в локальной сети всего Интернета 593
19.2.2. Преобразование в локальной сети без преобразования
в Интернете 594
19.3. ДУБЛИРОВАННЫЙ DNS 595
ГЛАВА 20. ЗАЩИТНЫЕ МЕХАНИЗМЫ И УЯЗВИМОСТИ TCP/IP И DNS 598
20.1. БЕЗОПАСНОСТЬ И УЯЗВИМОСТИ IP 599
Уязвимости IP 599
Методы атак на TCP/IP 600
Принципы IP-защиты 601
20.2. БЕЗОПАСНОСТЬ И УЯЗВИМОСТИ DNS 603
20.2.1. Уязвимости 603
20.2.2. Инструменты и механизмы защиты 604
Технология защиты TSIG 604
DNSSEC 605
СПИСОК ЛИТЕРАТУРЫ, ИСПОЛЬЗОВАННЫЙ ПРИ ПОДГОТОВКЕ
РУССКОГО ИЗДАНИЯ КНИГИ 606

Введение
СЕТЕВЫЕ ПРОТОКОЛЫ И МОДЕЛИ
ВЗАИМОДЕЙСТВИЯ
ОТКРЫТЫХ СИСТЕМ
МОДЕЛЬ ВЗАИМОДЕЙСТВИЯ ISO OSI
СТЕК ПРОТОКОЛОВ TCP/IP
СПОСОБЫ ПЕРЕДАЧИ ИНФОРМАЦИИ
ВИРТУАЛЬНАЯ ЦЕПЬ
TCP/IP и DNS в теории и на практике. Полное руководство

В.1. Сетевые протоколы
и модели взаимодействия открытых систем
Так же, как и дипломаты, использующие в ходе переговоров
дипломатический протокол, компьютеры в компьютерных сетях используют для
осуществления взаимной коммуникации сетевые протоколы.
Существует целый ряд сетевых протоколов. В Интернете используются сетевые
протоколы TCP/IP.
Сетевой протокол — это норма, зафиксированная на бумаге (например,
с помощью текстового редактора на компьютере). В Интернете
используются нормы, называемые Request For Comments (сокращенно — RFC),
которые имеют сквозную нумерацию, начиная с единицы. В настоящее
время их насчитывается более трех тысяч. Многие нормы со временем
устарели, поэтому из норм, относящихся к первой тысяче, осталось лишь
несколько актуальных.
Международная организация по стандартизации (ISO)
стандартизировала систему протоколов, обозначаемых как ISO OSI. Другой известной
организацией, издающей нормы в области коммуникации, является ITU.
Все стандарты для высокопроизводительных линий связи
определяются организацией ITU-TSS. Ранее эта организация носила имя CCITT.
Расположенная в Женеве, ITU (CCITT) является одной из самых
старых всемирных организаций, которая была основана в 1865 году (для
сравнения: «Красный Крест» был основан в 1863 году).
Далее нам встретятся нормы, изданные гильдией инженеров по
электротехнике IEEE. Мы можем легко получить доступ к нормам RFC, так как
их можно бесплатно скачать из Интернета. Остальные организации не
предоставляют возможность бесплатного скачивания своих норм — за
них нужно платить. Если плата за скачивание норм является для вас
препятствием, то их придется изучать в библиотеке.

Введение
Многие свободно распространяемые нормы также содержатся на интер
нет странице данной публикации по адресу: http: //www.cpress.cz/
knihy/tcp-ip-bezp. Сначала объясним, почему проблематика сете
вой коммуникации всегда делится на проблематику нескольких
протоколов. Ответ очень простой. Сама проблематика является очень
сложной, она охватывает несколько профессий. В большинстве публикаций
о сетевых протоколах приводится в качестве сравнения коммуникация
между двумя иностранцами (философами, шаманами и т. д.), каждый из
которых может говорить только на своем языке. Для того чтобы эти люди
могли обменяться между собой мыслями, каждый из них должен
позаботиться о наличии профессионального переводчика, выполняющего пере
вод с/на общий для них язык — например, чешский (см. рис. В.1).
Иностранцы
t
M Переводчицы Щ
U )\
*• ^* Физическое ** м
•< ►
соединение
Рис. В. 1. Трехуровневая архитектура коммуникации
В результате оба иностранца обмениваются своими мыслями, то есть
осуществляют коммуникацию между собой. Однако такая коммуника
ция является виртуальной. В действительности, оба человека передают
информацию переводчикам, которые, в свою очередь, с помощью голо
совых связок озвучивают информацию на понятном для получателя
языке. Либо обе стороны удалены друг от друга, и при этом переводчики
общаются по телефону. В таком случае информация физически переда
ется по телефонным линиям связи.
Различается виртуальная коммуникация в горизонтальном направле
нии (коммуникация на общем языке между переводчиками, а также
23

TCP/IP и DNS в теории и на практике. Полное руководство
с помощью электрических сигналов, передаваемых по телефонной
линии) и действительная коммуникация в вертикальном направлении,
представленная в следующих видах: иностранец — переводчик и
переводчик — телефон. На приведенном рисунке представлены три уровня
коммуникации:
• коммуникация между иностранцами;
• коммуникация между переводчиками;
• физическая передача информации через носитель (например, по
телефонной линии или через звуковые волны и т. п.).
В компьютерных сетях мы используем еще больше уровней. Количество
уровней зависит от того, какую систему сетевых протоколов мы
используем. Иногда вместо термина «система сетевых протоколов»
используется понятие так называемой сетевой модели. Чаще всего нам будет
встречаться модель, которая используется Интернетом.
TCP/IP
Прикладная
программа
эвены у
Прикладной
TCP/UDP
Сетевой
Канальный
Физический
Ур
ISO OSI
Прикладная
программа
овень: у
Прикладной
Представления
Сеансовый
Транспортный
Сетевой
Канальный
Физический
Рис. В. 2. Сравнение сетевых моделей TCP/IP и ISO OSI
Данная модель также называется семейством протоколов TCP/IP.
Кроме протоколов TCP/IP, нам еще встретится модель ISO OSI,
стандартизированная Международной организацией по стандартизации (ISO).
Семейство протоколов TCP/IP использует четыре уровня, тогда как
протоколы ISO OSI используют целых семь уровней, как показано на
рис. В.2.
24

Введение
Системы сетевых протоколов TCP/IP и ISO OSI отличаются друг от
друга — их нельзя сравнивать между собой. Из рис. В.2 видно, что они
расположены очень близко друг к другу на сетевом и транспортном уровне.
Семейство сетевых протоколов TCP/IP не решает (за исключением
протоколов SLIP и РРР) проблем на канальном и физическом уровнях,
поэтому в Интернете нам встречаются канальные и физические
протоколы модели ISO OSI.
В.2. Модель взаимодействия ISO OSI
Взаимодействие между двумя компьютерами в рамках модели ISO OSI
схематически изображено на рис. В.З.
Прикладная
программа
Прикладная
программа
Прикл.
Пред.
Сеанс.
Транс.
Сет.
Канал.
Ж
Физич. f
Прикладной уровень
Уровень представления
Сеансовый уровень
Транспортный уровень
Сетевой уровень
Канальный уровень
Физический уровень
Физический уровень
Прикл.
Пред.
Сеанс.
Транс.
Сет.
Канал.
Физич
j
ч. ВВ|
Рис. В.З. Семиуровневая архитектура ISO OSI
В. 2.1. Физический уровень
Говоря формальным языком, физический уровень отвечает за
активацию, коммуникацию и дезактивацию физической цепи между DTE
(Data Terminal Equipment) и DCE (Data Circuit-terminating Equipment).
Кроме того, он отвечает за коммуникацию между DCE (см. рис. В.4).
Под DTE мы подразумеваем, например, компьютер или маршрутизатор,
а под DCE — как правило, модем или мультиплексор.
25

TCP/IP и DNS в теории и на практике. Полное руководство
Попросту говоря, на физическом уровне, собственно, и осуществляется
передача информации между открытыми системами. Информация
передается в битах, представляющих собой двоичный разряд и
являющихся базовыми информационными единицами.
Протоколы физического уровня учитывают физические характеристики
сигналов и среды, по которой осуществляется передача информации (тип
провода, кабеля, разъемов и т. п.). Сам процесс передачи информации
заключается в передаче сигнала, изменение которого отражает
пересылаемые данные. Сигнал может быть самым разным. Кабельные линии
представляют нули и единицы (значения бита) в виде различных значений
напряжений, при звуковой передаче данных для этих целей используется
звуковая модуляция (различные значения частот) и т. д. и т. п.
Современные технологические достижения позволяют использовать
для передачи информации самые различные носители: всевозможные
электрические кабели, оптоволокно, дециметровые волны и даже
обычный свет. Использование каждого из них может быть реализовано с
помощью индивидуального набора протоколов физического уровня.
Все остальные уровни, располагающиеся над физическим уровнем,
являются абсолютно независимыми от среды, через которую
осуществляется их взаимодействие. Поменял линию подключения, например,
телефонную на оптоволокно — смени протоколы физического уровня,
а все остальные уровни какими были, такими и останутся.
Phc.B.4.DTEhDCE
26

Введение
На физическом уровне создается так называемая физическая цепь.
В физическую цепь между двумя компьютерами часто помещаются
прочие устройства, например, модемы, модулирующие цифровые данные
в аналоговый сигнал, передаваемый по телефонной линии, и т. п.
Протоколы физического уровня специфицируют:
• электрические сигналы (например, +1V);
• виды соединителей (например, V.35);
• вид носителя: скрученный двужильный провод, коаксиальный
кабель, оптическое волокно и т. д.;
• скорость передачи (например, 128 Кб/с);
• модуляцию (например, FM, РМ и т. д.);
• кодировку (например, RZ, NRZ и т. д.);
• синхронизацию: синхронная/асинхронная коммуникация, источник
времени и т.д.
В.2.2. Канальный уровень
Если физический уровень реализует передачу данных по физической
среде, то канальный уровень отвечает за обеспечение этой передачи. Он
ответственен за связь узлов в рамках одной локальной сети. Канальный
уровень обеспечивает помещение кадров данных в последовательную
линию, связывающую компьютеры в глобальной сети, а в случае с
локальными сетями — обмен данными в рамках локальной сети.
Заголовок
(Header)
Данные
(Payload)
Конечное поле
(Trailer)
Рис. В. 5. Канальный фрейм
Основополагающей единицей передачи данных на канальном уровне
является фрейм данных (см. рис. В.5). Фрейм данных складывается из
заголовка (Header)y передаваемых данных (Payload) и конечного поля (Trailer).
Фрейм данных содержит в заголовке канальный адрес получателя,
канальный адрес отправителя и прочую управляющую информацию.
27

TCP/IP и DNS в теории и на практике. Полное руководство
В конечном поле обычно содержится контрольный код из передаваемых
данных. С помощью контрольного кода можно определить, не
произошло ли повреждение данных в ходе их передачи. В передаваемых
данных, как правило, содержится пакет сетевого уровня.
Если следовать рис. В.4, канальный уровень не занимается
вопросами коммуникации между DTE и DCE (канальный уровень «не видит»
DCE). Он занимается обменом фреймов между DTE. То есть полагается,
что проблематика DCE находится в ведении физического уровня.
Как видно из рис. В.6, на физическом уровне для каждого узла
соединения могут использоваться различные протоколы. В нашем случае один
узел соединения использует протокол Х.21, а другой — протокол V.35.
Это касается не только последовательных каналов, но также и
локальных сетей. Применительно к локальным сетям может встретиться
более сложный случай, когда между обоими узлами соединения помещен,
например, переключатель (Switch), преобразующий канальные фреймы
одного канального протокола во фреймы другого канального протокола
(например, Ethernet в FDDI), в результате чего, разумеется, на
физическом уровне будут использоваться различные протоколы.
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
Х.21 t^
Л
модем
Li
: Физический :
Л
модем
ЛЛ
: Физический 1
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный,
Физический
S V.35
Рис. В.6. Коммуникация на канальном уровне
Канальным интерфейсом может быть, например, Ethernet-карта или
порт последовательной линии. Канальный интерфейс имеет канальный
адрес, который является однозначным в рамках локальной сети (LAN).
В.2.3. Сетевой уровень
Наличие сетевого уровня обусловлено необходимостью реализации
межсетевого взаимодействия. Только самые простые сети состоят из од-
28

Введение
ной локальной сети. Обычно сети имеют развернутую структуру и
состоят из нескольких объединенных локальных сетей.
Почему нельзя сделать одну большую локальную сеть? Да потому,
что передача данных в локальной сети, осуществляемая канальным
уровнем, имеет широковещательный характер, то есть передается всем
компьютерам сразу. Что, помимо вопросов безопасности, имеет чисто
технический аспект — значительное увеличение трафика (объема
передаваемых данных) на отдельно взятых участках, что, в свою очередь,
порождает замедление работы сети. Наличие такой глобальной сети,
как Интернет, при такой постановке вопроса вообще было бы
невозможно.
В отличие от канального уровня, имеющего дело с физическими адресами,
сетевой уровень работает с логическими адресами, индивидуальными
для каждого компьютера, подключенного к сети.
Таким образом, сетевой уровень обеспечивает передачу данных между
удаленными компьютерами в глобальной сети. Основной единицей
передачи данных является сетевой пакет, который помещается в
оболочку — фрейм данных. Сетевой пакет также состоит из заголовка и поля
данных. Конечное поле у сетевых протоколов встречается редко.
'
Канальный
заголовок
Сетевой
заголовок
Данные
' '
Данные (Payload)
г
Конечное
поле
Рис. В.7. Сетевой пакет и его размещение в оболочке — канальном фрейме
Как видно из рис. В.7, сетевой заголовок вместе с данными сетевого
пакета образует поле данных (Payload) канального фрейма.
В глобальных сетях (WAN) между компьютерами, как правило,
находится один или несколько маршрутизаторов. Между соседними
маршрутизаторами на канальном уровне всегда имеется прямое соединение.
Маршрутизатор вынимает сетевой пакет из фрейма данных (одного
канального протокола) и перед тем, как отправить его в другой канал,
помещает в оболочку другой фрейм данных (обычно другого канально-
29

TCP/IP и DNS в теории и на практике. Полное руководство
го протокола). Сетевой уровень «не видит» устройств, работающих на
физическом и канальном уровнях (модемов, повторителей,
переключателей и т. д.).
Приклад.
ОвтввоЙс
Канальный |
Физический:
Л Л
модем модем
JL1 ., /...1 :
• Физический : • Физический :
л
Е
маршрутизатор
&юШк$
Л
маршрутизатор
[ш
а
: Канальный
! Физический
А А
повторитель повторитель
...J...A ; 1.Л....,
j Физический : • Физический :
Представ.
Транспорт.
'Р0Ш$&
Канальный
Физический
Канальный протокол I
Канальный
протокол II
Единый сетевой протокол
Канальный протокол III
Рис. В.8. Коммуникация на сетевом уровне
Для сетевого уровня безразлично, какие именно канальные протоколы
использовались на пути между обоими узлами соединения.
Сетевым интерфейсом может быть, к примеру, карта для Ethernet или
последовательный порт. Сетевой интерфейс имеет однозначный адрес
в рамках WAN.
В.2.4. Транспортный уровень
Транспортный уровень имеет функции, аналогичные некоторым
функциям сетевого уровня. Его наличие обусловлено тем, что протоколы
сетевого уровня могут пересылать и принимать информацию по
логическим адресам, но они не гарантируют надежности этой передачи данных
между двумя компьютерами. Устранить этот недостаток призваны
протоколы, образующие особый, транспортный уровень.
При этом надежность транспортного уровня говорит не о том, что при
передаче информации ошибок возникать не будет. Надежность
транспортного уровня заключается в гарантии, что эти ошибки будут
выявлены и исправлены (путем повторной передачи).
Сетевой уровень обеспечивает соединение между удаленными
компьютерами, поэтому транспортному уровню «кажется», что никаких модемов,
30

Введение
повторителей, мостов или маршрутизаторов на пути нет. Транспортный
уровень полностью полагается на работу служб более низких уровней.
Он рассчитывает на то, что соединение между компьютерами
установлено, следовательно, он без лишних хлопот может заняться обеспечением
соединения между приложениями на удаленных компьютерах.
Приклад.
Представ.
Сеансовый
[Транспорт
Сетевой
Канальный
Физический
, А
• Физический:
А ,
• Физический!
Транспортный протокол
Г.А , , Л
: Сетевой • : Сетевой
! Канальный : j Канальный
! Физический! • физический
„
;....А......:
| Физический:
, А
; Физический:
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
Рис. В.9. Соединение на транспортном уровне
Между двумя компьютерами может быть установлено несколько
транспортных соединений одновременно — одно соединение, к примеру, для
виртуального терминала, а другое — для электронной почты. С точки
зрения сетевого уровня, транспортные пакеты имеют адрес компьютера (или
его сетевого интерфейса). С точки зрения транспортного уровня, они
адресованы отдельному приложению. Приложения имеют однозначные
адреса в рамках одного компьютера, поэтому транспортный адрес, как
правило, образуется путем соединения сетевого и транспортного адресов.
Единицей передачи данных является транспортный пакет, который
опять же состоит из заглавия и части данных. Транспортный пакет
передается в части данных сетевого пакета.
'
Канальный
заголовок
1
Сетевой
заголовок
Транспортный
заголовок
Данные
t
Данные
> i
Данные
f
>
Конечное
поле
Рис. В. 10. Размещение транспортных пакетов в сетевых пакетах,
которые затем помещаются в канальные фреймы
31

TCP/IP и DNS в теории и на практике. Полное руководство
В.2.5. Сеансовый уровень
Сеансовый уровень своей задачей имеет установление и разрыв сеансов
между компьютерами (приложениями), а также управление диалогами
между ними. Сеансом называется логическое соединение между двумя
компьютерами.
Каждый сеанс имеет три фазы:
1. Установление соединения. На данном этапе компьютеры
устанавливают друг с другом контакт: договариваются об использовании
одних протоколов и параметров связи.
2. Передача информации. На этом этапе компьютеры осуществляют
обмен данными.
3. Разрыв соединения
Сеансовый уровень обеспечивает обмен данными между
приложениями, то есть осуществляет так называемый checkpoint, синхронизацию
транзакций (commit), корректное закрытие файлов и т. д. Наглядным
примером соединения может служить, например, совместное
использование сетевого диска.
Диск может совместно использоваться в течение определенного
времени, однако работают с ним нечасто. Всегда, когда, к примеру, нужно
работать с тем или иным файлом на сетевом диске, на транспортном
уровне устанавливается соединение на срок с момента открытия файла до
его закрытия. Однако само соединение на сеансовом уровне существует
в течение всего срока совместного использования диска.
Основной единицей передачи данных является сеансовый пакет,
который опять-таки помещается в транспортный пакет. В литературе часто
может встретиться рисунок, на котором показано, что сеансовый пакет
образуется из заголовка сеанса и данных сеанса — при этом сам
сеансовый пакет помещается в транспортный пакет. Выше сеансового уровня
так быть не должно.
Информация сеансового уровня может быть помещена внутри данных.
Еще более примечательна ситуация с уровнем представления, который
данные, к примеру, шифрует, изменяя при этом содержимое всего
пакета в целом.
32

Введение
В. 2.6. Уровень представления
Представительный уровень служит для корректного представления
данных вышестоящему прикладному урбвню. С помощью него два
взаимодействующих стека протоколов (или две взаимодействующие
открытые системы) договариваются о формате, или, иначе говоря, синтаксисе
передаваемой друг другу информации.
Например, если связываются два компьютера с различной кодировкой
символов, то представительный уровень может отвечать за
преобразование присланной информации из чужой кодировки в свою.
Кроме того, уровень представления отвечает за защиту данных. При
этом под защитой подразумевается шифрование данных, обеспечение
их целостности, расстановка цифровой подписи и т. д.
В.2.7. Прикладной уровень
Прикладной уровень является высшим уровнем в модели
взаимодействия открытых систем. Именно на этом уровне осуществляется
работа служб, необходимых пользовательским приложениям (программам)
для работы в сети.
Этими службами могут являться:
• обмен электронной почтой. При этом протокол, работающий
с электронной почтой, поддерживается множеством различных
приложений;
• удаленный доступ к файлам, пересылка файлов;
• выполнение различных задач на удаленном компьютере и т. п.
Прикладной
Представление
Сеансовый
Транспортный
Сетевой
Канальный
Физический
Х.400, FTAM, CMIP
X.226.X.216.ASN.1
Х.225.Х.215
ТР 0-4, ТР дискрет.
Х.25, Х.75, ISDN
HDLC, LAPB, ISDN
V.24,V35,X.21,ISDN
Рис. В. 11. Некоторые сетевые протоколы из семейства протоколов ISO OSI
2 За* 518
33

TCP/IP и DNS в теории и на практике. Полное руководство
Прикладной уровень предписывает, в каком формате и каким образом
данные должны быть получены/переданы программами приложений.
Например, протокол «Виртуальный терминал» описывает то, как
данные должны быть отформатированы, а также диалог между обоими
узлами соединения.
В.З. Стек протоколов TCP/IP
Семейство протоколов TCP/IP не предназначено (за некоторыми
исключениями) для обеспечения процессов на физическом и канальном
уровнях. Практически в Интернете для физического и канального
уровней часто используются протоколы, соответствующие нормам ISO OSI,
стандартизированным ITU.
Каково же отношение между протоколами ISO OSI и TCP/IP? Каждая
группа имеет собственное определение своих уровней и протоколов на
этих уровнях. В связи с этим протоколы ISO OSI и TCP/IP обычно
несопоставимы. Однако на практике необходимо использовать
коммуникационное оборудование, соответствующее ISO OSI, для передачи IP-
пакетов или, напротив, реализовывать службы согласно ISO OSI через
Интернет.
В.З. 1. Протокол IP (Internet Protocol)
Протокол Internet Protocol (далее — IP) практически соответствует
сетевому уровню. Протокол IP передает данные (так называемые
IP-дейтаграммы) между удаленными компьютерами. Каждая IP-дейтаграмма
в своем заголовке содержит адрес получателя, представляющий собой
полную маршрутную информацию, необходимую для доставки
IP-дейтаграммы адресату. Кроме того, каждая IP-дейтаграмма может
передаваться самостоятельно. По этой причине IP-дейтаграммы могут достичь
адресата не в том порядке, в котором они были отправлены.
Каждый сетевой интерфейс в обширной сети Интернет имеет свой IP-
адрес (один сетевой интерфейс может иметь несколько IP-адресов, но
при этом один IP-адрес не может использоваться несколькими
сетевыми интерфейсами). Интернет образуют отдельные сети, которые
соединены между собой с помощью маршрутизаторов. В английском языке
34

Введение
маршрутизатор обозначается словом router. Однако в более ранних
публикациях он обозначается как gateway.
IP-протоколу посвящены главы 5, 6 и 7.
8.3.2. Протоколы TCP и UDP
Протоколы TCP и UDP соответствуют транспортному уровню.
Протокол TCP доставляет данные с помощью TCP-сегментов, которые
адресованы отдельным приложениям. Протокол UDP является
упрощенным вариантом транспортного протокола и, соответственно, доставляет
данные с помощью так называемых UDP-дейтаграмм.
Протоколы TCP и UDP обеспечивают соединение между
приложениями, работающими на удаленных компьютерах. Протоколы TCP и UDP
могут обеспечивать также коммуникацию между процессами,
работающими на одном компьютере. Однако это, на наш взгляд, не представляет
большого интереса.
Различие между протоколами TCP и UDP заключается в том, что
протокол TCP является так называемой службой, ориентированной на
установку соединения, при котором получатель подтверждает факт
получения данных. В случае утери данных (утери TCP-сегмента) получатель
требует повторной передачи данных. Протокол UDP передает данные без
требования их подтверждения (аналог телеграммы), то есть отправитель
посылает дейтаграмму, и ему уже неважно, была она доставлена или нет.
Адресом в рамках транспортного протокола служит так называемый
порт. Для того, чтобы понять различие между IP-адресом и портом,
используется сравнение с почтовым адресом. IP-адрес соответствует
адресу дома, тогда как порт — номеру квартиры.
Протоколу TCP посвящена глава 9, протоколу UDP — глава 10.
8.3.3. Протоколы приложений
Протоколы приложений соответствуют нескольким уровням ISO OSI.
Сеансовый уровень, уровень представления и прикладной уровень ISO
OSI сводятся к одному уровню приложений TCP/IP.
Вопрос об отсутствии уровня представления решается введением
специальных «представительных» протоколов приложений, таких как про-
35

TCP/IP и DNS в теории и на практике. Полное руководство
токолы SSL и S/MIME, специализирующиеся на обеспечении защиты
данных, или протоколы «Виртуальный терминал» и ASN.1,
предназначенные для представления данных. «Виртуальный терминал» (не
путать с одноименным протоколом в ISO OSI) специфицирует способ
представления данных в сети для протокола Telnet, однако этот
протокол используется также другими протоколами (FTP, SMTP и
частично HTTP). Аналогичным образом протокол ASN.1 (включая кодировку
BER, или DER) сначала использовался протоколом SNMP, теперь же он
используется, например, и протоколом S/MIME.
Существует огромное множество протоколов приложений. Если
посмотреть на данный вопрос с практической точки зрения, их можно
разделить на следующие:
• Пользовательские протоколы, которые применяются
пользовательскими приложениями (например, для поиска информации в
Интернете). К таким протоколам относятся HTTP, SMTP, Telnet, FTP,
IMAP, РОРЗ и т. д.
• Служебные протоколы, то есть протоколы, с которыми обычные
пользователи Интернета не имеют дела. Эти протоколы служат для
того, чтобы Интернет правильно функционировал. Речь идет,
например, о протоколах маршрутизации, которые взаимно используют
маршрутизаторы для правильной настройки маршрутных таблиц.
Примером служебного протокола является протокол SNMP,
служащий для управления сетью.
1 пгр
1 Telne
| ICMP
* 1
Прикладные протоколы
HTTP
IMAP
1 SSL I
1 DNS 11
TCP
IGMP |
NFS
| XDR
RPC
BOOTP
UDP
IP-протокол
| ARP |
Канальный и физический уровень
TFTP |
RARP |
Рис. В. 12. Некоторые протоколы из семейства протоколов TCP/IP
36

Введение
В.4. Способы передачи информации
В.4.1. Синхронная передача данных
Синхронная передача данных необходима, например, для передачи
видео и звука, то есть тогда, когда требуется в ходе всего процесса передачи
данных обеспечить необходимое постоянное значение ширины потока
данных. Если отправитель не использует поток данных в полном
объеме, то его часть остается неиспользованной.
При синхронной передаче используются фреймы постоянной длины,
которые передаются по сети с постоянной скоростью.
1. кадр 2. кадр
Слот
1
Слот
2
Слот
3
-
Слот
п
Слот
1
Слот
2
Слот
3
-
Слот
п
Рис. В. 14. Разделение фреймов на слоты при синхронной передаче данных
Ширина потока данных при синхронной передаче гарантируется
разделением передаваемых фреймов на слоты. Для данного соединения
в каждом передаваемом фрейме выделяется один или несколько слотов
(см. рис. В. 13). Если представить, что в каждом фрейме, к примеру, слот
1 выделен для нашего соединения, то, поскольку фреймы равномерно
следуют друг за другом при передаче по сети, наше приложение будет
иметь гарантированную ширину потока данных, которая задается тем,
сколько слотов 1 будет передано по сети за секунду.
Суть можно понять, если начертить несколько фреймов один под
другим в так называемом суперфрейме (см. рис. В. 14). Слоты,
расположенные один под другим, относятся к одному и тому же соединению.
С синхронной передачей данных мы встречаемся, например, в случае
подключения корпоративной телефонной станции к телефонной
станции Telecom. Такая станция может подключаться с помощью линии
связи Е1, содержащей 32 слота, ширина потока каждого из которых
равняется 64 Кб/с. Слот можно использовать для телефонного разговора.
При таких условиях теоретически гарантируется 32 разговора (однако
некоторые слоты используются в качестве служебных).
Интернет не использует синхронную передачу данных, то есть обычно не
гарантирует ширину потока передаваемых данных. Качественная переда-
37

TCP/IP и DNS в теории и на практике. Полное руководство
Г i г
Слот
|| 1 |
Слот
|| 1 |
I 1
Слот
2
Слот
2
Слот
3
Слот
3
Слот
4
Слот
4
Слот
5
Слот
5
Слот
6
Слот
6
1 *
Слот]
7
Слоч|
7
Слот
1 8
Слот
1 8
Кадр1
Кадр 2
i
т-
0)
S
X
Ф
I
S
9
о
о
i A
см
ф
s L
х Г
Q)
X
S
0)
о
и|
Кадрп
Рис. В. 13. Суперфрейм
ча звука или видео в Интернете, как правило, достигается
переназначением размеров для каналов передачи данных. В последнее время постоянно
увеличивается спрос на передачу звука или видео через Интернет,
поэтому мы все чаще встречаемся с системами, обеспечивающими ширину
потока данных даже в Интернете (QoS). Однако для того, чтобы /;остичь
желаемого эффекта, эти службы должны поддерживать работу различных
устройств, находящихся на пути от отправителя к получателю. В связи
с этим в настоящее время в Интернете нам могут встретиться лишь
отдельные области, где гарантируется ширина потока передачи данных.
В.4.2. Пакетная передача данных
Пакетная передача является особенно выгодной для передачи данных.
В пакетах обычно содержатся данные различной длины.
Пакет всегда содержит данные одного приложения (одного соединения).
Поскольку пакеты имеют различную длину, гарантировать ширину потока
невозможно. Преимущество здесь заключается в эффективном
использовании потока данных, так как в случае, когда приложению не нужно
передавать данные, поток может использоваться другими приложениями.
38

Введение
Заголовок
Данные
Конечное
X поле-'*: ^
Н Заголовок
Данные
...|Щ#|И1о|^
Рис. В. 15. Пакетная передача данных
В.4.3. Асинхронная передача данных
При асинхронной передаче данных используется протокол ATM. Этот
вид передачи сочетает в себе пакетную и синхронную передачу данных.
щ
ячейка
Данные
щ
ячейка
Данные
ячейка
Данные
j|
ячейка
Данные
Рис. В. 16. Асинхронная передача данных
Так же, как и при пакетной передаче данных, при асинхронной
передаче данные передаются в небольших пакетах одинаковой величины,
которые называются ячейками. Как и при пакетной передаче данных,
в одной ячейке передаются данные одного приложения (одного
соединения).
Сами ячейки имеют одинаковую длину. Если гарантируется, что каждая
х-я по счету ячейка будет в распоряжении конкретного приложения
(конкретного соединения), то тем самым гарантируется и ширина потока.
В.5. Виртуальная цепь
В.5.1. Концепция виртуальной цепи
Некоторые сетевые протоколы образуют в сети виртуальную цепь
(Virtual Circuit). Виртуальной цепью управляет сеть, и все пакеты
соединения проходят по этой цепи. Если цепь где-то прервется, то прервется
и соединение. Тогда будет создана новая цепь, после чего снова может
начаться процесс передачи данных.
На рис. В. 17 показана созданная виртуальная цепь между узлами А и D
через узлы В, F и G. Все пакеты должны проходить по этой цепи. С по-
39

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. В. 17. Виртуальная цепь
мощью виртуальной цепи дейтаграммы могут передаваться без гарантии
их доставки получателю (то есть в случае перегрузки сети дейтаграмма
может быть удалена), или, напротив, виртуальная цепь может
установить соединение и гарантировать доставку данных.
Протоколом, работающим по принципу передачи без гарантии,
является, например, Frame Relay. Протоколом, работающим по принципу
гарантии доставки данных, обеспечивается нумерация передаваемых
данных, и получатель подтверждает факт получения им данных. Важно, что
при утере данных отправляется запрос на их повторную передачу. Такой
механизм используется, к примеру, протоколом Х.25.
Преимуществом виртуальной цепи является то, что сначала она
формируется (с помощью сигналов), и только после этого в
сформированную цепь помещаются данные. Обычно в заглавии каждого пакета
содержится не однозначный адрес получателя, а только
идентификация цепи.
В Интернете механизм виртуальных цепей не используется, так как
уничтожение узла в виртуальной цепи означает разрыв соединения, что
не подходит создателям семейства протоколов TCP/IP, которое было
первоначально создано для Министерства обороны США. По этой
причине IP-протокол не использует виртуальные цепи.
40

Введение
Каждая IP-дейтаграмма содержит IP-адрес получателя (то есть полную
маршрутную информацию), поэтому она доставляется отдельно. При
уничтожении узла сети может быть уничтожена только та
IP-дейтаграмма, которая как раз проходит через данный узел в момент его
уничтожения. Прочие IP-дейтаграммы направляются через другие узлы.
Рис. В. 18. IP-протокол не использует виртуальные цепи
Как видно из рис. В. 18, IP-дейтаграммы 1, 2 и 3 были вместе
отправлены из узла А на узел В, но маршрут дейтаграмм 1 и 3 был отличным от
маршрута дейтаграммы 2. Таким образом, до конечного узла D каждая
дейтаграмма доходит своим путем. IP-дейтаграммы могут прийти к пункту
назначения и в порядке, отличном от того, в каком они были
отправлены, то есть, например, в следующем порядке: 2,1 и 3.
Кроме IP-протокола, который не ориентирован на установку
соединения, в Интернете используется протокол более высокого уровня — TCP,
который устанавливает соединение, а также гарантирует доставку
данных. Если он установит, что данные были утеряны из-за уничтожения
какого-либо узла сети, и если в сети существует еще резервный
маршрут, то повторная передача данных будет автоматически осуществлена
по этому маршруту.
В целях объективности следует сказать несколько слов в защиту
протокола Х.25. Это протокол, описывающий только интерфейс между поль-
41

TCP/IP и DNS в теории и на практике. Полное руководство
зователем и сетью Х.25. Внутри сети Х.25 (в пространстве, не доступном
взгляду пользователя) данные могут передаваться так же, как и в
Интернете (то есть ни в коем случае не с помощью самого протокола Х.25).
В.5.2. Постоянные и коммутируемые виртуальные цепи
Различают следующие виды виртуальных цепей:
• Постоянные (PVCs, Permanent Virtual Circuits), то есть виртуальные
цепи, закрепленные администратором сети.
• Коммутируемые (SVCs, Switched Virtual Circuits) — виртуальные
цепи, динамически появляющиеся в случае необходимости. SVC
формируется с помощью так называемых сигнальных
протоколов, то есть протоколов, с которыми пользователь и сама сеть
могут поддерживать коммуникацию между собой. Сеть
информирует пользователя о различных исключительных состояниях,
посредством которых можно управлять сетью и осуществлять ее
мониторинг, а также формировать цепи. Итак, в SVC процесс
коммуникации состоит из двух шагов: создание виртуальной цепи
и использование ее самой для осуществления коммуникации.
PVC — это аналог постоянных линий связи, тогда как SVC — это аналог
коммутируемых линий связи в телефонной сети.
Примечание.
Протоколы, использующие виртуальные цепи, в английском языке
обозначаются термином Connection Oriented Network Services (CONS), а
протоколы, доставляющие свои пакеты без формирования виртуальных
цепей, по-английски называются Connection-Less Network Services (CLNS).
Иными словами, речь идет о сетевых службах, ориентированных и не
ориентированных на установку соединения.

Глава 1
МАРШРУТИЗАТОРЫ CISCO
И СЕТЕВАЯ БЕЗОПАСНОСТЬ -
КАК ЭТО ВЫГЛЯДИТ
НА ПРАКТИКЕ
МАРШРУТИЗАТОРЫ CISCO:
ВИД СПЕРЕДИ, СБОКУ, СВЕРХУ
И... ИЗНУТРИ
ИДЕНТИФИКАЦИЯ ИНТЕРФЕЙСА
КАБЕЛИ
ПАМЯТЬ МАРШРУТИЗАТОРА:
ТИПЫ, НАЗНАЧЕНИЕ, ОСОБЕННОСТИ
ДОСТУПА
КОНСОЛЬ
КОМАНДЫ
КОНФИГУРИРОВАНИЕ
МАРШРУТИЗАТОРА. КАК ЭТО
ДЕЛАЕТСЯ
ОТЛАДКА. МОНИТОРИНГ
ПРОИСХОДЯЩИХ СОБЫТИЙ
TCP/IP и DNS в теории и на практике. Полное руководство

1.1. Маршрутизаторы CISCO: вид спереди,
сбоку, сверху и... изнутри
Любому администратору очень важно знать основы работы с
маршрутизаторами CISCO, можно даже сказать, что любой администратор должен
знать, как работать с CISCO. И если у вас установлен не CISCO-марш-
рутизатор, вам все равно нужно знать язык конфигурации CISCO,
поскольку он используется многими другими маршрутизаторами и
фактически является показательным стандартом. В последующих главах этой
книги мы рассмотрим не только примеры конфигурирования
UNIX-подобных операционных систем и систем семейства Microsoft Windows, но
и конфигурационный язык CISCO.
Компания CISCO специализируется на активных сетевых устройствах:
от коммутаторов до брандмауэров (firewall). Данные устройства
обладают собственным конфигурационным языком. Мы сконцентрируем наше
внимание только на маршрутизаторах, синтаксис конфигурационного
языка которых и описан в данной главе.
CISCO-маршрутизаторы — это устройства, работающие под
управлением собственной операционной системы IOS. Фактически, настройка
маршрутизатора заключается в настройке его операционной системы
IOS.
Более подробно о синтаксисе любого из устройств CISCO можно
прочитать на сайте www .cisco. com, на котором вы найдете тысячи страниц
полной документации, описывающей аппаратные средства и IOS.
Существует много различных версий IOS, поддерживающих разное
количество сетевых протоколов. При этом чем больше поддерживается
протоколов, тем больше требуется памяти маршрутизатору и тем выше
будет его цена. Если вам нужны некоторые экзотические протоколы,

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
цена такого устройства будет значительно выше обычной — ведь вы
платите не только за дополнительную память, но и за новую версию IOS,
«понимающую» эти протоколы.
При покупке маршрутизатора нужно принять следующие решения:
1. Выбрать само устройство, при этом нужно обратить внимание на:
• наличие нужных сетевых интерфейсов (синхронные, асинхронные
интерфейсы, интерфейсы Ethernet), а также на их количество;
• производительность (быстродействие) устройства и объем
памяти;
• кабели, соответствующие выбранному устройству.
2. Выбрать версию IOS, поддерживающую требуемые протоколы.
Будем считать, что вы справились со своей задачей и купили
маршрутизатор CISCO; теперь рассмотрим работу с ним на примере
взаимодействия с маршрутизатором CISCO 1603.
Во-первых, независимо от того, какая у вас модель маршрутизатора,
обратите внимание на его заднюю часть, содержащую разъемы. Взглянув
на них, вы сразу определите, какие интерфейсы поддерживает
маршрутизатор.
Рис. 1.1. Маршрутизатор CISCO 1603: вид сзади (www. cisco. com)
На любом маршрутизаторе CISCO вы обнаружите следующие разъемы
(слева направо, не учитывая разъем блока питания):
• Разъем для соединения с LAN (локальной сетью). Ethernet-
разъемы могут быть трех типов: RJ-45 для 10Base-T (см. рис. 3.20
и 3.28), CANNON 15 для AUI (см. рис. 3.27) или BNC-коннек-
тор. Рассматриваемая модель 1603 содержит два разъема: RJ-45
45

TCP/IP и DNS в теории и на практике. Полное руководство
и CANNON-15, поэтому она может подключаться к сети с
использованием одного из двух этих разъемов.
• RJ-45 для ISDN (интерфейс S/T). Модель 1604 содержит
интерфейс U с устройством NT-1. Бытует мнение, что если вы
подключаете маршрутизатор к U-интерфейсу, то вы можете подключить
другие ISDN-устройства (например, ISDN-телефон).
• RJ-45 с поддержкой V.24 (RS232). Данный разъем используется
для подключения консоли, для нас он наиболее интересен.
• WAN-порт (для подключения к глобальной сети). Расположен
в верхнем правом углу. Данный порт можно встретить на любом
CISCO-маршрутизаторе. В нашем случае, к этому порту можно
подключать, как синхронные, так и асинхронные линии. WAN-
порт используется во всех протоколах для последовательных
линий (HDLC, PPP, Frame Relay и т. д.) скоростью до 2 Мб/с.
WAN-порт маршрутизаторов CISCO использует специфический
интерфейс — DB-60 (на физическом уровне). Этот факт нужно
учитывать при выборе кабеля. Например, если мы хотим для
связи с каким-то сетевым объектом использовать протокол V.35, нам
нужен специальный кабель с коннектором DB-60 с одной стороны
(со стороны маршрутизатора) и с коннектором V.35 — с другой.
Некоторые CISCO-маршрутизаторы могут содержать и следующие
разъемы:
• AUX (auxiliary — интерфейс для удаленного
администрирования). Это классический асинхронный порт, позволяющий
аппаратное управление потоком данных. К нему можно без проблем
подключить обычный модем.
• Интерфейсы для различных типов LAN. К этой группе
интерфейсов относятся интерфейсы для подключения к Fast Ethernet
и Gigabit Ethernet.
• Специальные WAN-интерфейсы (Wide Area Network) — для
протоколов, поддерживающих передачу данных со скоростью более
2 Мб/с.
Серверы доступа заслуживают отдельного разговора. Это специальные
маршрутизаторы, служащие для подключения большого числа линий.
Сервер доступа обычно является точкой доступа (access point) для кли-
46

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
ентов интернет-провайдера, которые используют dial-up-подключение
(обычное модемное соединение, или ISDN).
Сервер доступа содержит множество портов для подключения модемов
(получается модемный пул). Большие серверы доступа состоят из
группы модулей, содержащих определенное количество портов. Модули,
в свою очередь, содержат интегрированные модемы. Модемы
подключаются прямо к телефонной сети. Выходит, что к нашему серверу доступа
«идут» выделенные линии от самой АТС. Современные АТС являются
цифровыми, поэтому могут передавать до 30-ти вызовов одновременно
по одной линии Е1 (см. рис. 3.17). Конечно, когда сервер доступа
подключается к цифровой АТС, ему нужен специальный модуль для
разделения линии Е1 — ведь информация обо всех 30-ти вызовах «приходит»
по одному кабелю, и без специального модуля сервер доступа просто не
поймет, что происходит.
1.2. Идентификация интерфейса
Маршрутизаторы CISCO имеют свои обозначения для различных
типов интерфейсов: Ethernet — для интерфейса Ethernet, Serial — для
последовательного интерфейса. То же самое касается линий: Console
(или просто con) — для консоли (еще одно обозначение CTY), aux —
для асинхронного интерфейса, tty — для асинхронных линий и vty —
для сетевых терминалов (или, выражаясь языком UNIX,
псевдотерминалов), использующих telnet.
Поскольку у маршрутизатора может быть более одного интерфейса, для
идентификации интерфейса только имени недостаточно. Кроме имени
указывается еще и номер интерфейса, который определяется
аппаратной конфигурацией маршрутизатора.
Например, если у вас два последовательных интерфейса, они будут
называться Serial 0 и Serial 1. Какой из них будет номер 0, а
какой 1 — зависит от конфигурации маршрутизатора (информацию об
этом вы найдете в руководстве к маршрутизатору). Даже если у вас
всего один интерфейс, в его названии обязательно будет присутствовать
номер, например, con 0.
В случае, если у вас большой маршрутизатор, состоящий из нескольких
модулей (также называемых слотами), имя интерфейса будет состоять
47

TCP/IP и DNS в теории и на практике. Полное руководство
из его типа, номера модуля и номера интерфейса в модуле. Последние
два числа указываются в формате «номер модуля/номер порта».
Предположим, что в слоте 0 («Slot 0») у вас два Ethernet-порта, тогда их
имена будут следующими: Ethernet 0 / 0 и Ethernet 0/1.
С сетевыми терминалами (vty) дело обстоит слегка иначе.
Теоретически, используя протокол telnet, по сети может зарегистрироваться очень
много пользователей — их число не ограничено. Номера сетевым
терминалам будут присваиваться в порядке подключения — vty 0, vty l
и т. д. Маршрутизаторы CISCO позволяют сконфигурировать
несколько линий для подключения пользователей.
Количество линий vty задается при конфигурировании IOS.
Ограничение числа vty не влияет на количество пользователей, которые
подключаются по протоколу РРР.
1.3. Кабели
При покупке CISCO-маршрутизатора особое внимание нужно уделить
кабелям. Также стоит уточнить у продавца, сможете ли вы позже
заменить один тип кабеля на другой, если обнаружите, что первый вам не
подходит (или просто со временем вам понадобится другой тип кабеля).
С кабелями для локальных сетей, скорее всего, у вас проблем не будет.
Особый интерес представляют кабели WAN-порта и консоли.
WAN-порт (универсальный последовательный интерфейс) моего
маршрутизатора использует коннектор DB-60. Выбирая определенный
кабель, мы также выбираем и физический уровень, который будет
использоваться нашим маршрутизатором. Мне нужно использовать протокол
V.35, поэтому я приобрел кабель с коннектором DB-60 со стороны
маршрутизатора и с интерфейсом V.35 со стороны модема.
Интерфейс V.35 может быть DTE или DCE (см. рис. В.4). DTE —
обычно компьютер, терминал или маршрутизатор, a DCE — модем (см. рис.
3.2). Поскольку используется асинхронная связь, для синхронизации
сигнала нужно указать источник времени (синхронизирующая
информация будет находиться в самих сигналах данных).
Для соединения двух маршрутизаторов я использовал нуль-модем. Это
было достигнуто путем соединения двух маршрутизаторов с помощью
48

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
интерфейса V.35. Получится нуль-модем. На рис. 3.5 показано, как
создать модем, основанный на интерфейсе V.24 (RS232). Аналогично,
соединив передатчик с приемником (и соответственно, управляющий
сигнал), можно создать нуль-модем для протокола V.35.
Для соединения маршрутизаторов CISCO используется специальный
кабель — с одной стороны DTE, а с другой DCE. После соединения
маршрутизаторов нужно установить источник времени с помощью
команды clock.
1.4. Память маршрутизатора:
типы, назначение, особенности доступа
Маршрутизаторы CISCO имеют три типа памяти:
• RAM — обычно используется операционной системой
(операционная система загружается в RAM). Память RAM стирается при
выключении маршрутизатора или пропадании питания. Данный тип
памяти в командах обычно называется "system".
• FLASH — данный тип памяти не стирается при выключении
питания. В Flash-памяти хранится операционная система, которая
переносится в RAM при включении маршрутизатора. Маршрутизатор,
изображенный на рис. 1.1, оснащен Flash-памятью, содержащейся на
PCMCIA-карте, вставленной в слот в нижнем правом углу.
• NVRAM — перезаписываемая память небольшого размера, в которой
хранятся копии конфигураций операционной системы IOS. Данная
память не стирается при выключении питания.
После включения маршрутизатор загружает операционную систему
IOS из Flash-памяти. При загрузке система конфигурируется
командами, указанными в файле startup-conf ig, хранящемся в NVRAM.
Получить доступ к той или иной памяти очень просто. Помните, как
в DOS называются диски? А:, В:, С: и т. д., в IOS имя диска заменяется
названием файловой системы: flash:, nvram:, system: (для RAM). Для
работы с файлами в новых версиях IOS мы можем использовать
команды copy, cd, dir, pwd, delete и т. д.
Рассмотрим, каким образом можно использовать команду сору для
копирования файла конфигурации running-con fig из RAM в NVRAM
49

TCP/IP и DNS в теории и на практике. Полное руководство
в файл startup-conf ig (эта команда нужна для сохранения текущей
конфигурации):
copy system: running-config nvram:startup-config
Того же результата можно добиться, используя устаревшую команду
write memory.
Команда сору в качестве параметра может использовать URL.
Например, для загрузки новой версии операционной системы во flash можно
использовать команду:
copy ftp: flash:
Данная команда позволяет обновить операционную систему с FTP-cep-
вера (система попросит вас указать недостающую информацию,
которую вы не указали в URL, — имя сервера, путь и т. д.).
Устаревшие версии IOS не поддерживают FTP, они поддерживают
только протокол TFTP (Trivial FTP). Если мы «развернем» простейший
TFTP-сервер на нашем компьютере, мы можем сделать резервную
копию конфигурации, выполнив следующую команду:
copy nvram:startup-config tftp:
Простейшую версию TFTP-сервера вы сможете найти в Интернете.
1.5. Консоль
Консоль — это асинхронный интерфейс. Если подключить этот
интерфейс с помощью кабеля к СОМ-порту компьютера, компьютер станет
консолью, которую можно использовать для настройки
маршрутизатора.
Примечание.
Консоль, по сути, это тот же порт, только предназначенный для
локального управления маршрутизатором.
Маршрутизатор подключается кабелем (нуль-модем для интерфейса
V.24 (RS232)) с коннекторами RJ-45 с обеих сторон. Со стороны
маршрутизатора кабель подключается непосредственно к самому устройству,
а вот для подключения к компьютеру у вас должен быть специальный
50

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
переходник RG-45 — CANNON 9 (или CANNON 25), который
поставляется вместе с маршрутизатором.
Давайте запустим терминальное приложение (например, Hypertermi-
nal). Выберите СОМ-порт, к которому подключен кабель, и
установите параметры линии: скорость 9600 bps, биты данных 8, без четности
(no parity), 1 или 2 стоп-бита и аппаратный режим управления потоком
данных.
Рис. 1.2. Настройка приложения Hyperterminal
Приложение терминала, если установлены правильные параметры,
должно связаться с маршрутизатором. Проблема заключается в том, что
маршрутизатор запрашивает пароль, которого мы не знаем. Но всегда
есть выход из положения. Сейчас мы попытаемся «обойти» ввод
пароля. Описываемая ниже процедура называется восстановлением забыто-
51

TCP/IP и DNS в теории и на практике. Полное руководство
го пароля, но с успехом может использоваться и для «восстановления»
того пароля, который мы никогда не знали.
Итак, начинаем «восстанавливать» пароль. Выключите маршрутизатор
и сразу же включите его. В течение 60 секунд (то есть сразу же) нажмите
клавиши «Ctrl» + «Break». Вы увидите ROM-монитор (ROM Monitor,
ROMMON).
Теперь выполните следующие действия:
1. Введите о, нажмите «Enter» и запишите текущее значение
конфигурационного регистра (обычно 0x2101 или 0x2102)
>о
Configuration register = 0x2102 at last boot
Bit# Configuration register option settings:
15 Diagnostic mode disabled
2. Введите о/г 0x2142 и нажмите «Enter» для загрузки из Flash без
загрузки конфигурации.
3. Теперь введите i и нажмите «Enter» для перезагрузки системы.
4. После перезагрузки вам нужно ответить по на все вопросы
программы конфигурации или просто нажать «Ctrl» + «С».
5. Введите enable в командной строке маршрутизатора (>). Вы
перейдете в привилегированный режим. В этом режиме изменится
символ-приглашение — теперь это решетка (■#).
6. Введите команду configure memory или copy startup-config running-
config. Этой командой вы скопируете конфигурацию
маршрутизатора из NVRAM в оперативную память. Не нужно вводить команды
write memory или copy running startup-config.
7. Введите команду write terminal или show running-config. Вы
увидите конфигурацию маршрутизатора. Все интерфейсы
маршрутизатора в данный момент будут выключены (shutdown). Также вы
увидите незашифрованный пароль — в открытом виде.
8. Введите команду configure terminal и произведите необходимые
вам изменения. Приглашение командной строки теперь выводится
в форме hostname (conf ig) #.
52

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
9. Введите enable secret <password>. Этим вы установите новый
пароль.
10. Выполните команду no shutdown для каждого используемого вами
интерфейса. После того, как вы выйдете из режима конфигурации,
введите команду show ip interface brief — каждый нужный
интерфейс должен быть в состоянии «up».
И. Введите команду config-register 0x2102 (вместо 0x2102 нужно
указать записанное вами в самом начале значение). Данная команда
загрузит из Flash операционную систему Cisco IOS с конфигурацией,
записанной в NVRAM (при следующей перезагрузке, поэтому
нужно не забыть сохранить конфигурацию).
12. Нажмите «Ctrl» + «Z» для выхода из режима конфигурации. Теперь
командная строка примет вид hostname #.
13. Введите команду write memory или copy running-config startup-
config ДЛЯ СОХРАНЕНИЯ ТЕКУЩЕЙ КОНФИГУРАЦИИ.
14. Все, что вам осталось сделать — ввести команду Reload для
перезагрузки IOS.
При подключении терминала к новому маршрутизатору (не
сконфигурированному) вы сразу увидите конфигурационное меню, и вам ничего
не нужно будет вводить, а просто установить первоначальные
параметры, в том числе пароль. Более детально об этом вы сможете прочитать
в руководстве по вашему маршрутизатору.
1.6. Команды
1.6.1. Методика и синтаксис использования команд
Чтобы увидеть список команд и их краткое описание, введите ? (знак
вопроса). Если ввести ? в непривилегированном режиме, вы получите
следующий список команд:
Router>?
Exec commands:
access-enable Create a temporary Access-List entry
access-profile Apply user-profile to interface
clearReset functions
connect Open a terminal connection
53

TCP/IP и DNS в теории и на практике. Полное руководство
disable Turn off privileged commands
disconnect Disconnect an existing network connection
enable Turn on privileged commands
exit Exit from the EXEC
help Description of the interactive help system
lock Lock the terminal
login Log in as a particular user
logout Exit from the EXEC
—More—
Если вас интересует какая-то определенная команда, введите первые
буквы этой команды и знак вопроса, например:
Router>p?
*p=ping pad ping ppp
Если же вам нужно полное описание синтаксиса команды, введите имя
команды и знак вопроса, например:
Router>ping ?
WORD Ping destination address or hostname
ip IP echo
tag Tag encapsulated IP echo
Большинство команд, которые вы будете использовать, работает
только в привилегированном режиме (режиме администратора), который
можно включить с помощью команды enable. Система попросит вас
ввести пароль (если он установлен). Привилегированный режим
узнать очень просто: в приглашении командной строки вместо символа >
стоит символ #.
Router>enable
Password: (не отображается)
Router#
54

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
1.6.2. Непривилегированный режим (режим пользователя) —
стоит на страже правопорядка.
Команды доступные в этом режиме
Непривилегированный режим позволяет запускать команды, не
изменяющие конфигурацию маршрутизатора, то есть те, которые не могут
повлиять на его работу. Давайте рассмотрим несколько примеров таких
команд:
• Telnet, ping, traceroute — данные команды подобны всем нам
известным командам из операционных систем UNIX и Windows.
• Terminal — с помощью этой команды мы можем установить
различные параметры терминала. Помните, что параметры терминала
должны быть одинаковыми с двух сторон, то есть, если вы
устанавливаете на маршрутизаторе тип терминала vt 100, то в
терминальной программе вы также должны выбрать тип терминала vtlOO.
Тип терминала можно установить с помощью команды:
terminal terminal-type vtlOO
Как видно из самой команды, она устанавливает тип терминала
vtlOO (очень часто также используется тип ansi).
• РРР — используется пользователями, подключенными к
маршрутизатору через модем (то есть асинхронную линию) с использованием
протокола РРР.
• Show — данная команда позволяет получить различную
информацию, а также статистические данные. При этом в качестве параметра
команды указывается объект, о котором требуется подобную
информацию получить:
• show ip route — таблица маршрутизации;
• show ip arp — кэш ARP;
• show ip interface — информация об отдельных сетевых
интерфейсах;
• show terminal — показывает настройки терминала;
• show users — отображает информацию о зарегистрированных
пользователях;
• show version — текущая информация об аппаратном и
программном обеспечении.
55

TCP/IP и DNS в теории и на практике. Полное руководство
• Login, logout, exit — для регистрации на маршрутизаторе под
другим именем используется команда login. Для выхода используются
команды logout или exit.
• Enable, disable — команда enable позволяет зарегистрироваться в
режиме администратора (данная команда подобна команде su в Unix).
Команда disable возвращает вас обратно в пользовательский режим.
1.6.3. Привилегированный режим (режим администратора)
В режиме администратора вы можете использовать все
непривилегированные команды, а кроме них команды для работы с файлами и
файловой системой: cd, dir, delete, copy, erase (стирает файловую систему),
а также команды configure (конфигурация маршрутизатора) и debug
(список переданных пакетов).
Команда show в режиме администратора содержит дополнительные
параметры:
• show debugging — информация о настройках;
• show running-config — текущая конфигурация системы;
• show configuration — загрузочная конфигурация системы;
• show logging — события системы;
• show line — показывает информацию об отдельных линиях;
• show interface — показывает текущую информацию об интерфейсе,
который указан в качестве параметра, например, show interface
serial 0 показывает информацию о первом последовательном
порте.
1.7. Конфигурирование маршрутизатора.
Как это делается
Файл конфигурации
Как отмечалось ранее, маршрутизатор работает с двумя
конфигурациями:
56

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
• Текущая конфигурация — с этой конфигурацией в настоящий
момент работает IOS. Просмотреть конфигурацию можно с помощью
команды show running-config.
• Конфигурация в NVRAM — данная конфигурация также
называется загрузочной (start-up), она хранится в памяти NVRAM, которая
не стирается при выключении питания. Просмотреть эту
конфигурацию можно с помощью команды show configuration.
Предположим, вы изменили текущую конфигурацию и хотите ее
сохранить в NVRAM. Для этого можно использовать команду write memory,
которая доступна на любых версиях IOS. Как было показано выше,
загрузочная конфигурация может быть обновлена по протоколу FTP или
TFTP с помощью команды сору. Вы можете создать конфигурационный
файл на компьютере (например, в обычном текстовом редакторе) и
загрузить его в NVRAM.
Рассмотрим пример простейшего файла конфигурации:
version 12.0
hostname Router
i
enable password tyurRjX3
i
interface EthernetO
ip address 195.0.1.195 255.255.255.224
i
interface SerialO
no ip address
shutdown
i
line con 0
transport input none
line vty 0
password reT6Jdk0u
login
i
end
Файл конфигурации состоит из различных секций. Секции всегда
начинаются командой с первого столбца. В нашем файле есть следующие
секции:
57

TCP/IP и DNS в теории и на практике. Полное руководство
• Version — указывает версию IOS.
• Hostname — определяет имя маршрутизатора.
• Секция, начинающаяся словами enable password, указывает
пароль для привилегированного режима.
• Секция interface EthernetO задает параметры для интерфейса
Ethernet 0: IP-адрес и маску сети, которые указываются с помощью
параметра ip address.
• Секция interface SerialO определяет конфигурацию интерфейса
Serial 0. Обратите внимание: конфигурация этого интерфейса должна
заканчиваться параметром shutdown, который означает, что
интерфейс выключен.
• Секция line con 0 задает параметры консоли. Если параметр login не
указан здесь, вход будет выполнен в непривилегированном режиме
без использования пароля.
• Секция line vty 0 определяет параметры первого псевдотерминала.
В данном случае даже непривилегированный режим требует
указания параметра login. Пароль указывается с помощью параметра
password.
• Последняя секция end «закрывает» файл конфигурации.
Давайте рассмотрим интерактивную конфигурацию. Обычно работа
любого администратора в привилегированном режиме начинается
командой:
configure terminal
Сразу нужно осознать, что при работе с IOS у нас будет не
полноэкранный текстовый редактор. Вместо него у нас будет простенький
строчный редактор. После ввода команды конфигурации нам нужно
ввести названия секции и параметры конфигурации: по одной секции/
параметру в каждой строке. Для завершения редактирования нужно
нажать «Ctrl» + «Z».
Предположим, что нам нужно изменить нашу конфигурацию, например,
изменить маску сетевого интерфейса Ethernet 0. Для этого выполним
команды:
Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
58

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
Router(config)#interfасе Ethernet 0
Router(config-if)#no ip address 195.0.1.195 255.255.255.224
Router(config-if)#ip address 195.0.1.196 255.255.255.0
Router(config-if)#AZ
Router# write memory
Building configuration...
[OK]
В приведенном примере сначала мы определяем секцию, которую
будем редактировать — interface Ethernet 0. Затем с помощью команды
по отменяем исходные значения IP-адреса и маски, определенные
параметром ip address. После этого мы вводим новые значения IP-адреса
и маски с помощью того же параметра ip address. По окончании
редактирования нажимаем «Ctrl» + «Z». Затем вводим команду write memory,
чтобы сохранить текущую конфигурацию в NVRAM.
Если бы нам нужно было запустить интерфейс Serial 0 (в нашем
примере он выключен, поскольку указан параметр shutdown), потребовалось
бы ввести имя секции interface Serial 0 и отменить параметр shutdown
командой:
no shutdown
Процесс конфигурации секции заканчивается командой exit. Если мы
хотим выйти из программы конфигурирования, нужно нажать «Ctrl» + «Z».
Защита конфигурационного файла CISCO
Наверное, вы удивлены, что пароль в файле конфигурации хранится
в незашифрованном виде. Существует второй способ установки
пароля, при котором пароль сохраняется в зашифрованном виде, а процесс
аутентификации также возможен с использованием протоколов Radius
и TACACS+.
Если мы не хотим использовать незашифрованный пароль, мы можем
установить его уже в зашифрованном виде. Зашифрованную версию
пароля можно взять, например, из файла /etc/passwd ОС UNIX. Для
установки зашифрованого пароля выполните команды:
Router#configure terminal
Router (conf ig) #enable pasword 7 зашифрованный__пароль
59

TCP/IP и DNS в теории и на практике. Полное руководство
Если вы хотите, чтобы система сама зашифровала пароль, тогда
выполните другую команду:
Router(config)tenable secret 5 пароль
возможность настройки маршрутизатора
через Web и безопасность
Если в конфигурационный файл добавить следующую команду:
ip http server
мы запустим на маршрутизаторе web-сервер, который можно
использовать для конфигурирования нашего маршрутизатора (см. рис. 1.3).
Запустите на своем компьютере браузер и введите IP-адрес
маршрутизатора в качестве URL.
Рис. 1.3. Web-конфигурирование
Маршрутизатор попросит вас ввести имя пользователя и пароль. Если
ваш маршрутизатор не содержит списка пользователей, просто не
заполняйте поле User name, а в качестве пароля укажите пароль для доступа
60

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
к привилегированному режиму. Теперь вы можете управлять своим
маршрутизатором через браузер.
Данный способ настройки обладает определенными достоинствами
(возможностью удаленной настройки), но сопряжен с неизбежным
понижением уровня безопасности, так как открывается еще один канал
воздействия на маршрутизатор, а универсальной защиты, как
говорится, нет.
Программа ConfigMaker
Еще один способ настройки маршрутизатора — это использование
программы ConfigMaker, которую можно загрузить по следующему адресу
http://www.cisco.com/go/configmaker.
Программа обладает понятным, дружественным интерфейсом (см. рис. 1.4).
С помощью функции Detect, программа определяет конфигурацию
отдельных маршрутизаторов. Используя инструменты в левой части окна,
вы сможете разработать нужную вам схему сети.
Программа попросит вас ввести новые параметры маршрутизаторов.
После этого она создаст конфигурационные файлы и отправит их
обратно в маршрутизаторы — для этого используется функция Deliver.
Программа позволяет просмотреть конфигурации в графическом виде
до ее отправки на маршрутизатор: она строит графическую диаграмму
сети, просмотрев которую, вы можете сохранить конфигурацию
маршрутизаторов.
Рис 1.4. Программа ConfigMaker
61

TCP/IP и DNS в теории и на практике. Полное руководство
Программу рекомендуется использовать начинающим
администраторам CISCO: в этом случае вероятность ошибочной конфигурации резко
снижается.
1.8. Отладка.
Мониторинг происходящих событий
Цель отладки состоит в регистрации различных событий. Нас
интересуют события двух типов:
• произошедшие во время работы системы, например, в процессе
изменения конфигурации интерфейсов, их включения («Up») и
выключения («Down»);
• определенные администратором, задающим «ловушку» для события
(например, «захват» тех или иных пакетов для их анализа).
Прежде всего мы должны указать файл, в который будет записываться
журнал событий, что можно сделать с помощью команды logging
конфигурационного режима:
Router# configure terminal
Router(config)# logging console 7
В данном случае журнал будет выводиться на консоль, параметр 7
задает наиболее детальный вывод событий (0 — наименее детальный).
Для задания «ловушек» мы должны использовать другую команду
(которая очень важна, особенно при записи событий по сети с
использованием протокола SYSLOG):
Router(config)# logging trap 7
Обратите внимание, что данная команда будет записывать события не
на консоль, а на терминал, поэтому мы должны включить вывод
событий на терминал:
Router# terminal monitor
Во время реальной работы маршрутизатора (а не простого
тестирования) на терминал будет выводиться огромное количество записей — за
62

Глава 1. Маршрутизаторы CISCO и сетевая безопасность...
всеми не усмотришь, поэтому рекомендуется отправлять протокол
событий на сервер SYSLOG (демон syslogd есть в любой версии UNIX).
Чтобы перенаправить протокол событий на сервер SYSLOG,
используется следующая команда:
Router(config)#logging IP_aMpec_cepBepa_SYSLOG
До этого SYSLOG-сервер должен быть запущен. Настройка
UNIX-версии демона syslogd — довольно сложная задача, поэтому я рекомендую
вам использовать простой Syslog-демон, работающий под управлением
Windows — Kiwi's Syslog Daemon.
Последнее, что нам осталось сделать, — это установить «ловушки». Для
этого используется команда debug. В качестве параметров данной
команды укажите интересующие вас протоколы, например, ip icmp:
Router# debug ip icmp
После этого будет записан протокол ICMP-событий
(отправка-получение ICMP-пакетов).
В журнале вы не найдете детальной информации о содержимом
пакета, поэтому не надейтесь таким образом перехватить пароли или другую
важную информацию. Однако с помощью журнала вы сможете легко
найти ошибки в вашей конфигурации.

Глава 2
СЕТЕВЫЕ МОНИТОРЫ.
АНАЛИЗ СТАБИЛЬНОСТИ
И БЕЗОПАСНОСТИ СЕТИ.
ПЕРЕХВАТ ДАННЫХ
СЕТЕВЫЕ МОНИТОРЫ — ОРУЖИЕ
АДМИНИСТРАТОРА ИЛИ ВЗЛОМЩИКА?
ПАКЕТНЫЕДРАЙВЕРЫ, КОММУТАТОРЫ
И КОНЦЕНТРАТОРЫ.
ВОПРОСЫ БЕЗОПАСНОСТИ ПЕРЕДАЧИ
ДАННЫХ ПО СЕТИ
MS NETWORK MONITOR —
ПРОГРАММА ПЕРЕХВАТА ДЛЯ
СЕРВЕРНЫХ ОПЕРАЦИОННЫХ СИСТЕМ
ПРОГРАММА ETHEREAL —
ПЕРЕХВАТ ДАННЫХ
ПОД ПОЛЬЗОВАТЕЛЬСКИМИ
ОПЕРАЦИОННЫМИ СИСТЕМАМИ
(WINDOWS 2000/XP)
TCP/IP и DNS в теории и на практике. Полное руководство

2.1. Сетевые мониторы —
оружие администратора или взломщика?
Сетевые мониторы используются для анализа передаваемых по сети
данных. Мониторинг — это процесс фиксирования сетевых кадров и
сохранения их в памяти. С помощью мониторинга вы также можете
просмотреть содержимое отдельных кадров.
Сетевые мониторы используются сетевыми администраторами для
поиска ошибок в конфигурации сети, а также для вычисления нагрузки
на сеть. Также сетевые мониторы незаменимы для программистов,
разрабатывающих сетевые приложения. Предположим, вы разрабатываете
сетевое приложение типа клиент/сервер. Вы запускаете его, но ничего
не происходит: клиент даже не может подключиться к серверу.
Проблема тут может быть либо в клиенте, либо в сервере. Для
определения «объекта» ошибки нам нужен сетевой монитор. Захватывая
передаваемые клиентом кадры, можно проверить их содержимое: возможно,
клиент не так их формирует, например, указывает неправильный номер
порта. А возможно, он вообще ничего не отправляет. Если же клиент
правильно формирует и отправляет кадры, тогда причину нужно искать
в сервере — почему тот не реагирует.
В этой главе будут рассмотрены две наиболее часто используемые для
сетевого мониторинга программы: Network Monitor и Ethereal. Обе они
обладают удобным графическим интерфейсом. Мы будем использовать
эти программы для демонстрации разных сетевых протоколов. В UNIX
есть свой «штатный» сетевой монитор — программа tcpdump, но в
отличие от упомянутых выше программ, tcpdump — это «текстовая»
программа, у нее нет графического интерфейса, поэтому использовать ее не
3 Зак. 518

TCP/IP и DNS в теории и на практике. Полное руководство
так удобно. Изначально программа tcpdump была разработана для
использования в сценариях оболочки.
Кроме программных сетевых мониторов существуют устройства для
сетевого мониторинга. Какие же преимущества у аппаратного сетевого
монитора? Устройства данного типа особенно важны для обслуживающего
персонала сети.
Программные мониторы отображают только неповрежденные кадры.
А что если неисправная сетевая плата искажает отправляемые кадры?
Программные мониторы не позволяют выявить поврежденные кадры и,
тем более, источник этих кадров в сети. Кроме того, программные
мониторы не могут работать с кадрами FDDI (Fiber Distributed Data
Interface).
Наиболее важная проблема использования сетевых мониторов — это
проблема безопасности. Используя простейший программный сетевой
монитор, злоумышленник может перехватить данные, отправляемые
другими пользователями, в том числе и пароли, передаваемые по
протоколам telnet, FTP, HTTP (Web).
В этой книге будет продемонстрирован перехват пароля с помощью
сетевого монитора. Возможно, это заставит вас перейти на более
совершенную схему аутентификации, не использующую для авторизации
имя пользователя и пароль.
2.2. Пакетные драйверы, коммутаторы
и концентраторы. Вопросы безопасности
передачи данных по сети
Чтобы следить за входящими и исходящими пакетами, нужна
специальная программа — мост между сетевым интерфейсом и операционной
системой, позволяющий проследить проходящие пакеты и/или передавать
их другим программам для протоколирования или отображения.
Данная программа называется пакетным драйвером, или пакетным
фильтром. В Microsoft Windows NT (Windows 2000, XP) пакетный драйвер
называется Network Monitor Agent. Программа, отображающая и
протоколирующая захваченные пакетным драйвером кадры, называется
Network Monitor for Windows. B UNIX для этой цели, как уже отмечалось,
используется программа tcpdump.
66

Глава 2. Сетевые мониторы...
Сетевые карты, подключенные к локальной сети, «прослушивают»
трафик сети, то есть читают все передаваемые по сети кадры. В каждом
кадре указывается адрес источника и адрес назначения. Если адрес
назначения совпадает с адресом сетевого интерфейса, кадр будет принят. Но
чтобы прочитать адрес назначения, нужно принять кадр, и если мы
прочитали адрес, значит, кадр уже принят. В действительности пакетный
драйвер должен получать только пакеты с адресом, предназначенные
только для того узла, на котором запущен этот пакетный драйвер.
Если же мы хотим получить весь трафик нашего сегмента локальной
сети, мы должны переключить сетевую плату в разнородный режим.
В разнородном режиме мы сможем получать все пакеты, даже не
предназначенные для нашего узла. Переключить сетевую плату в этот режим
можно с помощью программы Network Monitor.
Если сетевая плата не в разнородном режиме, то мы сможем увидеть
только пакеты, которые отправляются нашим компьютером, и пакеты,
предназначенные для нашего компьютера, а также широковещательные
пакеты (broadcast). Подробнее о широковещательных пакетах мы
поговорим в разделе 5.7.
При захвате пакетов всей сети надо иметь в виду, что пакеты передаются
только в рамках сегмента локальной сети, поэтому перехватить можно
пакеты, передаваемые компьютерами, находящимися в одном с вами
сегменте.
Еще одна проблема, с которой мы столкнемся при захвате пакетов,
заключается в использовании коммутаторов (switches) вместо
концентраторов (hub). Последние, получив пакет от компьютера А,
предназначенный компьютеру Б, рассылают этот пакет на все подключенные
порты — всем компьютерам: пусть они сами разбираются с пакетом.
Это объясняется тем, что концентраторы «не знают», какой компьютер
подключен к каждому порту. А коммутаторы, в отличие от хабов, имеют
точную информацию по этому вопросу. Таким образом, получив пакет
от компьютера А, который адресован компьютеру Б, они передают его
только на порт, к которому подключен компьютер Б. Проблема именно
в этом: ведь если наша сеть построена на коммутаторах, мы не сможем
перехватывать пакеты, предназначенные другим компьютерам.
Из данной ситуации есть выход. Например, нам нужно перехватить
трафик какого-то сервера нашей сети. Для этого достаточно простейшего
3-портового концентратора. Один порт концентратора будет подключен
67

TCP/IP и DNS в теории и на практике. Полное руководство
к коммутатору, то есть повторитель (концентратор) будет подключен
к тому порту коммутатора, к которому обычно подключается сервер. Ко
второму порту концентратора будет подключен сервер, трафик которого
нужно перехватить, а к третьему — наш компьютер, на котором запущен
сетевой монитор.
Если будете использовать программу Network Monitor от Microsoft, не
забудьте добавить в конфигурацию своей системы Драйвер сетевого
монитора (Network Monitor Agent).
Рис. 2.1. Добавление драйвера сетевого монитора
В UNIX-подобных операционных системах пакетный драйвер
обычно уже встроен в ядро операционной системы. Если у вас пакетный
фильтр не встроен в ядро, то при компилировании ядра выберите опцию
PACKETFILTER (или подобную ей). В UNIX True64 команда pfconfig
используется для переключения отдельных сетевых интерфейсов в
разнородный режим, а команда pfstat позволяет проверить конфигурацию
отдельного интерфейса.
68

Глава 2. Сетевые мониторы...
2.3. MS Network Monitor — программа перехвата
для серверных операционных систем
MS Network Monitor поставляется вместе с некоторыми продуктами от
Microsoft (например, SMS Server). Во время установки программы
нужно внимательно читать сообщения процесса установки. Где-то в
середине установки программа вас спросит, устанавливать ли модуль Network
Monitor Agent (см. рис. 2.1) Обязательно согласитесь, иначе после
установки программа работать не будет, и ее нужно будет переустанавливать.
MS Network Monitor работает под управлением операционной системы
Windows 2000 Server и более поздних версий. Windows 2000 Professional
ее не поддерживает. Если вам нужен сетевой монитор под Windows 2000
Pro, используйте программу Ethereal.
Network Monitor отлично отображает кадры — эта программа разделяет
не только заголовок и данные, но и отдельные элементы в заголовках
сетевого протокола.
2.3.1. Перехват кадров с данными
После запуска программы вы увидите окно, отображенное на рис. 2.2.
Внутри основного окна должно быть дочернее окно Capture Window
(сейчас оно развернуто). Если окно не открылось, следовательно, Network
Monitor или Network Monitor Agent установлен некорректно.
Первым делом выберите сетевой интерфейс, который вы будете
использовать для захвата кадров. Используйте команду меню Capturing —►
Networks (см. рис. 2.3). Обратите внимание на одну интересную деталь.
В окне на рис. 2.3 мы видим, что к компьютеру подключены две сетевые
платы Ethernet, а на самом деле у нас только одна сетевая плата.
Первый интерфейс — это настоящая сетевая плата. А второй
интерфейс используется для dial-up-соединения и не является физическим
сетевым адаптером. Узнать такой интерфейс очень просто: в окне Select
a network в поле Dial-up Connection этот интерфейс обозначен TRUE,
а обычная сетевая плата — FALSE.
Причина отображения в этом списке не-Ethernet адаптера заключается
в архитектуре самой Windows 2000. Уровень NDIS расположен «над»
платами сетевых интерфейсов, что гарантирует стандартный способ
связи между операционной системой и сетевыми интерфейсами. Драй-
69

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 2.2. Программа Network Monitor
Рис. 2.3. Выбор сетевого интерфейса для захвата кадров
вер NDISWAN (Ndiswan. sys) обрабатывает последовательные
порты, преобразуя коммуникационный формат последовательного порта
в Ethernet-формат (то есть в формат, поддерживаемый уровнем NDIS).
На практике это дает вам два положительных результата:
70

Глава 2. Сетевые мониторы...
• Вы можете захватывать кадры, передающиеся по последовательной
линии (модему); для этого достаточно выбрать интерфейс, для
которого указано Dial-up: Connection TRUE.
• При рассмотрении захваченных по последовательной линии кадров
(обычно это будут кадры протокола РРР) вы увидите, что «внутри»
этих кадров будут специальные адреса связи:
• Для исходящего кадра поля send и receive будут содержать
строку SEND.
• Для входящего кадра эти поля будут содержать строку RECV.
Это не относится к протоколу РРР over Ethernet (PPPoE), который
поддерживается Windows XP.
Начните захват кадров, нажав кнопку Start Capturing или выбрав
команду меню Capturing -* Start (клавиша «F10»). Как только начнется
захват, вы увидите окно, изображенное на рис. 2.4. Оно состоит из
нескольких маленьких окон.
В верхнем левом углу вы увидите окно, содержащее графики:
• % of Network Utilization — загрузка сетевых интерфейсов, которые
используются для захвата кадров (это не общая загрузка сети, а
только загрузка выбранных интерфейсов).
• Frames Per Second — скорость передачи данных, количество кадров
в секунду.
• Bytes Per Second — количество байтов, переданных за одну секунду
• Multicast Per Second — количество групповых кадров (которые
передаются группе компьютеров) в секунду.
Окно с общей статистикой находится в верхнем правом углу.
Статистика ведется с момента начала захвата. Окно статистики состоит из
четырех областей:
• Network Statistics — общее число кадров, переданных через сегмент
локальной сети; можно посмотреть, сколько из них было
широковещательными (broadcast), сколько байтов было передано (bytes),
а также отображается ли статус сети (network status).
• Captured Statistics — предоставляет статистику только по
захваченным кадрам (а не по всем кадрам, переданным через сегмент).
Данные в этой области могут отличаться от области Network Statistics,
71

TCP/IP и DNS в теории и на практике. Полное руководство
Начать Остановить
захват захват
Пауза/ Стоп и
продолжить просмотр
Просмотреть
захваченные данные
i
/
Общая статистика
I
Графики

Относительная
статистика
Статистика
станции
Рис. 2.4. Захват кадров
поскольку вы можете установить фильтр на захват кадров, то есть
захватывать не все кадры, а только определенные, например, только
ICMP-кадры. Установить фильтр можно с помощью команды меню
Capturing —► Filter («F8»).
• Per Second Statistics — посекундная статистика,
среднестатистические данные за одну секунду.
• Network Card Statistics — показывает загрузку сетевой платы.
Окно статистики предоставляет вам статистические данные отдельных
сессий. Сессия — это интервал, на протяжении которого две станции
обмениваются данными. Не забывайте: в сети Ethernet только две станции
могут одновременно обмениваться данными. Числовые значения
кадров — это количество кадров, переданное от одной станции к другой.
В дополнение к захвату кадров с помощью команды меню Capturing —►
Activation вы можете установить действие, которое будет выполнено
72

Глава 2. Сетевые мониторы...
при получении определенного кадра, например, кадра, содержащего
определенную строку.
2.3.2. Просмотр захваченных кадров
Когда вы нажмете кнопку Stop and View (Стоп и просмотр), вы сможете
просмотреть захваченные кадры (см. рис. 2.5). Имейте в виду, что, нажав
эту кнопку, вы останавливаете захват кадров.
Рис. 2.5. Просмотр захваченных кадров
Чтобы просмотреть содержимое любого кадра, щелкните по нему
кнопкой мыши (см. рис. 2.6).
Рассмотрим окно на рис. 2.6 более подробно. В верхней части окна
отображаются захваченные кадры. В середине окна предоставляется
информация о захваченных кадрах, а в нижней отображается содержимое
кадра в шестнадцатеричном и символьном виде.
73

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 2.6. Подробная информация о кадре
Наиболее интересен заголовок кадра, он показывается в средней части
окна. Здесь предоставляется вся информация: от транспортного до
прикладного уровня. Заголовки отдельных уровней сгруппированы. Для
раскрытия группы щелкните по знаку «+» (плюс) возле имени группы,
а для ее сворачивания — по знаку «-» (минус). Заголовки всех
отдельных протоколов будут описаны в этой книге чуть позже, поэтому сейчас
не будем на них останавливаться.
Отдельные кадры даже можно распечатать с помощью команды меню
File —* Print. Если распечатать кадр, изображенный на рис. 2.6, мы увидим:
Network Monitoring Trace Thu 03/28/02 11:12:04
Frame Time Src MAC Addr Dst MAC Addr Protocol Description Src Other АоУг
259.585680 2052 4543 5605 2052 4543 5605 LCP Config Req Packet, Ident = 0x00
+ Frame: Base frame properties
PPP: Unknown Frame (0x0)
PPP: Destination Address = RECV_
PPP: Source Address = RECV_
PPP: Protocol = Link Control Protocol
LCP: Config Req Packet, Ident = 0x00, Length = 25
74

Глава 2. Сетевые мониторы...
LCP: Code = Configuration Request
LCP: Identifier = 0 (0x0)
LCP: Length = 25 (0x19)
LCP: Options: ASYNC.MAP:00 00 00 00-AUTH:CHAP-MAGIC#:OxlOCO-
PROT.COMP-ADR/CF.COMP-
+ LCP: ASYNC.MAP:00 00 00 00
+ LCP: AUTH:CHAP
+ LCP: MAGIC#:0xl0C0
+ LCP: PROT.COMP
+ LCP: ADR/CF.COMP
00000: 20 52 45 43 56 05 20 52 45 43 56 05 CO 21 01 00 REEV. RECV.A!..
00010: 00 19 02 06 00 00 00 00 03 05 C2 23 80 05 06 00 ВГ...
00020: 00 10 CO 07 02 08 02 ..A
2.3.3. Фильтр захваченных кадров
Наиболее сложная задача при работе с сетевыми мониторами
заключается в поиске нужного кадра среди остальных. Ведь кадров не 10 и даже
не 100 — по сети передаются тысячи различных кадров, поэтому найти
нужный — это все равно что разыскать иголку в стоге сена. Чтобы
облегчить задачу поиска этой самой иголки, в любом сетевом мониторе есть
фильтры, позволяющие отсеять ненужные кадры. И в самом деле, если
нам нужны только кадры протокола HTTP, зачем нам просматривать все
остальные?
Сразу нужно сказать: в программе Network Monitor есть два типа
фильтров. Первый фильтр — это фильтр захвата кадров: вы указываете
условие на захват кадров, и все кадры, не соответствующие этому условию,
просто не будут захватываться. Второй тип фильтра — это фильтр
отображения кадров: вы указываете условие, и все кадры, не
соответствующие этому условию, не будут показаны, но они будут в памяти и при
желании их можно будет просмотреть, так как при этом типе фильтра
захватываются все кадры.
Для вызова фильтра захвата кадров используется команда меню
Capturing -> Filter («F8»). Для вызова фильтра отображения кадров
предназначена команда Display -> Filter.
В окне фильтра вы должны указать условие отбора кадров, которое
может состоять из:
• адреса (IP-адреса, поскольку мы используем протокол IP);
• протокола (например, IP, ICMP, HTTP и т. д.);
75

TCP/IP и DNS в теории и на практике. Полное руководство
• значения элемента протокола, например, номера порта отправителя
(TCP sender port) и т. п.
2.4. Программа Ethereal — перехват данных
под пользовательскими операционными
системами (Windows 2000/XP)
Программа Ethereal — это альтернативный сетевой монитор, который
можно использовать вместо Network Monitor. Скачать ее можно с сайта
www.ethereal.com.
Чем же хороша эта программа? Как уже было отмечено ранее,
программу Network Monitor можно использовать только на серверной версии
Windows, а если у нас Windows 2000 Professional или Windows XP, нам
придется использовать Ethereal (или другую программу), поскольку
Network Monitor под управлением указанных операционных систем
работать не будет. И еще: дистрибутив содержит несколько
вспомогательных утилит, в том числе и текстовую версию, ориентированную на
использование в командной строке программы Ethereal.
Для начала нужно установить пакетный драйвер. Как уже отмечалось,
если вы хотите запустить Ethereal под Windows (имеется в виду 9х), вам
нужен пакетный драйвер WinPcapp, который можно загрузить на сайте
http: //netgroup-serv.polito. it. Кстати, если у вас Windows XP,
лучше установите последнюю версию WinPcapp вместо родного
пакетного драйвера (фильтра).
После установки пакетного фильтра можно устанавливать и
настраивать программу Ethereal. После запуска программы вы увидите окно,
изображенное на рис. 2.7. Как видите, оно очень похоже на окно программы
Network Monitor (рис. 2.6). Для захвата кадров выберите команду меню
Capture -* Start. После этого вам нужно будет указать параметры
захвата кадров. Например, в поле Interface можно указать интерфейс,
который будет использоваться для захвата кадров. Для начала захвата
нажмите ОК. После завершения захвата кадров вы сможете просмотреть
захваченные кадры. Окно просмотра кадра подобно аналогичному окну
программы Network Monitor.
Программа Ethereal «умеет» открывать файлы с сохраненными
кадрами, которые генерируются другими сетевыми мониторами, в том числе
и Network Monitor.
76

Глава 2. Сетевые мониторы...
Рис. 2.7. Программа Ethereal
Ethereal интересна еще и тем, что она содержит много интересных
инструментов, например, команду Follow TCP Stream (меню Tools).
Данная команда позволяет проследить выбранное ТСР-соединение
(просмотреть его содержимое) в символьном (ASCII) или шестнадцате-
ричном виде. На рис. 2.8 изображен пример ТСР-соединения, а именно
FTP-соединения к серверу ftp. ripe. net. Для того чтобы проследить
соединение, нужно найти один из пакетов этого соединения, выделить
его и выполнить команду Tools —►Follow TCP Stream.
77

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 2.8. Пример ТСР-соединения
Посмотрите внимательнее на рисунок: стрелки показывают передачу
имени пользователя и пароля. Как видите, перехватить по сети любой
пароль особого труда не составляет.

Глава 3 ФИЗИЧЕСКИЙ УРОВЕНЬ -
КАНАЛ ПЕРЕДАЧИ ДАННЫХ,
БЕЗОПАСНОСТЬ, СТАНДАРТЫ
ПОСЛЕДОВАТЕЛЬНЫЕ ЛИНИИ
МОДЕМЫ. АНАЛОГОВЫЕ ЛИНИИ
ЦИФРОВЫЕЛИНИИ
ЛОКАЛЬНЫЕ СЕТИ
(LAN, LOCAL AREA NETWORK)
БЕСПРОВОДНЫЕ ЛИНИИ GSM
TCP/IP и DNS в теории и на практике. Полное руководство

Протоколы физического уровня для большинства пользователей —
«скрытые протоколы, описывающие и интерпретирующие сигналы на
разъемах сетевого кабеля, подключенного к сетевому интерфейсу
компьютера». Обычные пользователи могут даже и не подозревать об их
существовании, так как это дело технического персонала,
обслуживающего сеть.
Физический уровень отвечает за передачу битов по физическим каналам
связи: витой паре, коаксиальному кабелю и т. д. На физическом уровне
определены характеристики электрических сигналов, а также
назначение каждого разъема и каждого контакта в разъеме.
Как мы знаем, существует два основных типа сети: локальная (Local
Area Network, LAN) и глобальная (Wide Area Network, WAN). Для
каждого типа определены свои протоколы физического уровня. В последнее
время довольно популярна технология ATM, стирающая различия
между глобальной и локальной сетями.
Глобальные сети (WAN)
Глобальные сети покрывают большие территории, соединяют целые
континенты. Именно поэтому можно, находясь в любой точке нашей
планеты, подключиться к русскому серверу и отправить на
американский сервер письмо, которое будет доставлено получателю всего за пару
минут.
Скорости доступа к глобальной сети различны. Кто-то (например,
домашний пользователь) подключен к Интернету с помощью обычного
модема, и поэтому у него скорость приема/передачи данных исчисляется
в Кбит/с. А сервер какой-нибудь организации подключен к провайдеру
с помощью другой технологии, и поэтому скорость его доступа к Интер-

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
нету может исчисляться сотнями Кбит/с или даже Гбит/с (правда,
единицами, а не сотнями).
Скорость передачи по интерконтинентальным линиям достигает
десятков Гбит/с.
Локальные сети (LAN)
Локальные сети покрывают относительно небольшие территории,
например, соединяют компьютеры одного-двух зданий. Обычно для
построения локальных сетей используются технологии Ethernet или
Fast Ethernet, пиковая скорость передачи по которым составляет 10
и 100 Мбит/с соответственно. Так называемые расширенные
локальные сети могут соединять несколько обычных локальных сетей.
Соединение сетей производится с помощью коммутаторов, способных
конвертировать кадры одного протокола (который используется в
одной сети) в кадры другого протокола (который понятен компьютерам
другой сети). Таким образом достигается совместимость при
соединении сетей различных типов.
Для соединения локальных и глобальных сетей используются
маршрутизаторы. Маршрутизатор — это устройство, передающее
IP-дейтаграммы из локального сетевого интерфейса на глобальный и наоборот.
Сегодня скорость передачи данных по локальной сети достигает 10 Гбит/с
(минимальная —10 Мбит/с).
3.1. Последовательные линии
Практически на каждом компьютере есть два последовательных
интерфейса — СОМ1 и COM2. Первоначально порт СОМ1 предназначался
для подключения мыши, а COM2 — для модема. Если для подключения
мыши используется интерфейс PS/2, то не имеет значения, к какому
порту вы подключите модем — к СОМ1 или к COM2.
Сигналы последовательного интерфейса соответствуют стандарту ITU
V.24 (RS-232) — это последовательный асинхронный интерфейс
передачи данных.
Скорость передачи данных по последовательному интерфейсу не очень
велика: на наших телефонных линиях максимальное ее значение не
превышает 56 Кбит/с, а обычное — и того меньше.
81

TCP/IP и DNS в теории и на практике. Полное руководство
Последовательная и параллельная передача данных
При последовательной передаче данных от отправителя к получателю
используется только пара проводов (или один провод и «земля» для
асинхронных интерфейсов), поэтому отдельные биты символа (байта)
передаются друг за другом, то есть последовательно.
Для параллельной передачи данных используется восемь (или кратное
восьми количество) проводов, то есть все биты одного байта передаются
одновременно — параллельно. Обычно параллельный интерфейс
служит для подключения принтера, но существуют также и
«параллельные» модемы.
Симметрический и асимметрический сигнал
Последовательные интерфейсы используют минимум два сигнала:
прием данных и отправка данных. Если для передачи каждого сигнала
служат два провода, то такой сигнал называется симметрическим, или
дифференциальным. Симметрические сигналы передачи данных
используются, например, интерфейсами V.35 и Х.21.
Если для передачи отдельных сигналов служит только один кабель
(второй — «земля»), то это будет асимметрический сигнал.
Асимметрические сигналы используются интерфейсом V.24. Интерфейс V.35
использует асимметрические управляющие сигналы, но симметрические
сигналы передачи данных.
Синхронная и асинхронная передача
Чтобы представить себе принципы синхронизации данных на
компьютере, сопоставим ее с нашей речью. Если мы хотим, чтобы нас поняли, нам
следует говорить разборчиво и не слишком быстро. Другими словами,
мы должны синхронизировать свою речь со слушателем. Компьютерная
синхронизация основывается на тех же требованиях: передающий и
принимающий компьютер должны «говорить на одном языке».
Используются два типа синхронизации передаваемых данных:
• Синхронная передача, предусматривающая побитную передачу
данных. Моменты перехода от одного бита к другому одинаково
удалены друг от друга.
82

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
• Асинхронная передача, когда при переходе от одного бита к другому
равноудаленность во времени не поддерживается. Особым случаем
асинхронной передачи данных является так называемая
аритмичная передача. При аритмичной передаче данных передача символов
является асинхронной, передача отдельных битов в рамках
передаваемого символа является синхронной. Под асинхронной передачей
данных в большинстве случаев подразумевается асинхронная
аритмичная передача данных.
При асинхронной аритмичной передаче данных посылаемый символ
помещен в оболочку, образованную с помощью начального бита,
паритетных битов и стоп-битов (см. рис. 3.1).
Старт I
Биты данных
11111111111111111111 ■ 11111 ни in ми iii ими ими им ми пинии мм Частота приемника
Четн. - биты четности
Рис. 3.1. Асинхронная аритмичная передача символов
Приемник генерирует на порядок большую частоту дискретизации, чем
максимально допустимая частота передачи одного бита. Приемник с
помощью данной частоты тестирует образцы принимаемого сигнала. Если
образец точно соответствует начальному биту, предполагается, что
начинается передаваемый символ.
Далее продолжается процесс обработки образцов. Все биты до стоп-бита
считаются битами передаваемого символа. Между начальным битом
и стоп-битами находятся биты данных передаваемого символа. Более
того, там может находиться еще бит паритета, обеспечивающий защиту
кода от искажения.
Асинхронная передача данных имеет преимущество в том, что
приемник может синхронизировать свою передачу с частотой передатчика.
Оболочка, как правило, состоит из одного начального бита, одного бита
паритета и одного (может быть полтора или два) стоп-бита. Это
означает, что при асинхронной передаче возникают дополнительные затраты,
которые могут увеличить на 50% количество запросов на передачу
данных. Передаваемый символ чаще всего имеет от 5-ти до 8-и битов.
При синхронной передаче данных затраты снижаются. В прошлом
использовалась блоковая синхронная передача данных (BSC), когда
83

TCP/IP и DNS в теории и на практике. Полное руководство
данные передавались блоками. В начале блока находился один или
несколько символов синхронизации, которые являлись аналогом
начального бита. Приемник осуществлял синхронизацию на основе таких
символов синхронизации. Блок передавался синхронно. В настоящее время
повсеместно используется совершенно другой принцип, при котором
кроме предаваемых данных передается еще и сигнал синхронизации. На
рис. 3.2 коммуникацию осуществляют четыре устройства (два модема
и два компьютера).
DTE
DTE
1 1
ч
S
{(ИВ)} 1 1 1
МММ
1 1 1 1 1 1
МММ
МММ
м м м м м м м м
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Биты данных
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
м м м м м м м м
Биты данных
м м м м м м м м
1 >
S
ч
Синхро-
байт
Байт 1
И. В. - источник времени
Байтп-1
Байтп
Синхро-
байт
Рис. 3.2. Синхронная передача данных
Как и в оркестре, в котором может быть только один дирижер,
источником времени может быть только одно из этих четырех устройств. Как
правило, таким источником может быть один из модемов (originator).
Остальные устройства подчиняют свои действия тактам синхронизации.
Поскольку все четыре устройства синхронизированы, они могут
осуществлять коммуникацию непосредственно между собой без
тестирования отдельных образцов символов. Если бы источником времени был
один из компьютеров, мы могли бы настроить модем как originator на
стороне компьютера, генерирующего время. При этом для данного
модема следует устанавливать режим, при котором используются внешние
часы (часы компьютера).
84

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Протоколы V.24, V.35 и Х.21
На физическом уровне определены протоколы V.35,X.21 и V.24(RS 232),
которые используются последовательными интерфейсами. Конечно,
кроме этих протоколов есть и другие, но указанные три используются
чаще остальных. Обычно они применяются для связи модема и
компьютера (или маршрутизатора).
Вполне возможно, что кто-то никогда не сталкивался с протоколами
V.35 и Х.21, а вот с протоколом V.24 работали все — он используется для
подключения модема к компьютеру по последовательным интерфейсам
СОМ1 и COM2 (в UNIX данные интерфейсы называются /dev/ttySO
и /dev/ttySl).
Максимальная скорость передачи данных с использованием протокола
V.24 достигает 64 Кбит/с. Если же нам нужна более высокая скорость,
нужно задействовать протокол V.35 или Х.21.
Рассмотрим разъемы каждого протокола — по ним очень легко
определить используемый протокол (см. рис. 3.3).
рШОрШО!
V.24
V. 24/9 pin
Х.21
тшящш
V.35
Рис. 3.3. Разъемы протоколов V.24, V.35-HX.21
85

TCP/IP и DNS в теории и на практике. Полное руководство
Протоколы V.35 и Х.21 передают информацию по паре проводов, то есть
ими используется симметрическая передача данных. Протокол V.24
подразумевает асимметрическую передачу.
Используя интерфейсы V.24, V35 или Х.21, можно соединить два
компьютера, но только если расстояние между ними не превышает
нескольких метров, — в противном случае нужно использовать модемы.
В таблице 3.1 представлено назначение отдельных сигналов
интерфейсов V.24, X.21 и V.35. Я описал в таблице назначение сигналов кабеля,
соединяющего компьютер с модемом. Если в поле «от» приведено
значение «к», то источник сигнала — компьютер, а если «м» — модем. Поле
«тип» определяет тип сигнала — симметрический (между А и В) или
асимметрический (между А и «землей»). Все сигналы в таблице
разбиты на группы по выполняемым функциям — «земля», данные,
управляющие сигналы и т. д.
Таблица 3.1. Назначение отдельных сигналов интерфейсов V.24, X.21 и V.35.
«Земля»
Данные

Управление
Синхро
Тест
Описание сигнала
«Земля» экрана
«Земля» сигнала
Передаваемые данные
Принимаемые данные
Запрос передачи «Компьютер:
Я готов»
Готовность к передаче «Модем:
Я готов «
Готовность DCE (готовность
набора данных)
Готовность терминала
Обнаружение несущей
Индикатор вызова
Внешний синхро (clock)
Готовность передаваемых
данных
Готовность принимаемых
данных
Определение качества сигнала
Готовность к приему
От
к
м
к
м
к
м
к
м
к
м
к
м
м
Обоз нач.
сигнала
EIA
ITU
GND 101
SG 102
TD 103
RD 104
RTS 105
CTS 106
DSR 107
DTR
DCD 109
RI 125
ЕС 113
ТС 114
RC 115
SQD 140
RFR 142
V.24
25
Pin
9
Pin
1
7 5
2 3
3 2
4 7
5 8
6 6
20 4
8 1
22 9
24
15
17
21
25
Х.21
15 Pin
А
В
1
8
2 9
4 11
3 10
5 12
6 13
V.35
Тип
Сим
Асим
Асим
Асим
Асим
Асим
Асим
Асим
Асим
Асим
Асим
34 Pin
А
В
А
В I
Р S
R Т
с
D
Е
Н
F
J
и w
Y АА
V X
86

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Диалог между компьютером и модемом схематично изображен на
рис. 3.4. Сигналы DTR и DSR информируют о готовности устройства
(компьютера или модема — см. таблицу). На практике сигналы DTR
и DSR используются не всегда. Если DTR и DSR не используются (не
подключены), это означает, что обе стороны соединения уже готовы
(сконфигурированы). Это делается для того, чтобы одна сторона не
ждала вторую, что может длиться довольно долго.
Сигналы RTS и CTS очень важны для управления потоком данных.
Если буфер памяти модема полон, он снимает сигнал CTS (CTS = 0), что
предписывает компьютер на определенное время прекратить передачу
данных. После того, как буфер освобождается, модем заново
устанавливает сигнал CTS, и компьютер возобновляет передачу данных. С
другой стороны, если компьютер загружен и временно не может принимать
данные, он прерывает этот процесс с помощью сигнала RTS (сбрасывает
RTS в 0).
РТЕ
Компьютер
108, DTR —
-<■
106, DTS —
-<■
103, TD —
Рис. 3.4. Диалог компьютера и модема
модемный кабель
DCE
компьютер включен
Модем
модем включен
компьютер: «Я готов»
Модем: «Я готов»»
Данные
Данные
Несущая обнаружена
дозвон
—^
^
w
^
107, DSR
106, CTS
104, RD
109, DCD
125, RI
телефонная
линия
87

TCP/IP и DNS в теории и на практике. Полное руководство
Сигналы данных (как TD, так и RD) могут сначала передавать данные
только между компьютером и модемом, как АТ-команды. Только после
того, как соединение между модемами установлено, TD и RD сигналы
могут быть использованы для передачи данных между компьютерами.
Управление потоком данных с помощью сигналов RTS и CTS
особенно эффективно при использовании интерфейса V.24. Интерфейсы V.35
и Х.21, как правило, работают на более высоких скоростях и могут быть
использованы для подключения к сети Frame Relay. В этом случае по
одному интерфейсу (физическому интерфейсу) «проходит» несколько
суб-интерфейсов (логических интерфейсов), и в Frame Relay каждый
из субинтерфейсов соответствует одному DLCI, то есть виртуальному
кольцу. Если одно виртуальное кольцо перегружено данными,
невозможно остановить поток данных с помощью RTS или CTS, поскольку
подобное прерывание повлечет прерывание на всех субинтерфейсах.
Нуль-модемное соединение
Если мы хотим соединить два компьютера путем использования V.24,
Х.21 или V.35 интерфейсов (каждая сторона должна использовать
одинаковый протокол), соединительный кабель должен быть скомму-
тирован специальным образом. Нуль-модем — это специальным
образом изготовленный кабель, позволяющий непосредственно соединить
компьютеры. Можно изготовить нуль-модем для каждого типа
интерфейса — V.24, X.21 или V.35. Схемы распайки (способ соединения
проводов) приведены на рис. 3.5.
2^х^2 2\/2 2^^2
4—11—4 4^^4 4 И Г4
5 -J I— 5 5 ^^^ 5 5 4> 5
6—,1—6 6-, г-6 8 ^^ 8
О —1|— D 0—| г— О 8 ^^^- Ь
8 J L 8 8 AL 8 6 ^^^ 6
20 J L20 20^*^20 20-^^20
7 7 7 7 7 7
Рис. 3.5. Нуль-модемы(V.24, Х.21 и V.35 соответственно)
88

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
3.2. Модемы. Аналоговые линии
3.2.1. Назначение и принцип работы
Телефонная сеть часто используется для передачи данных на большие
расстояния. Можно, например, подключиться к удаленному
компьютеру, находящемуся в другом городе, и совершить обмен данными. Проще,
конечно, подключиться к Интернету — соединение будет надежнее
(поскольку вы звоните на местный телефон провайдера) и дешевле (если
нужно передать данные за пределы страны).
Как известно, телефонные сети используются для передачи
аудиоинформации — попросту говоря, нашей с вами речи. Чтобы передать
цифровой сигнал по телефонной сети, его нужно модулировать, а затем де-
модулировать. Функции модуляции и демодуляции цифрового сигнала
выполняют модемы (отсюда и название этих приборов — модулятор/
демодулятор).
Модем подключается к компьютеру или маршрутизатору с помощью
модемного кабеля (в случае с компьютером модем подключается к СОМ-
порту с помощью кабеля интерфейса V.24). С помощью второго кабеля
модем подключается к телефонной сети, как обычный телефон.
Модемы могут быть внешними и внутренними (встроенными).
Внешние модемы — это отдельные устройства с собственным блоком
питания. Внутренние модемы устанавливаются как карты расширения (ISA-,
PCI- или PCMCIA-карта). В этом случае из компьютера «исходит»
всего один телефонный кабель, который подключается к телефонной сети.
В последнее время появились внешние модемы, способные
подключаться к USB-шине компьютера.
Как уже отмечалось выше, мы можем соединить два компьютера без
использования модема (с помощью нуль-модемного кабеля), но в этом
случае расстояние между компьютерами должно быть небольшим.
Соединение компьютеров на относительно большом расстоянии
(например, находящихся в разных зданиях) можно устроить через модемы,
соединив их напрямую, то есть, создав выделенную линию.
Если расстояние между компьютерами очень велико, то имеет смысл
воспользоваться услугами телефонного оператора (провайдера) и его
сетью (телефонной, кабельной,...). При этом соединение между
компьютерами может быть организовано либо опять же на основе выделенной
линии, либо с использованием dial-up-соединения.
89

TCP/IP и DNS в теории и на практике. Полное руководство
3.2.2. Соединение модемов через провайдера
Dial-up-соединение
При использовании dial-up-соединения мы звоним на определенный
городской (или междугородний) номер, модем «на том конце» линии
«поднимает трубку», и устанавливается соединение. Преимущество
данного способа очевидно — он дешев. Для организации
dial-up-соединения вам хватит самого модема. Недостатки — медленная скорость
и ненадежность соединения.
модемный кабель
Компьютер
телефонная
линия
Компьютер
Модем
Рис. 3.6. Dial-up-соединение
Также очевидно, что поскольку dial-up-соединение использует
телефонную сеть, как и при обычном телефонном разговоре, ваш телефон будет
занят, пока вы не разорвете модемное соединение.
Выделенные линии
Второй способ соединения компьютеров заключается в организации
выделенной линии между модемами, подключенными к компьютерам.
Преимущество выделенной линии в более высоком качестве связи.
Также немаловажно, что вам не нужно тратить время на дозвон — связь
установится практически сразу после включения компьютера и модема.
90

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Но организация выделенной линии стоит довольно дорого и занимает
определенное время, к тому же не все модемы могут работать на
выделенной линии.
Дешевые модемы не поддерживают выделенные линии вообще,
модемы среднего класса поддерживают только двухпроводные выделенные
линии (dial-up — само собой), а «взрослые» модемы поддерживают все
три вида соединения: dial-up, двухпроводная и четырехпроводная
выделенные линии.
3.2.3. «Автоматические» модемы. Использование AT-команд
ДЛЯ «ПРЯМОГО» УПРАВЛЕНИЯ МОДЕМОМ
При использовании dial-up-соединений есть одна проблемка: кто будет
набирать номер? Раньше, во времена самых первых модемов,
пользователь должен был вручную набрать номер, а затем переключить модем
в режим данных (с помощью переключателя VOICE/DATA).
Позже появились так называемые «автоматические» модемы,
принимающие специальные команды от компьютера. Вот три основные команды
для набора номера: «поднять» трубку, набрать номер, «положить»
трубку. После набора номера такие модемы тоже автоматически переходят
в режим данных.
Управляющие модемом команды называются АТ-командами.
Каждая из них состоит из нескольких символов. Впервые данные команды
были представлены компанией Hayes. АТ-команды предназначены для
управления модемом через асинхронный интерфейс. Также АТ-команды
часто применяются для настройки модема на синхронную передачу,
если используется интерфейс V.24. По умолчанию обычно используется
асинхронный режим. После подключения модема к СОМ-порту
компьютером через терминальные приложения (например, программу Ну-
perTerminal) посылаются АТ-команды.
Остановимся подробнее на роли АТ-команд в управлении
модемом. Например, АТН-команда предусматривает посылку компьютером
в СОМ-порт, к которому подключен модем, АТН-строки. Модем
интерпретирует АТН-строку как команду. Первоначально компьютер
осуществляет коммуникацию с модемом, используя АТ-команды, и, после
того, как соединение между модемами установлено, локальный модем
информирует об этом путем посылки компьютеру команды CONNECT
и переключается в режим данных.
91

TCP/IP и DNS в теории и на практике. Полное руководство
Теперь компьютеры могут напрямую общаться между собой, то есть так, как
будто бы между ними нет никаких модемов (как если бы они были
соединены нуль-модемами). Если компьютеру нужно переключить модем обратно
в командный режим, он посылает строку «+++» в качестве данных.
Если вы работаете в Windows, запустите программу Hyperterminal.
Создайте новое соединение с любым номером. Нажмите кнопку Изменить
в окне Подключение. Затем нажмите кнопку Настроить, перейдите на
закладку Дополнительные параметры связи и включите режим
Открыть окно терминала до набора номера. Теперь дважды нажмите ОК
(в этом окне и в предыдущем), а затем — кнопку Набрать номер. Вы
увидите Окно терминала до набора номера. Теперь можно
попрактиковаться и ввести пару АТ-команд.
Например, можно ввести команду AT, которая означает «Модем, ты
готов?» В ответ вы должны получить строку Ок. Попробуйте ввести
произвольную строку символов — модем вам не ответит.
Наш модем готов к набору номера. Отправим ему команду набора
номера ATDtn, где t — тип набора (р — импульсный, t — тоновый), an -
телефонный номер, например, ATDP1234567. Модем начнет набор
номера. Как только он подключится к другому модему, вы увидите
сообщение CONNECT. Затем оба модема (наш и «на той стороне») перейдут
в режим данных. Процесс «общения» модемов подробно описан в
таблице 3.1а, правда, без учета сообщений об ошибках и АТ-команд для
инициализации нашего модема. Сегодня все чаще и чаще используются
выделенные линии, не требующие дозвона.
Таблица 3.1а. «Общение» модемов
Сигнализация
АТ-команды
Локальный
компьютер
105, RTS
AT
АТйРномер
-
«-
—
4-
-
Сигнализация
АТ-команды
Передача
данных
«_
—
Локальный
модем
(набирает
номер)
106, CTS
ОК
набор
109, DCD
CONNECT
Телефонная линия
Неактивна
Установка
соединения (на максимально
возможной скорости)
Используется
Удаленный
модем
(принимает
вызов)
106, CTS
~~*
Удаленный
компьютер
105, RTS
Прием вызова
109, DCD
-
—*
92

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
3.2.4. Синхронная передача и асинхронная
Передача данных может быть либо асинхронной, либо синхронной.
Раньше для синхронной передачи использовались синхронные модемы,
а для асинхронной — асинхронные. Современные модемы обычно
поддерживают оба типа передачи данных.
Компьютер по умолчанию использует асинхронную передачу, поэтому
модем, который будет использоваться в синхронном режиме, должен
быть сначала установлен в асинхронном режиме, иначе произойдет
ошибка. Данная проблема отсутствует у PCMCIA- и USB-модемов,
поскольку они не используют стандартный последовательный интерфейс
(СОМ-порты).
При конфигурировании синхронного модема мы должны не забыть
установить один модем в качестве источника времени (для синхронизации).
Модемы, работающие на скоростях до 64 Кбит/с, могут поддерживать
как синхронный, так и асинхронный режим. Модемы, работающие на
скоростях выше 64 Кбит/с, обычно поддерживают синхронный режим.
Существуют и модемы, использующие автосинхронный режим. Они
«общаются» с компьютером в синхронном режиме, хранят данные в
памяти, а затем отправляют эти данные в синхронном режиме. Стоит
отметить, что такие модемы используются довольно редко.
3.2.5. Базовая полоса и голосовая полоса
Рассмотрим принципы телефонной связи. При передаче голоса по
телефону используется полоса в диапазоне от 0.3 до 3.4 КГц. Телефонный
провод тянется от местной телефонной АТС до телефонной розетки
в вашей квартире. Ваша местная АТС соединена с другими
телефонными станциями, соединения телефонных станций образуют
телефонную сеть.
Поскольку сигналам свойственно такое явление, как затухание, между
телефонными станциями для увеличения уровня сигнала
используются повторители (см. рис. 3.7). Задачей повторителя является удержание
сигнала в пределах 0.3-3.4 КГц. Если телефонное соединение проходит
через повторитель (как в большинстве случаев), модемы должны
транслировать сигнал в соответствующую полосу. Это так называемая
голосовая полоса.
93

TCP/IP и DNS в теории и на практике. Полное руководство
модемный кабель
Компьютер
Модем
телефонная
линия
ТС - телефонная
станция
ПС - повторяющая
станция
(повторитель)
телефонная
линия
Компьютер
Рис. 3.7. Телефонные станции и повторители
Голосовая полоса позволяет передавать данные со скоростью 56 Кбит/с.
Если мы звоним на номер нашей телефонной станции (то есть наш
модем и удаленный модем подключены к одной и той же телефонной
станции), повторители не используются (см. рис. 3.8).
модемный кабель
телефонная
линия
ТС - телефонная
станция
ПС - повторяющая
станция
(повторитель)
телефонная
линия
Рис. 3.8. Базовая полоса — прямое соединение через телефонную станцию
94

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Если соединение происходит без повторителей, используется более
широкая базовая полоса. Модемы, работающие на базовой полосе, могут
передавать данные с более высокой скоростью, которая достигает
сотен Кбит/с при использовании двухпроводной линии, на относительно
большие расстояния (до нескольких миль).
Четырехпроводная линия (полный дуплекс) позволяет достичь
скорости передачи 2 Мбит/с или даже более высокой — все зависит от
расстояния. Модемы, работающие на базовой полосе, обычно не являются
автоматическими, поскольку они всегда работают с выделенной линией
и в синхронном режиме.
3.2.6. Скорость передачи
Модемы получают и принимают данные по телефонной линии, а также
получают и принимают данные компьютера. Ясно, что первая скорость
передачи значительно ниже второй. Чтобы хоть как-то выровнять эти
скорости, модемы оборудованы специальным буфером памяти, в котором
хранятся полученные от компьютера, но еще не отправленные данные.
Таблица 3.2. Скорость передачи согласно рекомендациям ITU
Рекомендации /71/
V.32
V.32bis
V.34
V.34+
V.90
Скорость передачи в Кбит/с
9.6
14.4
28.8
33.6
56 (от телефонной станции к модему)
33.6 (от модема к телефонной станции)
Говоря о скорости передачи данных по модему, мы имеем в виду скорость
передачи данных по телефонному проводу. В зависимости от стандарта
ITU изменяется скорость передачи данных. Если модем поддерживает
определенную рекомендацию, значит, он может работать с
максимальной скоростью, соответствующей стандарту ITU.
Стандарт (рекомендация) V.90 подходит не на все случаи жизни.
Например, вряд ли у вас получится использовать V.90 для подключения
домашнего компьютера к офисному dial-in-серверу. Стандарт V.90 больше
подходит для подключения к интернет-провайдеру, и то при условии,
что провайдер подключен к телефонной сети через цифровую АТС.
95

TCP/IP и DNS в теории и на практике. Полное руководство
аналоговая линия
цифровая линия
Цифровая АТС
(провайдер)
О
Рис. 3.9. Стандарт V.90
В наше время становится все больше цифровых АТС наряду с тем, что
аналоговые продолжают свою работу. Поскольку последние всё еще
актуальны, начнем разговор о работе АТС с них. Сегодня аналоговый
сигнал, полученный от аналоговой АТС, проходит через АЦП (аналого-
во-цифровой преобразователь — A/D). На выходе получается цифровой
сигнал, который можно передавать современным цифровым АТС.
Ответ сервера провайдера приходит на АТС провайдера в цифровом
виде, то есть без изменения. Но ведь его нужно передавать
пользователю, подключенному к аналоговой АТС, поэтому используется обратное,
цифро-аналоговое преобразование (ЦАП).
Именно поэтому скорость от АТС к модему составляет 56 Кбит/с, а от
модема к АТС — 33.6 Кбит/с (поскольку сигнал, полученный от
провайдера, не нуждается ни в каком преобразовании на АТС провайдера).
3.2.7. Аппаратное сжатие данных.
Особенности разных технологий
Если ваш модем «умеет» сжимать данные, а модем «на том конце»
линии способен распаковать их, то это способствует увеличению
количества передаваемых данных при неизменной скорости передачи. Сжатие
данных поддерживается только при асинхронной передаче.
96

Глава 3. Физический уровень — канал передачи данных, безопасность; стандарты
Компания Microcom разработала протокол сжатия данных MNP 5. А
одна из международных организаций по стандартизации — ITU
(Международное телекоммуникационное сообщество) — разработала стандарт
V.42bis для сжатия данных.
При использовании сжатия данных скорость передачи данных может
достичь 100 Кбит/с на линиях со скоростью 28.8 Кбит/с.
Что же нужно, чтобы достичь такой скорости? Ответ прост: вам
нужна пара модемов, поддерживающих один из протоколов сжатия. Лучще,
чтобы модемы были одной фирмы — тогда обеспечивается 100%-я
совместимость.
Протокол MNP 5 обеспечивает сжатие примерно 2:1, а протокол V.42bis —
примерно 3:1 и даже 4:1. К недостаткам MNP 5 можно отнести тот факт,
что при сжатии несжимаемых данных (например, уже сжатых ранее арг
хивных файлов), он наоборот увеличивает объем передаваемых данных.
В этих случаях (при передаче сжатых файлов) рекомендуется в
настройках модема отключать аппаратное сжатие данных.
3.2.8. Обнаружение и коррекция ошибок
Идея механизма обнаружения ошибок очень проста: данные между
модемами передаются в виде блоков данных, которые называются
кадрами. Модем-источник (который передает кадр) вычисляет контрольную
сумму блока данных и добавляет ее к передаваемым данным.
Модем-назначение (принимающий кадр) вычисляет контрольную сумму
полученного кадра (без первоначальной контрольной суммы), а затем сравнивает
ее с исходной контрольной суммой. Если контрольные суммы совпали,
значит, кадр передан правильно, и модем передает его дальше
компьютеру. Если же контрольные суммы не одинаковы, то модем запрашивает
этот кадр еще раз — пока он не будет получен без ошибок.
Первоначально наиболее часто используемыми протоколами от
Microcom были MNP 2 и 4 (MNP — Microcom Networking Protocol). Затем
в дополнение к ним появился протокол V.42 от ITU.
Протокол V.42 также предусматривает двухфазный процесс установки
соединения. На первой фазе — фазе «обнаружения» — модемы
«знакомятся» друг с другом, предоставляя друг другу информацию о своих
возможностях.
4 Зм. 518
97

TCP/IP и DNS в теории и на практике/Полное руководство
На второй фазе — фазе «подтверждения» — модемы «договариваются»
об обмене информацией: размере блока данных, запросах для
подтверждения получения блока данных.
Эффективность протокола V:42 выше, чем MNP-4, особенно при
работе на сильно зашумленных линиях. Кроме того, протокол V.42
обеспечивает более помехозащищенный метод начальной
инициализации, чем MNP-4.
3.3. Цифровые линии
До сих пор мы говорили об аналоговых линиях, теперь пришла пора
обсудить принципы работы цифровых АТС.
3.3.1. ISDN
Отмечу, что если раньше цифровые линии использовались только
телефонными компаниями для внутренней связи, то сегодня любой
желающий может испытать преимущества цифровых ISDN-линий — были бы
деньги и желание.
Итак, сети ISDN (Integrated Services Digital Network — цифровая сеть
с интегральными услугами) — это сети с коммутацией каналов и
цифровой обработкой данных. В последнее время ISDN-сети довольно
уверенно развиваются, причем цены на их организацию постепенно снижаются
(хотя пока остаются достаточно дорогими, по сравнению с обычными
модемными соединениями).
Прежде чем приступать к дальнейшему рассмотрению технологии
ISDN, рассмотрим три типа каналов, на которых основан
пользовательский интерфейс ISDN:
• Канал В — скорость передачи 64 Кбит/с.
• Канал D — скорость передачи 16 или 64 Кбит/с.
• Канал Н — скорость передачи 384 Кбит/с (НО), 1536 Кбит/с (НИ)
или 1920 Кбит/с (HI2).
Сеть ISDN поддерживает два типа пользовательского интерфейса:
98

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
• Начальный интерфейс (Basic Rate Interface, BRI) — два канала
для передачи данных типа В (по 64 Кбит/с) и один канал типа D
(со скоростью 16 Кбит/с) для передачи управляющей информации.
• Основной интерфейс (Primary Rate Interface, PRI) — для более
требовательных пользователей:
• В Северной Америке: поддерживается схема 23В + D — 23 канала
по 64 Кбит/с (тип В) для передачи данных и один канал типа D
(64 Кбит/с) для передачи управляющей информации.
• В Европе: схема ЗОВ + D, каждый канал (включая D-канал) по
64 Кбит/с.
Начальный интерфейс Основной интерфейс
Рис. 3.10. Начальный и основной интерфейсы ISDN
Канал типа D служит для передачи адресной информации, которая
используется для коммутации В-каналов (это основная функция D-каналов)
и для поддержки услуг низкоскоростной сети с коммутацией пакетов.
Начальный интерфейс
Начальный интерфейс использует имеющуюся телефоную сеть (то есть
для передачи данных служат два медных провода). Витая пара,
исходящая из телефонной компании, образует так называемый U-интерфейс
(см. рис. 3.11).
U-интерфейс — это интерфейс между телефонной компанией и
устройством NT-1, которое обычно поставляется оператором ISDN-услуг.
99

TCP/IP и DNS в теории и на практике. Полное руководство
Провайдер
ТЕЛЕФОННАЯ СЕТЬ
Передача / \ .••"••. \
► эоофоо>оо<| „-X^JXy
~< :>оофоооо<| " \>iJ
Прием \
U-Интерфейс
Интерфейс S/T
Рис. 3.11. Начальный интерфейс
Внутри зданий используется кабель из двух витых пар — это S/T-интер-
фейс, который позволяет подключать до восьми ISDN-устройств.
Именно поэтому для подсоединения к внешней линии необходимо устройство
NT-1 (точнее, по одному устройству на каждый BRI-интерфейс).
Устройство NT-1 заслуживает отдельного разговора. NT-1 (Network
Termination) — это устройство функциональной группы, образующее
абонентское окончание (Digital Subscriber Line, DSL) на кабеле,
который соединяет оборудование пользователя с сетью ISDN. Точка U — это
точка подключения устройства NT-1 к сети. Как уже отмечалось,
устройство U может поставляться оператором сети ISDN или же
принадлежать пользователю, но в обоих случаях оно всегда устанавливается
у пользователя.
На рис. 3.12 показано, что отдельные устройства подключаются к
интерфейсу S/T. Физически S/T-интерфейс — это четырехпроводная линия.
Поскольку начальный интерфейс (BRI) использует два В-канала, два
отдельных устройства (например, один цифровой телефон и один
модем или два цифровых телефона) могут работать одновременно.
Несмотря на то, что у нас всего два В-канала, мы можем подключать
к S/Т-интерфейсу более двух устройств (но только два из них смогут
работать одновременно). Скажем, мы можем подключить пять
цифровых телефонов и присвоить им неповторяющиеся номера.
Пользователю будет казаться, что у нас пять разных телефонных линий, хотя на
самом деле мы сможем одновременно использовать только два телефона.
100

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Макс. 182 м (600 футов), макс. 8 устройств
Терминатор
Терминальный
адаптер
Цифровой ISDN-
телефон адаптер
Аналоговый
модем
Интерфейс R
(разъем RJ-11)
RS-232,
USB,
PCMCIA
PC
Рис. 3.12. Присоединение устройств к S/T-интерфейсу
Для подключения к S/T-интерфейсу аналоговых устройств (например,
аналоговых модемов, факсов и телефонов) используется терминальный
адаптер.
Нужно сказать пару слов о «цифровых модемах». На самом деле
модемами данные устройства можно назвать с большой натяжкой. Ведь
модем — это модулятор/демодулятор, преобразовывающий аналоговый
сигнал в цифровой и обратно. Если мы имеем дело с цифровым
сигналом, никакого преобразования не нужно. Выходит, что «цифровой
модем» ничего не делает? Да, ничего, кроме преобразования одного типа
цифрового интерфейса (V.24, со стороны компьютера) в интерфейс S/T
(коннектор RJ-45). Вывод: цифровой модем — это своеобразный
переходник V.24 - S/T.
Сеть ISDN использует синхронную передачу данных. Начальный
интерфейс (BRI) используется для передачи данных со скоростью 192 Кбит/с
с разделением на слоты для отдельных каналов (см. рис. 3.13).
101

TCP/IP и DNS в теории и на практике. Полное руководство
2
k-J
10
I
15
I
23
L_
26
_J
34
L_
37
_l
45 48
L_*J
2
□
D
ш
8 бит
ISJ
IbSI
48 бит за 1/4 мс, То есть 48x4x1000=192 Кбит/с
|B2l
8
|В2|
8
3 8 18 1
12 бит за 1/4 мс, т. е. 12x4x1000=48 Кбит/с
Канал В1,16 бит за 1/4 мс, т. е. 16x4x1000=64 Кбит/с
Канал В2,16 бит за 1/4 мс, т. е. 16x4x1000=64 Кбит/с
Канал D, 4 бита за 1/4 мс, т. е. 4x4x1000=16 Кбит/с
Рис. 3.13. Как начальный уровень делится на отдельные слоты
Высокоуровневые протоколы и сигнализация
В-каналы могут использоваться для передачи речи (для обычного
телефонного разговора), но нас более интересует передача данных по ним.
При передаче данных кадры протокола LAPB (Link Access Protocol
Balanced — протокол доступа к линии, сбалансированный)
внедряются в В-каналы, а кадры протокола LAPD внедряются в D-канал (кроме
этих двух протоколов сети ISDN используют протоколы LABF, I.465,
V.120 и др.). Оба протокола — LAPB и LAPD — являются производными
от протокола HDLC (см. п. 4.1.3).
Сетевые пакеты, в свою очередь, внедряются в кадры протокола LAPB.
Пакеты сетевого уровня могут принадлежать, например, протоколу Х.25.
Данный протокол представляет для нас особый интерес, поскольку
IP-дейтаграммы могут быть внедрены в кадры протокола LAPB.
Адрес
Управляющее
поле
Контрольная
сумма
(checksum)
Рис. 3.14. Структура кадров протоколов LAPB и LAPD
Итак, мы уже рассмотрели ситуацию, в которой В-канал используется
для передачи данных или вызова. Как же происходит виртуальный
вызов («набор номера»)? Для ответа на этот вопрос поговорим о
сигнализации (для нее применяется D-канал).
102

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Различают два уровня сигнализации. При DSS1 -сигнализации
пользователь запрашивает создание вызова или другой услуги. Со стороны
провайдера (оператора) DSS1-сигнализация заменяется сигнализацией
SS7 (Signal System number 7), и вызов передается вызываемой стороне.
Данная сигнализация также используется для классических аналоговых
вызовов. О входящих вызовах сигнализирует DSS1.
Сигнализация DSS1 определена в рекомендациях ITU Q.391 и Q.392.
В Q.391 описаны основные сервисы (создание вызова, удержание
вызова и т. д.) и связь с моделью ISO OSI.
При DSS1-сигнализации отправляются служебные сообщения.
Некоторые из них представлены в таблице 3.3:
Рис. 3.15. DSS1 сигнализация
Таблица 3.3. Некоторые служебные сообщения DSS1
Тип сообщения
Setup
Call Proceeding
Alerting
Connect
Disconnect/Release
Аналогия с обычным телефоном
Поднимаем трубку
Набираем номер
Дозвон
«На той стороне» поднимают трубку
Вешаем трубку |
Прикладной
Транспортный уровень
Q.932
Сетевой уровень
Q.931
Канальный уровень
LAPD
Физический уровень
Интерфейсы БД и U
Рис. 3.16. DSS1 в модели ISO OSI
103

TCP/IP и DNS в теории и на практике. Полное руководство
3.3.2. Линии Е*
Линия Е1 — цифровой интерфейс, позволяющий передавать данные со
скоростью 2 048 Мбит/с. Е1 описана в рекомендациях ITU G.702 и G.703.
Иерархия Е-линий представлена в таблице 3.4. Базовая линия Е0
позволяет передавать данные со скоростью 64 Кбит/с. Линия Е1 содержит
32 базовых линии (для сравнения Т1 = 25 базовых линий). Линия Е2 -
4ХЕ1,ЕЗ=1бхЕ1ит.д.
Таблица 3.4. Линии Е*
Линия
(Е0)
Е1
Е2
ЕЗ
Е4
Скорость
передачи, Кбит/с
64
2 048
8448
34 368
139 264
Несмотря на то, что Е1 содержит 32 базовые линии, мы можем
использовать только 30. Слоты с номерами 0 и 16 зарезервированы для
служебного использования: «обслуживания» кадров, передачи контрольных
сумм (см. рис. 3.17).
Вы можете арендовать один (64 Кбит/с) или более слотов.
Максимальная пропускная способность линии Е1 равна 30X64 = 1920 Кбит/с.
32x8= 256 bits/125 m s = сса 2 Mb/s
6
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
fe
Ш'
;Ш
Ш
£**?
ш
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Рис. 3.17. Супер-кадр Е1 делится на 32 слота по 64 Кбит/с каждый
104

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Для построения линии Е1 могут быть использованы: витая пара (120 Q),
коаксиальный кабель (75 Q) или оптический кабель.
Для подключения к линии Е1 используются модемы с коннекторами
У35,У.24илиХ.21.
3.4. Локальные сети (LAN, Local Area Network)
Локальные сети используются для соединения компьютеров,
сосредоточенных на небольшой территории (обычно в радиусе до 2 км). Для
построения локальных сетей сегодня обычно используются технологии
Ethernet, Fast Ethernet и Gigabyte Ethernet (все они относятся к
канальному уровню). Помимо вышеперечисленных, разработанными
являются технологии FDDI, Token Ring и Arcnet, но они по разным причинам
сегодня практически не используются.
3.4.1. Кабели
Правильно проложить кабель — задача довольно непростая. Кабель не
должен проходить где попало, а тем более висеть под потолком, ничем
не закрепленный. Обязательным является соблюдение определенных
правил, позволяющее избежать повреждения кабеля.
Сейчас речь идет не о простых телефонных кабелях или кабелях
локальной сети: ведь система сигнализации тоже очень активно
использует кабель — там не все передается «по воздуху». Повреждение такого
кабеля может отрицательно сказаться на безопасности всего здания
(помещения).
Категории кабелей
К сожалению (или к счастью), обо всех кабелях мы говорить не будем:
остановимся только на кабелях локальной сети и телефонных.
Для каждого элемента сети, локальной или телефонной, в здании есть свое
место. Активные элементы сети (концентраторы, коммутаторы,
распределительные панели, телефонная станция) находятся, как правило, в
отдельных помещениях, доступ к которым имеет только обслуживающий
персонал. На рис. 3.18 вы найдете пример организации структуры кабелей.
105

TCP/IP и DNS в теории и на практике. Полное руководство
- многомодовое оптоволокно до 2-3 км FDDI-коммутатор
- одномодовое оптоволокно до 70 км
Рис. 3.18. Пример структуры кабелей в здании
Иногда распределительная панель и активные элементы сети находятся
в одной стойке. В некоторых случаях в эту же стойку (rackmount)
помещается еще и мини-АТС. Учитывая размеры современного
оборудования, все это возможно, так что не удивляйтесь. Давно прошли те
времена, когда мини-АТС занимали целую комнату.
Давайте рассмотрим несколько стандартов кабелей (в соответствии
с EIA/TIA):
• Категория 5 — полоса до 100 МГц, независима от протокола (может
использоваться в сетях Ethernet, Token Ring, CDDI).
• Категория 5Е — тоже с полосой до 100 МГц, но некоторые ее
параметры более строги.
• Категория 6 — полоса до 250 МГц.
• Категория 7 — полоса до 600 МГц. Пока это только «прототип»: на
момент написания данной книги не были определены ни типы
коннекторов, ни методы измерения параметров для этого типа кабеля.
Кроме перечисленных категорий кабелей раньше активно
использовались кабели категорий 3 и 4. Сейчас системы, основанные на этих типах
кабелей, нуждаются в модернизации.
106

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Пара
Пара
Пара
PVC
Слой экрана
(полиэстер
саллюминием)
Категория 5Е Категория 6 Категория 7
Рис. 3.19. Структура кабелей разных категорий
Обжимка витой пары
Витая пара 5-й категории состоит из восьми медных проводов (четыре
пары). Такой кабель наиболее часто используется для соединения
элементов сети: компьютера и коммутатора (switch) или концентратора
(hub), двух коммутаторов или концентраторов и т. д. Для витой пары
используются коннекторы типа RJ-45. Схематическое изображение
коннектора и нумерация его контактов приведены на рис. 3.20.
RJ45
^
Рис. 3.20. Коннектор RJ-45
Перед подключением кабеля к элементу сети его нужно правильно
обжать. Схема разводки приведена на рис. 3.21 (в соответствии со
стандартом EIA/TIA 568В).
ОО0О0000
Рис. 3.21. Разводка восьмижильного кабеля (EIA 568В)
107

TCP/IP и DNS в теории и на практике. Полное руководство
Примечание.
Возможно, для разводки кабеля вам будет проще воспользоваться
таблицей 3.5:
Таблица 3.5. Разводка восьмижильного кабеля
Контакт
1
2
3
4
5
6
7
8
Цвет провода
Бело-оранжевый
Оранжевый
Бело-зеленый
Синий
Бело-синий
Зеленый
Бело-коричневый
Коричневый
Оптические кабели
Волоконно-оптический (иногда его называют просто оптическим)
кабель состоит из двух слоев стеклянного волокна. Первый слой — это
сердцевина. Сердцевина окружена вторым слоем — оболочкой.
Оболочка обладает меньшим показателем преломления, чем сердцевина (см.
рис. 3.22).
Рис. 3.22. Волоконно-оптический кабель
Для передачи данных используется свет с длиной волны 850 нм, 1500 нм
или 1500 нм. Излучатели на 850 нм существенно дешевле, чем на 1300
или 1500 нм, но полоса пропускания с использованием таких
излучателей намного уже, например, 200 МГц вместо 500 МГц.
Оптический кабель всегда однонаправлен, то есть с одной стороны у нас
будет передатчик, а с другой — приемник. Чтобы образовать дуплексное
108

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
(двухстороннее) соединение, нам нужна пара оптических кабелей — по
одному на каждое направление.
Диаметр внешнего проводника равен 125 |im (125 мкм). В зависимости
от диаметра сердцевины различают два типа волоконно-оптических
кабелей:
• Многомодовый кабель (диаметр сердцевины 50 мкм или 62.5 мкм)
со ступенчатым или плавным изменением показателя преломления
(см. рис. 3.22). В качестве источника излучения света многомодовые
кабели используют либо светодиоды (LED), либо
полупроводниковые лазеры (в последнее время используются все чаще). От
используемого источника зависит полоса пропускания: чем выше длина
волны (и дороже источник), тем больше полоса пропускания.
• Одномодовый кабель (диаметр сердцевины 9 мкм). В этом типе
кабеля используется центральный проводник очень малого диаметра (от
5 до 10 мкм). Полоса пропускания такого кабеля очень широка — от
100 ГГц на 1 км, поэтому одномодовый кабель обычно используется
для передачи данных на большие расстояния. В качестве источника
света одномодовый кабель использует только полупроводниковый
лазер, поскольку мощности светодиода явно недостаточно.
Вторичная оболочка
^ЧЛЛЛЛЛЛЛЛЛЛЛЛД^
[х Первичная оболочка X]
Ч £ердцеви*1а \
<ст©к. волокно)
„ Первичная оболочка
Вторичная оболочка
250 mm
125 mm
Г 50/62,5 mm £
Вторичная оболочка
LKXXXXXXXXXXXX>G
[х Первичная оболочка х]
Сердцевина -
К
|:.<ед^';||ШШЙ1;
ЛЛЛЛЛЛЛЛЛЛЛЛ,
Первичная оболочка ,
Вторичная оболочка
250 mm
125 mm
9 mm
Многомодовый кабель
Одномодовый кабель
Рис. 3.23. Многомодовый и одномодовый волоконно-оптический кабель
109

TCP/IP и DNS в теории и на практике. Полное руководство
На рис. 3.23 показаны защитные слои волоконно-оптического кабеля.
Оптический кабель обернут в так называемую первичную оболочку, без
которой кабель очень уязвим. Второй слой является дополнительным
и иногда удаляется (например, при соединении кабелей).
Склеивание
V^^ Волоконно-оптический кабель ^^
^*"" ^^ «Хвост свиньи»
V\ Коннектор
Рис. 3.24. «Хвост свиньи»
В офисных условиях более популярны кабели с двумя защитными
слоями (диаметр кабеля 900 мкм), поскольку они обеспечивают более
надежную защиту от всевозможных повреждений. Такие кабели более
дорогие, чем кабели с одним слоем защиты, поэтому они не
используются (точнее редко используются) для передачи данных на большие
расстояния.
При использовании кабелей с первичной оболочкой применяются уже
готовые оптические коннекторы, известные под названием «хвост
свиньи» (см. рис. 3.24). Присоединение оптического кабеля к такому
коннектору требует сложной операции склеивания (а не обжимки, как в случае
с витой парой), поэтому стоимость монтажных работ с использованием
оптических кабелей обходится намного дороже.
Склеивание оптических кабелей (например, оптического кабеля и
«хвоста свиньи») — целая наука. Просто представьте: нам нужно склеить два
слоя стекловолокна — сердцевину и оболочку (см. рис. 3.25).
Некачественное выполнение этой операции резко снижает полосу пропускания
кабелей (иногда вообще до нуля, то есть после такого склеивания по
кабелю вообще ничего нельзя передать).
Волокна должны быть склеены так, чтобы световой луч мог
беспрепятственно проходить по кабелю. Для самой операции склеивания
используется очень дорогой прибор.
Мы можем попытаться избежать склеивания. Для этого мы должны
использовать оптические кабели с двумя слоями защиты и оптические
коннекторы: оптические кабели будут соединены этими коннекторами.
110

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Склеивание
I
> i\ /v-- ^: ^ч; v£$ V, - ^„*^ 4V|^X^'-S'fr Чн
Рис. 3.25. Склеивание оптических кабелей
Еще одна проблема — это разрыв кабеля. Мы не можем просто взять
нож и перерезать кабель пополам. Для этого нужно использовать
специальный прибор. Но даже если у нас есть такой прибор, после разрыва
кабеля мы должны с помощью микроскопа проверить, правильно ли мы
разрезали кабель.
Оптоволокно
Керамика
Рис. 3.26. Оптический коннектор
На рис. 3.26 изображен оптический коннектор, присоединенный к
оптическому кабелю с вторичной оболочкой. На конце коннектора
вторичный слой удаляется, его заменяет керамическое кольцо (Ferrule).
К оптическому коннектору подключается два оптических кабеля с
обеих сторон. Внутри коннектора сердцевины кабелей соприкасаются, что
обеспечивает прохождение светового луча.
111

TCP/IP и DNS в теории и на практике. Полное руководство
3.4.2. Ethernet (10 Мбит/с)
Технология Ethernet иcпoльзyet четыре типа интерфейсов: AUI, BNC,
ТР и оптический коннектор.
Представленный на рис. 3.27 интерфейс AUI (Attachment Unit Interface,
он же 10BASE-5) подразумевает использование трансивера
(передатчик/приемник, transmitter + receiver = transceiver). Сетевой адаптер
подключается с помощью кабеля АШ к трансиверу, а трансивер, в свою
очередь, к среде передачи данных, то есть к сетевому кабелю.
Трансивер используется для передачи/приема данных по кабелю
локальной сети. Имеются трансиверы для коаксиального кабеля (AUI/
BNC) и для витой пары (AUI/TP). Это означает, что интерфейс AUI
универсален. Для подсоединения к интерфейсу AUI используется разъем
DB-15 (он же CANNON 15).
Рис. 3.27. Интерфейс AUI
Интерфейс BNC (10BASE-2) используется для соединений с
использованием коаксиального кабеля. В точке соединения коаксиальный
кабель прерывается. Чтобы соединить два конца кабеля, используется
BNC Т-коннектор. Данный коннектор соединяет два конца кабеля и
сетевой адаптер компьютера.
Витая пара (Twisted Pair, ТР или 10Base-T) подключается с помощью
коннектора RJ-45 к концентратору или коммутатору сети. Коннектор
RJ-45 соединяет две витые пары: одна используется для передачи
информации, а другая — для приема.
Если витая пара соединяет непосредственно два компьютера (имеется
в виду прямое соединение без использования коммутатора), пары долж-
112

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
ны быть соединены перекрестно (то есть пара для передачи с одной
стороны должна быть соединена с парой для приема с другой).
На рис. 3.28 изображена разводка витой пары для стандартов 10Base-T
или 10Base-TX. Провода 4 и 5 не используются, что делает возможным
их использование для аналоговой связи, например, для обычного
телефона.
О000000©
?
Рис. 3.28. Разводка витой пары для WBase-Тили 10Base-JX
Очень интересен сегмент сети, состоящий из двух станций, соединенных
напрямую (без коммутатора или концентратора). Сетевые интерфейсы
в таком сегменте работают в полнодуплексном режиме, полностью
отделяя передаваемые данные от принимаемых.
В таком сегменте никогда не бывает коллизий, поскольку
передаваемые данные сразу, без посредников, поступают на приемник, поэтому
на таком сегменте может быть достигнута теоретически
максимальная скорость передачи (10 Мбит/с для Ethernet и 100 Мбит/с для Fast
Ethernet). Поскольку в нашем сегменте нет коллизий, максимальная
длина сегмента может достичь 45 миль (!) — 72 км.
На рис. 3.29 представлены прямая и перекрестная разводки витой пары.
0©0©©00©
О©©0©©0©
Прямая
Перекрестная
Рис. 3.29. Прямая и перекрестная разводка йитой пары
113

TCP/IP и DNS в теории и на практике. Полное руководство
Примечание.
Если вы хотите соединить два компьютера с помощью витой пары
напрямую, то один конец кабеля нужно обжать как обычно, а второй —
используя перекрестную разводку.
3.4.3. Fast Ethernet (100 Мбит/с)
Технология Fast Ethernet использует витую пару 5-й категории (100
Base-TX) или волоконно-оптический кабель (100 Base-FX). Различие
между Ethernet и Fast Ethernet заключается только в использовании
более качественных кабелей (соответственно, и более дорогой
аппаратуры), а все основные принципы сохраняются. Поэтому для построения
сети Fast Ethernet вам нужны сетевые адаптеры и коммутаторы,
поддерживающие передачу данных со скоростью 100 Мбит/с (теоретически)
и витая пара 5-й категории (или соответствующий оптический кабель).
3.4.4. Gigabit Ethernet (1 Гбит/с)
Данная технология также использует или витую пару, или волоконно-
оптический кабель. В первом случае нам нужна витая пара категории 5Е
или 6. При использовании кабеля категории 5Е данные будут
передаваться параллельно по всем четырем парам. Это сделано, чтобы достичь
скорости 1000 бит/с при полосе пропускания до 100 МГц. Если мы
используем категорию б, то у нас будет полнодуплексная передача, то есть
две пары будут зарезервированы для приема и две — для передачи. Это
обусловлено более высокой полосой пропускания кабеля категории 6.
Кроме витой пары, технология Gigabit Ethernet позволяет использовать
многомодовый и одномодовый волоконно-оптический кабель. Стандарт
1000Base-LX подразумевает использование одномодового кабеля. В
качестве источника света используется полупроводниковый лазер с
длиной волны 1300 нм, максимальная длина сегмента сети всего 1.2 мили
(почти 2 км). Если же стандарт 100 Base-LX применить для многомодо-
вого кабеля, то расстояние будет равно 450 ярдов (около 411 м). Буква
«L» в названии стандарта означает «Long wavelength»
(«длинноволновый»).
Стандарт 100 Base-SX (Short wavelength) используется только для мно-
гомодовых оптических кабелей, длина волны 850 нм, максимальное
расстояние — 25 ярдов (чуть больше 22 м).
114

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
3.4.5. FDDI (Fiber Distributed Data Interface)
Аббревиатура FDDI расшифровывается как Fiber Distributed Data
Interface — распределенный интерфейс передачи данных по волоконно-
оптическому кабелю.
Существует два типа FDDI: первый использует волоконно-оптический
кабель (FDD), а второй — витую пару (CDDI). Оба типа FDDI
можно комбинировать в одной сети. Предпочтение обычно отдается витой
паре, поскольку она дешевле, но, если нужно передавать информацию
на большие расстояния, необходим волоконно-оптический кабель.
Что нужно знать о FDDI:
• FDDI — это первая технология локальных сетей, использующая
волоконно-оптический кабель. Скорость передачи данных — до 100 Мбит/с.
• Сеть FDDI строится на базе двух волоконно-оптических колец,
образующих основной и резервный путь передачи данных, что
обеспечивает высокую отказоустойчивость сети.
• В нормальном режиме данные передаются только по первому
кольцу, второе кольцо вообще не используется. Если по каким-либо
причинам невозможно передать данные по первому кольцу, оно (первое
кольцо) соединяется со вторым, обеспечивая единое кольцо.
• Максимальное количество станций — 500, максимальный диаметр
двойного кольца — 100 м.
3.5. Беспроводные линии GSM
Протоколы, стандарты, безопасность в сетях GSM
Пользователей GSM (пользователей мобильных телефонов) больше,
чем пользователей Интернета. Многих GSM-пользователей интересуют
два вопроса:
• Как использовать GSM-сеть для подключения компьютера к
Интернету.
• Как отправлять информацию непосредственно с мобильного
телефона в Интернет (или как просматривать web-страницы с помощью
мобильного телефона).
115

TCP/IP и DNS в теории и на практике. Полное руководство
В этом пункте мы попытаемся ответить на эти вопросы.
Стандарт GSM опубликован Европейским Телекоммуникационным
Институтом Стандартизации {European Telecommunications Standards
Institute, ETSI). Подробная информация об этом стандарте доступна на
сайте http://www.etsi.org
Система GSM покрывает территорию, разбивая ее на ячейки — соты.
Отсюда и название — сотовая связь. Каждая сота обслуживается одной
BTS (Base Transceiver Station) — базовой станцией передатчика,
попросту говоря — передатчиком. Отдельные ячейки могут пересекаться
(накладываться друг на друга), как показано на рис. 3.30. При
перемещении пользователя мобильного телефона из одной соты в другую
сота передает управление следующей соте — той, в которую
переместился пользователь.
Рис. 3.30. Территория разделена на соты
Давайте немного упростим систему, приведенную на рис. 3.30. Теперь
будем считать, что наша система выглядит как на рис. 3.31.
Чтобы работала вся система GSM, очень важно отслеживать
«координаты» пользователя. Несколько ячеек формирует область. Сеть постоянно
обновляет информацию о местонахождении пользователя. Если нужно
найти пользователя (например, для того, чтобы перенаправить ему
входящий звонок), проверяются все ячейки определенной области (в
которой до сих пор Находился пользователь).
Стандарт GSM использует две частоты:
116

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Область 1 Область 2 Область 3
Рис. 3.31. Упрощенная система областей ячеек
• Первичная частота — 900 МГЦ. Полоса пропускания — 25 МГц, то
есть диапазон от 890 до 915 МГц или от 935 до 960 МГц.
• Вторичная частота — 1800 МГц. Используются две полосы: от 1710
до 1785 МГц и от 1805 до 1880 МГц, то есть полоса пропускания в три
раза выше, чем у GSM 900 (составляет 75 МГц).
Выделенные полосы пропускания делятся на секции по 200 КГц,
использующиеся как станциями BTS, так и самими мобильными
телефонами. Теоретически, первичная частота содержит 124 частоты. Так как
две крайние обычно не используются, то у нас остается 122 частоты.
Одна ячейка может использовать 122/9 частот, то есть 13. На практике
же одну занимает BTS, а остальные (от 4 до 12) используются
мобильными телефонами.
На рис. 3.32 изображена инфраструктура GSM:
• Радио-интерфейс — используется для связи между станцией BTS
и мобильным телефоном.
• BTS (Base Transceiver Station) — станция передатчика.
• BSC (Base Station Controller) — станция, контролирующая
несколько станций BTS.
• NSS (Network and Switching System) — система, переключающая
(коммутирующая) вызовы. Каждый вызов, даже в пределах одной
соты, коммутируется системой NSS. Система NSS может передавать
117

TCP/IP и DNS в теории и на практике. Полное руководство
вызовы в другие сети; для своей работы она использует
сигнализацию SS7, которая была рассмотрена при рассмотрении технологии
ISDN. Система NSS состоит из:
♦ MSC (Mobile Services Switching Center) — центр переключения
услуг, управляющий несколькими BSC.
♦ HLR (Home Location Register) — реестр домашних абонентов,
содержащий информацию о пользователях — имя,
предоставленные сервисы и т. д., то есть базу данных. Аутентификационный
центр также является частью HLR.
♦ VLR (Visitors Location Register) — реестр активных абонентов,
содержащий базу данных посещений пользователей (данная
информация не содержится в HLR).
♦ GSMC — шлюз, на который перенаправляются все входящие вызовы.
• Network Control — центр управления сетью.
Для организации связи между BTS и мобильными телефонами
используются коммуникационные каналы. Основной канал, применяющийся
для связи, называется ТСН (Traffic Channel). Существует несколько
типов ТСН:
1. TCH/F канал (F = полная скорость).
2. ТСН/Н канал (Н = половина скорости).
3. ТСН/8 канал (1/8 возможной скорости).
в
8
8
BTS
BTS
BTS
Радио Интерфейс Интерфейс
интерфейс Abis A
Рис. 3.32. Инфраструктура GSM
118

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
Каждый из этих типов каналов ассоциируется с одним медленным
SACCH-каналом. Данный канал используется для передачи
приблизительно двух сообщений в секунду, в зависимости от типа канала — TCH/F
илиТСН/Н.
Каждая частота передачи делится на восемь слотов (то есть одна частота
может использоваться восемью пользователями). Каждый слот может
передавать один TCH/F канал, то есть голос со скоростью 13 Кбит/с
или данные со скоростью 12.6 Кбит/с.
Слот канала TCH/F также содержит SACCH-канал. Оба канала
создают один ассоциированный канал, называемый ТАСН/Е Это же касается
и канала ТСН/Н: только в данном случае создается ассоциированный
канал ТАСН/Н.
Теоретически, если не использовать сервисные каналы, можно
разделить одну частоту между восемью пользователями, то есть одна частота
будет использована для передачи восьми вызовов.
Но кроме каналов TACH/F и ТАСН/Н, которые используются для
передачи информации пользователя, сеть GSM использует несколько
сервисных каналов:
• Канал синхронизации SCH (synchronization channel) и канал
коррекции FCCH. Оба эти канала гарантируют синхронизацию в
пределах ячейки (GSM используют только синхронную связь).
• ВССН (Broadcast Control Channel) — широковещательный
управляющий канал. Каждая ячейка индицируется в этом канале. Данный
канал позволяет определить следующую ячейку при перемещении
пользователя. ВССН-канал обрабатывается мобильным телефоном,
даже если тот выключен. Это значит, что ваше месторасположение
можно определить, даже если вы выключили телефон (если же вы не
хотите, чтобы кто-то узнал о вашем месторасположении, отключите
аккумулятор вашего телефона).
• PAGCH (Paging and Access Channel) — сигнализирует о входящем
звонке в пределах определенной области.
• RACH (Random Access Channel) — используется для связи
мобильного телефона и сети (только в направлении телефон —► сеть).
Этот канал задействуется, когда пользователь мобильного телефона
хочет кому-то позвонить, то есть при создании исходящего вызова.
Поскольку данный канал использует случайный доступ, могут
возникнуть коллизии.
119

TCP/IP и DNS в теории и на практике. Полное руководство
♦ СВСН (Cell Broadcast Channel) — канал используется
неактивными телефонами: по этому каналу телефоны
отправляют сообщения (приблизительно 80 байтов) каждые
две минуты, информируя сеть о своей готовности.
Сервисные каналы FCCH, SCH, ВССН и PGCH являются частью
одного канала TACH/F (занимают часть его полосы).
Как мы уже знаем, соты сети GSM обслуживаются станцией BTS,
которая может содержать 1, 4 или 12 передатчиков. В соте (ячейке)
используется следующая установка каналов:
• Для 1-го передатчика (8 слотов):
♦ 1 слот для каналов FCCH, SCH, ВССН, PAGCH, RACH и 4х
ТАСН/8,.
♦ 7 слотов для TACH/F, то есть одна ячейка может обслуживать
одновременно 7 вызовов.
• Для 4-х передатчиков (всего 4 х 8 = 32 слота):
♦ 1 слот для каналов FCCH, SCH, ВССН, PAGCH, RACH.
♦ 2 слота для 8х ТАСН/8.
♦ 29 слотов для TACH/F, то есть одна ячейка может обслуживать
одновременно 29 вызовов.
• Для 12-ти передатчиков:
♦ 1 слот для каналов FCCH, SCH, ВССН, PAGCH, RACH.
♦ 5 слотов для 8х ТАСН/8.
♦ 87 слотов для TACH/F, то есть одна ячейка может обслуживать
одновременно 87 вызовов.
Подключение компьютера к Интернету через сеть GSM
Один из возможных способов подключения к Интернету через сеть GSM
заключается в использовании сервисов GSM для передачи данных. При
этом задействуется канал TCH/F
Мобильный телефон подключается к компьютеру с помощью адаптера
RA-0, который является частью мобильного телефона или компьютера.
Данный адаптер преобразует асинхронный сигнал (9.6 Кбит/с) в
синхронный (12.6 Кбит/с), который будет передаваться по каналу ТСН/Е
120

Глава 3. Физический уровень — канал передачи данных, безопасность, стандарты
На рис. 3.33 показано, как компьютер подключается к адаптеру RA-0
(Rate Adaptation 0) через асинхронный СОМ-порт. Адаптер
преобразует асинхронный сигнал в синхронный, который будет передан
мобильным телефоном через BTS другому специальному модулю сети
GSM — устройству TRAU (Transcoder/Rate Adapter Unit).
Адаптер RA-0 заполняет канал незначительными колебаниями для
достижения скорости 8 Кбит/с или 16 Кбит/с. Модуль TRAU также
добавляет в полученный канал колебания — для достижения скорости
64 Кбит/с. Такой сигнал может быть обработан обычными
телефонными станциями.
Затем сигнал из NSS попадает как один из В-каналов ISDN на
маршрутизатор интернет-провайдера. Провайдер обычно подключен к NSS по
линии Е1 или ЕЗ, поэтому одновременно к Интернету могут
подключиться несколько пользователей.
После установки канала для передачи данных из сети GSM в Интернет
все происходит как обычно: пользователь будет работать по протоколу
РРР, который используется, в том числе, и для аутентификации
пользователя.
RA-0
8
BTS
BSC
TRAU
9,6
асин.
12,6 Кбит/с синх. 64 Кбит/с синх. ISDN В-канал в Е1
Протокол РРР
М -
маршрутизатор
Рис. 3.33. Использование мобильного телефона
для подключения компьютера к Интернету
121

TCP/IP и DNS в теории и на практике. Полное руководство
GPRS (General Packet Radio Service) —
HE ПУТАТЬ С ГЛОБАЛЬНЫМ ПОЗИЦИОНИРОВАНИЕМ
Описанный способ подключения к Интернету имеет два основных
недостатка:
• Очень низкая скорость передачи данных — 9.6 Кбит/с.
• Требуется время для установки соединения. Стоимость мобильной
связи все еще очень высока, поэтому вы после загрузки страницы,
вероятно, будете разрывать соединение, чтобы не платить за время в
Интернете, которое не используется (пока вы, например, читаете
какую-то страницу). Для просмотра следующей страницы, вам нужно
будет вновь устанавливать соединение, а это займет больше
времени, чем обычное dial-up-соединение по телефонной сети.
Оба эти недостатка исправляются технологией GPRS (General Packet
Radio Service). Эта технология не предусматривает установку
виртуального соединения, а использует передачу пакетов. Мобильный телефон
постоянно подключен к сети — это и есть основное преимущество.
Технологию GPRS можно сравнить с подключением компьютера по
локальной сети. При ее использовании пакеты сразу отправляются
маршрутизатором, и нам не нужно ждать, пока установится соединение, как
в случае с dial-up-подключением.
Рис. 3.34. GRPS — сеть в пределах GSM-сети
Теоретически, GPRS могут обслуживать 8 слотов передачи данных со
скоростью 171.2 Кбит/с. На практике используются 4 слота со средней
скоростью 28 Кбит/с. В будущем планируется скорость 112 Кбит/с.
(см. http: //www.gsmworld. com).

Глава 4
КАНАЛЬНЫЙ УРОВЕНЬ.
ПРОТОКОЛЫ, СТАНДАРТЫ,
БЕЗОПАСНОСТЬ
ПРОТОКОЛ SLIP
CSLIP — УСОВЕРШЕНСТВОВАННЫЙ
SLIP
j ПРОТОКОЛ HDLC — ОТЕЦ РРР
ПРОТОКОЛ РРР (POINT-TO-POINT
PROTOCOL) - САМОЕ
РАСПРОСТРАНЕННОЕ РЕШЕНИЕ
FRAME RELAY —
ПРОТОКОЛ КАНАЛЬНОГО УРОВНЯ
ДЛЯ ГЛОБАЛЬНЫХ СЕТЕЙ
ЛОКАЛЬНАЯ СЕТЬ
(LOCAL AREA NETWORKS, LAN)
И ПРОТОКОЛ ETHERNET
БЕСПРОВОДНЫЕ ЛОКАЛЬНЫЕ СЕТИ
(WIRELESS LOCAL AREA NETWORKS,
WLAN)
TCP/IP и DNS в теории и на практике. Полное руководство

На канальном уровне работает очень много протоколов. Мы
рассмотрим следующие из них: SLIP (Serial Line Internet Protocol), CSLIP
(Compressed SLIP), HDLC (High-level data link control), PPP (Point-to-
Point Protocol), Frame Relay и Ethernet.
4.1. Протокол SLIP
Serial Line Internet Protocol (далее SLIP) был первым протоколом,
позволяющим устройствам, подключенным к последовательным
интерфейсам, работать по протоколу TCP/IP. Очень простой протокол
SLIP, использующийся для передачи пакетов сетевого уровня, описан
bRFC-1055.
Данный протокол помещает IP-пакеты прямо в последовательную
линию. Единственная его задача -<- распознать начало и конец пакета в
потоке битов, который поступает по последовательной линии.
END
^я
сО
ESC
db
IP
-пакет
dc
db
\
ESC
db
dd
\. END
^Я
Рис. 4.1. Кадр протокола SLIP

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Для распознавания границ IP-пакета протокол SLIP использует
специальный символ END (код в шестнадцатеричной системе с016). Но в этом
случае байт со значением с016 будет ошибочно принят за конец пакета.
Для решения этой возможной проблемы байт данных со значением с016
заменяется двухбайтовой последовательностью, которая состоит из
символа ESC (DB) и кода DC. Если байт данных имеет значение ESC, то
он заменяется последовательностью ESC и DD. После заключительного
байта пакета передается байт END.
Протокол SLIP не гарантирует:
• Обнаружение ошибок во время передачи данных — для
обнаружения ошибок рекомендуется использовать уровень модема, то есть
протокол V.42, который обеспечивает обнаружение и коррекцию
ошибок. IP-протокол содержит контрольную сумму только в
заголовках пакетов. Контрольная сумма для протокола UDP
необязательна, поэтому очень не рекомендуется передавать по протоколу
SLIP пакеты серверов DNS и NFS, которые не помещают
контрольные суммы в дейтаграммы UDP.
• Индикацию типа протокола, который инкапсулируется в SLIP-
пакет — по этой причине по SLIP-линии могут передаваться
только пакеты протокола IP. Пакеты других протоколов передавать по
SLIP-линии нельзя.
Еще к недостаткам SLIP можно отнести следующее:
• невозможность передачи конфигурационных параметров сторон
(например, IP-адреса и другой информации);
• невозможность использования синхронных линий.
Единственное преимущество SLIP — легкость настройки. Но, поскольку
он не обеспечивает коррекцию ошибок, его можно использовать только
на медленных последовательных линиях с хорошим качеством.
Приходится констатировать, что протокол SLIP устарел, и в последнее
время вообще не используется. Вместо него все провайдеры давно уже
перешли на более мощный протокол РРР, который будет рассмотрен
позже.
125

TCP/IP и DNS в теории и на практике. Полное руководство
4.2. CSLIP — усовершенствованный SLIP
ПОЯВИЛОСЬ СЖАТИЕ ЗАГОЛОВКОВ
Протокол CSLIP (Compressed SLIP) — это усовершенствованный
вариант протокола SLIP с поддержкой сжатия. Протокол CSLIP описан
bRFC-1144.
Предпосылкой появления данного протокола послужила низкая
пропускная способность последовательных линий. А использование сжатия
позволило увеличить количество передаваемой информации при той же
скорости.
Рис. 4.2. Протокол РРР также поддерживает сжатие заголовков
(Windows 2000, Windows XP)
126

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
При использовании многих программ (например, того же telnet)
приходится передавать 20-байтовый заголовок IP-пакета и 20-байтовый
заголовок TCP-пакета. Протокол CSLIP сжимает заголовки пакета, экономя на
этом от 24-х до 37-ти байтов, то есть после сжатия наши заголовки «весят»
от 3-х до 16-ти байтов. Передаваемые данные при этом не сжимаются.
Точно такое же сжатие TCP- и IP-заголовков используется протоколом
РРР. Только в отличие от протокола CSLIP, где обе стороны должны
быть соответствующим образом сконфигурированы заранее, при
использовании РРР обе стороны соединения договариваются об
использовании сжатия во время соединения (рис. 4.2).
Когда мы говорим о сжатии заголовков, слово «сжатие» не должно
вводить нас в заблуждение: речь идет не об обычном сжатии, к которому мы
привыкли при использовании архиваторов, скажем, программы ZIP.
Очень простая и понятная, как все гениальное, идея сжатия заголовков
пакета принадлежит Вану Якобсону (Van Jacobson). Она сводится к
следующему: в заголовках есть очень много информации, которая
практически не изменяется (или изменяется совсем немного). Поэтому
передаваться будут только измененные заголовки.
0 8 16 24 31
Версия IP
4 бита
Длина
заголовка
Класс обслуживания
8 бит
Идентификация IP-пакета
| 16 бит
TTL (Time to Live)
| 8 бит
Протокол
8 бит
Общая длина IP-пакета
16 бит
Флаги
Смещение фрагмента
13 бит
Контрольная сумма (checksum) заголовка
16 бит
IP-адрес отправителя
| 32 бита
IP-адрес получателя
| 32 бита
Порт отправителя
16 бит
Порт получателя
16 бит
Порядковый номер отправленного байта (sequence number)
32 бита
Порядковый номер принятого байта (acknowledgment number)
32 бита
Trailer Length
4 бита
Резерв
6 бит
и
R
G
А
С
К
Р
S
н
R
S
т
S
Y
N
F
I
N
Контрольная сумма TCP
16 бит
Размер окна
Указатель срочности (urgent pointer)
16 бит
Рис. 4.3. Заголовки IP и TCP
127

TCP/IP и DNS в теории и на практике. Полное руководство
На практике изменяются только несколько заголовков (адреса
отправителя/получателя, размер окна, контрольная сумма ТСР-заголовка
и др.), все остальные остаются неизменными. Некоторые заголовки
(контрольная сумма и общая длина IP-дейтаграммы) вообще не нужны
(необязательны).
Проще говоря, сжатие заголовка — это просто удаление из него
ненужной в данный момент информации. Сжатие используется только для
заголовков TCP/IP; если используется другой протокол (ICMP-пакет,
UDP-дейтаграмма или же установлены атрибуты RST, SYN, FIN), пакет
будет передан без сжатия.
Как происходит сжатие на практике
При отправке TCP/IP-пакета он изначально передается адресантом
(отправителем) компрессору (см. рис. 4.4). Компрессор может или сжать
пакет, или же оставить его без изменения. Затем пакет передается по
линии связи. Другая сторона (получатель, адресат) пакет получает опять-
таки через компрессор, который на этот раз выполняет функцию
декомпрессии, то есть «распаковывает» оригинальный заголовок.
Компрессор отправителя сжимает отдельные потоки данных (отдельные
соединения). Каждое соединение хранится в слоте, в котором находится
вся информация о заголовках TCP/IP, необходимая для сжатия и
декомпрессии, то есть реконструкции обоих (ТРС и IP) заголовков.
Uwl^HMHMBy
1 пакет
lompei
М 1
Слоты (0-255) *) 1
II 1
иггель
Линия
чЦЯННЩ^^Н пакет 1
it 1
Г Слоты (0-255)
II 1
Получ
1атель 1
Рис. 4.4. Компрессор и декомпрессор
128

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Давайте рассмотрим, что происходит, когда пакет отправителя
передается компрессору. В этом случае компрессор первым делом анализирует,
можно этот пакет сжать или нет. Если пакет не может быть сжат (ICMP-
пакет, UDP-дейтаграмма, установлены атрибуты SYN, RST и др.),
сжатие на этом завершается и несжатый пакет передается по линии связи.
В противном случае (то есть если пакет подлежит сжатию) компрессор
начинает искать его слот данных IP + TCP, в который можно поместить
пакет.
На этом этапе может произойти одна из двух ситуаций:
1. Соответствующий IP + TCP заголовок не найден ни в одном из
слотов. Это первый пакет нового соединения. У самого первого пакета
нового соединения установлен атрибут SYN, и поэтому он не может
быть сжат. Компрессор должен выделить для нового соединения
новый слот. Выбирается первый свободный слот. Если нет свободных
слотов (их число ограничено — всего 256), компрессор выбирает
слот, который давно не использовался. Компрессор не сжимает этот
пакет, только изменяет значение 6 (для протокола TCP) поля
Протокол (Protocol) на номер выбранного слота.
2. Компрессор нашел слот, соответствующий заголовкам IP + TCP.
Пакет будет сжат.
Структура сжатого пакета представлена на рис. 4.5 (необязательные
элементы выделены пунктиром). TCP и IP-заголовки сжаты, сжатие не
касается данных.
Байт О
1
2
3
Номер слота (номер соединения) - N
Контрольная сумма TCP
Указатель срочности - U
Прирост размера окна - W
Прирост номера принятого байта - А
Прирост номера отпр. байта - S
Прирост идентификатора пакета -I
Рис. 4.5. Сжатый заголовок
5 Заж.518
129

TCP/IP и DNS в теории и на практике. Полное руководство
Первый байт сжатого заголовка содержит так называемую маску.
Отдельные биты в маске указывают, какие поля исходного пакета были
изменены. Именно поэтому некоторые поля должны быть переданы полностью
или в виде приростов (инкрементов) как часть сжатого заголовка.
В заголовок включается измененное поле (или его прирост), и
устанавливается соответствующий ему флаг. Если элемент не включается в
заголовок, то соответствующий ему флаг не устанавливается. Контрольная
сумма заголовка TCP всегда включается в заголовок.
Биты маски:
• Номер — предназначен для номера слота (номера соединения).
Номер слота не является обязательным элементом. Если он не указан,
то считается, что он такой же, как у предыдущего полученного
пакета. Длина данного поля составляет один байт: этого достаточно,
чтобы передать номер слота (0-255). Теперь ясно, почему
одновременно могут быть сжаты только 255 соединений — резервирование
для номера слота даже двух байтов себя бы не оправдало, так как при
сжатии мы экономим каждый байт.
• U — указатель срочности (urgent pointer). При отправке срочных
данных (что указано в поле Флаг (Flag)) в этом поле содержится
длина срочных данных.
• W — прирост размера окна. Чтобы не передавать полное значение
окна, передается только его прирост (инкремент). Если инкремент
отрицательный или превышает 65536 (то есть 2 байта), пакет не
сжимается. Это также касается битов A,S и I.
• А — прирост номера принятого байта (поле acknowledgement
number).
• S — прирост номера отправленного байта (поле sequence number).
• I — прирост идентификации пакета.
• Р — флаг PUSH. Данный бит не связан с каким-либо элементом
(полем) в сжатом заголовке пакета; он устанавливается, если
установлен флаг PUSH в TCP-заголовке исходного пакета.
Можно предположить, что размер каждого поля сжатого заголовка не
должен превышать 1 байт, то есть его значения лежат в диапазоне 0-255.
В целях уменьшения размера могут передаваться не целые значения,
а только их приросты. И еще сжатые заголовки никогда не передают нуле-
130

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
вые значения элементов. То есть, если прироста нет, то вместо включения
в заголовок поля, сообщающего «прирост поля = 0», данные поля вообще
не включаются в заголовок (их бит в маске не устанавливается).
Несмотря на то, что TCP-соединение двунаправлено (используется
полный дуплекс), сжатие заголовков IP и TCP полностью независимо
от направления передачи данных.
Если заголовок содержит одновременно установленные флаги A, W и U,
то пакет передается несжатым; исключение составляют протоколы
telnet, rlogin и некоторые другие.
Сжатые заголовки этих протоколов содержат только флаги A, W, U
и контрольную сумму, то есть сжатый заголовок занимает всего 3
байта. В этом случае для передачи кода нажатой клавиши требуется всего
4 байта вместо 41 (3 байта для заголовка и 1 для данных). Более
подробно этот процесс описан в RFC-1144.
В настоящее время сжатие заголовка IP улучшено до такой степени, что
можно сжимать протоколы, отличные от TCP (UDP или IPv6). С новой
спецификацией вы можете ознакомиться в RFC-2507 - 2509.
4.3. Протокол HDLC — отец РРР
4.3.1. Описание и режимы работы протокола
Протокол HDLC (High level Data Link Control — высокоуровневый
протокол управления каналом) предоставляет обнаружение ошибок и
управление потоком данных. Протокол стандартизирован ISO: ISO-3309,
ISO-4335, ISO-7776, ISO-7809, ISO-8471 и ISO-8885.
HDLC происходит от протокола SDLC, разработанного компанией IBM,
но поддерживает не все функции своего «предка». Протокол SDLC
использовался для синхронной передачи данных. В настоящее время он
является одним из протоколов семейства.
В протокол HDLC добавлена поддержка асинхронных функций.
Разницу между синхронным и асинхронным режимом HDLC мы опишем
на примере протокола РРР, который происходит от HDLC и обычно
используется на асинхронных линиях.
Протокол HDLC работает в следующих режимах (в основном
актуальны первые два):
131

TCP/IP и DNS в теории и на практике. Полное руководство
• ABM (Asynchronous Balanced Mode) — асинхронный
сбалансированный режим. Используется для полнодуплексного соединения
двух станций (обе станции могут передавать данные одновременно).
Это наиболее применяемый в настоящее время режим.
• NRM (Normal Response Mode) — нормальный режим ответа.
Данный режим подобен протоколу SDLC. Он используется для
полудуплексного соединения нескольких станций (отдельно прием,
отдельно передача). Для передачи и приема данных используется общая
среда передачи данных. Одна станция является управляющей,
остальные — подчиненными. Управляющая станция может передавать
данные без разрешения, подчиненные могут начать передачу лишь
с разрешения управляющей. Разрешение на передачу — это
установленный P/F бит в управляющем поле HDLC-кадра. Только
управляющая станция может отдавать команды — остальные станции
отправляют только ответы (они отвечают управляющей станции).
Данный режим редко используется в Интернете, поэтому мы не
будем его подробно рассматривать.
• ARM (Asynchronous Response Mode) — асинхронный режим
ответа; в настоящее время практически не используется.
Сбалансированный режим (АВМ)
Станция
Станция
Нормальный режим (NRM)
Станция
i
у
к >
'
Подч.
станция
1
к
f
Подч.
станция
Рис. 4.6. Режимы HDLC
4.3.2. Формат кадра HDLC
Формат кадра HDLC изображен на рис. 4.7. Далее в этом разделе мы
подробнее остановимся на рассмотрении отдельных полей.
132

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Заголовок
^^^^^И Адрес
Управляющее поле
\}и Данные^ ' -
«Хвост»
Контрольная сумма ^^^^^И
Рис. 4.7. Формат кадра HDLC
Поле Флаг
Поле Флаг (Flag) обозначает границы HDLC-кадра: каждый HDLC-
кадр начинается и заканчивается полем Флаг (Flag). Сразу два флага
(один за другим), определяют пустой кадр, который не обрабатывается.
Флаг формируется восемью битами: 0111 1110 — шесть единиц между
двумя нулями. Но что делать, если нам нужно передать
последовательность 0111 1110, которая совпадает с флагом? Протокол HDLC решает
эту проблему путем включения в поток выходных данных 0 после пяти
подряд идущих единиц, встретившихся в любом месте между
начальным и конечным флагами кадра. Это называется битовым наполнением
или вставкой бита (bit staffing).
Данная техника возможна только в бит-ориентированной передаче,
когда мы передаем последовательность битов. В
символьно-ориентированной передаче такой способ работать не будет, потому что количество
битов должно делиться на длину символа (обычно 7 или 8 битов).
Добавление дополнительного бита нарушило бы данное правило.
Поле адреса
Поле адреса (см. рис. 4.7) содержит адрес станции, на которую нужно
передать пакет. Длина данного поля — 8 битов. Очевидно, что это поле
используется только в NRM-режиме (или в протоколе SDLC), когда
данными обмениваются несколько станций, но оно присутствует во всех
модификациях протокола HDLC.
Протокол РРР использует данное поле для широковещания (значение
поля 1111 1111). Поле адреса протокола HDLC не имеет ничего общего
с IP-адресом, так как это адрес связи.
Контрольная сумма (Checksum)
Для вычисления контрольной суммы используются передаваемые данные,
адрес и управляющее поле. Длина контрольной суммы 32 или 16 битов.
133

TCP/IP и DNS в теории и на практике. Полное руководство
Получатель также вычисляет контрольную сумму входящего кадра
и сравнивает ее с контрольной суммой полученного кадра. Если они
совпадают, можно предположить, что принятый кадр передан корректно
(без повреждений). В противном случае получатель просит отправителя
повторить отправку кадра.
Поле данных и тип передаваемого протокола
Поле Данные (Data) содержит передаваемые данные. Обратите
внимание, что заголовок HDLC-кадра не содержит поля, в котором бы
содержался номер протокола высшего уровня. Данный факт не позволяет
смешивать различные протоколы, например, IP и IPX.
Мы должны использовать только один протокол для передачи его
данных по протоколу HDLC. Однако существует способ смешивания
разных протоколов. Выбор протокола происходит при инициализации
HDLC-соединения.
Можно указать спецификацию протокола в начале поля данных
непронумерованных кадров, позволяя одновременно использовать разные
протоколы (см. далее).
Управляющее поле
Управляющее поле (Control Field) является самым сложным полем
в HDLC-кадре. По первым (младшим) двум битам этого поля
определяется тип HDLC-кадра:
• Информационный кадр (I-frame, 1-кадр) — используется для
передачи данных. Также может содержать управляющую информацию
в своем управляющем поле (например, подтверждение о получении
кадра). Первые два бита управляющего поля равны 00.
• Непронумерованный кадр (U-frame, U-кадр) — используется
многими управляющими функциями (инициализационный диалог,
управление линией, диагностика и т. д.). Может содержать
определенные данные. Первые два бита —11.
• Супер-кадр (S-frame, S-кадр) — используется для управления
потоком данных (отправкой запроса, подтверждением I-кадра и т. д.).
S-кадры используются после инициализации соединения. S-кадры
не содержат данных. Первые два бита — 10.
134

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Управляющее поле U-кадров не превышает 8 битов, а управляющее поле
I- и S-кадров может занимать 8 или 16 битов (так называемый
расширенный режим). Режимы АВМ и NRM используют 8-битовые
управляющие поля. 16-битовые поля используются расширенными режимами
ABMEhNRME.
За счет чего достигается экономия целых 8 битов в обычном
управляющем поле? Для использующихся при нумерации кадров полей N(S)
hN(R) задействуются всего 3 бита, которые позволяют пронумеровать
8 кадров (23). В расширенном режиме можно пронумеровать 128 кадров
(27), для нумерации используется только 7 битов, поскольку один бит
является битом P/F.
-< 16 бИТ : >•
I I I I
N(R)
I I I I
I
...L .
р
/
F
МММ
N(S)
I I I I I I I
Младший бит
Рис. 4.8. Поля N(S) и N(R)
4.3.3. Типы HDLC-кадров, их особенности и назначение
Информационный кадр (I-frame, I-кадр)
Поля N(S) и N(R) в I-кадре используются для нумерации кадров.
Нумерация производится от 0 до 127. Когда значение достигает 127, счетчик
обнуляется, и нумерация начинается снова. N(S) — это счетчик
отправленных кадров, a N(R) — счетчик принятых кадров.
Для подтверждения получения данных используется S-кадр (команда
RR). Если полученный кадр поврежден, и нужно повторить передачу
кадра, в S-кадре отправляется команда REJ — так называемое
отрицательное подтверждение. В S-кадре указывается номер последнего
корректно принятого кадра (поле N(R)).
Можно подтверждать кадр за кадром. Но это требует дополнительного
времени, поскольку отправитель должен дождаться от получателя
подтверждения о приеме текущего кадра перед отправлением следующего.
Для экономии времени используются окна, то есть отправляется
несколько кадров друг за другом без подтверждения. Сколько именно —
зависит от размера окна.
135

TCP/IP и DNS в теории и на практике. Полное руководство
Предположим, что размер нашего окна равен трем (см. рис. 4.9). После
отправления трех пакетов мы ожидаем подтверждения первого пакета.
После подтверждения первого кадра, отправляется четвертый кадр,
затем мы ждем подтверждения второго кадра, после чего отправляем
пятый кадр и т. д. В буфере отправителя хранится окно неподтвержденных
кадров, чтобы можно было отправить кадр в случае его повреждения
или потери.
Очень важным для режима NRM является бит P/F. Управляющая
станция в режиме NRM позволяет подчиненным станциям передавать
данные установкой этого бита в Р (Pool). Если подчиненная станция не
сбрасывает бит P/F на протяжении передачи, значит, она хочет
продолжить передачу. После последнего переданного кадра данный бит
устанавливается в F (Final).
N(S)=0 ►
N(S)=1 ►
N(S)=2 ►
^ N(R)=0
N(S)=3 ►
*< N(R)=1
N(S)=4 ►
Рис. 4.9. Передача и подтверждение кадров
Суперкадр (S-frame, S-кадр)
Суперкадр (S-кадр; см. рис. 4.10) используется для подтверждения
принятого кадра. Поле команды может содержать следующие команды (или
ответы):
• RR (Receiver Ready) — информирует другую сторону о том, что
приемник готов принять I-кадры (то есть «линия свободна для
передачи»), также данная команда может использоваться для
подтверждения корректной передачи кадра («кадр получен без ошибок»).
• RNR (Receiver Not Ready) — сообщает, что приемник временно не
способен принять I-кадры, и подтверждает кадры, полученные до
этого момента.
• REJ (Reject) — принят поврежденный кадр, требуется повторная
отправка.
136

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
-^ 16 бит ►
К - команда Младший бит
Рис. 4.10. Суперкадр (S-кадр)
Непронумерованный кадр (U-frame, U-кадр)
Непронумерованные U-кадры (см. рис. 4.11) используются как для
передачи данных, так и для следующих команд:
• SABM (Set Asynchronous Balanced Mode) — команда,
устанавливающая режим ABM с 8-битовым управляющим полем.
• SABME (Set Asynchronous Balanced Mode Extended) — команда,
устанавливающая расширенный режим ABM с 16-битовым
управляющим полем.
• SNRM (Set Normal Response Mode) — команда, устанавливающая
режим NRM с 8-битовым управляющим полем.
• SNRME (Set Normal Response Mode Extended) — команда,
устанавливающая расширенный режим NRM с 16-битовым управляющим
полем.
• UA (Unnumbered Acknowledgement) — используется для
подтверждения SABM, SABME, SNRM, SNRME и DISC.
• DISC (Disconnect) — отключение.
• DM (Disconnect Mode) — положительное подтверждение DISC.
• FRMR (Frame Reject) — используется для индикации входящего
поврежденного кадра. После получения FRMR начинается
установка линии одной из команд: SABM, SABME, SNRM или SNRME.
Первые 2-3 байта поля данных содержат код ошибки.
• XID (Exchange Station Identification) — расширенная
идентификация станции — используется для первичной инициализации, когда
станции договариваются о том, как они будут общаться: какой будет
длина контрольной суммы, какой будет использоваться протокол
высшего уровня и т. д.
137

TCP/IP и DNS в теории и на практике. Полное руководство
UI (Unnumbered Information) — используется для передачи
непронумерованных кадров данных. Эти кадры могут содержать
спецификацию протокола в начале поля данных, позволяя смешивать разные
протоколы (например, IP и IPX) на одной линии.
■ 8 бит ■
1 1
к
1 1
р
/
F
т-|
и
К - команда |
Младший бит
Рис. 4.11 ^Непронумерованный кадр (U-кадр)
4.3.4. Обобщенная информация о протоколе HDLC
HDLC — это высокоуровневый протокол управления линией (см. рис. 4.12),
позволяющий:
• проверять поврежденные кадры с помощью контрольных сумм;
• при получении поврежденного кадра отправлять запрос на его
повторную передачу;
Line Set:
Line Disconnect:
Line Reset:
SABM -
DI6C -
FRMR -
UA -
-<-
-►
- UA
- SABM
Рис. 4.12. Диалог по протоколу HDLC
• с помощью непронумерованных кадров смешивать несколько
сетевых протоколов на одной линии.
Линия протокола HDLC может находиться в следующих состояниях:
• Офф-лайн (off line) — полностью отключена.
138

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
• Состояние установки линии с использованием только U-кадров.
• Состояние передачи данных с использованием только I- и S-кадров
(U-кадры не используются для передачи данных).
• Состояние отключения с передачей только U-кадров.
4.4. Протокол РРР (Point-to-Point Protocol) —
самое распространенное решение
4.4.1. Общее описание
Основные функции РРР
Рано или поздно каждый интернет-пользователь столкнется с
протоколом РРР. Данный протокол используется для подключения компьютера
к Интернету по коммутируемому соединению (dial-up). РРР-кадры
подобны кадрам протокола HDLC, рассмотренного выше; однако данные
протоколы отличаются ассортиментом функций: РРР предоставляет не
все функции, предоставляемые протоколом HDLC, зато добавляет свои
собственные.
Основные функции РРР:
• На физическом уровне данный протокол можно использовать с
интерфейсами, соответствующими рекомендациям V.24, V.35. Протокол
не требует управляющих сигналов (RTS, CTS, DCD, DTR и т. д.),
однако они могут использоваться для расширения его эффективности.
• Протокол поддерживает асинхронную и синхронную (бит/символ)
передачи данных.
• Для асинхронной передачи используется 1 старт-бит, 8 битов
данных и 1 стоп-бит (без проверки четности).
• Протокол требует полнодуплексной выделенной или
коммутируемой (dial-up) линии.
• Для обнаружения поврежденных во время передачи кадров
используются 16- или 32-битовые контрольные суммы.
• Задача протокола РРР состоит в передаче нескольких сетевых
протоколов по одной линии (то есть протокол позволяет смешивать
себе подобные). Протокол использует не I-кадры, а только U-кадры,
поэтому нумерация и повтор поврежденных кадров невозможны.
139

TCP/IP и DNS в теории и на практике. Полное руководство
• Тип сетевого протокола помещается в начало поля данных
передаваемого кадра (идентификатор протокола может занимать 8 или
16 битов).
Протокол РРР описан в RFC-1661, а формат кадров РРР — в RFC-
1662.
Формат РРР-кадра
На рис. 4.13 изображена структура РРР-кадра (поле Протокол
(Protocol) используется для передачи типа протокола).
Заголовок
«Хвост»
Адрес Управляющее поле Протокол
Данные' Контрольная сумма
1бит
с021
с023
' - ""PAP ' * *'
8053
t ECP ; v :
8021
, Л|РСР ->;v
0021
^IP-пакет
s i
Рис. 4.13. РРР-кадр
Примечание.
Кадры протокола РРР могут инкапсулироваться в кадры HDLC, Frame
Relay, Ethernet (см. RGC-2516).
Давайте рассмотрим HDLC-инкапсуляцию. РРР-кадры содержат
значение ff1(. (broadcast) в поле адреса и всегда значение 0316 в управляющем
поле (U-кадр с установленным в 0 битом P/F). Если на линии только
кадры с этими значениями полей: Адрес (Address) и Управляющее поле
(Control Field), то обе стороны могут использовать сжатие этих полей
Address-and-Control-Field-Compression. При использовании данного вида
сжатия управляющее поле и поле адреса могут просто не передаваться.
140

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Поле Флаг (Flag), как и в случае с HDLC, задает границы кадра. Флаг
содержит значение 0111 1110, то есть 7е16 Но что делать, если нужно
передать байт с таким значением? На синхронной линии можно
использовать описанную выше технологию вставки битов {bit stuffing).
На асинхронных линиях (а также при использовании посимвольной
передачи по синхронной линии) должны использоваться ESC-последова-
тельности. Символ с кодом 7et6 будет заменен последовательностью 7d
5е16. А сам символ 7d16 заменяется последовательностью 7d 5d16.
Протоколы — составляющие РРР
В состав протокола РРР входят пять сервисных (служебных)
протоколов:
• LCP — протокол установки соединения.
• Протоколы аутентификации (PAP, CHAP, EAP и др.).
• Протоколы для реализации возможности обратного звонка
(callback).
• Дополнительные протоколы: кодирования, сжатия данных, Multilink-
протокол и т. д.
• Группа NCP. Каждый сетевой протокол, использующий протокол
РРР, имеет свой NCP-стандарт. Номер протокола всегда задается
в поле Протокол (Protocol) РРР-кадра. Некоторые NCP-протоколы:
♦ IPCP (номер протокола 80211б) — один из вариантов NCP для
протокола IP версии 4. Описан в RFC-1332. Кадры данных
содержат значение 002116 (в поле Протокол (Protocol)).
♦ IPV6CP (номер протокола 805716) — версия NCP для протокола
IPv6. Кадры данных, переданные протоколом IPv6, используют
номер протокола 005716
♦ SNACP (номер протокола 804d16) - NCP для IBM SNA (RFC-2043).
Номер протокола кадров данных — 004d16
♦ DNCP (номер протокола 802716) - NCP для DECnet Pahse IV
(RFC-1762). Номер протокола кадров данных — 002716
♦ IPXCP (номер протокола 802b16) - NCP для IPX (RFC-1552).
Номер протокола кадров данных — 002Ь16
141

TCP/IP и DNS в теории и на практике. Полное руководство
OSINLCP (номер протокола 80231(.) — NCP для протоколов OSI,
например, протоколов ES-IS, IS-IS и т. д. (RFC-1377). Номер
протокола кадров данных — 0023 f
4.4.2. Набор номера по телефонной линии «изнутри» —
с точки зрения РРР
Перед обзором отдельных протоколов семейства РРР давайте
рассмотрим набор номера. Чаще всего проблемы возникают именно на этом
этапе — еще до установки РРР-соединения.
В Windows (да и в других операционных системах) мы можем открыть
окно терминала:
• До набора номера. Пользователь может ввести АТ-команду,
управляющую модемом. Например, команду набора номера ATDP12345678,
предусматривающую набор номера «вручную». В данном режиме
предоставляется возможность «наблюдать» за тем, как модем
выполняет введенные команды.
• После набора номера. Соединение уже установлено, и оба модема
(с двух сторон) уже переключены в режим данных. Здесь возможны
две ситуации:
1. Другая сторона ожидает только протокол РРР. Протокол РРР
будет использоваться как для аутентификации пользователя, так
и для дальнейшей установки соединения. Наиболее разумное
решение в этом случае — закрыть окно терминала. После закрытия
окна терминала наши стороны продолжат «общение» по
протоколу РРР.
2. Другая сторона выведет терминальный диалог для входа в сеть.
Обычно такое происходит при подключении к серверу с
терминальным способом аутентификации (CISCO-маршрутизатор,
UNIX-сервер). Вам будет предложено ввести имя пользователя
и пароль. Будем считать, что вы указали их правильно. Опять
возможны два варианта:
• Вы продолжите работать в терминальном режиме: сможете
вводить команды, которые будут выполнены на удаленном
сервере, а вам будет передан только результат их работы. Вы
сможете работать как обычный пользователь этого сервера,
комфортность вашей работы будет зависеть от скорости и ка-
142

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
чества используемой вами линии. В этом случае выйти из
системы можно с помощью команд exit или logout, или просто
закрыв окно терминала.
• После введения правильного имени пользователя и пароля
будет установлено РРР-соединение. Вы не сможете работать
интерактивно, зато ваши сетевые программы используют это
соединение для передачи данных (например, вы
подключитесь к Интернету и получите возможность принимать и
отправлять данные).
В Windows 2000/XP установить опцию Отображать окно терминала
после набора номера можно в окне конфигурации коммутируемого
(dial-up) соединения (см. рис. 4.17).
4.4.3. Протокол LCP — ответственный
ЗА УПРАВЛЕНИЕ СВЯЗЬЮ В РРР
Назначение протокола LCP. Выбор алгоритма аутентификации
В соответствии с протоколом управления связью LCP (Link Control
Protocol) принимаются параметры соединения. Также в обязанности
этого протокола входит установка соединения, его завершение
(отключение), выбор алгоритма аутентификации и т. д.
Protocol UP
Protocol UP
Protocol UP
Рис. 4.14. Отдельные этапы связи в РРР
143

TCP/IP и DNS в теории и на практике. Полное руководство
Как показано на рис. 4.14, работа с линией состоит из четырех основных
этапов: установки соединения, аутентификации, передачи сетевого
протокола и .отключения.
Отключение — это начало и конец сеанса вашей работы с соединением
(имеется в виду состояние линии). В случае возникновения
какого-нибудь внешнего события (например, потери соединения, произошедшей
спонтанно или по воле администратора сети) линия переключается
в фазу Отключения.
Следующая фаза — Установка соединения. Соединение
устанавливается с помощью обмена конфигурационными пакетами. Во время этой
фазы не передаются пакеты с данными. Цель данной фазы — установка
соединения между двумя модемами.
Аутентификация — это фаза, во время которой происходит
идентификация клиента, в ходе которой он передает некоторую информацию,
например, имя пользователя и пароль. После этого станции могут
поменяться местами, то есть уже сервер должен подтвердить, что он тот
самый сервер. Хотя обычно используется односторонняя
идентификация (в&йример, пользователь подключается к интернет-провайдеру).
Аутентификация необязательна и может быть пропущена. Во время
аутентификации не передаются пакеты с данными (то есть пакеты
сетевого протокола). Сам протокол LCP не выполняет процедуру
аутентификации — для этого используются протоколы аутентификации: РАР
(Password Authentication Protocol) или CHAP (Challenge-Handshake
Authentication Protocol). Первый протокол передает данные (имя
пользователя, пароль) «в открытом» виде, а второй — в зашифрованном
После аутентификации обе стороны могут договориться об обратном
звонке (call-back). Если это произошло (стороны договорились об
обратном звонке), соединение разрывается, сервер звонит клиенту,
соединение устанавливается снова и проходит другая фаза аутентификации.
Фаза обратного звонка необязательна и обычно не используется.
Если соединение установлено, активизируются дополнительные
протоколы, позволяющие сторонам договориться о кодировании
передаваемых данных, их сжатии и т. д. В большинстве случае это происходит
сразу после фазы аутентификации.
После установки параметров соединения можно передавать пакеты с
данными, то есть наступает фаза передачи пакетов сетевых протоколов. По
одной линии сразу можно передавать несколько сетевых протоколов.
144

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Завершение соединения (отключение) — последняя фаза работы
соединения, во время которой все пакеты, кроме LCP-пакетов, удаляются.
Завершение соединения передается и на физический уровень.
Физический уровень обязан отреагировать на это, например, «повесив» трубку,
то есть, освободив телефонную линию.
Формат LCP-кадра
Формат LCP-кадра показан на рис. 4.15. Нужно отметить, что все кадры
протоколов семейства РРР имеют одинаковую структуру: поле данных
любого из них состоит из кода команды и опций (параметров команды
поля Опции (Options)).
Заголовок «Хвост»
Заголовок «Хвост»
КК- код команды
ОД - общая длина
КО- код опции —
Д1, Д2 - длина данных 1 -й и 2-й опций
Рис. 4.15. Формат кадра протокола LCP
Поле КК (код команды) содержит однобайтовый код команды (или
ответа) протокола LCP (см таблицу 4.1).
Таблица 4.1. Команды протокола LCP
Код
1
2
3
Команда
Configure-Request
Configure-Ack
Configure-Nak
Описание
Конфигурационный пакет с запросом на изменение параметров линии
Конфигурационный пакет с положительным подтверждением
изменения параметров линии, то есть все параметры успешно
установлены в соответствии с предыдущим пакетом типа Configure-Request
Частичное подтверждение параметров линии. Практически все
параметры применены, но некоторые запросы пакета Configure-Request
выполнить не удалось (не удалось применить некоторые параметры).
В этом пакете также указываются параметры, которые не могут быть
задействованы, и их допустимые (альтернативные) значения
145

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 4.1.
I Код
4
5
6
7
8
9
10
11
12
Команда
Configure-Reject
Terminate-Request
Terminate-Ack
Code-Reject
Protocol-Reject
Echo-Request
Echo-Reply
Discard-Request
Identification
Описание
Невозможно применить все параметры — отрицательное
подтверждение. Вполне возможно, что система не смогла идентифицировать
код запроса (код запроса указан неверно)
Запрос на завершение соединения
Подтверждение команды Terminate-Request
Запрос не будет обработан, поскольку указан неизвестный код
команды. Такое может случиться, если станции используют разные версии
протоколов
Противоположная сторона не поддерживает указанный протокол
Диагностическая команда: проверка уровня связи
Ответ на Echo-Request
Отклоняет пакет. Это делается для проверки загрузки линии, то есть
отправитель генерирует пакеты, что создает искусственную загрузку
линии этими пакетами
Четырехбайтовое «магическое число*». Опция для расширенной
идентификации станций, позволяющая узнать версию программного
обеспечения, тип аппаратной платформы и т. д.
Поле Идентификатор (ID) (8 битов) — поле идентификационного
запроса. В этом поле отправитель генерирует идентификационный запрос,
а получатель заносит ответ на него.
Поле Длина (Length) — 16-битовое. Оно содержит сумму длин
следующих полей: код, ID, длина, опции.
Поле Опции (Options) содержит параметры отдельного запроса (или
ответа), позволяющие изменить параметры линии. В этом поле может
быть одна или сразу несколько опций, что и определяет его длину. При
передаче нескольких опций используется специальный формат,
изображенный на рис. 4.15: код опции, длина данных опции, данные опции
(например, значение параметра), затем — следующая опция.
В таблице 4.2 представлены некоторые опции протокола LCP.
Таблица 4.2. Опции протокола LCP
| Код
1
2
Опция
Maximum-Receive-Unit
(MTU)
АССМ (ASYNC.MAP)
Описание
Данная опция задает размер кадра, превышающий 1500
байтов (по умолчанию размер кадра составляет не менее 1500
байтов). Длина кадра указывается в поле данных
В 4-х байтах поля данных указывается, какие управляющие
символы будут представлять ESC-последовательность
146

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Продолжение табл. 4.2.
| Код
3
5
7
8
13
17
18
19
23
Опция
Authentication-Protocol
Magic-Number
Protocol-Field-
Compression
Address-and-Control-Field-
Compression
Call-Back
Multilink-MRRU
SSNH
Multillnk-Endpoint
Discriminator
Line-Discriminator for BAP
Описание
Позволяет указать протокол аутентификации, который хочет
использовать станция. Например, для РАР это поле содержит
шестнадцатеричное значение с02316, для CHAP —c22316, для
ЕАР — с227,6. При использовании CHAP данная опция задает
еще и идентификатор алгоритма кодирования: 0516 для MD-5,
8016для MS CHAP версия 1 (использует MD-4) и 811? для MS
CHAP версия 2
Содержит 4-байтовое «магическое число», позволяющее
определить «петлю» на линии. Если получателю прислана
команда Configure-Request с «магическим числом», он находит
«магическое число» предыдущего Configure-Request. Если
они равны, значит, есть «петля». В этом случае, он
отправляет другое число в качестве ответа. Если же «петли» нет, он
отправляет исходное «магическое число». Некоторые версии
РРР повторяют первый кадр на линии до тех пор, пока не
получат первый ответ
Сжатие поля протокола: отбрасывает первые нули в
номере протокола, то есть если номер нашего протокола 0021, то
в результате этого сжатия мы получим номер 21
Сжатие поля адреса и управляющего поля. В РРР-кадрах поле
Адрес (Address) всегда содержит значение FF, а
управляющее поле — значение 03. После установки этого сжатия
отправитель просто не будет отправлять данные поля, а получатель
после получения кадра без этих полей автоматически их
добавит
Запрос на обратный звонок. После подтверждений этого
запроса фаза аутентификации завершается. Стороны «вешают»
трубки. Затем вторая сторона (сервер) начинает набирать
номер телефона, переданный ей первой стороной в поле
данных
Подтверждение этой опции означает, что система использует
протокол MR Поле данных этой опции содержит
максимальный размер пакета, который система может обработать.
Запрашивает «сократить» MP-заголовок с 4 до 2 байтов (см.
протокол MP)
Идентификация,компьютера с использованием протокола MP
Идентификация • линии одним компьютером (см. протокол
ВАР) |
Разбираем пример кадра РРР-соединения
Чтобы лучше понять функции отдельных полей, давайте рассмотрим
листинг кадра РРР-соединения с Windows 2000 Server (стандартное
dial-up-подключение с РАР-аутентификацией).
147

TCP/IP и DNS в теории и на практике. Полное руководство
Листинг 4.1. Кадр РРР-соединения с Windows 2000 Server
+ Frame: Base frame properties
PPP: Unknown Frame (0x0)
PPP: Destination Address = SEND_
PPP: Source Address = SEND_
PPP: Protocol = Line Control Protocol
LCP: Config Req Packet, Ident = 0x00, Length = 44
LCP: Code = Configuration Request
LCP: Identifier = 0 (0x0)
LCP: Length = 44 (0x2C)
LCP: Options:
LCP: ASYNC.MAP:00 00 00 00
LCP: Option Type = Async-Control-Character-Map
LCP: Option Length = 6 (0x6)
LCP: Async Control Character Map = 00 00 00 00
LCP: AUTH:PAP
LCP: Option 'Type = Authentication-Protocol
LCP: Option Length = 4 (0x4)
LCP: Authentication Protocol = Password Authentication Protocol
LCP: Option Data: Number of data bytes remaining = 0 (0x0000)
LCP: MAGIC#:0x6147A40
LCP: Option Type = Magic-Number
LCP: Option Length = 6 (0x6)
LCP: Magic Number =?■ ,102005312 (0x6147A40)
LCP: PROT.COMP
LCP: Option Type = Protocol-Field-Compression
LCP: Option Length =2 (0x2)
LCP: ADR/CF.COMP
LCP: Option Type = Address-and-Control-FieId-Compression
LCP: Option Length = 2 (0x2)
LCP: CALL.BACK:Unkn
LCP
LCP
LCP
Option Type = Callback
Option Length = 3 (0x3)
CallBack - 0x06
LCP: MRRU
LCP
LCP
LCP
Option Type = Multiline-MRRU
Option Length = 4 (0x4)
.Multiline MRRU = 1614 (0x64E)
LCP:. Option Summary = N/A-

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
LCP: Option Туре = Multiline-Endpoint-Discriminator
LCP: Option Length = 9 (0x9)
LCP: Option Summary = N/A
LCP: Option Type = Line Discriminator for BACP
LCP: Option Length = 4 (0x4)
Приведенный листинг — это РРР-кадр, который Windows 2000
«пересчитала» в Ethernet-кадр. Кадр РРР состоит из:
• Command code (Configuration Request =1).
• Identifier (= 0).
• Length (44 bytes).
• Options.
После этого идут опции кадра:
• ASYNC.MAP (Async-Control-Character-Map):.... Определяет ESC-
последовательность.
• AUTH:PAP:... Запрос РАР-аутентификации.
• MAGIC:... Содержит «магическое число».
• PROT.COMP:... Запрос сжатия Protocol-Field-Compression.
• ADR/CF.COMP: ... Запрос сжатия Address-and-Control-Field-Com-
pression.
• CALLBACK:... Активация CALL BACK.
• Multilink MRRU: ... Поддерживает ли другая сторона MP? Каков
максимальный размер пакета?
На рис. 4.16 приведен пример LCP-диалога, состоящий из следующих
этапов:
1. Первая сторона отправляет запрос Configure-Request.
2. Вторая сторона не знает опцию PROT.COMP, поэтому посылает
команду Configure-Reject с опцией PROT.COMP.
3. Первая сторона отправляет команду, которая, по ее мнению, должна
быть понятной второй стороне — CALLBACK, MRRU e 500.
149

TCP/IP и DNS в теории и на практике. Полное руководство
4. Вторая сторона понимает команду, но предпочитает установить
опцию MRRU = 700 (вместо 500), установка данной опции
выполняется с помощью команды Configure-Nack.
Первая сторона
(точка)
Вторая сторона
(точка)
^Configure-Request: CALLBACK, PROT.COMR MRRU=
О
A
4SM
A
ts9
-<—
Configure-Reject: PROT.COMP
Configure-Request: CALLBACK, MRRU=500
Configure-Reject: MRRO700
Configure-Request: CALL.BACK, MRRU=700
Configure-Ack: CALL.BACK, MRRU=700
=500
A
ХЭ
Л
%3
—©
Рис. 4.16. Пример LCP-диалога
5. Первая сторона соглашается и подтверждает опции CALL.BACK,
MRRU - 700.
6. Вторая сторона: «Все, договорились: CALL.BACK, MRRU = 700».
4.4.4. Управление доступом. РРР-Аутентификация
Существуют три способа РРР-аутентификации:
• Терминальный — при подключении открывается окно терминала,
вторая сторона выводит приглашение ввести имя пользователя и
пароль, в ответ на которое вы должны это сделать. Данный способ
подробно описан в п. 4.4.2.
• Password Authentication Protocol (PAP) — данный способ
подобен первому, но имя пользователя и пароль передаются по
протоколу РАР, а не вводятся в терминале вручную. Протокол РАР описан
bRFC-1334.
150

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Challenge Handshake Authenticatibrt Protocol (CHAP) —
протокол определен в RFC-1994 и очень похож на РАР, но передает
данные (имя пользователя и пароль)'не в ;«открытом виде», а в
закодированном.
Рис. 4.17. Протоколы аутентификации в Windows 2000
151

TCP/IP и DNS в теории и на практике. Полное руководство
Протокол РАР
РАР — более простой протокол, предлагающий элементарный
двухфазовый способ аутентификации. При наступлении фазы аутентификации
(Authentication Phase) абонент начинает передавать пакеты, которые
содержат имя пользователя и пароль (Authenticate-Request). Передача
пароля продолжается до тех пор, пока от сервера не придет ответ (Authenticate-
Ack/Authenticate-Nak), или соединение не будет разорвано.
Таблица 4.3. Команды протокола РАР
Код
1
2
3
Команда
Authenticate-Request
Authenticate-Ack
Authenticate-Nak
Описание
Пакет Authenticate-Request, содержащий имя пользователя
и пароль, начинает фазу аутентификации.
Подтверждение аутентификации: имя пользователя и пароль
правильны
Имя пользователя и/или пароль неправильны
В листинге 4.2. приведен пример РАР-аутентификации, «захваченной»
сетевым монитором.
Листинг 4.2. Пример РАР-аутентификации
+ Frame: Base frame properties
+ PPP: Unknown Frame (0x0)
PPPPAP: Authenticate Request
PPPPAP
PPPPAP
PPPPAP
PPPPAP
PPPPAP
PPPPAP
PPPPAP
Code = Authenticate Request
ID = 5 (0x5)
Length = 27 (OxlB)
Side ID Length = 13 (OxD)
Side ID = Administrator
Password Length = 5 (0x5)
Password = Heslo
Протоколы типа CHAP
В отличие от РАР протокол CHAP предоставляет более сильный
механизм аутентификации пользователей. При этом процедура
аутентификации состоит из трех этапов.
В начале процесса аутентификации, который инициализируется
клиентом доступа, абоненту (пользовательскому компьютеру) передается
152

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
пакет запроса CHAP-Challenge. Данный пакет содержит «запрос»
(challenge) — уникальную, достаточно длинную последовательность
случайных символов. Эта последовательность изменяется при каждой новой
посылке.
Получив пакет, абонент (компьютер клиента) запрашивает пароль
у пользователя (пароль уже может быть сохранен в базе паролей), затем
абонентский компьютер выполняет некоторые шифрующие действия
(обычно используется алгоритм RSA MD5) над «запросом» (challenge),
используя введенный пароль. После этого абонент отправляет пакет
CHAP-Response, содержащий ответ (Responce) — значение,
полученное в результате шифрования.
Сервер, регламентирующий доступ, знает правильные имя
пользователя и пароль, и уже вычислил правильное значение для них. Если
полученный результат совпадает с Response-ответом, полученным от
клиента, сервер отправляет клиенту сообщение об успешной
аутентификации — CHAP-Success, в противном случае выдается сообщение
CHAP-Failure, и соединение разрывается. Функции сервера и клиента
доступа может выполнять один компьютер.
Преимущество протокола CHAP заключается в том, что посети никогда
не передается пароль в «чистом» виде — его знает только сам
пользователь и сервер аутентификации. А поскольку пароль не «ходит» через
сеть, он не может быть взломан. Так что желающие проникнуть в
систему под чужим именем обычно выбирают другой способ получения
пароля «жертвы».
Команды протокола CHAP приведены.в таблице 4.4.
Таблица 4.4. Команды протокола CHAP
Код
1
2
3
4
Команда
Challenge
Response
Success
Failure
Описание
Запрос на аутентификацию со стороны сервера, содержит
«секрет»
Ответ клиента, содержащий имя пользователя, пароль и
закодированный «секрет»
Аутентификация успешна
Аутентификация неуспешна
Компания Microsoft выпустила собственную версию протокола CHAP —
MS CHAP. Для кодирования информации данный протокол
использует алгоритмы MD-4 и DES. Первая версия этого протокола (MS CHAP
version 1) описана в RFC-2433.
153

TCP/IP и DNS в теории и на практике. Полное руководство
Нужно отметить, что использование UNIX классической версии CHAP,
a Windows — «версии от Microsoft» порождало проблемы при
подключении UNIX-станции к Windows-серверу по протоколу CHAP.
Основное преимущество MS CHAP vl — это обратная совместимость
с системами LAN Manager. Однако что-то в MS CHAP vl (другое
название — MS CHAP 80) пошло не так, и практически сразу была выпущена
MS CHAP v2 (в составе SP3 для Windows NT). В отличие от первой
версии вторая не поддерживает системы LAN Manager.
Какой протокол будет использоваться (CHAP, MS CHAP vl, MS CHAP v2
(он же MS CHAP 81)), указывается при установке соединения.
Например, если ваш сервер использует MS CHAP vl, то при отладке соединения
с использованием демона pppd в UNIX вы увидите на экране:
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap 80> <magic 0x46a3>]
А если MS CHAP v2, to:
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap 81> <magic 0x46a3>]
Расширяемый протокол аутентификации
Extensible Authentication Protocol (EAP)
Несмотря на то, что формат кадра протокола ЕАР очень похож на формат
кадра протокола CHAP, работает протокол ЕАР совсем иначе.
Расширяемый протокол аутентификации (Extensible Authentication Protocol,
ЕАР) используется как унифицированный интерфейс для
аутентификации, авторизации и учета (Authentication, Authorization, Accountion, AAA
или ЗА). В качестве ЗА-сервера обычно используется сервер RADIUS.
ЕАР — это не метод аутентификации, а основа, на базе которой проходят
аутентификация и распределение ключей.
Преимущество этого протокола заключается в том, что производителям
коммутаторов требуется внедрить только протокол ЕАР, а
разработчики программного обеспечения могут сами выбирать различные методы
ЕАР, например, EAP-MD5 или EAP-TLS. Сам протокол ЕАР описан
в RFC-2284, a EAP-TLS в RFC-2716.
Аутентификация на основе EAP-MD5 осуществляется следующим
образом:
1. Проверяющая сторона запрашивает согласие на аутентификацию
другой стороны сообщением EAP-Request.
154

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
2. Если вторая сторона соглашается на аутентификацию, она
отправляет сообщение EAP-Response.
3. Проверяющая сторона отправляет второй стороне сообщение ЕАР-
Request, что означает «запрос» (Challenge).
4. Абонентская сторона добавляет имя пользователя и пароль
к Challeng'y и применяет к полученной строке М05-функцию. Так
формируется EAP-Response.
5. Проверяющая сторона просит третью сторону (обычно сервер
RADIUS) подтвердить или опровергнуть предоставленные ей
данные (Challenge и Response). В ответ на это сервер отправляет одно
из двух сообщений: EAP-Success (подтверждение) или EAP-Failure
(опровержение).
Механизм аутентификации EAP-MD5 использует MD5-X3iu имени
пользователя и пароля как подтверждение для сервера RADIUS.
Аутентификация EAP-MD5 не поддерживает ни управление ключами, ни
создание динамических ключей, что делает ее неэффективной для
применения на транспортном уровне.
На транспортном уровне используется EAP-TLS (ЕАР — Transport
Layer Security). При этом для аутентификации используются
сертификаты Х.509 в рамках инфраструктуры открытых ключей (Public Key
Infrastructure, PKI). Протокол EAP-TLS поддерживает динамическое
создание ключей и двунаправленную аутентификацию. Данный протокол
для идентификации пользователей позволяет использовать Active
Directory, что очень удобно в сетях Microsoft и при организации VPN-сетей.
Пользователь ~"*--
Рис. 4.18. Использование протокола EPA-TLS в сети Microsoft
155

TCP/IP и DNS в теории и на практике. Полное руководство
Протокол Radius решает проблемы аутентификации
Основная проблема аутентификации заключается в том, что
пользователь не желает, или у него нет возможности регистрироваться на данном
конкретном сервере доступа. Например, модемный пул одного сервера
доступа временно недоступен, или же клиент находится в другом городе
и хочет зарегистрироваться на местном сервере доступа своего
провайдера. Тут нужно централизированное управление пользователями,
которое обеспечивается различными протоколами. Одним из них является
RADIUS.
Протокол RADIUS (Remote Authentication Dial In User Service) очень
часто используется в различных сетевых устройствах
(маршрутизаторах, коммутаторах и т. д.) для аутентификации пользователей. Сетевые
устройства обычно имеют ограниченные аппаратные ресурсы, поэтому
не могут хранить в памяти информацию о большом количестве
пользователей. На помощь приходит RADIUS-сервер, обеспечивающий
централизованное управление пользователями, что очень важно в целом
ряде случаев. Предположим, у нас есть интернет-провайдер с
десятками или даже с сотнями тысяч пользователей, причем их число может
варьироваться в зависимости от времени суток (например, дневной
пакет — с 8 до 19 часов, ночной пакет — с 19 часов до 8 утра и т. д.).
Централизованная база данных хранит информацию о каждом
пользователе.
Протокол RADIUS поддерживается большинством производителей
сетевого оборудования и программного обеспечения. В Windows Server
2000/2003 RADIUS является частью сервиса интернет-аутентификации
IAS (Internet Authentication Service).
Протокол обеспечивает функции защиты от целого ряда сетевых атак,
в том числе, использования сетевых снифферов. Основные конкуренты
RADIUS — это TACACS+ и LDAP, но у них больше недостатков, чем
у RADIUS.
4.4.5. Протокол управления обратным звонком —
СВСР (Call-Back Control Protocol)
Данный протокол используется для организации обратного вызова.
При этом возможны два способа (более безопасным считается второе
решение):
156

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
1. Клиент устанавливает соединение с сервером и передает серверу
свой номер телефона — по этому номеру сервер должен перезвонить.
Сервер обрывает соединение и набирает указанный номер. Это не
очень хорошо с точки зрения безопасности. Единственное
преимущество данного решения заключается в том, что оно довольно
просто в организации, и пользователю не нужно платить за соединение,
так как сервер сам набирает номер.
2. Как и в предыдущем случае, клиент устанавливает соединение с
сервером, но не передает серверу номер телефона. Сервер определяет
его сам — находит в базе данных пользователей (не забываем, что
установка обратного звонка начинается уже после аутентификации
пользователя, поэтому сервер знает, кто находится на другом конце
линии).
Обойти второй способ очень сложно. Единственная возможность —
подключиться к линии абонента и позвонить как бы от него. Сервер
определит абонента и перезвонит ему, но вызов будет принят не абонентом,
а злоумышленником. А абонент в это время будет думать, что у него
неполадки с телефонной линией.
Пользователь
!В
ррр
Сервер
доступа
Рис. 4.19. Протоколы Radius и Radius Accounting (учет пользователей)
Протокол СВСР имеет такой же формат кадров, что и протокол LCP.
Основные команды протокола СВСР: CB-Request (код 1), CB-Response
(код 2) и СВ-Ack (код 3).
157

TCP/IP и DNS в теории и на практике. Полное руководство
Опции протокола СВСР представлены в таблице 4.5.
Таблица 4.5. Опции протокола СВСР
Код
1
2
3
4
Опция
No Call-Back
Call-Back to user-specified
number
Call-Back to administrator-
defined number
Call-Back to any of a list of
numbers
Описание
Без обратного вызова
Обратный вызов по указанному клиентом номеру
Обратный вызов по номеру из базы данных пользователей
Сервер звонит по одному из указанных в списке номеров
Когда клиент передает серверу номер телефона, диалог между клиентом
и сервером выглядит так:
1. Сервер передает клиенту запрос CB-Request с опцией No CallBack.
2. Клиент отвечает серверу: CB-Response с опцией Call-Back to the
user-specified number, которая содержит три значения:
• время задержки звонка;
• тип номера телефона (Q1 для классических аналоговых сетей
(PSTN) или ISDN-сетей);
• сам номер телефона.
3. Сервер передает клиенту команду СВ-Ack, чем подтверждает
принятие информации.
При втором способе организации обратного вызова, когда сервер
находит номер телефона в базе пользователей, диалог между сервером и
клиентом выглядит так:
• Сервер отправляет клиенту запрос CB-Request с опцией Call-Back
to administrator-defined number.
• Клиент отвечает командой CB-Response с опцией Call-Back to
administrator-defined number.
• Сервер отправляет подтверждение — команда СВ-Ack.
158

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
4.4.6. Дополнительные (вспомогательные) протоколы
семейства РРР
Многоканальный протокол «точка-точка» —
Multiline Protocol (MP)
Протокол MP представляет собой открытый стандарт, определяющий
способ комбинирования В-каналов (в цифровых линиях типа ISDN).
Продукты, отвечающие спецификациям MP, могут взаимодействовать
друг с другом. Хотя протокол MP не предусматривает методов сжатия
данных и ряд других аспектов, мы считаем, что пользователю,
выбирающему маршрутизатор ISDN, следует рассматривать совместимость с MP
как абсолютно обязательную характеристику.
Многоканальный протокол описан в RFC-1990. Он определяет, как
использовать несколько физических линий между двумя компьютерами
одновременно. В результате эти линии создают одну виртуальную
линию-связку (логический канал), которая используется для передачи
данных.
Другая очень важная функция этого протокола заключается в том, что
отдельные линии, формирующие виртуальную линию-связку, могут
быть физически разными, например, коммутируемые линии,
выделенные линии, Х.25 и т. д. Классический пример — соединение двух
В-каналов в ISDN (Начальный интерфейс).
Поскольку пропускная способность РРР-линий всегда ограничена,
данный протокол очень важен, поскольку за счет использования
нескольких линий он позволяет увеличить пропускную способность.
На рис. 4.20 приведен пример односторонней связи. Соединение с
использованием нескольких линий уже установлено по протоколу LCP.
И с помощью этого же протокола установлена поддержка протокола MP,
для чего обе стороны договариваются о максимальном размере пакета —
MRRU (минимум 1500 байтов). Обе стороны производят
идентификацию друг друга с помощью опции Multiline-Endpoint-Discriminator.
Одной из проблем при использовании MP является распределение
пакетов по каналам и последующее их упорядочивание — какой пакет по
какому каналу отправить и как потом определить исходную
последовательность пакетов.
По виртуальному каналу нельзя передавать конфигурационные LCP-пакеты:
Configure-Request, Configure-Reject, Configure-Ack, Configure-Nak,
159

TCP/IP и DNS в теории и на практике. Полное руководство
;:В,
Е
zero
padding
, Fragment no.
В
First connection point
(source)
r V I Protocol BAP T I
I fragment""]-»- n I * ГЖ-
\M—I J | rragmjhti » *-f-
*MRRU I J
УГ— fragment 1 » —y-
Protocol MP
Second connection point
(destination)
Рис. 4.20. Использование протокола MP
Terminate-Request или Tenninate-Ack. Принимающая сторона должна
их игнорировать. Нельзя передавать только конфигурационные пакеты,
но можно передавать остальные LCP-пакеты (Code-Reject, Protocol-
Reject, Echo-Request, Echo-Reply и Discard-Request).
Рассмотрим формат пакета MP:
Адрес = OxFF
Управляющее поле = 03
PID (Н) = 00
PID (L) = 0x3D
Порядковый номер пакета
Порядковый номер (L)
Фрагмент данных
FCS
160

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Специально следует рассмотреть лишь следующие поля:
• Поле PID — это идентификатор протокола (Protocol ID), его
подполе В (Beginning) - бит фрагмента = 1 для первого фрагмента РРР и О
для всех последующих фрагментов.
• Поле Порядковый номер пакета имеет длину 24 бита. Иногда
используется «сокращенная», 12-битовая версия. Выбор длины этого
поля происходит с помощью LCP. Как следует из названия,
значения этого поля увеличиваются на 1 после отправки очередного
фрагмента.
Для протоколов более высокого уровня MP-канал выглядит как
единый канал, по которому передаются данные, то есть тут все
абсолютно прозрачно — вышестоящий протокол просто записывает в канал
данные, а как там все организовано — пусть разбирается MP — это
его задача.
При передаче пакетов по MP-каналу соблюдаются следующие правила:
• Асинхронное управление кодированием символов не используется.
• Не используются «магические числа».
• Не разрешается мониторинг качества канала.
• Выполняется сжатие адреса, протокола и управляющего поля.
• Запрещено заполнение с самоописанием (Self-Describing-Padding).
Протоколы ВАР (Bandwidth Allocation Protocol)
и ВАСР (Bandwidth Allocation Control Protocol)
Данные протоколы (описаны в RFC-2125) позволяют динамически
добавлять (или удалять) линию в логический MP-канал. При этом
добавление дополнительной линии происходит «на лету», без остановки
интерфейса.
Если оба протокола поддерживаются, то каждая линия виртуального
канала должна во время установки соединения идентифицировать себя,
используя LCP-опцию Line-Discriminator for ВАР.
«Представиться» можно двумя способами:
• Используя опцию Multiline-Endpoint-Discriminator, которая
описывает весь компьютер. Данная идентификация использует MP.
6 Змс.518 461

TCP/IP и DNS в теории и на практике. Полное руководство
• Используя опцию Line-Discriminator for BAP, описывающую
определенную линию в пределах виртуального канала. У каждой
стороны соединения будут независимые (и различные)
идентификаторы.
После этого активизируется ВАСР. Это простой управляющий
протокол с простыми функциями. Если оба конца линий посылают запрос на
добавление/удаление линии одновременно, ВАСР случайным образом
определяет, какой запрос ему нужно обработать. Хотя также
учитываются и приоритеты сторон: чем ниже номер стороны, тем выше
приоритет посылаемых ею запросов.
Пакеты протокола ВАСР подобны LCP-пакетам.
Команды, позволяющие добавлять и удалять линии, представлены
в таблице 4.6.
Таблица 4.6. Команды протокола ВАСР
\ Код
1
2
3
4
5
6
7
L8
Команда
Call-Request
Call-Response
Call Back-Request
CallBack-Response
Line-Drop-Query-Request
Une-Drop-Query-Response
Call-Status-lndication
Call-Status-Response
Описание
«Я хочу установить соединение по другой линии»
Подтверждение запроса на добавление линии
«Я хочу добавить линию, по который вы мне перезвоните. Вы
согласны?»
Подтверждение запроса обратного звонка
«Я хочу удалить линию»
Подтверждение запроса на удаление линии
После подтверждения запроса на добавление линии данная
опция сообщает, удачна эта операция или нет. Ведь мы
могли подтвердить, что согласны «принять» линию, но что-то не
вышло |
Ответ на Call-Status-lndication |
Все эти ответы являются подтверждениями запроса, то есть они
сообщают: положительное это подтверждение (операция успешна) или
отрицательное (операция неуспешна).
Определить успешность выполненной операции можно по сегменту
данных ответа. Этот сегмент начинается с первого байта (8 битов) и
содержит код ошибки:
• 00000000 - Request- Ack
• 00000001 - Request-Nack
• 00000010 — Request-Reject
162

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
• 00000011 — Request-Full-Nak (запрашиваемая операция запрещена,
например, при достижении максимального/минимального
количества линий).
Опции команд представлены в таблице 4.7.
Таблица 4.7. Опции протокола ВАСР
| Код
1
2
3
4
5
6
Опция
Line-Type
Phone-Delta
No-Phone-Number- Needed
Reason
Link- Discriminator
Call-Status
Описание
Определяет скорость и тип линии: 0 = ISDN, 1 = Х.25, 2 =
аналоговая линия
Содержит информацию, необходимую для набора номера
(например, сам номер)
Информация, необходимая для набора номера, не передана.
Из соображений безопасности иногда не нужно передавать
номер телефона, он сохраняется в конфигурации системы,
которая сама наберет нужный номер
Причина добавления/удаления линии (передает текстовое
сообщение)
Используется при удалении линии, содержит идентификатор
линии для ее удаления (см. Link-Discriminator for the BAP,
табл. 4.2)
Информация о статусе dial-up-соединения. О = «номер не
будет набран «заново», 1 = «будет произведен повтор набора
номера |
Протокол управления сжатием —
Compression Control Protocol (ССР)
Протокол ССР (описан в RFC-1962) управляет алгоритмами сжатия.
РРР-кадры, содержащие пакеты ССР, используют номер протокола
80fd16, и их формат снова похож на формат LCP.
ССР используется для настройки, включения и выключения сжатия
данных на обоих концах РРР-соединения. Также он используется для
обнаружения ошибок сжатия.
Посмотрим на рис.4.20. Цилиндром на рисунке изображен протокол MP.
Так вот, возможны два типа сжатия: сжатие выше «цилиндра» (сжатие
всего пакета) и ниже «цилиндра» (сжатие только фрагмента). При
использовании сжатия фрагмента теоретически можно выполнить сжатие
на некоторых линиях (например, когда используется сжатие на
физическом уровне — протокол V.42), но не на всех.
Итак, мы определились, что сжатие фрагмента происходит на физическом
уровне, который нас сейчас не интересует. Протокол ССР используется
163

TCP/IP и DNS в теории и на практике. Полное руководство
для сжатия пакетов. Если сжатие неудачно, то есть у сжатого пакета
размер больше, чем у исходного, тогда отправляется несжатый пакет.
Мы не зря упомянули протокол MP. Протокол ССР с номером 0x80FDj6
используется для сжатия обычного РРР-соединения. Если же у нас МР-
соединение, то используется модификация протокола ССР — ее номер
0x80FB16. Данная модификация используется для сжатия отдельной
линии МР-соединения.
Команды протокола ССР подобны LCP-командам: Configure-Request,
Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request,
Terminate-Ack и Code-Reject (коды команды 1-7). Есть две
специфические для ССР-команды:
• Reset-Request (код = 14). Рекомендует, чтобы сжатые данные
периодически дополнялись контрольными суммами. Если приемник
обнаружит ошибку сжатия (то есть не совпадет контрольная сумма),
с помощью этой команды он попросит отправителя сбросить все
свои счетчики компрессии, словари и начать сжатие сначала.
• Reset-Ack (код = 15). Когда отправитель сбрасывает все свои
счетчики и словари, он информирует об этом получателя с помощью
команды Reset-Ack.
Опции команд позволяют указывать алгоритм сжатия. Если другая
сторона не поддерживает этот алгоритм, ничего страшного —
дальнейшая работа будет продолжена без сжатия. Наиболее используемыми
алгоритмами являются Stac LZS — код 17 и МРРС, (Microsoft Point-
To-Point Compression Protocol) — код 18. Данные алгоритмы описаны
в следующих стандартах:
• RFC-1967: «PPP LZS-DCP Compression Protocol (LZS-DCP)».
• RFC-1974: «PPP Stac LZS Compression Protocol».
• RFC-2118: «Microsoft Point-To-Point Compression (MPPC) Protocol».
Протокол управления шифрованием —
PPP Encryption Control Protocol (ECP)
Протокол ЕСР (определен в RFC-1968) используется для установки
и настройки алгоритма шифрования данных, передаваемых по РРР-
соединению. Формат пакета ЕСР такой же, как у LCP (Link Control
Protocol).
164

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Данный протокол не используется для обмена ключами шифрования.
Команды ЕСР аналогичны командам ССР, есть команды Reset-Request
и Reset-Ack. Можно также сказать, что ССР и ЕСР — братья-близнецы,
только первый протокол используется для сжатия данных, а второй —
для их шифрования.
Принципиальная особенность ЕСР заключается в том, что в случае,
если одна из сторон не поддерживает алгоритм шифрования,
соединение будет разорвано, а не продолжено, как в случае с ССР. На рис. 4.17
изображена установка параметров данного протокола в Windows XR
На базе этого протокола основаны некоторые другие, например,
протокол «Microsoft Point-To-Point Encryption (MPPE) Protocol», описанный
в RFC-3078. Данный протокол использует шифрование RC-4 и
поддерживает ключи длиной 40, 56 или 128 байтов.
Опции команд позволяют установить алгоритм шифрования. Наиболее
часто используются следующие алгоритмы:
• DESE, PPP DES Encryption Protocol, код 1, описан в RFC 1969.
• 3DESE, PPP Triple-DES Encryption Protocol, код 2, описан в RFC
2420.
• DESE-bis, PPP DES Data Encryption Standard Protocol, код З,
описан в RFC 2419.
4.4.7. IPCP. Протокол сетевого уровня,
входящий в группу протоколов РРР
Напомним этапы подготовки канала: установка соединения,
аутентификация, подключение нескольких линий (если нужно), установка
параметров сжатия и шифрования. После этого вступают в силу сетевые
протоколы (протоколы сетевого уровня). Каждый протокол имеет свой
протокол управления — NCP-протокол (Network Control Protocol).
IPCP (IP Control Protocol) — это IP-версия NCP-протокола, то есть
протокол управления протоколом IP. Данный протокол используется для
протокола IP версии 4 (RFC-1332). Формат кадров протокола IPCP
подобен формату кадров LCP, номер протокола — 0x8021 (см. рис. 4.15).
В следующих таблицах (4.8 и 4.9) представлены команды и опции
протокола IPCP.
165

TCP/IP и DNS в теории и на практике. Полное руководство
Таблице 4.8. Команды протокола IPCP
Код
1
2
3
4
5
6
7
Команда
Configure-Request
Gonfigure-Ack
Configure-Nak
Configure-Reject
Terminate-Request
Terminate-Ack
Code-Reject
Описание
Это конфигурационный пакет, изменяющий определенные
параметры
Положительное подтверждение конфигурационного пакета, то
есть все параметры, указанные в конфигурационном пакете,
успешно применены
Один или несколько параметров не могут быть применены.
Какие именно, указывается в этом же пакете. Остальные
параметры (не указанные в пакете) уже установлены
Конфигурационный пакет, запрещающий все запросы (не
применен ни один параметр). Также может использоваться,
если указан неверный код запроса
Запрос на завершение соединения
Подтверждение завершения соединения
Запрос не принят, поскольку указан неверный код запроса.
Возможно, что «на той стороне» используется более старая
(или другая) версия протокола J
Таблица 4.9. Опции протокола IPCP
[ Код
2
3
129
130
131
132
Название
IP-Compression-Protocol
IP-Address
Primary-DNS-Address
Primary-NBNS-
server-address
Secondary-DNS-Address
Secondary-NBNS-
server-address
Описание
Сжатие IP-заголовка. Поле данных содержит номер протокола
сжатия, например, 002d для «классического» сжатия в
соответствии с RFC-1144.
Передача IP-адреса второй стороне. Позволяет динамически
назначать IP-адреса (протокол DHCP). Если узел хочет
использовать другой IP, он отправляет соответствующий ответ — пакет
Configure-Nak, в котором указан нужный IP.
Установка IP первичного сервера DNS. Поле данных содержит
4-байтовый IP-адрес сервера DNS
Установка WINS-сервера
Установка вторичного сервера DNS
Установка вторичного WINS-сервера
В РРР протокол 0x00211б служит для передачи несжатых пакетов
данных по протоколу IPv4 с использованием метода Ван Якобсона
(Vanjacobson). В случае сжатия ситуация немного усложняется,
поскольку не у всех пакетов сжат заголовок. Поэтому нужно различать
переданные пакеты: со сжатым заголовком TCP/IP и без сжатого
заголовка (например, первый пакет потока). Дифференцирование таких
пакетов выполняется с помощью поля протокола.
В РРР-кадре пакет со сжатым заголовком имеет в поле Протокол
(Protocols) значение 0x002d16, а у несжатых кадров — 0x002f1(..
166

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Рассмотрим пример РРР-кадра, захваченного программой Network
monitor между Windows ХР и Windows 2000 (см. листинг 4.3). Данный
кадр содержит команду Configure-Request протокола IPCP.
Листинг 4.3. Пример РРР-кадра с командой Configure-Request протокола IPCP
Frame: Base frame properties
+ PPP: Unknown Frame (0x0)
IPCP: Configuration Request, Ident = 0x05
IPCP: Code = Configuration Request
IPCP: Identifier = 5 (0x5)
IPCP: Length = 16 (0x10)
IPCP: Cption: Compression Prot.=0x002D (Van Jacobson Compr. TCP/IP)
IPCP: Option Type = Compression Protocol
IPCP: Option Length = 6 (0x6)
IPCP: Compression Protocol=Van Jacobson Compr. TCP/IP
IPCP: Max Slot ID = 15 (OxF)
IPCP: Comp Slot ID = Slot Identifier may be compressed
IPCP: Option: Address = 10.1.1.1
IPCP
IPCP
IPCP
Option Type = Address
Option Length = 6 (0x6)
Source Address = 10.1.1.1
Обратите внимание на то, что требуется «классическое» сжатие данных
по методу Van Jacobson (RFC 1144) с параметрами Max Slot ID и Comp
Slot ID.
4.5. Frame Relay — протокол канального уровня
для глобальных сетей
Общее описание технологии
Frame Relay — это протокол канального уровня для глобальных сетей.
Он определен следующими стандартами: 1.122,1.441 и ANSITI.606.
Frame Relay обычно используется для создания постоянных
виртуальных каналов (теоретически, можно использовать коммутируемые линии,
но на практике их никогда не используют). Постоянные виртуальные
167

TCP/IP и DNS в теории и на практике. Полное руководство
каналы подобны выделенной линии. Пользователь может арендовать
виртуальные каналы у своего местного провайдера Frame Relay.
Frame Relay — это дейтаграмма-ориентированная сеть, по которой
передаются ненумерованные кадры. Провайдер не может гарантировать
доставку кадра. Каждый кадр содержит контрольную сумму, по которой
проверяется корректность передачи пакета. Поврежденные пакеты
отбрасываются.
Основной параметр виртуального канала — это количество данных,
которое может быть передано пользователем по этому каналу за интервал
времени Тс. Этот параметр обозначается аббревиатурой Be (Committed
Burst Size).
Следующий параметр — это CIR {Committed Information Rate). CIR
является производным от первых двух параметров: CIR = Вс/Тс, то есть
это согласованная скорость, с которой сеть будет передавать данные.
CIR позволяет установить, сколько данных пользователь сможет
передать по сети Frame Relay за единицу времени.
CIR нужно рассматривать как некое абстрактное, приблизительное
значение, поскольку скорость передачи зависит от многих факторов и
может меняться во время работы сети. Выражаясь математическим
языком, CIR — это теоретически среднее значение, на практике все будет
иначе.
Самое интересное, что полоса виртуального канала всегда
соответствует потребностям пользователя. Пользователь заключает с провайдером
соглашение о какой-то определенной CIR, например, 64 Кбит/с. Также
оговаривается скорость в час пик. За дополнительную плату можно
получить небольшую прибавку к скорости — это называется ВЕ (Excess
Burst Rate) - максимальное количество информации, которое сеть
будет пытаться передать сверх установленного значения Вс за интервал
времени Тс.
Сеть Frame Relay может передавать данные со скоростью от 56 Кб/с
до 2Мб/с. Рассмотрим пример сети. Предположим, что нужно связать
четыре объекта, расположенных в разных регионах — Берлине,
Мюнхене, Дортмунде и Кельне (см. рис. 4.21). При использовании
выделенных линий понадобится четыре выделенные линии от телефонной сети
к провайдеру и четыре модема — по одному в каждом регионе. Также три
интерфейса на маршрутизаторе в каждом регионе.
168

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
LAN Мюнхен
LAN Дортмунд
LAN Берлин LAN Кельн
Рис. 4.21. Некая компания, расположенная в четырех регионах
Предположим, что в данном регионе есть провайдер Frame Relay.
Достаточно подключиться к этому провайдеру и ни о чем не заботиться: ни об
организации выделенной линии, ни о маршрутизации — все это берет
на себя провайдер. Кроме того, вы получаете более высокоскоростной
канал между офисами вашей компании.
Чтобы соединить четыре региона, будет достаточно одного интерфейса
на маршрутизаторе и одной линии к ближайшей точке доступа
провайдера Frame Relay в каждом регионе.
LAN Мюнхен
LAN Дортмунд
LAN Берлин
LAN Кельн
Рис. 4.22. Компания, расположенная в четырех регионах, и провайдер Frame Relay
169

TCP/IP и DNS в теории и на практике. Полное руководство
Между всеми регионами будут установлены виртуальные каналы.
Вернемся к нашему рисунку. Будут установлены следующие виртуальные
каналы: Мюнхен — Дортмунд, Мюнхен — Берлин, Берлин — Дортмунд.
Топология сети будет такой же, как и при использовании выделенных
линий, вместо которых будут использоваться виртуальные каналы.
LAN Мюнхен
М - маршрутизатор
LAN Берлин
I
I/ Провайдер
И Frame Relay
f
LAN Дортмунд
M
J М
1 ZL
LAN Кельн
Рис. 4.23. Виртуальные каналы Frame Relay
Физическая линия, соединяющая какой-то регион с сетью Frame Relay,
обслуживает два виртуальных канала одновременно. Провайдер Frame
Relay создает большую частную сеть, соединяющую клиентов с
помощью виртуальных каналов. В основном к Frame Relay подключаются
целые сети, а не отдельные компьютеры. Подключение к FR-сети
отдельного компьютера экономически неоправданно. Подключение сети
означает подключение маршрутизатора к Frame Relay, а к
маршрутизатору — остальных компьютеров сети.
Между пользовательским маршрутизатором и сетью Frame Relay
находится FR-коммутатор (см. рис. 4.24). Между маршрутизатором и FR-
коммутатором определен сетевой интерфейс пользователя.
На физическом уровне с сетями Frame Relay используются интерфейсы
V.35 и Х.21 (а также некоторые другие).
Виртуальные каналы Frame Relay используют синхронную передачу
данных. Кадр от отправителя до получателя проходит довольно долгий путь
через большое количество различных линий. У каждого виртуального со-
170

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Приклад.
Представ.
Транспорт.
Сетевой интерфейс
.пользователя.
Маршрутизатор
Маршрутизатор
Представ.
Транспорт.
Рис. 4.24. Frarrie Relay и модель OSI
единения есть свой идентификатор — DLGI (Data Link Connection
Identifier). Номер DLCI задается в заголовке кадра Frame Relay. Формат кадра
Frame Relay похож на HDLC, но со следующими отличиями: иоле адреса
изменило свой формат, а управляющее поле вообще отсутствует.
В заголовке кадра Frame Relay для DLCI зарезервировано 10 битов,
следовательно, значения DLCI лежат в диапазоне от 1 до 1023.
LAN Дортмунд
Физическая
линия,
т. е. интерфейс
С.35
DLCI=21,DLCI=22
I
-L^
М
I
М -маршрутизатор
LAN Берлин
LAN Кельн
Рис. 4.25. Изменение DLCI при передаче кадра
171

TCP/IP и DNS в теории и на практике. Полное руководство
На рис. 4.25 показано, как изменяется DLCI кадра по пути из Берлина
в Дортмунд. Пользователь в Берлине отправил кадр с DLCI = 22 в
большое плавание по сети Frame Relay. Коммутатор в соответствии со своей
таблицей конфигурации изменяет DLCI на 32 и передает входящий кадр
из интерфейса #1 на интерфейс #2. Коммутатор 2 сконфигурирован на
изменения DLCI с 32 на 62. Коммутатор 3 изменяет значение 62 на 92
и передает кадр конечному пользователю.
С точки зрения конечного пользователя все выглядит намного проще:
при передаче кадра из Берлина в Дортмунд значение DLCI изменяется
с 22 на 92. Когда мы отправляем кадр из Берлина (DLCI = 21) в Мюнхен,
конечное значение DLCI будет равно 41. А при отправке из Мюнхена
(41) в Берлин DLCI будет равно опять 21 (см. рис. 4.25).
Кадр протокола Frame Relay
Как уже отмечалось, кадр протокола Frame Relay (см. рис. 4.26) очень
похож на кадр протокола HDLC без полей адреса и управления (точнее,
поле адреса осталось, изменив не только свой формат, но и название).
Заголовок
; Данные
Контрольная
сумма
DLCI
16 битов
1-й байт
с
ЕА
0
DLC
4 бита
2-й
F
Е
С
N
бай
В
Е
с
N
т
D
Е
ЕА
1
DLCI
16 битов
1-й байт
с
/
R
ЕА
0
DLCI
4 бита
2-й
F
Е
с
N
5ай
—
В
Е
с
N
т
—
ъ
Е
ЕА
0
DLCI или DL-CORE
6 битов
3-й байт
D
с
ЕА
1
DLCI
16 битов
1 -й байт
с
/
R
ЕА
0
DLCI
4 бита
2-й
F
Е
с
N
бай
В
Е
с
N
т
D
Е
ЕА
0
DLCI
7 битов
3-й байт
ЕА
0
DLCI или DL-CORE
6 битов
4-й байт
D
с
ЕА
1
Рис. 4.26. Формат кадра Frame Relay
172

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Кадр имеет общее поле заголовка, содержащее DLCI и другую
управляющую информацию. Длина заголовка может быть 2, 3 или 4 байта
(16 или 32 бита). Обычно используются двухбайтовые заголовки (из
них 10 битов отводится для DLCI).
В каждом байте заголовка есть так называемый ЕА-бит, определяющий,
что следует за этим байтом — управляющая информация (то есть
следующая часть заголовка) или передаваемые данные. Если ЕА = 0, то за
этим байтом находится следующий байт заголовка. Если ЕА = 1, то это
последний байт заголовка, следовательно, за ним — пользовательские
данные.
Поле DLCI (Data Link Connection Identifier) — это идентификатор
виртуального канала. DLCI может быть уникален в пределах конкретного
сетевого интерфейса, в пределах FR-коммутатора или в пределах целой
сети. Обычно встречается только первый тип уникальности — в
пределах сетевого интерфейса.
Бит C/R определяет тип кадра — команда (С, Command) или ответ (R,
Response). В 3- и 4-байтовых заголовках есть бит DC. Если он
установлен в 0, то последние 6 битов являются частью DLCI. Если он равен 1, то
в последних 6-и битах находится DC-CORE.
Поля DE, FENC и BENC используются для управления трафиком и
поддержания качества обслуживания виртуального канала (QoS).
Поддержка QoS является неоспоримым преимуществом сети Frame Relay.
Данные биты не всегда используются, но и их все-таки рассмотрим. С
помощью полей DE, FENC и BENC мы можем решить проблему
загруженности виртуальных каналов, немного разгрузив их. Проблему загрузки
линии можно сравнить с горлышком бутылки. Воды в бутылке много,
а больше, чем позволяет горлышко, все равно не вытечет. Точно так же
и в сети Frame Relay: в ней существуют «узкие» места — «горлышко
бутылки». Пакетов много, а передать их быстро не получается. Поэтому
пакеты хранятся в буферах памяти, пока не будут отправлены.
Если при передаче кадров пара из них «потеряется», ничего
страшного — их передача будет повторена. Потеря кадра для верхнего уровня
означает запрос на повторную его передачу. В случае потери соединения
оно должно быть повторно установлено. В обоих случаях требуется
повторная передача определенного количества кадров, а значит,
дополнительная нагрузка на сеть.
173

TCP/IP и DNS в теории и на практике. Полное руководство
Перегруженная сеть. Переполнение канала
Когда сеть перегружена, самый маленький трафик может полностью
перегрузить линию, что понизит ее пропускную способность
(производительность) и приведет еще к большим потерям кадров, что, в свою
очередь, повлечет дополнительный трафик (при повторе потерянного
трафика). При использовании протокола TCP соединение будет
возобновляться снова и снова, пока не будет закрыто. Пользователю будет
казаться, что это сетевая неисправность (в принципе по результатам нет
разницы в том, поломка это или перегрузка, пользователь в любом
случае не может воспользоваться сетью).
Решение данной проблемы в снижении скорости виртуального
канала — он будет работать медленно, но будет работать (и со стороны не
будет казаться, что канал не работает).
В случае перегрузки виртуального канала сеть информирует об этом
отправителя установкой бита BECN, а получателя — установкой бита
FECN (см. рис. 4.27).
Заголовок:
DLCN1023
BECN=1
Данные:
DCLI=2
Рис. 4.27. Информирование о загрузке канала
Отправка кадров с установленным битом BECN (или FECN) происходит
в тот момент, когда сеть уже близка к критическому моменту — вот-вот
она начнет отбрасывать все кадры или уже начала это делать. Сеть мо-
174

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
жет предугадывать скопление кадров (перегрузку линии) и заранее
определить линию, которая скоро будет перегружена.
Установка битов BECN и FECN не производится на обычных линиях
связи (каналы данных — data DLCI). Для этой цели зарезервирован
отдельный управляющий канал с номером DLCI = 1023. Данный канал
доставляет кадры к пользователю по сетевому пользовательскому
интерфейсу (интерфейс пользователь-сеть) сети Frame Relay.
Структура сервисного кадра похожа на структуру XID-кадра
протокола HDLC (XID-кадр (U-кадр) используется для передачи
команд/ответов и конфигурационной информации). В нашем случае XID содержит
номер (DLCI) канала, эквивалентного переполненному виртуальному
каналу. Рассмотрим ситуацию, изображенную на рис. 4.28.
Пользовательский маршрутизатор получит бит BECN,
информирующий о том, что виртуальный канал переполнен. Но достаточно ли этого
для снижения загрузки линии? Ведь этот факт нужно передать
протоколу высшего уровня.
В случае с Internet протоколом высшего уровня будет IP (см. рис. 4.28).
Направление маршрутизации
Сетевой интерфейс
пользователя:
пользователь — сеть
ICMP Source Quench
Маршрутизатор
IP
К i ' '" "?':
Канальный
Физический
Рис. 4.28. Переполнение канала и протокол IP
Обработка переполнения канала осуществляется несколькими
механизмами. Протокол IP обладает собственным механизмом обработки
переполнения канала, который основывается на использовании протокола
ICMP. В рамках данного механизма маршрутизатор, отбросивший пакет
175

TCP/IP и DNS в теории и на практике. Полное руководство
из-за переполнения канала, информирует об этом отправителя с
помощью ICMP-дейтаграммы Source Quench.
После получения ICMP получатель снижает скорость ТСР-соедине-
ния (нужно отметить, что Source Quench не используется с протоколом
UDP). Вот так и реализуется механизм управления трафиком в Frame
Relay.
IP no Frame Relay
Если посмотреть на структуру кадра протокола Frame Relay (см.
рис. 4.26), несложно заметить, что отсутствует информация о протоколе
высшего уровня. С помощью подобного поля мы могли довольно
просто помещать пакеты различных сетевых протоколов в кадр канального
уровня (в нашем случае в кадр Frame Relay). Данная проблема
(передача пакетов разных протоколов по Frame Relay) решена в RFC-2427
{Multi-protocol over Frame Relay). Кадр, соответствующий новому
стандарту RFC-2427, представлен на рис. 4.29.
Header асе. to RFC-2427
1 В 2-4 В
1 В 0-1 В 1 В
80i6 = SNAP
8ei6 = IPv6
ccie = IPv4
cfie = PPP
03i6 = кадры данных (ненумерованные)
afie or bfie = кадры XID (см. HDLC)
Рис. 4.29. Передача нескольких протоколов по Frame Relay
Мы видим, что в кадр добавлены:
• Управляющее поле, позаимствованное от протокола HDLC,
поскольку Frame Relay использует ненумерованные кадры; значение
управляющего поля для кадров данных всегда равно 3.
• Поле дополнения — Paging, содержащее двоичные нули, что
гарантирует четную длину заголовка (в соответствии с RFC-2427).
176

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
• Поле NLPID (Network Layer Protocol ID), содержащее номер
протокола высшего уровня. Занимает всего 1 байт. Принимает различные
значения в зависимости от протокола (см. рис. 4.29). Ясно, что этого
значения нам не хватит для обозначения всех протоколов. По этой
причине для SNAP (Sub-network Access Protocol,) используется свое
обозначение — 0x80 (см. рис. 4.30).
1В 0-1 В 1В 3B 2 В
Рис. 4.30. SNAP
Заголовок SNAP содержит поле OUI с организационной
идентификацией, которая назначает номера протоколам более высокого уровня для
поля PID (Protocol Identifier). Например, если в OUI будут одни нули,
в поле PID будут номера, используемые протоколом Ethernet II (то есть
0х08001б для протокола IP). Поскольку SNAP-заголовок имеет длину
3 байта, поле дополнения (Paging) используется только в случае, если
поле заголовка занимает два байта.
Теоретически, используются три формы кадров Frame Relay для
протокола IP:
• Стандартная форма кадра (см. рис. 4.26), не содержащая ни
управляющего поля, ни поля NLPID. IP-дейтаграмма добавляется
непосредственно в поле данных.
• Кадр, соответствующий стандарту RFC 2427, без поля SNAP. Поле
NLPID принимает значение 0хСС16 (протокол IPv4).
• Кадр, соответствующий стандарту RFC 2427, с полем SNAP. Поле
NLPID принимает значение 0х8016, а поле OUI содержит нули,
только если поле PID содержит значение 0х80016.
LMI
Использовать сеть Frame Relay очень просто: можно механически
отправлять кадры в виртуальный канал и получать их на другой стороне,
не заботясь о том, что происходит на самом деле.
177

TCP/IP и DNS в теории и*на практике. Полное руководство
Кроме простой отправки кадров, сеть Frame Relay способна
предоставлять различную статическую информацию о конкретном интерфейсе.
Для этого используется протокол LMI (Local Management Interface).
Для протокола LMI зарезервирован канал DLCI = 0 (см. рис. 4.27).
Конфигурация Frame Relay на маршрутизаторах CISCO
Провайдер Frame Relay, скорее всего, с нашей стороны разместит
синхронный широкополосный модем, к которому мы будем подключаться
с помощью кабеля V.35. Итак, все виртуальные каналы (все DLCI) будут
подключены к одному последовательному интерфейсу (физически они
будут на одном кабеле). Предположим, что они присоединены к
интерфейсу Serial 1.
Один канал DLCI образует так называемый под-интерфейс,
который обозначается в CISCO с помощью суффикса .1, .2 и т. д. (то есть
Serial 1.1).
Протокол Frame Relay может использовать стандартную инкапсуляцию,
как показано на рисунке 4.26 (encapsulation frame-relay), или
инкапсуляцию в соответствии со стандартом RFC-2427 (encapsulation
frame-relay IETF).
Пример (DLCI =112):
Interface Seriall
no ip address
encapsulation frame-relay IETF
frame-relay lmi-type cisco
i
interface Seriall.1 point-to-point
ip address пака
no ip directed-broadcast
frame-relay interface-dlci 112
Резюме
Клиент обычно договаривается с провайдером Frame Relay:
• о том, какие регионы будут соединены виртуальными каналами;
• о длине переданного интервала (CIR) на этих каналах и качестве Вс,
которое определяет, каким будет CIR в час пик;
178

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
• об установке битов BECN и FECN. Маршрутизаторы пользователя
должны знать об этих битах;
• о линии, соединяющей пользователя и провайдера (выделенная
линия, оптоволоконная линия, радио-линия и т. д.). Обычно провайдер
сам предоставляет линии для подключения к сети Frame Relay. He
забудьте уточнить, какой физический интерфейс (V.35, Х.21...) будет
использоваться, чтобы заранее приобрести нужный кабель для
вашего маршрутизатора.
4.6. Локальная сеть (Local Area Networks, LAN)
и протокол Ethernet
Обзор основных технологий локальных сетей
Скорость передачи данных по локальной сети варьируется от 10 Мбит/с
до 1 Гбит/с в зависимости от используемой технологии.
Предназначение локальных сетей заключается в соединении компьютеров и
различных сетевых устройств (например, маршрутизаторов), расположенных
на относительно небольшом расстоянии друг от друга (например, в
пределах зданий кампуса). При использовании оптических кабелей
локальные сети могут покрывать несколько квадратных километров.
Имеется множество технологий, используемых для построения
локальных сетей. Но не все они часто используются. Если быть более точным,
то наиболее распространенными являются технологии Ethernet
(наиболее популярна) и FDDI (менее популярна, чем Ethernet, но все-таки
используется, а не «умерла», как технология IBM Token Ring)
Для организации локальной сети нам, кроме нескольких компьютеров,
нужны соответствующие сетевые адаптеры. Протоколы канального
уровня локальной сети частично реализуются непосредственно
сетевыми адаптерами, поэтому без них не обойтись.
Локальная сеть состоит из следующих частей:
• Сетевого кабеля — данная часть относится к физическому уровню.
Можно сказать, что это очень важная часть, так как по ней
передаются наши данные.
• Сетевых адаптеров — для подключения к среде передачи (или к
активному элементу сети — об этом позже) используются именно
179

TCP/IP и DNS в теории и на практике. Полное руководство
i ■—
сетевые адаптеры. Они реализуют функции как физического, так
и канального уровня.
• Канального протокола и его программного воплощения, то есть
драйверы операционной системы.
Независимо друг от друга было разработано несколько технологий
локальных сетей. С того момента прошло много времени, но
некоторые технологии, например, Ethernet II, до сих пор успешно
используются.
На рассвете эры персональных компьютеров на рынке локальных сетей
был такой же беспорядок, как и на рынке самих компьютеров: каждый
разработчик выпускал свой стандарт локальной сети, свои сетевые
адаптеры и т. д.
Если с персональными компьютерами благодаря усилиям IBM
ситуация стабилизировалась, то ситуация с сетью требовала вмешательства
института IEEE (Institute of Electrical and Electronics Engineers),
разработавшего единые сетевые стандарты (то есть Ethernet, Arcnet, Token
Ring и др.). Данные стандарты описывают МАС-уровень (Medium
Access Control, уровень управления доступом к среде передачи данных)
для каждого типа сети:
• IEEE 802.3 для Ethernet;
• IEEE 802.4 для Token Bus;
• IEEE 802.5 для Token Ring и т. д.
Также был создан вспомогательный стандарт, IEEE 802.2, описывающий
логический канальный уровень (Logical Link Control, LLC) для всех
сетевых технологий (см. рис. 4.31).
Канальный
уровень
Физический
уровень
ISO OSI
LLC
MAC
Физический
уровень
IEEE
IEE 802.2
IEEE 802.3, 802.4, 802.5.
Рис. 4.31. Архитектура IEEE802
180

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Из рис. 4.31 мы видим, что канальный уровень LAN разделен на два
подуровня. Нижний (МАС-уровень) частично перекрывает физический
уровень, предоставляя доступ к среде передачи данных. Верхний
уровень (LLC) позволяет начать, завершить логическое соединение между
двумя станциями локальной сети и управлять им.
Международная организация по стандартизации (ISO) не могла
оставаться в стороне и выпустила свои стандарты, точнее — просто
приняла стандарты IEEE. Итак, ISO 8802-2 - это стандарт IEEE 802.2, a ISO
8802-3 - это IEEE 802.3 и т. д.
Технология Ethernet
Технология Ethernet является наиболее распространенной технологией
локальных сетей. Она была разработана компаниями DEC, Intel и Xerox.
Ее 10-мегагерцевая версия также известна как Ethernet II или DIX (по
первым буквам создавших ее компаниям). Позже технология Ethernet
была немного упорядочена стандартом IEEE 802.3.
ISO-стандарт данной технологии был опубликован под названием ISO
8802-3. Формат кадров исходного стандарта Ethernet II немного
отличается от стандарта ISO 8802-3. Со временем стандарт IEEE 802.3 стал
описывать 100-мегагерцевую версию — Fast Ethernet, a IEEE 802.3z —
Gigabit Ethernet (1 ГГц).
Сеть Ethernet обычно использует толстый коаксиальный кабель
10BASE-5. Длина сегмента локальной сети при использовании этого
кабеля может достигать 500 м. Сегмент сети на основе толстого
коаксиального кабеля представляет собой обычный коаксиальный кабель
определенной длины. Это общая среда передачи данных. К ней подключаются
трансиверы, а к ним, в свою очередь, сетевые платы компьютера.
Трансивер (transceiver = transmitter + receiver, то есть передатчик/
приемник) соединяется с сетевым адаптером с помощью AUI-кабеля
(Attachment Unit Interface) длиной до 50 м. А для присоединения к
интерфейсу AUI используется разъем CANNON-15 (DB-15).
Стандарт 10BASE-5 подразумевает передачу данных по сети с частотой
10 МГц (это теоретически максимальная частота передачи). Что же
касается скорости передачи данных, то она равна 10 Мбит/с
(максимальная теоретическая скорость).
181

TCP/IP и DNS в теории и на практике. Полное руководство
J'
й
Маршрутизатор
э
Принтер
Рис. 4.32. Сегмент Ethernet на основе коаксиального кабеля
Следующая веха в развитии Ethernet — это применение тонкого
коаксиального кабеля для передачи данных. Тонкий коаксиальный кабель
прерывается с помощью BNC Т-коннектора в местах подключения к
сетевому адаптеру.
Тонкий Ethernet, известный также как 10Base-2, использует сегменты
до 185 м. Применяя специальные сетевые адаптеры, можно продлить
сегмент до 300-400 м.
С помощью повторителей сегмент локальной сети разбивается на подсег-
менты. Повторитель — это устройство с двумя (или более)
интерфейсами, предназначенное для повторения кадров одного интерфейса на все
остальные. Обычно у повторителя есть порты двух типов — AUI и BNC,
поэтому их можно использовать для соединения сегментов из толстого
и тонкого коаксиала.
Технология Ethernet позволяет использовать для передачи данных
также и оптический кабель. Данный стандарт называется 10Base-F.
Преимущество оптического кабеля заключается в том, что расстояние
между двумя повторителями может достигать 1 км.
Еще один стандарт технологии Ethernet — 10Base-T. Он позволяет
использовать витую пару в качестве среды передачи данных. В этом случае
немного изменяется топология сети. Если во всех предыдущих случаях
компьютеры тем или иным способом (например, с помощью трансиве-
ров или Т-коннекторов) подключались к общему кабелю (топология —
общая шина), то теперь каждый компьютер подключается к
центральному элементу сети — концентратору — с помощью собственного кабеля
182

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
.
1
1
Сегмент 1
■ ^^-1—^^
i
—м ювторитель i—
/
Сегмент 3
i
о
L
гме
5
^
" 1
moBTopMTej
ribV
Рис. 4.33. Локальная сеть, состоящая из нескольких сегментов
(витой пары). В случае повреждения кабеля сеть не прекращает свою
работу — просто становится не виден один из ее узлов. В случае
использования общей шины при повреждении общего кабеля сеть теряет
работоспособность.
Концентратор можно рассматривать как повторитель (repeater). Только
повторитель соединяет сегменты сети, а концентратор может соединять
как их, так и сами компьютеры. Грубо говоря, концентратор — это
многопортовый повторитель, так как число портов концентратора больше или
равно количеству компьютеров в данном сегменте сети.
Повторитель
Повторитель
Рис. 4.34. Хаб(повторитель)
183

TCP/IP и DNS в теории и на практике. Полное руководство
Концентратор работает точно так же, как и повторитель: получив сигнал
из одного порта, он повторяет его на все порты. Как видите, изменилась
только физическая топология сети, логическая осталась без изменения,
так как это общая шина. Как и в случае с тонким или толстым коаксиа-
лом отправленный одним компьютером пакет получают все
компьютеры сети. Повторитель также называют хабом (hub).
[о] |оооооо| Щ
Повторитель
В
щ
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
щ
Рис. 4.35. Повторитель для витой пары
Кроме стандарта 1 OBase-T, витую пару используют более быстрые версии
Ethernet: стандарт 100Base-TX (Fast Ethernet, 100 Мбит/с) и 1000Base-CX
(Gigabit Ethernet, 1000 Мбит/с).
Длина участка кабеля витой пары между повторителем и станцией
обычно составляет 100 м.
С точки зрения сетевой модели, повторитель (хаб) работает на
физическом уровне. Связь по сети с использованием повторителей абсолютно
прозрачна, то есть компьютеры в сети даже и не подозревают о
существовании каких-то повторителей.
Кроме повторителя, соединять сегменты локальной сети может другое
устройство — мост (bridge). Данное устройство используется для
локализации трафика. Как работает повторитель? Он просто повторяет
кадры, полученные из одного интерфейса, на все остальные.
184

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Мост — это специализированный компьютер, работающий с таблицей
МАС-адресов всей локальной сети. Например, пусть у нас есть три
сегмента — А, В, С. Если компьютер из сегмента А отправляет данные
компьютеру из этого же сегмента, то кадры не будут отправлены в сегменты
В и С (а повторитель отправил бы!). Использование моста позволяет
существенно снизить нагрузку на сеть в целом.
Канальный
Физический
Канальный
Физический
Канальный
Физический
Канальный
Физический
000000
00
Мост
Физический
Физический
Сегмент 1
Физический
Физический
*-^*
ЗЙ
>. я y^j^v'
|оооо0о||оо|
Сегмент 2
Физический
Физический
Физический
/
в
ш
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
BI
Повторитель
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
Повторитель
■
ш
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
щ
Рис. 4.36. Мост
Самое интересное, что мост не требует настройки — его нужно только
подключить к сегментам сети. Далее служебная таблица моста
строится автоматически. Сначала мост работает в режиме простого
повторителя, то есть повторяет все кадры на все интерфейсы. Но делает он это
не просто так: он собирает информацию о структуре сети, он запомина-
185

TCP/IP и DNS в теории и на практике. Полное руководство
ет, через какой порт на него поступил кадр от каждого компьютера сети
и впоследствии передает информацию на нужный порт. Собрав всю
необходимую информацию, мост перед отправкой кадра уже знает, на
какой интерфейс его следует направить.
Итак, мы выяснили, что повторители — это ядро сегментов локальной
сети. Они используются для соединения компьютеров между собой
внутри сегмента, а мосты — для соединения разных сегментов сети.
Использование моста, как уже отмечалось, позволяет локализовать трафик
и снизить нагрузку на сеть.
А можно ли локализовать трафик внутри сегмента? То есть отправлять
кадры не всем, а только определенному компьютеру, которому они
предназначены? Да, можно. Для этого используется коммутатор (switch).
Установка коммутатора в сегмент сети не требует никакой
переработки — просто отключается концентратор, и на его место устанавливается
коммутатор, после чего к нему подключаются все компьютеры сегмента.
Коммутатор работает подобно мосту, только используется не для
соединения сегментов сети, а для соединения компьютеров внутри сегмента.
Коммутатор запоминает, какой компьютер подключен к какому порту
и впоследствии отправляет кадры не на все, а только на определенный
порт, к которому подключен нужный компьютер.
Коммутаторы более мощны и гибки, чем мосты. Они могут повторять
кадры не только между отдельными сегментами Ethernet, но и между
сегментами сети с различными технологиями, например, между Ethernet
и Fast Ethernet, Ethernet и FDDI. При этом коммутатор не только
изменяет форматы кадров, скажем, при передаче кадра из сегмента Fast
Ethernet в сегмент FDDI, но и справляется с разницей в скорости с
помощью специальных буферов памяти.
Для передачи данных между двумя станциями в условиях общей
среды передачи данных используется протокол CSMA/CD (Carrier Sense
Multiply Access with collision detection). Согласно этому протоколу, все
станции локальной сети равны между собой. Когда какая-нибудь
станция хочет передать данные, она обращается к среде передачи данных и,
если та свободна, начинает передачу.
В один момент времени данными могут обмениваться только две
станции, остальные ожидают освобождения среды передачи данных. Если
какая-нибудь третья станция начинает передачу (а такое иногда
случается), происходит коллизия. При обнаружении коллизий все станции
186

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
н
ж
Приклад.
Представ.
Сеансовый
Транспорт.
Сетевой
Канальный
Физический
а
Рис. 4.37. Коммутатор
должны прекратить передачу и возобновить ее через случайно
выбранный интервал времени. Коллизии — это нормальное явление для
Ethernet-сети, в них нет ничего страшного.
Коллизии вообще не встречаются, если в нашей сети только две
станции. Также коллизий нет, если две станции соединяются с помощью
витой пары непосредственно, без использования концентратора — это
так называемый свободный от коллизий сегмент. В этом случае сетевые
адаптеры переключаются в полнодуплексный режим, в котором они
могут одновременно принимать и передавать данные. В таких сегментах
скорость передачи данных достигает своего теоретического максимума.
Также свободным от коллизий является сегмент между компьютером
и коммутатором.
Структура кадра Ethernet зависит от используемого стандарта,
структура кадра Ethernet II изображена на рис. 4.38.
Кадр Ethernet II начинается синхронизирующей преамбулой (является
частью физического уровня), которая используется для синхронизации
кадров. А заканчивается контрольной суммой, которая используется
для проверки целостности кадра.
187

TCP/IP и DNS в теории и на практике. Полное руководство
Преамбула
8В
Адрес получателя
6В
Адрес отправителя
6В
Протокол
2В
Контрольная
сумма - 4В
Рис. 4.3в. Кадр Ethernet II
Кроме того, она содержит 6-байтовые поля адреса отправителя и
получателя, а также поля протокола, содержащее номер протокола высшего
уровня — IPv4, ARP или RARP (см. рис. 4.38) Поле данных содержит
передаваемые данные, его длина минимум 46 байтов.
Сеть может использоваться для групповой рассылки кадров. Адрес
назначения может быть длиной 2 или 6 байтов. Обычно всегда
используются только 6-байтовые поля.
Существует два способа групповой рассылки: multicast или broadcast.
Первый бит старшего байта адреса назначения определяет, какой это
адрес: индивидуальный (для одного компьютера) или групповой
(Multicast).
Групповой адрес может предназначаться группе компьютеров или всей
сети. Если адрес состоит из всех единиц, то есть в шестнадцатеричной
системе равен OxFFFFFFFFFF, то это широковещательный адрес
(broadcast), который предназначается всем компьютерам сети.
ID производителя
ID карты, уникален в пределах
серии производителя
1111111
1111111
1111111
1111111
1111111
1111111
1111111
1111111
1111111
1111111
1111111
I И I I I I
• 1=broadcast/multlcast, 0=unlcast
Рис. 4.39. Поле адреса назначения (получателя)
188

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Давайте рассмотрим кадр Ethernet II, захваченный программой MS
Network Monitor (см. листинг 4.4).
Листинг 4.4. Кадр Ethernet II, захваченный программой MS Network Monitor
+ FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
ETHERNET: Destination address : 00000C31D211
ETHERNET: 0 = Individual address
ETHERNET: 0. = Universally administered address
ETHERNET: Source address : 0010A4F18B3E
ETHERNET: 0 = No routing information present
ETHERNET: 0. = Universally administered address
ETHERNET: Frame Length : 74 (0x0 04A)
ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol)
ETHERNET: Ethernet Data: Number of data bytes remaining = 60 (ОхООЗС)
+ IP: ID = ОхАВОб; Proto = ICMP; Len: 60
+ ICMP: Echo, From 195.47.37.200 To 194.149.105.18
Формат кадра протокола ISO 8802-3 немного отличается от Ethernet II
(см. рис. 4.40).
Преамбула
8В
Адрес получателя
6В
Адрес отправителя
6В
Длина
2В
Контрольная
сумма - 4В
Рис. 4.40. Формат кадра протокола IEEE802.3 (ISO 8802-3)
Поле данных (см. рис. 4.41) может содержать не только данные, но и
пакет протокола ISO 8802-2, заголовок которого может быть расширен
двумя или более полями SNAP.
Попросту говоря, станции могут обмениваться информацией с
помощью следующих типов кадров:
• Обычные кадры (Raw 802.3) протокола ISO 8802-3 (без ISO 8802-2
и SNAP).
• Кадры протокола ISO 8802-3, содержащие инкапсулированные
пакеты ISO 8802-2 без SNAP (кадр Ethernet II, DIX).
• Кадры протокола ISO 8802-3 с инкапсулированными пакетами ISO
8802-3 и SNAP (кадр Ethernet SNAP).
189

TCP/IP и DNS в теории и на практике. Полное руководство
Поле Длина (Length) содержит длину передаваемых данных, то есть
длину поля данных в кадре.
Преамбула
8В
Адрес получателя
6В
Адрес отправителя
6В
DSAP
1В |
SSAP
1В
Упр.поле
1В
Длина
2В
SNAP
*
Код орг.
ЗВ
AAie AAie ОЗ16
ISO 8802-2
Протокол
2В
Контрольная
сумма - 4В
Данные,;
46-1500В
0800,6
IP-пакет
080616
J*;\^4;A
8035i6
RARP
Рис. 4.41. ISO 8802-2 и SNAP
Рассмотрим пример кадра третьего типа (Ethernet SNAP), захваченного
сетевым монитором (листинг 4.5).
Листинг 4.5. Кадр Ethernet SNAP
+ FRAME: Base frame properties
ETHERNET: 802.3 Length = 60
ETHERNET:. Destination address : 010081000100
ETHERNET: 1 = Group address
ETHERNET: 0. = Universally administered address
ETHERNET: Source address : 0000810C3D50
ETHERNET: 0 = No routing information present
ETHERNET: 0. = Universally administered address
ETHERNET: Frame Length : 60 (ОхООЗС)
ETHERNET: Data Length : 0x0013 (19)
ETHERNET: Ethernet Data: Number of data tytes rarairiing = 46 (0x002E)
LLC: UI DSAP=0xAA SSAP=0xAA C
LLC: DSAP = OxAA : INDIVIDUAL : Sub-Network Access Protocol (SNAP)
LLC: SSAP = OxAA: COMMAND : Sub-Network Access Protocol (SNAP)
LLC: Frame Category: Unnumbered Frame
190

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
LLC: Command = UI
LLC: LLC Data: Number of data bytes remaining = 43 (0x002B)
SNAP: ETYPE = 0x01A2
SNAP: Snap Organization code = 00 00 81
SNAP: Snap etype : 0x01A2
SNAP: Snap Data: Number of data bytes remaining =38 (0x0026)
Выбранный нами кадр не содержит IP-дейтаграммы, как можно было
ожидать. Технология Ethernet II получила наибольшее
распространение, именно поэтому каждая станция должна поддерживать протокол
Ethernet П.
Вернемся к описанию полей. Поля Destination Server Access Point
(DSAP)/Source Service Access Point (SSAP) указывают
идентификаторы исходного и результирующего приложения, которые отправляют/
принимают кадры. DSAP указывает номер (зарегистрированный в
системе) приложения, которому будет передан кадр после его получения.
Управляющее поле аналогично управляющему полю протокола HDCL.
Снова мы сталкиваемся с U, I и S-кадрами. Кадры нумеруются,
поэтому при потере кадра мы точно знаем его номер и можем запросить его
повторную передачу по номеру. В случае с протоколом IP используются
только U-кадры с битом P/F = 0, то есть управляющее поле содержит
значение 0х031(., как в случае с протоколом РРР.
Заголовок SNAP (Sub-Network Access Protocol) используется
специфическими протоколами высших уровней, по сути, SNAP — это аналог
поля Протокол (Protocol), которое используется в Ethernet П.
Заголовок SNAP состоит из двух подполей. Третий байт поля Organization
code (см. листинг кадра выше) указывает организацию, которая
администрирует назначение номеров протоколов высшего уровня.
4.7. Беспроводные локальные сети
(Wireless Local Area Networks, WLAN)
4.7.1. Обзор технологий беспроводных локальных сетей
В последнее время довольно уверенно развиваются беспроводные
локальные сети — WLAN. Тому есть причины:
191

TCP/IP и DNS в теории й на практике. Полное руководство
• Мобильность — пользователь может свободно перемещаться,
причем его перемещение не ограничено парой метров кабеля, как в
классическом варианте локальной сети.
• Быстрая и простая установка такой сети — вам не нужно
прокладывать и обжимать кабели, делать в стенах отверстия и т. д.
• Дешевизна построения сети (вам не нужен ни кабель, ни
специальный инструмент, ни дополнительное оборудование для его монтажа).
• Масштабируемость — выбрав подходящую антенну, вы можете
покрыть дополнительную территорию или же просто повысить
пропускную способность.
• Роуминг — очень важная функция WLAN-сетей. Если настроен роу-
минг, мобильные передвигающиеся станции (например,
пользователи ноутбуков) могут передвигаться из одной покрытой сетью
области в другую. Мобильные станции регистрируются на точках доступа
(access point), которые связаны с базовой сетью.
Обычно WLAN используются:
• в помещениях, где невозможно проложить кабели и установить
разъемы, например, на производстве (на заводе) или в больницах;
• во временных сетях, например, сети какой-нибудь выставки или
конференции;
• в обычных сетях, где комбинируются оба способа доступа:
обычный (с помощью кабеля) для стационарных компьютеров и
беспроводный.
• для связи отдельных филиалов компаний в пределах одного
города: использование технологии WLAN (например, Radio Ethernet)
дешевле, чем организация выделенной линии, а главное, скорость
доступа будет значительно выше, чем при использовании
классической выделенной линии со скоростью 33.6 Кбит/с, а также
организация WLAN занимает намного меньше времени, чем организация
выделенной линии;
• для подключения к Интернету в отделенных районах города, где
нужно обеспечить высокую скорость доступа к Интернету и
невозможно организовать выделенную линию.
192

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Сети WLAN используют радиотрансляцию на частоте 2.4 ГГц. Для
использования WLAN обычно не требуется лицензия на широковещание.
Вы можете подключаться к другим беспроводным сетям, которые
находятся в пределах досягаемости вашей антенны, например, к сети вашего
интернет-провайдера.
При использовании WLAN возникает проблема рабочего диапазона.
Ведь диапазон 2.4 ГГц часто используют другие устройства, например,
те же микроволновки. К тому же сигналы 2.4 ГГц плохо проходят через
преграды, например, стены или тело человека.
Спецификация на беспроводные сети изложена в стандарте IEEE 802.11.
WLAN-сети используют протокол доступа к среде (Media Access
Protocol, MAC) вместе с протоколом Carrier Sense Multiple Access/Collision
Avoidance — CSMA/CA — метод коллективного доступа с опознаванием
несущей и предотвращением коллизий.
Данный метод является производным от метода GSMA/CD (то же
самое, но не «предотвращение коллизий», а «обнаружение коллизий»),
известного нам из Ethernet. В отличие от Ethernet, беспроводные
передатчики не обнаруживают коллизии, для их обнаружения используется
система подтверждения.
Протокол CSMA/CA также используется для ассоциации и повторной
ассоциации конечной станции с точкой доступа.
Сигнал может передаваться «по воздуху» следующими способами:
• Direct Sequence Spread Spectrum (DSSS). DSSS используется при
частоте радиоволн в диапазоне от 2.4 до 2.4835 ГГц. Передатчик
преобразует поток битов данных в поток символов, каждый символ
представляет группу из одного или более битов. Используя
модуляцию QPSK (Quadrature Phase Shift Keying), передатчик модулирует
или умножает каждый символ на псевдослучайную
последовательность, что искусственно увеличивает ширину полосы частот. DSSS
делит полосу на 14 каналов по 22 МГц каждый, которые частично
перекрываются. В одной полосе есть только три абсолютно
независимых канала.
• Frequency Hopping Spread Spectrum (FHSS) Диапазон радиоволн —
2.4-2.4835 ГГц. При этом FHSS-передатчик передает один или более
пакетов данных по одной полосе (полоса делится на 75 подканалов,
каждый по 1 МГц), а затем переходит на другую. Это метод
переходов (hops). Следующая частота выбирается не случайно, исполь-
7 Зак. 518
193

TCP/IP и DNS в теории и на практике. Полное руководство
зуется определенный алгоритм, по которому работают передатчик
и приемник (перед переходом полоса уже известна).
• Diffused Infrared (DFIR) — использование инфракрасных волн —
Поскольку инфракрасные лучи не проходят через твердые тела
(например, стены), данный метод ограничивает WLAN-сеть
пределами одного офиса или другого небольшого открытого пространства.
Даже в открытом пространстве нельзя использовать данный метод
для передачи на большие расстояния.
Чтобы улучшить функциональность WLAN-сетей, разрабатывались все
новые и новые стандарты. Один из них — стандарт IEEE 802.1 lb,
известный также как Wi-Fi (Wireless Fidelity). Данный стандарт позволяет
передавать данные с теоретической скоростью в 11 Мбит/с по полосе
в 2.4 ГГц.
На самом деле пропускная способность примерно на 40% ниже,
поскольку зависит от многих факторов: погодных условий (при передаче
в открытом пространстве), количества станций, транспортного
протокола, длины передаваемых файлов и т. д.
4.7.2. Типичная конфигурация WLAN
Одноранговые сети
Беспроводные станции непосредственно связаны друг с другом. Точки
доступа не используются. Данный метод позволяет соединить
максимум 8-10 компьютеров.
Рис. 4.42. Одноранговая беспроводная сеть
Access Point — АР
Точка доступа — это базовая радиостанция и мост данных. Точка
доступа всегда подключена к сети (например, через Ethernet). Точки доступа
также выполняют некоторые сервисные функции, например, функции
брандмауэра, функции шифрования данных. К одной точке доступа
могут подключиться 15-38 станций.
194

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
Рис. 4.43. Точка доступа
Роуминг (несколько точек доступа)
Если роуминг активизирован, конечные станции могут свободно
перемещаться от одной точки доступа к другой.
Рис. 4.44. Роуминг
Магистральное соединение точка-точка
Соединение двух сетей с использованием точек доступа — это и есть
магистральное (backbone) соединение точка-точка. Такие соединения
обычно высокоскоростные, так как им нужно обслуживать данные не
отдельных стаций, а целых сетей. Обычно такое соединение типично
для связи на открытом пространстве, например, соединение сетей двух
195

TCP/IP и DNS в теории и на практике. Полное руководство
подразделений компании в пределах города с использованием
подходящей антенны.
■
в
Рис. 4.45. Магистральное соединение точка-точка
4.7.3. Антенны
Сети WLAN используются не только в пределах каких-либо помещений,
обычно они служат для «наружных» соединений, то есть беспроводных
соединений, выходящих за пределы одного здания.
Для передачи данных «по воздуху» используются антенны, которые,
в отличие от привычных нам телевизионных, оборудованы мощными
передатчиками и приемниками (то есть могут передавать данные на
довольно большие расстояния). Антенны обычно работают в
полудуплексном режиме, но можно применить полнодуплексный режим, используя
для соединения пару параллельных антенн: одну для передачи, а другую
для приема.
Антенны используют горизонтальную, вертикальную или круговую
поляризацию. Вертикальная или горизонтальная поляризация
устанавливается при настройке однонаправленной (то есть служащей для
соединения в одном направлении) антенны, а круговая используется
совершенно другим типом антенны (спиральной антенной).
Для соединений точка-точка применяются параболы различных
диаметров. Для множественных соединения точка-много_точек (point+to-
196

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
multipoint), используются Yagi-антенны; то есть горизонтальные
многонаправленные антенны или секторные (круговые) антенны.
При наружном использовании антенн нужно учесть много факторов:
направление передачи данных, максимальную высоту объектов,
расположенных между антеннами. Например, если вы хотите соединить с
помощью антенн два двухэтажных здания, а между ними находится
девятиэтажка, скорее всего, у вас ничего не получится.
4.7.4. Безопасность WLAN
До недавнего времени WLAN использовались только для небезопасных
соединений. Давайте рассмотрим некоторые WLAN-функции,
обеспечивающие безопасность передаваемых данных.
Служба Установки ID — Service Set ID (SSID)
SSID — это ссылка на точку доступа (другое название — «имя сети»). ID
сети постоянно передается точке доступа, что позволяет пользователю
выбрать подходящую сеть. Это не очень безопасный способ, поскольку
SSID может быть взломан хакером. Более безопасный вариант — ручная
настройка SSID на каждой конечной станции.
Wired Equivalent Privacy (WEP)
Протокол WEP — это часть стандарта IEEE 802.11b. Протокол
предоставляет средства аутентификации между станциями и средства
шифрования предоставляемых данных. WEP использует симметрическое
шифрование.
Для аутентификации конечных станций используются идентичные 40-
битовые секретные ключи, которые известны обеим станциям. Речь идет
об односторонней аутентификации конечной станции (устройства), а не
о пользовательской аутентификации.
Для шифрования данных используется 64-битовый ключ (иногда
можно использовать 128-битовый). Ключ содержит ключ пользователя и
изменяемый вектор инициализации длиной 24 бита. Вектор
инициализации изменяется с каждым переданным пакетом. В качестве алгоритма
шифрования используется алгоритм RC4.
197

TCP/IP и DNS в теории и на практике. Полное руководство
Безопасность протокола WEP — довольно спорный вопрос, поскольку
перехваченные данные могут быть легко расшифрованы с помощью
различных программ, например, WEPcrack или AirShort.
IEEE 802.1Х
Поскольку безопасность WLAN оставляет желать лучшего, был
разработан стандарт IEEE 802.1Х(см. рис. 4.46), позволяющий увеличить
уровень безопасности беспроводных сетей. Данный стандарт
подразумевает использование аутентификации пользователя, шифрования
и безопасного распространения ключей.
«у*
» поддержка Х.802.11
> поддержка Х.802.1Х
» поддержка EAP-TLS
• сертификат
Точка
доступа
RADIUS server
* вся информация о пользователе хранится в БД
• сертификат - это поле записи, в котором
хранится информация о пользователе
С
802.11 Аутентификация
>
802.1X EAP-TLS Аутентификация
С>
Пользователь опознан,
отправка ключей
<!
Пользователь ОК, отправка WEP-ключей
Безопасная передача данных
Рис 4.46. Пример использования стандарта IEEE802.1Х
198

Глава 4. Канальный уровень. Протоколы, стандарты, безопасность
4.7.5. Фиксированный беспроводный доступ
(Fixed Wireless Access, FWA)
Обзор технологии
FWA-сети (также они называются беспроводными локальными
петлями) — технология беспроводного магистрального соединения типа
point-to-multipoint. FWA — это альтернативное решение «последней
мили», предоставляемое телекоммуникационными провайдерами как
альтернативный способ доступа конечных пользователей. Основная
особенность данной технологии — высокая производительность
предоставленной полосы, что обеспечивает высокоскоростную передачу
данных, голосовую связь и другие телекоммуникационные сервисы.
Это сотовая система с большим числом взаимно накладывающихся
ячеек, работающая подобно GSM-сети с конечными терминалами (могут
устанавливаться в здании клиента), к которым подключаются базовые
станции.
Базовая станция — это компьютер или другое устройство, оснащенное
антенной, способной передавать сигнал на 360° в радиусе 7-9 км.
Передача сигнала может быть разделена на секторы в диапазоне от 15° до
90°. Используя распределение (планирование) частот, можно увеличить
общую емкость базовой станции и более оптимально использовать
диапазон частот.
Одна базовая станция с одним или более сектором формируют модуль
FWA. FWA формируется широкополосной сетью с полосами в 26 ГГц.
FWA-операторы могут предоставлять следующие услуги:
• Быстрый доступ к Интернету (до 8 Mbps).
• VPN (virtual private networks) — виртуальные частные сети.
• Высокоскоростная передача данных большого объема.
• Голосовые сервисы, основывающиеся на принципе euroISDN30.
• Сервисы конференции.
• Мультимедиа-сервисы.
Отличия между FWA и WLAN
Эти технологии используются для достижения разных целей, поэтому
FWA отличается от WLAN следующим:
199

TCP/IP и DNS в теории и на практике. Полное руководство
• Она не поддерживает мобильные станции и роуминг.
• Для FWA нужны специальные лицензии на использование частот.
• Скорость передачи между конечными станциями выше, но
расстояние между ними меньше.
• FWA можно использовать для передачи голоса.
• Цена конечной и базовой станции существенно отличается от
WLAN-устройств (выше в 2 раза).
Основные преимущества FWA
В качестве преимуществ FWA можно отметить следующие:
• Гарантированная полоса пропускания.
• Высокая степень надежности передачи (99.995%), что сравнимо
с оптическими кабелями.
• Большая гибкость.
• Эффективное использование спектра частот.

Глава 5
i-
m
ПРОТОКОЛ IP
(INTERNET PROTOCOL)
НАЗНАЧЕНИЕ И ФУНКЦИИ
ПРОТОКОЛАМ
УСТРОЙСТВО IP-ДЕЙТАГРАММЫ
ПРОТОКОЛ МЕЖСЕТЕВЫХ
УПРАВЛЯЮЩИХ СООБЩЕНИЙ
(INTERENT CONTROL MESSAGE
PROTOCOL, ICMP)
ФРАГМЕНТАЦИЯ IP-ДЕЙТАГРАММ И
УЯЗВИМОСТИ, ЕЮ ОБУСЛОВЛЕННЫЕ
ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ
IP-ЗАГОЛОВКА — ПОДВОДНЫЕ КАМНИ
БЕЗОПАСНОСТИ
ПРОТОКОЛЫ ARP И RARP
ПРОТОКОЛ IGMP (INTERNET GROUP
MANAGEMENT PROTOCOL)
МУЛЬТИКАСТИНГ И КАНАЛЬНЫЙ
ПРОТОКОЛ
TCP/IP и DNS в теории и на практике. Полное руководство

5.1. Назначение и функции протокола IP
Функции и особенности IP
Функции протокола IP определены в стандарте RFC-791 следующим
образом: «Протокол IP обеспечивает передачу блоков данных,
называемых дейтаграммами, от отправителя к получателям, где отправители
и получатели являются компьютерами, идентифицируемыми адресами
фиксированной длины (IP-адресами). Протокол IP обеспечивает при
необходимости также фрагментацию и сборку дейтаграмм для передачи
данных через сети с малым размером пакетов».
Протокол IP является ненадежным протоколом без установления
соединения. Это означает, что протокол IP не подтверждает доставку
данных, не контролирует целостность полученных данных и не производит
операцию квитирования (handshaking) — обмена служебными
сообщениями, подтверждающими установку соединения с узлом назначения
и его готовность к приему данных. Протокол IP обрабатывает каждую
дейтаграмму как независимую единицу, не имеющую связи ни с
какими другими дейтаграммами в Интернете. После того, как дейтаграмма
отправляется в сеть, ее дальнейшая судьба никак не контролируется
отправителем (на уровне протокола IP). Если дейтаграмма не может быть
доставлена, она уничтожается. Узел, уничтоживший дейтаграмму, может
отправить по обратному адресу 1СМР-сообщение о причине сбоя [1].
Гарантию правильной передачи данных предоставляют протоколы
вышестоящего уровня (например, протокол TCP), которые имеют для
этого необходимые механизмы.
Одна из основных задач, решаемых протоколом IP, — маршрутизация
дейтаграмм, то есть определение пути следования дейтаграммы от
одного узла сети к другому на основании адреса получателя.

Глава 5. Протокол IP (Internet Protocol)
Обычно данные передаются (маршрутизируются) от отправителя к
получателю через множество маршрутизаторов. Каждый из них передает
данные следующему и т. д. по цепочке. Переход данных от одного
маршрутизатора к другому в англоязычной литературе называется хопом
(hop), в русскоязычной — прыжком или переходом.
Протокол IP — это протокол, обеспечивающий соединение отдельных
(часто локальных) сетей в глобальную сеть — Internet. Отсюда
произошло и название протокола — InterNet Protocol, то есть протокол,
соединяющий сети. Позже слово InterNet было заменено словом Internet,
что немного изменило суть названия.
Рис. 5.1. InterNet Protocol
Вспомогательные протоколы, входящие в состав IP
Протокол IP состоит из нескольких отдельных протоколов:
• Собственно протокол IP.
• Протокол ICMP (Internet Control Message Protocol) — протокол
межсетевых управляющих сообщений.
• Протокол IGMP (Internet Group Management Protocol) — протокол
межсетевого группового управления.
• Протокол ARP (Address Resolution Protocol) и RARP (Reverse
Address Resolution Protocol) — протокол определения адреса (ARP)
203

TCP/IP и DNS в теории и на практике. Полное руководство
преобразует IP-адрес в физический (MAC) адрес; протокол RARP
используется для обратного преобразования.
Принимая во внимание, что в канальном протоколе каждый сетевой
интерфейс имеет свой физический адрес (который для локальных сетей
состоит из 6-ти байтов), в протоколе IP каждый сетевой интерфейс
имеет, по крайней мере, один IP-адрес.
IP-адрес для протокола IP версии 4 представляется четырьмя байтами,
а для протокола IP версии 6 (IPv6) — шестнадцатью байтами.
IP- уровень: IP-адрес
Канальный уровень: канальный адрес
Локальная сеть
Рис. 5.2. Канальные адреса и IP-адреса
Маршрутизатор и обработка IP-дейтаграмм
Основным элементом, использующимся для построения глобальных
сетей (WAN), является маршрутизатор, с помощью которого отдельные
локальные сети (LAN) подключаются к глобальной сети. В качестве
маршрутизатора может использоваться компьютер с несколькими
сетевыми интерфейсами и подходящей операционной системой.
Слово «маршрутизатор» имеет два значения. Во-первых,
маршрутизатор — это компьютер (или специальное устройство), который управляет
передачей пакетов между двумя сетевыми интерфейсами. Второе
значение более практично: маршрутизатор — специальное устройство,
выбирающее маршрут для передачи данных. Ведь можно просто передать
пакет, полученный с какого-то интерфейса на один из доступных
интерфейсов. А можно выбрать оптимальный адресат для передачи пакета
(если оба интерфейса «идут» в одну сеть, то целесообразнее передать
пакет на менее загруженный интерфейс).
Возможность передачи пакетов между сетевыми интерфейсами
маршрутизатора называется перенаправлением (forwarding) пакетов. С
данной функцией без особых проблем справится любой компьютер с соот-
204

Глава 5. Протокол IP (Internet Protocol)
ветствующей операционной системой (UNIX, OpenVMS, NT, Windows
Server 2000/2003).
Вероятно, у вас возникнет вопрос: «Почему для передачи данных
недостаточно одного протокола канального уровня?» Канальный протокол
обслуживает только передачу данных в пределах одной локальной сети
(то есть передает информацию на ближайший маршрутизатор, который
«распаковывает» данные из канального кадра и «переупаковывает» их
в другой, отличный от исходного, канальный кадр).
Разные канальные протоколы должны использоваться на каждом
интерфейсе маршрутизатора. Не позволяйте ввести вас в заблуждение: когда
маршрутизатор использует тот же самый канальный протокол на
различных интерфейсах, например, Ethernet, все равно выполняется
«переупаковка». Мы должны помнить о том, что Ethernet-кадр использует
различные физические адреса перед «упаковкой» и после
«переупаковки» (см. ниже).
Некоторые протоколы, например, NetBEUI (Microsoft) или LAT
(Digital), используют 6-байтовый адрес. Эти протоколы довольно
просты и обычно довольно быстро обрабатывают пакеты, но они
предназначены только для адресации в пределах локальной сети и не способны
отправить данные получателю, находящемуся за пределами
маршрутизатора, то есть в глобальной сети. Поэтому данные протоколы относятся
к так называемым немаршрутизируемым протоколам: они
используются только в пределах локальной сети.
Получатель
М - маршрутизатор
1 -й канальный протокол 2-й канальный протокол 3-й канальный протокол
■< ►-« Ъ~4 ►
IP-протокол
Рис. 5.3. Канальные протоколы и IP-протокол
205

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 5.3 показывает, что в отличие от протокола IP, передающего данные
между двумя удаленными компьютерами в глобальной сети, канальный
протокол передает кадры данных только между маршрутизаторами, то
есть от одного маршрутизатора к следующему. Кадры канального
уровня изменяются маршрутизаторами по пути их следования к
компьютеру-получателю.
IP-дейтаграммы, в отличие от кадров канального уровня, не
изменяются маршрутизаторами. Исключение составляет только поле TTL в
заголовке IP-дейтаграммы. Каждый маршрутизатор уменьшает это поле
минимум на единицу. Когда TTL достигает нуля, дейтаграмма
отбрасывается — она не дошла до своего получателя. Данный механизм
используется для прекращения бесконечного блуждания пакетов по
Интернету, например, в случае отключения адресата. Кроме TTL есть еще
несколько исключений (фрагментация, маршрутизация источника), но
о них мы поговорим позже.
Рассмотрим рис. 5.4.
М - маршрутизатор
Рис. 5.4. Отправитель отправляет IP-дейтаграмму в фрейме протокола Ethernet
Отправитель по локальной сети передает данные с интерфейса Ethernet
1 на интерфейс Ethernet 2 получателю. Для простоты восприятия мы
обозначили адреса отправителя и получателя словами From и То — как
206

Глава 5. Протокол IP (Internet Protocol)
в e-mail. Точно так же мы обозначили канальный адрес. Например, у
отправителя канальный адрес HW1.
Отправитель хочет передать IP-дейтаграмму получателю с IP-адресом
IP2. Он создает дейтаграмму, но, чтобы передать ее по сети, он должен
инкапсулировать (вставить) ее в кадр канального уровня — в нашем
случае, в Ethernet-кадр. После этого дейтаграмма отправляется в
«путешествие» по сети. Канальный протокол передает ее маршрутизатору 1,
который извлекает IP-дейтаграмму из кадра Ethernet и анализирует адрес
получателя. В зависимости от адреса получателя маршрутизатор решает,
какому из соседних маршрутизаторов отправить эту 1Р-дейтаграмму.
Данный выбор очень не прост. Маршрутизатор выбирает следующий
маршрутизатор на основе своей таблицы маршрутизации, которую мы
рассмотрим позже. Сейчас предположим, что маршрутизатор решил
передать дейтаграмму по HDLC-линии.
Заголовок
HDLC
From=IP1,To=IP2
HDLC
"хвост"
TTL=TTL-1
HW5
IP 2
Получатель
М - маршрутизатор
Рис. 5.5. IP-дейтаграмма была помещена в фрейм протокола HDLC
Маршрутизатор уменьшает значение TTL минимум на единицу и
инкапсулирует IP-дейтаграмму в другой канальный протокбл — в данном
случае, в HDLC-протокол (рис. 5.5). Наша IP-дейтаграмма помещается
в контейнер HDLC и передается по протоколу HDLC к другому
маршрутизатору, который снова извлекает IP-дейтаграмму, но на этот раз уже
из HDCL-кадра, уменьшает значение TTL, инкапсулирует дейтаграмму
в кадр Ethernet и передает получателю по локальной сети.
207

TCP/IP и DNS в теории v\ на практике. Полное руководство
М - маршрутизатор
Рис. 5.6. IP-дейтаграмма снова вложена в фрейм протокола Ethernet
Я намеренно задал один канальный протокол (Ethernet) обеим
локальным сетям, чтобы продемонстрировать, что канальные кадры этих двух
сетей абсолютно разные. В сети отправителя в Ethernet-кадре адрес
отправителя — HW2, а адрес получателя — HW1. В сети получателя же
адрес отправителя — HW4, а адрес получателя — HW5.
5.2. Устройство IP-дейтаграммы
IP-дейтаграмма состоит из заголовка и передаваемых данных. Длина
заголовка обычно составляет 20 байтов. Однако в заголовок могут
добавляться необязательные поля, что незначительно увеличивает его длину.
Структура IP-дейтаграммы изображена на рис. 5.7.
Перед описанием отдельных элементов заголовка дейтаграммы
давайте захватим одну из IP-дейтаграмм сетевым монитором MS Network
Monitor. С помощью сетевого монитора можно посмотреть, что реально
передается по сети, а также просмотреть значения отдельных элементов
заголовка 1Р-дейтаграммы.
Первый элемент заголовка — поле Версия (Version). Данное 4-битовое
(по л байта), доле содержит версию протокола. При использовании
протокола IPv4 оно будет содержать значение 4 (0x4).
208

Глава 5. Протокол IP (Internet Protocol)
0
Версия IP
4 бита
Длина
заголовка
8
Тип обслуживания (TOS)
8 бит
Идентификатор IP-пакета
16 бит
Время жизни (TTL)
8 бит
Протокол высшего
уровня - 8 бит
16
24
Общая длина IP-пакета
16бит
Флаги
Смещение фрагментов
Контрольная сумма IP-заголовка
16 бит
IP-адрес отправителя
32 бита
IP-адрес получателя
32 бита
Опции заголовка
(если есть)
Данные
Рис. 5.7. Устройство IP-дейтаграммы
Следующее поле — Длина заголовка (Header length) — содержит
длину заголовка IP-дейтаграммы (длина поля 4 бита). Здесь ситуация на
первый взгляд несколько непростая. Длина заголовка исчисляется не
вбайтах, а в 4-байтовых словах. Поле Длина заголовка (Header length)
содержит количество 4-байтовых слов (32-битовых) в заголовке
IP-пакета. Минимальный размер заголовка — 20 байтов, следовательно,
длина минимального заголовка — 0x05 (5 X 4 - 20 байтов). Опции IP могут
увеличивать минимальный размер заголовка на 4 байта. Если опция
использует не все 4 байта, то оставшиеся биты заполняются нулями,
поэтому длина заголовка всегда кратна 4-м байтам.
Максимальная длина заголовка IP-дейтаграммы ограничена длиной
самого поля Длина заголовка (Header length), 4 бита которого могут
содержать максимальное значение 1510 (11112 e F16 - 151()). Следовательно,
максимальная длина заголовка равна 6010 (=15x4) байтов. Поскольку
20 байтов занимает базовый заголовок, остальные 40 байтов могут
использоваться дополнительными элементами заголовка.
Поле Тип обслуживания (Type of service, TOS) долгое время просто
не использовалось (хотя было зарезервировано). Относительно
недавно оно начало использоваться для указания качества передачи
IP-дейтаграммы (рис. 5.9).
209

TCP/IP и DNS в теории и на практике. Полное руководство
1 « 1
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP:
5.1.1
5.1.2
5.1.2.1
5.1.3
+ ICMP
00000:
00010:
00020:
00030:
00040:
ID = 0x5814; Proto = ICMP; Len: 60
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
IP: Service Type = 0 (0x0)
IP: Precedence = Routine
IP: ...0.... = Normal Delay
IP: ....0... = Normal Throughput
IP: 0.. = Normal Reliability
IP: Total Length = 60 (ОхЗС)
IP: Identification = 22548 (0x5814)
IP: Flags Summary = 0 (0x0)
IP: 0. = May fragment datagram if necessary
IP: Fragment Offset = 0 (0x0) 'bytes
IP: Time to Live = 32 (0x20)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = OxEBFO
IP: Source Address = 194.149.104.198
IP: Destination Address = 194.149.104.203
IP: Data: Number of data bytes remaining = 40 (0x0028)
• Echo, Front 194.149.104.198 To 194.149.104.203
00 00 F8 21 71 A4 00 20 AF FA 25 89 08 00 45 00 ... !q....%...E.
00 3C 58 14 00 00 20 01 EBF0 C2 95 68 C6 C2 95 .<X h...
68 CB 08 00 46 5C 01 00 06 00 61 62 63 64 65 66 h...F\... .abcdef
67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 ghijklmnopqrstuv
77 61 62 63 64 65 66 67 68 69 wabcdefghi
Рис. 5.8. IP-дейтаграмма, полученная с помощью
сетевого монитора MS Network Monitor
Однако в стандарте RFC-2474 данное поле используется для других
целей. У него поменялось название: теперь оно называется не TOS, a DS
(Differentiated Services), что означает «Дифференцированные
сервисы». Важность этого поля значительно возросла в сетях, где
необходимо обеспечить минимально допустимую пропускную полосу. Особенно
данное поле актуально для приложений, передающих видео и звук.
210

Глава 5. Протокол IP (Internet Protocol)
Тип обслуживания (TOS) 8 битов
Приоритет
(3 бита)
Тип обслуживания 4 бита
J L
I
Не использ.
L
минимальная цена
1— максимальная надежность
1— максимальная производительность
1— минимальная задержка
Рис. 5.9. Значение отдельных битов поля TOS
Если необходимо обеспечить нужную пропускную полосу на всех
линиях между отправителем и получателем, приложения должны
использовать протокол резервирования ресурсов — RSVP (Resource Reservation
Protocol), определенный стандартом RFC-2205. Но данный протокол
можно использовать лишь в том случае, если обе машины (отправителя
и получателя) поддерживают его.
Поддерживается ли RSVP на «той» стороне или нет (параметр -R),
позволяет узнать программа pathping. Данная команда есть в Windows
2000 и более поздних версиях:
pathping -R www.company.com
Поле Общая длина IP-дейтаграммы (IP datagram total length)
содержит общую длину IP-дейтаграммы в байтах. Поскольку размер этого
поля составляет всего 2 байта, максимальный размер IP-дейтаграммы
равен 65 535 байтам.
Поле Идентификатор IP-дейтаграммы (IP datagram identification)
содержит идентификатор IP-дейтаграммы, который вставляется в
IP-дейтаграмму операционной системой отправителя. По данному полю
идентифицируются фрагменты дейтаграммы, на которые та разбивается при пересылке.
Флаги фрагментации (см. рис. 5.10) представляют собой три 1-битовых
флага, которые указывают, разрешена ли фрагментация IP-дейтаграммы
и завершает ли данный конкретный фрагмент серию фрагментов.
Значение первого бита зарезервировано и всегда равно 0. Если бит DF (второй
бит) установлен (DF =1), фрагментация запрещена (см. рис. 5.9). Если
DF = 0, возможна фрагментация пакета (разделение пакета на группы).
211

TCP/IP и DNS в теории и на практике. Полное руководство
Flags 3 bits
D
DF
MF
DF - не фрагментировать <Don't Fragment)
MF - еще фрагменты (More Fragments,
второе значение - последний фрагмент,
Last Fragment)
Рис. 5.10. Флаги фрагментации
Значение третьего бита учитывается только в том случае, если второй
бит равен О (DF=0). Третий бит (MF) показывает, завершает ли данный
фрагмент дейтаграммы серию переданных фрагментов (MF =1) или нет
(MF = 0).
Поле смещения (Fragment Offset) — 8-разрядное поле, содержащее
в себе смещение фра,гментировацного содержимого дейтаграммы
относительно ее начала. Данное поле вместе с флагами и полем смещения
фрагмента (fragment offset) используется механизмом фрагментации
дейтаграмм.
Поле Продолжительность жизни дейтаграммы (IP datagram lifespan)
предотвращает бесконечное блуждание IP-дейтаграммы через
Интернет. Каждый маршрутизатор обязан уменьшить TTL минимум на 1.
Когда TTL достигает нуля, IP-дейтаграмма отбрасывается. Отправитель
дейтаграммы будет проинформирован об этом с помощью специального
ICMP-сообщения (сообщения протокола ICMP будут нами
рассмотрены далее).
Узнать значение TTL очень просто — оно выводится командами ping
и traceroute (tracert). Если же нам нужно изменить это значение,
следует отредактировать реестр Windows. В Windows 2000 мы должны
изменить значение TTL по умолчанию; hkey_LOCAL_machine\SYSTEM\
CurrentControlSet\Services\Topic\Parameters\DefaultTL.
Тип значения REG_DWORD.
Поле Протокол высшего уровня (Higher layer protocol) содержит
идентификационный номер протокола высшего уровня, который
инкапсулирован в IP-дейтаграмму. Номера всех протоколов можно найти на сайте:
http: / /www. iana. org. /numbers . html.
В таблице 5.1 представлены номера некоторых протоколов.
212

Глава 5. Протокол IP (Internet Protocol)
Таблица 5.7. Номера протоколов стандартны
Номер протокола высшего
уровня
1
2
4
6
1V11«
Протокол
ICMP
IGMP
IP через IP
TCP
UDP
Протокол высшего уровня — далеко не единственное, что может быть
инкапсулировано в IP-дейтаграмму. Мы можем инкапсулировать
протоколы, которые не поддерживаются Интернетом, но по некоторым
причинам должны быть переданы через Интернет, например, Novell's
IPX protocol (IPX через IP).
В таблице 5.2 представлены номера некоторых таких протоколов.
Таблица. 5.2. Номера протоколов, несвойственных Интернету
N9 протокола высшего
уровня
(в десятеричной системе)
97
111
Протокол
Ethernet no IP
IPX через IP |
Если нам нужно передать дейтаграммы протокола IPv6 по сети,
поддерживающей только протокол IPv4, мы можем инкапсулировать
дейтаграммы IPv6 в дейтаграммы IPv4.
Поле Контрольная сумма IP-заголовка (IP header checksum)
содержит контрольную сумму только заголовка IP-дейтаграммы, а не всей
дейтаграммы. О том, как вычисляется контрольная сумма, вы можете
прочитать в документах RFC-1071 и RFC-1141.
Поля IP-адрес отправителя (IP-source address) и IP-адрес
получателя (IP-destination address) содержат 4-байтовый IP-адрес отправителя
и получателя.
Поле Параметры (Parameters) предусмотрено для передачи информации
о безопасности дейтаграммы, маршрутизации сообщений от источника и
временной пометки. Рассмотрению этих параметров посвящен раздел 5.5.
Поле Дополнение служит для выравнивания длины IP-заголовка,
чтобы она была кратна 32-м битам. В случае необходимости это поле
заполняется нужным количеством нулей.
213

TCP/IP и DNS в теории и на практике. Полное руководство
5.3. Протокол межсетевых управляющих
сообщений (Interent Control Message Protocol, ICMP)
5.3.1. Общая информация
Назначение протокола ICMP
Протокол ICMP — это сервисный протокол протокола IP. Протокол
ICMP используется для оповещения об ошибках и управляет
сообщениями для протокола IP. Данный протокол не используется для
повышения надежности передачи данных, а только лишь для информирования
об ошибках и, в некоторых случаях, для обеспечения обратной связи.
IP-заголовок
обычно 20 байт
ICMP-пакот
Заголовок
ICMP-пакета
Данные ICMP-пакета
Echo
Тип«0 (ответ) Тип-В (запрос)
Сеть недоступна
Тип=3
Подавление источником
Тип=4
Перенаправление
Тип=5
Выбор маршрутизатора
Тип=10Код=0
«Реклама» маршрутизатора
Тип=9 Код=0
Время вышло
Тип=11
Ошибка параметра
Тип»12
Синхронизация времени
Тип=13 (запрос)Тип=11 (ответ)
Маска адреса подсети
Тип* 17 (запрос) Тип=18 (ответ)

Идентификатор 2 Б
№ послед-ти
2Б
Данные (не обязательно)
Не используется
(обычно = 0) 4 Б
IP-заголовок плюс
64 Б данных
Не используется
(обычно = 0) 4 Б
IP-заголовок плюс
64 Б данных
IP-адрес 4 байта
IP-заголовок плюс
64 Б данных
Не используется
(обычно = 0) 4 Б
Содер-
Раэмер
2Б
Время
жизни
Адрес, метрика,
Не используется
(обычно = 0) 4 Б
IP-заголовок плюс
64 Б данных

Указатель
Не используется
3
Адрес, метрика,...

Идентификатор 2 Б
№ послед-ти
2Б
Исх. время
4Б

Идентификатор 2 Б
№ послед-ти
2Б
Mask
4Б
Принятое
время 4 Б

Переданное время
Рис. 5.11. Структура ICMP-пакета
214

Глава 5. Протокол IP (Internet Protocol)
Длина заголовка ICMP-пакета постоянна — 8 байтов. Назначение
первых четырех байтов всегда одно и то же, а вот назначение оставшихся
четырех байтов зависит от типа ICMP-пакета.
Какие бывают ЮМР-сообщения
Первые четыре байта заголовка всегда содержат тип сообщения, код
сообщения и 16-разрядную контрольную сумму.
Некоторые типы и коды сообщения представлены в таблице 5.3.
Таблица 5.3. Список сообщений ЮМР-протокола
Тип '■ Код '• Описание
0:0! Echo
О чем
сообщает?
Ответ
пользовательскому
приложению
Кто
обрабатывает?

Пользовательское
приложение
1 : : : Пользователь-
3 ; Получатель недоступен (Destination unreachable) Ошибка i ское приложе-
1 : : ние
: 0 \ Сеть недоступна (Network unreachable) '
\ 1 : Узел недоступен (Host unreachable)
: 2 : Протокол н едоступен (Protocol unreachable)
: 3 : Порт недоступен (Port unreachable)
: а • Нужна фрагментация, но бит фрагментации не уста-
: новлен (Fragmentation need but don't fragment bit set)
: 5 : Ошибка маршрута (Source route failed)
j e j Неизвестна сеть назначения (получателя)
: (Destination network unknown)
: _ : Неизвестен узел назначения (получателя)
: (Destination host unknown)
: о : Сеть получателя административно запрещена
: (Destination network administratively prohibited)
! 10 j Узел получателя административно запрещен
j (Destination host administratively prohibited)
: 11 : Сеть недоступна для TOS (Network unreachable for TOS)
: 12 : Узел недоступен для TOS (Host unreachable for TOS)
! 1 о j Связь запрещена сетевым фильтром
: (Communication administratively prohibited by filtering)
4:0 i Подавление источником (Source quench)
Ошибка
1. Ядро ОС
для TCP
2.
Отбрасывается для UDP
215

TCP/IP и DNS в теории и на практике. Полное руководство
Тип : Код : Описание
О чем
сообщает?
5 • Перенаправление (Redirect) Ошибка
: 0 j Перенаправление для сети (Redirect for network)
: 1 \ Перенаправление для узла (Redirect for host)
i (Redirect for TOS and network)
: „ : Перенаправление для TOS и узла
8:0: Echo-запрос (Echo request)
9:0: Объявление маршрутизатора (Router advertisement)
I 10: 0 ; Выбор маршрутизатора (Router selection)
11: Время вышло (Time exceeded)
: о S TTL ~ ° (TTL equals 0 during transit)
Запрос
приложения
пользователя
Ответ
приложения
пользователя
Запрос
приложения
пользователя
Ошибка
: : Вышло время сборки фрагмента (Fragment Reassem-
j Ыу Time Exceeded)
12 : Ошибка параметра (Parameter problem) Ошибка
: о \ Ошибка IP заголовка (Pointer Indicates the error)
: . : Пропущена необходимая опция (Missing a Required
: Option)
: 2 : Неверная длина (Bad Length) \
j | j Запрос
13 : 0 : Запрос временной метки (Timestamp request) . i приложения
! ! j пользователя
: : | Ответ
14 : 0 ; Ответ временной метки (Timestamp reply) I приложения
: j пользователя
I ; Запрос
17 j 0 j Запрос маски адреса (Address mask request) \ приложения
| : : j пользователя
I ! ! j Ответ
18j о ; Ответ маски адреса (Address mask reply) ! приложения
j : j пользователя
Кто

обрабатывает?
Ядро ОС
Ядро ОС
Процесс
пользователя
Процесс
пользователя
Процесс
пользователя
Процесс
пользователя
Процесс
пользователя
Ядро ОС
Процесс
пользователя
Ядро ОС
ОС - операционная система
216

Глава 5. Протокол IP (Internet Protocol)
5.3.2. Разбираем отдельные ICMP-сообщения
Сообщение Echo
Это простейший ICMP-инструмент, позволяющий удостовериться,
что отправляемые нами пакеты «доходят» до получателя.
Приложение-отправитель отправляет запрос Echo request, получатель, в
случае получения этого запроса, должен отправить ICMP-пакет с
ответом Echo.
Во всех операционных системах, поддерживающих протокол TCP/IP,
есть программа ping, позволяющая пользователю отправить
эхо-запросы. Также программа ping отображает эхо-ответы и ведет простую
статистику: сколько пакетов получено, а сколько — потеряно.
Предположим, что мы хотим проверить, доходят ли наши пакеты до узла
с IP-адресом 194.149.105.18. Для этого нужно выполнить команду:
D:\ >ping 194.149.105.18
Обмен пакетами с 194.149.105.18 по 32 байт:
Ответ от 194.149.105.18
Ответ от 194.149.105.18
Ответ от 194.149.105.18
Ответ от 194.149.105.18
число байт=32 время <10мс TTL=63
число байт =32 время <10мс TTL=63
число байт =32 время <10мс TTL=63
число байт =32 время <10мс TTL=63
Наша система отправляет эхо-запрос четыре раза. Время ответа от узла
с адресом 194.149.105.18 составляет менее 10 мс, a TTL пакета = 63.
Недоставляемая IP-дейтаграмма
(Undeliverable IP datagram)
Если дейтаграмму невозможно передать, она будет отброшена
(отвергнута), и отправитель получит ICMP-сообщение Undeliverable IP
datagram. Некоторые причины ошибки указаны в таблице 5.3.
Подавление источником (Source Quench)
Если некоторая часть сети между отправителем и получателем
перегружена, и маршрутизатор не может передать следующие IP-дейтаграммы,
он отправляет отправителю сообщение Source Quench.
217

TCP/IP и DNS в теории и на практике. Полное руководство
Перенаправление (Redirect)
С помощью данного ICMP-пакета можно динамически изменять
таблицу маршрутизации.
М1, М2 - маршрутизаторы
Рис. 5.12. Перенаправление
На рис. 5.12 маршрутизатор 1 при получении от отправителя
IP-дейтаграммы передает ему ICMP-пакет с требованием изменить свою
таблицу маршрутизации и больше не обращаться к этому маршрутизатору.
Данная ситуация возникает в локальной сети с несколькими
маршрутизаторами при условии, что некоторые компьютеры локальной сети «не
знают» других маршрутизаторов и используют только маршрутизатор
по умолчанию.
Поиск маршрутизаторов с помощью ICMP
Это новая особенность, благодаря которой мы можем не
конфигурировать вручную таблицу маршрутизации каждого компьютера локальной
сети. После запуска компьютер отправляет ICMP-сообщение поиска
маршрутизатора (ICMP Router Solicitation Message):
«Маршрутизаторы! Отзовитесь!».
В ответ на это маршрутизаторы отправляют «рекламные» 1СМР-со-
общения ICMP Router Advertisement Message, содержащие адрес
маршрутизатора, длину адреса и пары IP-адрес/предпочтение. Исходя
из этого ответа, компьютер может выбрать маршрутизатор по
умолчанию.
218

Глава 5. Протокол IP (Internet Protocol)
Время вышло (Time exceeded)
Сообщение типа Time exceeded (Время вышло) может быть двух видов:
• код = 0 — информирует о том, что TTL = 0, то есть дейтаграмма
«потерялась»;
• код = 1 — получатель не способен собрать все фрагменты
дейтаграммы за определенное время.
ICMP-пакет Time exceeded (время вышло) с кодом 0 используется
программами traceroute (UNIX) или tracert (Microsoft).
Программа tracert более проста. Она отправляет ICMP-пакет Echo
request (эхо-запрос) компьютеру-получателю. В первом пакете TTL
устанавливается в 1 (TTL =1). Первый маршрутизатор уменьшает TTL на 1
(теперь TTL = 0) и, поскольку TTL достиг 0, отбрасывает дейтаграмму,
а нашему компьютеру отправляет ICMP-сообщение Time exceeded.
Итак, мы знаем адрес первого маршрутизатора по пути к получателю.
Можно узнать и имя маршрутизатора: для этого используется обратное
преобразование адреса системы DNS. Программа также замеряет время,
которое понадобилось для получения ответа от отправителя. Если время
было превышено, в выводе программы оно заменяется звездочкой (*).
Затем программа устанавливает TTL = 2 и повторяет итерацию. После
второго прохода мы будем знать адрес и имя второго маршрутизатора.
Программа будет повторять отправку ICMP-запросов, с каждым разом
увеличивая TTL на 1, пока пакет не достигнет получателя. Если пакет
все-таки не дойдет до получателя, отправитель получит сообщение
Undeliverable IP datagram (Невозможно отправить IP-дейтаграмму).
TTL=4
TTL=3
TTL=2
TTL=1
►
Рис. 5.13. Программа tracert
219

TCP/IP и DNS в теории и на практике. Полное руководство
D:\. >tracert kula.uap.ac . f j
Трассировка маршрута к kula.usp.ac.fj [144.120.8.11] С
максимальным числом прыжков 30:
cbuN002e00.pvt.net [194.149.104.193]
phucbu.pvt.net [194.149.96.13]
951.Hssi5-0.GWl.NYC2.ALTER.NET [157.130.0.117]
143.ATM2-0.XR1.EWR1.ALTER.NET [146.188.177.50]
193.ATMl-0-0.BRl.EWRl.ALTER.NET [146.188.176.49]
sl-pen-ll-h3.sprintlink.net [137.39.44.130]
661 mssl-bblO-pen-0-l.sprintlink.net [144.232.5.5]
sl-bb22-stk-6-0.sprintlink.net [144.232.8.178]
sl-bb23-stk-8-0.sprintlink.net [144.232.4.110]
sl-bbl0-sj-6-0.sprintlink.net [144.232.8.193]
sl-gw2-sj-0-0-155M.sprintlink.net [144.232.3.38]
sl-cais-1.sprintlink.net [144.228.111.18]
hssi9-0-0.hk-T3.hkt.net [202.84.128.253]
f5-0.yck06.hkt.net [205.252.130.201]
a6-0.tmh08.hkt.net [205.252.130.81]
s4-3b.tmh08.hkt.net [205.252.128.158]
202.84.251.6
202.62.120.6
202.62.125.134
kula.usp.ac.fj [144.120.8.11]
Трассировка завершена.
Программа traceroute работает аналогично. Однако она вместо ICMP-
запросов Echo request генерирует UDP-дейтаграммы. Если на
маршрутизаторе установлен пакетный фильтр (брандмауэр), то вы должны
указать такой номер порта, который «пропустит» маршрутизатор.
Номер порта указывается с помощью опции -р. Обычно можно указать
номер порта 53, который используется системой DNS.
$ /usr/sbin/traceroute -p 20000 libor.pvt.net
traceroute to libor.pvt.net (194.149.104.198), 30 hops max, 40 byte packets
1 cbuN003f00.pvt.net (194.149.105.17) 1 ms 1 ms 1 ms
2 Libor.pvt.net (194.149.104.198) 1 ms 1 ms 1 ms
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<10
10
601
591
591
400
500
871
691
811
641
,801
801
821
1402
1381
1362
1422
1412
ms
ms
ms
ms
ms
ms
811
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
ms
10 ms
10 ms
561 ms
571 ms
581 ms
381 ms
msM
651 ms
831 ms
650 ms
771 ms
651 ms
811 ms
•
831 ms
1342 ms
1362 ms
1362 ms
1372 ms
1382 ms
<10 ms
10 ms
641 ms
571 ms
571 ms
360 ms
591 ms
731 ms
932 ms
611 ms
771 ms
641 ms
861 ms
811 ms
822 ms
1362 ms
1352 ms
1352 ms
1392 ms
1412 ms
220

Глава 5. Протокол IP (Internet Protocol)
Получатель обычно отвечает ICMP-пакетом Port unreachable (Порт
недоступен) (тип - 3, код = 3). Кроме времени и звездочки, traceroute
может выводить причину ошибки:
• !Н — получатель недоступен,
• IN — сеть получателя недоступна,
• !А — сеть «закрыта»,
• IS — ошибка маршрутизации.
Запрос маски адреса подсети (Address mask request)
Получив IP-адрес по протоколу RARP, бездисковые станции с
помощью протокола ICMP могут запрашивать маску сети. Именно для этого
и предназначено сообщение Address mask request (Запрос маски
адреса подсети).
Правда, данный механизм используется довольно редко, поскольку для
получения параметров сети используются протоколы ВООТР и DHCP.
В последнее время протокол DHCP практически вытеснил протокол
ВООТР.
Синхронизация времени
Протокол ICMP используется очень широко, в том числе, и для
синхронизации времени. Механизм синхронизации изображен на рис. 5.14.
Отправитель
Получатель
Отправитель
Запрос
Ответ
Время
получения
Время запроса
отправления
запроса
-►- ВреМя
Время
получения
Время ответа
отправления
ответа
RTT
Рис. 5.14. Синхронизация времени
221

TCP/IP и DNS в теории и на практике. Полное руководство
Отправитель отправляет ICMP-запрос Timestamp request (Запрос
временной метки). Получатель дважды отправляет пакет Timestamp reply
(Ответ временной метки):
• В первый раз пакет содержит время получения запроса timestamp.
• Во второй раз — время отправки ответа.
Отправитель (компьютер, отправивший запрос) использует эти данные
для синхронизации времени.
Время отсчитывается в миллисекундах с предыдущей полуночи по
гринвичскому времени GMT (Greenwich Mean Time) — времени на нулевой
долготе.
Примечание.
На данный момент принято гринвичское время называть UTC (Coordinated
Universal Time), но по привычке еще часто используется GMT.
5.4. Фрагментация IP-дейтаграмм
и уязвимости, ею обусловленные
Размер фрагментов
IP-дейтаграммы помещаются в кадры канального уровня.
Максимальный размер данных, который может быть помещен в один кадр
канального уровня, называется MTU (Maximum Transfer Unit). В таблице 5.4
приведены значения MTU для разных канальных протоколов.
Таблица 5.4. Значения MTU
Канальный протокол
Ethernet II
Ethernet 802.3 SNAP
Frame Relay
FDDI
MTU, Кб
1500
1492
1600
4478
Каждый фрагмент исходной дейтаграммы пересылается в виде
отдельной дейтаграммы IP. Информации, хранящейся в заголовках IP,
достаточно для идентификации фрагментов. Эта информация используется
хостом-получателем при сборке; исходной дейтаграммы из фрагментов.
222

Глава 5. Протокол IP (Internet Protocol)
На некоторых линиях, соединяющих большие расстояния, MTU
может быть менее 1 Кб. Поле Общая длина IP-дейтаграммы имеет размер
16 битов, поэтому, теоретически, можно создать IP-дейтаграмму
размером 64 Кб.
ФРАГМЕНТИРОВАНИЕ ДЕЙТАГРАММ МАРШРУТИЗАТОРАМИ
Что же произойдет, когда IP-дейтаграмма на своем пути от отправителя
к получателю достигает маршрутизатора (рис. 5.15, маршрутизатор 2),
который перенаправляет ее на линию получателя с размером MTU,
меньшим, чем наша IP-дейтаграмма?
( М2 1^» *ч^( М1 Vx"*—"n^JC получателю
MTU < общей длины IP-пакета
1Ь М - маршрутизатор
Рис. 5.15. Перенаправление IP-дейтаграммы
Маршрутизатор не может отправить такую дейтаграмму. Он принимает
решение фрагментировать исходную дейтаграмму, то есть разбить ее на
части. Тут очевидно наличие двух вариантов: фрагментация возможна
и фрагментация невозможна (установлен бит Don't Fragment (DF = 1)).
В последнем случае маршрутизатор просто отвергнет дейтаграмму и
отправит отправителю ICMP-сообщение Fragmentation needed but don't
fragment bit set (Необходима фрагментация, но установлен бит «не
фрагментировать» ).
Если мы устанавливаем бит DF = 1, то мы должны выбрать такой размер
MTU, который был бы приемлем для линии, по которой будет
передаваться дейтаграмма. Для этого можно использовать команду ping с
параметрами -f и -1. Первый параметр запрещает фрагментацию, а второй
устанавливает максимальный размер дейтаграммы (в байтах):
С:\ > ping -f -l 2000 получатель
Теперь мы или увидим сообщение об ошибке, или же дейтаграммы
нормально дойдут до получателя. Если дейтаграммы дошли, значит, мы мо-
223

TCP/IP и DNS в теории и на практике. Полное руководство
жем использовать дейтаграммы данного размера на этой линии. Если же
нет, нужно попытаться уменьшить значение параметра -1 и запустить
ping снова, и повторять так до тех пор, пока дейтаграмма не дойдет до
получателя.
Было бы намного проще, если бы ICMP-сообщение содержало
подходящее значение MTU, но первоначально данная возможность не
рассматривалась. В последнее время к ICMP-пакетам было добавлено поле
MTU, но оно редко используется. Для этого поля были задействованы
последние два байта заголовка ICMP-пакета. Структура ICMP-пакета
приведена на рис. 5.16.
О 8 16 24
Тип*3
Код = 4
Не используется - заполняется нулями
Контрольная сумма (checksum)
MTU
IP-заголовок + 8 Б части данных отброшенного пакета
Рис. 5.16. Структура ICMP-пакета
Если поле MTU равно 0, значит, маршрутизатор не поддерживает эту
новую возможность.
Давайте вернемся обратно и рассмотрим первую ситуацию обработки
большой IP-дейтаграммы, когда фрагментация возможна.
Если она возможна (DF - 0), то маршрутизатор разбивает исходную
дейтаграмму на части, соответствующие MTU-линии, по которой будет
передаваться дейтаграмма (см. рис. 5.17).
Заголовок каждой IP-дейтаграммы содержит ее идентификатор,
который наследуется фрагментами дейтаграммы. По этой идентификации
можно определить первоначальную дейтаграмму: кадры с одним
значением ID «собираются» в одну дейтаграмму. Никто, кроме получателя, не
имеет права «собирать» первоначальную дейтаграмму — даже
маршрутизатор с линией большего значения MTU, которая способна передать
всю дейтаграмму сразу. Причина проста: Интернет не гарантирует, что
отдельные фрагменты попадут на тот же самый маршрутизатор, то есть,
что одни фрагменты могут «пойти» по одному маршруту, другие — по
другому, но в конечном итоге все они будут доставлены получателю.
224

Глава 5. Протокол IP (Internet Protocol)
IP-пакет
£MTU
"П
IP-фрагмент
Идентификация = 1236
IP-пакет
Идентификация = 1235
IP-пакет
Идентификация = 1234
IP-фрагмент
IP-фрагмент
IP-фрагмент
Идентификация = 1234 Идентификация = 1234 Идентификация = 1235 Идентификация = 1235
Рис. 5.17. Разбиение IP-дейтаграммы на фрагменты
Идентификатор IP-дейтаграммы может быть однозначным только
в пределах кадра одного протокола более высокого уровня, потому что
заголовок IP-дейтаграммы также содержит поле Протокол (Protocol).
Глобальная идентификация может быть представлена как
формирование цепочки полями идентификации поля и протокола (плюс, конечно,
IP-адрес отправителя и получателя). Так что, теоретически, могут быть
получены две IP-дейтаграммы с одинаковой идентификацией. Но одна
содержит TCP-пакет, а другая — UDP-пакет.
Каждый фрагмент — это независимая IP-дейтаграмма с собственным
IP-заголовком. Заголовок для каждой дейтаграммы фрагмента
создается во время процесса фрагментации. Некоторые данные (вроде
протокола и IP-адресов отправителя и получателя) переносятся из заголовка
исходной 1Р-дейтаграммы.
При фрагментации используется поле Смещение фрагмента (Fragment
offset), в которое заносится, сколько байтов исходной IP-дейтаграммы
было включено в предыдущие фрагменты. Поле Общая длина
IP-дейтаграммы (Total length of IP datagram) фрагмента содержит длину
самого фрагмента, а не длину исходной дейтаграммы.
Последний фрагмент дейтаграммы помечается флагом MF (More
Fragments). Если MF - 1, то это не последний фрагмент, если MF - 0, то
получен последний фрагмент. Механизм фрагментации представлен на
рис. 5.18.
8 За* 518
225

TCP/IP и DNS в теории и на практике. Полное руководство
[тСР-загоЛово£^ Данные ТСР;Фрагмвнта_
IP-эаголовок р
Данные IP-пакета
Идентификация ■ 1234/ смещение=0, общ.длина=3500. Флаги: фрагментация возможна и послед, фрагмент(LF)
*Ethernet-
\эаголовок
I
1Р-заголовок
1. IP-фрагмент
Идентификация = 1234/ смещение=0, оСщ.длина=1500. Флаги: фрагментация возможна
IP-заголовок
2. IP-фрагмент
Идентификация=1234, смещение=1500, общ.длинаа1500. Флаги: фрагментация воэм.
MTU = 1500 J
IP-заголовок
Идентификация=1234, смещвние=3000, общ.длина=
— — — «■» 540 (500+20+20 - 2 дополнительных IP-эаголовка
" "~ ~* ~~ ""* — ~" "~' ~* ~~ ™" """ ~" """ "~ ™" "*Eth. / Флаги: фрагментация возможна и последний
1й фрагмент включая IP-эаголовок Гхвост"* фрагмент
■ •
\ Ethernet- I Eth. /
\ заголовок 2Й Фрагмент включая IP-эаголовок |"хвост-|
L « JL '
» Ethernet- г"
\ заголовок |
L L -
Зй фрагмент
-^Eth. /
I"хвост"i
Рис. 5.18. Фрагментация IP-дейтаграммы
Для сети нет разницы, что передавать — всю дейтаграмму или ее
фрагмент. Ведь фрагмент представлен в виде самостоятельной
дейтаграммы, которая с точки зрения сети ничем не отличается от остальных
дейтаграмм. Только у нефрагментированной дейтаграммы смещение
фрагментации = 0 и установлен флаг Последний фрагмент (MF = 0).
Поэтому во многих случаях слова «дейтаграмма» и «фрагмент»
взаимозаменяемы.
УЯЗВИМОСТЬ МЕХАНИЗМА ФРАГМЕНТАЦИИ
Нужно понимать, что каждый фрагмент «тянет» за собой
дополнительные 20 байтов — это длина заголовка. Если исходная дейтаграмма была
разбита на 5 фрагментов, то по сети будет передано на 100 байтов
больше информации, чем занимала исходная дейтаграмма.
Чтобы не передавать лишние данные, TCP-заголовок включается
только в первый IP-фрагмент. Остальные идут без этого заголовка.
Предположим, что на брандмауэре установлена фильтрация пакетов не только
по IP-заголовку, но еще и по TCP-заголовку. Первый фрагмент (с ТСР-
заголовком) соответствует какому-нибудь правилу, например: «удалить
все пакеты с таким заголовком».
226

Глава 5. Протокол IP (Internet Protocol)
Данный пакет будет отброшен и не выйдет за пределы сети. А все
остальные будут пропущены брандмауэром. Выходит, что мы сами
предоставляем злоумышленнику информацию, которую хотели
защитить брандмауэром. Чтобы этого не произошло, брандмауэр,
отфильтровав первый фрагмент, должен «не забыть» отфильтровать
остальные.
Из соображений безопасности лучше не использовать фрагментацию,
а заранее отправлять дейтаграммы меньшего размера.
5.5. Дополнительные элементы IP-заголовка —
подводные камни безопасности
5.5.1. Какие они есть
Дополнительные элементы IP-заголовка (далее опции) — очень
интересное явление протокола TCP/IP. Мы продемонстрируем, насколько
опасным может быть их использование, и вы поймете, почему
большинство провайдеров отбрасывают IP-дейтаграммы, содержащие их.
Код
1байт
Сору
I Длина
1 байт
Данные
длина определяется полем Длина
Класс опции
Номер опции
1Б 2Б 5Б
Рис. 5.19. Опции заголовка IP-дейтаграммы
При получении IP-дейтаграммы с одной из этих опций компьютер
обязан тоже использовать опцию для ответа. Поскольку длина IP-заголовка
равна 60-ти байтам (20 из них обязательны), опции могут занимать до
40-а байтов. Определены следующие опции:
1. Запись маршрута ( Record route ).
2. Временная отметка (Timestamp).
3. Свободный источник маршрутизации (Loose source routing).
4. Строгий источник маршрутизации (Strict source routing).
227

TCP/IP и DNS в теории и на практике. Полное руководство
5. Опция тревоги (IP Router Alert Option).
6. Опции безопасности протокола IP (Security Options for Internet
Protocol (RFC-1108)).
Дополнительные элементы IP-заголовка следуют сразу за
обязательными элементами. Формат опций представлен на рис. 5.19.
Если какой-либо опции установлен бит Сору (Сору - 1), то данная она
должна быть скопирована во все фрагменты дейтаграммы. Если бит
сброшен, опция должна содержаться в заголовке первого фрагмента.
Первые два бита формируют необязательное поле Class (Класс),
принимающее следующие значения:
• 0, если IP-дейтаграмма содержит регулярные данные или данные,
предназначенные для управления сетью;
• 2 (= 102), если IP-дейтаграмма используется для синхронизации сети.
В таблице 5.5 представлены некоторые опции.
Таблица 5,5. Дополнительные опции IP-заголовка
Код
0 00 00000
0 00 00001
| 000 00111
01000100
I 100 00011
| 1 00 01001
10010100
Шест-
надца-
тирич-
ные
00
01
07
44
83
89
94

Десятиричные
00
1
7
68
131
137
148
Длина
-
-
Переменная
Переменная
Переменная
Переменная
4
Опция
Конец списка опций. Используется в случае, если
опции не заканчиваются вместе с IP-заголовком.
Поля Длина и Данные не используются
Нет операции (No operation) — используется для
заголовка, кратного четырем. Поля Длина и
Данные не используются
Запись маршрута
Временная отметка (Timestamp)
Свободный источник маршрутизации
Строгий источник маршрутизации
Опция тревоги IP-маршрутизатора
5.5.2. Запись маршрута (Record Route)
Если заголовок содержит опцию с кодом 7 (Record Route), то каждый
маршрутизатор на пути IP-дейтаграммы к получателю добавляет
IP-адрес своего исходящего интерфейса в IP-заголовок. Отдельные
4-байтовые поля в заголовке IP-дейтаграммы для IP-адресов называются
слотами. Можно вставить до 9-ти слотов для IP-адресов в IP-заголовок.
228

Глава 5. Протокол IP (Internet Protocol)
Поле Длина (Length) содержит общую длину расширения, а поле
указателя ptr (pointer) показывает первые три слота, доступные для
записи IP-адреса (при записи каждого нового адреса поле ptr
увеличивается на 4).
ptr = 4
ptr = 8
ptr =12
39
Код=7
1байт
Длина
1 байт
Ptr
1байт
\J
1 -й IP-адрес
4 байта
2-й IP-адрес
4 байта
3-й IP-адрес
4 байта
А А
9-й IP-адрес
4 байта
т
ptr = 36
Рис. 5.20. Произвольный элемент заголовка «запись маршрута»
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x673D; Proto = ICMP; Len: 84
IP: Version = 4 (0x4)
IP: Header Length = 44 (0x2C)
+ IP: Service Type = 0 (0x0)
IP: Total Length = 84 (0x54)
IP: Identification = 26429 (0x673D)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 32 (0x20)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0xCB51
IP: Source Address = 194.149.104.198
IP: Destination Address = 194.149.105.18
IP: Option Fields = 7 (0x7)
IP: Record Route Option = 7 (0x7)
IP: Option Length = 23 (0x17)
IP: Next Slot Pointer = 4 (0x4)
IP: Route Traveled = 0 (0x0)
IP: End of Options = 0 (0x0)
IP: Data: Number of data bytes remaining = 40 (0x0028)
+ ICMP: Echo, From 194.149.104.198 To 194.149.105.18
Рис. 5.21. Содержимое IP-дейтаграммы
229

TCP/IP и DNS в теории и на практике. Полное руководство
Таким образом, дейтаграмма на своем маршруте от отправителя к
получателю «собирает» исходящие IP- адреса маршрутизаторов в свои слоты.
Используя команду ping с опцией record route, мы можем собрать
список исходящих адресов на пути дейтаграммы. В версии программы ping
от Microsoft для записи маршрута используется параметр -г, после
которого нужно указать количество создаваемых слотов:
D:\ >ping -г 5 ns.pvt.net
Данная команда генерирует ICMP-пакет с опцией record route и с
пятью слотами для записи IP-адресов. Отправитель создает пять слотов,
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x2DD8; Proto = ICMP; Len: 84
IP: Version = 4 (0x4)
IP: Header Length = 44 (0x2C)
+ IP: Service Type = 0 (0x0)
IP: Total Length = 84 (0x54)
IP: Identification = 11736 (px2DD8)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 63 (0x3F)
IP: Protocol = ICMP - Internet Control Message
IP: Checksum = 0x3334
IP: Source Address = 194.149.105.18
IP: Destination Address = 194.149.104.198
IP: Option Fields = 7 (0x7)
IP: Record Route Option = 7 (0x7)
IP: Option Length = 23 (0x17)
IP: Next Slot Pointer = 16 (0x10)
IP: Route Traveled = 194 (0xC2)
IP: Gateway = 194.149.105.17
IP: Gateway = 194.149.105.18
IP: Gateway = 194.149.104.193
IP: End of Options = 0 (0x0)
IP: Data: Number of data bytes remaining =40 (0x0028)
+ ICMP: Echo Reply, To 194.149.104.198 From 194.149.105.18
Рис. 5.22. Содержимое IP-дейтаграммы
230

Глава 5. Протокол IP (Internet Protocol)
изначально ничем не заполненных. Поэтому индикатор ptr для первого
свободного слота указывает на первый слот. Тогда расширение
IP-заголовка составит 3 + 5 х 4 = 23 байта, в чем мы можем убедиться, взглянув
на захваченную IP-дейтаграмму (см. рис. 5.21).
Для пользователя отображается ответ:
Pinging ns.pvt.net [194.149.105.18] with 32 bytes of data:
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63
Route: 194.149.105.17 ->
194.149.105.18 ->
194.149.104.193
Итак, на пути от отправителя к получателю (194.149.105.18) и обратно
(см. рис. 5.22) удалось обнаружить всего один маршрутизатор, который
на пути к получателю имеет адрес 194.149.105.17, а на обратном пути —
адрес 194.149.104.193 (в данном случае отправитель — это пользователь,
запустивший команду ping).
5.5.3. Временная метка (Timestamp)
Данная опция является вариантом опции Record Route. Она
используется для регистрации времени получения IP-дейтаграммы на каждом из
промежуточных маршрутизаторов. При этом каждый маршрутизатор,
через который проходит дейтаграмма, добавляет в ее заголовок свой IP-
адрес и время получения, измеряемое в миллисекундах с последней
полуночи по универсальному времени UTC (время, называвшееся ранее
гринвичским (GMT) и соответствующее времени на нулевой долготе).
1 40
Код=44
1байт
Длина
1байт
Ptr
1байт
О
F
F
L
1-я врем,
метка
2-я врем,
метка
2-я врем,
метка
Врем, метка
OF - переполнение (4 бита) - маршрутизатор устанавливает это поле, если нет свободных слотов для
добавления временных меток
FL - флаги (4 бита)
FL =0 - каждый маршрутизатор записывает в слот только время, но не IP-адрес (длина слота 4 байта)
FL=1 - каждый маршрутизатор записывает в слот и время, и IP-адрес (длина слота 8 байт)
Отправитель инициализирует до 4 слотов по 8 байт каждый, т. е. для IP-адреса и временной метки.
Отправитель заполняет IP-адреса маршрутизаторов. Когда пакет проходит через маршрутизатор,
адрес которого есть в списке, маршрутизатор добавляет временную метку в слот.
Рис. 5.23. Временная метка (Timestamp)
231

TCP/IP и DNS в теории и на практике. Полное руководство
Для «сбора» временных меток можно использовать команду ping от
Microsoft. Параметр -s размещает слоты для временных меток
(максимум можно разместить 4 слота):
D:\ >ping -s 3 194.149.105.18
Полученная IP-дейтаграмма (сокращенный вид):
IP: Option Fields = 68 (0x44)
IP: Internet Timestamp Option = 68 (0x44)
IP: Option Length = 28 (OxlC)
IP: Time pointer = 5 (0x5)
IP: ....0001 = Both time stamps and IP addresses
IP: Missed stations = 0 (0x0)
IP: Time Route = 0 (0x0)
IP: Gateway = 0.0.0.0
IP: Time Point = 0 (0x0)
IP: Gateway = 0.0.0.0
IP: Time Point = 0 (0x0)
IP: Gateway = 0.0.0.0
IP: Time Point = 16792576 (ОхЮОЗСОО)
IP: Data: Number of data bytes remaining = 40 (0x0028)
Мы видим IP-адреса и временные метки. Миллисекунды нужно
преобразовать в часы, минуты и секунды.
Pinging 194.149.105.18 with 32 bytes of data:
Reply from 194.149.105.18: bytes=32 time<10ms TTL=63
Timestamp: 194.149.105.17 : 52251609 ->
194.149.105.18 : 52531841 ->
194.149.104.193 : 52251610
IP: Option Fields = 68 (0x44)
IP: Internet Timestamp Option = 68 (0x44)
IP: Option Length = 28 (OxlC)
IP: Time pointer = 29 (OxlD)
IP: ....0001 = Both time stamps and IP addresses
IP: Missed stations = 0 (0x0)
232

Глава 5. Протокол IP (Internet Protocol)
IP: Time Route
IP: Gateway = 194.149.105.17
IP: Time Point = 52251609 (0x31D4BD9)
IP: Gateway = 194.149.105.18
IP: Time Point = 52531841 (0x3219281)
IP: Gateway = 194.149.104.193
IP: Time Point = 52251610 (0x31D4BDA)
IP: Data: Number of data bytes remaining =40 (0x0028)
5.5.4. Маршрутизация от источника (Source Routing).
Скрытые возможности атаки на сеть
Жесткая и свободная маршрутизации от источника
Маршрутизация от источника позволяет задать, через какие
маршрутизаторы IP-дейтаграмма должна пересылаться получателю. Путь
представляется в виде списка IP-адресов посещаемых маршрутизаторов.
Имеются два типа маршрутизации от источника:
1. Жесткая маршрутизация от источника (Strict source routing,
код = 8916) — дейтаграмма должна пройти через все указанные
маршрутизаторы и ни через какие другие. Если дейтаграмма
проходит через не указанный маршрутизатор, маршрутизация
прекращается с ошибкой. При этом путь между соседними
IP-адресами должен проходить в границах одного физического сетевого
сегмента. Один физический сегмент может включать в себя
устройства уровня 1 (повторители) и 2 (мосты), но не уровня 3
(маршрутизаторы)
2. Свободная маршрутизация от источника (Loose source routing,
код = 831(.) -дейтаграмма должна быть передана через указанные
маршрутизаторы. Но при этом путь между двумя
последовательными IP-адресами из списка может содержать произвольное
количество промежуточных маршрутизаторов, в списке не
присутствующих.
Механизм маршрутизации от источника довольно сложен. Отдельные
маршрутизаторы корректируют не только поле ptr, но и адрес
получателя в 1Р-дейтаграмме.
233

TCP/IP и DNS в теории и на практике. Полное руководство
Код=7
1байт
39
Длина
1байт
Ptr
1байт
1-й IP-адрес
4 байта
2-й IP-адрес
4 байта
3-й IP-адрес
4 байта
9-й IP-адрес
4 байта
Рис. 5.24. Произвольный элемент «маршрутизации от источника»
К: Отправителю
Слоты:
*S1,S2,S3
Отправитель
( Марш-р Л ( Марш-р Л ( Марш-р
Получатель
K:S1 K:S2 К: S3 К: Получателю
Слоты: Слоты: Слоты: Слоты:
*S2, S3, Получатель S1,*S3, Получатель S1.S2, ^Получатель S1,S2,*S3
Рис. 5.25. Механизм «маршрутизации от источника»
Команда Microsoft ping позволяет использовать маршрутизацию от
источника: опция -j используется для свободной маршрутизации, а опция
-к применяется для строгой маршрутизации.
Пример:
D:\ >ping
Output:
-j 195.47.1.1 10.1.1.1
IP: Source Address = 194.149.104.198
IP: Destination Address = 195.47.1.1
IP: Option Fields = 131 (0x83)
IP: Loose Source Routing Option =131 (0x83)
IP: Option Length = 7 (0x7)
IP: Routing Pointer = 4 (0x4)
IP: Route To Go
IP: Gateway = 10.1.1.1
IP: End of Options = 0 (0x0)
IP: Data: Number of data bytes remaining = 40 (0x0028)
234

Глава 5. Протокол IP (Internet Protocol)
В случае ошибки пользователь будет об этом оповещен:
Pinging 172.17.101.1 with 32 bytes of data:
Reply from 194.149.104.193: Invalid source route specified.
Данное сообщение означает, что на указанном источнике
(194.149.104.193) маршрутизация от источника запрещена из
соображений безопасности.
Атака на сеть
Маршрутизацией от источника можно воспользоваться для атаки на
сеть, причем сразу двумя способами:
• Можно направить передачу IP-дейтаграмм через определенный
маршрутизатор, в котором данные будут захвачены или даже изменены.
• С помощью маршрутизации от источника можно атаковать узлы
локальной сети извне (например, из Интернета), даже если сеть
использует адреса, зарезервированные только для локального
использования (например, 10.0.0.0/8). Данные локальные сети нельзя
адресовать из Интернета непосредственно — это одна из степеней защиты
локальных сетей. Чтобы получить к ним доступ, можно
использовать брандмауэр, если он поддерживает маршрутизацию от
источника, но это маловероятно. Проще всего получить доступ к локальным
Server 10.1.1.1
Рис. 5.26. Маршрутизация от источника — обход брандмауэра
235

TCP/IP и DNS в теории и на практике. Полное руководство
сетям через компьютер, который непосредственно подключен к
Интернету. Например, это может быть ноутбук, который присоединен
к локальной сети, а к Интернету подключается по коммутируемому
(dial-up) соединению, когда пользователь находится за пределами
офиса. Если пользователь установит соединение с двух сторон, он
разрешит IP-forwarding, включив, таким образом, маршрутизацию
от источника. Механизм проиллюстрирован на рис. 5.26. Как
видите, можно очень просто обойти брандмауэр.
5.5.5. Опция IP Router Alert (опция тревоги)
IP-дейтаграмма передается по Интернету через ряд маршрутизаторов.
Маршрутизаторы просто перенаправляют дейтаграммы, но
практически никогда их не читают — ведь сотрудники почтового отделения не
читают чужих писем. Для маршрутизатора все равно, что будет в
передаваемой дейтаграмме — его задача просто передать дейтаграмму дальше
(следующему маршрутизатору).
Дейтаграммы обычно адресуются какому-нибудь компьютеру. Но
существуют такие дейтаграммы, которые адресуются маршрутизаторам.
Маршрутизаторы обрабатывают данные дейтаграммы как обычные IP-
дейтаграммы. Но информация, содержащаяся в них, может быть
«интересна» маршрутизаторам (даже при условии, что дейтаграмма не
адресована конкретному маршрутизатору), поэтому маршрутизаторы перед
передачей дейтаграмм дальше читают их содержимое.
Опция IP Router Alert на доступном языке означает следующее: «Эта
дейтаграмма адресована не вам, но в ней может быть интересная для вас
информация».
1 4
Код= 0x94ie
1 байт
Длина = 4
1байт
Данные = 0
2 байта
Рис. 5.27. Произвольный элемент «IP Router Alert»
236

Глава 5. Протокол IP (Internet Protocol)
5.6. Протоколы ARP и RARP
5.6.1. Общее описание стандартного ARP
Протокол ARP и устройство его заголовка
Предположим, что у нас есть станция локальной сети, и мы бы хотели
передать по протоколу IP некоторые данные другой станции в этой же
сети. Мы знаем свой IP-адрес и IP-адрес получателя, поэтому мы
сможем сформировать IP-дейтаграмму. Но есть небольшая проблема:
поскольку дейтаграмма должна быть помещена в кадр канального уровня,
то есть в Ethernet-кадр, нам нужно узнать канальцые адреса отправителя
и получателя (не IP-адреса). Сделать это можно с помощью протокола
разрешения адреса ARP (Address Resolution Protocol).
Данный протокол позволяет узнать канальный адрес требуемой
станции при условии, что мы знаем ее IP-адрес. Работает он довольно
просто (см. рис. 5.28). В сеть посылается широковещательная дейтаграмма
(канальный адрес FF:FF:FF:FF:FF:FF) с содержанием: «Я — станция
с канальным адресом HW1 и IP-адресом IP1. Я хочу связаться со
станцией с IP-адресом IP2». Станция с адресом IP2 получит это сообщение
и в ответ на него отправит свой канальный адрес (HW2).
1.AR
IP 4
г
1
kHW1
IP1
Кто поможет мне
2.AF
1
rHV
IP1
IP 4
I
V1
Р-запрос
j IP3 |
найти HW2?
IP-ответ
I |РЗ j
I
IP 2
| HV
N2
IP 2
|hv
Канальный
адрес IP-2 ■
HW2
V2
Рис. 5.28. Протокол ARP
237

TCP/IP и DNS в теории и на практике. Полное руководство
Аппарат,
тип
Тип
протокола
Н
S
Р
S
Код
опции
Аппарат.
адрес
отправителя
Протокол
отправителя
Аппаратный
адрес
получателя
Протокол
получателя
щщ^ч<^$т^штмшлш&^^^^>'^'^^^:^ ■ <■
CRc/
111
CRC - контрольная сумма
Рис. 5.29. АЯР-пакет
ARP-пакеты (см. рис. 5.29) помещаются непосредственно в
Ethernet-кадры, то есть им больше не предшествует IP-заголовок. ARP-протокол
фактически не зависит от протокола IP, именно поэтому другие протоколы,
которые не имеют ничего общего с TCP/IP, могут тоже использовать ARP.
Особо следует рассмотреть следующие поля:
• Поле Тип канального протокола (link protocol type) определяет тип
канального протокола, который используется локальной сетью.
Номер 1 зарезервирован для канального протокола Ethernet П. Список
номеров доступен по адресу: http: / /www. iana. org.
• Поле Тип сетевого протокола (network protocol type) определяет,
как и следовало бы ожидать из названия, тип сетевого протокола,
используемого устройством-отправителем. Применяются те же
номера протоколов, которые использовались для поля Протокол
(Protocol) в Ethernet П. Для протокола IP зарезервирован номер 2048.
• Поле HS устанавливает длину канального адреса, а поле PS — длину
сетевого адреса. По умолчанию HS - 6, PS = 4.
• Поле Операция (Operation) определяет выполняемую задачу.
Значение этого поля для ARP-запроса равно 1, а для ARP-ответа
равно 2. Соответственно, значения для RARP-запроса и RARP-ответа
равны 3 и 4.
После этого следует информация: канальный адрес отправителя (source
link address), IP-адрес отправителя, канальный адрес получателя
(destination link address) и IP-адрес получателя.
Схема работы ARP
Запрос посылается широковещательно, поэтому канальный адрес
получателя всегда содержит нули. Ответ заполняется как обычно — ведь
нужно ответить только компьютеру, пославшему широковещательный
238

Глава 5. Протокол IP (Internet Protocol)
запрос, а не всем компьютерам. Ясно, что поля отправителя и
получателя в ответе будут другими. Рассмотрим следующий пример, который все
ставит на свои места:
С:\ > ping 194.149.104.126
Данная команда, отправляющая первую IP-дейтаграмму (пакет ICMP
«echo request»), должна использовать таблицу маршрутизации, чтобы
определить, где находится получатель — в пределах этого сегмента или
за маршрутизатором. Если получатель находится за маршрутизатором
(то есть в другой сети), программа находит канальный адрес
маршрутизатора, чтобы связаться с ним. Если же получатель находится в этой
сети, то программа ищет канальный адрес не маршрутизатора, а
непосредственно получателя (как в нашем случае).
Допустим, мы знаем, что получатель с IP-адресом 194.149.104.126
находится у нас в сети. Нужно определить его канальный адрес.
Операционная система отправителя генерирует ARP-запрос.
+ FRAME: Base frame properties
ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol
+ ETHERNET: Destination address : FFFFFFFFFFFF
+ ETHERNET: Source address : 0020AFFA2589
ETHERNET: Frame Length : 42 (0x002A)
ETHERNET: Ethernet Type: 0x0806 (ARP: Address Resolution Protocol)
EIHERNET: Ethernet Data: Number of data kytes retaining = 28 (QxOOlC)
ARP_RARP:ARP: Request, Target IP: 194.149.104.126
ARP_RARP: Hardware Address Space = 1 (0x1)
ARP_RARP: Protocol Address Space = 2048 (0x800)
ARP__RARP: Hardware Address Length = 6 (0x6)
ARP_RARP: Protocol Address Length = 4 (0x4)
ARP_RARP: Opcode = 1 (0x1)
ARP_RARP: Sender's Hardware Address = 0020AFFA2589
ARP_RARP: Sender's Protocol Address = 194.149.104.121
ARP_RARP: Target's Hardware Address = 000000000000
ARP_RARP: Target's Protocol Address = 194.149.104.126
Получатель немедленно отвечает посылкой пакета.
+ FRAME: Base frame properties
ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol
+ ETHERNET: Destination address : 0020AFFA2589
239

TCP/IP и DNS в теории и на практике. Полное руководство
+ ETHERNET: Source address : 00603E1D9001
ETHERNET: Frame Length : 60 (ОхООЗС)
ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol)
ETHERNET: Ethernet Data: Number of data tytes regaining = 46 (0x002E)
ARP_RARP:
ARP_RARP: Hardware Address Space = 1 (0x1)
ARP_RARP: Protocol Address Space = 2048 (0x800)
ARP_RARP: Hardware Address Length = 6 (0x6)
ARP_RARP: Protocol Address Length = 4 (0x4)
ARP_RARP: Opcode = 2 (0x2)
ARP_RARP: Sender's Hardware Address = 00603E1D9001
ARP_RARP: Sender's Protocol Address = 194.149.104.126
ARP__RARP: Target's Hardware Address = 0020AFFA2589
ARP_RARP: Target's Protocol Address = 194.149.104.121
ARP_RARP: Frame Padding
Получив ответ на этот запрос, система автоматически добавит запись
в свою ARP-таблицу (ARP-кэш) — канальный адрес,
принадлежащий данному IP-адресу. При следующем обращении к компьютеру
194.149.104.126 будет использоваться эта запись, и запрос не будет
повторно генерироваться. Просмотреть ARP-таблицу можно с помощью
команды агр -а. Например:
D:\ > агр -а
Interface: 194.149.104.121
Internet Address Physical ADRESS Type
194.149.104.12 6 00-60-3e-ld-90-01 dynamic
10.1.1.1 00-01-ll-ll-ff-08 static
В ARP-таблице существует два типа записей: статические и
динамические. Первые записи постоянны и не удаляются из ARP-таблицы:
• до перезагрузки компьютера;
• до удаления этой записи с помощью параметра -d команды агр
(см. ниже);
• до получения в широковещательном ARP-сообщении другого
адреса сетевого адаптера.
Динамические записи хранятся в КЭШе не более 10-ти минут: 2
минуты — для неиспользуемых записей и 10 минут — для записей, к которым
часто обращаются.
240

Глава 5. Протокол IP (Internet Protocol)
Можно изменить время жизни динамических записей, для того чтобы
уменьшить нагрузку на сеть. В реестре Windows 2000/XP/2003 в
разделе HKEY__LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
Tcpip\ Parameters есть два параметра:
• ArpCacheLif e задает время жизни (в секундах) неиспользуемой
записи в ARP-таблице.
• ArpCacheMinReferenceLife задает время жизни (в секундах)
часто используемой записи.
Использование статических записей позволяет уменьшить нагрузку на
сеть, поскольку число ARP-запросов немного сократится (это зависит
от количества статических записей и количества компьютеров в сети).
Целесообразно при загрузке системы добавлять в ARP-таблицу каждого
компьютера сети записи серверов вашей сети. Для добавления
статической записи используется команда arp -s. Например:
D:\ > arp -s 10.1.1.1 00-01-11-11-ff-08
Удалить запись еще проще:
D:\ > arp -d 10.1.1.1
5.6.2. Безопасность средствами ARP.
Фильтр ARP
Фильтр ARP — это не настоящий фильтр пакетов, каким, например,
является брандмауэр. Но работает он подобно полноценному фильтру.
Фильтр ARP используется, когда в одном сегменте сети находятся две
фирмы (или два независимых подразделения) и нужно, чтобы одна
фирма «не видела» компьютеры другой.
Сервер
компании А
PC
Ко*
лпания
А
PC
Сервер
компании Б
К
:омпан1
4ЯБ
Рис. 5.30. Фильтр ARP.
Настройка обособленности фрагментов сети
241

TCP/IP и DNS в теории и на практике. Полное руководство
Фильтр ARP необходим, например, чтобы сотрудники компании В
не могли получить доступ к серверам компании А. Для решения этой
задачи мы должны вручную заполнить ARP-кэш сервера А (внести
статические записи). После этого сервер будет получать адреса
сотрудников компании А без использования протокола ARP. Однако
такое решение не вполне надежно, поскольку можно подделать
канальный адрес.
5.6.3. ARP-прокси
ARP-протокол работает только в локальной сети, причем между
запрашивающим и отвечающим компьютером не может быть
маршрутизаторов. Почему? Ответ прост: широковещательные запросы не передаются
маршрутизаторами.
Но что делать, если у нас есть два (или более) сегмента локальной сети,
соединенные маршрутизатором? В этом случае нужно использовать
ARP-прокси, который запускается на маршрутизаторе. С помощью
ARP-прокси компьютер, отправляющий ARP-запрос (пусть это будет
компьютер А), может найти IP-адрес компьютера, находящегося за
пределами маршрутизатора.
Какой аппаратный адрес
компьютера А?
1/2 LAN
1/2 LAN
А
Рис. 5.31. Два сегмента локальной сети, соединенные маршрутизатором
Маршрутизатор не может передать такой запрос в другой сегмент, но
если на нем настроен ARP-прокси, он ответит, что его собственный
канальный адрес связан с запрашиваемым IP-адресом. Компьютер А по-
242

Глава 5. Протокол IP (Internet Protocol)
лучит канальный адрес маршрутизатора и будет «думать», что это адрес
того самого компьютера, который находится за пределами
маршрутизатора. Кадры компьютера А будут направляться на маршрутизатор,
который передаст их потом получателю с указанным IP-адресом.
1/2 LAN
Используйте мой адрес f^ ^"^ч
в качестве аппаратного адреса ( МаРшРУ™-\
узла А узатор^/
I 1/2 LAN
А
Рис. 5.32. ARP-прокси
5.6.4. Протокол RARP (Reverse ARP)
Если протокол ARP используется для преобразования IP-адреса в
канальный, то протокол RARP — для обратного преобразования, то есть
для преобразования канального адреса в IP-адрес. Зачем нужно это
преобразование?
Протокол RARP используется для бездисковых станций. При
включении бездисковая станция не знает ничего, кроме своего канального
адреса, который сохранен в ее сетевом адаптере. Ей нужно найти свой IP-
адрес. Для этого станция посылает широковещательный запрос: «Мой
канальный адрес HW1. Кто знает мой IP-адрес?». В сети должен быть
RARP-сервер, который и сообщит станции ее IP-адрес. На практике
RARP-протокол практически не используется, поскольку он вытеснен
более функциональным протоколом DHCP.
243

TCP/IP и DNS в теории и на практике. Полное руководство
5.7. Протокол IGMP
(Internet Group Management Protocol)
Как и 1СМР, протокол IGMP — сервисный протокол IP,
используемый для передачи групповых сообщений. При передаче IGMP-na-
кеты помещаются в IP-дейтаграммы. Текущая, вторая версия IGMP
описана в RFC-2236. Структура IGMP-пакета (версия 2) показана
на рис. 5.33.
Тип
1Б
MRT
1Б
Контрольная
сумма 2 Б
Групповой IP-адрес 4 Б
Рис. 5.33. Структура IGMP-пакета (версия 2)
Как видно из рисунка, заголовок IGMP-пакета (версия 2) имеет
следующие поля:
• Поле Тип (type) может принимать значения, перечисленные в
таблице 5.6.
Таблица 5.6. Значения поля Тип
Значение (шест-
| надцатеричное)
11
12
16
[ 17
Описание
Запрос узла о принадлежности к какой-нибудь группе (IP Membership query)
Ответ узла о принадлежности к некоторой группе (IGMPvl Membership Report)
Ответ узла о принадлежности к некоторой группе (IGMPv2 Membership Report)
Уйти из группы (IGMPv2 Leave Group )
• Поле Максимальное время ответа — MRT (Maximum Response
Time) используется в запросах маршрутизатора и определяет время
(в десятках секунды), на протяжении которого члены группы
должны повторить свои запросы о членстве в группе. В большинстве
случаев значение поля MRT равно 0.
• Контрольная сумма (checksum) вычисляется так же, как и в случае
с протоколом ICMP.
• Поле Групповой адрес (IP group address) используется в
сообщении Host Membership Report для хранения группового IP-адреса.
В запросе Host Membership Query групповой адрес заполняется нуля-
244

Глава 5. Протокол IP (Internet Protocol)
ми, а для идентификации группы компьютером используется
широковещательный адрес сетевого адаптера.
IP-адреса мультикастинга (multicasting) находятся в диапазоне от
224.0.0.0 до 239.255.255.255. Интервал 224.0.0.0 ... 224.0.0.255
зарезервирован для использования в локальных сетях (см. таблицу 5.7).
Поскольку мультикастинги с этими адресами предназначены только для
локальной сети, значение TTL для них всегда равно 1.
Таблица 5.7. IP-адреса мультикастинга
IP -адрес
224.0.0.1
224.0.0.2
224.0.0.4
224.0.0.5
224.0.0.6
224.0.0.9
Зарезервирован для адресации
Всех компьютеров локальной сети
Всех маршрутизаторов локальной сети
Протокол DVMRP (Distance Vector Multicast Routing Protocol) — см. RFC-1075
Протокол OSPF, все маршрутизаторы — см. RFC-1583
Протокол OSPF, только определенные маршрутизаторы — см. RFC -1583
Протокол RIP-2
TTL для любого ICMP-пакета равно 1. Протокол IGMPv2 (вторая
версия) использует дополнительную опцию IP-заголовка IP Router Alert.
Передача групповых сообщений является очень важной для
Интернета. Взглянем на рис. 5.34. Интернет-радиостанция передает свои данные
с помощью мультикастинга (групповых сообщений). Если бы данные
отправлялись без всякого контроля, они бы дублировались. Например,
одни и те же данные могли «прийти» к маршрутизатору С от
маршрутизатора А и от маршрутизатора В.
Протокол IGMP решает проблему передачи групповых сообщений
в пределах локальной сети. Представим, что у нас есть локальная сеть.
Несколько маршрутизаторов принимают групповые сообщения от
MBONE, они должны решить, как отправить их в локальную сеть.
Вообще, если ни один компьютер локальной сети не нуждается в этих
сообщениях, отправлять их в локальную сеть бесполезно, поскольку это
только увеличит нагрузку на нее. Итак, у нас следующая ситуация:
несколько маршрутизаторов могут отправить групповые сообщения в
локальную сеть, но они не делают этого, поскольку данные сообщения не
нужны компьютерам локальной сети.
Для каждого группового сообщения создается группа IP-адресов.
Маршрутизаторы хранят списки этих групп. Как только к одной из этих групп
подключается компьютер локальной сети, маршрутизаторы начинают
245

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 5.34. Распространение широковещательной рассылки
отправлять групповые сообщения этому компьютеру (и всем другим
компьютерам, подключившимся к группе). Когда последний член
группы выходит из ее состава, передача групповых сообщений в локальную
сеть прекращается.
Если приложение хочет «слушать» радиостанцию 226.1.1.1, компьютер
отправляет запрос о принадлежности к группе 226.1.1.1 (см. рис. 5.35).
ГМарш-pDJ (Марш-рЕ J
Компьютер 1
Компьютер 2
Марш-р F
Рис. 5.35. Компьютер по LAN отправляет запрос на членство в группе
246

Глава 5. Протокол IP (Internet Protocol)
Поля запроса заполняются следующим образом:
IP-header:
TTL=1
IP-sender's address=Computer
IP-recipient's address=224.0.0.2 (to all routers on LAN)
IGMP-paket:
Typ=16
MRT=0 16
IP-multicast address=226.1.1.1
Если компьютер принимает групповые сообщения, то, чтобы
остановить их передачу, нужно отправить простой IGMP-пакет со
значением 0x17 поля Тип (type). Что же случается, если компьютер не успел
отправить этот пакет, например, пропало напряжение? Представим,
что групповые сообщения в нашу сеть отправляет маршрутизатор Е
(см. рис. 5.36).
f Марш-р D J ( Марш-р Е
f Марш-р F )
Компьютер 1
Компьютер 2
Рис. 5.36. Маршрутизатор Е: «Есть ли в LAN еще какие-либо члены?»
Периодически маршрутизатор опрашивает всех членов группы: «Есть
ли кто в группе?» (поле Тип =11). Если на этот запрос не ответит ни
один компьютер (все выключены), маршрутизатор прекращает
передачу групповых сообщений в эту группу. Маршрутизатор может
опрашивать членов группы двумя способами:
• Общий запрос: отправляется всем компьютерам сети, то есть
требует подтверждения о принадлежности к группам от всех компьютеров
всех групп. Поле IP-адреса содержит нули.
• Частичный запрос: опрашиваются только компьютеры
определенной группы.
247

TCP/IP и DNS в теории и на практике. Полное руководство
Где:
IP-header:
TTL=1
IP-sender's address=Router E
IP-recipient's address=224.0.0.1 (ко всем системам
локальной сети)
IGMP-paket:
Туре=1116
MRT>0 for version 2, =0 for version 1 (то постоянною s)
IP-address of a multicast=226.1.1.1 (частичный запрос),
0.0.0.0 (общий запрос)
Однако остается вопрос, каким образом между собой
договариваются отдельные маршрутизаторы в LAN, если их там больше, чем один.
Маршрутизаторы в отношении протокола IGMP работают в двух
режимах:
• Заявитель (Applicant), который посылает в LAN запросы на
членство в группах;
• Слушатель (Listener), который не является активным, а только
прослушивает трафик и, если в LAN находится какой-либо заявитель,
он не вмешивается.
Маршрутизатор после своего запуска начинает работать как заявитель,
однако, если он выявит, что в LAN имеются также запросы
маршрутизатора с более высоким IP-адресом, то он переключается в режим
слушателя.
5.8. Мультикастинг и канальный протокол
Мы описали механизм широковещательной передачи, но как
определить канальный адрес получателя? Как мы уже знаем, протокол ARP
позволяет определить канальный адрес по IP-адресу, то есть ARP
определяет соотношение IP-адреса и канального адреса. Данное
соотношение называется маппингом (от англ. mapping, отображение) IP-адреса
в канальный адрес.
Но у нас несколько другая ситуация: ведь нам нужно отправить данные
всем системам локальной сети. Для этих целей канальный протокол
248

Глава 5. Протокол IP (Internet Protocol)
(Ethernet, FDDI) использует специальный адрес: FF:FF:FF:FF:FF:FF.
Данный адрес позволяет адресовать все компьютеры локальной сети.
Но что делать с теми групповыми сообщениями, которые адресованы не
всем компьютерам локальной сети, а только компьютерам определенной
группы? Обычно компьютер принимает только те кадры, которые ему
адресованы (можно переключить сетевую карту в разнородный режим,
в котором будут приниматься все кадры, но многие сетевые интерфейсы
WLAN и FDDI не могут быть переключены в этот режим).
Канальный протокол также поддерживает групповые сообщения. В них
младший бит первого байта канального адреса установлен как 1.
Выходит, что широковещательные сообщения — это частный случай
групповых сообщений. Но как выполнить маппинг IP-мультикастинга в
канальный мультикастинг? Первые три байта 6-байтового канального
адреса определяют производителя сетевой платы, а оставшиеся 3 — ее
серийный номер.
Организация IANA зарезервировала для себя идентификационный
номер производителя 00:00:5е. Данное значение используется в качестве
первых 3-х байтов маппинга IP-мультикастинга в канальный
мультикастинг (см. рис. 5.37). При этом маппинг (отображение) не может быть
однозначным.
Младший бит первого байта канального адреса должен быть равен 1
(поскольку это канальный мультикастинг). Поэтому вместо значения
00:00:5е в первых трех байтах у нас будет значение 01:00:5е. Часть А
(см. рис. 5.36) IP-адреса определяет мультикастинг, поэтому она всегда
постоянна. Часть В не отображается.
Итак, если два мультикастинга отличаются только частью В, они
отображаются в тот же самый канальный адрес. Например, IP-адреса 224.0.1.1,
224.128.1.1 и 225.0.1.1 всегда отображаются в 01:00:5е:00:01:01.
IP-адрес
-4 ►!-«
Vi1i°i i i
Аппаратный адрес
о.о.о.о .о .о.о .ilo .о.о.о .о.о .o.olo.i ,о.1.1.1.1
—*•
I
'
-«
I I I
t
1l°l 11 ■
I I I I I I I I I I I I I I I I
23 отображенных бита
1111111111111111
►-;
I I I |
Y
l l l I
01 00 5e
Рис. 5.37. Формат IP-адреса и канального адреса
249

TCP/IP и DNS в теории и на практике. Полнре руководство
Канальный уровень принимает следующие кадры:
• адресованные данному компьютеру;
• широковещательные кадры;
• групповые сообщения, предоставляемые канальному уровню
протоколами высших уровней (предоставляют адрес 224.0.0.1 и все
производные от него адреса, которые получаются с помощью
однозначного отображения (маппинга)).

Глава 6 IP-АДРЕСА
ЧТО ТАКОЕ IP-АДРЕС
И КАКОЙ У НЕГО ФОРМАТ
КЛАССЫ И СПЕЦИАЛЬНЫЕ АДРЕСА
ПОДСЕТИ И МАСКИ СЕТИ
МЕХАНИЗМ БЕСКЛАССОВОЙ
МЕЖДОМЕННОЙ МАРШРУТИЗАЦИИ
CIDR
TCP/IP и DNS в теории и на практике. Полное руководство

6.1. Что такое IP-адрес и какой у него формат
IP-адрес — это уникальный адрес сетевого интерфейса. Если в
системе установлено несколько сетевых интерфейсов, и все они используют
протокол IP, то у каждого интерфейса будет свой собственный IP-адрес.
Это как номер квартиры в доме: если дом многоквартирный, то у каждой
квартиры будет свой номер.
Но протокол IP предоставляет и другую возможность: одному
физическому сетевому интерфейсу может быть назначено несколько IP-адресов.
Первый IP-адрес называется первичным адресом, а все остальные —
вторичными, или псевдонимами. Используя вторичные IP-адреса,
например, на WWW-серверах, можно запускать несколько WWW-cep-
веров разных компаний на одном физическом интерфейсе. Правда,
для WWW-серверов данная технология используется редко, вместо
нее применяется так называемая технология виртуальных
WWW-серверов. В этом случае несколько WWW-серверов используют один
общий IP-адрес.
У большинства компьютеров есть только один сетевой интерфейс,
поэтому IP-адрес единственного сетевого интерфейса будем называть IP-
адресом компьютера.
IP-адрес состоит из 4-х байтов, которые разделены точками.
Используются три способа записи IP-адресов:
• Двоичная запись: отдельные байты записываются в двоичном виде
и разделяются точкой, например: 10101010 . 01010101.11111111
.11111000.
• Десятичная запись (наиболее часто используемая): байты
записываются в десятичной системе и разделяются точкой, например:
170.85.255.248.

Глава 6. IP-адреса
• Шестнадцатеричная запись: каждый байт записывается в шестнад-
цатеричной системе, например: аа . 55 . f f . f 8.
IP-адрес состоит из двух частей:
• Адреса (локальной) сети;
• Адреса компьютера в (локальной) сети.
Проблема заключается в определении этих частей — какая часть является
адресом сети, а какая — адресом компьютера. Ведь даже сам термин «сеть»
довольно неточен — сети есть большие и маленькие, локальные и
глобальные. В данной главе мы обсудим способы решения этой проблемы.
6.2. Классы и специальные адреса
Классы IP-адресов
Эра Интернета началась с 1993 года прошлого века. На данном этапе
термин «сеть» был определен стандартом RFC-796 (J.Postel, 1.9.1981).
В то время считали, что 4-х байтов будет достаточно для IP-адреса
(четыре октета — 8-разрядных двоичных чисел).
IP-адрес состоит из адреса сети и адреса компьютера (узла) в пределах
этой сети (см. рис. 6.1). Первые биты первого байта IP-адреса
определяют, сколько байтов IP-адреса нужно для адресации сети. Существует
пять классов адресов сети:
46
Адрес сети
Адрес узла
Рис. 6.1. Структура IP-адреса
Класс А: значение старшего бита первого байта равно 0. Остальные
семь битов первого октета представляют адрес сети, а все прочие —
адрес хоста в пределах этой сети. Сетей класса А не очень много —
всего 126 (номера 0 и 127 зарезервированы для служебного
использования). Адреса IPv4 класса А предназначены для поддержки очень
больших сетей. IP-адреса класса А лежат в интервале от 1.0.0.0. до
126.255.255.255. При этом каждая сеть класса А может поддерживать
253

TCP/IP и DNS в теории и на практике. Полное руководство
до 16777214 уникальных хостов (224-2 при этом 2 вычитается, так
как IP-адрес, состоящий из одних нулей используется для
идентификации сети, а адрес, состоящий из одних единиц — для групповой
рассылки по этой сети).
• Класс В: значение двух старших битов первого байта — 102.
Оставшиеся 6 битов первого байта, а также второй байт представляют
адрес сети. Несложно посчитать, что сетей класса В может быть 214,
и каждая из них может содержать 216-2 компьютеров (65534).
Адреса класса В предназначены для поддержки средних и крупных сетей
и лежат в интервале от 128.1.0.0 до 191.255.255.255.
• Класс С: первые три бита первого байта — 1102. Оставшиеся 5 битов
и следующие 2 байта используются для адресации сети. Считаем:
сетей класса С может быть 221-2 (то есть 2097150), каждая сеть может
содержать 254 (256-2) компьютера.
• Класс D: значение первых четырех битов — 1110. Это особый адрес —
групповой (multicast), созданный для поддержки групповой
рассылки в сетях IP. Оставшаяся часть этого адреса не делится на адрес сети
и адрес компьютера. Групповой адрес (multicast address) представляет
собой уникальный сетевой адрес — посланные на него пакеты
направляются заранее определенной группе адресов. Таким образом, один
отправитель может передать серию пакетов, которая будет
маршрутизирована нескольким получателям одновременно. Данный подход
гораздо эффективнее персональной передачи данных каждому
получателю из группы, которым должны быть переданы одни и те же данные.
• Класс Е: значение первых четырех битов — 11110. Этот класс
зарезервирован для дальнейшего использования. Адреса IP класса Е
лежат в интервале от 240.0.0.0 до 255.255.255.255.
Таблица 6.1. Классы IP-адресов
Класс
А
В
С
D
Е
1 -й байт IP-адреса
Osssssss
1-127м
1Ossssss
128-1911П
110sssss
192-22310
1110mmmm
224-23910
>23910
2-й байт IP-адреса
SSSSSSSS
SSSSSSSS
mmmmmmmm
3-й байт IP-адреса
4-й байт IP-адреса
Адрес компьютера
Адрес компьютера
SSSSSSSS
Адрес компьютера
mmmmmmmm mmmmmmmm
254

Глава 6. IP-адреса
Специальные IP-адреса
Формат IP-адреса следующий:
network.computer
где сеть (network) представляется одним байтом для класса А, двумя
байтами для класса В и тремя байтами для класса С. Остальное
пространство в IP-адресе служит для идентификации компьютера (хоста,
computer).
Если адрес сети или компьютера (computer) содержит только нули
(в двоичном представлении, то есть 00...0), то под этим адресом
подразумевается этот компьютер в этой сети. Если же адрес сети или
компьютера содержит только единицы, то это широковещательный адрес
(broadcast), адресующий все компьютеры данной сети.
В таблице 6.2 представлены адреса, зарезервированные для служебного
использования.
Таблица 6.2. IP-адреса специального назначения
Тип адреса
1 о.о.о.о
00... 0. computer
1 network.OO...O
network. 11... 1
11...1 (в десятичной форме: 255.255.255.255)
127.*
Что означает?
Этот компьютер в этой сети, то есть текущий компьютер
Компьютер в этой сети
Адрес сети
Широковещательный адрес, адресующий все
компьютеры сети с адресом network. В качестве адреса сети
можно использовать любой адрес, то есть сеть может быть
удаленной, а не локальной
Широковещательный адрес в локальной сети (limited
broadcast)
Программная петля (loopback) — пакеты с адресом
127.* никогда не выходят за пределы компьютера — то
есть компьютер отправляет пакеты и сам их получает.
Используется для тестирования. Обычно используется
адрес 127.0.0.1
Каждый сетевой интерфейс (сетевая плата) имеет, по крайней мере,
один уникальный адрес (unicast). Кроме того, у каждого компьютера
есть адрес локальной петли — 127.0.0.1. Данный адрес не является
уникальным, поскольку он одинаков у всех компьютеров.
Пример: сеть 192.168.6.0 является сетью класса С. Как
идентифицировать сразу все компьютеры сети? Для этого используется
широковещательный адрес (broadcast) сети — 192.168.6.255. После выполнения
команды:
255

TCP/IP и DNS в теории и на практике. Полное руководство
ping 192.168.6.255
Все компьютеры этой сети получат ICMP Echo-запрос. Версия ping от
Microsoft не отображает ответы от всех компьютеров, но в других
операционных системах с помощью этой команды вы увидите, какие
компьютеры работают в сети.
Если вы не знаете адреса этой подсети, можно использовать
групповой адрес 224.0.0.1 (означает «все компьютеры в этой подсети», см.
RFC-1112):
ping 224.0.0.1
6.3. Подсети и маски сети
Почему стандартных механизмов IPv4
недостаточно для адресации
Первейшая проблема стандартной IP-адресации заключалась в том, что
на фоне общего развития Интернета (и достаточно бурного) большое
количество IP-адресов резервировалось, но оставалось
неиспользованным. Что, в свою очередь, приводило к быстрому перерасходу адресного
пространства. Вызвано это было большими различиями в количестве
IP-адресов в разных классах. Давайте рассмотрим пример. Допустим,
имеется компания, которой требуется 350 IP-адресов. Одной сети
класса С для такой организации будет недостаточно (254 адреса).
В результате придется либо выделить под нее две сети класса С, или
одну класса В. Оба варианты плохи. В первом случае, хотя
перерасход адресов и небольшой (в двух сетях класса С соответственно будет
508 адресов, что на 158 больше необходимых 350-ти), но существенно
усложнится маршрутизация, так как придется по сути
администрировать и маршрутизировать две сети, под каждую из которых в таблице
маршрутизации заводится своя запись (неважно, что они принадлежат
одной организации).
Неудобство от этого было настолько велико, что по началу
предпочитали использовать второй вариант и предлагать всем, кому нужно больше
256 IP-адресов сети класса В с их 65534 адресами. При этом большая
часть из них не использовалась, но на заре Интернета это было
несущественно. Когда же, с развитием Интернета, встала проблема перерасхода
256

Глава 6. IP-адреса
адресного пространства, массовая выдача адресов класса В была
приостановлена, но это все равно не решало проблему.
Необходимо было либо увеличить разрядность IP-адреса (и тем самым
увеличить количество потенциально доступных адресов), либо
существенно модернизировать и повысить эффективность использования
существующего 32-разрядного адресного пространства.
В действительности пошли обоими путями. Был разработан протокол
IPv6 (основанный на 48-разрядном IP-адресе), и был существенно
оптимизирован существующий IPv4. К самым важным улучшениям IPv4
относятся:
• Использование подсетей и масок подсетей.
• Использование масок подсетей переменной длины (VLSM, Variable
Length Subnet Masks).
• CIDR.
Если протокол IPv6 еще не получил широкого распространения, то
вышеприведенные модификации IPv4 применяются повсеместно.
Кстати говоря, именно благодаря этому и не используется пока протокол
IPv6 — после оптимизации старого IPv4 его в большинстве случаев
стало хватать, а внедрение IPv6 было приторможено (тем не менее оно
скоро произойдет, так как даже оптимизированного IPv4 стало не
хватать на фоне повсеместной «сетезации» практически всех электронных
приборов).
Подсети и маски
Изначально в Интернете использовалась двухуровневая схема
адресации: в рамках IP-адреса сначала шел идентификатор сети, а потом —
идентификатор хоста (в этой сети). Однако такая иерархия
подразумевает, что одной организации принадлежит только одна сеть. Именно
поэтому и шли на то, чтобы организациям выдавать сети класса В, даже
если им (организациям) требовалось лишь немного больше адресов, чем
было в сети класса С. Несмотря на перерасход адресного пространства
сточки зрения маршрутизации сети это было гораздо выгоднее. Что,
в конечном счете, стало приводить к резкому сокращению свободных
IP-адресов.
9 Зак.518
257

TCP/IP и DNS в теории и на практике. Полное руководство
От подобной практики отказались. Выхода не было, в ущерб
эффективности маршрутизации стали одной организации выдавать по нескольку
сетей более низкого класса (как правило, класса С). Но при этом
придумали механизм, который бы позволял однозначно идентифицировать
компьютеры одной организации, даже если они принадлежат
нескольким сетям класса С. Для этого пришлось ввести в обращение подсети
третий уровень в иерархии адресации Интернета.
По своей сути сеть организации, как правило, представляет собой
локальную сеть (в рамках которой и распределены адреса из нескольких
сетей какого-либо класса), подключенную через какую-либо общую
точку — маршрутизатор или шлюз. Такая локальная сеть и может
интерпретироваться как подсеть.
Снаружи, со стороны Интернета, обращение ведется лишь к одному
устройству сети — шлюзовому маршрутизатору, и совершенно все равно,
сколько компьютеров и сетей стоит за этим маршрутизатором. При этом
трафик направляется на него, а он уже сам занимается его последующим
распределением. При этом IP-адрес в подсети состоит из трех
компонентов:
• Идентификатора сети.
• Идентификатора подсети.
• Идентификатора хоста.
Идентификаторы подсети и хоста содержатся в идентификаторе хоста
исходного IP-адреса. При этом фактически забирается часть битов хос-
тового идентификатора для идентификации подсети. Осуществляется
это путем использования специального псевдоадреса IP, называемого
маской сети.
Маска сети представляет собой 32-разрядное двоичное число, которое
может выражаться в десятичной записи с точечным разделителем.
Маска сообщает конечным системам сети (включая маршрутизаторы и
другие хосты), какие именно биты IP-адреса следует интерпретировать как
идентификатор сети и подсети. Такие биты называются расширенным
сетевым префиксом. Остальные биты IP-адреса, соответственно,
идентифицируют хосты в подсети.
Биты маски, идентифицирующие сеть, равны 1, а хостовые биты равны 0.
Давайте разберемся, как работают маски. Как мы уже знаем, различные
классы сети можно определить по первым битам первого байта. Посколь-
258

Глава 6. IP-адреса
ку класс А использует только первый байт, то в первом байте все биты
будут установлены (1), а во всех остальных байтах сброшены (0):
11111111.00000000.00000000.00000000
В десятичной форме это соответствует записи:
255.0.0.0 (или ff.00.00.00 в шестнадцатеричной форме).
Аналогично запишем сетевую маску для сети класса В (в десятичной
форме):
255.255.0.0 (или ff.00.00.00 в шестнадцатеричной форме).
И для класса С:
255.255.255.0 (или f f . 00 . 00 . 00 в шестнадцатеричной форме).
Сетевые маски, соответствующие сетям классов А, В и С, называются
стандартными сетевыми масками.
Сетевые маски помогают выделить адрес сети из IP-адреса. Пусть у нас
есть IP-адрес 170.85.255.248. Запишем его в двоичной форме:
10101010.01010101.11111111.11111000
Сначала посмотрим на первый байт адреса и по нему определим класс
сети (см. таблицу 6.1). Это сеть класса В. Стандартная сетевая маска
сети класса В:
11111111.11111111.00000000.00000000
Чтобы получить адрес сети, нужно умножить IP-адрес на сетевую маску
побитно:
10101010.01010101.11111111.11111000
X 11111111.11111111.00000000.00000000
10101010.01010101.00000000.00000000
После обратного преобразования в десятичную форму получим адрес
сети 170.85.0.0.
Таким образом, структура IP-адреса несколько изменилась. IP-адрес
состоит уже из трех элементов: адрес сети, адрес подсети и адрес
компьютера (см. рис. 6.2.).
С точки зрения адреса сети, адрес сети и адрес подсети — это как бы
одно целое. Просто в новом стандарте произошло разделение на сети и
подсети.
259

TCP/IP и DNS в теории и на практике. Полное руководство
Адрес сети
Адрес узла
Адрес
компьютера
Рис. 6.2. Структура IP-адреса
Возьмем сеть класса С — 192.168.0.0. Ей всегда соответствует маска
255.255.255.0, поскольку это сеть класса С. Маска 255.255.255.0
называется стандартной сетевой маской класса С.
В таблице 6.3. показано, как сеть 192.168.0.0 с помощью сетевых масок
разбивается на подсети (стандартная сетевая маска выделена жирным).
Таблица 6.3. Пример разделения сети 192.168.0.0 на сетевые маски
Маска
255.248.0.0
255.252.0.0
255.254.0.0
255.255.0.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0
255.255.255.128
255.255.255.192
255.255.255.224
255.255.255.240
255.255.255.248
255.255.255.252
255.255.255.254
255.255.255.255
Кол-во единиц
в маске
13
14
15
16
21
22
23
24
25
26
27
28
29
30
31
32
Интервал IP-адресов
с 192.168.0.0 до 192.175.255.255
с 192.168.0.0 до 192.171.255.255
с 192.168.0.0до 192.169.255.255
с 192.168.0.0ДО 192.168.255.255
с 192.168.0.0 до 192.168.7.255
с 192.168.0.0 до 192.168.3.255
с 192.168.0.0до 192.168.1.255
с 192.168.0.0 до 192.168.0.255
с 192.168.0.0 до 192.168.0.127
с 192.168.0.0 до 192.168.0.63
с 192.168.0.0до 192.168.0.31
с 192.168.0.0 до 192.168.0.15
с 192.168.0.0 до 192.168.0.7
с 192.168.0.0до 192.168.0.3
с 192.168.0.0 до 192.168.0.1
Внимание! Эта сеть — полный абсурд,
так как она содержит только два
адреса: адрес сети и
широковещательный адрес, но не содержит адресов
компьютеров
Адрес компьютера (host address)
192.168.0.0
Сокращенная запись
маски
192.168.0.0/13
192.168.0.0/14
192.168.0.0/15
192.168.0.0/16
192.168.0.0/21
192.168.0.0/22
192.168.0.0/23
192.168.0.0/24
192.168.0.0/25
192.168.0.0/26
192.168.0.0/27
192.168.0.0/28
192.168.0.0/29
192.168.0.0/30
192.168.0.0/31
192.168.0.0/32
Адреса с масками с меньшим количеством единиц, чем в стандартной,
называются адресами суперсетей (см. верхнюю часть таблицы — до
выделенной строки; о суперсетях речь пойдет в разделе 6.4), а адреса с масками
с большим количеством единиц, чем в стандартной, называются адресами
подсетей (см. нижнюю часть таблицы — после выделенной строки).
260

Глава 6. IP-адреса
Как уже говорилось, поле маскирования является общим для IP-адреса
сети и подсети (см. рис. 6.3).
1Р-адрес (4 б)
•* ►
Адрес сети
Адрес узла
Адрес
компьютера
: *
Маска сети (4 б)
Единицы
Нули
Рис. 6.3. IP-адрес и его сетевая маска
В таблице 6.4 представлены зарезервированные для специального
использования адреса.
Таблица 6.4. Зарезервированные адреса
network.subnetwork.00...0
1 network.OO...O.OO...O
network.subnetwork. 11...1
network.11...1.11...1
Адрес подсети как таковой
Адрес сети
Широковещательный адрес подсети
Широковещательный адрес для всех подсетей
в пределах сети
Очевидно, что подсеть, содержащая только нули в адресе подсети,
представляет целую проблему: сложно дифференцировать адрес сети и адрес
подсети, то есть непонятно, что является адресом сети, а что — адресом
подсети. Аналогичная ситуация возникает, когда адрес подсети
содержит одни единицы, поскольку неясно, является ли адрес групповым для
одной подсети или всех подсетей (всей сети). По этим причинам данные
сети не используют, а большинство программных продуктов вообще не
поддерживает эти подсети.
Широковещательная передача всем подсетям одной сети — это только
теория, на практике я ни разу с ней не сталкивался. Возможно, потому
что маршрутизатор «не знает» структуру удаленных подсетей.
Подсети используются большими компаниями для создания отдельных
локальных сетей. Из-за недостатка IP-адресов многими компаниями
выделены только сети класса С. Впоследствии, эти сети могут быть
разделены на меньшие размером подсети.
261

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 6.4. Интернет состоит из сетей, которые могут быть разделены на подсети
Использование постоянных и переменных сетевых масок
Рассмотрим небольшой пример. Мне нужно подключить
компанию к Интернету. Нашей компании выделена сеть класса С (ее адрес
194.149.115.0, то есть 11000010.10010101.1110011.00000000 в двоичной
форме). Можно сказать, нам еще повезло, что компании выделена вся
сеть класса С, а не только какая-то ее часть.
Структура компании довольно сложна. Ее сеть состоит из нескольких
локальных сетей и последовательных линий, соединяющих эти сети.
Нужно разбить сеть на подсети — для каждого подразделения
компании. Снаружи сеть компании будет казаться сетью со стандартной
сетевой маской.
Поскольку первые три байта выделенного IP-адреса постоянны, в
дальнейшем мы будем работать только с последним байтом IP-адреса
(первые три байта остаются постоянными — 194.149.115). Очевидно, что
для разделения сети на подсети нужно использовать нестандартную, но
постоянную сетевую маску, например: 255.255.255.240 (11111111.1111
1111.11111111.11110000 — первая половина последнего байта исполь-
262

Глава 6. IP-адреса
зуется как адрес подсети) вместо 255.255.255.0. Данная сетевая маска
(255.255.255.240) может использоваться для разделения сети класса С
на 16 подсетей по 16 адресов каждая.
Таблица 6.5. Постоянная сетевая маска
1 Подсеть в двоичной за-
1 писи (последний байт
IP-адреса
1 194.149.115.0)
00000000 до 00001111
| 00010000до00011111
| 00100000до00101111
| 00110000 до 00111111
| 01000000 до 01001111
| 01010000 до 01011111
| 01100000 до 01100000
| 01110000 до 01111111
| 10000000 до 10001111
| 10010000 до 10011111
| 10100000 до 10101111
| ЮПООООдо 10111111
| 11000000до 11001111
11010000 до 11011111
11100000 до 11101111
11110000 до 11111111
(а двоичной
записи)
11110000
Адрес подсети
(в десятичной
записи)
.0
.16
.32
.48
.64
.80
.96
.112
.128
.144
.160
.176
.192
.208
.224
.240
Сетевая маска
(в десятичной
записи)
.240
Макс, кол-во компьютеров
в подсети (без адреса сети
и широковещательного
адреса)
0 (не уникальная подсеть,
не используется)
14 |
14
14
14
14
14
14
14
14
14
14
14
14
' 14
0 (не уникальная подсеть,
не используется)
Каждая подсеть состоит из 16-тй адресов, 2 из которых
используются для служебных целей (адрес сети и широковещательный адрес),
следовательно, в каждой такой подсети может быть до 14-ти
компьютеров. Нули в маске — это адрес подсети, единицы —
широковещательный адрес. Например, адрес 194.149.115.32 — это адрес третьей
подсети, а адрес 194.149.115.47 — широковещательный адрес для этой
подсети (194.149.115.255 — это широковещательный адрес для всей сети
194.149.155.0). Адреса компьютеров могут быть назначены только из
диапазона от 194.149.155.33 до 46.
Также непонятно, является ли адрес 194.149.155.255
широковещательным для всех подсетей этой сети или только для подсети 194.149.115.240.
По этой причине последняя подсеть обычно не используется.
Подобная проблема — это «коллизия» адресов; адреса сети и адреса подсети
194.149.115.0. Поэтому первая подсеть также не используется.
263

TCP/IP и DNS в теории и на практике. Полное руководство
В предыдущем примере мы использовали постоянную сетевую маску.
Но ее использование далеко не всегда оправдывает себя на практике —
так как при этом вся сеть ограничивается одной маской сети. В то же
время в одном подразделении компании может быть всего 5
компьютеров, а в другом — 25.
Кроме того, даже если на текущий момент ситуация с сетевой маской
вполне нормальная и отрегулированная, то вполне вероятно, что в
будущем вам понадобится увеличить количество компьютеров в сети, —
тогда вам придется изменять маску всей сети, что является весьма сложной
и длительной процедурой. Решение подобных проблем заключается
в использовании так называемых масок подсетей переменной длины
(см. таблицу 6.6) — VLSM (Variable Length Subnet Masks).
VLSM повышает эффективность использования адресного
пространства IP в границах организации, так как сетевому администратору
предоставляется возможность настройки маски по конкретным
требованиям каждой подсети.
Таблица 6.6. Переменная сетевая маска
Подсеть в двоичной
записи (последний байт
IP-адреса
194.149.115.0)
00000000 to 00000011
| 00000100 to 00000111
| 00001000 to 00001111
I 00010000to00011111
I 00100000 to 00111111
| 01000000 to 01111111
| 10000000to 10111111
| 11000000 to 11011111
I 11100000 to 11101111
I 11110000 to 11100011
mnoooto 11111011
umiooto 11111111
Сетевая маска
(в двоичной
записи)
11111100
11111100
11111000
11110000
11100000
11000000
11000000
11100000
11110000
11111000
11111100
11111100
Адрес подсети
(в десятичной
записи)
.0
.4/30
.8/29
.16/28
.32/27
.64/26
.128/26
.192/27
.224/28
.240/29
.248/30
.252/30
Сетевая маска
(в десятичной
записи)
.252
.252
.248
.240
.224
.192
.192
.224
.240
.248
.252
.252
Макс, кол-во компьютеров
в подсети (без адреса сети
и широковещательного
адреса)
0 (не уникальная подсеть,
не используется)
2
6
14
30
62
62
30
14
6
2
0 (не уникальная подсеть,
не используется)
Очевидно, что самая большая подсеть содержит 64 адреса (2 из них
зарезервировано); если нам нужна локальная сеть с большим количеством
компьютеров (больше, чем 62), целесообразно использовать всю сеть
класса С.
264

Глава 6. IP-адреса
Рассмотрим несколько примеров. Вычислим адрес сети, в которой
находится компьютер с адресом 10.0.0.239 (сетевая маска 255.255.255.240).
Для этого нужно побитно умножить IP-адрес на маску подсети (ясно,
что до этого нужно преобразовать IP-адрес и маску в двоичную форму):
00001010.00000000.00000000.11101111 т.е. 10.0.0.239
х 11111111.11111111.11111111.11110000 т.е. 255.255.255.240
00001010.00000000.00000000.11100000 = 10.0.0.224
Искомый адрес сети — 10.0.0.224. Может ли этот адрес быть адресом
компьютера? Нет. Почему? Давайте выделим адрес компьютера из
адреса сети:
00001010.00000000.0000000.1110 11111
< сеть > I <узел>
Формат адреса следующий: сеть.единицы. Это означает, что данный
адрес не является адресом компьютера, так как это широковещательный
адрес подсети 10.0.0.224. Попробуем «пропинговать» все компьютеры
этой подсети:
ping 10.0.0.224
В UNIX-версии команды ping вы увидите ответы ото всех компьютеров
подсети, которые в данный момент работают в сети (попросту говоря,
включены в данный момент).
6.4. Механизм бесклассовой междоменной
маршрутизации CIDR
Бесклассовая адресация
Одним из самых последних модификаций протокола IP, направленных
на оптимизацию использования адресного пространства, является
механизм бесклассовой междоменной маршрутизации (CIDR — Classless
Interdomain Routing).
Эта технология не предназначена для оптимизации использования уже
выданных IP-адресов (размораживания зарезервированных, но не
используемых адресов), а направлена на замедление и оптимизацию
выдачи новых IP-адресов (из оставшихся свободных).
265

TCP/IP и DNS в теории и на практике. Полное руководство
Примечание.
Благодаря чему планируется существенно замедлить расходование
адресного пространства IPv4 на время ввода в эксплуатацию протокола
IPv6.
Для этого в механизме CIDR можно выделить следующие ключевые
аспекты:
• Исключение классовой адресации.
• Расширенное агрегирование маршрутных данных, когда одна запись
в таблице маршрутизации может представлять адресные
пространства нескольких сетей.
• Поддержка суперсетей
Суперсети, автономные системы
Суперсеть представляет собой не что иное, как несколько смежных
блоков адресных пространств класса С, имитирующих одно адресное
пространство большего размера.
Что касается автономных систем, то здесь следует «начать издалека».
Интернет является системой взаимосвязанных интернет-провайдеров
(или подобных организаций), обеспечивающих подключение к сети
Интернет. Кроме интернет-провайдеров, в развитии всемирной сети
участвуют другие организации, которые не являются провайдерами
в нашем с вами понимании, однако являются ими с точки зрения сетей.
Так вот в Интернете не употребляется слово «провайдер», вместо него
используется термин «автономные системы».
Провайдеры (автономные системы) передают IP-дейтаграммы или
в пределах своей сети, или между другими сетями. Кроме обычных
провайдеров, передающих дейтаграммы друг другу, имеются еще
и транзитные провайдеры, которые обеспечивают обмен данными
между обычными провайдерами.
В терминах маршрутизации (то есть передачи IP-пакетов), Интернет
делится на автономные системы (autonomous systems). Автономная
система представляется 2-байтовым номером. Для маршрутизации
между автономными системами используются EGP-протоколы (Exterior
Gateway Protocols). Если быть предельно точным, то сегодня работает
протокол BGP (Border Gateway Protocol) четвертой версии.
266

Глава 6. IP-адреса
У каждого провайдера есть одна автономная система или несколько
автономных систем. Интернет-провайдеры являются администраторами
автономных систем (АС). АС-администраторы распределяют вверенные
им IP-адреса между своими клиентами. В главе, посвященной интернет-
администрированию, будут показаны проблемы распределения
IP-адресов при использовании так называемых локальных интернет-реестров
(Local Internet Registries).
В АС используются интервалы IP-адресов. Каждый интервал может быть
«встроен» в один адрес суперсети, то есть целый интервал адресов теперь
представляется одним адресом. Это экономит память маршрутизаторов
(ведь для записи всего интервала нужна только одна запись в таблице
маршрутизации) и делает администрирование АС намного проще.
Рис. 6.5. Интернет делится на автономные системы, которые, в свою очередь, могут быть
разделены на суперсети. Суперсети делятся на сети, а те —на подсети
Соединение интервалов IP-адресов — очень простая задача. Например,
у нас есть интервал адресов сетей 194.149.96.0 -194.149.128.0. Данный
интервал может быть записан как адрес суперсети 194.149.96.0 с сете-
267

TCP/IP и DNS в теории и на практике. Полное руководство
вой маской 255.255.224.0. В сокращенной форме интервал
записывается так: 194.149.96.0/19 (маска 255.255.224.0 содержит 19 единиц). Это
и есть CIDR-совместимый сетевой адрес. Мы его рассмотрели в рамках
автономных систем (провайдеров), так как именно перед ними наиболее
часто встает задача объединения нескольких последовательных
интервалов IP-адресов в один интервал. Тем не менее, с подобной задачей
может столкнуться и любая другая организация, оперирующая большими
количествами IP-адресов (правда, она, по сути, при этом превращается
в того же провайдера).
При делении сети на подсети число единиц в маске сети увеличивается,
при объединении подсетей, наоборот, уменьшается. Объединенные сети
называются суперсетями. С точки зрения АС и их администрирования,
суперсеть является единым целым.
Когда компания переходит от одного провайдера к другому,
принадлежащему другой АС, возникает проблема. Компания должна запросить
новые IP-адреса и перенумеровать свои сети. Конечно же, символьные
имена компьютеров (и домен электронной почты) останутся теми же
самыми.
Давайте вернемся к одному из наших предыдущих гипотетических
примеров, где компании был выделен интервал IP-адресов 194.149.115.32/24.
Поскольку компания расположена в разных регионах, например, в Бюд-
вейсе и еще где-то, администратор назначил подсети в Бюдвейсе
адрес 194.149.115.32/28. В этой подсети есть компьютер с IP-адресом
194.149.115.33, который пытается связаться с сервером на о-ве Фиджи
(например, загрузить web-страницу).
IP-дейтаграммы будут переданы через Интернет серверу на Фиджи.
Получив дейтаграмму от нашего компьютера, сервер отправляет ему ответ.
IP-дейтаграмма, адресованная компьютеру с IP-адресом 194.149.115.33,
будет передана по каналам связи (например, по подводному кабелю).
Адрес 194.149.115.33 принадлежит интервалу 194.0.0.0/7,
закрепленному за организацией RIPE (Regional IP Registry in Europe and neighboring
territories — региональный IP-реестр в Европе и соседних территориях).
Получатель должен быть где-то между Сенегалом и Камчаткой.
Теоретически, серверу Фиджи все равно, к какой АС принадлежит получатель,
при условии, что весь трафик в Европу (и из нее) проходит по одному
подводному кабелю, а в его таблице маршрутизации будет одна запись
«на Европу»: 194.0.0.0 с маской 254.0.0.0.
268

Глава 6. IP-адреса
Географическое расстояние от Фиджи до Европы приблизительно
такое же, как от Фиджи до США, но дейтаграмма почему-то отправлена
маршрутизатору в США. Значит, все не так просто, как хотелось бы. От
Европы до Америки есть очень много линий, и довольно трудно сказать,
по какой из них пройдет наша дейтаграмма (решение, по какой линии
должна пройти дейтаграмма, изменяется во время самой передачи этой
дейтаграммы).
Маршрутизатор в США выясняет, что адрес 194.149.115.33 принадлежит
интервалу 194.149.92/19 автономной системы AS5490. Таблица
маршрутизации ее маршрутизаторов должна иметь одну запись для каждого
интервала адресов, принадлежащих автономной системе AS5490. В
нашем случае:
194.149.92.0 смаской 255.255.224.0.
Самые важные маршрутизаторы в США, расположенные на границах
автономных систем, имеют по одной записи для каждого интервала IP-
адресов, принадлежащих каждому провайдеру на Земле. Данные
маршрутизаторы содержат завершенные таблицы маршрутизации для всего
Интернета. Такие таблицы маршрутизации требуют большого
количества оперативной памяти — минимум 256 Мб.
Маршрутизаторы с завершенными таблицами маршрутизации нужны
как граничные маршрутизаторы транзитных автономных систем, то есть
АС, через которые передаются дейтаграммы между другими
автономными системами. Предположим, что мы находимся на Западном побережье
США, и нам нужно передать дейтаграмму в Европу. Через транзитные
АС дейтаграмма будет передана на восточное побережье США, а
затем — по подводному кабелю — в Европу.
Эффективный обмен IP-дейтаграмм между автономными системами
зависит не только от технических факторов, то есть от технически
наиболее выгодного маршрута к получателю, но и от правил маршрутизации
между отдельными автономными системами. Сюда же относят и
экономический фактор — возможно, дейтаграмма пойдет по более сложному
маршруту, стоимость передачи по которому будет дешевле, чем по более
простому.
Наша IP-дейтаграмма прибыла из США на граничный маршрутизатор
автономной системы AS5490. Теперь маршрутизатор полностью
анализирует адрес получателя и определяет, что IP-адрес 194.149.115.33
269

TCP/IP и DNS в теории и на практике. Полное руководство
принадлежит интервалу 194.149.115/24, выделенному нашей компании.
В таблицах маршрутизации автономной системы AS5490 будет запись:
194.149.115.0 смаской 255.255.255.0.
Провайдер передает IP-дейтаграмму граничному маршрутизатору
нашей компании, который анализирует адрес 194.149.115.33 и определяет
подсеть получателя. В его таблице маршрутизации будет запись:
194.149.115.32 смаской 255.255.255.224 — это сеть в Бюдвейсе.
IP-дейтаграмма передается маршрутизатору в Бюдвейсе.
Маршрутизатор определяет, что сеть 194.149.115.32/28 подключена непосредственно
к его локальному интерфейсу. С помощью протокола ARP он
определяет 6-байтовый канальный адрес получателя и отправляет ему
дейтаграмму. Вот такой длинный путь проделала наша дейтаграмма от
Фиджи до Бюдвейса (Европа).
А теперь вы только вдумайтесь: все это путешествие занимает всего
около двух секунд (I). Представляете, какова скорость передачи и
производительность маршрутизаторов и каналов связи? Для повышения
производительности маршрутизаторы оборудованы специальными
сопроцессорами, которые обрабатывают таблицы маршрутизации.
Номера автономных систем назначаются региональными
интернет-реестрами {Regional Internet Registries): агентство RIPE — в Европе,
агентство ARIN — в Северной Америке, LACNIC — в Латинской Америке
и APNIC — в Азии и Тихоокеанском регионе. Эти агентства хранят в
своих базах данных информацию о присвоенных интервалах IP-адресов.
На сервере RIPE ftp://ftp.ripe.net есть сценарий prtraceroute,
использующий команду traceroute. По выводу команды traceroute
данный сценарий ищет информацию в базах данных региональных с
помощью команды whois. Рассмотрим маршрут к Фиджи:
./prtraceroute kula.usp.ac.fj
** WARNING ** Destination AS unknown for kula.usp.ac.fj (144.120.8.11)
** WARNING ** Policy information is not possible - setting to "?"
traceroute to kula.usp.ac.fj (144.120.8.11) with AS and policy additions
cbuN002e00.pvt.net 194.149.104.193 [?]
phucbu.pvt.net 194.149.96.13 [?]
951.Hssi5-0.GWl.NYC2.ALTER.NET 157.130.0.117 [?]
143.ATM2-0.XR2.EWR1.ALTER.NET 146.188.177.62 [?]
192.ATM2-0-0.BR1.EWR1.ALTER.NE 146.188.176.53 [ ? ]
1
2
3
4
5
AS5490
AS5490
AS701
AS702
AS702
270

Глава 6. IP-адреса
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
AS701
AS1790
AS1790
AS1790
AS1790
AS1790
AS1239
AS4637
AS3491
AS3491
AS3491
AS4637
???
AS681
???
sl-pen-ll-h3.sprintlink.net
sl-bblO-pen-0-1.sprintlink.
sl-bb22-stk-6-0.sprintlink.
si-bb23-stk-8-0.sprintlink.
net
net
net
sl-bblO-sj-6-0.sprintlink.net
s1-gw2-sj-0-0-0-155M.sprint1in
sl-cais-1.sprintlink.net
hssi9-0-0.hk-T3.hkt.net
f5-l.yck06.hkt.net
a6-0.tmh08.hkt.net
s4-3b.tmh08.hkt.net
202.84.251.6
202.62.120.6
202.62.125.134
kula.usp.ac.fj
137,
144,
144.
144,
144.
144,
144.
202,
205,
205,
205,
202,
202,
202,
144,
.39.44.130
.232.5.5
.232.8.178
.232.4.110
.232.8.193
.232.3.38
.228.111.18
.84.128.253
.252.130.233
.252.130.81
.252.128.158
.84.251.6
.62.120.6
.62.125.134
.120.8.11
[?]
[?1
[?]
[?
[?'}
[?]
[?]
[?]
[?]
[?]
[?]
[?I
[?]
[?]
[?]
AS Path followed: AS5490 AS701 AS702 AS701 AS1790 AS1239 AS4637 AS3491
AS4637 ??? AS681 ???
AS5490 =
AS701 =
AS702 =
AS1790 =
AS1239 =
AS4637 =
AS3491 =
AS681 =
PVTNET
Alternet
UUNET
SprintLink Washington D.C.
SprintLink Backbone
Hong Kong Telecom
CAIS Internet
KAWAIHIKO-1
Первый столбец — это номер перехода (хопа), второй — номер
автономной системы (в десятичном виде, после строки «AS»). Третий столбец
показывает имя интерфейса маршрутизатора, четвертый — его IP-адрес.
В пятом столбце отображаются правила маршрутизации (в квадратных
скобках). Тип маршрутизации может быть I или Е; I — внутренняя
маршрутизация автономной системы, Е — внешняя маршрутизация.
В конце вывода показывается путь дейтаграммы: список автономных
систем, через которые проходит дейтаграмма (as Path followed).
После этого списка выводится название организаций-владельцев
(провайдеров) автономных систем.
Как видите, путь к Фиджи более сложный, чем это можно было
предположить — дейтаграммы «идут» через Гонконг.
271

TCP/IP и DNS в теории и на практике. Полное руководство
Вот еще один пример использования prtraceroute. В Европе лучше
обслуживают базы данных, поэтому знаки вопроса для Европы —
редкость.
./prtraceroute -v is.eunet.cz
traceroute with AS and policy additions [Oct 16 05:06:18 UTC]
from AS5490 info.pvt.net (194.149.104.203)
to AS2819 is.eunet.cz (193.85.1.11)
1 AS5490 cbuN002e00.pvt.net 194.149.104.193 [I] 3 1 1 ms
2 AS5490 phucbu.pvt.net 194.149.96.13 [I] 132 14 17 ms
3 AS5490 194.149.101.226 194.149.101.226 [I] 16 10 20 ms
4 AS2819 acc-gw.eunet.cz 193.85.3.65 [El] 35 16 18 ms
5 AS2819 is.eunet.cz 193.85.1.11 [I] 15 11 13 ms
AS Path followed: AS5490 AS2819
AS5490 = PVTNET
AS2819 = EUnet Czechia AS
Команда prtraceroute — отличный помощник администратору
автономной системы. Если вам нужно узнать подробную информацию о какой-
то АС, можно использовать команду whois, например:
$ whois AS4637
aut-num: AS4637
as-name: REACH
descr: Reach Network Border AS
country: HK
import: from AS3561
action pref=100;
accept ANY
import: from AS3491
action pref=100;
accept ANY
import: from AS1239
action pref=100;
accept ANY
import: from AS7 01
action pref=100;
accept ANY
import: from AS1
action pref=100;
accept ANY
272

export:
export:
export:
export:
export:
admin-c:
tech-c:
notify:
mnt-by:
changed:
source:
role:
address:
address:
address:
country:
phone:
fax-no:
e-mail:
admin-c:
tech-c:
nic-hdl:
remarks:
notify:
mnt-by:
changed:
changed:
changed:
source:
role:
address:
phone:
fax-no:
e-mail:
to AS3491
announce AS4637
to AS3561
announce AS4637
to AS1239
announce AS4637
to AS701
announce AS4637
to AS1
announce AS4637
CC318-AP
PHN02-AP
noc@hkt.net
MAINT-AP-REACH
carmen.m.chow@reach.com 20021003
APNIC
APNIC Hostmaster
Level 1
33 Park Road
Milton QLD 4064
AU
+61 7 3858 3100
+61 7 3858 3199
hostmaster@apnic.net
DNS3-AP
N04-AP
HM20-AP
Administrator for APNIC
dbmon@apnic.net
MAINT-APNIC-AP
hostmaster@apnic.net 19981111
dbmon@apnic.net 19990702
hostmaster@apnic.net 20020211
APNIC
Network Operation Center of Reach Networks HK Ltd
Telecom House, 3 Gloucester Rd.
+852-2883-2255
+852-2824-1440
ipnoc@reach.com
Wanchai, Hong Kong

TCP/IP и DNS в теории и на практике. Полное руководство
admin-c: CC318-AP
tech-c: NH28-AP
nic-hdl: PHN02-AP
notify: carmen.m.chow@reach.com
mnt-by: MAINT-AP-REACH
source: APNIC
changed: carmen.m.chow@reach.com 20021001
person: Carmen Chow
address: Telecom House,
address: 3 Gloucester Rd,
address: Wanchai, Hong Kong.
remarks: ***************************************
remarks: The phone and fax contact which is shown
remarks: in this object is
remarks: Reach Hotline phone and fax no.
remarks: ***************************************
phone: +852-2883-2255
fax-no: +852-2824-1440
country: HK
e-mai1: carmen.m.chow@reach.com
nic-hdl: CC318-AP
mnt-by: MAINT-AP-REACH
source: APNIC
changed: carmen.m.chow@reach.com 20021008
Если вам нужна команда whois, лучше всего использовать whois-окно на
сайте www.apnic.net.

Глава 7
МАРШРУТИЗАЦИЯ
ПРОДВИЖЕНИЕ (FORWARDING)
И ЭКРАНИРОВАНИЕ (SCREENING)
МАРШРУТИЗАЦИЯ
РАБОТА С ТАБЛИЦАМИ
МАРШРУТИЗАЦИИ
ПРОТОКОЛЫ МАРШРУТИЗАЦИИ
НЕЙТРАЛЬНЫЕ ТОЧКИ ОБМЕНА
(NEUTRAL EXCHANGE POINT (NIX))
TCP/IP и DNS в теории и на практике. Полное руководство

IP-маршрутизация и IP-продвижение (IP forwarding) — два очень важных
процесса в Интернете. Суть маршрутизации показана на рис. 7.1. Давайте
его внимательно изучим. Итак, посмотрев на рисунок, сразу понятно, для
чего нужен loopback. Как только интерфейс выясняет, что IP-дейтаграмму
нужно отправить обратно на вход, он перенаправляет ее на программную
петлю — loop-интерфейс, который и выполняет эту операцию.
Также на этом рисунке изображены следующие операции:
маршрутизация, продвижение, эхо-запрос, перенаправление (redirect).
Ядро операционной системы отвечает за автоматическую обработку IP-
дейтаграмм, сюда относится и маршрутизация, и продвижение пакетов.
7.1. Продвижение (forwarding)
и экранирование (screening)
Продвижение пакетов (IP-forwarding) позволяет использовать станции
(то есть обычный компьютер) как маршрутизатор. Не все
операционные системы позволяют использовать продвижение: некоторые вообще
не поддерживают эту функцию, у других она выключена по умолчанию
(после ее активизации все работает, как положено).
Предположим, что компьютер с включенной возможностью
продвижения пакетов получил IP-дейтаграмму, которая ему не адресована. Он
пытается передать ее дальше (продвижение) — точно так же работает
простейший маршрутизатор.
Как уже отмечалось, продвижение пакетов может быть выключено.
Некоторые системы для включения этой функции требуют
перекомпиляции ядра (например, Linux, некоторые UNIX), но обычно перекомпи-

Глава 7. Маршрутизация
ляция требуется для старых версий ядер, поскольку все современные
ядра уже содержат эту функцию. Продвижение пакетов поддерживается
Windows 2000 и большинством UNIX-систем.
Прикладные протоколы
&
TCP/UDP
Действия над таблицами
маршрутизации: routed, gadet
route, netstat И также SNMP
Получение
Передача
Физический
уровень
Рис. 7.7. Маршрутизация
Для того чтобы включить продвижение пакетов в Windows 2000/ХР,
нужно установить значение 1 для ключа реестра IpEnableRouter,
который находится в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Tcpip\Parameters.
277

TCP/IP и DNS в теории и на практике. Полное руководство
Некоторые операционные системы не передают все IP-дейтаграммы
механически, а только некоторые их них. Данная функция называется
экранированием пакетов. Экранирование можно представить как
фильтрацию пакетов: одни пакеты отбрасываются, а другие передаются
дальше (см. рис. 7.2).
Экранирование выполняется, как правило, до продвижения
IP-дейтаграммы: сам процесс продвижения приостанавливается, и принимается
решение, что делать с пакетом: передать его дальше или отбросить.
Решение принимается на основании следующей информации:
1. IP-заголовка: внесен ли IP-адрес в черный список или нет.
2. TCP-заголовка: проверяются номера портов и флаги АСК и SYN.
3. Протокола, вложенного в дейтаграмму.
Рис. 7.2. Фильтрация
Программы, выполняющие экранирование пакетов, называются файрво-
лами (firewalls)— они же бастионы, брандмауэры и межсетевые экраны.
7.2. Маршрутизация
7.2.1. Как это происходит
Маршрутизация IP-дейтаграмм очень напоминает сортировку обычных
писем на почте. Есть сортировочный стол с небольшими отверстиями
для конвертов. Каждое отверстие соответствует определенному городу.
Сортировщик раскладывает письма по этим отверстиям. В результате
письма, адресованные в один и тот же город, оказываются в одном ме-
278

Глава 7. Маршрутизация
шочке. По окончании сортировки каждый мешочек отправляется в
главное почтовое отделение своего города (см. рис. 7.3).
Сортировка писем — процесс простой, но весьма рутинный.
Сортировщик должен просмотреть адрес каждого письма и поместить письмо
в соответствующее отверстие сортировочного стола. Например, если
адресат из Вены, то сортировщик помещает письмо в отверстие с
надписью «Вена». Предположим, что сортировщик обнаружил, что адресат
находится не в Праге, а недалеко от Праги — в ее окрестностях или в
небольшой деревне возле Праги. В этом случае сортировщик все равно
помещает конверт в отверстие с надписью «Прага». Письмо будет
доставлено на центральное почтовое отделение Праги, где и будет произведена
окончательная сортировка.
ZZ7/ZJCD,
Вена София Загреб
'ZZ7СПЕЛ,
Прага
& ооо
£^ЗЗР
>- Прага
Рис. 7.3. Сортировочный стол
Маршрутизатор — этот тот же сортировщик, только он сортирует не
письма, a IP-дейтаграммы. Процесс сортировки дейтаграмм
называется маршрутизацией. Когда маршрутизатор получает 1Р-дейтаграмму,
он должен решить, на какой из интерфейсов ее следует отправить.
Возможно, дейтаграмма попадет сразу в сеть получателя, а может быть, она
будет передана одному из соседних маршрутизаторов (следующий
переход) для дальнейшей маршрутизации.
Попросту говоря, маршрутизатор — это устройство, сортирующее и
отправляющее 1Р-дейтаграммы. IP-дейтаграмма может быть отправлена
279

TCP/IP и DNS в теории и на практике. Полное руководство
на тот же самый интерфейс, из которого она была получена, но данная
ситуация непонятна. В этом случае отправитель будет уведомлен ICMP-
пакетом «redirect» (перенаправление).
На рис. 7.4 маршрутизатор получил IP-дейтаграмму, адресованную
получателю с IP-адресом 10.5.2.1. Маршрутизатор должен решить, на
какой интерфейс ее отправить — Serial 1, Serial2 или Ethernet.
10.5.2.1
v Г—л '
Т Марш-р
Serial 2 \" к *J Serial 1
Ethernet T
l
I
PC
10.1.2.0/24
Получатель:
10.5.2.1
Рис. 7.4. Маршрутизатор должен решить, на какой интерфейс
отправить IP-дейтаграмму
Для принятия решения используется таблица маршрутизации (если
провести аналогию с почтовым отделением, это тот же сортировочный
стол). В таблице 7.1 представлена таблица маршрутизации нашего
маршрутизатора.
Таблица 7.1. Таблица маршрутизации
Сеть
192.168.1.0
10.1.2.0
10.5.1.0
10.5.0.0
0.0.0.0
Маска
255.255.255.0
255.255.255.0
255.255.255.0
255.255.0.0
0.0.0.0
Следующий
переход
192.168.254.5
Локальный интерфейс
10.10.10.2
10.5.5.5
10.10.10.2
Сетевой
интерфейс
Serial 1
Ethernet
Serial 2
Serial 1
Serial 2
Метрика
4
0
3
2
1
Первый столбец таблицы — это IP-адрес сети получателя. Как выбрать
нужный маршрут? Делается это очень просто: больший приоритет
имеет адрес, сетевая маска которого содержит больше единиц. Адрес с
наибольшим приоритетом называется наиболее подходящим адресом.
280

Глава 7. Маршрутизация
Иногда возникает ситуация, когда в таблице маршрутизации есть два
маршрута, ведущие к получателю. Оба маршрута (оба адреса) содержат
одинаковое количество единиц в маске. В этом случае маршрутизатор
выбирает маршрут с самой низкой метрикой (ценой). Давайте
рассмотрим процесс обработки таблицы маршрутизации подробнее.
7.2.2. Обработка таблицы маршрутизации
Учитывая, что записи в таблице маршрутизации сортируются по
убыванию по первому столбцу, таблица маршрутизации обрабатывается
сверху вниз. Обработка таблицы маршрутизации заключается в следующем:
сетевая маска каждой строки побитно умножается на содержащийся
в дейтаграмме IP-адрес получателя.
Результат умножения сравнивается с первым столбцом. Если результат
не совпадает с IP-адресом сети, маршрутизатор начинает обрабатывать
следующую запись. Думаю, не стоит говорить о том, что обработка
аналогично выполняется до тех пор, пока результат все-таки не совпадет
с IP-адресом сети.
Давайте вернемся к нашему примеру (см. рис. 7.4). Маршрутизатор
должен выбрать интерфейс, на который будет отправлена IP-дейтаграмма
с IP-адресом 10.5.2.1. Маршрутизатор начинает обработку таблицы
маршрутизации (таблица 7.2).
Таблица 7.2. 1-я запись
192.168.1.0
255.255.255.0
192.168.254.5
Serial 1
4
Результат побитного умножения целевого адреса 10.5.2.1 на маску
255.255.255.0 равен 255.255.255.0, что не совпадает со значением первого
столбца (192.168.1.0), поэтому маршрутизатор переходит к следующей
записи (таблица 7.3).
Таблица 7.3. 2-я запись
10.1.2.0
255.255.255.0
Local interface
Ethernet
0
Побитно умножив адрес 10.5.2.1 на маску 255.255.255.0, мы получаем
результат 10.5.2.0. Результат умножения не совпадает со значением
первого столбца (10.1.2.0), поэтому нужно обработать следующую запись.
281

TCP/IP и DNS в теории и на практике. Полное руководство
Таблица 7.4. 3-я запись
10.5.1.0
255.255.255.0
10.10.10.2
Serial 2
3
Опять побитно умножаем адрес 10.5.2.1,на маску 255.255.255,0. В
результате получаем значение 10.5.2.0, которое не совпадает со значением
10.5.1.0, поэтому приступаем к обработке следующей записи.
Таблица 7.5. 4-я запись
10.5.0.0
255.255.0.0
10.5.5.5
Serial 1
2
Умножив адрес 10.5.2.1 на маску 255.255.0.0, мы получим результат
10.5.0.0, совпадающий со значением IP-адреса сети получателя — со
значением первого столбца (10.5.0.0). Поэтому IP-дейтаграмма будет
отправлена по интерфейсу Serial 1 и передана маршрутизатору с
IP-адресом 10.5.5.5 (следующий переход). Маршрутизатор 10.5.5.5 будет
найден по протоколу ARP.
Рассмотрим последнюю запись с адресом сети 0.0.0.0 и сетевой маской
0.0.0.0. Это маршрут по умолчанию (default). По данному маршруту
будут отправлены все дейтаграммы, вычислить сеть получателя которых
не удалось.
7.3. Работа с таблицами маршрутизации
В предыдущем пункте мы рассмотрели абстрактную таблицу
маршрутизации, содержащую только основные элементы — IP-адрес сети, маску,
IP-адрес соседнего маршрутизатора, интерфейс и метрику.
На практике таблицы маршрутизации, кроме этих элементов, содержат
еще и различные дополнительные элементы. Какие цменно — зависит от
операционной системы маршрутизатора.
Бывает даже, что в разных таблицах маршрутизации есть одни и те же
элементы, но называются они по-разному, например, «gateway» (шлюз)
и «router» (маршрутизатор) — обозначают следующий переход (IP-
адрес следующего маршрутизатора), но названия этих элементов, как
видите, разные. В этом пункте мы рассмотрим четыре наиболее часто
используемых формата таблицы маршрутизации — NT, Windows 2000,
UNIX и CISCO.
282

Глава 7. Маршрутизация
7.3.1. Таблицы маршрутизации
в разных операционных системах и устройствах
Таблица маршрутизации в Windows NT
Для просмотра содержимого таблицы маршрутизации в Windows NT
можно использовать команду netstat с параметром -г. Данная команда
выводит таблицу маршрутизации (см. таблицу 7.6) в возрастающем
порядке, поэтому она обрабатывается снизу вверх.
Как видите, запись по умолчанию — самая первая. Если бы таблица
обрабатывалась сверху вниз, то все дейтаграммы отправились бы
только на маршрут по умолчанию, а другие записи вообще не
обрабатывались — попробуйте умножить любой адрес на сетевую маску 0.0.0.0
и получите значение 0.0.0.0, что совпадает со значением первого
столбца, следовательно, все дейтаграммы должны быть отправлены по этому
маршруту.
Также обратите внимание на конфигурацию интерфейса обратной
петли — 127.0.0.1. Все пакеты для сети 127.0.0.0 отправляются обратно на
маршрутизатор с адресом 127.0.0.1. Тут все ясно. А теперь рассмотрим
запись 194.149.104.121 ... 127.0.0.1. Почему именно так? Просто, потому
что 194.149.104.121 — это адрес локального сетевого интерфейса.
Таблица 7.6. Таблица маршрутизации
С:\ > netstat -г
Route Table
Active Routes:
Network Address
0.0.0.0
127.0.0.0
194.149.104.64
194.149.104.121
194.149.104.255
224.0.0.0
255.255.255.255
255
255
255
255.
Netmask
0.0.0.0
255.0.0.0
.255.255.192
.255.255.255
.255.255.255
224.0.0.0
255.255.255
Gateway Address
194.149.104.126
127.0.0.1
194.149.104.121
127.0.0.1
194.149.104.121
194.149.104.121
194.149.104.121
Interface
194.149.104.121
127.0.0.1
194.149.104.121
127.0.0.1
194.149.104.121
194.149.104.121
194.149.104.121
Metric
1
1
1
1
1
1
1
Сеть 224.0.0.0 с маской 224.0.0.0 используется для всех групповых рас-
сылок (multicasts).
283

TCP/IP и DNS в теории и на практике. Полное руководство
Таблица маршрутизации в Windows Server 2000/2003
В Windows 2000 Server для просмотра и редактирования таблицы
маршрутизации используется утилита Routing and Remote Access,
позволяющая добавлять и удалять статические записи. Кроме этого, программа
может конфигурировать протоколы маршрутизации в Windows 2000.
Таблица маршрутизации в UNIX/Linux
Таблица маршрутизации выводится в возрастающем порядке, поэтому
она тоже обрабатывается снизу вверх.
UNIX — более старая, чем Windows NT/2000/2003, операционная
система, поэтому формат таблицы маршрутизации был у нее несколько другой.
«Был», потому что в новых версиях UNIX формат таблицы
маршрутизации очень напоминает описанный выше формат NT. Особенностью
старого формата является то, что сетевая маска не выводится. Всегда
подразумевалась стандартная сетевая маска, что приводило к недоразумениям
при использовании других, отличных от стандартной, сетевых масок.
Затем (в «средних» версиях) сетевая маска отображалась как количество
единиц в маске, написанное через слэш после IP-адреса сети. В новых
версиях, как уже отмечалось, формат похож на формат NT, только с
некоторыми специфическими элементами, появившимися еще в самых первых
таблицах маршрутизации. Рассмотрим сначала таблицу 7.7, выводимую
с помощью команды netstat -m, а затем эти дополнительные элементы.
Таблица 7.7. Таблица маршрутизации UNIX
$ netstat
-rn
Routing tables
Destination
Netmasks:
Inet
Inet
Inet
Route Tree
Default
10/8
127.0.0.1
172.17/16
195.47.37.
for
Gateway
255.0.0.0
255.255.0.0
255.255.255.224
Protocol Family 2:
192/27
195.47.37.193
195.47.37.193
127.0.0.1
195.47.37.193
195.47.37.194
Flags
UGS
UGS
UH
UGS
U
Refs
8
0
1
2
17
Use
25686
4916
0
21306
30404
Interface
tuO
tuO
loO
tuO
tuO
284

Глава 7. Маршрутизация
Столбец Refs отображает количество TCP-соединений по этому
маршруту, а столбец Use — количество отправленных по этому маршруту IP-
пакетов (подсчет ведется с инициализации системы).
Самый интересный столбец Flags, он может содержать следующие
значения:
• U (up) — маршрут доступен.
• G (gateway) — флаг «G» указывает, что данный маршрут
ведет к соседнему маршрутизатору (следующий переход).
Если данный флаг не установлен, дейтаграммы сразу
попадут в сеть получателя.
• Н (host) — указывает, что это адрес интерфейса (компьютера),
а не адрес сети, то есть сетевая маска равна 255.255.255.255.
• D — означает, что данная запись была добавлена на
основании ICMP-сообщения «redirect».
• М — означает, что запись была изменена на основании ICMP-
сообщения «redirect».
• S (static) — статический маршрут, добавленный с помощью
команды route.
• R (reject) — данная запись также была создана с помощью
команды route.
Допускается использование нескольких флагов одновременно. При
этом они идут подряд.
Таблица маршрутизации на маршрутизаторах CISCO
Содержимое таблицы маршрутизации (см. таблицу 7.8) могут
просматривать даже непривилегированные пользователи. Для этого
используется команда sho ip route.
Нижняя часть вывода команды содержит отдельные записи таблицы
маршрутизации. Данный список делится на секции, соответствующие
отдельным сетям. Например, заголовок 10.0.0.0/24 is subne 11 ed,
3 subnets сообщает о том, что сеть 10.0.0.0 разбита на 3
подсети. Очень важен первый столбец — он показывает, как запись «попала»
в таблицу маршрутизации:
285

TCP/IP и DNS в теории и на практике. Полное руководство
• С — данная запись была указана при конфигурации интерфейса
маршрутизатора;
• S — сконфигурирована статически;
• другие способы, описанные в верхней части вывода программы
(см. список Codes таблицы 7.8).
Таблица 7.8. Таблица маршрутизации CISCO
Router>sho ip route
Codes: С - connected, S - static, I - IGRP, R - RIP, M - mobile, В - BGP
D - EIGRP, EX - EIGRP external, О - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
El - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, LI - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, о - ODR
Gateway of last resort is 195.47.37.192. to network 0.0.0.0
195.47.37.0/27 is subletted, 1 subnets
С 195.47.37.192 is directly connected, EthernetO
10.0.0.0/24 is subnetted, 3 subnets
S 10.4.6.0 [1/0] via 195.47.37.211
S 10.4.4.0 [1/0] via 195.47.37.210
S 10.4.5.0 [1/0] via 195.47.37.210
S* 0.0.0.0/0 [1/0] via 195.47.37.192
7.3.2. Редактирование таблицы маршрутизации
Редактирование таблицы маршрутизации заключается в добавлении
и удалении ее записей. Записи в таблицу маршрутизации могут быть
добавлены:
• При конфигурировании сетевого интерфейса, когда определяется
адрес и сетевая маска интерфейса. В UNIX для этого используется
команда ifconfig.
• Статически — с помощью команды route.
• Динамически — на основании ICMP-сообщения «redirect» или
протоколами маршрутизации.
286

Глава 7. Маршрутизация
Работа со статическими записями
в таблице маршрутизации
Для добавления статических записей используется команда route.
Windows-версия этой команды применяет следующий синтаксис:
ROUTE [-f ] [command [destination] [MASK netmask] [gateway] [METRIC metric] ]
- f Сначала удаляет все содержимое таблицы
маршрутизации.
-р Если следует за командой ADD, добавляет постоянный
маршрут.
Если следует за командой PRINT, выводит все
постоянные маршруты.
command Задает команду:
PRINT Выводит содержимое таблицы маршрутизации.
ADD Добавляет запись в таблицу.
DELETE Удаляет запись.
CHANGE Модифицирует запись.
destination Указывает целевую сеть.
netmask Определяет сетевую маску.
gateway Указывает следующий переход (соседний
маршрутизатор).
METRIC Указывает метрику.
Пример:
route -р add 10.0.0.32 mask 255.255.255.240 192.168.1.2
В UNIX команда route существенно сложнее. В UNIX нет постоянных
маршрутов: после перезагрузки системы статические записи
автоматически добавляются в таблицу маршрутизации с помощью команды
route, которая вызывается сценарием инициализации системы.
Ясно, что UNIX-версия имеет другой синтаксис и другие команды.
Обычно в UNIX-версии нет команды PRINT — содержимое таблицы
выводится, если команда указана без всяких параметров. Сложность ис-
287

TCP/IP и DNS в теории и на практике. Полное руководство
пользования данной команды заключается в том, что ее параметры
варьируются в зависимости от самого UNIX. Поэтому перед
использованием этой команды желательно ознакомиться с содержимым справочной
системы (команда man route).
Например, некоторые реализации route поддерживают команды flush
(удаление всей таблицы) и monitor (вывод на консоль изменений в
таблице маршрутизации в реальном времени), а некоторые — нет.
Пример:
route add -net 10.0.0.32/28 192.168.1.2
В CISCO-маршрутизаторах статические записи добавляются при
конфигурировании маршрутизатора:
ip route 10.1.1.0 255.255.255.0 192.169.1.1
Данная команда добавляет маршрут к сети 10.1.1.0/24 через
маршрутизатор 192.169.1.1. Маршрут по умолчанию к маршрутизатору 192.168.1.2
можно добавить командой:
ip route 0.0.0.0 0.0.0.0 192.168.1.2
Управление таблицей маршрутизации
по протоколу SNMP
Предположим, что вы — администратор большой сети, в которой далеко
не один маршрутизатор. Изменение таблицы маршрутизации
маршрутизаторов и компьютеров вашей сети — довольно непростая задача, ведь
вам придется зарегистрироваться (пусть даже и удаленно) на каждом
компьютере и отредактировать его таблицу маршрутизации с помощью
команды route.
Согласитесь, довольно непростая задача. В ее решении вам может
помочь протокол SNMP (Simple Network Management Protocol — простой
протокол управления сетью). На каждом активном элементе сети
(компьютере, маршрутизаторе, модеме, хабе и т. д.) должен быть запущен
SNMP-агент.
Ваш компьютер превращается в управляющую станцию — вы будете
управлять всеми SNMP-агентами. Протокол SNMP позволяет
изменять различные сетевые параметры, в том числе, и таблицы
маршрутизации.
288

Глава 7. Маршрутизация
Рис. 7.5. Протокол SNMP
Объединение (aggregation) нескольких записей
Объединение — это процесс слияния нескольких записей в таблице
маршрутизации в одну. Оно полезно при маршрутизации между двумя
автономными системами. Объединение легко представить на примере все
той же обычной почтовой системы. У нас есть все тот же сортировочный
стол с отверстиями и с надписями городов: Москва, Челябинск,
Мурманск и т. д.
Сортировщик, как ни в чем не бывало, сортирует письма по городам,
пока не доходит до письма, адресованного в другую страну, например,
в Киев. Украина с точки зрения АС — это отдельная автономная
система. Поэтому письмо будет помещено в мешочек с надписью Украина —
то есть объединенный мешочек украинских городов. Это имеет смысл,
если поток писем во все города Украины соизмерим со
среднестатистическим потоком писем в отдельный российский город.
Точно такая же ситуация складывается и с записями таблицы
маршрутизации. При объединении нескольких записей в одну,
соответствующие им сети составляют одну суперсеть. Автоматическая агрегация —
это скорее мечта, нежели действительность. На практике объединение
выполняется вручную.
10 Заж. 518
289

TCP/IP и DNS в теории и на практике. Полное руководство
7.4. Протоколы маршрутизации
Протоколы маршрутизации — это протоколы прикладного уровня, но
используемые не пользователями, а маршрутизаторами для заполнения
их таблиц в процессе коммуникации.
Существуют две независимые категории протоколов маршрутизации:
• Link State Protocols (LSP) и Routing Vector Protocols (RVP).
• ЮР и EGR
Начнем с первой категории.
LSP и RVP
Протокол RVP (Routing Vector Protocols) основан на обмене содержимым
таблиц маршрутизации соседних маршрутизаторов (векторы — это одна
запись таблицы маршрутизации).
Работает данный протокол так: маршрутизатор получает векторы из
таблицы маршрутизации своего соседа и, если они отсутствуют в его
таблице, заносит их в нее. Как видите, все очень просто. Единственный
недостаток данного протокола — его нельзя использовать в больших
сетях, потому что векторный обмен требует некоторого времени, и может
сложиться такая ситуация, что вектор только-только занесен в таблицу
маршрутизации, а сеть, описанная в векторе, уже недоступна. Под
большими сетями подразумеваются сети, состоящие более чем из 10-ти
локальных сетей.
Примерами протокола RVP могут послужить протоколы RIP и RIP2.
В UNIX протокол RIP реализуется демоном routed. Обмен векторами
маршрутизации по протоколу RIP осуществляется с помощью
широковещательных сообщений (broadcasts). Основной недостаток этого
протокола — при передаче записей таблицы маршрутизации не передаются
сетевые маски. Именно поэтому протокол RIP может использоваться
только в сетях со стандартными сетевыми масками. Этот недостаток
исправлен во второй версии протокола — RIP2. Данный протокол
использует «широковещание» с IP-адресом 224.0.0.9. Недостаток этого
протокола — он редко используется и поддерживается не всеми
маршрутизаторами.
290

Глава 7. Маршрутизация
Рис. 7.6. Конфигурация протоколов маршрутизации в ОС Windows 2000/2003 Server
Принцип работы LSP-протоколов абсолютно другой. Каждый
маршрутизатор «вычисляет» своих соседей и через определенные
интервалы времени опрашивает их, чтобы проверить, доступны ли они. Затем
маршрутизатор передает широковещательные сообщения,
информирующие его о соседях. Таким образом, у каждого маршрутизатора будет
информация о соседях всех своих соседей — так строится список всех
маршрутов сети.
Данный список обрабатывается алгоритмом поиска кратчайшего пути,
по которому и будет передана IP-дейтаграмма. Это означает, что записи
таблицы маршрутизации «вычисляются» с помощью алгоритма поиска
кратчайшего пути на основании данных, полученных от других
маршрутизаторов.
Широковещательные сообщения маршрутизаторов могут отрицательно
сказаться на производительности: представьте, что каждый
маршрутизатор через определенное время будет передавать информацию о своих
соседях, а его соседи, в свою очередь, информацию о своих соседях и т. д.
Поэтому сеть делится на области, и вышесказанный алгоритм
выполняется только в пределах области. Затем граничные маршрутизаторы
передают информацию о своей области граничным маршрутизаторам
соседних областей.
291

TCP/IP и DNS в теории и на практике. Полное руководство
Протоколы семейства LSP более надежны, чем RVP-протоколы, и их
можно применять даже в больших сетях. Основной недостаток — это
сложность их внедрения, ведь если в случае с RVP-протоколами
достаточно было активизировать RIP-протокол на маршрутизаторе, то в
случае с LSP нужно делить сеть на области, а это непростая задача, решать
которую должен опытный эксперт. Если протокол LSP
конфигурируется неопытным специалистом, то может случиться, что некоторые
маршруты будут недоступны, пока другие маршруты перегружены, чего не
должно произойти при правильной настройке.
Примерами LSP-протоколов могут послужить протоколы OSPF (Open
Shortest Path First) и IS-IS (Intermediate System to Intermediate System).
Протокол OSPF подходит для маршрутизации только IP-трафика,
а протокол IS-IS поддерживает маршрутизацию нескольких
протоколов (например, IP и DECnet). Конфигурировать IS-IS должен только
эксперт.
IPG (Interior Gateway Protocol)
и EGP (Exterior Gateway Protocol)
IGP-протоколы (протоколы внутренних шлюзов) используются в
пределах автономной системы. Все вышеупомянутые протоколы — RIP,
RIP2, OSPF и IS-IS являются также и IGP-протоколами.
Как правило, интернет-провайдеры нуждаются в обмене
маршрутизирующей информацией. Для обмена этой информацией между
автономными системами интернет-провайдеры используют EGP-протоколы
(протоколы внешних шлюзов). В настоящее время часто используется
протокол BRP {Border Gateway Protocol) четвертой версии.
Примечание.
Пояснить назначение протокола EGP (BRP) можно и не применительно
к автономным системам. Протокол EGP (BRP) используется для
обмена информацией между не-базовыми соседними маршрутизаторами
(внешними шлюзами). He-базовые маршрутизаторы содержат полную
маршрутную информацию для своих непосредственных соседей в сети
и компьютеров, подключенных к ним, не не обладают сведениями о
других зонах Интернета.
292

Глава 7. Маршрутизация
Отметка протокола маршрутизации в таблице маршрутизации.
Перераспределение
Посмотрим на рис. 7.7. Маршрутизатор обменивается
маршрутизирующей информацией протоколов BGP, OSPF и RIP. В его таблице
маршрутизации есть несколько статических записей. Протоколы
маршрутизации — разные. Как узнать, каким протоколом была создана та ли иная
запись, полученная маршрутизатором? Ведь информация, полученная
от одного протокола, должна быть передана другим протоколам, то есть
перераспределена.
Для этого каждая запись таблицы маршрутизации дополняется
информацией относительно протокола, с помощью которого она была создана.
Рис. 7.7. Перераспределение
7.5. Нейтральные точки обмена
(Neutral Exchange Point (NIX))
Если мы хотим стать новым интернет-провайдером за пределами США,
нам нужно решить две основные коммуникационные проблемы.
Первая проблема — нужно установить соединение с Америкой. То есть
мы должны предоставить нашим клиентам доступ к главным
информационным источникам Интернета. Если мы находимся в географически
отдаленной стране, мы должны быть готовы к высокой стоимости
трансатлантических линий связи. Представляете, сколько будет стоить
проложить такой канал?
293

TCP/IP и DNS в теории и на практике. Полное руководство
Поэтому для удешевления общей стоимости мы будем вынуждены
пользоваться услугами одного из интернациональных интернет-провайдеров.
У каждого такого провайдера уже есть собственные трансатлантические
каналы, которые мы можем использовать. Для начала это единственное
приемлемое решение.
С точки зрения маршрутизации, наш партнер (интернациональный
интернет-провайдер) выполняет транзит нашего трафика в другие
автономные системы, благодаря чему мы сможем передавать данные по
всему миру
Теперь у нас есть интернациональное соединение — мы соединены со
всем миром. Но, с другой стороны, мы находимся в определенной
стране и нам нужно обеспечить возможность нашим клиентам обмениваться
информацией в пределах нашей страны. Ведь огромная часть трафика
любого провайдера так и не выходит за пределы страны. Другими
словами: наши клиенты должны передавать данные клиентам наших
конкурентов.
Если у нас есть только интернациональное соединение (то есть с США),
данные наших клиентов, отправляемые клиентам наших конкурентов,
будут передаваться через США, даже если отправитель и получатель
находятся в соседних квартирах. С экономической точки зрения, это
неразумно.
Поэтому мы должны решить вторую проблему коммуникации —
установить «связь» с нашими соседями-конкурентами, то есть решить
проблему обмена IP-дейтаграммами между нашей автономной системой
и автономными системами наших конкурентов. Но отношения между
соседями-конкурентами всегда «натянуты».
Чтобы избежать лишнего общения с конкурентами и при этом
установить связь со всеми национальными интернет-провайдерами,
используются нейтральные точки обмена (Neutral Exchange Point, NIX). Через
них происходит обмен IP-дейтаграммами всех провайдеров,
подключенных к NIX. С технической точки зрения, NIX — это сеть, объединяющая
маршрутизаторы провайдеров.

Глава 8
ПРОТОКОЛ IP, ВЕРСИЯ 6
ОСОБЕННОСТИ ПРОТОКОЛА IPV6
ИСПОЛЬЗОВАНИЕ ДОПОЛНИТЕЛЬНЫХ
ЗАГОЛОВКОВ В IP-ДЕЙТАГРАММАХ
ПРОТОКОЛ ICMPV6
IPV6-АДРЕСА
TCP/IP и DNS в теории и на практике. Полное руководство

8.1. Особенности протокола IPv6
Что нового появилось в протоколе IPv6
Бывшее название протокола IP версии 6 (IPv6) — IP the Next Generation
(IPng) — протокол IP «следующего поколения». Его предшественник,
протокол IP версии 4 (IPv4) определен в RFC-760 в январе 1980 года.
Позже, в сентябре 1981 года, спецификация RFC-760 была заменена
спецификацией RFC-791. Спецификация RFC-1883, описывающая
IPv6, появилась в декабре 1995 года. Сегодня для протокола IPv6
используется спецификация RFC-2460.
Основными предпосылками для разработки новой версии протокола IP
стали:
• Существенное развитие Интернета и надвигающееся истощение
адресного пространства протокола IPv4.
• Потребность в более простой конфигурации.
• Потребность в защите на уровне IP.
• Потребность в лучшем обслуживании передачи данных в реальном
времени — в службе качества обслуживания (QpS, quality of service).
Протокол IPv6 не только увеличил размер IP-адреса с 4-х до 16-ти
байтов, но и изменил формат IP-дейтаграммы. Редко используемые поля
вроде «контрольная сумма заголовка» («header checksum») теперь
необязательны.
Дейтаграмма протокола IPv6 состоит из 40-байтового основного
заголовка, после которого следуют различные расширения
(дополнительные элементы). 40-байтовый заголовок не должен казаться очень
большим — ведь теперь IP-адреса отправителя и получателя занимают
32 байтов (по 16 каждый).

Глава 8. Протокол IP, версия 6
Заголовок IPv6
На рис. 8.1 изображена структура основного (базового) заголовка.
О 8 16 24
Версия IP
4 бита = 6
—
—
Тип
графика
Длина полезных данных
Метка потока
След. заголовок
IP-адрес отправителя
128 бит (16 байт)
IP-адрес получателя
128 бит (16 байт)
Лимит перехода
—
—
—
Рис. 8.1. Структура базового заголовка дейтаграммы протокола IPv6
Рассмотрим поля обновленной дейтаграммы.
Поле Версия IP (IP Version) содержит значение 6, а не 4, как для
протокола IPv4.
Длина поля Тип трафика (Traffic Class) составляет 4 бита, поэтому оно
может принимать значения от 0 до 15. По значению этого поля
определяется тип передаваемых данных. В зависимости от типа трафика
маршрутизатор решает, что с ним делать в случае перегрузки сети — один
тип трафика должен быть передан, а другой можно отбросить. Чем выше
значение этого поля, тем выше приоритет дейтаграммы. Быстрее будут
отброшены дейтаграммы с меньшим значением поля, то есть с меньшим
приоритетом.
Интервал значения поля Тип трафика (Traffic Class) делится на две
части:
297

TCP/IP и DNS в теории и на практике. Полное руководство
• 0-7 — обычный трафик:
• 0 — данные неопределенного типа;
• 1 — фоновый трафик;
• 2 — необслуживаемая пересылка данных;
• 4 — передаваемые пользователем большие объемы данных
(например, передача файлов по FTP);
• 6 — интерактивный трафик (например, telnet, Х-Window);
• 7 — пересылка управляющих данных (протоколы
маршрутизации, SNMP).
• 8-15 — используется для передачи в реальном времени (например,
для передачи аудио- и видеоинформации). Чуть выше было
отмечено, что дейтаграммы с меньшим приоритетом будут отброшены
перед дейтаграммами с более высоким приоритетом. Это
действительно только для интервала 0-7, интервал 8-15 обрабатывается
отдельно.
Поле Метка Потока (Flow Label) впервые представлено в IPv6. Вместе
с Адресом отправителя (source address) данное поле используется для
идентификации отдельных потоков данных в Интернете. До недавних
пор (во времена «старого доброго» IPv4) маршрутизация основывалась
только на адресе получателя.
Недостаток интернет-маршрутизации заключается в том, что
дейтаграммы передаются отдельно, то есть обрабатывается не поток
дейтаграмм между двумя приложениями, а каждая дейтаграмма этого
потока — каждый маршрутизатор, встретившийся на пути от отправителя
к получателю, обрабатывает каждую дейтаграмму отдельно, а не как
часть потока.
Представим, что нам нужно передать файл размером в несколько
мегабайтов. Данное мероприятие вызовет довольно большой поток
дейтаграмм — их количество будет измеряться в тысячах (в зависимости от
канала передачи данных). Каждый маршрутизатор будет обрабатывать
каждую дейтаграмму отдельно.
Маршрутизация — это задача, которую должен решить маршрутизатор.
Ее результат — отправление в сеть получателя (или перенаправление на
другой маршрутизатор) адресованной ему дейтаграммы. Выходит, что
298

Глава 8. Протокол IP, версия 6
каждый маршрутизатор будет пару тысяч раз решать одну и ту же
задачу и получать один и тот же результат. Данное решение нельзя назвать
оптимальным.
Оптимальным же решением будет обработка потока дейтаграмм, а не
каждой дейтаграммы в отдельности. Для этого дейтаграммы одного
потока маркируются. Маркировка дейтаграмм позволяет существенно
увеличить производительность и сэкономить память маршрутизатора:
ведь ему не нужно решать задачу маршрутизации снова — можно
повторить одни и те же действия для всех дейтаграмм потока. При такой
постановке вопроса задача маршрутизации фактически решается один
раз — для первой дейтаграммы потока. Дейтаграммы одного потока
автоматически пересылаются на нужный интерфейс.
Для идентификации i ютока используется адрес отправителя и поле Метка
noTOKa(Flow Label). Во время маршрутизации остальные дейтаграммы
потока (кроме первой) хранятся в кэш-памяти маршрутизатора. А теперь
представим следующую ситуацию: что если пользователь перезагрузит
компьютер (или произойдет кратковременное отключение питания, что
равносильно), и операционная система сгенерирует ту же самую метку,
но уже для другого потока данных? Попробуй потом разбери, что здесь
к чему! Чтобы не случилось непоправимого, дейтаграммы хранятся
в кэше маршрутизатора не более 6-ти секунд — за 6 секунд пользователь
никак не успеет перезагрузить компьютер.
Поле Длина полезных данных (Payload length) содержит длину IP-
дейтаграммы без базового заголовка. Поскольку данное поле состоит
из двух байтов, максимальная длина полезных данных дейтаграммы
равна 65.535 байтам. В некоторых случаях этого явно недостаточно.
Однако с помощью поля Следующий заголовок (next header) можно
передавать огромные дейтаграммы. Поле Следующий заголовок (Next
header) определяет тип следующего заголовка, им может быть один из
расширенных заголовков IPv6, TCP-заголовок, UDP и др. (см.
таблицу 8.1). Длина поля — 8 битов.
В разделе 8.2 мы детально остановимся на этом поле, а пока рассмотрим
таблицу 8.1, раскрывающую некоторые возможности, предоставляемые
этим полем.
В приводимой таблице жирным шрифтом выделены элементы,
относящиеся к IP-протоколу. Все остальные принадлежат протоколам
высших уровней.
299

TCP/IP и DNS в теории и на практике. Полное руководство
Таблица 8.1. Некоторые значения поля Следующий 3aronoeoK(Next header)
0
4
6
17
43
44
45
46
50
51
58
59
60
Заголовок перехода (Hop-by-Hop Header)
IP-протокол (IP в IP — инкапсуляция IPv4)
TCP-протокол
UDP-протокол
Заголовок маршрутизации
Заголовок фрагмента
IRP-протокол
RRP-протокол
ESP (Encapsulating Security Payload)
Заголовок аутентификации
ICMPve-протокол
Нет следующего заголовка
Опции получателя
Поле Лимит перехода (Hop Limit) напоминает поле TTL (Time To Life)
в IPv4. Значение этого поля уменьшается на 1 с каждым
маршрутизатором, встретившимся на пути дейтаграммы. Данное поле используется
для двух целей:
• Для удаления потерявшихся дейтаграмм. Когда значение поля
станет равным 0, дейтаграмма будет отброшена.
• Для вычисления кратчайшего пути (подобно команде traceroute).
8.2. Использование дополнительных заголовков
в IP-дейтаграммах
После базового заголовка могут следовать дополнительные заголовки.
В поле Следующий заголовок (Next header) указывается тип
следующего заголовка, а именно, какой заголовок будет следовать за базовым.
По сути, это как бы указатель на следующий заголовок, в котором тоже
может быть поле Следующий заголовок. Таким образом, заголовки
формируют цепочки (см. рис. 8.2).
Цепочки содержат только те заголовки, которые необходимы, в отличие
от протокола IPv4, в котором в заголовок часто включается
неиспользуемая информация. С помощью этого заголовка можно уменьшить размер
дейтаграммы, включив в ее состав только необходимую информацию.
300

Глава 8. Протокол IP, версия 6
ч
ч
ч
ч
0
Версия IP
4 бита = 6
Тип
графика
8
16
24
Метка потока
Длина полезных данных
След. заголовок=0
Лимит перехода
IP-адрес отправителя
128 бит (16 байт)
IP-адрес получателя
128 бит (16 байт)
След. заголовок ?=43
Щ4Щу^^
ttlieiieieiJBBi;1
л-::--:;-Ж
;; Опед^&гоцоуок ^44£
ЩЩ^^офШ-Щ
■:?Щ^Щ;|:1:^^
ЬШШШШЩЩ:Ш
След. загблрвок * 51
Зарезё|ййррван6 g
,1:Ш:;:2|:1^
ШШ-S'
Шк
Л;'-':-: шШ^ЩШ
След; заголовок «=^6 ^
■Лу-'^та:^]^^й^
■'igJ^ix
ЩЩ^^Ш$^^ШШ0^^0->^^: :ЬУ '■■•■ :
фнт?^^
Рис. 8.2. Структура IPv6-дейтаграммы
(стрелками показан порядок обработки заголовков)
301

TCP/IP и DNS в теории и на практике. Полное руководство
Поле Следующий заголовок сопровождается полем Длина заголовка
(header length). В этом поле указан сдвиг, необходимый для достижения
следующего заголовка, тип которого указан в поле Следующий
заголовок. Базовый заголовок не содержит какого-либо заголовка, поскольку
он главный заголовок дейтаграммы, его длина всегда равна 40 байтам.
Длина заголовка фрагмента (fragment headers) также всегда
постоянна, она составляет 8 байтов.
Опции перехода (Hop-by-Hop Options)
Следующий заголовок содержит опции получателя (destination options),
опции перехода (Hop-by-Hop Options) и обрабатывается не конечным
узлом, а промежуточными узлами, то есть маршрутизаторами. Каждый
маршрутизатор должен просмотреть эти опции.
Опция состоит из поля Тип (type) длиной 1 байт, поля Длина (length)
тоже длиной 1 байт и самого поля Опция (option), длина которого
задается полем Длина (см. рис. 8.3).
Тип
Длина
Опция
След* за'гЬЙойок:,
Длина заголовка
I
Тип
1-я опция
Тип
Длина
2-яо
пция
\
Длина
Рис. 8.3. Структура одной опции из заголовка
Рассмотрим поле Тип — оно состоит из восьми битов:
aabxxxxx
Биты а а сообщают маршрутизатору, что нужно сделать с
дейтаграммой, если он не знает текущую опцию:
302

Глава 8. Протокол IP, версия 6
00 — пропустить эту опцию и продолжить обработку заголовка;
01 — отбросить дейтаграмму и не предпринимать никаких действий;
10 — отбросить дейтаграмму и проинформировать об этом
отправителя по протоколу ICMP;
• 11 — отбросить дейтаграмму и, если она не является групповой
дейтаграммой (multicast), проинформировать об этом отправителя по
протоколу ICMP.
Бит Ь определяет, может ли маршрутизатор изменить опцию:
• 0 — маршрутизатору разрешается изменить опцию;
• 1 — опцию нельзя изменить.
В таблице 8.2 представлены некоторые опции.
Таблица 8.2. Некоторые опции, предназначенные для маршрутизаторов
Тип (в
десятичной системе)
0
1
194
Тип (в двоичной
системе)
0
1
11000010
Метка
Содержит 1 байт
Содержит п байтов
Экстенсивная дейтаграмма
Длина
1
2+п
2+4
Значение
поля Длина
N/A
N
4
Опции дополнения (padding) используются для простого
выравнивания длины заголовка, которая должна быть кратной 4. «Слонограммы»
протокола IPv6 (IPv6 Jumbograms) используют выравнивание. Именно
поэтому данная опция должна закончиться на 4-байтовой границе (см.
рис. 8.4). «Слонограммы» описаны в RFC-2675.
Если используется «Слонограмма», поле Длина дейтаграммы в базовом
заголовке устанавливается в 0, а вместо него задействуется
одноименное поле в опции Jumbogram.
,0
8
16
Тип =194
Длина «слонограммы»
24
Длина = 4
Рис. 8.4. IPv6-«слонограмма»

TCP/IP и DNS в теории и на практике. Полное руководство
Заголовок маршрутизации
Заголовки маршрутизации присоединяются к IP-дейтаграммам в тех
случаях, когда пользователь сам непосредственно хочет управлять
маршрутизацией дейтаграммы, а не полагаться на работу
маршрутизаторов. При этом в нижней части заголовка указываются IP-адреса
маршрутизаторов, через которые отправитель хочет передать дейтаграмму
(см. рис. 8.5).
Сл. заголовок
Резерв
—
к-
к-
к-
i—
Длина заголовка
Тип = 0
Маска
1. IP-адрес
2. IP-адрес
п. IP-адрес
i
—
—i
—
—
—
Рис. 8.5. Опция явной маршрутизации
Поле Маска строгого источника маршрутизации (strict source routing
mask) — 24-битовое. Каждый бит соответствует одному переходу и
указывает, должен ли следующий маршрутизатор быть соседним для
предыдущего (строгая маршрутизация). Например, если бит установлен
в 1, то маршрутизатор использует строгую маршрутизацию к
следующему переходу.
Поле i указывает, сколько дополнительных маршрутизаторов нужно для
маршрутизации дейтаграммы. Каждый маршрутизатор, перечисленный
в списке, уменьшает значение этого поля на 1.
304

Глава 8. Протокол IP, версия 6
Рис. 8.6. Ротация IP-адресов при явной маршрутизации
305

TCP/IP и DNS в теории и на практике. Полное руководство
Проблема заключается в том, что, если дейтаграмма должна быть
передана через определенный маршрутизатор, адрес получателя также должен
содержать IP-адрес этого определенного маршрутизатора (ведь в
данный момент дейтаграмма адресуется именно этому маршрутизатору).
Поэтому поле Адрес получателя всегда содержит IP-адрес следующего
маршрутизатора, который должен передать дейтаграмму дальше.
Настоящий адрес получателя сохранен в информационном заголовке
маршрутизации среди других перечисленных маршрутизаторов. На рис. 8.6
приведен пример ротации IP-адресов при явной маршрутизации.
Фрагментация IPv6-дейтаграмм. Заголовки фрагментации
Заголовки фрагментации присоединяются к IP-дейтаграммам при
разбивании тех на части (фрагменты).
Фрагментация IPv6-дейтаграмм разрешена только операционной
системе отправителя. Маршрутизаторы не могут фрагментировать 1Ру6-дей-
таграммы, как это они делали с 1Ру4-дейтаграммами.
Следующий заголовок
Резерв
Смещение фрагмента
Идентификация фрагмента
М
Рис. 8.7. Заголовок фрагмента
Поле Смещение фрагмента (Fragment Offset) используется для сборки
фрагментов дейтаграммы в единое целое. Используя это поле,
получатель может определить порядок следования фрагментов дейтаграммы.
Поле Смещение фрагмента содержит смещение не в байтах, а в
множителях 8-и байтов (8-байтовые блоки).
Флаг М (больше фрагментов, more fragment) используется для
обозначения последнего фрагмента. Если флаг М установлен в 1, то это не
последний фрагмент, если 0 — то это последний фрагмент.
В поле Идентификатор (Identificator) для каждого фрагментируемого
пакета указывается уникальный идентификатор IP-дейтаграммы, по
которому впоследствии, на стороне получателя будут
идентифицироваться части одной фрагментированной дейтаграммы.
306

Глава 8. Протокол IP, версия 6
Заголовок аутентификации (протокол АН)
Заголовок аутентификации {authentication header) гарантирует, что в
содержимое дейтаграммы не были внесены изменения, а сама дейтаграмма
была отправлена с узла, указанного в IP-заголовке.
Следующий заголовок
Длина
Индекс параметров безопасности
Аугентификационные данные
Резерв
Рис. 8.8. Заголовок аутентификации
Заголовок аутентификации использует алгоритм MD-5 (RFC-1321)
для вычисления хэша. Аутентификационные данные хешируются. Хеш
вычисляется на основании IP-дейтаграммы и общедоступного секрета,
хранящегося в специальной таблице. Секрет — это 128-битовая строка
(если строка меньше, то она дополняется двоичными нулями).
Даная строка должна быть известна получателю и отправителю.
Каждый из них не может иметь более одного секрета. Параметры
безопасности хранятся в поле SPI (security parameters index) — это индекс
параметров безопасности — индекс таблицы, в которой хранятся секреты.
Заголовок безопасности (Протокол ESP)
Заголовок безопасности используется для обеспечения целостности
данных. Этот заголовок обеспечивает шифрование данных. Он должен
быть последним заголовком в IP-дейтаграмме, все последующие данные
будут зашифрованы.
Первые четыре байта заголовка похожи на заголовок аутентификации.
Заголовок содержит SPI (индекс параметров безопасности) — индекс
таблицы безопасности, в которой находится вся информация о
шифровании: тип шифрования, режим шифрования, ключи и т. д. Рис. 8.9
является примером зашифрованных данных с использованием алгоритма
DES в СВС-режиме
307

TCP/IP и DNS в теории и на практике. Полное руководство
Индекс параметров безопасности
^Щ1Ж:Щ'ЩЙ
;. ;.v?j^); «:^:0й;:: ?'' Lw-
v Полезные данные
Дополнение
Длина Дополнения
Тип Дополнения ;;
Рис. 8.9. Заголовок безопасности
Имеются два способа использования заголовка защиты:
1. Если отправитель зашифровал данные, то расшифровку будет
выполнять получатель.
2. В процессе шифрования/дешифрования не участвуют ни
отправитель, ни получатель. Шифрование и дешифрование дейтаграмм
выполняют маршрутизаторы, через которые эти дейтаграммы
проходят. Данные маршрутизаторы называются шлюзами безопасности
(см. рис. 8.10).
Отправитель
—
Intr
шлюз
безопасности
( Марш-р V-""~4
anet I
дейтаграмма
Internet k-
'^Йтаграмма:.
шлюз
безопасности
^-*/ Марш-р )
| Intra
Отправитель
net
дейтаграмма
г^
Рис. 8.10. Шлюзы безопасности
8.3. Протокол ICMPv6
Протокол ICMP является сервисным протоколом для протокола IPv4
и используется для диагностики ошибок и оповещения о них. Протокол
IPv6 также использует протокол ICMP, только IPv6-вepcия протокола
ICMP описана в RFC-2463.
308

Глава 8. Протокол IP, версия 6
Протокол ICMPv6 более функционален, чем его предыдущая версия.
Например, ICMPv6 сам преобразует IP-адреса в канальные адреса и
обратно, а в предыдущей версии использовались посторонние
протоколы - ARP и RARP.
Рассмотрим структуру ЮМРуб-пакета (см. рис. 8.11).
О 8 16 24
г
\
Рис. 8.11. Структура пакета протокола ICMPv6
Поле Тип ICMP (ICMP type) содержит тип ICMP-сообщения, а поле
Код ICMP (ICMP code) - его код.
Стандарты RFC-2461 и RFC-2463 определяют типы и коды ICMPv6-
сообщений, представленные в таблице 8.3.
309

TCP/IP и DNS в теории и на практике. Полное руководство
Таблица 8.3. Типы и коды ICMPv6-сообщений
Тип
1
2
3
4
128
129
133
134
135
136
137
Код
0
1
3
4
0
0
1
0
1
2
0
0
0
0
0
0
0
Описание
Получатель недоступен
Нет маршрута к получателю
Связь с получателем запрещена администратором
Адрес недоступен
Порт недоступен
Пакет слишком большой
Время вышло
При передаче был превышен предел переходов
Вышло время сборки фрагмента
Проблема с параметром
Ошибочный (некорректный) заголовок
Следующий заголовок не опознан
Не опознана 1Ру6-опция
Эхо-запрос
Эхо-ответ
Поиск маршрутизатора (Router solicitation)
Я — маршрутизатор (Router advertisement)
Поиск соседа (Neighbor solicitation)
Я — сосед (Neighbor advertisement)
Перенаправление
Все ЮМРуб-сообщения делятся на два класса:
• с номерами 0-127 — сообщения об ошибках;
• с номерами 128-255 — информационные сообщения.
Функции ЮМРуб-сообщений с номерами 0-129 (см. таблицу 8.3)
подобны аналогичным функциям протокола ICMP, поэтому мы не будем
их рассматривать.
Отображение (mapping) IP-адреса в канальный адрес
На рис. 8.12 станция А с адресом FE80::220:AFFF:FE42:4636 хочет
отправить IP-дейтаграмму станции В. Ясно, что IP-дейтаграмма должна
быть помещена в кадр канального уровня. Станция А знает IP-адрес
станции В (FE80::2A0:24FF:FE47:1EC), но кроме него ей нужен
канальный адрес станции В.
Чтобы узнать ее канальный адрес, станция А отправляет
информационный запрос «поиск соседа (neighbor solicitation)».
В новой версии протокола ICMP есть два типа сообщений,
позволяющие определить канальный адрес соседней станции:
310

Глава 8. Протокол IP, версия 6
FE80:2A0:24FRFE47:1 EC
Multicast: FF02::1:FF47:1EC
FE80::220:AFFRFE42:4636
Рис. 8.12..Станция А хочет отправить IP-дейтаграмму станции В
Запрос о канальном адресе (поиск соседа — Neighbor Solicitation) —
станция А запрашивает информацию о станции В с помощью муль-
тикастинга. Затем станция В отправляет ей свой канальный адрес.
Оповещение о канальном адресе (объявление соседа — Neighbor
Advertisement) — станция В отправляет свой адрес станции А.
15
Длина полезных данных = 48
След. = 58 Переходы *= 255
IP отправителя: 4800::1234:2222:1234
IP получателя: FF02::t:FF47:EC
Тип = 135
Код = 0
Контрольная сумма
Зарезервировано = О
Ищем канальный адрес, соответствующий IP-адресу:
FE80::2A0:24FRFE47:1EC
Опция = 1
Длина опции
Канальный адрес отправителя (т. е. станции А)
00-20-AF-42-46-36
Рис. 8.13. Запрос о канальном адресе
311

TCP/IP и DNS в теории и на практике. Полное руководство
Максимальное число переходов для сообщения «neighbor solicitation»
составляет 255. Если запрос проходит через маршрутизаторы (то есть
в другую сеть), это значение уменьшается на 1. Если запрос отправлен
маршрутизатором (то есть из другой сети), значение будет ниже 255.
Тело ЮМРуб-сообщения содержит IP-адрес требуемой станции
(станции В). Опции ЮМРуб-сообщений всегда состоят из трех полей:
• 1 -байтовое поле, содержащее идентификацию опции (например, при
запросе канального адреса: 1 — это запрос, 2 — это ответ);
• 1 -байтовое поле длины, содержащее длину опции;
• сама опция.
Рассмотрим захваченное программой MS Network Monitor ICMPv6-co-
общение, запрашивающее канальный адрес станции (см. листинг 8.1).
Ответ на него представлен на рис. 8.14.
ЛИСТИНГ 8.1 . ЮМРуб-СООБЩЕНИЕ, ЗАПРАШИВАЮЩЕЕ КАНАЛЬНЫЙ АДРЕС СТАНЦИИ
+ ETHERNET: EType = IPv6
IP6: Proto = ICMP6; Len = 32
IP6: Version = 6 (Охб)
IP6: Traffic Class = 0 (0x0)
IP6: Flow Label - 0 (0x0)
IP6: Payload Length = 32 (0x20)
IP6: Next Header = 58 (ICMP6)
IP6: Hop Limit = 255 (OxFF)
IPS: Source Address = f e80 :: 220 : afff": fe42 : 4636
IP6: Destination Address = ff02::1:ff47:lee
IP6: Payload: Number of data bytes remaining = 32 (0x0020)
ICMP6: Neighbor Solicitation; Target = fe80::2a0:24ff:fe47:lee
ICMP6
ICMP6
I CMP 6
ICMP6
ICMP6
+ ICMP6
Type = 135 (Neighbor Solicitation)
Code = 0 (0x0)
Checksum = 0x6665
Reserved
Target Address = fe80::2a0:24ff:fe47:lee
Source Link-Layer Address = 00 20 AF 42 46 36
Давайте рассмотрим это сообщение. Значение поля Лимит перехода
(hop limit) базового заголовка IP-дейтаграммы равно 1, что
предотвращает ответы из других сетей. Кроме того, указан не групповой 1Р-ад-
312

Глава 8. Протокол IP, версия 6
Длина полёзй^^
IP отправителя: FE8Q::2A0:24FF:FE47^EC
IP получателя: FF80::220:AFFF:FE42:4636
Тип =136
Код = 0
Контрольная сумма
R I S I О
Зарезервировано = О
IPv6- адрес, соответствующий искомому канальному адресу:
FE80::2A0:24FRFE47:1EC
Опция = 1 Длина опции
Запрашиваемый канальный адрес 00-20-AF-42-46-36
Рис. 8.14. Оповещение о канальном адресе
pec, a IP-адрес станции В, то есть той станции, канальный адрес которой
нужно узнать.
Также тело содержит IP-адрес станции, канальный адрес которой нужно
узнать.
Опция 1 содержит канальный адрес отправителя (см. рис. 8.13), а опция
2 — искомый канальный адрес (см. рис. 8.14).
Тело 1СМРу6-сообщения содержит три скрытых флага: R, S и О. Если
отправитель — маршрутизатор, он устанавливает флаг R (router) в 1.
Если это ответ на запрос о канальном адресе, устанавливается в 1 флаг S.
Если отправитель хочет подчеркнуть, что получатель должен
перезаписать значения, сохраненные в памяти, устанавливается в 1 флаг О
(override). Получатель сохраняет объявления своих соседних узлов в памяти,
313

TCP/IP и DNS в теории и на практике. Полное руководство
чтобы каждый раз при отправке дейтаграммы не запрашивать
канальный адрес соседей. В Windows.NET можно вывести содержимое этой
памяти с помощью команды ipv6 nc.
Напоследок, рассмотрим ЮМРуб-сообщение «Neighbor Advertisement»,
захваченное программой Network Monitor (см. листинг 8.2)
Листинг 8.2. 1СМРу6-сообщение «Neighbor Advertisement»
+ ETHERNET: EType = IPv6
+ IP6: Proto = ICMP6; Len = 32
ICMP6: Neighbor Advertisement; Target = fe80::2a0:24ff:fe47:lee
ICMP6: Type =13 6 (Neighbor Advertisement)
ICMP6: Code = 0 (0x0)
ICMP6: Checksum = OxADOE
ICMP6: 0 = Not router
ICMP6: .1 - Solicited
ICMP6: .1 = Override
ICMP6: Target Address = fe80::2a0:24ff:fe47:lee
ICMP6: Target Link-Layer Address = 00 A0 24 47 01 EC
ICMP6
ICMP6
ICMP6
Type = 2 (0x2)
Length = 1 (0x1)
Target Link-Layer Address = 00 A0 24 47 01 EC
Определение адреса маршрутизатора в локальной сети
Если нашей станции нужно связаться с другой станцией, находящейся
за пределами ее локальной сети, ей нужно знать адрес
маршрутизатора. Обычно адрес маршрутизатора по умолчанию (default) сохраняется
в таблице маршрутизации каждой станции.
Адрес маршрутизатора может указываться как вручную — при
конфигурировании станции, так и автоматически — маршрутизаторы регулярно
отправляют в сеть мультикастинги, адресованные всем компьютерам,
сообщающие о наличии маршрутизатора в сети и о его IP-адресе. Если
быть предельно точным, то регулярно всем компьютерам сети
отправляется ICMP-сообщение «объявление маршрутизатора» («router
advertisement»). Формат данного сообщения изображен на рис. 8.15.
После принятия этого ЮМР-сообщения станция создает запись default
в своей таблице маршрутизации или изменяет ее, если это необходимо.
314

Глава 8. Протокол IP, версия 6
' 6
15
-V'-l ■ ~£\.:- 0
Длина полезных данных
След. = 58
Переходы = 255
U Отправитель —
— Получатель: FF02;:1 —
Тип= 134
Cur Hop Limit
Код = 0
М
О
0..0
Контрольная сумма
Время жизни маршрутизатора
Время доступности
Таймер повтора
Опция = 1
Длина опции
Канальный адрес отправителя
Рис. 8.15. Формат ICMP-сообщения «Объявление маршрутизатора»
ICMP-сообщение «Объявление маршрутизатора» содержит следующие
поля:
• Поле Тип ICMP-сообщения (ICMP message type) — значение
данного поля равно 134, а код устанавливается в 0.
• Поле Лимит перехода (hop limit) — задает лимит переходов.
• Флаги М и О используются протоколами высших уровней,
например, протоколом DHCP.
• Поле Время жизни маршрута (router lifetime) — содержит время
в секундах, на протяжении которого станция должна хранить
установленную запись default в своей таблице маршрутизации. Если
значение равно 0, то запись default вообще не должна содержаться
в таблице маршрутизации.
• Поля Время доступности (Reachable Time) и Таймер повтора
(Retrans Timer) относятся к сообщениям поиска/объявления со-
315

TCP/IP и DNS в теории и на практике. Полное руководство
седей. Оба поля содержат значения, указанные в миллисекундах.
Первое поле содержит время, на протяжении которого сосед
считается доступным. Второе поле задает время между двумя
сообщениями поиска соседа, то есть интервал между сообщением и его
повтором.
ICMP-сообщения — объявления соседей могут содержать
дополнительные опции, например, на рис. 8.15 изображена дополнительная опция
MTU, приводящая максимальный размер канального кадра.
В ICMP-сообщении «Объявление маршрутизатора»
присутствует опция Канальный адрес отправителя (source link address). Она
используется, чтобы станция, получившая это сообщение, не
отправляла в сеть еще одно сообщение, запрашивающее канальный адрес
маршрутизатора.
Станция может запросить, чтобы маршрутизатор отправил сообщение
поиска маршрутизатора. В этом случае используется ЮМРуб-сообще-
ние «Neighbor Advertisement» — сообщение поиска
маршрутизатора (router solicitation). Данное сообщение (см. рис. 8.16) отправляется
станцией с помощью групповой рассылки (multicast) всем
маршрутизаторам (FF02:2).
Рис. 8.16. Формат ICMP-сообщения поиска маршрутизатора (Router Solicitation)
316

Глава 8. Протокол IP, версия 6
Перенаправление (Redirect)
Структура ICMP-сообщения «перенаправление» изображенанарис. 8.17.
В нижней части рисунка изображена гипотетическая команда route,
которую должна выполнить станция при получении этого сообщения.
Поле Код (code) содержит 0, если получатель ICMP-сообщения
является компьютером и 1, если получатель — маршрутизатор.
15
Полезная длина
. След. = 58 Переход «255
Отправитель: Router 1
Получатель: отправитель IP-дейтаграммы
Тип = 137
Код = 0
Контрольная сумма
Зарезервировано
IP-адрес: Router 1
IP-адрес: получатель
% Опция а 2 Длина опций
Канальный адрес Router 2
Опция-4 Длина опции
Reserved
Зарезервировано
Начало дейтаграммы (макс. 576 В)
"route add host Destination Router 2"
Рис. 8.17. Перенаправление
317

TCP/IP и DNS в теории и на практике. Полное руководство
Рассмотрим пример, изображенный на рис. 5.12. В сети есть несколько
маршрутизаторов. Станция отправляет IP-дейтаграмму, адресованную
другой станции. Поскольку таблица маршрутизации отправителя не
содержит прямого маршрута к маршрутизатору 2, дейтаграмма
отправляется по маршруту default к маршрутизатору 1. Маршрутизатор 1,
получив дейтаграмму, отправляет ее маршрутизатору 2. Во время
маршрутизации маршрутизатор 1 информирует об этом отправителя с помощью
ICMP-сообщения «изменение маршрута» (change routing) — попросту
говоря, «перенаправление» (redirect).
Отправитель исходной дейтаграммы, получив такое сообщение, делает
в своей таблице маршрутизации соответствующую запись, и
впоследствии все дейтаграммы к получателю отправляет непосредственно через
маршрутизатор 2.
8.4. IPv6-адреса
IP-адреса в протоколе IPv6 16-байтовые (128-битовые). При этом
различают три типа адресов:
• Направленный адрес (Unicast) — уникальный адрес сетевого
интерфейса (индивидуальный адрес);
• Групповой адрес (Multicast) — адрес, предназначенны для
отправки дейтаграмм группе компьютеров;
• Альтернативный адрес (Anycast) — определяет группу
интерфейсов для одного группового адреса. IP-дейтаграмма, содержащая
адрес типа anycast, будет отправлена на один из перечисленных в поле
адреса интерфейсов (на ближайший интерфейс, согласно топологии
сети). Anycast-адрес составляется из unicast-адресов. Обычно апу-
cast-адреса назначаются маршрутизаторам, у которых, как правило,
есть несколько сетевых интерфейсов (иначе, это был бы не
маршрутизатор).
Протокол IPv6 не предусматривает широковещательных адресов
(broadcast).
318

Глава 8. Протокол IP, версия 6
Правила написания адресов
В IPv6 используются три типа написания адресов:
• hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh, где h - одна
шестнадцатеричная цифра (0..F), представляющая 4 бита.
Пример: ABCE:3:89AD:134:FEDC:E4Dl:34:4321(Hy™ в начале
необязательны — их можно не указывать).
• Сокращенный тип, использующий двойное двоеточие,
применяющееся для замены группы, состоящей из четырех нулей.
Двойное двоеточие может встретиться в адресе только один раз.
Пример: адрес 12А1:0:0:0:0:5:15:500С:44 можно сокращенно записать
так: 12А1::5:15:500С:44; адрес 1234:0:0:0:0:0:0:14 записывается так:
1234:: 14; петля, то есть адрес 0:0:0:0:0:0:0:1 записывается как ::1
• hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:hhhh:d.d.d.d, последние
четыре символа являются десятичными цифрами — как в IPv4.
Данный способ записи адреса используется в среде, в которой
одновременно применяются оба способа адресации — IPv4 и IPv6.
Примеры: ::195.47.103.12 и 12::А54:147.123.25.4
Адреса сетей представляются аналогично адресам IPv4 — как
записанный через наклонную черту префикс, указывающий количество битов,
формирующих адрес. Например: 80:1:: 1/64.
Таблица 8.4. Некоторые части адресного пространства IPv6
0:0:0:0:0:0:0:0
1 0:0:0:0:0:0:0:1
1 0012/3
2001::/16
1 2001:0000::/29 to
2001:01F8::/29
1 2001:0200::/29 to
2001:03F8::/29
2001:0400::/29 to
2001:05F8::/29
2001:0600::/29 to
2001:07F8::/29
2002::/16
Неопределенный адрес — не назначается ни одному сетевому интерфейсу,
используется для указания того, что сетевому интерфейсу не был назначен
адрес
Обратная петля, соответствует 127.0.0.1
Глобально уникальные адреса (unicasts)
Адреса, зарезервированные интернет-реестрами для назначения интернет-
провайдерам
IANA
APNIC (Азия и Тихий океан)
ARIN (Америка)
RIPE NCC (Европа)
«6to4» (см. RFC-3056)
319

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 8.4.
1111 1110 102/10
(Такие как
FE80::)
1111 1110 112/10
(Такие как
FECO::)
FF/8
Уникальные в пределах локальных сетей адреса или адреса соединения соседей
(Link-Local Unicast). Соответствуют 169.254.0.0/16
Уникальные адреса в пределах компании (Site-Local Unicast). Соответствуют
10.0.0.0/8
Групповые адреса (Multicasts)
Групповые адреса (Multicasts)
Первый байт префикса группового адреса состоит только из двоичных
единиц, то есть в шестнадцатеричном виде — FF (см. рис. 8.18).
j 3 13 13 19 16 |
г<—►-* >~* ►-< ►-« >'.<
64 бита
001 TLAID
под-TLA
NLAID
SLAIDs
Идентификатор интерфейса
*~< ►-« ►-< *~*
Для Internet- Для В пределах •
провайдера ком- компании
пании
Для Internet-
реестра
(т. е. для RIPE
2001:0600::)
Сеть (64 бита)
Интерфейс
Рис. 8.18. Групповой адрес
Второй байт разделен на две половины. Первая половина содержит
только один важный бит — Т: если он содержит 0, значит, групповой
адрес постоянный (всем известный адрес), если 1, значит, он назначен
временно (переходящий мультикастинг).
Вторая половина второго байта определяет область группы,
формирующей групповой адрес — поле Scope или Range. На данный момент
в стандарте зафиксировано пять значений, остальные же
зарезервированы на будущее:
• 1 — локальная группа в пределах узла сети;
• 2 — локальная группа в пределах физической сети (подсети);
320

Глава 8. Протокол IP, версия 6
• 5 — локальная группа в пределах производственной площадки
(подразделения компании);
• 8 — группа локальна в пределах организации;
• Е (14) — глобальная группа.
Оставшиеся 112 битов являются идентификатором группы. Можно
выделить несколько наиболее часто используемых групповых адресов:
• FFxx: : 1 — все станции сети (компьютеры и маршрутизаторы);
• FFxx: : 2 — все маршрутизаторы;
• FFxx: : 9 — все маршрутизаторы, использующие протокол RIP.
Вместо XX нужно вставить значение поля Scope (Range). Например,
адрес FF02::2 предназначен для всех маршрутизаторов в сети, a FF08::2 —
для всех маршрутизаторов предприятия.
Индивидуальные адреса
Рассмотрим обычный глобальный индивидуальный 1Ру6-адрес (см.
рис. 8.19). Формат адреса описан в RFC-2373 и в RFC-2450.
1 3
13
13
19
16
64 бита
001
TLAID
под-TLA
NLAID
SUID
Для Internet- Для Internet- Для В пределах
реестра провайдера ком- компании
(т. е. для RIPE пании
2001:0600::)
Сеть(64
1бита)
Идентификатор интерфейса
Интерфейс
Рис. 8.19. Индивидуальный \Рч6-адрес, назначенный провайдером
Адрес состоит из шести полей (в скобках указан размер поля в битах):
• FP (3) — префикс данного типа адресов, значение равно 001;
• TLA ID (13) — идентификатор агрегации (объединения) высшего
уровня;
• RES (8) — зарезервировано;
11 Заг 518
321

TCP/IP и DNS в теории и на практике. Полное руководство
• NLA ID (24) — идентификатор агрегации (объединения)
следующего уровня;
• SLA ID (16) — идентификатор агрегации уровня производственной
площадки;
• ID Интерфейса (64) — идентификатор сетевого интерфейса.
Идентификатор объединения TLA ID используется провайдерами
высшего уровня (точнее, их маршрутизаторами) и точками обмена
трафиком (NIX). Идентификатор NLA ID предназначен для маршрутизаторов
подсетей, a SLA ID — для сетей отдельных компаний (например, для
корпоративных сетей или провайдеров). На каждом из уровней
маршрутизаторы обрабатывают не весь адрес, а только его часть, которая
предназначена именно для них, что положительно сказывается на размере таблицы
маршрутизации (она уменьшается) и скорости обработки адресов.
Поле RES зарезервировано и пока не используется. Оно будет
использовано, если возникнет потребность в расширении полей 1Ру6-адреса.
Сложнее ситуация с узлами, которые поддерживают только протокол
IPv4, Ясно, что рано или поздно все перейдут на IPv6, но на время
перехода нужно как-то выйти из положения. Для этого старым узлам
присваиваются адреса в формате: 80 нулевых битов, 16 единичных, а после
них — обычное значение адреса, согласно IPv4.
Поле ID интерфейса (interface identification) — 64-битовое. Оно
использует способ адресации, соответствующий стандарту IEEE EUI-64,
который предусматривает 8-битовые адреса. Такой адрес состоит из трех
байтов производителя и пяти байтов, уникальных для данного
производителя. Преобразование адреса EUI-64 в 1Р\г6-адрес интерфейса
выполнить очень просто: достаточно изменить всего один бит — младший бит
первого байта.
Однако на канальном уровне мы обычно используем 6-байтовые
адреса, соответствующие стандарту IEEE 802. Мы должны преобразовать
6-байтовый адрес формата IEEE 802 в 8-байтовый адрес,
соответствующий стандарту IEEE EUI-64. Преобразование выполнить очень просто:
2 байта с шестнадцатеричным значением FFFE вставляются между
третьим и четвертым байтами (см. рис. 8.20).
Пример: производитель назначил моей сетевой карте канальный адрес
00-А0-24-47-01-ЕС. После преобразования в EUI-64 он стал
выглядеть так: 00-A0-24-FF-FE-47-01-EC. ID интерфейса протокола IPv6—
::2A0:24FF:FE47:1EC.
322

Глава 8. Протокол IP, версия 6
IEEE 802
cccoccOO occccocc ccccococ
xxxxxxxx xxxxxxxx xxxxxxxx
EUI-64
IPv6

интерфейс
ococccO 0 fccq<?cocc , cccccccc
llllllll 11111110
xxxxxxxx
xxxxxxxx
FFFEie
"ccfOCPCl^^jOCOPCqcip^qpqbqcqQ'
llllllll 11111110
Рис. 8.20. Преобразование IEEE 802 адреса в IPv6 адрес
IPv6 И ОПЕРАЦИОННЫЕ СИСТЕМЫ СЕМЕЙСТВА WINDOWS
В Windows стек протокола IPv6 — это самостоятельный стек, не
зависящий от стека IPv4. Однако стоит отметить, что в Windows XP поддержка
IPv6 (впрочем, как и во многих других ОС) пока экспериментальна.
Активизировать поддержку можно командой:
ipv6 install
IPv6 официально интегрирован в Windows.NET. Для IPv6 используется
свой набор команд, подобных ping и tracert — команд ping6 и tracert6.
Для начала давайте посмотрим, какие интерфейсы доступны после
установки IPv6. Для этого используется команда:
ipv6 if
К моему удивлению, я увидел четыре интерфейса. Если быть предельно
точным, то это 4 индекса моего сетевого интерфейса:
• Первый индекс используется как обратная петля (loopback). Адрес
этого индекса — ::1 или FE80::1.
• Два других интерфейса используются для тунеллирования IPv6
через IPv4.
• Четвертый интерфейс соответствует моей сетевой плате. Адрес
интерфейса, созданный автоконфигурацией — ::2A0:24FRFE47:1EC
(это уникальный адрес в пределах локальной сети (см. таблицу 8.4)).
323

TCP/IP и DNS в теории и на практике. Полное руководство
Интерфейс также принимает групповые рассылки с адресами FF01::1
hFF02:1(cm.ii.8.2.1).
Чтобы «пропинговать» соседний узел, недостаточно указать его IPv6-
адрес, нужно с помощью процента указать еще и требуемый индекс. Для
«пинга» используется команда ping6:
ping6 FE80::2А0:24FF:FE47:1ЕС%4
Pinging fe80::2а0:24ff:fe47:lec%4
from fe80::220:afff:fe42:4636%4 with 32 bytes of data:
Reply from fe80::2a0:24ff:fe47:lec%4: bytes=32 time<lms
Reply from fe80::2a0:24ff:fe47:lec%4: bytes=32 time<lms
Теперь введем команду ipv6 nc, чтобы просмотреть сохраненные в
памяти канальные адреса (см. п. 8.2.1):
4: fe80::2a0:24ff:fе47:lee 00-a0-24-47-01-ec reachable (33000ms)
4: fe80::220:afff:fe42:4636 00-20-af-42-46-36 permanent
2: fe80::5efe:10.0.0.30 127.0.0.1 permanent
1: fe80::l permanent
1: ::1 permanent
Первый столбец — это индекс интерфейса.

Глава 9
ПРОТОКОЛ УПРАВЛЕНИЯ
ПЕРЕДАЧЕЙ (TRANSMISSION
CONTROL PROTOCOL, TCP)
TCP-СЕГМЕНТЫ
ДОПОЛНИТЕЛЬНЫЕ ЭЛЕМЕНТЫ
TCP-ЗАГОЛОВКА
ПРИМЕР TCP-СЕГМЕНТА ИЗ СЕТИ
(NETWORK MONITOR)
УСТАНОВКА И ЗАВЕРШЕНИЕ
ТСР-СОЕДИНЕНИЯ
ОПРЕДЕЛЕНИЕ СОСТОЯНИЯ
СОЕДИНЕНИЯ
МЕТОДЫ ЗАДЕРЖКИ ОТВЕТА
ТЕХНИКА ОКНА
ПЕРЕГРУЗКА СЕТИ
ОПЦИЯ РАСШИРЕНИЯ ОКНА
(INCREASE WINDOW OPTION)
TCP/IP и DNS в теории и на практике. Полное руководство

В отличие от IP, протокол TCP — протокол высшего уровня. Первый
вопрос, который всегда задает новичок: «Зачем нам нужны два
протокола - и IP, и TCP?»
Протокол IP передает данные между отдельными компьютерами в
Интернете, а протокол TCP используется для передачи данных между
двумя приложениями, которые выполняются на этих двух компьютерах.
Если сравнить это со стандартной почтовой системой, IP-адрес — это
адрес жильца, а номер порта (адрес в TCP) — это имя фактического
жильца в доме.
Кроме того, протокол IP не гарантирует доставки данных, а протокол TCP
специально предназначен для этого. Протокол TCP ориентирован на
соединение. Другими словами — это служба, устанавливающая связь между
двумя приложениями и создающая виртуальный канал на время
соединения. Этот канал полнодуплексный — данные одновременно передаются
в обоих направлениях независимо друг от друга, как показано на рис. 9.1.
i Ввод Вывод ,
Первая / yj | l__\J \ Вт°Рая
сторона I I I I сторона
соадинвния ирр^^^^ШЩШ!^'совАИНвнИЯ
Рис. 9.1. Двусторонняя связь между сторонами соединения
Передаваемые байты имеют нумерацию. Потерянные или
поврежденные данные запрашиваются снова. Целостность переданных данных
контролируется контрольной суммой. В связи с этим, приложению, ис-

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
пользующему протокол TCP, не нужно беспокоиться о данных,
утраченных или ощибочно измененных в процессе передачи — это задача
протокола TCP.
Однако протокол TCP обеспечивает защиту только от технических
ошибок, но он не защищен от «интеллектуальных атак», которые изменяют
данные и пересчитывают контрольную сумму. Для защиты от этого рода
атак используются протоколы SSL и S/MIME, относящиеся к семейству
протоколов TCP/IP.
Стороны соединений («отправитель» и «получатель») указываются
с помощью номеров портов. Номер порта — двухбайтовый, поэтому
номера портов могут изменяться в диапазоне от 0 до 65535. Часто с
номером порта указывается и его протокол, например: 53/udp или 53/tcp.
Порт 53/tcp не имеет ничего общего с портом 53/udp.
В Интернете нужное приложение определяется IP-адресом, номером
порта и используемым протоколом (TCP или UDP). Протокол IP
передает IP-дейтаграмму на определенный компьютер. Ясно, что на
компьютере выполняются различные приложения. Операционная система
для определения нужного приложения использует номер порта. Порты
напоминают почтовые ящики в доме, как показано на рис. 9.2.
TPC сегмент
Для порта 6
IP дейтаграмма
Для компьютера
к
*
Ч
к
Сете
Порты Порты
UDP TCP
0
1
2
3
4
5
7
0
1
2
3
4
5
6
7
65535
65535
той ин1
герфей<
Рис. 9.2. Порты TCPnUDP
327

TCP/IP и DNS в теории и на практике. Полное руководство
Базовая единица передачи информации в протоколе TCP — это
дейтаграммы, называемые TCP-сегментами, передаваемые в виде байтовых
потоков. TCP-сегмент инкапсулируется в IP-дейтаграмму, которая,
в свою очередь, инкапсулируется в кадр канального уровня. Если
нужно передать слишком большой TCP-сегмент, размер которого
превышает размер кадра канального уровня (MTU), то протокол IP выполняет
фрагментацию IP-дейтаграмм (см. рис. 9.3).
1
заголовок
Данные
Предаваемые данные приложения
f
t
заголовок
Данные
• Фрагментация •
IP
заголовок
заголовок
Данные
заголовок
Данные
1Й§Ш11н
заголовок
Данные
IP
заголовок
Данные
Рис. 9.3. Сегментация и фрагментация
9.1. ТСР-сегменты
Структура TCP-сегмента изображена на рис. 9.4.
Порт отправителя (Source port) — порт отправителя TCP-сегмента, в то
время, как порт получателя (Destination port) — это порт получателя
TCP-сегмента. Для однозначной идентификации соединения в
Интернете в любой текущий момент времени используется пять элементов
заголовков TCP-сегмента и IP-пакета: порт отправителя, порт получателя
(ТСР-заголовок), IP-адрес отправителя, IP-адрес получателя
(IP-заголовок) и тип протокола (TCP). TCP-сегмент — это часть потока данных
между отправителем и получателем.
328

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
TCP-сегмент
IP-заголовок
обычно 20 байт
TCP-заголовок
обычно 20 байт
TCP-данные (не всегда)
9^ 8 16 24 " ~ " ~ ~ - - -31
Порт отправителя
16 бит
Порядковый номер
32 бита
Номер подтверждения
32 бита
Заголовок
Длина 4 бита
Резерв
ббит
и
R
G
А
С
К
Р
S
Н
R
S
Т
S
Y
N
F
I
N
Контрольная сумма TCP
16 бит
Дополнительные данные (если
Порт получателя
16 бит
Размер окна
Указатель срочности
16 бит
есть)
Рис. 9.4. ТСР-сегмент
Порядковый номер посланного байта (sequence number of the sent
byte) — это порядковый номер байта TCP-сегмента в потоке данных от
отправителя к получателю. Поток данных в противоположном
направлении использует независимую нумерацию для своих данных.
Поскольку размер этого поля равен 32-м битам, по достижении значения 232-1
данное поле циклически обнуляется. Обычно нумерация начинается не
с нуля, а со случайно выбранного номера. Если установлен флаг SYN,
операционная система отправителя всегда обнулит счетчик, генерируя,
таким образом новый начальный порядковый номер для передачи
байтов, который называется ISN (Initial Sequence Number).
И наоборот, поле Номер подтвержденного байта (acknowledgment
number of the accepted byte) отображает номер следующего байта,
который адресат готов принять. Другими словами, получатель
подтверждает, что правильно принял все данные, вплоть до числа «номер
подтвержденного байта — 1».
Длина заголовка (Header length) определяет длину заголовка
ТСР-сегмента в множителях 32-х битов (4-х байтов) — подобно формату
заголовков протокола IP.
329

TCP/IP и DNS в теории и на практике. Полное руководство
Размер окна (Window size) определяет увеличение порядкового
номера передаваемого байта, который будет еще приниматься адресатом
(количество байтов, которое можно принять).
Указатель срочности (urgent pointer) — когда отправляются срочные
данные, это поле содержит конечную границу срочных данных в
сегменте. Используется вместе с флагом срочности URG. Данный механизм
применяется, например, протоколом Telnet.
Протокол Telnet передает данные между терминалом и сервером.
Кроме обычных данных программы, поток данных может также содержать
команду IAC (интерпретировать как команду), которая означает:
«интерпретировать следующие данные как команду telnet». После
команды IAC следует команда telnet. Примером команды можно назвать
команду ABORT (прерывание процесса), код которой в десятичной
системе равен 238.
Команда ABORT передает запрос пользователя на окончание процесса.
Возможно, пользователь отправил серверу большое количество данных,
которые ожидают в памяти сервера обработки.
Если пользователь хочет преждевременно завершить процесс, отбросив
все необработанные данные, он посылает команду ABORT. Сервер
обрабатывает все данные последовательно, поэтому команда ABORT
выполнится только после того, как все данные будут обработаны. Однако
пользователь хочет закончить процесс немедленно. Для этого
ТСР-сегмент, содержащий команду ABORT, маркируется флажком URG и
заполняется указателем срочности, связанным с командой ABORT.
....<ABORTXIAC>....
А ^ Поток данных
'— Указатель срочности
Рис. 9.5. Указатель срочности
По флагу URG сервер определяет, что TCP-сегмент содержит срочные
данные. Указатель срочности содержит порядковый номер байта начала
срочных данных (начала команды ABORT). Срочные данные считыва-
ются в буфер, пока не встретится команда <1АС> (код 255). Получив
команду, сервер интерпретирует ее.
330

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Работа указателя срочности зависит от программного обеспечения.
Большинство программ вообще не использует ни этот указатель, ни флаг
URGA— если URG установлен, то он просто игнорируется. Программы
telnet и rlogin, использующие этот указатель, — исключения из правила.
В поле Флаги (flags) могут использоваться следующие флаги:
• URG — TCP-сегмент содержит срочные (важные) данные. Этот
флаг используется вместе с полем (urgent pointer). Если он
установлен, то TCP позволяет сообщить о том, что в поток данных
помещены «срочные данные». Посылка таких данных осуществляется до
завершения обработки ранее отправленных данных. Как поступить
со «срочными данными» должно быть решено в программе
получателя.
• АСК — TCP-сегмент с действительным «номером подтверждения»
(acknowledgment). Устанавливается во всех сегментах, кроме
первого, с которым клиент устанавливает соединение.
• PSH — TCP-сегмент содержит данные приложения, и отправка этих
данных принимающему процессу должна быть предусмотрена
настолько быстро, насколько это возможно.
• RST — отклонение (сброс) TCP-соединения, что означает посылку
флага «сброс», вместо обычного FIN, чтобы закрыть соединение.
RST-сегмент не ожидает ответа — он не содержит подтверждения
вообще.
• SYN — отправитель сбрасывает счетчик переданных байтов.
Другими словами, TCP-сегмент содержит порядковый номер первого
посланного байта (initial sequence number, ISN). Флаг SYN
устанавливается при создании нового соединения, и поле номера
последовательности (sequence number of the sent byte) содержит исходный
номер последовательности (ISN), который выбирается хостом для
данного соединения. Номер последовательности первого байта
данных, который посылается этим хостом, будет равен ISN плюс один,
в связи с тем, что флаг SYN занимает собой номер
последовательности.
• FIN — флаг закрытия соединения. Этот флаг используется для
закрытия соединения, каждая сторона должна послать FIN, когда
передача данных завершена. При получении сервером флага FIN, он
отправляет назад АСК с принятым номером последовательности
плюс один.
331

TCP/IP и DNS в теории и на практике. Полное руководство
Мы будем записывать флаги, используя первую букву названия каждого
из них. Если какой-нибудь флажок не установлен, мы будем
использовать вместо него точку. Например, если у нашего TCP-сегмента
установлены только флаги АСК и FIN, то поле флагов будет записано: .A...F.
Контрольная сумма (checksum) заголовка IP вычисляется только по
заголовку IP. Контрольная сумма TCP-сегмента вычисляется не только
по заголовку, но и по передаваемым сегментом данным. Кроме ТСР-за-
головка и данных сегмента, для вычисления контрольной суммы TCP
используются и некоторые элементы заголовка IP.
Контрольная сумма вычисляется по полям, представленным на рис. 9.6,
на котором изображены только поля, используемые для расчета
контрольной суммы: пакет с такой структурой никогда бы не был передан по
Интернету Иногда данная структура называется «псевдозаголовок».
IP-адрес отправителя,""
эес отправителя^ * ^ « \ w ^ „\^т х«*'ъ *г%>
t
§§
Двоичные нули
Протокол PTCL
8 бит V
;/ ч ^ Длина IP-дейтаграммьгЧ */%*>-£ 1
•'»v ь • у ^,i foe wrb- - - ^ х ;-• -M>i
Порт отправителя
16 бит
Порт получателя
16 бит
Номер последовательности
32 бита
Номер подтверждения
32 бита
Заголовок
Длина 4 бита
Резерв
6 бит
и
R
G
А
С
К
Р
S
н
R
S
т
S
Y
N
U-
I
N
Размер окна
Двоичные нули
Указатель срочности
16 бит
Дополнительные данные (если есть)
ДАННЫЕ
Добавление для четного количества байтов
По необходимости - двоичные нули
Рис. 9.6. Поля, по которым вычисляется контрольная сумма TCP
На рис. 9.7 представлены заголовки протоколов IP и TCP.
332

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
TCP-сегмент
IP-заголовок,
обычно 20 байтов
TCP-заголовок
обычно 20 байт
TCP-данные (дополнительно)
8
16
24
31
■ВерЬйяЩ
заголовка;|
t-ЩУ"
Иде^фиКацйяШ
штттшштвшхш
"<флагй|;:
* Смещение фрагмента
И1ИШротоШ;Я
К6нтрольная1Ьумма^
шшшш&ш
■^ЩЙ^й-эЬтй)-®
Порт отправителя
16 бит
Порт получателя
16 бит
Порядковый номер
32 бита
Номер подтверждения
32 бита
Заголовок
Длина 4 бита
Резерв
6 бит
и
R
G
А
с
К
Р
S
н
R
S
т
S
Y
N
F
I
N
Размер окна
Контрольная сумма TCP
16 бит
Опорный указатель
16 бит
Дополнительные данные (если есть)
ДАННЫЕ
Рис. 9.7. Заголовки IP и TCP
9.2. Дополнительные элементы ТСР-заголовка
Обязательные элементы заголовка TCP занимают 20 байтов. После них
следуют дополнительные элементы. Дополнительный элемент состоит
из типа дополнительного элемента, длины и значения. Чтобы получить
длину TCP-сегмента в байтах, поле длины нужно умножить на 4. Если
333

TCP/IP и DNS в теории и на практике. Полное руководство
длина заголовка не кратна 4, то определенное количество байтов
заполняется пустым элементом NOP.
Поскольку поле длины заголовка состоит только из четырех битов,
оно может принимать максимальное значение 11112=1510. Поскольку
длина ТСР-заголовка обычно больше, чем 15 битов, длина указывается
в множителях на 4, поэтому максимальная длина ТСР-заголовка
составляет 15 х 4 = 60 байтов. Обязательные элементы занимают 20 байтов,
а 40 байтов отводится под дополнительные элементы.
На рис. 9.8 изображены некоторые элементы заголовка TCP и их
структура. Наиболее интересным для нас является дополнительный элемент
Максимальный размер сегмента (Maximum Segment Size, MSS).
Используя этот элемент, обе стороны соединения могут согласовать
максимальный размер сегмента в начале соединения.
Тип
1 байт
0
1
2
3
8
11
12
13
И5айт Значение |
Конец списка опций - EOL
Нет операции - NOP
4
Макс, размер сегмента
(MSS) 2 В
3
Коэффициент окна
(Shift count) 1 В
10
Временная метка
4В
6
Счетчик соединения
4В
6
Новый счетчик
4В
6
Эхо-счётчик
4В
Эхо-ответ врем, метки
4В |
Рис. 9.8. Некоторые элементы заголовка TCP и их структура
334

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
9.3. Пример TCP-сегмента из сети
(Network Monitor)
Рассмотрим TCP-сегмент, у которого установлен только флажок SYN.
В заголовке сегмента есть один дополнительный элемент —
максимальный размер сегмента (MSS), равный 1460.
FRAME: Base frame properties
ETHERNET: ETYPE=0x0800:Protocol=IP:DOD Internet Protocol
IP:ID = 0x4030; Proto = TCP; Len: 44
IP: Version = 4 (0x4)
Header Length = 20 (0x14)
Service Type = 0 (0x0)
Total Length = 44 (0x2C)
Identification = 16432 (0x4030)
Flags Summary = 2 (0x2)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = TCP — Transmission Control
IP: Checksum = 0x63DF
IP: Source Address = 194.149.104.198
IP: Destination Address = 194.149.104.203
IP: Data: Number of data bytes remaining = 24 (0x0018)
TCP:S.,len:4,seq: 145165778-145165781,ack:0,win:8192,src:1458 dst: 4433
TCP: Source Port = 0x05B2
Destination Port = 0x1151
Sequence Number = 145165778 (0x8A70DD2)
Acknowledgement Number = 0 (0x0)
Data Offset = 24 (0x18)
Reserved = 0 (0x0000)
Flags = 0x02 : ....S.
TCP: ..0.. = No urgent data
TCP: ...0. = Acknowledgement field not significant
TCP: ....0... = No Push function
TCP: 0. . = No Reset
TCP: 1. = Synchronize sequence numbers
TCP: 0 = No Fin
TCP: Window = 8192 (0x2000)
TCP: Checksum = 0xF3ED
IP:
IP:
IP:
IP:
IP:
TCP:
TCP:
TCP:
TCP:
TCP:
TCP:
335

TCP/IP и DNS в теории и на практике. Полное руководство
TCP: Urgent Pointer f 0 (0x0)
TCP: Options
TCP: Option Kind (Maximum Segment Size) = 2 (0x2)
TCP: Option Length = 4 (0x4)
TCP: Option Value = 1460 (0x5B4)
9.4. Установка и завершение TCP-соединения
Протокол IP ориентирован на дейтаграмму (без установки соединения).
В случае возникновения ошибки при отправке дейтаграммы, протокол
IP сообщает об этом с помощью протокола ICMP. На практике из
соображений безопасности использование протокола ICMP ограничено,
поэтому особой пользы от него, кроме запросов/ответов echo, нет.
Протокол TCP использует IP для передачи данных через Интернет,
устанавливая надежный потокоориентированный сервис над этим
протоколом. Протокол TCP решает проблемы установления и закрытия
соединения, подтверждения полученных и запроса утраченных данных.
9.4.1. Установка соединения
TCP позволяет одной стороне устанавливать соединение. Другая
сторона или принимает соединение, или отказывается от него. С точки зрения
прикладного уровня, сторона, устанавливающая соединение, — это
клиент, а привилегированный порт — используется порт 4433 (4433>1023).
Любой пользователь операционной системы может инициализировать
этот тип сервера (если, конечно, соответствующий порт открыт и еще не
распределен для другого процесса).
Серверы обычно используют известный номер порта. Организация
IANA назначает эти номера авторам серверов. Вы можете посмотреть
назначенные номера портов на сайте http://www.iana.org.
Клиент начинает установку соединения, посылая первый ТСР-сегмент
(сегмент 1) (см. рис. 9.9) В этом сегменте порт отправителя — 1458,
а порт получателя — 4433. Клиент вставляет этот сегмент TCP в
дейтаграмму, IP-адрес отправителя которой равен «Клиент», а IP-адрес
получателя — «Сервер». Пока всё еще предельно ясно. Но как выглядят
другие поля ТСР-сегмента?
336

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Клиент генерирует случайное число в диапазоне 0 и 232-1, которое
используется в качестве ISN (см. выше). В нашем случае мы
сгенерировали ISN = 145165778. Флажок SYN(....S.) в сегменте TCP показывает, что
клиент создал начальный порядковый номер переданного байта (ISN).
Во время этого соединения сторона, ожидающая соединения, — сервер.
Кроме модели клиент/сервер, есть и другие прикладные модели, но для
облегчения восприятия мы будем пользоваться именно этими
определениями.
Протокол TCP позволяет обеим сторонам устанавливать соединение
в одно и то же время. На практике данная возможность не всегда
используется, поэтому мы будем работать только со случаями, в которых одна
сторона устанавливает соединение, а другая ожидает его. Предположим,
что клиент хочет установить соединение с сервером (сервер — это всего
лишь программа), работающим на компьютере «Server» через порт 4433
(на практике мы бы записали, что клиент хочет установить соединение
с сервером «Server: 4433»). Для соединения клиент использует порт
1458. Порт сервера должен быть известен клиенту, а серверу совсем не
обязательно знать порт клиента. Клиент тоже может использовать
фиксированный порт, но в данном случае он будет зависеть от этого порта.
Для клиента намного лучше попросить операционную систему
назначить один из свободных портов на время соединения.
Предположим, что операционная система назначает клиенту порт 1458.
Операционная система назначает номера портов выше, чем 1023. Эти
порты известны как клиентские или непривилегированные. Порты с
номерами ниже, чем 1023, являются привилегированными — только
суперпользователь (например, пользователь root в UNIX) может их применять.
Для сервера не имеет никакого значения, запрашивал ли клиент именно
порт 1458, или этот порт ему был назначен операционной системой.
Windows 2000 обычно устанавливает номера портов до 5000. Если мы
хотим изменить это значение (например, установить максимальный
номер порта 9000), нам придется изменить значение ключа MaxUpserPort,
которое будет следующим: HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\Tcpip\Parameters register. Тип
этого ключа — REG DWORD. Данный параметр также относится и к
портам UDP.
Порты с номерами ниже, чем 1024, известны как привилегированные.
Эти порты чаще всего используются серверами, потому что, как
правило, серверы инициализированы (запускаются) привилегированными
337

TCP/IP и DNS в теории и на практике. Полное руководство
пользователями или инициализируются во время запуска
операционной системы так, как если бы были инициализированы
привилегированными пользователями. Наш сервер использует привилегированный
порт — используется порт 4433 (4433>1023). Любой пользователь
операционной системы может инициализировать этот тип сервера.
Серверы обычно используют известный номер порта. Эти номера назначает
авторам серверов организация IANA.
Клиент начинает установку соединения, посылая первый ТСР-сегмент
(сегмент 1) (см. рис. 9.9). Клиент вставляет этот сегмент TCP в
дейтаграмму, IP-адрес отправителя которой равен «Клиент», а IP-адрес
получателя — «Сервер». Клиент генерирует случайное число в диапазоне О
и 232-1, используемое в качестве ISN. В нашем случае мы сгенириро-
вали ISN = 145165778. Флажок SYN(...S.) в сегменте TCP показывает,
что клиент создал начальный порядковый номер переданного байта
(ISN). Во время этого соединения порядковый номер переданного
байта будет всегда содержать переданный номер, поэтому он не
генерируется снова. Клиент не может установить флажок SYN в любых других
сегментах TCP на протяжении этого соединения. Сегмент 1 является
первым сегментом в коммуникации TCP и поэтому не может
подтвердить никаких принятых данных. Поле номера подтверждения не имеет
определенного значения (заполнено двоичным нулем).
Флаг АСК также не
устанавливается, поскольку он присутствует лишь
в каждом следующем после первого
сегмента, пока не будет достигнут
конец соединения. TCP-сегмент с
установленным флажком SYN и
неустановленным флажком АСК — это
типично для первого сегмента TCP
в соединении.
Если вы хотите запретить клиентам
установление подключения из
определенного направления, просто
установите фильтр на все ТСР-сегменты
из того направления, в котором
установлен флажок SYN, и у
нападающего не будет никаких шансов.
Клиент
порт 1458
Сервер
порт 4433
SYN 145165778-14516581 (4)
..S. <mss 1460>
SYN 377664000-37766003 (4)
АСК 145165779(1)
.A..S. <mss 1460>
SYN 145165779-145165779(0)
АСК 37664001(1)
А...
£8-
.АР...
-или -
.А....
00
"О
CD
20
Рис. 9.9. Установка соединения
338

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Другая часть сегментов 1 и 2 — дополнительный элемент MSS в
заголовке TCP. Этот элемент информирует другую сторону о
максимальной длине поля данных TCP-сегмента. Этот элемент может быть только
в сегменте TCP, у которого установлен флажок SYN (другими словами,
в первых двух сегментах).
По умолчанию для MSS используется значение 536 байтов. Это
значение служит для соединений за пределами локальной сети (через WAN).
В нашем примере используется подключение Ethernet II в пределах
локальной сети. Для канального протокола Ethernet II максимальный
размер данных кадра составляет 1500. Если из этих 1500 вычесть 20 для
заголовка IP и еще 30 для заголовка TCP, мы получим значение из
нашего примера (1460). Если бы мы использовали Ethernet ISO 8802-3 на
нашем канальном уровне, нам пришлось бы разместить еще 3 байта для
заголовка согласно ISO 8802 и 5 байтов для SNAP- заголовка, так что
MSS был бы равен 1452.
Предположим, что мы будем использовать MS Network Monitor для
просмотра абстрактного соединения, по которому будут переданы
четыре байта данных — байты с номерами 145165778-14516581. Для
максимальной наглядности на рис. 9.9 показаны суммированные посланные
байты; результат приведен в круглых скобках. Первые три сегмента не
содержат никаких данных.
Сегмент 1 содержит только дополнительный 4-байтовый элемент
заголовка TCP, определяющий максимальную длину принятых ТСР-
сегментов <MSS 1460>. MS Network Monitor добавляет длину
дополнительных элементов заголовка к длине данных. Часто записывают
дополнительные элементы заголовка в <> скобках.
Вывод MS Network Monitor (показана только строка отчета TCP):
1. сегмент Клиент -* Сервер
TCP: ....S., len: 4, seq: 145165778-145165781, ack: 0, win: 8192, src: 1458 dst: 4433
2. сегмент Сервер -* Клиент
TCP: .A..S., lai: 4, seq: 377664000-377664003, ack: 145165779, win:33580, src: 4433 cfet: 1458
Второй сегмент уже только подтверждает полученные данные — на
это указывает флажок АСК. Он подтверждает один байт
полученных данных. На самом деле, в этом поле будет значение ISN+1, что
означает, что отправитель может отправлять байт с номером ISN+1.
339

TCP/IP и DNS в теории и на практике. Полное руководство
Начиная со второго сегмента, все сегменты будут подтверждать
принятые данные (то есть в них устанавливается флажок АСК).
3. сегмент Клиент —> Сервер
TCP: .A...., lei: 0, seq: 145165779-145165779, ack: 377664001, win: 8760, see: 1458 dst: 4433
Третий сегмент также подтверждает флажок SYN, так как будто бы
подтверждает один байт. Таким образом, третий сегмент и следующий
за ним не могут содержать дополнительного элемента заголовка.
На третьем сегменте заканчивается создание соединения. TCP
требует «трехфазного подтверждения» для установления соединения
и «четырехфазного подтверждения» для завершения соединения.
4. сегмент Клиент —* Сервер
TCP: .АР..., lei:84, seq: 145165779-145165862, ack: 377664001, win: 8760, src: 1458 cbt: 4433
Вы, возможно, будете удивлены, что четвертый сегмент послан
клиентом серверу — вероятно, вы ожидали, что он будет послан
сервером клиенту. Однако нет разницы в том, кто этот сегмент отсылает.
Как только любая сторона получает первый АСК, она может начать
передачу. В конце концов, TCP-соединение — полнодуплексное
соединение. Факт, что сегмент TCP переносит данные приложения,
уже сообщен через посылку флажка PSH.
5. сегмент Сервер —► Клиент
TCP: .АР..., len:79, seq: 377664001-377664079, ack: 145165863, win:33580, src: 4433 cbt: 1458
и т. д.
Не все TCP-сегменты должны обязательно переносить данные
приложения (другими словами, не у каждого сегмента установлен флажок PSH
(.АР...)). Это может случиться, если одна сторона соединения
отправляет данные, а у другой стороны в этот момент нет данных для отправки.
Даже если второй стороне не нужно ничего отправлять, она должна
подтвердить принятые данные. Для подтверждения используется ТСР-сег-
мент, в котором не устанавливается флажок PSH(.A....) — в этом
сегменте нет никаких данных.
Соединение всегда находится в каком-либо состоянии. Во время своей
установки соединение может находиться в следующих состояниях.
Сервер:
a) LISTEN — сервер готов для соединения с клиентами.
340

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
б) SYN_RCVD — сервер получил первый сегмент TCP (установлен
флажок SYN) от клиента.
Клиент:
в) SYN_SEND — клиент послал первый сегмент TCP (установлен
флажок SYN).
Если соединение установлено, то клиент и сервер переходят в состояние
ESTABLISHED (соединение установлено). В этом состоянии обе
стороны соединения могут одновременно передавать данные.
Как в Windows, так и в Unix, вы можете легко вывести информацию
о текущих соединениях на вашем компьютере, используя следующую
команду:
netstat -a
Сервер
Клиент порт 4433
LISTEN
SYNJICVD
V
ESTABUSHED
V
Рис. 9.10. Состояния соединения
порт иэо
SYNJSEND
ESTABUSHED
341

TCP/IP и DNS в теории и на практике. Полное руководство
9.4.2. Завершение соединения
В архитектуре клиент-сервер клиент обычно устанавливает соединение,
но завершить соединение может любая сторона. Одна из сторон
отправляет TCP-сегмент с установленным флажком FIN (конец соединения) —
это активное завершение (active close). У второй стороны нет другого
выбора, кроме как провести пассивное завершение (passive close).
Теоретически возможно завершить соединение одновременно.
Если одна сторона проводит активное завершение соединения, то она не
может больше послать данные (не может послать сегменты TCP с
установленным флажком PSH). Другая сторона может это сделать, однако
продолжает отправлять данные до завершения соединения. Интервал
между активным и пассивным завершением соединения называется
полузакрытым соединением (half closed connection). Сегмент TCP
с установленным флажком FIN подобен концу файла (EOF).
Для надлежащего завершения соединения требуются четыре ТСР-сег-
мента.
SYN 11112-11112(0)
АСК38
A..F
Рис. 9.11. Завершение соединения
342

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Сегмент 6 начинает активное завершение соединения с установки
флажка FIN. Сегмент 7 подтверждает закрытие соединения с другой
стороны — другими словами, он проводит пассивное завершение. Самое
важное, что сегмент 7 также содержит флажок FIN, который начинает
полное завершение соединения. Рис. 9.11 приводит общий пример (для
примера использована rsh программа), в котором сегмент 7 не содержит
флажка FIN, потому как эта сторона хочет продолжать соединение.
Другими словами, она хочет использовать полузакрытое соединение, чтобы
передать некоторые данные приложения. Сторона, закрывшая
соединение, не может больше передавать данные.
Состояния во время закрытия соединения:
• FIN_WAIT1 — стороны выясняют, отправлены ли все данные,
устанавливается флажок FIN в TCP-сегменте, то есть сообщается об
активном завершении соединения сегментом 6.
• CLOSE_WAIT — вторая сторона приняла активное завершение
соединения и переходит в пассивное завершение — она сообщает об
этом с помощью сегмента 7. После этого соединение находится в
режиме CLOSEJWAIT.
• FIN_WAIT2 — после принятия сегмента 7 от второй стороны
сегмент 7 подтверждает активное завершение соединения. Сторона
находится в режиме FIN_WAIT2, пока другая сторона не передаст
TCP-сегмент с флажком FIN (иными словами, пока не перейдет в
режим TIME_WAIT). Если другая сторона не хочет передавать данные
в полузакрытом соединении, и соединение неактивно в течение 11.25
минут, то операционная система автоматически изменяет состояние
соединения на закрытое (CLOSED).
• LAST_ACK — другая сторона уже послала все данные и сообщает
о полном завершении соединения сегментом 8.
• TIME__WAIT — все данные с обеих сторон были переданы.
Необходимо только подтвердить, что соединение полностью закрыто.
Отправкой 9-го TCP-сегмента подтверждается полное завершение
соединения. Этот сегмент не подтвержден, и сторона, пославшая его,
должна ожидать в режиме TIME_WAIT в течение двух минут
(некоторые реализации TCP/IP сокращают этот период до 30 секунд).
Этот период времени ограничен двумя циклами жизни сегмента TCP
в сети. Причина этого проста: если сегмент 9 будет потерян в сети, дру-
343

TCP/IP и DNS в теории и на практике. Полное руководство
гая сторона может запросить его повторно. Если бы подключение было
уже закрыто, то повторить сегмент было бы невозможно.
CLOSED — вторая сторона получила подтверждение, что соединение
было полностью закрыто и переходит в режим CLOSED. Сторона,
пославшая сегмент 9, также переходит в режим CLOSED после того, как
прошло соответствующее время.
ESTABUSHED
TIMEJVAIT
Рис. 9.12. Состояние во время
9.4.3. Разрыв соединения
Соединение можно разорвать, установив флажок RST (RESET) в
заголовке TCP- сегмента.
Соединение может быть разорвано в следующих двух случаях:
• Клиент запросил соединение с сервером на порт, с которым не
работает ни один сервер. Это не касается UDP. Если дейтаграмма
протокола UDP отправлена на порт, на котором не работает ни один
сервер, система отвечает ICMP-сообщением «порт недоступен».
344

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
• Если запрещено продолжение работы существующего соединения,
мы можем также разделить эту ситуацию на два случая:
a. Закрытие соответствующего соединения — процедура
относительно долгая (например, приложение вынуждено ожидать
в режиме TIME_WAIT). После передачи всех данных
приложение хочет закрыть соединение быстрее и использует отказ от
соединения. На практике мы часто находим, что вместо сегмента
9 передается сегмент с флажком RST. Другой вариант, когда за
сегментом 9 следует подтверждение сегмента 9, в котором
установлен флажок RST. Использование этого метода допускается,
если обе стороны обменялись всеми данными.
b. Одна сторона «осознает», что нельзя доверять другой стороне,
и немедленно завершает соединение. Пример этого — протокол
SSL, который обеспечивает безопасный обмен данными. Если
одна сторона не может аутентифицировать себя или не может
использовать такой сильный алгоритм кодирования, который
требует другая сторона, то соединение немедленно завершается
(устанавливается флажок RST).
9.5. Определение состояния соединения
Вы можете просмотреть список всех фактических TCP- и UDP-соеди-
нений, используя команду netstat с параметром -а.
$ netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 194.149.105.18.22 194.149.103.204.24695 TIMEJWAIT
tcp 0 0 194.149.105.18.3099 194.108.145.128.25 SYN_SENT
tcp 0 34472 194.149.105.18.3079 195.47.32.245.25 ESTABLISHED
tcp 0 0 *.22 *.* LISTEN
tcp 0 0 *.25 *.* LISTEN
tcp 0 0 *.53 *.* LISTEN
иф О О *.53 *.*
иф 0 0 127.0.0.1.53 *.*
Первые две строки — это заголовок списка. Столбцы списка имеют
следующие значения:
345

TCP/IP и DNS в теории и на практике. Полное руководство
• Proto — содержит название используемого протокола (TCP или
UDP).
• Recv-Q — отображает число байтов в очереди заданий соединения
(ожидают обработки приложением).
• Send-Q — отображает число байтов в исходящей очереди (ожидают
отправки).
• Local Address — содержит адрес локального сетевого интерфейса,
через точку указывается номер локального порта. Сервер,
ожидающий соединения, обозначается звездочкой вместо IP-адреса.
Звездочка указывает, что сервер ожидает соединения на всех своих
сетевых интерфейсах.
• Foreign Address — содержит IP-адрес и номер порта удаленной
стороны соединения. Звездочки указывают, что сервер ожидает
соединения от любого IP- адреса и номера порта.
• State — отображает состояние соединения.
Для серверов могут появляться следующие комбинации:
Local Address
IPLporM
| IP1.port1
LISTEN
IP1.port1
\port1
Foreign Address
IP2.port2
IP2.port2
Сервер завершает
соединение с
особым клиентом
V
V
State
LISTEN
Excluding
LISTEN
LISTEN
Объяснение
Сервер ожидает подключения к своему сетевому
интерфейсу IP1. Причем сервер ожидает особого
клиента — с IP-адресом IP2 и портом port2
Сервер ожидает подключения к своему
единственному сетевому интерфейсу IP1 любого
клиента
Сервер ожидает подключения к любому из своих
сетевых интерфейсов любого клиента
Строка из предыдущего примера:
tcp 0 0 194.149.105.18.22 194.149.103.204.24695 TIME_WAIT
указывает, что сервер, работающий с портом 22 (программа sshd),
подтвердил полное завершение соединения (TIME_WAIT) с компьютером
с IP-адресом 194.149.103.204. Клиенту для этого соединения был
назначен порт 24695.
Следующая строка:
tcp 0 0 *.53 *.* LISTEN
346

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
означает, что сервер, работающий на порте 53 локального компьютера,
ожидает соединения с любым клиентом на всех своих сетевых
интерфейсах.
9.6. Методы задержки ответа
Интерактивные приложения вроде telnet очень сложны именно ввиду
своей интерактивности. Интерактивность означает, что, если вы
нажимаете клавишу «В» на вашей клавиатуре, символ В вставляется в
сегмент TCP (20 +1 = 21 байт). Сегмент TCP затем инкапсулируется в
дейтаграмму (20 + 21=41 байт), а эта IP-дейтаграмма передается серверу
через Интернет как сегмент 1 на рис. 9.13 (то есть IP-дейтаграмма
включается в кадр канального уровня, который передается от
маршрутизатора к маршрутизатору). Сервер:
а) Подтверждает получение символа. Другими словами, если нет данных
для передачи, он передает пустой сегмент (40 байтов) — сегмент 2.
б) Передает символ В серверу для обработки. Сервер должен отправить
символ В назад (сегмент 3), чтобы клиентское программное
обеспечение отобразило символ В на мониторе клиента (использование
эха). Эхо необходимо, чтобы у пользователя сложилось впечатление
интерактивности.
Клиент получает эхо (символ А) и далее:
а) Отображает его на мониторе.
б) Посылает серверу подтверждение получения эха с помощью
сегмента 4. Если нет никаких других данных для передачи, то посылает
подтверждение с пустым TCP- сегментом.
Если приложение работает таким образом, то нажатие одной клавиши
на клавиатуре означает, что в обоих направлениях должен передаться
81 байт информации (не учитывая дополнительные данные канального
уровня). 81 байт = 41 байт для передачи символа + 40 байтов для
подтверждения.
На рисунке 4.13 изображена ситуация, когда пользователь нажимает
клавиши А и Н. Чтобы уменьшить вероятность перегрузки соединения,
нам нужно сократить количество данных, передаваемых в обоих
направлениях.
347

TCP/IP и DNS в теории и на практике. Полное руководство
Наша стратегия основана на предположении, что подтверждение о
принятии данных не нужно посылать немедленно, ведь оно может быть
отправлено после небольшой задержки. Во время этой задержки,
возможно, появятся другие данные, которые нужно передать/подтвердить.
Клиент Сервер
Рис. 9.13. Нажатие «А» и «Н»
Операционная система отсчитывает время тиками по 200 мс
(максимальная длина тика не может превысить 500 мс). После каждого тика
система проверяет, есть ли что-нибудь для передачи (подтверждение
принятия данных или данные для передачи). Если что-то нужно
передать, то система сразу же передает эти данные.
На рис. 9.14 сервер принял символ А (сегмент 1), но он ответит только
после следующего тика (200 мс). Перед этим приложение может
подготовить данные для передачи (эхо А). Затем операционная система
передаст как подтверждение символа А и эха А в одном ТСР-сегменте.
Однако нет вероятности, что клиент нажмет клавишу «Н» во время
отправки символа Н, чтобы можно было отправить вместе символ Н
348

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Клиент Сервер
I I A
II 200 ms
Рис. 9.14. Сокращение числа передаваемых сегментов
и подтверждение получения эха символа А. Как показано на следующем
рисунке, клиент передает подтверждение эха символа В сегментом 3,
а нажатая клавиша «Н» передается сегментом 4.
В идеальной ситуации мы можем сократить число передаваемых
сегментов TCP от четырех до трех. Мы можем достичь даже большей
экономии, используя алгоритм Nagle, как показано на рис. 9.15.
В этом примере клиент не ожидает следующего тика (200 мс). Вместо
этого он ожидает получения любых данных с другой стороны. Данный
алгоритм синхронизирует время ответа с «вместимостью» линий
соединения (управляет потоком данных). Другими словами, если линия
загружена больше чем нужно, то тогда на реакцию нужно больше времени,
и ответ задерживается.
Техника задержки реакции полезна для программ, подобных telnet, но ее
нежелательно использовать программам, подобных Х-серверу. Если бы
мы использовали ее для Х-сервера, то движение мыши отразилось бы
на нашем мониторе только через определенное время (время задержки).
349

TCP/IP и DNS в теории и на практике. Полное руководство
Клиент Сервер
Рис. 9.15. Алгоритм Nagle
Кому хочется, чтобы перемещение мыши отображалось на терминале
через секунду (хотя бы секунду)?
Для приложений, передающих большие объемы данных (http, FTP в
режиме передачи данных), задержка ответа не используется — в ней нет
смысла.
9.7. Техника окна
Предположим, что клиенту нужно отправить большой объем данных.
Тогда клиент (или сервер) отправляет большой объем данных серверу
без подтверждения их приема. Протокол TCP буферизирует данные
между двумя сторонами соединения, используя технику окна (window
или сокращенно WIN). У каждого узла есть два окна: одно для приема
данных, другое,— для отправки. Размер окна определяет объем данных,
которые могут быть буферизированы на компьютере.
350

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Представим, что клиент установил связь с сервером, и они взаимно
договорились о том, что MSS = 1 Кб (или 1024 байта), а размер окна = 4 Кб
(или 4096 байтов ).
1 Установка соединения
WIN 4096 <mss=1024>
SYN 1-1025 (IK)
1 SYN 1025-2049(1 К)
I SYN 2049-3073(1 К)
L ACK 2049 (2K). WIN 4096
SYN 3073-4097 (1K)
SYN 4097-5121 (1K)
SYN 5121-6145 (1K)
ACK 6145 (2K), WIN 0
I ACK 6145 (2K), WIN 2048
Рис. 9.16. Техника окна
Клиент начинает передачу данных, отправляя сегменты 1, 2 и 3.
Затем он принимает подтверждение (сегмент 4) от сервера, который
подтверждает сегменты 1 и 2 (принято 2 Кб = 2048 байтов). Клиент, в свою
очередь, посылает сегменты 5, 6 и 7, но у сервера не было достаточно
времени, чтобы обработать данные, поэтому его буферная память
заполнена.
Сегмент 8 подтверждает, что сегменты 3, 5, 6 и 7 были получены, но в то
же время он закрывает окно для клиента. Другими словами, клиент не
может продолжать передачу данных. После этого сервер обрабатывает
часть данных (2 Кб). Это позволяет клиенту продолжать передачу
данных, но сегмент 9 открывает окно не полностью, а только 2 Кб, потому
что не все данные в буферной памяти были обработаны, и в ней нет
места для большего объема информации.
Давайте рассмотрим окно с точки зрения клиента после получения
сегмента 4 (рис. 9.17).
351

TCP/IP и DNS в теории и на практике. Полное руководство
Предана
неподтвержденных данных
-4 ►-«-
Окно, доступное передаче
7168
8192
Возможность передачи
после открытия окна
Открытие окна
Рис. 9.17. Окно
MSS
8192
8192
8192
Рис. 9.18. Передвижение окна после передачи данных
352

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Первые 2 Кб уже подтверждены. Окно было перемещено на 2408 байтов.
Клиенту больше не нужно продолжать держать эти подтвержденные
данные в памяти. Данные, которые были переданы, но не подтверждены
(сегмент 3), занимают 1 Кб. Поэтому клиент может передать 3 Кб
данных без какого-либо дальнейшего подтверждения.
Так как данные отправлены, окно постепенно передвигается вдоль
посланных данных, как показано на рис. 9.18.
9.8. Перегрузка сети
Окно — это количество данных, которые получатель может принять.
Несмотря на то, что размер окна определен получателем, проблема также
распространяется и на отправителя.
Если отправитель подключен к быстрому каналу связи (например, к
локальной сети), а получатель — к медленному (коммутируемое
соединение), то может возникнуть проблема: поскольку сеть получателя не
справляется с передачей такого большого количества данных (которое
может отослать отправитель), она будет перегружена, и данные, которые
сеть не может передать, будут отброшены.
Конечно, маршрутизаторы могут хранить какое-то количество
IP-дейтаграмм в буферной памяти, но ведь она тоже ограничена.
НЩ—f»~ ^^^^^В -)—пНЩ
Рис. 9.19. Небольшая «пробка» при передаче данных
от отправителя к получателю
В потере данных нет ничего хорошего, и наша цель — избежать ее любой
ценой. Для этого мы определим на стороне отправителя окно,
позволяющее узнать, сколько неподтвержденных данных отправитель может
передать перед тем, как сеть будет переполнена. Окно со стороны
источника называется окном перегрузки (congestion window или CWND для
краткости).
12 Зак. 518
353

TCP/IP и DNS в теории и на практике. Полное руководство
Отправитель постепенно увеличивает CWND до определенного
предела. Порог, после которого, вероятно, произойдет сетевая перегрузка,
называется SSTHRESH. Поскольку мы заинтересованы использовать
все возможности Интернета, нам нужно найти самый большой из
возможных CWND, который немного выше, чем SSTHRESH. Стало быть,
имеет смысл измерять SSTHRESH в множителях MSS. Отправитель
должен всегда отправлять объем неподтвержденных данных, которые
не только не превышают окно, объявленное получателем, но также не
превышают и CWND. Другими словами, максимальный объем
неподтвержденных данных, который вы можете передать — меньше значения
WIN и CWND.
9.8.1. Медленный старт
Вопрос в том, как определить максимальный CWND. Отправитель
устанавливает динамический CWND. Для начала он посылает один
сегмент и ожидает его подтверждения. Если подтверждение приходит,
то отправляются два сегмента. Если снова приходит подтверждение, то
посылаются четыре сегмента и так далее. Мы имеем дело с
экспоненциальным рядом 2п. Данная техника называется медленным стартом
(см. рис. 9.20).
CWND
SSTHRESH-
Неподтвержденный
(потерянный)
сегмент
Время - подтверждение сегмента
Рис. 9.20. Медленный старт
354

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Понятно, что после нескольких итераций источник переполнит сеть
и не получит подтверждения. Другими словами, ему придется послать
некоторые сегменты снова, потому что они будут потеряны. В этот
момент CWND уменьшается на половину, и значение устанавливается как
значение SSTHRESH (Если SSTHRESH меньше, чем два сегмента, то
его значение устанавливается равным двум сегментам).
Как определить, что сегмент не был подтвержден? Предположим, что
сегмент где-то потерялся по пути к получателю. Получатель не получил
новый сегмент, поэтому он все еще подтверждает последний
полученный сегмент. После получения трех подтверждений какого-либо
сегмента источник решает, что сегмент, следующий за подтверждаемым,
потерян, и снова отправляет его.
Возможно, что отправитель не получит никакого подтверждения
вообще в пределах определенного лимита времени. В этом случае CWND
устанавливается к размеру одного сегмента (MSS), SSTHRESH — как
двойной размер сегмента (2xMSS), и медленный старт начинается с
самого начала.
9.8.2. Предотвращение перегрузки
Для каждого соединения отправитель хранит фактические значения
MSS, WINDOW, CWND и переменную SSTHRESH. MSS
устанавливается получателем при установке соединения (сегмент, содержащий
этот дополнительный элемент, отмечается флажком SYN). Окно
динамически устанавливается получателем на протяжении всего
соединения — оно определяет количество данных, которое может быть записано
в буферную память. При передаче сегмента отправитель должен быстро
принять решение, основанное на следующих переменных:
• Если CWND меньше или равно SSTHRESH, то мы имеем дело
с медленным стартом. Поэтому нужно пытаться передать двойное
количество данных.
• Если CWND больше, чем SSTHRESH, то передача двойного
количества данных, вероятно, вызовет перегрузку. В данном случае CWND
будет незначительно увеличен (MSSxMSS/CWND + MSS/8). Это
«несущественное увеличение» CWND называется Алгоритмом
предотвращения перегрузки (см. рис. 9.21).
355

TCP/IP и DNS в теории и на практике. Полное руководство
CWND
SSTHRESH-
Предотвращение перегрузки
/ 'Быстрый старт
Рис. 9.21. Алгоритм предотвращения перегрузки
9.8.3. Потеря сегмента
Кроме перегрузки сети потеря сегмента может быть вызвана самим
каналом связи (например, чисто техническими причинами, вплоть до
поломки оборудования). Если CWND очень большой (например,
исчисляется в мегабайтах или даже в гигабайтах), повторять целое
неподтвержденное окно из-за потери одного-единственного сегмента было бы
настоящим расточительством. Поэтому используется алгоритм быстрой
повторной передачи(Раз1 Retransmit Algorithm).
Как отправитель может определить, что TCP-сегмент был фактически
потерян? С получателем все ясно. Он определяет потерю сегмента очень
просто: получает любые другие сегменты, но не потерянный сегмент.
Получатель отправляет отправителю подтверждение о последнем
корректно принятом сегменте.
TCP-сегменты включаются в IP-дейтаграммы. Каждая IP-дейтаграмма
передается по Интернету независимо и, теоретически, по другому
маршруту. Некоторые маршруты быстрее, чем другие. Поэтому может
сложиться ситуация, что отправленный позже сегмент будет получен
раньше. Тем временем, получатель уже отправил просьбу повторить якобы
потерянный сегмент.
Получение одного такого подтверждения рассматривается как
банальное событие. Это не фактическая потеря сегмента. Получатель просто
получает не ожидаемый сегмент, а следующий за ним сегмент.
Выполняется двойное подтверждение последнего корректно принятого
сегмента. Затем он получает следующий сегмент, который, однако, также
356

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
приходит вне очереди, потому что адресат все еще не получил
отсутствующий сегмент. Подтверждение дублируется снова. Получатель,
получив еще один внеочередной сегмент, повторяет запрос на
отсутствующий сегмент.
Тем временем отправитель получает запрос от получателя, затем второй,
но еще полагает, что все нормально. Получив третий запрос, он
думает: «Что-то, наверное, случилось». После этого отправитель принимает
решение об отсылке потерянного сегмента и отправляет его. Сегмент
приходит к получателю. Но так как отправитель не отбрасывал любой
из последующих сегментов (все полученные внеочередные сегменты),
получатель подтверждает, что принял все отосланные отправителем
сегменты.
Данный алгоритм быстрой повторной передачи позволяет вам
повторять только те сегменты, которые были потеряны вместо повторения
всех неподтвержденных данных. Повторение всех неподтвержденных
данных необходимо только тогда, когда алгоритм быстрой повторной
передачи «не сработал» за определенное время.
Сейчас давайте рассмотрим, как работает быстрая повторная передача
с переменными CWND и SSTHRESH:
• Когда адресат получает третий дубликат (третий запрос о
повторении отсутствующего сегмента):
♦ Устанавливается SSHTRESH, равный CWND/2.
♦ Снова передается сегмент TCP.
♦ Устанавливается CWND, равный SSHTRESH+3xMSS.
• С каждым последующим дубликатом (после 4-го) отправитель
увеличивает CWND на размер сегмента (MSS).
• Если потерянный сегмент подтвержден адресатом, источник
устанавливает CWND равным значению SSTHRESH.
Нелегко определить стабильное значение переменной SSTHRESH.
Соединение может быть неустойчивым, особенно вначале. Некоторые
операционные системы UNIX (например, DEC OSF/1, версия 4 и более
поздняя) сохраняют значение SSTHRESH в таблицах маршрутизации
для индивидуальных компьютеров даже после того, как соединение
закрыто, а затем используют это значение для последующих соединений.
357

TCP/IP и DNS в теории и на практике. Полное руководство
С помощью команды:
netstat -rv
вы можете вывести эти расширенные элементы таблицы
маршрутизации. Столбец «Thresh» содержит переменную SSTHRESH.
9.9. Опция расширения окна
(Increase Window Option)
Длина элемента заголовка Размер окна (Windows size) составляет 2
байта, следовательно, максимально допустимый размер окна равен 65535.
Данное значение слишком мало для гигабайтовых сетей. Поэтому для
расширения окна используется дополнительный элемент ТСР-заголовка
«Расширение окна» (Increase Window Option). Данную опцию можно
использовать только в начальных сегментах соединения (с флагом SYN).
Используя эту опцию, можно увеличить окно в интервале от 0 до 14.
Назовем это увеличение п. Стороны договариваются об увеличении во
время установки соединения. Согласованное увеличение может быть
разным в каждом направлении.
Расширяется окно по формуле: о х 2п. о — обычный размер окна.
Используя расширение, мы можем довести максимальный размер окна
почти до 1 Гб:
65535x214 (=1073725440=1G-16384).
Но почему окно не может быть еще больше? Ответ простой.
Передаваемые данные пронумерованы от 0 до 232 (= 4 Гб). Когда достигается
номер 232, мы начинаем нумерацию с нуля. Если мы увеличим окно до
8 Гб, то отправитель сможет послать вплоть до 8 Гб неподтвержденных
данных.
Однако если получатель попросит повторить любую часть этих 8 Гб
(например, сегмент, начинающийся около 2 Гб), то отправитель не
сможет узнать, послать ли сегмент, начинающийся с 2 Гб, или тот, что
начинается с 6-ти Гбайтов. Ведь обоим сегментам соответствует один и тот
же порядковый номер — мы запустили подсчет с нуля, когда достигли
4 байтов.
358

Глава 9. Протокол управления передачей (Transmission Control Protocol, TCP
Даже если размер окна будет исчисляться в сотнях мегабайтов (что
допускается), полученный сегмент относился к уже подтвержденному
окну, но у него порядковый номер, который используется в текущем
окне. Данная проблема разрешается с помощью использования
временных меток (timestamp) в заголовке TCP-пакета. С помощью временных
меток мы можем разграничить старые и текущие сегменты, а также
распознать старые, якобы потерянные, сегменты.

Глава 10 ПРОТОКОЛ UDP
(USER DATAGRAM PROTOCOL)
ПРОТОКОЛ UDP И ЕГО ОСОБЕННОСТИ
ФРАГМЕНТАЦИЯ
ШИРОКОВЕЩАНИЕ И ГРУППОВЫЕ
РАССЫЛКИ — ОТЛИЧИТЕЛЬНАЯ
ОСОБЕННОСТЬ ПРОТОКОЛА UDP
ЧЕГО НЕ «УМЕЕТ» UDP
СРАВНЕНИЕ UDP И TCP
TCP/IP и DNS в теории и на практике. Полное руководство

10.1 ■ Протокол UDP и его особенности
Общее описание протокола
Протокол UDP (User Datagram Protocol) представляет собой
простейший протокол транспортного уровня, вкладываемый в протокол IP
(упрощенная альтернатива TCP). Он предназначен для передачи
информации, которой не требуется абсолютная надежность доставки. В этом
отношении он ничем не лучше протокола IP. Однако его использование
имеет некоторые преимущества:
• во-первых, протокол UDP, как протокол транспортного уровня,
поддерживает порты. Что, как уже упоминалось, позволяет сразу
нескольким приложениям осуществлять обмен данными;
• во-вторых, контрольная сумма вычисляется для всего пакета
данных, тогда как в рамках протокола IP она определяется только для
IP-заголовка.
Протокол TCP, являющийся надежным транспортным протоколом,
требует, чтобы хосты устанавливали между собой соединение, которое
поддерживалось бы в течение всего времени обмена данными. После
того, как этот обмен закончится, происходит закрытие соединения. Это
делается для обеспечения стопроцентной надежности передачи данных.
Однако при этом значительно возрастает нагрузка на сеть.
Протокол UDP, при всех своих недостатках, оказывает гораздо меньшую
нагрузку на сеть, поэтому для некоторых случаев его использование
может быть предпочтительнее протокола TCP. Например, для передачи
данных, надежность которого обеспечивается на более высоком уровне
(на уровне приложений) или утеря которого не будет критической.
Примером некритичной отправки могут послужить данные-извещения,
отправляемые некоторыми сетевыми устройствами при своем обновлении.

TCP/IP и DNS в теории и на практике. Полное руководство
Структура UDP-заголовка
Пакеты протокола UDP состоят из заголовка и поля данных и
целиком вкладываются в поля данных IP-пакета. Структура UDP-заголовка
представлена на рис. 10.1.
UDP-дейтаграмма
-4 ►
IP-заголовок,
обычно 20 байт
UDP-заголовок,
8 байт
UDP-данные (не обязательно)
'Ъ 8 16 24 ^ " " - -^ .31
Порт отправителя
16 бит
Длина UDP
16 бит
Порт получателя
16 бит
Контрольная сумма UDP
16 бит
Рис. 10.1. Заголовок UDP-дейтаграммы
Полная структура (а не только заголовок) UDP-дейтаграммы
изображена на рис. 10.2.
Как видно из рис. 10.1, UDP-заголовок очень прост. Он состоит из
четырех полей: порта отправителя (source port), порта получателя
(destination port), длины дейтаграммы (UDP length) и контрольной
суммы (UDP checksum). С номерами портов мы уже сталкивались
при рассмотрении протокола TCP. Нужно отметить, что порты UDP
не имеют ничего общего с портами TCP, то есть UDP-порт 53 — это не
ТСР-порт 53.
Поле Длина (UDP length) содержит длину всей дейтаграммы, то есть
длину заголовка + длину данных. Минимальная длина
UDP-дейтаграммы составляет 8 байтов, что соответствует UDP-дейтаграмме с
заголовком, но без данных.
Поле Контрольная сумма (UDP checksum) в большинстве случаев
не заполняется. Его вычисление — вне компетенции протокола UDR
В прошлом вычисление контрольной суммы вообще не использовалось,
особенно на компьютерах с установленной сетевой файловой системой
NFS (Network File System). Причина — в стремлении увеличения
производительности компьютеров.
362

Глава 10. Протокол UDP (User Datagramm Protocol)
UDP-дейтаграмма
IP-заголовок,
обычно 20 байт
UDP-заголовок,
8 байт
UDP-данные (не обязательно)
16
24
31
ДАННЫЕ
(если есть)
Рис. 10.2. UDP-дейтаграмма
Вычисление контрольной суммы производится в особо важных
случаях. Особенно опасно отсутствие контрольной суммы для серверов DNS,
поскольку в случае, если контрольная сумма не вычисляется, проверить
ошибку можно только на канальном уровне, чего явно недостаточно.
Ведь некоторые протоколы канального уровня (например, SLIP) не
вычисляют контрольную сумму, что еще больше повышает вероятность
повреждения данных при передаче.
Если же контрольная сумма вычисляется, используется
псевдозаголовок, показанный на рис. 10.3.
363

TCP/IP и DNS в теории и на практике. Полное руководство
IP-адрес отправителя
32 бита
IP-адрес получателя
.."- 32бита ^ /\
Двоичные нули
Протокол PTCL
8 бит
Общая длина IP-дейтаграммы
*16бит;
Порт отправителя
16 бит
Порт получателя
16 бит
Длина UDP
16 бит
Контрольная сумма UDP
16 бит
ДАННЫЕ
(если есть)
Дополнение двоичн. О
до нужного кол-ва байт
(если нужно)
Рис. 10.3. Псевдозаголовок для вычисления контрольной суммы U DP-дейтаграммы
Пример UDP-дейтаграммы
Листинг 10.1. Пример UDP-дейтаграммы
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x9CCE; Proto = UDP; Len: 74
IP: Version = 4 (0x4)
IP: Service Type = 0 (0x0)
IP: Total Length = 74 (0x4A)
IP: Identification = 40142 (0x9CCE)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 30 (OxlE)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x803D
IP: Source Address = 194.149.104.203
IP: Destination Address = 192.36.148.18
IP: Data: Number of data bytes remaining = 54 (0x003 6)
UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 54 (0x36)
UDP: Source Port = DNS
364

Глава 10. Протокол UDP (User Datagramm Protocol)
UDP: Destination Port = DNS
UDP: Total length = 54 (0x3 6) bytes
UDP: UDP Checksum = 0xl3A0
UDP: Data: Number of data bytes remaining = 46 (0x002E)
+ DNS: 0x7E01:Std Qry for 130.204.212.195.in-addr.arpa.
of type Dom. name ptr INET addr.
00000: 00 60 3E ID 90 00 00 00 F8 21 71 A4 08 00 45 00 . > !q...E.
00010: 00 4A 9C CE 00 00 IE 11 80 3D C2 95 68 CB CO 24 .J = . .h. .$
00020: 94 12 00 35 00 35 00 36 13 АО 7Е 01 00 00 00 01 ...5.5.6..~
00030: 00 00 00 00 00 00 03 31 33 30 03 32 30 34 03 32 130.204.2
00040: 31 32 03 31 39 35 07 69 6E 2D 61 64 64 72 04 61 12.195.in-addr.a
00050: 72 70 61 00 00 0C 00 01 rpa
10.2. Фрагментация
Фрагментация IP-дейтаграмм может быть использована и для
протокола UDP, но ее все-таки стоит избегать.
Лучшим примером этому может послужить DNS, когда DNS-клиент
отправляет запрос по UDP. Если ответ сервера превышает 512 б, то сервер
посылает только то количество информации, которое умещается в 512 б.
При этом устанавливается флаг ТС, сообщая клиенту о том, что ответ
был сокращен. Если клиенту этой сокращенной информации
недостаточно, он отправляет уже TCP-запрос для получения полного ответа.
10.3. Широковещание и групповые рассылки —
отличительная особенность протокола UDP
На первый взгляд, UDP — это урезанная версия TCP. Есть ли хоть что-
то, что «умеет» делать UDP, но не «умеет» TCP? Получателем UDP-
дейтаграммы может быть не только отдельный компьютер, но и группа
станций При этом передача данных может осуществляться в
широковещательном режиме (broadcasting) — всем подряд, либо в режиме
групповой рассылки (multicasting) — определенной группе
пользователей (как правило с установленным специальным программным
обеспечением).
365

TCP/IP и DNS в теории и на практике. Полное руководство
10.4. Чего не «умеет» UDP
Приложение ProgressiveRealAudio использует Интернет для передачи
аудиозаписей. Если UDP-дейтаграмма потеряна, наши динамики будут
издавать треск, поскольку окажутся переданными не все данные.
Основная проблема UDP при мультикастинге (групповой рассылке)
заключается в том, чтобы корректно повторно запросить потерянные
данные. Давайте рассмотрим несколько случаев, когда потерянные
дейтаграммы должны быть обязательно отправлены повторно.
Например, по мультикастингу файл может передаваться сразу
множеству пользователей (характерный пример — приложение MFTP, Multicast
File Transfer Protocol).
Представим, что некоторые пользователи получили не все части этого
файла. Получатель, не получивший определенную часть файла, должен
запросить ее еще раз. Но у кого ее запрашивать? У отправителя? Если
так, то Интернет будет просто разрушен — представьте, что миллионы
пользователей, не получивших дейтаграммы (причем, не получивших
разные дейтаграммы), обратятся к отправителю. Таким образом, это
решение сразу отпадает.
Групповые сообщения пересылаются маршрутизаторами. Выходит, что
получатель должен запросить отсутствующую дейтаграмму у
ближайшего маршрутизатора. Такие маршрутизаторы называются mrouter
(multicast router). Но обратиться к нему с запросом протокол UDP не
в состоянии, что заставляет нас использовать другие протоколы для
мультикастинга, например, протокол PFG, который в данный момент
находится еще на стадии разработки.
10.5. Сравнение UDP и TCP
Наличие этих протоколов предоставляет сетевым разработчикам
выбор между надежностью (протокол TCP) и эффективностью (протокол
UDP). Устанавливая и поддерживая соединение между двумя хостами,
протокол TCP обеспечивает надежность передачи информации между
ними, однако снижает ее эффективность.
К тому же возможности этого протокола не позволяют осуществлять
широковещательную передачу данных, так как соединение устанавли-
366

Глава 10. Протокол UDP (User Datagramm Protocol)
вается только между двумя хостами. Протокол UDP лишен этих
недостатков, однако в нем не предусмотрено никаких механизмов по
обеспечению надежности передачи данных.
В нижерасположенной таблице 10.1 приведен сравнительный анализ
двух протоколов.
Таблица 10.1. Сравнение протоколов UDPn TCP
Протокол UDP
Ненадежный
Маленькая нагрузка на сеть
Не устанавливает соединение
Обмен данными осуществляется в виде
отдельных дейтаграмм
Не производит сегментацию своих пакетов
Протокол TCP
Надежный
Большая нагрузка на сеть
Устанавливает соединение
Обмен данными осуществляется через
устойчивый виртуальный канал
Производит сегментацию своих пакетов
Особенности обоих протоколов позволяют использовать их
применительно к различным задачам и условиям.

Глава 11
СЛУЖБА ИМЕН DNS
ДОМЕНЫ И ПОДДОМЕНЫ
СИНТАКСИС ИМЕНИ
ОБРАТНЫЕ ДОМЕНЫ
ДОМЕН 0.0.127.IN-ADDR.ARPA
ДОМЕННЫЕ ЗОНЫ
ЗАРЕЗЕРВИРОВАННЫЕ ДОМЕНЫ
И ПСЕВДОДОМЕНЫ
ЗАПРОСЫ DNS (РАЗРЕШЕНИЯ ИМЕНИ)
ПРАКТИКА НАСТРОЙКИ РЕЗОЛВЕРОВ
СЕРВЕР ИМЕН
FORWARD-СЕРВЕРЫ
TCP/IP и DNS в теории и на практике. Полное руководство

Все приложения, обеспечивающие коммуникацию между
компьютерами в Интернете, используют IP-адреса, чтобы идентифицировать
связывающиеся узлы. Однако обычному пользователю сложно запомнить IP-
адрес. Поэтому вместо IP-адреса используется символьное имя сетевого
интерфейса (заметьте — не компьютера, поскольку у компьютера может
быть несколько сетевых интерфейсов).
С каждым IP-адресом может быть связано символьное имя сетевого
интерфейса (компьютера, в случае, если у него всего один интерфейс) или,
если быть предельно точным, доменное имя. Доменное имя
используется во всех командах вместо IP-адреса (за небольшим исключением: IP-
адрес может использоваться в команде определения доменного имени
по IP-адресу).
С одним IP-адресом может быть ассоциировано несколько доменных имен.
Взаимосвязь между именем компьютера и IP-адресом определена в базе
данных службы доменных имен — DNS (Domain Name System), или просто
службы имен. База данных DNS содержит отдельные записи, которые
называются ресурсными записями или записями ресурса (Resource Records).
Отдельные части базы данных DNS, называемые зонами, размещены на
разных серверах имен. Таки образом, DNS — всемирно распределенная
база данных.
Если вы с помощью программы telnet хотите зарегистрироваться на
узле info.pvt .net с IP- адресом 194.149.104.203 (см. рис. 11.1),
введите команду:
telnet info.pvt.net
После выполнения команды будет осуществлен DNS-запрос для
определения адреса сервера, и только тогда будет установлено соединение
с сервером. Таким образом, соединение устанавливается с
использованием IP-адреса, а не доменного имени.

TCP/IP и DNS в теории и на практике. Полное руководство
установка
соединения
Сервер имен
194.149.104.203
info.pvt.net
Рис. 11.1. Перед установкой соединения нужно преобразовать имя в IP-адрес
На практике IP-адрес используют только в том случае, если есть
подозрение, что DNS сработает неправильно. Несмотря на то, что это
выглядит необычно, мы можем обратиться к серверу так:
ping 194.149.104.203
http://194.149.104.203
или направить e-mail на:
dostalek@[194.149.104.203]
Однако реакция может быть довольно неожиданной. Например,
почтовые серверы не всегда поддерживают запись IP-адреса в скобках, так как
обычно они настроены на работу с доменными именами. С HTTP, скорее
всего, у вас проблем не будет. А вот протокол HTTPS сообщит, что такое
имя сервера не соответствует имени, указанному в сертификате сервера.
11.1. Домены и поддомены
Весь Интернет делится на домены, то есть группы имен, которые
логически связаны друг с другом. Домены определяют, принадлежат ли
имена узлов определенной компании, стране и т. д. Можно внутри домена
создавать подгруппы, которые называются поддоменами. Так, можно
создать поддомен домена компании для подразделения этой компании,
например, developers . company. com. Имя домена отражает членство
узла в группе и подгруппе. Каждой группе назначается имя. Имя
домена узла состоит из отдельных имен групп. Например, рассмотрим узел
bob. company. com: bob — это имя компьютера, company — имя до-
370

Глава 11. Служба имен DNS
мена, в котором находится узел, домен company является поддоменом
домена com.
Доменное имя состоит из строк, разделенных точками. Имя
обрабатывается слева направо. Самые высокие полномочия у корневого домена,
отделенного последней точкой справа. Домены верхнего уровня (Top Level
Domains) определены в корневом домене.
Существует два вида TLD: Общий домен верхнего уровня (generic
TLD) и Домен верхнего уровня кода страны (country code TLD).
Известными gTLD являются: edu, com, org, net и mil, которые
используются в большинстве случаев в США. Согласно ISO-3166
определены два символа для ccTLD каждой страны: домен us ассоциируется
с США, для Чешской Республики выделен домен cz, для России — ru.
Более подробный список ccTLD, ассоциированных с доменами, вы
найдете в главе 17.
TLD-домены делятся на поддомены для отдельных организаций.
Например, у домена com есть следующие поддомены: Coca-Cola.com,
McDonalds . com, в общем виде — company; com (имя_компании.сот).
Поддомены также могут содержать свои поддомены — домены третьего
уровня, а те — свои поддомены, являющиеся доменами четвертого
уровня и т. д. Например, у компании Company Ltd. может быть поддомен
bill, company. com для отдела счетов, sec . company. com для отдела
безопасности и поддомен head. company. com — для штаб-квартиры.
Домены создают древовидную структуру (см. рис. 11.2).
Кореньм
Третий
уровень
доменов
Рис. 11.2. Именование в системе DNS имеет древовидную структуру
371

TCP/IP и DNS в теории и на практике. Полное руководство
Рассмотрим некоторые зарегистрированные gTLD-домены:
• .org — домен предназначен для некоммерческих структур;
• . aero — домен используется структурами промышленности
авиатранспорта;
• .biz— домен используется бизнес-структурами;
• . coop — домен используется совместными объединениями
• . int — домен используется только для регистрации организаций,
утвержденных международными соглашениями между
правительствами;
• .museum — домен используется музеями;
• . name — домены для персонального использования;
• . pro — домен предназначен для аккредитованных
профессионалов и связанных с ними объектов.
11.2. Синтаксис имени
В доменном имени его составляющие перечисляются через точку
(например, abc . head. company. com) . Общий синтаксис имен таков:
строка.строка.строка ...строка.
где первая строка — имя компьютера, за ним следует имя домена
самого низкого уровня, затем имя домена более высокого уровня и т. д. Для
однозначности корневой домен, представленный точкой, завершает
данное имя.
Максимальная длина доменного имени — 255 символов. Отдельная
строка может, таким образом, состоять максимум из 63-х символов.
Строка может состоять из букв, чисел и дефисов. Дефис не может стоять
в начале или в конце строки. Можно также использовать
дополнительные символы для создания имен. Однако мы обычно их не используем,
потому что они поддерживаются не всеми приложениями.
Для записи имен можно использовать символы как нижнего, так и
верхнего регистра, но в базе данных DNS для упрощения обработки
доменных имен регистр символов не учитывается. Другими словами, имя
newyork. com может быть сохранено в одном месте базы данных DNS,
372

Глава 11. Служба имен DNS
как NewYork.com, а в другом — NEWYORK.com, но это одно и то же
имя.
Примечание.
Тем не менее доменное имя хранится в базе данных с учетом
регистра (другое дело, что он не учитывается при обращении к ресурсу). Так,
если NewYork.com был сохранен в базе данных именно так (то есть
буквы N и y — прописные), то при запросе к БД будет возвращено имя
NewYork.com. Последняя точка — часть имени.
В некоторых случаях правая часть имени может быть опущена. Мы
можем почти всегда пропустить последнюю часть доменного имени в
прикладных программах. В базах данных, описывающих домены, ситуация
сложнее:
• Почти всегда возможно опустить последнюю точку.
• Обычно возможно пропустить конец имени, если он идентичен
имени домена. Например, внутри домена company.com можно
записать computer. abc вместо computer. abc . company . com
(однако в этом случае нельзя ставить точку в конце!). Домен, к которому
принадлежит компьютер, определяется командами domain и search
в файле конфигурации (см. раздел 11.9).
11.3. Обратные домены
Как мы уже говорили, для установления соединения между узлами
используется IP-адрес, а не доменное имя. Поэтому обычно сначала
доменное имя преобразуется в IP-адрес, а только затем устанавливается
соединение по полученному IP-адресу — это разрешение имени узла
в IP-адрес. Иногда некоторым приложениям нужно обратное
преобразование, то есть по определенному IP-адресу нужно узнать связанное с ним
доменное имя. Данный процесс называют обратным разрешением.
Как и домены, IP-адреса также образуют древовидную структуру
(см. рис. 11.3). Домены, образованные IP-адресами, часто называют
обратными доменами (reverse domains). Для обратного разрешения были
созданы псевдодомены 1Р6.агра(для IPv6) и in-addr.агра(для
IPv4). Здесь in-addr. arpa означает — «обратная адресация в Arpanet»
(inverse addresses in the Arpanet).
373

TCP/IP и DNS в теории и на практике. Полное руководство
1_ 2.37.47.195.ln-addr.arpa
Рис. 11.3. Обратный домен для IP-адреса 195.47.37.2
В домене in-addr.arpa есть домены с такими же именами,
соответствующими IP-адресам сетей. Например, домен in-addr. arpa
содержит поддомены от 0 до 255. Каждый из них также содержит поддомены
низшего уровня от 0 до 255. Например, сеть 195.47.37.0/24 принадлежит
поддомену 37.47.195. in-addr. arpa. Этот поддомен принадлежит
домену 47 .195 . in-addr .arpa и т. д. В домене in-addr.arpa
поддомены записываются подобно IP-адресам, только наоборот.
Весь этот механизм работает, если между IP-адресами классов А, В и С
установлены связи. Но что делать, если у вас только сеть класса С.
Можно ли запустить свой собственный сервер имен для обратного
перевода? Да. При условии, что IP-адрес — 4-байтовый, а классический
обратный домен — 3-байтовый (четвертый байт — элемент домена, IP-
адрес), будет создан 4-байтовый обратный домен для подсети класса С.
Например, подсеть 194.149.150.16/28 будет использовать домен
16.150.149.194. in-addr. arpa, как будто бы IP-адрес состоит из 5-ти
байтов. Изначально это было ошибкой в реализации DNS, но позже дан-
374

Глава 11. Служба имен DNS
ная ошибка нашла свое практическое применение и была
стандартизирована RFC. Более подробно вы узнаете об этом в главе 16.
11.4. Домен 0.0.127.in-addr.arpa
IP-адрес 127.0.0.1 представляет для нас особый интерес. Сеть 127
резервируется для обратной петли (loopback). В то время, как другие
IP-адреса однозначны в пределах Интернета, адрес 127.0.0.1 имеется на каждом
компьютере.
Каждый сервер имен отвечает не только за «общие» домены, но и за
домен 0.0.127. in-addr. arpa. Данный домен мы не будем отображать
в схемах, но забывать о нем нельзя. Например, кэширующий сервер имен
является первичным сервером для этого домена.
11.5. Доменные зоны
ЧТО ТАКОЕ ЗОНА
Часто задаются вопросы: «Что такое зона? Какая связь между
доменом и зоной?» Давайте рассмотрим их взаимосвязь на примере домена
company.com.
Как мы уже говорили, домен — это группа компьютеров с одинаковой
правой частью доменного имени. В нашем случае, домен — это
группа компьютеров, у которых доменное имя заканчивается строкой
company. com. Однако домен company. com — большой. Кроме того,
он содержит поддомены bill.company.com, sec.company.com,
sales . company. com, xyz . company. com и т. п.
Мы можем управлять всем доменом company. com на одном сервере
имен или создать независимые серверы имен для некоторых
поддоменов (на рис. 11.4 мы создали отдельные, серверы имен для поддоменов
bill. company. com и head, company. com). Первичный (главный)
сервер имен обслуживает домен company.com и поддомены sec.
company.com, sales.company.com и xyz.company.com —
другими словами, первичный сервер имен управляет зоной company.com.
То есть зона — это часть домена, которая управляется специфическим
сервером имени.
375

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 11.4. Зона company, сот
Зона, содержащая домены низшего уровня, называется «подчиненной
зоной» (subordinate zone).
Специальные Зоны
Кроме классических зон, содержащих данные о частях доменов или
поддоменов, также используются специальные зоны для реализации
системы DNS:
• Корневая зона — это, на самом деле, подчиненная зона, содержащая
только информацию о том, какой DNS-сервер управляет каким под-
доменом (содержит NS-записи для зоны). Таким образом, корневая
зона не содержит полную зону.
• Зона кэша/подсказки — содержит список корневых серверов имен.
Данная зона называется зоной подсказок, начиная с версии 8.x Bind;
в предыдущих версиях она называлась зоной кэша. Помните, что
корневой сервер имен является авторитетным для корневого
домена, который обозначается как «.».
11.6. Зарезервированные домены и псевдодомены
В качестве TLD-доменов могут использоваться следующие
зарезервированные домены (см. RFC-2606):
• Домен test — для тестирования.
376

Глава 11. Служба имен DNS
• Домен example — для создания документации и примеров.
• Домен invalid — для вызова ошибочных состояний.
• Домен localhost — для обратной петли.
Что такое псведодомен? Это группа компьютеров, которые не
подключены к Интернету, не используют протокол TCP/IP и, следовательно,
не имеют IP-адресов. Псевдодомены особенно значимы для
электронной почты. Можно отправить электронную почту в другие сети, а затем
в Интернет с помощью псевдодомена (DECnet или MS Exchange).
Во внутренней сети компания может использовать оба протокола — TCP/
IP и DECnet. Если пользователь работает по протоколу TCP/IP, с его
адресацией проблем нет. Например, у этого пользователя может быть адрес
электронной почты daniel@computer. company. com. Но как
обратиться к пользователю компьютера, работающего по протоколу DECnet?
Чтобы решить эту проблему, в адрес добавляется вымышленный псевдодомен.
Пользователь Daniel будет иметь следующий адрес daniel@computer.
dnet. company . com. С помощью DNS вся электронная почта, которая
направлена в домен dnet. company. com, переадресовывается к шлюзу
протокола DECnet (шлюз домена company.com), который выполняет
преобразование из TCP/IP (SMTP) в Decnet (Mail-11).
11.7. Запросы DNS (разрешения имени)
Запросы и их обработка
Самый распространенный DNS-запрос — это перевод имени узла в IP-
адрес. Также можно запросить другую информацию из DNS. Запросы
передаются с помощью резолвера (resolver). Резолвер — это клиент
DNS, запрашивающий сервер имен. Поскольку база данных
распространена во всем мире, ближайший сервер имен не всегда знает конечный
ответ, поэтому он может запросить другие серверы имен. Резолверу
сервер имен возвращает или результат запроса, или отрицательный ответ.
Весь процесс разрешения состоит из запросов и ответов.
При запуске сервер имен ищет в кэш-памяти данные о зоне, которой он
управляет. Первичный сервер имен читает данные с локального диска,
вторичный сервер имен получает данные от первичного сервера имен
при передаче зоны (zone transfer) — он делает запрос на передачу зоны,
377

TCP/IP и DNS в теории и на практике. Полное руководство
получает зону от первичного сервера и сохраняет данные в кэш-памяти.
Данные, которые содержит первичный сервер, называются
авторитетными данными.
К тому же, сервер имен читает файл зоны кэша/подсказок (находится на
его локальном диске), который не является частью администрируемой
зоны, но необходим для связи с корневыми серверами имен. Эти данные
называются неавторитетными данными. В терминологии программы
BIND 8-й и 9-й версий, первичный и вторичный (primary&secondary)
серверы называются, соответственно, главным и подчиненным (master&
slave) серверами.
щ
Ба
дан
над
Щ
Первичный |
имен
за
ных
иске
Передача
зоны
гпг
Вторичный
имен *
XV \ |
Рис. 11.5. Первичный сервер имен загружает данные с диска,
вторичный сервер получает данные с помощью запроса на передачу зоны
Серверы имен сохраняют в кэш-памяти положительные (а иногда даже
отрицательные) ответы на запросы, полученные от других серверов
имен. С точки зрения нашего сервера имен, данные, полученные от
других серверов имен, также неавторитетны — просто наш сервер экономит
время, обрабатывая повторные запросы.
Как работают резолверы
Запросы программы на обращение к DNS, например, запрос о
разрешении имени узла в IP-адрес, передаются специальному компоненту
операционной системы — резолверу. Последний передает этот DNS-запрос
378

Глава 11. Служба имен DNS
серверу имен, указанному в конфигурации резолвера. Резолвер может
кэшировать ответы сервера, а может не кэшировать.
Резолвер без кэш-памяти называется stub-резолвером, а резолвер,
который кэширует ответы, называется кэширующим резолвером. Ясно, что
кэширующий резолвер работает быстрее, чем stub-резолвер. Ведь при
повторном запросе он извлекает данные из своей кэш-памяти, а
обычный (stub) резолвер опять запрашивает сервер (см. рис. 11.6).
—1
Другие
■> серверы
имен
/
\
Другие
*> серверы
имен
Рис. 11.6. Stub-резолвер и кэширующий резолвер
Кэширующий резолвер есть в Windows 2000, Windows XP и т. д.
В Windows этот сервис называется «DNS-клиент». Понимаю, что
данный термин вводит вас в заблуждение, ведь stub-резолвер — это тоже
DNS-клиент. Так оно и есть, но что поделаешь — будем выражаться
языком Microsoft.
На некоторых компьютерах запущен только резолвер (кэширующий
или его «урезанная версия» — stub). На других может быть запущен не
только резолвер, но и сервер имен. Имеется много различных
комбинаций (см. рис. 11.7), но основной принцип остается тем же:
1. Пользователь вводит команду, которая требует разрешения имени
узла в IP-адрес (на рис. 11.7 — это номер 1).
379

TCP/IP и DNS в теории и на практике. Полное руководство
2. Если резолвер кэширующий, то он попытается найти ответ в своем
кэше (2).
3. Если ответ не найден в кэше резолвера (или у нашего резолвера
просто нет кэша), то резолвер посылает запрос к серверу имен (3).
4. Сервер имен ищет ответ в своей кэш-памяти.
5. Если сервер имен не находит ответа в своей памяти, то он
запрашивает другие серверы имен.
6. Сервер может запрашивать другие серверы несколько раз, пытаясь
определить авторитетный сервер для запроса пользователя, то есть
сервер, который точно знает ответ. Ответ (может быть
отрицательным) авторитетного сервера сохраняется в памяти нашего сервера
имен и отправляется резолверу.
Stub-
реэолвер
Программа
Компьютер С
(Windows 98)
Сервер имен не
запущен или
резолвер
направлен на
другой сервер
Сервер
имен
Резолвер
Программа
Компьютер D
(Windows XP)
Рис. 11.7. Сервер имен и резолвер

Глава 11. Служба имен DNS
7. Если сервер не возвращает ответ за определенное время, то резолвер
повторяет свой запрос. Если в конфигурации резолвера указано
несколько серверов имен (обычно позволяется указать до 4-х серверов
имен), то он отправляет свой запрос следующему (другому) серверу
имен. Список серверов имен обрабатывается циклически: сначала
отправляются запросы первому серверу, затем второму, после
третьему, потом снова первому и т. д. (при условии, что указано 3 сервера
имен).
Транспортные протоколы, используемые DNS.
Особенности работы с перегруженными DNS-серверами
Для передачи своих запросов/ответов DNS использует протоколы UDP
и TCP. При этом используется порт 53 для обоих протоколов (то есть
порты 53/udp и 53/tcp). Общие запросы, как, например, перевод имени в IP-
адрес и наоборот, выполняются протоколом UDP. Длина данных,
передаваемых протоколом UDP, неявно ограничена 512-ю байтами (с флажком
усечения, который означает, что ответ не вместился в 512 байтов, и
поэтому необходим повторный запрос ответа по протоколу TCP).
Теоретически, возможна фрагментация UDP-дейтаграмм, но DNS ее не
использует. Запросы, передающие зоны, передаются по протоколу TCP.
Существует неписаное правило: база данных DNS должна быть
размещена как минимум на двух независимых серверах. В случае, если один
из них (первичный) будет недоступен (или просто перегружен),
запросы будут отправляться на другой сервер. В общем же ожидается, что все
серверы имен будут доступны. Если для передачи запроса к
недоступному серверу используется протокол TCP, то запрос будет повторен
несколько раз через определенные промежутки времени. В случае, если
после последней попытки сервер все же не будет доступен, запрос будет
направлен ко второму серверу имен.
Решение, основанное на протоколе UDP, более элегантно: дейтаграмма
с запросом отправляется серверу. Если через определенное время ответ не
будет получен, запрос будет отправлен другому серверу. Если и от этого сервера
через то же самое время не будет получен ответ, запрос будет направлен
третьему серверу имен и т. д. Если больше нет серверов имен, запрос будет снова
отправлен первому серверу, и цикл начнется сначала.
Сервер, получив запрос, пытается его обработать. Если он не может
справиться с запросом, он отправляет его другому серверу. Если и этот
381

TCP/IP и DNS в теории и на практике. Полное руководство
сервер не может обработать запрос, он направляет его следующему
серверу. Цикл продолжается до тех пор, пока не будет получен ответ —
положительный или отрицательный (например, в домене X нет такого узла).
Затем ответ точно так же рекурсивно отправляется исходному серверу,
а тот, в свою очередь, отправляет ответ клиенту.
1(т[о^) T(tld) T(tld
Запрос
Итерация
Повторный
запрос
Итерация
9
Сервер
имен 2
Повторный
запрос
Итерация
Q
Сервер
именЗ
■J> Время
Рис. 11.8. Обработка запроса
Технология Round Robin
Технология Round Robin позволяет равномерно распределить
(сбалансировать) нагрузку на серверы. Большинство серверов имен (в том
числе и Windows 2000 Name Server) поддерживают эту технологию.
Предположим, что у нас есть web-сервер (www. company. com) и
связанный с ним IP-адрес. Мы хотим увеличить производительность сервера
и выделяем для нужд этого web-сервера еще два адреса. В итоге в базе
данных DNS имя www. company. com будет связано с тремя
IP-адресами, например, 195.47.40.5, 195.47.37.200 и 194.149.105.103. Web-сервер
запущен на этих трех интерфейсах.
382

Глава 11. Служба имен DNS
Сервер DNS, поддерживающий технологию Round Robin, при
получении первого запроса на разрешение имени www. company. com сначала
возвращает адрес 195.47.40.5, при получении второго запроса
возвращает второй IP-адрес, то есть 195.47.37.200 и т. д. Когда возвращен
последний IP-адрес, сервер DNS начинает цикл заново — с первого адреса.
11.8. Практика настройки резолверов
Как уже было сказано ранее, резолвер — это компонент операционной
системы, отвечающий за разрешение доменных имен. По своей сути
резолвер представляет собой набор библиотечных функций, которые
вызывают прикладные программы.
Когда прикладной программе (например, telnet) нужно разрешить имя
в IP-адрес, она вызывает специальную библиотечную функцию.
Данная функция вызывает вспомогательные функции. В результате работы
всех этих функций будет сформирован и отправлен DNS-запрос
серверу. С другой стороны, этот запрос будет принят независимой
программой — DNS-сервером, например, программой named.
Конфигурация резолвера в Unix
Конфигурационный файл резолвера ОС Unix называется /etc/
resolv/conf. Формат этого файла следующий:
Domain имя локального домена
Nameserver IP-адрес сервера имен
Первая команда (Domain) имя домена. Вторая команда, которая может
повторяться несколько раз для разных IP-адресов серверов имен, задает
IP-адрес сервера имен.
В случае, если пользователь указал имя без точки в конце, резолвер
добавляет после указанного имени имя домена из команды Domain
файла конфигурации. Если разрешить адрес не удалось, резолвер пытается
разрешить переданное имя как есть, то есть без суффикса, указанного
в команде Domain.
Некоторые резолверы поддерживают команду Search. Эта команда
позволяет определять другие имена локальных доменов.
383

TCP/IP и DNS в теории и на практике. Полное руководство
Предположим, что наш домен называется company. com, и в нем есть
два сервера DNS — 192.168.1.1 (первичный сервер) и 192.168.1.2
(вторичный сервер). Тогда файл /etc/resolv/conf будет выглядеть так:
domain company.com
nameserver 192.168.1.1
nameserver 192.168.1.2
В этом файле конфигурации нужно указывать только IP-адреса
серверов DNS, а не доменные имена серверов DNS. Думаю, понятно почему.
Ведь TCP/IP-соединение, в том числе и с DNS-сервером,
устанавливается по IP-адресу, а не по доменному имени. Не зная IP-адреса сервера
DNS, система не сможет разрешить доменное имя самого сервера и
узнать IP-адрес сервера — следовательно, и подключиться к серверу имен
она также не сможет.
Если на компьютере запущен сервер имен, то команда nameserver
может содержать адрес 127.0.0.1.
Другие параметры резолвера (например, максимальное количество
команд nameserver) хранятся непосредственно в ядре операционной
системы. Для их изменения требуется перекомпиляция ядра ОС. Если вас
это заинтересовало, просмотрите файл /usr/include/resolv.h — в нем
как раз и находятся эти параметры. Чтобы изменения данного файла
вступили в силу, нужно будет перекомпилировать ядро.
Вообще можно сконфигурировать все компьютеры сети без
использования системы DNS. На каждом компьютере есть файл /etc/hosts
(в Windows%System_Root%/System32/Drivers/etc/hosts).
В этом файле указываются имена компьютеров и соответствующие им
IP-адреса. По умолчанию система обращается к DNS-серверу после
просмотра этого файла (порядок просмотра задается в файле /etc/host.
conf). В Unix для просмотра файла /etc/host. conf служит True64.
Конфигурация резолвера в Windows
В Windows 2000 (2003, ХР), как мы уже отмечали, имеется служба
«DNS-клиент». Она представляет собой реализацию кэширующего
резолвера. Служба запускается неявно, и останавливать ее не
рекомендуется. После остановки этой службы Windows работает в режиме
обычного stub-резолвера, то есть запросы пользователя и ответы сервера не
кэшируются.
384

Глава 11. Служба имен DNS
Содержимое кэша резолвера может быть выдано еще командой IPConfig
/displayDNS, а удалено — командой IPConfig /flushDNS.
Содержимое файла %System_Root%/System32/Drivers/etc/hosts
— это тоже часть кэша резолвера, правда, при выполнении команды
IPCongif /flushDNS, данный файл остается неизменным.
Параметры кэширующего резолвера задаются в разделе реестра:
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/
Dnscache/Parameters. Например, ключ NegativeCacheTime
задает время кэширования отрицательных ответов.
Рис. 11.9. Настройка резолвера в Windows XP
13 Зак. 518
385

TCP/IP и DNS в теории и на практике. Полное руководство
В ранних версиях Windows настройка резол вера была такой же простой,
как в Unix. Разница была только в том, что текст файла настройки
создавался не в текстовом редакторе, а значения вводились в специальном
окне. В Windows 2000 окно конфигурации резолвера (рис. 11.9)
содержит намного больше опций, что у неопытных пользователей вызывает
определенные проблемы.
Посмотрим на Windows 2000 с исторической точки зрения.
Предшественником сетевой подсистемы Windows была система LAN Manager,
основанная на протоколе NetBIOS. Протокол NetBIOS также
использует имена узлов, которые на сетевом уровне преобразуется в сетевые
адреса. При использовании протокола TCP/IP в качестве основного
сетевого протокола имена компьютеров преобразуются в IP-адреса
и наоборот.
В системе LAN Manager (сейчас Windows) была своя собственная
система имен. Имена узлов и соответствующие им IP-адреса хранились
вфaйлe%System_Root%/System 32/Drivers/etc/lmhosts.B более
поздних версиях Windows появилась служба WINS (Windows Internet
Names Service — служба интернет-имен Windows), очень похожая по
своим функциям на DNS.
Разрешение имен в Windows — очень интересный и занимательный
процесс. Если нужная информация не найдена в файле Imhosts или на
WINS-сервере, система отправляет широковещательный запрос, в
котором спрашивается, есть ли в сети искомый компьютер. Запрос к DNS-
серверу выполняется в самую последнюю очередь. Порядок разрешения
имени компьютера в Windows выглядит так:
1. Поиск в кэше NetBIOS (LAN Manager) локального компьютера (кэш
выводится командой nbtstat -с). В кэш NetBIOS заносится
информация из файла Imhosts при запуске компьютера. После
изменения файла Imhosts желательно выполнить команду nbtstat -R для
перезагрузки кэша.
2. Поиск на серверах WINS.
3. Поиск с помощью широковещательной или групповой рассылки
в локальной сети.
3. Поиск в файле lmhos t s.
4. Поиск в кэше резолвера.
5. Поиск на серверах DNS.
386

Глава 11. Служба имен DNS
Порядок поиска IP-адреса для программ, ориентированных на
Интернет (например, ping), несколько другой:
1. В кэше резолвера.
2. На DNS-серверах.
3. На WINS-серверах.
4. Широковещательной или групповой рассылкой.
5. В файле lmhosts.
Так что, если вы допустили ошибку в имени компьютера в команде ping,
то с помощью программы MS Network Monitor вы сможете увидеть
пакеты протокола Netbios и даже широковещательную рассылку.
Сейчас давайте рассмотрим настройку резолвера в Windows XP на
рис. 11.9. Сначала нужно ввести IP-адреса серверов DNS (адреса DNS-
серверов в порядке использования), но это не обязательно, поскольку
IP-адреса можно получить при запуске ОС по протоколу DHCP или
при установке коммутируемого соединения по протоколу РРР Вводить
их или не вводить (и что вводить?) — эту информацию вы всегда можете
уточнить у своего сетевого администратора.
Ниже представлены две опции:
1. Дописывать основной суффикс и суффикс подключения.
Разрешение будет выполнено следующим образом:
• Если требуемое имя содержит точку, то резолвер попытается
разрешить имя без добавления суффикса.
• Если имя не заканчивается точкой, после него добавляется т(}чка
и имя локального домена Windows.
• Если в предыдущем случае не удалось разрешить имя, то к имени
добавляется точка и DNS-суффикс этого соединения.
2. Дописывать следующие DNS-суффиксы (по порядку).
Разрешение будет выполнено так:
• Если требуемое имя содержит точку, тогда резолвер попытается
перевести имя без добавления суффикса.
• Резолвер пытается добавлять специфические суффиксы
согласно списку, перечисленному в окне вышеупомянутой опции.
387

TCP/IP и DNS в теории и на практике. Полное руководство
Если вы допустите ошибку в имени компьютера и укажете
несуществующее имя — ххх, то резолвер сначала попытается разрешить имя ххх.
den.dhsilabs.com, а затем — lena.dhsilabs.com (см. рис. 11.9).
В обоих случаях сначала будет генерироваться запрос к серверу имен
192.168.1.1, а потом, если ответ не будет получен вовремя, запрос будет
повторен, но уже к серверу 192.168.1.2.
11.9. Сервер имен
ТИПЫ СЕРВЕРОВ ИМЕН
Сервер имен содержит информацию для перевода имен компьютеров
в IP-адреса (а также для обратного перевода). Сервер имен отвечает за
определенное множество IP-адресов и связанных с ними имен
компьютеров. Данное множество называется зоной (как минимум, сервер имен
отвечает за зону 0.0.127. in-addr . агра).
Домен или его часть формирует зону. Сервер имен с помощью записи
типа NS может делегировать администрирование поддомеиа
подчиненному серверу, то есть назначить ответственный сервер для опреденного
поддомена.
Сервер имен — программа, которая выполняет разрешение по запросу
резолвера или другого сервера имен. В Unix сервер имен — это
программа named. Этот сервер называется BIND (Berkeley Internet Name
Domain).
Существуют различные типы серверов имен:
• Первичный сервер (primary master) — главный источник данных
для зоны, авторитетный для нее сервер. Этот сервер получает данные
о зоне из своей базы данных, которая сохранена на его локальном
диске. Администратор вручную заполняет базы данных для этого
сервера. Первичный сервер указывается в SOA-записи. В зоне может
быть только один первичный сервер. В англоязычной литературе вы
можете встретить названия primary server и primary master — это
одно и то же. Название зависит от версии BIND, которая
описывается в читаемой вами документации. Термин «primary server»
встречается в документации по BIND версии 4.x (то есть в более старых
версиях BIND), а термин «primary master» — в документации по BIND
версии 8.x и выше.
388

Глава 11. Служба имен DNS
• Главный сервер (master) — авторитетный сервер для зоны.
Данный сервер всегда указывается в NS-записях домена как
авторитетный сервер. Главный сервер является источником данных для
вторичных (подчиненных) серверов домена. В домене может быть
несколько главных серверов. Данный тип сервера появился в
версии 8.x BIND.
• Вторичный сервер имен /подчиненный сервер получает данные
о зоне от первичного сервера (от главного сервера) с помощью
запроса на передачу зоны. База данных на этом сервере не
редактируется вручную — в этом нет смысла, поскольку при следующем
обновлении зоны база данных будет перезаписана. Вторичный сервер
имен также авторитетен для зоны. Название данного сервера, как
и в случае с первичным, зависит от версии BIND. Термин
«вторичный сервер» (secondary server) встречается в документации по BIND
версии 4.x, а термин «подчиненный сервер» (slave server) — в
документации по восьмой (8.x) версии и выше. Хотя очень часто
упоминаются оба имени, поэтому вы должны иметь в виду, что речь идет об
одном и том же сервере.
• Кэширующий сервер не является ни первичным, ни вторичным, ни
авторитетным сервером для зоны. Он используется для
кэширования DNS-запросов/ответов. Соответственно, данные, полученные от
этого сервера, не являются авторитетными. Мы должны понимать,
что у каждого сервера есть свой кэш, но кэширующий сервер
устанавливается на определенном компьютере, чтобы повысить
производительность его резолвера — проще и быстрее найти ответ в кэше
кэшируюшего сервера, который установлен на этом компьютере, чем
искать его в кэше сервера в локальной сети. Конечно, даже
кэширующий сервер — первичный сервер для зоны 0.0.127. in-addr. агра,
но это не считается.
• Корневой сервер имен — авторитетный сервер для корневого
домена (обозначается точкой «.»). Каждый корневой сервер является
независимым первичным сервером.
• Подчиненный сервер (в терминологии 4-й версии BIND) — просто
передает запросы другим серверам имен.
• Сервер-«невидимка» (Stealth server) — секретный сервер. Данные
об этом сервере нигде не указываются. Знают о нем лишь серверы,
в которых его IP-адрес прописан в их файлах конфигурации. Это
389

TCP/IP и DNS в теории и на практике. Полное руководство
авторитетный сервер для зоны. Обычно stealth-серверы работают
«на подхвате» и содержат резервную копию базы, если локальные
серверы имен недоступны.
Архитектура master/slave изображена на рис. 11.10.
Primary master
Рис. 11.10. Архитектура Главный/Подчиненный (Master/Slave)
Как видно из рисунка, один сервер может быть главным (master)
сервером для одного сервера и, в то же время, быть подчиненным (slave) для
другого.
Для клиента нет никакой разницы между главным (первичным) и
подчиненным (вторичным) серверами имен. Оба сервера авторитетны для
определенной зоны (еще раз напомню, что кэширующий сервер не
является авторитетным).
Если хостмастер добавит в базу данных первичного (главного) сервера
новую запись, например, сведения о новом компьютере, через некоторое
время данная запись появится на всех вторичных серверах сети.
Время обновления зоны указывается в SOA-записи данной зоны.
Проблема может возникнуть, если клиент запрашивает информацию о
компьютере у вторичного (подчиненного) сервера, когда тот еще не обновил
зону. Ответ сервера будет отрицательным, поскольку сам вторичный
сервер и знать не знает о существовании такого компьютера.
Хотя это не самая плохая ситуация. Предположим, что хост-мастер
добавил информацию о новом компьютере в базу данных первичного сер-
390

Глава 11. Служба имен DNS
вера, после чего база данных на всех вторичных серверах автоматически
корректируется в течение интервала времени, указанного в качестве
параметра в SOA.
У нас довольно большая сеть, поэтому время от времени первичный
сервер оказывается перегруженным и резолверы вынуждены обращаться
к вторичному серверу. Если вторичный сервер к моменту запроса еще
не знает ничего о новом компьютере, его ответ будет отрицательным.
А когда первичный сервер хорошо себя «чувствует», то компьютер
будет доступен.
Авторитетная информация о зоне — это та информация, которая
хранится на диске первичного сервера. Однако из этого правила есть одно
исключение. На диске первичного сервера также хранится
информация о корневых серверах имен. Эти данные не являются
авторитетными. Кстати, периодически рекомендуется обновлять файл, содержащий
информацию о корневых серверах имен (это файл зоны подсказок).
Актуальную информацию о корневых серверах имен можно запросить
у любого корневого сервера.
Работа серверов имен
Рассмотрим процесс перевода имени abc.firm.com в IP-адрес (он
изображен на рис. 11.11).
Bliiiilll
1|||р^<Ж|Ш:
Штттт
>
1
<з
J
Сервер
имен
NS
Корневой
сервер имен
Авторитетный
сервер
для TLD com.
Авторитетный
сервер
для firm.com.
Рис. 11.11. Перевод имени домена abc.firm. com в 1Р~
391

TCP/IP и DNS в теории и на практике. Полное руководство
1. Резолвер формулирует запрос к серверу имен и ожидает ответ от
сервера. Если сервер имен может ответить, то посылает ответ
немедленно. Ответ сервер ищет в своей кэш-памяти (5). В ней находятся
авторитетные данные из баз данных диска, так же, как и
неавторитетные данные, полученные от других серверов. Если сервер не находит
ответ в кэш-памяти, то он связывается с другими серверами. Если
сервер имен не знает ответ, то он соединяется с корневым сервером
имен — вот почему каждый сервер имен должен знать IP-адрес
корневых серверов имен. Если ни один из корневых серверов имен не
доступен (например, в случае с закрытой локальной сетью или
потерей соединения с Интернетом), то после нескольких неудачных
попыток сервер отправляет клиенту отрицательный ответ.
2. Корневой сервер имен выясняет, какой сервер является
авторитетным для домена com (он находит соответствующую NS-запись в
своей базе), и возвращает нашему серверу IP-адрес сервера имен,
ответственного за домен com.
3. Наш сервер имен обращается к авторитетному серверу для домена
com, который выясняет, какой сервер отвечает за домен f irm. com, и
возвращает нашему серверу IP-адрес сервера имен домена f irm. com.
4. Наш сервер имен обращается к авторитетному серверу имен для
домена firm, com, который либо ответит на его запрос, либо нет (то
есть нет такого узла abc). Ответ авторитетного для данной зоны
сервера расценивается как авторитетный ответ. Результат
передается клиенту (1).
5. Информация, которую получит сервер, также будет сохранена в кэш.
Если какой-либо клиент снова запросит информацию об узле
abc . f irma. com, наш сервер сразу же возвратит ответ, но ответ не
будет помечен как авторитетный.
Сохраняя ответы в кэш-память, сервер не только экономит время и
деньги, но также очень помогает корневым серверам. Представляете, что
было бы, если бы ответы не сохранялись в кэш-памяти? Миллионы
серверов DNS со всего мира практически одновременно за каждым
запросом обращались бы к корневым серверам DNS...
Нужно также сказать, что такое рекурсивный запрос. Проще всего
объяснить это на примере. Клиент отправляет серверу рекурсивный запрос,
то есть требует конечный результат. Сервер обращается к корневому
серверу имен, затем к TLD-серверу, после — к серверу второго уровня
392

Глава 11. Служба имен DNS
и т. д. То, как он получит результат, клиента, которому нужен IP-адрес
запрошенного узла, не касается.
Сервер же отправляет нерекурсивные запросы: сначала он определяет
IP-адрес сервера TLD-домена (практически всегда есть в кэше), затем
IP-адрес сервера домена второго уровня, затем — третьего. И уже у
конечного сервера имен наш сервер запрашивает IP-адрес нужного узла.
То есть наш сервер не запрашивает конечный IP-адрес, а «подбирается»
к нему постепенно.
Для администрирования серверов имен полезна программа nslookup.
В качестве примера ее использования приведем следующий запрос:
$ nslookup
set norecurse
set nosearch
11.10. Forward-серверы
Forward-сервер — это еще один тип сервера имен. Разберемся, что он
собой представляет.
Как мы уже сказали, резолвер передает запрос серверу имен (клиент
посылает рекурсивный запрос и ожидает окончательный ответ). Если
сервер имен не может ответить, он посылает нерекурсивный запрос
к другому серверу. Затем соединяется с сервером, IP-адрес которого он
получил в результате прошлого запроса, и посылает этому серверу
нерекурсивный запрос. Таким образом сервер имен посылает много
пакетов в Интернет.
Если сеть компании соединена с Интернетом по медленной линии, то
только один ее DNS-сервер может загрузить всю линию своими
запросами. В таком случае нужно использовать Forward-серверы. Наш
локальный сервер посылает запрос Forward-серверу, находящемуся за
пределами нашей сети — в Интернете (обычно это сервер провайдера),
и помечает запрос как рекурсивный (то есть как будто бы мы — не
сервер, а обычный клиент).
Forward-сервер делает всю «грязную» работу за наш сервер, а ему
возвращает только результат — IP-адрес конечного компьютера.
Представляете, во сколько раз сокращается нагрузка на линию?
393

TCP/IP и DNS в теории и на практике. Полное руководство
Наш сервер ожидает окончательного ответа от Forward-сервера в
течение определенного времени. Если за это время он не получит ответ, то
сам свяжется с корневыми серверами как обычно (см. выше).
Forward-сервер также может работать как кэширующий сервер и быть
главным или подчиненным сервером для определенной зоны.
Клиент
Итерация
• после окончания времени
• если сервер имен не настроен как forward
1 Сервер
| имен
—1
Forward
и в
А
V
Ч*
Корневой
сервер имен
Авторитетный
сервер
для TLD com.
Авторитетный
сервер
для firm.com.
Рис. 11.12. Соединение локального сервера имен с Forward-се рве ром
Forward-серверы можно настраивать как в Unix (на базе BIND), так
и в Windows 2000/2003. Более подробно о настройке
Forward-серверов вы сможете прочитать в документации по BIND и по Windows
Server 2000/2003.

Глава 12 ПРОТОКОЛ DNS
ЗАПИСИ РЕСУРСОВ
ПРОТОКОЛ DNS
ОПЕРАЦИЯ DNS QUERY (ЗАПРОС)
ПРИМЕРЫ ОБЩЕНИЯ DNS-КЛИЕНТА
И DNS-CEPBEPA
TCP/IP и DNS в теории и на практике. Полное руководство

12.1. Записи ресурсов
Информация о доменных именах и соответствующих им IP-адресах,
распространяемая вместе с другой информацией по протоколу DNS, хранится
в памяти DNS-серверов в виде записей ресурсов RR (Resource Records).
Сервер имен (он же DNS-сервер) загружает данные в память
несколькими способами. Авторитетные данные он читает из файлов, сохраненных
на диске, или получает с помощью запроса на трансфер (передачу) зоны
от другого сервера. Неавторитетные данные могут быть получены от
других серверов DNS с помощью обычных DNS-запросов (когда сервер
сам не может обработать запрос).
Если DNS-клиенту нужно получить информацию от DNS-сервера, он
запрашивает у сервера имен ресурсную запись согласно своим
требованиям. Например, для преобразования доменного имени в IP-адрес
клиенту нужно запросить ресурсную запись типа А.
Структура ресурсной записи изображена на рис. 12.1.
• NAME — доменное имя.
• TYPE — тип данной ресурсной записи. Этот тип характеризует
содержимое описателя ресурса. Например, тип А говорит о том, что
содержащий его описатель содержит IP-адрес. Тип MX означает, что
описатель ресурса содержит имя почтового сервера. Описатель
ресурса типа HINFO содержит информацию о хосте и т. п.
• CLASS — класс данной ресурсной записи. С помощью этого поля
ресурсной записи ставится в соответствие определенный класс
протоколов. Для Интернета используется значение IN
• TTL — время жизни. 32-битовое число определяет, сколько времени
данная запись должна храниться в кэш-памяти сервера. Когда задан-

Глава 12. Протокол DNS
Общий формат
Имя
переменная длина
Тип
2Б
Класс
2Б
TTL
4Б
RDLEN-
QTH
Данные (RDATA)
переменная длина
2Б
Ресурсная запись типа А:
Ресурсная запись типа ТХТ:
Ресурсные записи типов NS, CNAME и PTR:
Ресурсная запись типа MX:
IP-адрес
4Б
Текстовая строка
переменная длина
Доменное имя
переменная длина
Приоритет
Доменное имя
переменная длина
2Б
Рис. 12.1. Структура ресурсной записи
ное время истекает, запись считается недопустимой. Если TTL = О,
запись в кэш-памяти не сохраняется.
• RDLENGTH - длина поля RDATA (16 битов).
• RDATA — данные, которые несет в себе запись. Обычно это строка
переменной длины. Формат этого поля зависит от типа и класса записи.
Данные по сети передаются в двоичном виде, то есть они не прозрачны
для пользователя. Если же пользователю нужно просмотреть ресурсную
запись в текстовом виде, например, чтобы вставить в файл зоны сервера
или другой текстовый файл, достаточно преобразовать двоичное
представление в текстовую форму, разделяя при этом отдельные поля
пробелами или символами табуляции (или комбинацией этих символов).
Отдельные строки в имени домена разделяются точками.
Часто используемые ресурсные записи представлены в таблице 12.1.
Таблица 12.1. Некоторые ресурсные записи (RR)
Тип
А
NS
CNAME
Имя
Адрес узла (A host address)
Авторитетный сервер имен
(Authoritative name server)
Каноническое имя или
псевдоним (Canonical name
for an alias)
Значение поля RDATA
32-битовый IP-адрес
Доменное имя сервера имен (DNS), являющегося
авторитетным сервером для определенного домена
Доменное имя-псевдоним
397

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 12.1
Тип
SOA
PTR
HINFO
MX
TXT
| АААА
WKS
SIG
KEY
Имя
Начало полномочий.
(Start Qf Authority)
Указатель доменного имени
(Domain name pointer)
Информация об узле
(Host information)
Обмен почтой
(Mail exchange)
Текстовая строка
(Text string)
1Ру6-адрес
Описание общеизвестных
сервисов (Well known service
description)
Подпись безопасности
(Security signature)
Ключ безопасности
(Security key)
Значение поля RDATA
Каждый файл данных зоны должен содержать эту запись,
состоящую из 7-ми полей
Доменное имя. Данная запись используется для
обратного разрешения имен, то есть для преобразования
IP-адреса в имя
Состоит из двух строк — HW (описание аппаратного
обеспечения и SW (описание программного обеспечения)
Состоит из двух полей. Первое — 16-битовое поле,
содержащее приоритет почтового сервера, второе поле
— это доменное имя сервера
Просто текстовая строка
128-битовый IP-адрес (IPv6)
Описание общеизвестных сервисов протоколов TCP и
UDR Состоит из трех частей: 32-битовый адрес, номер
протокола и номер порта
Описание записи, используется для аутентификации в
Secure DNS (безопасный DNS)
Общедоступный ключ (public key) зоны, используемый как
подпись при аутентификации
12.2. Протокол DNS
Протокол DNS поддерживает несколько типов операций. Наиболее
часто используемой является операция DNS-запроса — DNS QUERY. Она
позволяет получить одну или несколько записей из базы данных DNS.
В текущей главе будет рассмотрена именно эта операция. Другие
операции, например, DNS NOTIFY или DNS UPDATE, будут рассмотрены
в главе 13.
Протокол DNS основан на запросах и ответах. Клиент посылает
серверу свой запрос, а сервер отвечает ему. Для большей компактности
DNS-пакетов используется их сжатие, что немного усложняет
ситуацию, но в общем случае все работает как описано выше: запрос — и
ответ на него.
Протокол DNS является протоколом прикладного уровня, поэтому сам
не занимается доставкой своих пакетов. Данная задача возложена на один
из транспортных протоколов — TCP или UDP. Каждый из этих
протоколов может использоваться как для отправки DNS-запросов (со стороны
клиента), так и для отправки DNS-ответов (со стороны сервера).
398

Глава 12. Протокол DNS
Для осуществления запросов обычно предпочитается протокол UDP.
Ответ тоже пересылается клиенту по UDP. Если ответ превышает 512 б,
то устанавливается флаг усечения (ТС), и ответ в сокращенной форме
пересылается клиенту. Для получения всего ответа используется
протокол TCP.
Для передачи зоны (трансфера зоны) между первичным и вторичным
серверами имен всегда используется протокол TCP. Сервер имен
ожидает подключения клиентов по портам 53/udp и 53/tcp.
Примечание.
Некоторые реализации UDP не заполняют поле контрольной суммы. Это
полезно для NFS, но очень опасно для DNS, особенно, если для связи
сервера и клиента используется протокол SLIP. Перед установкой
сервера имен убедитесь, что ваша система заполняет поле контрольной суммы
в UDP-пакете.
12.3. Операция DNS QUERY (запрос)
Операция DNS QUERY состоит из самого запроса и его неотъемлемой
части — ответа. Запрос содержит запрос записи ресурсов (или
нескольких записей). Ответ содержит ресурсную запись (или несколько
записей) или же опровержение запроса. Ресурсная запись в большинстве
случаев содержит ответ сервера. Но она также может помочь клиенту
правильно сформулировать запрос, чтобы достичь нужной ему цели.
12.3.1. Формат пакета DNS-запроса
Формат пакета одинаков для запроса и для ответа (см. рис. 12.2). Пакет
может состоять максимум из пяти секций. Каждый пакет начинается
секцией ЗАГОЛОВОК (HEADER).
Термин «запрос» нужно понимать в двух смыслах:
• Операция DNS QUERY. Базовая операция протокола DNS: поиск
нужной ресурсной записи в базе данных DNS. Другие операции
будут рассмотрены в главе 13.
• Операция DNS QUERY всегда состоит из запроса (отправляется
клиентом) и ответа (отправляется сервером клиенту). Клиентом
399

TCP/IP и DNS в теории и на практике. Полное руководство
может быть резолвер (программа операционной системы,
разрешающая доменные имена) или другой сервер имен, не способный
самостоятельно справиться с запросом. Резолвер обычно помечает свой
запрос специальным тегом, обозначая таким способом рекурсивный
запрос, то есть он рассчитывает получить ответ от сервера. Если же
запрос был послан другим сервером имен, то устанавливается
другой тег — тег интерактивного запроса.
12.3.2. Заголовок пакета запроса DNS query
Заголовок пакета обязателен как для запроса, так и для ответа. Первые
два байта (16 битов) заголовка содержат идентификатор запроса (ID).
Идентификатор запроса первоначально генерируется клиентом и
копируется в ответ сервера. Идентификатор запроса используется, чтобы
согласовать запрос с ответом. С помощью техники идентификаторов
клиент может посылать серверу несколько запросов, не дожидаясь от
него ответа на предыдущие запросы.
ЗАГОЛОВОК
ЗАПРОС
ОТВЕТ
АВТОРИТЕТНЫЕ СЕРВЕРЫ
ДОПОЛНИТЕЛЬНО
0
Q
R
8
15 бит
1
ID
OPCODE
А
А
т
С
R
D
R
А
Z
RCODE
QDCOUNT
(кол-во записей в запросе)
ANCOUNT
(кол-во записей в ответе)
NSCOUNT
(кол-во авторитетных серверов)
ARCOUNT
(кол-во дополнительных рее. записей)
Рис. 12.2. Формат пакета DNS Query (запрос DNS)
Следующие два байта заголовка содержат управляющие биты. Значение
этих служебных битов представлено в таблице 12.2.
400

Глава 12. Протокол DNS
Следующие четыре двухбайтовых поля в заголовке содержат число
записей, содержащихся в отдельных секциях заголовка:
• QDCOUNT — определяет число записей в запросе.
• ANCOUNT — определяет число записей в ответе.
• NSCOUNT — определяет число записей в секции, содержащей
ссылки на авторитетные серверы имен.
• ARCOUNT — определяет число записей в секции, содержащей
дополнительную информацию.
Таблица 12.2. Предназначение отдельных управляющих битов заголовка DNS-пакета
Поле
QR
Opcode
АА
ТС
| RD
| RA
Z
Rcode
Кол-во
битов
1
4
1
1
1
1
3
4
Значение
0 — данное сообщение является запросом
1 — данное сообщение является ответом
Тип запроса/ответа (одинаковы для запроса и для ответа):
0 — стандартный запрос (QUERY)
1 — инверсный (обратный) запрос (IQUERY)
2 — запрос состояния (STATUS)
4 — запрос предупреждения (NOTIFY)
5 — запрос обновления (UPDATE)
0 — неавторитетный ответ
1 — авторитетный ответ
1 — ответ был «урезан» до 512 Б. Если нужно получить полный ответ, запрос
должен быть послан снова, но уже по протоколу TCP
1 — если требуется реверсивная трансляция (для запросов)
1 — если реверсивная трансляция разрешена сервером (для ответов)
Зарезервировано для будущего использования
Код результата (для ответа):
0 — Нет ошибки (Noerror)
1 — Ошибка формата, запрос не.может быть интерпретирован сервером
(FormErr)
2 — Сервер не может ответить (Sen/Fail)
3 — Запрашиваемое имя не существует (то есть нет такого домена),
данный ответ может быть произведен только авторитетными серверами
(NXDomain)
4 — Тип запроса не поддерживается (Notlmplemented)
5 — Сервер запретил запрос, например, из соображений безопасности (Query
Refused)
Рассмотрим пример «перехваченного» в сети DNS-пакета в листинге 12.1.
401

TCP/IP и DNS в теории и на практике. Полное руководство
Листинг 12.1. «Перехваченный» в сети DNS-пакет
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0XF126; Proto = UDP; Len: 253
+ UDP: Src Port:DNS, (53); Dst Port: Unknown (1143) ;Length=233 (0xE9)
ENS:Qx3:Std Qry Resp. for snmpO.pvt.net. of type Host Addr on class ШЕТ addr.
DNS: Query Identifier = 3 (0x3)
ENS: ШЗ Flags = Response, C£Code - Std Qry, AA RD RA Bits Set, RCode - No error
DNS: 1 = Response
DNS : . 0000 = Standard Query
DNS: 1 = Server authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 1 = Recursive queries supported by server
DNS : 000 .... = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 1 (0x1)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 5 (0x5)
ENS: Question Section: snmp0.pvt.net. of type Host Addr on class ШЕГ addr.
DNS: Question Name: snmp0.pvt.net.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
+ ENS: Answer section: snmp0.pvt.net. of type Host Addr on class ШЕТ addr.
+ DNS: Authority Section: pvt.net. of type Auth. NS on class
INET addr.(5 records present)
ENS: Additional Records Section: ns.pvt.net. of type Host A3dr on class ШЕГ
+ ENS: Resource Record: ns.pvt.net. of type Host Addr on class ШЕЛ? addr.
+ ENS: Resource Record: nsl.pvt.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: snmp0.pvt.net. of type Host A3dr on class ШЕГ addr.
+ ENS: Resource Record: ns0.pipex.net. of type Host Addr on class ШЕТ addr.
+ ENS: Resource Record: nsl.pipex.net. of type Host Addr on class ШЕГ addr.
12.3.3. Секция вопроса
В большинстве случаев пакет DNS-запроса (DNS query) содержит
только одну секцию — секцию для одного вопроса к серверу (QDCOUNT= 1).
Секция вопроса состоит из трех полей:
402

Глава 12. Протокол DNS
• QNAME — содержит доменное имя. Однако в пакете DNS в
качестве разделителя вытсупает не точка, а байт, содержащий длину
фрагмента доменного имени до следующей точки. В конце QNAME
ставится нуль. Рассмотрим небольшой пример: содержимое этого поля
для доменного имени info.pvt.net будет представлено в виде
04u;info031f.pvt03l6net0016.
• QTYPE — определяет тип запроса, то есть тип запрашиваемой
ресурсной записи. Наиболее часто используемые типы запросов
представлены в таблице 12.3.
Таблица 12.3. Значения типов запросов
Тип
I A
NS
CNAME
SOA
WKS
PTR
I HINFO
MX
TXT
SIG
KEY
NXT
AAAA
CERT
A6
AXFR
IXFR
*
Значение
(в десятичной форме)
1
2
5
6
11
12
13
15
16
24
25
30
28
37
38
252
251
255
Описание
1Ру4-адрес
Авторитетный сервер имен
Каноническое имя (псевдоним)
Начало полномочий
Описание наиболее известных сервисов
Указатель доменного имени
Информация об узле
Обмен почтой
Текстовые строки
Для подписи безопасности
Для ключа безопасности
Следующий домен
IPv6-ampec
CERT (см. раздел 13.8)
1Ру6-адрес
Передача (трансфер) всей зоны
Инкрементный трансфер
Все записи
• QCLASS — класс запроса (см. таблицу 12.4).
403

TCP/IP и DNS в теории и на практике. Полное руководство
Таблица 12.4. Значения классов запроса
Числовое значение
(в десятичном виде)
1
3
4
255
Подпись
IN — Internet
CH — Chaos
HS — Hesiod
* - все классы
Пример DNS-пакета, найденного в сети, представлен в листинге 12.2.
Листинг 12.2. Пример DNS-пакета
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0xF126; Proto = UDP; Len: 253
UDP: Src Port: DNS, (53); Dst Port: Unknown (1143); Length = 233 (0xE9)
ENS: 0x3:Std Qry Resp. for snrtp0.pvt.net. of type Host Addr on class INET addr.
DNS: Query Identifier = 3 (0x3)
+ ENS: ENS Flags = Response, CpCcde - Std Qry, AA RD RA Bits Set, RCode - No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 1 (0x1)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 5 (0x5)
ENS: Question Section: snmp0.pvt.net. of type Host Addr on class INET addr.
DNS: Question Name: snmp0.pvt.net.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
+ ENS: Answer section: snmp0.pvt.net. of type Host Addr on class INET addr.
+ DNS: Authority Section: pvt.net. of type Auth. NS on class INET
addr.(5 records present)
LNS: Additional Records Section: ns.pvt.net. of type Host Addr on class ШЕГ....
+ ENS: Resource Record: ns.pvt.net. of type Host Addr on class INET addr.
+ LNS: Resource Record: nsl.pvt.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: snrrp0.pvt.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: ns0.pipex.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: nsl.pipex.net. of type Host Addr on class MET addr.

Глава 12. Протокол DNS
12.3.4. Секция ответа, авторитетные серверы
и дополнительная информация
Кроме секции заголовка и секции повтора вопроса (для синхронизации
запроса с ответом), пакеты ответа содержат еще три секции: секцию
ответа, секцию авторитетных серверов и секцию дополнительной
информации.
Ответ сервера помещается в секцию ответа. Секция авторитетных
серверов имен содержит имена серверов имен в NS (тип ресурсной
записи). Секция дополнительной информации обычно содержит IP-адреса
авторитетных серверов имен, то есть серверов, указанных в предыдущей
секции.
Записи в этих секциях используют общий формат ресурсной записи (RR):
• NAME — доменное имя, формат аналогичен формату поля QNAME
секции вопроса.
• TYPE — тип записи, формат аналогичен формату поля QTYPE
секции вопроса.
• CLASS — класс записи.
• TTL — время жизни ресурсной записи, то есть количество времени,
которое ответ будет храниться в кэш-памяти сервера.
• RDLENGTH - длина поля RDATA.
• RDATA — правая сторона ресурсной записи (IP-адрес или доменное
имя).
Рассмотрим пример перехваченного DNS-пакета, который представлен
в листинге 12.3.
Листинг 12.3. Пример перехваченного DNS-пакета
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0xFl26; Proto = UDP; Len: 253
UDP: Src Port: DNS, (53); Dst Port: Unknown (1143); Length = 233 (0xE9)
DNS: 0x3:Std Qry Resp. for snmpO.pvt.net. of type Host Addr on class
INET addr.
DNS: Query Identifier = 3 (0x3)
+ ENS: ENS Flags = Response, CpCode - Std Qry, AA RD RA Bits Set, RCode -
No error
405

TCP/IP и DNS в теории и на практике. Полное руководство
DNS: Question Entry Count = 1 (Oxl)
DNS: Answer Entry Count = 1 (0x1)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 5 (0x5)
+ DNS: Question Section: snmpO.pvt.net. of type Host Addr on class
INET addr.
DNS: Answer section: snmp0.pvt.net. of type Host Addr on class
INET addr.
DNS: Resource Name: snmpO.pvt.net.
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 86400 (0x15180)
DNS: Resource Data Length =* 4 (0x4)
DNS: IP address = 194.149.103.34
DNS: Authority Section: pvt.net. of type Auth. NS on class INET addr.
(5 records present)
+ DNS: Resource Record: pvt.net. of type Auth. NS on class INET addr.
+ DNS: Resource Record: pvt.net. of type Auth. NS on class INET addr.
+ DNS: Resource Record: pvt.net. of type Auth. NS on class INET addr.
+ DNS: Resource Record: pvt.net. of type Auth. NS on class INET addr.
+ DNS: Resource Record: pvt.net. of type Auth. NS on class INET addr.
ENS: Additional Records Section: ns.pvt.net. of type Host Addr on class 1ШГ
+ ENS: Resource Record: ns.pvt.net. of type Host Addr on class 1ШГ addr.
+ ENS: Resource Record: nsl.pvt.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: snnpO.pvt.net. of type Host Addr on class INET addr.
+ ENS: Resource Record: ns0.pipex.net. of type Host Addr on class 1ШГ addr.
+ ENS: Resource Record: nsl.pipex.net. of type Host Addr on class ШЕГГ addr.
Секция ответа выделена жирным шрифтом, а дополнительная
информация — курсивом.
12.3.5. Сжатие
Для уменьшения размера DNS-пакетов используется сжатие. В DNS-
пакете часто повторяются различные доменные имена. Сжатие
заключается в том, что за определенным доменным именем (при его первом
появлении в пакете) закрепляется определенный флаг, который
впоследствии заменяет имя (используется вместо него).
406

Глава 12. Протокол DNS
Как уже было сказано, в DNS-пакетах имена доменов разделяются не
точками, а числами, задающими длину имени домена.
Число-разделитель занимает один байт. Каждая часть доменного имени может
содержать до 63-х символов, в двоичном представлении — это 00111111
символов.
Если значение этого байта-разделителя равно 192 (или больше), то это
означает, что вместо доменного имени будет указан флажок, его
заменяющий. Данный флаг занимает 16 битов. Первые два бита флага содержат
единицы, что позволяет отличить флаг от числа-разделителя (там
первые два бита — нули). Оставшиеся биты задают позицию первого байта
доменного имени (отсчет начинается с начала DNS-пакета), на которое
указывает флаг. 0 -начало пакета — это первый байт пакета, то есть поле
ID-заголовка пакета.
Примечание.
Почему именно 192? Чтобы различать число-разделитель и флаг
доменного имени. Максимальное значение разделителя 63 = 0011 1111,
то есть в любом случае первые два бита будут равны 00. Первые два
бита флага всегда равны 11. Двоичное значение 1100 0000
соответствует значению 192.
DNS-пакет
IP-заголовок
UDP или TCP
заголовок
snmpO.pvt.net
Ethernet
CRC
п
< >
вместо snmp0.pvt.net теперь
просто указывается п
Рис. 12.3. Сжатие DNS-пакета
Рассмотрим в качестве примера DNS-пакет со сжатым заголовком,
найденный в сети (листинг 12.4).
Листинг 12.4. DNS-пакет со сжатым заголовком
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xF126; Proto = UDP; Len: 253
+ UDP: Src Port: DNS, (53); Dst Port: Unknown (1143); Length = 233 (0xE9)
ENS: 0x3:Std Qry Resp. for snmp0.pvt.net. of type Host Addr on class ШЕГ addr.
407

TCP/IP и DNS в теории и на практике. Полное руководство
DNS: Query Identifier = 3 (0x3)
+ DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode -
No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 1 (0x1)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 5 (0x5)
ENS: Question Section: snmp0.pvt.net. of type Host Addr on class ШЕГ addr.
DNS: Question Name: snmp0.pvt.net.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
ENS: Answer section: snmp0.pvt.net. of type Host Addr on class ШЕГ addr.
DNS: Resource Name: snmp0.pvt.net.
DNS: Resource Type = Host Address
DNS: Resource Class = Internet address class
DNS: Time To Live = 86400 (0x15180)
DNS: Resource Data Length = 4 (0x4)
DNS: IP address = 194.149.103.34
+ ENS: Authority Section: pvt.net. of type Auth. NS on class INET addr.
(5 records present)
ENS: Additional Records Section: ns.pvt.net. of type Host Addr on class ШЕГ
+ ENS: Resource Record: ns.pvt.net. of type Host Addr on class INET addr.
+ DSB: Resource Record: nsl.pvt.net. of type Host Addr on class ШЕГ addr.
+ ENS: Resource Record: snmp0.pvt.net. of type Host Addr on class ШЕГ addr.
+ ENS: Resource Record: ns0.pipex.net. of type Host Addr on class ШЕТ addr.
+ ENS: Resource Record: nsl.pipex.net. of type Host Addr on class ШЕГ addr.
00000: 00 20 AF F9 2F A0 00 60 3E ID 90 00 08 00 45 00 . ../..4 E.
00010: 00 FD Fl 26 00 00 ID 11 54 C7 C2 95 69 12 C2 95 . . .& T...i...
00020: 68 C5 00 35 04 77 00 E9 8E 41 00 03 85 80 00 01 h..5.w...A
00030: 00 01 00 05 00 05 05 73 6E 6D 70 30 03 70 76 74 snmpO.pvt
00040: 03 6E 65 74 00 00 01 00 01 CO ОС 00 01 00 01 00 .net
00050: 01 51 80 00 04 C2 95 67 22 03 70 76 74 03 6E 65 .Q g".pvt.ne
00060: 74 00 00 02 00 01 00 01 51 80 00 05 02 6E 73 CO t Q ns.
00070: 2F CO 2F 00 02 00 01 00 01 51 80 00 06 03 6E 73 /./ Q ns
00080: 31 CO 2F CO 2F 00 02 00 01 00 01 51 80 00 02 CO l.l.l Q
00090: 0C CO 2F 00 02 00 01 00 01 51 80 00 0C 03 6E 73 ../ Q ns
OOOAO: 30 05 70 69 70 65 78 CO 33 CO 2F 00 02 00 01 00 O.pipex.3./
000B0: 01 51 80 00 06 03 6E 73 31 CO 77 CO 42 00 01 00 .Q nsl.w.B...
000C0: 01 00 01 51 80 00 04 C2 95 69 12 CO 53 00 01 00 . . .Q i..S...
408

Глава 12. Протокол DNS
000D0: 01 00 01 51 80 00 04 С2 95 67 С9 СО ОС 00 01 00 . . .Q g
000Е0: 01 00 01 51 80 00 04 С2 95 67 22 СО 73 00 01 00 . . .Q g".s...
000F0: 01 00 00 5Е 23 00 04 9Е 2В 80 08 СО 8В 00 01 00 .../ч#... +
00100: 01 00 00 5Е 24 00 04 9Е 2В СО ..."$... + ..
Значение флага сжатия доменного имени (назовем его так) — С00С1(.=
11000000000001112 Вычислим номер первого байта доменного имени,
на которое указывает флаг, — это 000000000001112 = 12ш Учитывая тот
факт, что нумерация начинается с 0, это будет 13-й байт DNS-пакета.
Но нужно помнить, что это 13-й байт DNS-пакета, а не всего пакета,
полученного нами по сети. DNS-пакет начинается с 11-го байта в третьей
строке (00 03 85 80 ...). Нужные нам байты (с 13-го) подчеркнуты.
Понятно, что этот флаг указывает на строку pvt .net.
12.3.6. Инверсный (обратный) запрос
Инверсные (обратные) запросы не нужно путать с реверсивными. У
обратных запросов IP-адрес обратно преобразовывается в доменное имя;
они основаны на записи типа А. Реверсивное разрешение имени
основано на ресурсной записи типа PTR. Не все серверы имен поддерживают
инверсные запросы (определены в RFC 1035), которые считаются
устаревшими.
12.3.7. Методы передачи ресурсных записей в DNS-пакете
Один DNS-пакет может содержать одну или несколько ресурсных
записей. Форматы пакетов с одним ответом и множеством ответов
отличаются. Поскольку последний формат (с множеством ответов) более
эффективен, он поддерживается 8-ой версией BIND (и более старшими
версиями).
12.4. Примеры общения DNS-клиента
и DNS-сервера
Рассмотрим несколько примеров «общения» DNS-клиента и
DNS-сервера. Обратите внимание на заголовки отдельных пакетов.
409

TCP/IP и DNS в теории и на практике. Полное руководство
Пример: запрос IP-адреса несуществующего доменного имени
и ответ сервера
Попробуем разрешить какое-нибудь несуществующее доменное имя,
скажем, aaa.abc.cz. Для этого мы будем использовать программу
nslookup. В результате мы получим два пакета, переданных по сети, —
запрос (листинг 12.5) и ответ (листинг 12.6).
# nslookup
Default Server: localhost
Address: 127.0.0.1
> aaa.abc.cz
Server: localhost
Address: 127.0.0.1
*** localhost can't find aaa.abc.cz:
>
Non-existent host/domain
Листинг 12.5. DNS-запрос
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x3186; Proto = UDP; Len: 56
UDP: Src Port: Unknown, (1258); Dst Port: DNS (53); Length = 36 (0x24)
DNS: 0x14:Std Qry for aaa.abc.cz. of type Host Addr on class INET addr.
DNS: Query Identifier = 20 (0x14)
ENS: DNS Flags = Query, CpCode - Std Qry, RD Bits Set, RCode - No error
DNS: 0 = Query
DNS : . 0000 = Standard Query
DNS: 0 = Server not authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 0 = No recursive queries
DNS : 000 .... = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
DNS: Question Section: aaa.abc.cz. of type Host Addr on class INET addr.
DNS
DNS
DNS
Question Name: aaa.abc.cz.
Question Type = Host Address
Question Class = Internet address class
410

Глава 12. Протокол DNS
Листинг 12.6. DNS-otbet
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x9D43; Proto = UDP; Len: 56
+ UDP: Src Port: DNS, (53); Dst Port: Unknown (1258); Length = 36 (0x24)
DNS: 0x14:Std Qry Resp. : Name does not exist
DNS: Query Identifier = 20 (0x14)
DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode -
Name does not exist
DNS: 1 = Response
DNS : . 0000 = Standard Query
DNS: 1 = Server authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 1 = Recursive queries supported by server
DNS : 000 .... = Reserved
DNS: 0011 = Name does not exist
Question Entry Count = 1 (0x1)
Answer Entry Count = 0 (0x0)
Name Server Count = 0 (0x0)
Additional Records Count = 0 (0x0)
DNS
DNS
DNS
Question Name: aaa.abc.cz.
Question Type = Host Address
Question Class = Internet address class
Пример коммуникации с корневым сервером
Я использовал программу nslookup для запроса рекурсивного
разрешения (преобразования) доменного имени www. lackf ix. cz. Причем
для запроса я использовал не обычный, а корневой сервер DNS.
Корневые сервера DNS не выполняют рекурсивного преобразования, поэтому
в качестве результата я получил имена и IP-адреса авторитетных
серверов имен для TLD. cz.
# nslookup
Default Server: localhost
Address: 127.0.0.1
> server a.root-servers.net
411

TCP/IP и DNS в теории и на практике. Полное руководство
Default Server: a.root-servers.net
Address: 198.41.0.4
> set recurse
> www.lackfix.cz
Server: a.root-servers.net
Address: 198.41.0.4
Name: www.lackfix.cz
Served by:
- NS.CESNET.CZ
192.108.150.10
CZ
- NS.EU.NET
192.16.202.11
CZ
- SUNIC.SUNET.SE
192.36.125.2, 192.36.148.18
CZ
- NS.UU.NET
137.39.1.3
CZ
- SPARKY.ARL.MIL
128.63.58.18
CZ
- NS.EUNET.CZ
193.85.1.12
CZ
Листинг 12.7. DNS-запрос
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0xlE88; Proto = UDP; Len: 60 IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14) + ip: Service Type = 0 (0x0)
IP: Total Length = 60 (0x3C) IP: Identification = 7816 (0xlE88)
+ IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram
IP: Checksum = 0x2AAl IP: Source Address = 194.149.104.197
412

Глава 12. Протокол DNS
IP: Destination Address = 198.41.0.4
IP: Data: Number of data bytes remaining = 40 (0x0028)twork Monitor
UDP: Src Port: Unknown, (1264); Dst Port: DNS (53); Length = 40 (0x28)
ENS: 0xlA:Std Qry for www.lackfix.cz. of type Host Addr on class ШЕГ addr.
DNS: Query Identifier = 26 (OxlA)
DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
0
.0000.
.0.
.000.
DNS
DNS
DNS
DNS
0000
Question Entry Count = 1 (0x1)
Answer Entry Count = 0 (0x0)
Name Server Count = 0 (0x0)
Additional Records Count = 0 (0x0
= Query
= Standard Query
= Server not authority for domain
= Message complete
= Recursive query desired
= No recursive queries
= Reserved
= No error
ENS: Question Section: w^w.lackfix.cz. of type Host A3dr on class ШЕГ addr.
DNS
DNS
DNS
Question Name: www.lackfix.cz.
Question Type = Host Address
Question Class = Internet address class
Листинг 12.8. DNS-otbet
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP:
IP: ID = 0x8DE8; Proto = UDP; Len: 320
DOD Internet Protocol
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
Version = 4 (0x4)
Header Length = 20 (0x14)
Service Type = 0 (0x0)
Total Length = 320 (0x140)
Identification = 36328 (0x8DE8)
Flags Summary = 2 (0x2)
Fragment Offset = 0 (0x0) bytes
Time to Live = 245 (0xF5)
Protocol = UDP — User Datagram
Checksum = 0x053C
Source Address = 198.41.0.4
Destination Address = 194.149.104.197
413

TCP/IP и DNS в теории и на практике. Полное руководство
IP: Data: Number of data bytes remaining = 300 (0x012C)
+ UDP: Src Port: ENS, (53); Dst Port: Unknown (1264); Length = 300 (0xl2C)
DNS: 0xlA:Std Qry Resp. Auth. NS is CZ. of type Auth. NS on class INET addr.
DNS: Query Identifier = 26 (OxlA)
ENS: ENS Flags = Response, CpCode - Std Qry, RD Bits Set, RCode - No error
DNS: 1 = Response
DNS: . 0000 = Standard Query
DNS: - . . . .0 = Server not authority for domain
DNS: 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 0 = No recursive queries
DNS : 000 . . . . = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 6 (0x6)
DNS: Additional Records Count = 7 (0x7)
ENS: Question Section: www.lackfix.cz. of type Host Addr on class INET addr.
DNS: Question Name: www.lackfix.cz.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
DNS: Authority Section:
(6 records present)
CZ. of type Auth. NS on class INET addr.
+ DNS
+ DNS
+ DNS
+ DNS
+ DNS
+ DNS
Resource Record:
Resource Record:
Resource Record:
Resource Record:
Resource Record:
NS on class INET addr.
NS on class INET addr.
NS on class INET addr.
NS on class INET addr.
NS on class INET addr.
CZ. of type Auth.
CZ. of type Auth.
CZ. of type Auth.
CZ. of type Auth.
CZ. of type Auth.
Resource Record: CZ. of type Auth. NS on class INET addr.
ENS: Additional Records Section: NS.CESNET.CZ. of type Host Ackli: on class ШЕГ
+ ENS: Resource Record: NS.CESNET.CZ. of type Host Addr on class INET addr.
+ DNS: Resource Record: NS.EU.NET. of type Host Addr on class INET addr.
+ ENS: Resource Record: SUNIC.SUNET.SE. of type Host Addr on class ШЕГ addr.
+ ENS: Resource Record: SUNIC.SUNET.SE. of type Host Addr on class INET addr.
+ DNS: Resource Record: NS.UU.NET. of type Host Addr on class INET addr.
+ ENS: Resource Record: SPARKV.ARL.MIL. of type Host Addr on class ШЕГ ac<3r.
+ ENS: Resource Record: NS.EUNET.CZ. of type Host Addr on class INET addr.

Глава 12. Протокол DNS
Пример: использование DNS-cepbepa
smudla.svamberk•cz
Давайте попробуем отправить запрос из предыдущего примера
обычному серверу для домена . с z , а не корневому серверу. Для этого будем
опять использовать программу nslookup. Чтобы пример был более
интересным, я включил уровень отладки.
Разница между выводом nslookup и содержимым DNS-пакета очевидна.
В результате этого запроса я получил IP-адрес узла www. lackf ix. cz.
> server smudla.svamberk.cz
Default Server: smudla.svamberk.cz
Address: 194.196.119.33
> set debug
> www.lackfix.cz
Server: smudla.svamberk.cz
Address: 194.196.119.33
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
www.lackfix.cz.pvtnet.cz, type = A, class = IN
Got answer:
HEADER:
opcode = QUERY, id = 5, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 0, additional = 0
QUESTIONS:
www.lackfix.cz, type = A, class = IN
ANSWERS:
-> www.lackfix.cz
canonical name = wwwvirt.pvtnet.cz
415

TCP/IP и DNS в теории и на практике. Полное руководство
ttl = 85847 (23 hours 50 mins 47 sees)
-> wwwvirt.pvtnet.cz
internet address = 194.149.101.35
ttl = 85847 (23 hours 50 mins 47 sees)
Non-authoritative answer:
Name: wwwvirt.pvtnet.cz
Address: 194.149.101.35
Aliases: www.lackfix.cz
>
Обратите внимание: клиент получил два ответа. Первый — это отказ
(код ошибки rcode=NXDOMAIN). Почему же произошла ошибка?
Посмотрим. Сервер пытался разрешить имя www. lackf ix. cz .pvtnet. cz,
а не запрошенное нами имя www. lackf ix. cz. Это произошло потому,
что в конце доменного имени была пропущена точка, и сервер добавил
к имени доменное имя, установленное при конфигурировании резолве-
ра, то есть pvtnet. cz. Поэтому нужно при разрешении доменных имен
в их IP-адреса всегда указывать завершающую точку.
Листинг 12.9. DNS-запрос
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x7B8D; Proto = UDP; Len: 60
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
+ IP: Service Type = 0 (0x0)
IP: Total Length = 60 (ОхЗС)
IP: Identification = 31629 (0x7B8D)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 128 (0x80)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x59E3
IP: Source Address = 194.149.104.197
IP: Destination Address = 194.196.119.33
IP: Data: Number of data bytes remaining = 40 (0x0028)
UDP: Src Port: Unknown, (1270); Dst Port: DNS (53); Length = 40 (0x28)
416

Глава 12. Протокол DNS
DNS: 0x5:Std Qry for www.lackfix.cz. of type Host Addr on class INET addr.
DNS: Query Identifier = 5 (0x5)
DNS: DNS Flags = Query, QpCode - Std Qry, RD Bits Set, RCode - No error
DNS: 0 = Query
DNS : . 0000 = Standard Query
DNS: 0 = Server not authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 0 = No recursive queries
DNS : 000 . . . . = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
ENS: Question Section: www.lackfix.cz. of type Host Addr on class INET addr.
DNS
DNS
DNS
Question Name: www.lackfix.cz.
Question Type = Host Address
Question Class = Internet address class
Листинг 12.10. DNS-otbet (только второй ответ)
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0xA90D; Proto = UDP; Len: 105
IP: Version = 4 (0x4)
IP: Header Length = 20 (0x14)
+ IP: Service Type = 0 (0x0)
IP: Total Length = 105 (0x69)
IP: Identification = 43277 (0xA90D)
+ IP: Flags Summary = 0 (0x0)
IP: Fragment Offset = 0 (0x0) bytes
IP: Time to Live = 122 (0x7A)
IP: Protocol = UDP - User Datagram
IP: Checksum = 0x3236
IP: Source Address = 194.196.119.33
IP: Destination Address = 194.149.104.197
IP: Data: Number of data bytes remaining = 85 (0x0055)
UDP: Src Port: DNS, (53); Dst Port: Unknown (1270); Length = 85 (0x55)
DNS: 0x5:Std Qry Resp. for www.lackfix.cz. of type Canonical name
14 Зак. 518
417

TCP/IP и DNS в теории и на практике. Полное руководство
on class INET addr.
DNS: Query Identifier = 5 (0x5)
DNS: DNS Flags = Response, OpCode - Std Qry, RD RA Bits Set, RCode -
No error
DNS: 1 = Response
DNS : . 0000 = Standard Query
DNS: 0 = Server not authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 1 = Recursive queries supported by server
DNS : 000 .... = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 2 (0x2)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
ШЗ: Question Section: w&w.lackfix.cz. of type Host Addr on class INET addr.
DNS: Question Name: www.lackfix.cz.
DNS: Question Type = Host Address
DNS: Question Class = Internet address class
ENS: Answer section: www.lackfix.cz. of type Canonical name on class ШЕГ addr.
+ DNS: Resource Record: www.lackfix.cz. of type Canonical name on
class INET addr.
+ DNS: Resource Record: wwwvirt.pvtnet.cz. of type Host Addr on class
INET addr.
Пример использования TCP
Я могу использовать программу nslookup, чтобы получить все записи,
ассоциированные с доменным именем ааа. pvtnet. cz. Для этого
нужно указать тип запроса q=any.
# nslookup
Default Server: localhost
Address: 127.0.0.1
> set q=any
> aaa.pvtnet.cz
Server: localhost
Address: 127.0.0.1
418

Глава 12. Протокол DNS
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
aaa.pvtnet.cz
pvtnet.cz
pvtnet.cz
pvtnet.cz
pvtnet.cz
pvtnet.cz
info.pvt.net
cbu.pvtnet.cz
ns.pvt.net
nsl.pvt.net
snmpO.pvt.net
nsO.pipex.net
nsl.pipex.net
text = „Budejovice locality"
text = „mail server"
text = „32 MB operating memory"
text = „an upgrade to 64 MB soon"
CPU = PC OS = Linux 1.3.20
text = „e-mail: alena@pvt.net"
text = „test node"
text = „mail for aaa.pvtnet.cz"
text = „not working yet"
preference = 10, mail exchanger = info.pvt.net
preference = 20, mail exchanger = cbu.pvtnet.cz
preference = 100, mail exchanger = mail.pvtnet.cz
preference = 200, mail exchanger = mail2.pvtnet.cz
internet address = 195.47.55.55
nameserver = ns.pvt.net
nameserver = nsl.pvt.net
nameserver = snmp0.pvt.net
nameserver = ns0.pipex.net
nameserver = nsl.pipex.net
internet address = 194.149.104.203
internet address = 194.149.105.18
internet address = 194.149.105.18
internet address = 194.149.103.201
internet address = 194.149.103.34
internet address = 158.43.128.8
internet address = 158.43.192.7
Листинг 12.11. DNS-запрос, отправленный по UDP
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x5BA9; Proto = UDP; Len: 59
+ UDP: Src Port: Unknown, (1284); Dst Port: DNS (53); Length = 39 (0x27)
ENS: 0xC:Std Qry for aaa.pvtnet.cz. of type Req. for all on class INET addr.
DNS: Query Identifier = 12 (OxC)
DNS: DNS Flags = Query, CpCode - Std Qry, RD Bits Set, RCode - No error
DNS: 0 = Query
DNS : . 0000 = Standard Query
419

TCP/IP и DNS в теории и на практике. Полное руководство
DNS: О = Server not authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 0 = No recursive queries
DNS : 000 .... = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
+ ENS: Question Section: aaa.pvtnet.cz. of type Req. for all on class ШЕГ addr.
В результате ответ от сервера превысит 512 байтов (листинг 12.12),
и DNS-пакет будет усечен (установлен бит ТС). Чтобы получить
полный ответ, нужно использовать TCP (листинг 12.13).
Листинг 12.12. Ответ сервера на DNS-запрос, отправленный по UDP
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x6970; Proto = UDP; Len: 524
UDP: Src Port: DNS, (53); Dst Port: Unknown (1284); Length = 504 (0xlF8)
ENS: 0xC:Std Qry Resp. for aaa.pvtnet.cz. of type Host Addr on class ШЕГ addr.
DNS: Query Identifier = 12 (OxC)
DNS: DNS Flags = Response, OpCode - Std Qry, AA TC RD RA Bits Set, RCode -
No error
DNS: 1 = Response
DNS : . 0000 = Standard Query
DNS: 1 = Server authority for domain
DNS: 1 = Message truncated
DNS: 1 = Recursive query desired
DNS: 1 = Recursive queries supported by server
DNS : 000 .... = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 14 (OxE)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 0 (0x0)
+ ШЗ: Question Section: aaa.pvtnet.cz. of type Req. for all on class ШЕГ addr.
420

Глава 12. Протокол DNS
DNS: Answer sect ion: aaa.pvtnet .cz . of typeHostAddronclass INETaddr .
(14 records present)
DNS: Authority Section = N/A
Листинг 12.13. DNS-запрос no TSP
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x5FA9; Proto = TCP; Len: 71
TCP: .AP..., len: 31, seq: 31853005-31853035, ack: 320256001, win: 8760,
src: 1285 dst: 53
DNS: 0x100 :Std Qry for o_ of type Unknown Type on class Unknown Class
DNS: TCP Length = 12 (OxC)
DNS: Query Identifier = 256 (0x100)
DNS: DNS Flags = Query, OpCode - Std Qry, RCode - Server unable to
interpret query
DNS: 0 = Query
DNS : . 0000 = Standard Query
DNS: 0 = Server not authority for domain
DNS : 0 = Message complete
DNS: 0 = Iterative query desired
DNS: 0 = No recursive queries
DNS : 000 .... = Reserved
DNS: 0001 = Server unable to interpret query
DNS: Question Entry Count = 0 (0x0)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 865 (0x361)
+ DNS: Additional Records Section: of type Unknown Type on class Unknown
Class(865 records present)
Листинг 12.14. Полный DNS-otbet (650 Б), полученный по TSP
FRAME: Base frame properties
ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
IP: ID = 0x697C; Proto = TCP; Len: 692
TCP: .AP..., len: 652, seq: 320256001-320256652, ack: 31853036, win:33580,
src: 53 dst: 1285
ENS: OxC:Std Qry Resp. for aaa.pvtnet.cz. of type Host Addr on class INET addr.
421

TCP/IP и DNS в теории и на практике. Полное руководство
DNS: TCP Length = 650 (0х28А)
DNS: Query Identifier = 12 (OxC)
DNS: DNS Flags = Response, CpCode - Std Qry, AA RD RA Bits Set, RCode -
No error
DNS: 1 = Response
DNS : . 0000 = Standard Query
DNS: 1 = Server authority for domain
DNS : 0 = Message complete
DNS: 1 = Recursive query desired
DNS: 1 = Recursive queries supported by server
DNS : 000 . . . . = Reserved
DNS: 0000 = No error
DNS: Question Entry Count = 1 (0x1)
DNS: Answer Entry Count = 14 (OxE)
DNS: Name Server Count = 5 (0x5)
DNS: Additional Records Count = 7 (0x7)
DNS: Question Section: aaa.pvtnet.cz. of type Req. for all on class
INET addr.
DNS: Answer section: ._aaa_pv. of type Unknown Type on class Unknown
Class(14 records present)
DNS: Authority Section = N/A
+ DNS: Additional Records Section = N/A
Практика использования программы NSLOOKUP
для мониторинга DNS-cepbepob
Для мониторинга процесса «общения» между сервером и клиентом
администраторы серверов DNS обычно используют программу nslookup, a
не сетевой монитор Microsoft Network Monitor. Чтобы увидеть все,
«сказанное» клиентом и сервером, нужно установить опции отладки debug
или d2. Сравните выводы nslookup на каждом из этих уровней отладки
(см. листинг 12.15 и 12.16).
Листинг 12.15. Программа nslookup: уровень отладки debug
>set debug
>www.lackfix.cz.
Server: localhost
Address: 127.0.0.1
422

Глава 12. Протокол DNS
Got answer (263 bytes):
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 5, additional = 5
QUESTIONS:
www.lackfix.cz, type = A, class = IN
ANSWERS:
-> www.lackfix.cz
type = CNAME, class = IN, dlen = 19
canonical name = wwwvirt.pvtnet.cz
ttl = 86400 (1 day)
-> wwwvirt.pvtnet.cz
type = A, class = IN, dlen = 4
internet address = 194.149.101.35
ttl = 86400 (1 day)
AUTHORITY RECORDS:
-> pvtnet.cz
type = NS, class = IN, dlen = 12
nameserver = ns.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 6
nameserver = nsl.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 8
nameserver = snmp0.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 12
nameserver = ns0.pipex.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 6
nameserver = nsl.pipex.net
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> ns.pvt.net
423

TCP/IP и DNS в теории и на практике. Полное руководство
type = A, class = IN, dlen = 4
internet address = 194.149.105.18
ttl = 86400 (1 day)
-> nsl.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.103.201
ttl = 86400 (1 day)
-> snmp0.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.103.34
ttl = 86400 (1 day)
-> nsO.pipex.net
type = A, class = IN, dlen = 4
internet address = 158.43.128.8
ttl = 62655 (17 hours 24 mins 15 sees)
-> nsl.pipex.net
type = A, class = IN, dlen = 4
internet address = 158.43.192.7
ttl = 62655 (17 hours 24 mins 15 sees)
Name:wwwvirt.pvtnet.cz
Address: 194.149.101.35
Aliases: www.lackfix.cz
Листинг 12.16. Программа NSLOOKUP: уровень отладки d2
#nslookup
> set d2
> www.lackfix.cz.
Server: localhost
Address: 127.0.0.1
SendRequest(), len 32
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
424

Глава 12. Протокол DNS
www.lackfix.cz, type = A, class = IN
Got answer (2 63 bytes):
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 2, authority records = 5, additional = 5
QUESTIONS:
www.lackfix.cz, type = A, class = IN
ANSWERS:
-> www.lackfix.cz
type = CNAME, class = IN, dlen = 19
canonical name = wwwvirt.pvtnet.cz
ttl = 86400 (1 day)
-> wwwvirt.pvtnet.cz
type = A, class = IN, dlen = 4
internet address = 194.149.101.35
ttl = 86400 (1 day)
AUTHORITY RECORDS:
-> pvtnet.cz
type = NS, class = IN, dlen = 12
nameserver = ns.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 6
nameserver = nsl.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 8
nameserver = snmp0.pvt.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 12
nameserver = ns0.pipex.net
ttl = 86400 (1 day)
-> pvtnet.cz
type = NS, class = IN, dlen = 6
nameserver = nsl.pipex.net
425

TCP/IP и DNS в теории и на практике. Полное руководство
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> ns.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.105.18
ttl = 86400 (1 day)
-> nsl.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.103.201
ttl = 86400 (1 day)
-> snmp0.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.103.34
ttl = 86400 (1 day)
-> ns0.pipex.net
type = A, class = IN, dlen = 4
internet address = 158.43.128.8
ttl = 62851 (17 hours 27 mins 31 sees)
-> nsl.pipex.net
type = A, class = IN, dlen = 4
internet address = 158.43.192.7
ttl = 62851 (17 hours 27 mins 31 sees)
Name: wwwvirt. pvtnet. cz
Address: 194.149.101.35
Aliases: www.lackfix.cz

Глава 13 РАСШИРЕННЫЕ ФУНКЦИИ
ПРОТОКОЛА DNS
ОПЕРАЦИЯ DNS UPDATE
ОПЕРАЦИЯ DNS NOTIFY
ВОЗРАСТАЮЩАЯ ПЕРЕДАЧА ЗОНЫ
ОТРИЦАТЕЛЬНОЕ КЭШИРОВАНИЕ
(DNS NCACHE)
TCP/IP и DNS в теории и на практике. Полное руководство

13.1. Операция DNS UPDATE
13.1.1. Общее описание
Операция DNS UPDATE подробно описана в RFC-3007. Она позволяет
динамически корректировать записи базы данных DNS, поэтому данная
функция также называется «динамическим обновлением». Операция
DNS UPDATE позволяет осуществлять добавление/удаление одной
или более записей в/из файла зоны. Если эта функция активизирована,
файл зоны больше не нуждается в статическом редактировании
администратором — теперь он изменяется динамически по протоколу DNS.
Операция обновления также основывается на запросах и ответах.
BIND версии 8 и 9 полностью поддерживают DNS UPDATE, поэтому
мы будем использовать его терминологию, то есть говорить о главном/
подчиненном (master/slave) сервере имен. Операция DNS UPDATE
также широко используется в Windows 2000/2003.
При использовании механизма динамического обновления данные зоны
обновляются только на первичном (он же главный, master) сервере
имен:
• Первичный (primary или master) сервер доменных имен является
авторитетным сервером зоны (ответственным сервером). Он читает
описание зоны из файла, сохраненного на жестком диске, и отвечает,
в соответствии с прочитанным файлом, на запросы DNS-клиентов
(резолверов). Описание зоны (файл зоны) создается вручную
администратором зоны. Изменения может вносить тоже только
администратор. Все остальные серверы DNS (вторичные, slave-серверы)
копируют информацию о зоне с первичного сервера. Для зоны
может быть определен только один первичный сервер.

Глава 13. Расширенные функции протокола DNS
• Вторичный (дублирующий, secondary, slave) сервер также является
авторитетным для зоны. Его основная задача - подстраховать
первичный сервер на случай его выхода из строя, а также немного
разгрузить его, приняв на себя часть запросов. Например, если в зоне
есть 5 серверов DNS, то 4 из них - вторичные, и только один -
первичный. Администратор вторичного сервера не прописывает
информацию о зоне в настройках сервера, он только настраивает его так,
чтобы всю необходимую информацию о зоне тот получал у
первичного сервера.
Операция обновления DNS UPDATE используется не для создания
новых зон, а только для коррекции уже созданных. Например, в зоне есть
компьютер compl с IP-адресом 192.168.2.1. Администратор первичного
сервера изменил его имя на server. Но вторичному серверу он пока
известен как compl. Через некоторое время происходит обновление зоны на
вторичном сервере, то есть синхронизация базы данных вторичного
сервера с базой данных первичного. В результате операция DNS UPDATE
обновит ресурсную запись для этого компьютера.
И еще: операция DNS UPDATE не производит добавления новой SOA-
записи или ее удаления. SOA-запись может быть только обновлена.
Итак, с помощью запроса DNS UPDATE мы можем модифицировать
одну или несколько записей зоны.
Динамическое обновление позволяет удалять и добавлять отдельные
ресурсные записи зоны, наборы записей, выделенных по
определенному признаку, например, записей определенного типа или записей,
относящихся к определенному домену. Возможна модификация записи по
условию. Что же касается условий, то их может быть несколько. Если
хотя бы одно из условий не выполнено, выражение считается ложным,
и никакая модификация зоны производиться не будет.
В DNS-пакете обновления (UPDATE) отдельно указаны эти условия
и записи, которые должны быть добавлены или удалены из файла зоны.
Операция DNS UPDATE использует спецификацию протокола DNS,
определенную в RFC 1035 (см. главу 12). Стандарт RFC 2136 вместе
с новым стандартом RFC 3007 определяет несколько расширений
этого протокола, например, новые типы сообщений и новые
результирующие коды.
429

TCP/IP и DNS в теории и на практике. Полное руководство
13.1.2. Формат DNS-пакета для операции UPDATE
Формат DNS-пакета для операции UPDATE такой же самый, как
и у обычного DNS-пакета. Он по-прежнему состоит из пяти полей
(см. рис. 13.1):
• Секция заголовок.
• Секция зоны — определяет зону, которая будет изменена.
• Секция условия — набор ресурсных записей, которые должны
существовать в зоне.
• Секция обновления — набор ресурсных записей, которые должны
быть изменены или удалены.
• Секция дополнительных данных — эта информация не является
частью информации обновления, но важна для самого процесса
обновления.
15 бит
Секция заголовка
Секция зоны
Секция условия
Секция обновления
Секция
дополнительных данных
\
Q
R
1 1
ID
OPCODE
А
А
т
С
R
D
R
А
Z
RCODE
ZOCOUNT
(кол-во записей в секции зоны)
PRCOUNT
(кол-во записей в секции условий)
UPCOUNT
(кол-во записей в секции обновлений)
ADCOUNT
(кол-во записей в секции дополн. данных)
Рис. 13.1. Формат пакета DNS UPDATE
430

Глава 13. Расширенные функции протокола DNS
Секция заголовка
Секция заголовка, подобно заголовку DNS QUERY, содержит в первых
двух байтах идентификацию (поле ID), после которой следуют два
байта управляющих полей и четыре двухбайтовых поля длины отдельных
секций (каждое поле длины занимает 2 б):
• ZOCOUNT - количество записей в секции зоны.
• PRCOUNT - количество записей в секции условий.
• UPCOUNT - количество записей в секции обновлений.
• ADCOUNT - количество записей в секции дополнительных
данных.
Таблица 13.1. Значения управляющих полей
Поле
I Ю
QR
Opcode
Z
I Rcode
Длина
16
1
4
7
4
Значение
Идентификация сообщения, копируется в ответ
0, если данное сообщение — запрос,
1, если данное сообщение — ответ. Операция DNS UPDATE не
использует другие биты.
Поле Opcode (Код операции) следует сразу после QR
5 (UPDATE), копируется из запроса в ответ
Зарезервировано для будущего
Код ответа (используется только в ответе, в запросе данное
поле не определено)
Таблица 13.2. Результирующие коды ответа (поле Rcode)
Код ошибки
| NOERROR
FORMERR
SERVFAIL
NXDOMAIN
NOTIMP
REFUSED
YXDOMAIN
YXRRSET
Числовое
значение
0
1
2
3
4
5
6
7
Описание ошибки
Нет ошибок, все нормально
Ошибка формата сообщения - сервер не может
интерпретировать запрос
Произошла внутренняя ошибка сервера во время
обработки сообщения (например, ошибка
операционной системы)
Несуществующий домен
Сервер не поддерживает операцию, код которой
указан в поле Opcode
Сервер имен отказался от обработки сообщения,
например, из соображений безопасности
Имя, которое не должно существовать, существует
Существуют некоторые ресурсные записи, которые
не должны существовать
431

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 12.2
Код ошибки
NXRRSET
NOAUTH
NOTZONE
Числовое
значение
8
9
10
Описание ошибки
Некоторые ресурсные записи, которые должны
существовать, не существуют
Сервер не является авторитетным для данной зоны
Имя, указанное в секции условия (Prerequisite) или
секции обновления (Update) не является именем
зоны, указанной в секции зоны (Zone Section)
Секция зоны
В данной секции указывается зона, подлежащая обновлению. Один
запрос DNS UPDATE может использоваться для изменения только одной
зоны. Секция состоит из трех частей:
• ZNAME - имя зоны.
• ZTYPE - тип зоны (цепочка SOA).
• ZCLASS - класс зоны - IN (Internet).
Секция условия (Prerequisite Section)
Данная секция содержит набор ресурсных записей (РЗ), которые
должны существовать на первичном сервере в определенной зоне в момент
получения пакета UPDATE. Существует пять опций (условий) секции
условия:
1. Должна быть хотя бы одна РЗ заданного имени (NAME) и типа
(TYPE). Набор РЗ существует, значение независимо. Секция
условия содержит одну РЗ с заданным именем (NAME) и типом (TYPE),
которая должна быть в зоне. Другие элементы записи не столь
важны, однако RDLENGTH устанавливается в 0, поскольку поле
RDATA ничего не содержит. Поля CLASS и TTL устанавливаются
так: CLASS=ANY, TTL=0.
Например, я запрашиваю запись типа А с доменным именем ааа.
company. com и любыми данными (RDATA), связанными с доменом.
2. В зоне должен существовать набор РЗ с заданным именем и типом,
правая сторона записи соответствует правой стороне записей
пакета UPDATE (Набор РЗ существует). Порядок следования записей
значения не имеет. Секция содержит набор РЗ с заданным именем
432

Глава 13. Расширенные функции протокола DNS
(NAME) и типом (TYPE), а также данными RDATA. Класс
определяется в секции зоны, TTL=0.
Например, я запрашиваю, содержит ли зона эти записи:
mail.company.com. А 195.47.11.11
www.company.com. А 195.47.11.12
company.com. MX 10 mail.company.com
3. Не должно быть ни одной РЗ с заданным именем и типом (Набор
РЗ не существует). Секция содержит одну запись с заданными
полями ЫАМЕ=имя, TYPE-тип, RDLENGTH=0, RDATA ничего не
содержит, CLASS=NONE, TTL=0.
Например, мне нуясно узнать, не содержит ли зона запись типа А для
доменного имени mail. company. com.
4. Зона должна содержать хотя бы одну запись с заданным именем,
которая определена в секции зоны. (Проверка: имя существует).
Секция содержит одну РЗ с заданными полями NAME-имя, TYPE=ANY,
RDLENGTH=0, RDATA ничего не содержит, CLASS=ANY, TTL=0.
Например, мне нужно узнать, если ли в зоне хотя бы одна РЗ с именем
company . com.
5. Зона не должна содержать хотя бы одну запись с заданным
именем, которая определена в секции зоны. {Проверка: имени
не существует). Секция содержит одну РЗ с заданными полями
NAMЕ=имя, TYPE=ANY, RDLENGTH=0, RDATA ничего не
содержит, CLASS=ANY, TTL=0. Обратная предыдущей проверка.
Секция обновления
Секция обновления содержит РЗ, которые должны быть добавлены в
зону или удалены из нее. С помощью операции обновления можно
произвести четыре основных изменения:
1. Добавление РЗ
Секция обновления содержит несколько РЗ. Для каждой РЗ указаны
поля NAME (имя), TYPE (тип), TTL, RDLENGTH (длина данных)
и RDATA (данные). Поле CLASS берется из секции зоны. Данные
записи будут добавлены в файл зоны. Дублирование записей (если
такие записи уже есть в файле) игнорируется.
Например, я хочу добавить следующие записи:
433

TCP/IP и DNS в теории и на практике. Полное руководство
company.com. MX 20 mh.company.com.
mh.company.com. А 195.47.13.12
2. Удаление набора РЗ заданного типа
Секция содержит одну запись с заданными полями имени и типа,
указывающую тип записей, которые должны быть удалены. Остальные
поля устанавливаются так: TTL=0, CLASS=ANY, RDLENGTH=0,
RDATA - пусто.
Например у я хочу удалить все записи типа MX, связанные с
доменным именем company. com.
3. Удаление всех записей, связанных с указанным именем
Секция содержит запись только с заданным именем. Все
остальные поля устанавливаются так: TYPE=ANY, TTL=0, CLASS=ANY,
RDLENGTH=0, RDATA - пусто.
Например, я хочу удалить все записи, связанные с доменным именем
mail.company.com.
4. Удаление одной определенной РЗ
Секция содержит одну запись, которую нужно удалить. Явно
указываются все поля, идентифицирующие запись (NAME, TYPE,
RDLENGTH, RDATA). Поля TTL и CLASS устанавливаются так:
TTL=0, CLASS=NONE.
Например, я хочу удалить следующую запись:
company.com. IN MX 10 mail.company.com.
Секция дополнительных данных
Секция дополнительных данных содержит РЗ, которые имеют какое-
либо отношение непосредственно к обновлению или созданию новых
записей с использованием обновления.
13.1.3. Файл журнала
Операцией DNS UPDATE не модифицируют файлы зоны
непосредственно, сервер имен сохраняет все изменения файла зоны в журнале
зоны. Модификация файла зоны согласно журналу будет выполнена во
время остановки или перезапуска сервера имен.

Глава 13. Расширенные функции протокола DNS
У каждой зоны есть свой собственный файл журнала, который
создается автоматически при выполнении первой операции DNS UPDATE для
этой зоны. Имя файла журнала идентично имени зоны, а расширение
- .jnl.
Содержимое файла журнала представлено в двоичном виде, то есть
редактировать вручную его нельзя. Правда, даже если бы содержимое
файла было текстовым, никто бы вам не разрешил редактировать этот
файл. Также запрещено самостоятельное редактирование файлов зон,
для которых используется динамическое обновление.
Причина этому очевидна: файлы зон не должны содержать наиболее
актуальную информацию, поскольку этой информации нет в файле
журнала (а этот файл, как уже было сказано, отредактировать вручную нельзя).
Если по каким-либо причинам вам необходимо вручную отредактировать
динамически созданную зону, нужно выполнить следующие действия:
1. Остановить сервер DNS (команда rndc stop).
2. Удалить файл журнала, который вы собираетесь редактировать,
чтобы его содержимое не конфликтовало с содержимым файла зоны.
3. Отредактировать файл зоны.
4. Запустить снова сервер DNS.
13.1.4. Замечания
Операцию DNS UPDATE рекомендуется использовать вместе с
системой безопасности. В RFC 2137 вы можете прочитать о безопасном
динамическом обновлении — Secure Dynamic Update.
13.2. Операция DNS Notify
Операция уведомления DNS Notify
Операция уведомления DNS Notify описана в RFC 1993. Данная операция
позволяет уведомлять вторичные серверы об изменениях в данных зоны.
При использовании операции DNS Notify «общение» первичного и
вторичных серверов выглядит так, как это представлено на рис. 13.2.
Первичный сервер информирует вторичные серверы о любом изменении
435

TCP/IP и DNS в теории и на практике. Полное руководство
в зоне: «Запрос на передачу зоны». Вторичные серверы должны
запросить передачу зоны немедленно после получения этого сообщения.
Сообщение DNS Notify будет получено всеми серверами,
перечисленными в ресурсной записи NS данной зоны. Сервер, указанный в
записи SOA, данное сообщение не получит, поскольку предполагается, что
именно этот сервер будет отправлять сообщение DNS Notify.
Некоторые реализации серверов DNS разрешают администраторам
первичного сервера добавить IP-адреса других серверов к уже
существующему набору. Данный список серверов называется списком
уведомления (Notify Set). Серверам из данного списка будет также отправлено
сообщение DNS Notify.
AXFR или IXFR
Главный
(master)
SOA-запрос
Рис. 13.2. Уведомление
Сообщение Notify
Формат DNS-пакета с сообщением Notify описан в RFC 1035.
Сообщение Notify использует всего одну подгруппу полей пакета,
неиспользуемые поля заполняются двоичными нулями. Код операции (Opcode)
равен 4 (NOTIFY). Первичный сервер может отправлять элементы
NAME, CLASS, TYPE и RDATA изменившихся записей как часть
сообщения уведомления. Сообщения уведомления не используют секцию
авторитетных серверов и секцию дополнительных данных.
Пример сообщения DNS Notify (модифицирована главная зона
abcde . com):
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0xD4; Proto = UDP; Len: 54
+ UDP: Src Port: Unknown, (1049); Dst Port: ENS (53); Length = 34 (0x22)
Notify
Подчиненный
(slave)
436

Глава 13. Расширенные функции протокола DNS
DNS: 0x54C6:Std Qry for abcde.com. of type SOA on class INET addr.
DNS: Query Identifier = 21702 (0x54C6)
DNS: DNS Flags = Query, OpCode - Rsrvd, RCode - No error
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS
DNS:
0.
,0100.
0.
.0.
,000.
DNS
DNS
DNS
. = Query
. = Reserved
= Server not authority for domain
. = Message complete
. = Iterative query desired
. = No recursive queries
. = Reserved
0000 = No error
Question Entry Count = 1 (0x1)
Answer Entry Count = 0 (0x0)
Name Server Count = 0 (0x0)
Additional Records Count = 0 (0x0)
Question Section: abcde.ccm. of type SOA on class INET addr.
Question Name: abcde.com.
Question Type = Start of zone of authority
Question Class = Internet address class
Поле Код операции (Opcode) установлено в 4. Для захвата этого
пакета использовалась программа Microsoft Network Monitor V4, которая
интерпретирует это значение как значение поля Rsrvd
(Зарезервировано), поскольку данная версия еще не поддерживает сообщения DNS
Notify.
Пример ответа на сообщение DNS Notify:
+ FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol
+ IP: ID = 0x84C9; Proto = UDP; Len: 40
+ UDP: Src Port: ENS, (53); Dst Port: Unknown (1049); Length = 20 (0x14)
ENS: 0x54C6:Std Qry Resp. : This query not supported fcy name server
DNS: Query Identifier = 21702 (0x54C6)
DNS: DNS Flags = Response, OpCode - Rsrvd, RA Bits Set,
RCode - This query not supported by name server
1 = Response
. 0100 = Reserved
0 = Server not authority for domain
0 = Message complete
0 = Iterative query desired
DNS
DNS
DNS
DNS
DNS
437

TCP/IP и DNS в теории и на практике. Полное руководство
DNS: 1 = Recursive queries supported by server
DNS: 000 = Reserved
ENS: 0100 = This query not supported by name server
DNS: Question Entry Count = 0 (0x0)
DNS: Answer Entry Count = 0 (0x0)
DNS: Name Server Count = 0 (0x0)
DNS: Additional Records Count = 0 (0x0)
DNS: Frame Padding
Для передачи пакета уведомления могут использоваться протоколы
UDP и TCP. Если используется протокол TCP, сообщение уведомления
отправляется всего один раз. В настройках первичного сервера имен
установлен таймаут, на протяжении которого первичный сервер будет
ждать ответа от вторичного. При использовании протокола TCP, ни
первичному, ни подчиненным серверам не разрешается прервать операцию.
При использовании протокола UDP первичные серверы периодически
отправляют сообщения уведомления вторичным серверам. Отправка
сообщений конкретному вторичному серверу прекращается при
получении ответа от него. Если первичный сервер не получил ответ, он
прекращает передачу после определенного количества повторов или по
получении ICMP-сообщения о том, что порт недоступен. Интервал времени
между отдельными попытками указывается как параметр первичного
сервера в файле конфигурации (обычно 60 секунд). Как правило, число
попыток равно 5.
Единственная причина отправки уведомляющего сообщения — это
изменения в SOA-записи. После получения сообщения Notify вторичный
сервер будет действовать так, как будто истек интервал времени,
заданный в поле Refresh SOA-записи зоны, указанной в QNAME. Вторичный
сервер должен запросить у первичного сервера SOA-запись нужной зоны
и проверить поле серийного номера. Если серийный номер был
увеличен, он должен выполнить операции AXFER или IXFR (см. ниже).
Передача зоны производится от первичного сервера к вторичным
серверам. Первичный сервер может также включить в уведомляющее
сообщение измененные ресурсные записи (имя, тип, класс, а также данные
(RDATA)).
Ответ на уведомляющее сообщение не содержит никакой информации -
важен сам факт, что первичный сервер получил ответ. Если вторичный
сервер получил уведомляющее сообщение, содержащее QNAME от узла,
438

Глава 13. Расширенные функции протокола DNS
не являющегося первичным сервером заданной зоны, он игнорирует это
сообщение, а в ответ генерирует в журнале запись об ошибке.
При запуске сервер обязан послать уведомляющее сообщение для
каждой зоны, которую он поддерживает. При перезапуске отправка
уведомляющего сообщения необязательна.
Каждый вторичный сервер может получить несколько одинаковых
уведомляющих сообщений. Чтобы справиться с таким многообразием (или
наоборот, однообразием), сервер ведет протокол уведомляющих
сообщений.
Первичный сервер отправляет уведомляющие сообщения разным
серверам с определенной задержкой. Ведь если эти серверы получат эти
сообщения одновременно, то это вызовет большой поток запросов на
передачу зоны, что может отрицательно сказаться на
производительности сервера. Задержка выбирается произвольно, поэтому
вероятность передачи зоны одновременно двум вторичным серверам
практически равна нулю.
Данная задержка указывается в поле обновления (Refresh). Обычно
задержка происходит в диапазоне 30-60 секунд, чего вполне достаточно,
чтобы передать зону одному серверу. Вторичный сервер, получив
уведомляющее сообщение, должен прежде всего прервать выполняемую
транзакцию, а затем отправить сообщение серверам более низких
уровней (вторичным серверам, для которых он является первичным).
В Bind 8.1 и более поздних версиях механизм уведомляющих
сообщений воплощен по умолчанию.
13.3. Возрастающая передача зоны
Возрастающая передача зоны (IXFR) описана в RFC 1995. Данная
операция позволяет передачу только измененных данных с первичного
сервера на вторичный, то есть передачу только измененной части зоны, а не
всей зоны. С другой стороны, может быть произведена классическая
передача зоны (AXFR), при которой передается вся зона.
Чтобы предоставить подчиненным серверам только изменившиеся
ресурсные записи, первичному серверу необходима хронология базы
данных. Первичный сервер следит за версиями зоны — за текущей и пре-
439

TCP/IP и DNS в теории и на практике. Полное руководство
дыдущей. Благодаря этому механизм динамического обновления
позволяет получать только разницу между текущим и предыдущим
состояниями зоны - то есть новые и измененные записи, а также информацию
об удаленных записях. Если подчиненный сервер поддерживает IXFR,
то будет передана только изменившаяся посредством выполнения DNS
UPDATE часть зоны.
Индивидуальные версии файлов различаются серийным номером,
содержащимся в записи SOA. Если подчиненный сервер определяет, что
он нуждается в новых данных от первичного сервера, он посылает
запрос, содержащий серийный номер (serial) последней версии зоны,
который у него есть.
Главный сервер посылает исправления - версии зон, которые
превышают указанный вторичным сервером номер. Альтернативно вторичному
серверу может быть отправлена вся зона. Вся зона сразу отправляется
и в том случае, если версия зоны, имеющаяся у вторичного сервера,
настолько стара, что сервер не способен выполнить IXFR.
Как только зона в памяти будет откорректирована, вторичный сервер
должен сохранить изменения в файл и затем ответить на IXFR-запрос.
Для ввода изменений в файл зоны с помощью IXFR используются
файлы журнала, подобные файлам журнала обновления (см. DNS UPDATE).
Если сервер получил запрос с серийным номером, указанным в SOA-за-
писи, большим его собственного серийного номера, сервер возвращает
ответ, содержащий только его текущую SOA-запись.
Для IXFR могут использоваться оба протокола - TCP и UDP. Если
клиент посылает запрос по UDP, ответ он тоже получит по UDR Если ответ
превышает 5126, сервер использует UDP только для отправки SOA-за-
писи, а клиент обязан установить соединение по TCP.
Вторичный сервер, запрашивающий возрастающую передачу зоны,
является IXFR-клиентом. А главный сервер, который будет передавать
зону вторичному серверу, называется IXFR-сервером.
IXFR использует DNS-пакеты, описанные в RFC 1035.
Формат запроса
Для IXFR устанавливается специальное поле типа запроса (Opcode -
Код операции), а секция авторитетных серверов имен содержит SOA-
запись зоны.
440

Глава 13. Расширенные функции протокола DNS
Формат ответа
IXFR указывается в поле Opcode (Код операции) ответа. Первая
и последняя ресурсные записи в секции ответа представляют
собой SOA-запись зоны, которая должна быть модифицирована
(updated).
IXFR отправляет ответ в форме одной или нескольких изменений в зоне.
Изменение - это добавление новой или удаление ресурсной записи.
Изменение в существующей записи рассматривается как удаление старой
записи и добавление новой. Изменения перечислены в секции ответа по
порядку: от самой старой до самой новой.
IXFR-клиент может обменять старую версию файла на новую только
после того, как все принятые изменения будут успешно применены.
Если клиент не поддерживает IXFR, или в зоне произошло столько
изменений, что IXFR использовать неразумно, клиент повторяет запрос,
запрашивая в этот раз передачу всей зоны - AXFR.
Генеральная уборка
IXFR-сервер не должен содержать все предыдущие версии зоны.
Поддержка IXFR предусматривает периодическое удаление старых файлов
зон. Что же касается большой и часто изменяющейся зоны, мы можем
столкнуться с несоответствием между размером занимаемого дискового
пространства и возможностью использования IXFR (то есть размер
занимаемого пространства больше, чем допускает IXFR).
В этом случае, если на IXFR-передачу нужно больше времени,
используется AXFR-передача.
Примеры
Давайте рассмотрим несколько примеров. У нас есть три версии данных
зоны, третья версия является самой новой.
JAIN.AD.JP. IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
1 600 600 3600000 604800)
IN NS NS.JAIN.AD.JP.
NS.JAIN.AD.JP. IN A 133.69.136.1
NEZU.JAIN.AD.JP. IN A 133.69.136.5
441

TCP/IP и DNS в теории и на практике. Полное руководство
3anncbNEZU. JAIN. AD. JP. удалена, азапись JAIN-BB. JAIN. AD. JP. —
добавлена
IN SOA ns.jain.ad.jp.mohta.jain.ad.jp. (
2 600 600 3600000 604800)
NS.JAIN.AD.JP.
133.69.136.1
133.69.136.4
192.41.197.2
jain.ad.jp
NS.JAIN.AD.JP.
JAIN-BB. JAIN. AD,
.JP.
IN
IN
IN
IN
IN
SOP
NS
A
A
A
Изменен один из IP-адресов для JAIN-BB. JAIN. AD. JP.
JAIN.AD.JP. IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
3 600 600 3600000 604800)
NS.JAIN.AD.JP.
133.69.136.1
133.69.136.3
192.41.197.2
NS.JAIN.AD.JP.
JAIN-BB.JAIN.AD.JP.
IXFR-запрос:
IN
IN
IN
IN
NS
A
A
A
Header I OPCODE=SQUERY
+
Question I QNAME=JAIN.AD.JP., QCLASS=IN/ QTYPE=IXFR I
+ +
Answer I I
+ +
Authority I JAIN.AD.JP.
+
Additional I
+
IN SOA serial=l
В качестве ответа может быть послана вся зона:
Header
Header
I OPCODE=SQUERY
+
I OPCODE=SQUERY/ RESPONSE
Question | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR
+
Answer I JAIN.AD.JP. IN SOA serial=3
I JAIN.AD.JP.
IN NS
NS.JAIN.AD.JP.
442

Глава 13. Расширенные функции протокола DNS
I
I
I
I
4-.
Authority I
Additional I
NS.JAIN.AD.JP.
JAIN-BB.JAIN.AD.JP.
JAIN-BB.JAIN.AD.JP.
JAIN.AD.JP.
IN
IN
IN
IN
A
A
A
SOA
133.69.
133.69.
192.41.
serial=
.136,
.136,
.197,
=3
.1
.3
.2
1
1
1
1
4.
1
4.
1
или только измененные данные:
Header
Question
Answer
Authority
Additional
1
+
1
+ ■
1
1
1
1
1
1
1
1
1
1
1
+ ■
1
+ ■
LI
+ ■
OPCODE=SQUERY/ RESPONSE
QNAME=JAIN.AD.JP., QCLASS=IN/
JAIN.AD.JP. IN
JAIN.AD.JP. IN
NEZU.JAIN.AD.JP. IN
JAIN.AD.JP. IN
JAIN-BB.JAIN.AD.JP. IN
JAIN-BB.JAIN.AD.JP. IN
JAIN.AD.JP. IN
JAIN-BB.JAIN.AD.JP. IN
JAIN.AD.JP. IN
JAIN-BB.JAIN.AD.JP. IN
JAIN.AD.JP. IN
SOA
SOA
A
SOA
A
A
SOA
A
SOA
A
SOA
QTYPE=IXFR
serial=3
serial=l
133.69.136.
serial=2
133.69.136,
192.41.197.
serial=2
133.69.136.
serial=3
133.69.136.
serial=3
.5
.4
.2
.4
.3
1
4.
1
4.
1
1
1
1
1
1
1
1
1
1
1
1
4.
1
- +
Могут также быть отправлены сжатые файлы:
4-
Header | OPCODE=SQUERY/ RESPONSE
Question I QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR
4-
Answer | JAIN.AD.JP. IN SOA serial=3
JAIN.AD.JP.
IN
SOA serial=l
443

TCP/IP и DNS в теории и на практике. Полное руководство
1 NEZU.JAIN.AD,
1 JAIN.AD.JP.
1 JAIN-BB.JAIN.
1 JAIN-BB.JAIN.
1 JAIN.AD.JP.
.JP.
.AD.
.AD.
. JP.
.JP.
IN
IN
IN
IN
IN
A
SOA
A
A
SOA
133.69,
serial-
133.69,
192.41,
serial^
.136,
= 3
.136,
.197,
= 3
.5
.3
.2
+ +
Authority I I
+ +
Additional I I
+ +
Ожидается, что в будущем IXFR будет также использоваться для
больших доменов (например, .com, .org, etc).
13.4. Отрицательное кэширование (DNS NCACHE)
Сохранение отрицательных ответов на DNS-запросы определено
bRFC1034hRFC2308.
Отрицательное кэширование означает, что сервер будет хранить в
памяти информацию о несуществующих доменах или именах узлов.
RFC 1034 определяет отрицательное кэширование как опциональное,
то есть поддержка отрицательного кэширования необязательна. Только
некоторые версии Bind поддерживают его. Отрицательное кэширование
поддерживается в Bind в 8-й и 9-й версиях (начиная с 4.9.3). В RFC 2308
сказано, что отрицательное кэширование - обязательная функция
каждого резолвера.
ОС Windows 2000/2003 поддерживает отрицательное кэширование.
Время хранения записи в памяти составляет 5 минут. Если мы хотим
изменить это время, нам нужно добавить ключ NegativeCacheTime
(тип REG_DWORD) в раздел реестра HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Значения данного ключа задает время хранения записи в секундах.
Какие отрицательные ответы будут храниться в памяти?
В памяти обязательно будут сохранены ответы с кодами (поле RCODE)
NXDOMAIN и NOERROR NODATA.
444

Глава 13. Расширенные функции протокола DNS
Необязательные ответы сохраняются в памяти сервера не более 5-ти
минут (если вообще сохраняются). IP-адреса серверов сохраняются как
часть сохраненной информации.
Таблица 13.3. Данные негативные ответы обязательно сохраняются
Ошибка
Ошибка имени
(NXDOMAIN)
NOERROR_NODATA
Описание ошибки
Доменное имя, указанное в поле QNAME запроса, не существует. Секция
авторитетных серверов может содержать SOA- и NS-записи
Значение поля RCODE равно NOERROR. Секция ответов не содержит
ресурсных записей. Секция авторитетных серверов может содержать SOA-
и NS-записи
Сохранение других отрицательных ответов не обязательно, то есть данные
ответы с одинаковым успехом могут сохраняться или не сохраняться.
Таблица 13.4. Сохранение данных ответов не обязательно
Ошибка
Отказ (ошибка) сервера
Сервер недоступен
Описание ошибки
Внутренняя ошибка сервера. Может быть связана с конфигурацией
сервера или конфигурацией зоны
Такого сервера не существует или он недоступен
СКОЛЬКО ВРЕМЕНИ ОТРИЦАТЕЛЬНЫЕ ОТВЕТЫ ХРАНЯТСЯ В ПАМЯТИ?
Ресурсные записи сохраняются в памяти, если их TTL больше 0 — иначе
запись теряет силу и удаляется из памяти. Поэтому TTL - решающий
фактор для сохранения ресурсной записи в памяти. Значение TTL
отрицательного ответа, если его нужно хранить в памяти, также должно быть
больше 0. Но как определить TTL отрицательного ответа, если он
обычно не содержит ни одной ресурсной записи в секции ответа (см. первый
пример в главе 12)? TTL определяется SOA-записыо зоны в
авторитетной секции ответа.
Поле MINIMUM (Минимум) в SOA-записи
Рассмотрим три различные интерпретации поля MINIMUM:
1. Минимальное значение TTL для всех записей зоны (обычно
используется именно эта интерпретация).
2. Неявное значение TTL для всех ресурсных записей, у которых
значение этого поля не задано. Это относится только к первичным серверам.
445

TCP/IP и DNS в теории и на практике. Полное руководство
3. Значение TTL для отрицательного ответа.
С этого момента будем считать, что поле MINIMUM SOA-записи
соответствует третьей интерпретации. Значение TTL отдельных записей
должно быть указано непосредственно в самой записи или с помощью
команды $TTL в файле зоны.
Синтаксис команды:
$TTL ttl комментарий
Если у какой-то записи не задано значение поля TTL, будет
использовано значение, указанное командой $TTL.
Реальное значение TTL определяется как минимум двумя значениями:
значением TTL- записи и поля MINIMUM. Если TTL отрицательного
ответа =0, информация в памяти теряет свою силу, то есть становится
неактуальной.
Сохранение правил отрицательных ответов
Применительно к этому можно отметить следующее:
• Сохранение отрицательных ответов обязательно для резолверов.
Если резолвер сохраняет в памяти ответы сервера, он также
должен сохранять и отрицательные ответы.
• Не авторизированные отрицательные ответы не сохраняются.
• SOA-запись авторитетной секции ответа должна быть
сохранена в памяти.
• Отрицательные ответы без SOA-записи не сохраняются.
• SOA-запись, сохраненная в памяти, должна соответствовать
определенному ответу.
• Ответы NXDOMAIN сохраняются вместе с QNAME и QCLASS.
• Ответ NOERROR_NODATA сохраняется вместе с QNAME,
QTYPE и QCLASS.
• Команда $TTL должна указываться в главном файле зоны.

Глава 14
РЕАЛИЗАЦИЯ
СЕРВЕРА ИМЕН
НЕМНОГО ПРЕДЫСТОРИИ
БАЗАДАННЫХОЫЗИЕЕЗАПИСИ
BIND НОВОГО ПОКОЛЕНИЯ
(ВЕРСИИ 8 И 9)
КОНФИГУРАЦИОННЫЙ ФАЙЛ BIND
ПАРАМЕТРЫ КОМАНДЫ OPTIONS
КОМАНДЫ РЕДАКТИРОВАНИЯ
ФАЙЛОВ ЗОНЫ. СПЕЦИАЛЬНЫЕ
ВОЗМОЖНОСТИ BIND 9
ИНСТРУМЕНТЫ ДЛЯ ОТЛАДКИ
И УПРАВЛЕНИЯ DNS
ДИСТАНЦИОННОЕ УПРАВЛЕНИЕ
СЕРВЕРОМ ИМЕН. ПРОГРАММА RNDC
СИГНАЛЫ
ДЕСЯТЬ НАИБОЛЕЕ ЧАСТО
НАРУШАЕМЫХ ПРАВИЛ
В КОНФИГУРАЦИИ DNS
TCP/IP и DNS в теории и на практике. Полное руководство

14.1. Немного предыстории
Основу DNS составляют база данных DNS и хорошо
сконфигурированные серверы имен, обслуживающие эту базу данных. В главе 12 было
дано описание протокола DNS, который в своих запросах и ответах
использует DNS-записи. За функционирование и хранение DNS-записей
в форме текста в дисковых файлах, на первичных серверах имен,
отвечают на первоначальном этапе хост-мастера. Указанные дисковые файлы
обозначаются как база данных DNS.
Формат отдельных записей в базах данных DNS устанавливается
системой BIND. Позднее возникли и другие серверы имен, однако
первоначальный формат базы данных DNS остался таким же, каким был.
В Windows Server 2000/2003 также используется данный формат
(разумеется, если в Windows Server 2000/2003 первоначальные текстовые
файлы базы данных будут скачаны в Active Directory, то все будет
преобразовано в формат, принятый в Active Directory).
В этом разделе мы кратко рассмотрим прародителя современной
программы BIND 9 (и 8) — BIND версии 4. Сделаем это в целях
отслеживания эволюции развития данного программного продукта. Однако вы
можете этот экскурс в историю пропустить и сразу начинать чтение
главы с раздела 14.2.
Сервер системы BIND создается программой named. Программа named
входит в комплект поставки многих операционных систем UNIX.
Конфигурация версии 4 проста и, если не требуются какие-нибудь
особенные функции, использование этой версии целесообразно и при
администрировании сети Windows Server 2000. Сервер имен в Windows
Server 2000 можно обслуживать из конфигурационных файлов, формат
которых базируется именно на системе BIND версии 4.

Глава 14. Реализация сервера имен
Программа named при своем запуске сначала читает конфигурационный
файл named.boot. Согласно инструкции, приведенной в файле named.
boot, при запуске выполняется чтение с диска информации баз данных
DNS и сохранение ее в кэш-память. Местоположение
конфигурационного файла задается с помощью параметра, который указывается в
командной строке. По умолчанию используется каталог /etc.
Конфигурационный файл named. boot содержит следующие команды:
• directory — указывает на каталог на диске, содержащий
информацию баз данных DNS. В прочих командах указываются имена
файлов без пути к ним. Пример:
directory /etc/namedb
• primary — определяет, что сервер имен будет являться первичным
для домена, указанного как первый параметр команды, а также на
то, что соответствующая база данных находится в текстовом файле,
указанном как второй параметр. Пример:
primary pvt.cz db.pvt.cz
Каждый сервер имен должен быть первичным, по крайней мере для
домена 0.0.127. in-addr. arpa. Это означает, что, даже когда мы
имеем дело с сервером имен типа Caching only, в конфигурационном
файле обязательно должна присутствовать, например, команда:
primary 0.0.127.in-addr.arpa db.0.0.127
• secondary — определяет, что сервер имен будет являться вторичным
для домена, заданного первым параметром. Прочими параметрами
являются IP-адреса серверов, из которых будут передаваться
данные. Эти параметры должны быть указаны как IP-адреса. Передача
данных осуществляется с помощью программы named-xfer. Если
указан последний параметр (он не может быть указан в форме
IP-адреса), то он считается именем того файла на компьютере, в который
должны быть сохранены данные после их передачи. Пример:
secondary cbu.pvt.cz 172.17.14.1 172.17.18.1 cbu.pvt.cz.tmp
Данная команда предписывает получение авторитетных данных
о домене cbu.pvt. cz с помощью запроса zone transfer из сервера
с IP-адресом 172.17.14.1 и сохранение их в файл cbu .pvt. cz . tmp.
Если этот сервер недоступен, то данные копируются с сервера
172.17.18.1.
15 Зак.518
449

TCP/IP и DNS в теории и на практике. Полное руководство
Если имя файла не указано (последний параметр), то переданные
данные не сохраняются на диск (они будут сохранены только в
кэшпамять).
• cache — определяет, из какого файла должна быть скопирована и
перенесена в память компьютера информация о корневых серверах
имен. Пример:
cache . cache.db
Данная команда предписывает копирование данных о корневых
серверах имен из файла cache.db и сохранение их в памяти
компьютера. Этот файл не содержит авторитетных данных, то есть
первоначально он не содержит записи SOA. Каждая его запись должна
содержать все явно указанные данные, в особенности массив TTL.
Однако будьте внимательны! Если в корневом сервере имен, в
конфигурационном файле, будет содержаться не команда cache, а
команда primary.db.root, то файл db.root будет содержать данные,
аналогичные тем, которые содержатся в файле cache. db. Однако
сначала в нем будет лишь запись типа SOA, причем важно отметить,
что отдельные записи файла не должны содержать массив TTL — его
значение будет заимствовано из записи типа SOA.
• forwarders — указывает, что локальный сервер имен должен
передавать запросы forwarder-серверу. В качестве прочих параметров
указываются IP-адреса доступных в Интернете серверов имен. Пример:
forwarders 193.85.240.40 193.85.240.40
В примере один и тот же IP-адрес написан два раза, в этом нет
ошибки. В команде forwarders тем самым увеличивается временной
интервал, в течение которого локальный сервер ожидает ответа от
forwarders, прежде чем сам не вступит в контакт с корневыми
серверами имен.
Директива slave следует за командой forwarders в том случае, если
мы хотим, чтобы локальный сервер работал как slave-сервер. Это
значит, что сервер имен ни в коем случае не должен обращаться
к корневым серверам имен. Пример:
forwarders 193.85.240.40 193.85.240.40
slave
Пример конфигурационного файла для первичного сервера имен
домена pvt . cz :
450

Глава 14. Реализация сервера имен
directory /etc/namedb
primary pvt.cz db.pvt.cz
primary 17.172.in-addr.arpa db.172.17
primary 0.0.127.in-addr.arpa db.127.0.0
cache . db.cache
14.2. База данных DNS и ее записи
14.2.1. Синтаксис базы данных DNS
START
I
named, boot
Л\
Отдельные базы данных ► Память
Рис. 14.1. Программа named во время своего запуска
узнает информацию о базах данных DNS в файле named. boot
Базы данных DNS хранятся на первичном сервере имен в файлах. При
запуске сервера имен их содержимое загружается в память компьютера.
Имена файлов базы данных DNS указываются как последние
параметры отдельных команд конфигурационного файла named.boot. База
данных на диске может содержать следующие типы данных:
• Авторитетные данные для зоны обработки. В самом начале должна
быть приведена запись типа SOA. При этом данные могут храниться
только на первичном сервере имен. Вторичный сервер имен
получает их с помощью запроса zone transfer от первичного или другого
вторичного сервера имен.
• Данные, позволяющие получить доступ к корневым серверам имен
(зоны Cache/hint). Здесь нет записи SOA, поэтому явно в отдельных
записях должен быть приведен массив TTL. Эти данные не
являются авторитетными для локального сервера имен. Они должны быть
на каждом сервере имен, за исключением slave-сервера и корневого
сервера.
451

TCP/IP и DNS в теории и на практике. Полное руководство
• Данные, с помощью которых сервер имен передает полномочия на
управление субдоменами другим серверам имен. Для делегирования
полномочий используются записи типа NS. Эти данные относятся
к вышестоящей зоне, для которой локальный сервер является
авторитетным. Если полномочия делегируются серверу имен, чье
доменное имя является неотъемлемой частью субдомена, в отношении
которого делегируются полномочия, то к записи типа NS добавляется
еще запись типа А, определяющая IP-адрес данного сервера имен.
Стандартный синтаксис отдельных строк базы данных (так называемых
DNS-записей):
[name] [TTL] класс тип Данные_зависящие_от_типа_записи
Поля в квадратных скобках [ ] необязательны для заполнения —
значения в них берутся из предыдущей записи (например, из записи SOA).
Комментарии отделены друг от друга точкой с запятой.
Значение отдельных полей:
1. Поле name содержит доменное имя. В этом случае может быть
несколько ситуаций:
• Поле не заполнено, тогда значение в нем берется из поля name
предыдущей записи.
• В записи типа SOA в поле name может быть значение @. Данное
значение показывает, что в поле name необходимо добавить имя
домена, указанное в соответствующей команде файла named,
boot.
• Доменное имя указано в поле name без точки на конце. В таком
случае автоматически к этому имени в поле добавляется имя
домена, указанное в записи SOA. В случае, если перед записью (без
точки на конце) указана команда $ORIGIN, в поле добавляется
имя домена, указанное в команде $ORIGIN.
• Имя домена указано в поле name с точкой на конце — мы имеем
дело с абсолютным именем домена, которое приводится в
соответствии с его написанием.
2. Поле TTL содержит срок жизни записи в памяти (указан в секундах).
Сервер имен автоматически уменьшает это значение. В тот момент,
когда данное значение достигнет нуля, запись будет объявлена
недействительной. По умолчанию значение в поле равно нулю. Однако
452

Глава 14. Реализация сервера имен
если данной записи предшествует запись типа SOA, то значение по
умолчанию берется из поля TTL записи типа SOA. Запись типа SOA
всегда указывается в начале файла, то есть наша запись не должна
непременно предшествовать ей.
3. Класс — IN (Internet), HS (Hesiod) или СН (Chaos). В нашем случае
мы будем заниматься исключительно записями типа IN
(существуют реализации программы named, поддерживающие Hesiod, но мы
ими заниматься не будем).
4. Тип — один из тех типов, которые указаны в таблице 11.1.
5. Последнее поле содержит данные, зависящие от типа записи. Если
здесь используется доменное имя, то не забудьте после него
поставить точку. В противном случае к этому имени автоматически
будет добавлено имя домена. Напротив, если здесь указан IP-адрес, то
необходимо помнить, что за четвертой цифрой в IP-адресе точка не
ставится.
Cm.RFC-1035.
14.2.2. Формат записей в базе данных DNS
Имена в базе данных должны стоять на первом месте. Если первым
символом в строке является пробел, то используется имя из предыдущей
строки. Файл состоит из типов записей {resource records), указанных
в таблице 11.1.
Запись SOA
Запись типа SOA (Start Of Authority) — задает сервер имен, который
является авторитетным источником информации для данного домена.
Запись SOA всегда стоит особняком в начале файла.
В качестве примера приведем запись для сервера домена pvt. cz.
@ IN SOA cbu.pvt.cz. bindmaster.cbu.pvt.cz. (
1 /Serial
86400 /Refresh after 24 hours
600 ;Retry after 5 min.
120960 /Expire after 2 weeks
86400 ) /Minimum TTL of 1 day
453

TCP/IP и DNS в теории и на практике. Полное руководство
В этом примере:
• Имя pvt. с z должно быть на первом месте в строке и должно
кончаться точкой. Оно обозначает название зоны. Как правило, вместо
имени зоны здесь стоит символ @, который указывает на то, что имя
зоны необходимо взять из другого параметра (то есть имени домена)
команды файла named. boot.
• IN означает тип адреса (IN Internet).
• Первое имя за SOA (cbu.pvt. cz .) — это имя компьютера, в
котором хранятся данные (имя первичного именного сервера), а второе
имя (bindmaster. cbu. pvt. cz .) задает почтовый адрес лица,
ответственного за данные. Если символ @ имеет в записи SOA особое
значение, то тогда вместо данного символа в почтовом адресе
ставится точка, то есть вместо bindmaster@cbu.pvt. cz пишется
bindmaster.cbu.pvt.cz.
• Скобки позволяют продолжить запись в следующих строках (для
лучшей читаемости).
• Serial обозначает серийный номер версии файла базы данных. При
замене файла необходимо увеличить данный номер. Мы советуем
вам использовать номер ггггммддн (год, месяц, день, номер
обновления в рамках дня). Вторичный сервер имен отправляет запрос
первичному серверу имен только на запись типа SOA. Он
сравнивает значение массива serial в записи типа SOA, причем только в том
случае, если первичный сервер имен имеет в записи типа SOA
значение массива serial, которое больше, чем значение вторичного
сервера имен. Далее осуществляется передача данных зоны от первичного
сервера имен на вторичный. Если администратор внесет изменения
в базу данных DNS на первичном сервере имен и забудет увеличить
значение массива serial, то никакие вторичные данные не будут
переданы, и никаких изменений на вторичном сервере имен не
произойдет. При обнаружении такой ошибки администратора
первичного сервера имен у вас есть единственная возможность удалить на
вторичном сервере имен файл для соответствующей зоны —
завершить работу программы named на вторичном сервере имен и снова
ее запустить. Значение массива serial не оказывает влияния на
работу первичного сервера имен, то есть, если вы забудете увеличить
значение массива на первичном сервере имен, то после перезапуска
сервера имен на первичном сервере имен изменения произойдут.
454

Глава 14. Реализация сервера имен
Следующие значения дают различную информацию о времени в секундах:
• Refresh — предоставляет информацию о том, как часто вторичные
серверы должны сверять свои данные. Если при такой сверке будет
обнаружено, что на сервере имеются данные с более низким
значением serial, то в таком случае будет осуществлена передача данных
зоны с помощью протокола TCP.
• Retry — если вторичный сервер не может связаться с первичным по
истечении временного интервала refresh, он будет делать попытки
вновь связаться с первичным сервером каждые ... секунд, заданные
значением retry.
• Expire — если вторичному серверу имен не удастся связаться с
первичным до истечения временного лимита expire, то предоставление
информации будет прекращено (ввиду устаревания данных).
Должно иметь силу следующее: Expire > Refresh.
• TTL — данное значение имеет отношение ко всем записям в файле
базы данных (как исходное значение) и указывается сервером имен
в каждом его ответе. Информирует о том, как долго могут
остальные серверы (неавторитетные) хранить данную запись в своей
кэшпамяти (значение, равное нулю, препятствует сохранению записей
в кэш-память).
Если вы не знаете, какие значения необходимо задать в записи SOA, то
воспользуйтесь тем, что рекомендует RFC-1537 для доменов верхнего уровня:
86400
7200
2592000
345600
Для остальных доменов:
28800
7200
604800
86400
Refresh 24 hours
Retry 2 hours
Expire 3 0 days
Minimum TTL 4 days
Refresh 8 hours
Retry 2 hours
Expire 7 days
Minimum TTL 1 day
Записи типа А
Записи типа A (Address) присваивают доменным именам компьютеров
IP-адреса. За IP-адресом нельзя ставить точку.
455

TCP/IP и DNS в теории и на практике. Полное руководство
Пример:
pvt.cz. IN SOA . . .
WWW IN A 172.17.14.1
www.cbu IN A 172.17.18.1
muj.cbu.pvt.cz. IN A 172.17.14.2
tvuj IN A 10.1.1.3
В примере записи типа А компьютерам присваиваются IP-адреса:
www.pvt.cz, www.cbu.pvt.cz, muj.cbu.pvt.cz и tvuj.pvt.cz.
Записи типа CNAME
С помощью записей типа CNAME создаются синонимы для доменных
имен. При этом создаются альтернативные имена для компьютеров.
Пример:
firma.cz. IN SOA
mail IN A 192.1.1.2
www IN CNAME mail.firma.cz.
В этом примере описана ситуация, когда в компании имеется один
компьютер mail. firma. cz, который ее сотрудники желают использовать
и как WWW-сервер.
В правой части команды CNAME должно быть указано доменное имя,
которому с помощью записи типа А присваивается IP-адрес.
В правой части не должно быть синонима, то есть CNAME не должно
указывать на CNAME. Далее показана ошибочная передача имен.
Пример (ошибочный!):
firma.cz. IN SOA
mail IN A 192.1.1.2
www IN CNAME mail.firma.cz.
server IN CNAME www.firma.cz.
456

Глава 14. Реализация сервера имен
В записях типа CNAME следует быть внимательными при написании
точки в конце полного имени домена. Мы принципиально стараемся
в правой части указывать точку в конце полного имени домена. В том
случае, если мы не поставим точку, к этому имени будет добавлено еще
имя домена.
При работе с маленькими базами данных администратор увидит
результат такого добавления. Однако, по мере увеличения базы данных,
подобную ситуацию становится сложно отыскать.
Записи типа HINFO и ТХТ
Записи типа HINFO и ТХТ являются исключительно информативными.
Запись типа HINFO имеет в своей информативной части два значения.
Первое значение содержит информацию об устройствах, а второе —
о программном обеспечении.
Запись ТХТ содержит в своей информативной части текстовую строку.
Пример:
firma.cz. IN SOA
mail IN A 192.1.1.2
IN HINFO AlphaServer UNIX
IN TXT Muj server
Записи типа NS
Записи типа NS определяют авторитетные серверы имен для домена.
В правой части должно быть указано доменное имя, которому
посредством записи типа А присвоен IP-адрес. Справа не должно быть
синонима, то есть запись типа NS не может указывать на запись типа CNAME.
Одинаковые записи типа NS всегда находятся в двух базах данных: в
базе данных более высокого уровня и на авторитетном для зоны сервера
имен. С помощью записей типа NS полномочия передаются серверу
имен более низкого уровня. В случае, если название сервера имен более
низкого уровня само находится в домене более низкого уровня, к этой
записи типа NS должна быть еще добавлена запись типа А с IP-адресом
сервера имен.
457

TCP/IP и DNS в теории и на практике. Полное руководство
Это необходимо, чтобы можно было попасть на сервер имен более
низкого уровня. Сервер имен более высокого уровня должен указывать IP-
адрес сервера имен более низкого уровня в разделе дополнительной
информации в DNS-ответе.
Рассмотрим пример. Допустим, авторитетный сервер имен зоны более
высокого уровня f irma. cz делегирует полномочия на управление
доменом cbu. f irma. cz серверу ns . cbu. f irma. cz. Если нижестоящий
сервер имен является элементом нижестоящего домена, то необходимо
в вышестоящую зону добавить неавторитетную запись типа А для
компьютера ns . cbu. f irma . cz:
IN
IN
IN
IN
IN
IN
IN
SOA
NS
NS
A
NS
NS
A
ns ,
ns,
11.
ns
ns,
11,
.provider.cz.
.firma.cz
.1.1.1
.firma.cz.
.cbu.firma.cz.
.2.2.2
На сервере имен домена cbu. f irma. cz, то есть на авторитетном
сервере имен домена более низкого уровня, имеется база данных:
cbu.firma.cz. IN SOA ...
IN NS ns.firnta.cz.
IN NS ns.cbu.firma.cz.
ns IN A 11.2.2.2
Опять следует подчеркнуть, что в правой части записей типа NS лучше
писать полные имена доменов с точкой на конце.
Записи типа MX
Запись MX показывает, на какой компьютер должна быть доставлена
почта для домена. В этой записи имеется числовой приоритет, с чьей
помощью можно определить несколько компьютеров, на которые можно
отправлять почту для домена. Сначала делается попытка доставить
почту на компьютер самого высокого уровня приоритета (с самым низким
числом), а затем, если это сделать не удастся, на следующий компьютер
(с более высоким числом) и т. д.
458

Глава 14. Реализация сервера имен
В нижеприведенном примере описана ситуация, когда почта для
домена f irma. cz должна быть доставлена на компьютер mail. f irma. cz.
Если этот компьютер недоступен, то почта будет отправлена на
компьютер mai 11. provider. сz, где она будет дожидаться того момента,
когда компьютер mail. firma.cz станет доступным. Если и компьютер
maill.provider.cz недоступен, то почта будет отправлена на
компьютер mail2 .provider . cz.
Пример:
firma.cz. IN SOA ...
IN MX 3 0 mail2.provider.cz .
IN MX 20 maill.provider.cz.
IN MX 10 mail.firma.cz .
mail IN A 11.1.1.8
Записи типа PTR
Запись типа RTR служит для преобразования IP-адреса в доменное имя,
то есть для преобразования элементов домена in-addr.arpa в имя
компьютера.
Пример:
ЗаписитипаКТЫдлякомпьютерапз. f irma. czcIP-адресом 195.47.200.1
и для компьютера www. f irma. cz с IP-адресом 195.47.200.201:
1.200.47.195.in-addr.arpa. IN PTR ns.firma.cz.
201.200.47.195.in-addr.arpa. IN PTR www.firma.cz.
Однако данный пример совершенно оторван от контекста, для его
понимания необходимо пояснить весь механизм делегирования. Подробное
описание механизма делегирования рассмотрим на следующем
примере. Предположим, что нашей компании (firma.cz) выделены
IP-адреса в диапазоне 195.47.200.0/24, то есть целая сеть класса С. Обратное
преобразование осуществляется следующим образом:
На корневых серверах Интернета выполняется делегирование зоны
195 . in-addr.arpa серверам имен для Европы — ns .ripe.net. При
использовании корневыми серверами программы named версии 4
делегирование осуществляется так:
А: в файле named. boot была бы строка:
459

TCP/IP и DNS в теории и на практике. Полное руководство
primary . root.db
В: файл root. db содержал бы следующее:
195.in-addr.arpa IN NS ns.ripe.net
ns.ripe.net *' IN A 193.0.0.193
195.in-addr.arpa IN NS ns.apnic.net
ns.apnic.net IN A 203.37.255.97
195.in-addr.arpa IN NS munnari.oz.au
munnari.oz.au IN A 128.250.22.2
IN A 128-.250.1.21
Зона 19 5 . in-addr. arpa так важна, что в настоящее время в ней 7
авторитетных серверов, находящихся по всему миру.
На сервере имен ns . ripe. net, то есть на сервере имен более высокого
уровня для Европы (Амстердам):
А: в файле named.boot будет присутствовать, например, следующая
строка:
primary 195.in-addr.arpal95.rev
В: в файле 19 5 . rev будет, к примеру, указано следующее:
195.in-addr.arpa. IN SOA
200.47 IN NS ns.firma.cz.
IN NS ns.provider.cz.
На сервере имен ns. f irma. cz (первичном сервере имен):
А: в файле named. boot будет присутствовать, к примеру, следующая
запись:
primary 200.47.195.in-addr .arpa 200.47.195.rev
В: в файле 200.47.195.rev будет, например, указано следующее:
200. 47.195. in-addr. arpa. IN SOA ...
IN NS ns.firma.cz.
IN NS ns.provider.cz.
1 IN PTR ns.firma.cz.
201 IN PTR www.firma.cz.
460

Глава 14. Реализация сервера имен
На сервере имен ns. provider. cz (вторичном сервере имен):
В файле name. boot будет содержаться, например, следующая строка:
secondary 200.47.195.in-addr.arpa 195.47.200.1 200.47.195.rev
Необходимо снова напомнить о том, что нельзя забывать ставить
точки после имени компьютера (справа), так как в случае отсутствия точки
к доменному имени будет добавлено имя домена, заканчивающееся на
in-addr. arpa, что на самом деле является недопустимым.
Вероятно, вы ждете, что я сделаю еще акцент на том, что справа не
должно быть также синонима (CNAME), то есть запись типа PTR не должна
указывать на запись типа CNAME. Однако все совсем иначе — синоним
может быть. Долго это считалось ошибкой в системе BIND, пока не стало
использоваться как полезный инструмент и даже как норма RFC-2317.
Данному вопросу посвящена глава 16.
Записи типа SRV
Запись типа SRV была предложена в качестве эксперимента в RFC-
2052, в окончательном виде введена в RFC-2782. Основное различие
между обеими нормами заключается особенно в том, что RFC-2782
ставит символ подчеркивания ( _ ) перед названием службы и названием
протокола. Записи типа SRV используют Windows 2000.
Назначение записи SRV состоит в том, чтобы в базе данных DNS
хранились не только имена компьютеров, но также и имена служб. Мы уже
встречались с такой ситуацией в случае с записями MX, где службой
являлась электронная почта. Записи типа MX определяют почтовые
серверы, на которые должна отправляться почта. С помощью иерархии
показано, с каким почтовым сервером необходимо связаться в первую
очередь, а с какими — после.
Остановимся на примере с WWW-серверами. Если мы хотим получить
информацию о некой чешской компании, то напишем в окне браузера
следующее:
http://www.firma.cz
Это означает, что мы хотим с помощью протокола HTTP связаться
с WWW-сервером из домена firma.cz. То, что интернет-серверы
называются WWW-серверами, является неписаным правилом.
461

TCP/IP и DNS в теории и на практике. Полное руководство
Запись типа SRV информирует DNS о том, как найти соответствующий
интернет-сервер. В нашем случае мы будем искать в DNS имя (протокол
HTTP использует для передачи своих данных протокол TCP):
http.tср.www.firma.cz.
Синтаксис записи SRV может быть представлен следующим образом
(код в протоколе DNS имеет для записи типа SRV значение 33):
_Служба._Протокол.доменное-имя [TTL] IN SRV Приоритет
Процентная_доля Порт Компьютер.
Где:
• Служба — здесь задается символическое имя службы (сервера),
например: http, smtp и т. д.
• Протокол — в этой части записи указывается протокол (например,
tep или udp).
• Приоритет — здесь устанавливается приоритет. Компания может
использовать несколько интернет-серверов для того, чтобы в случае
сбоя всегда какой-нибудь сервер был доступен. Для компании
предпочтительно в такой ситуации установить иерархию, позволяющую
определить, с каким сервером клиенту необходимо связаться в
первую очередь, а с каким — после.
• Процентная доля — интернет-сервер компании может быть
чрезвычайно перегружен, в этой ситуации компания может использовать
несколько серверов одного уровня приоритета, работающих
параллельно друг с другом. Они запускаются на разных компьютерах
неодинаковой мощности. С этой целью вводится понятие процентной
доли. Вот пример DNS, в котором есть две записи:
_http._tcp .www.finna.cz. IN SRV 10 1 80 serverl.firma.cz.
Ш SRV 10 3 88 server2.firma.cz.
Поскольку обе записи имеют одинаковый уровень приоритета, то
в случае, если оба сервера доступны, клиент может установить
соединение с любым из них по своему усмотрению. Однако server 2 .fir-
ma . cz является более производительным, чем serverl. f irma. cz.
Процентная доля указывает на то, что, несмотря на произвольность
выбора сервера для подключения к нему большого количества
установленных соединений, 25% соединений должно быть установлено
462

Глава 14. Реализация сервера имен
с serverl. f irma. cz, a 75 % соединений — с server2 . f irma. cz,
то есть сервер 2 в три раза более производительный, чем сервер 1.
Нулевая процентная доля предназначена для администраторов, так
как в этом случае не проводится никакого сравнения мощностей
компьютеров,
• Порт — здесь указывается порт, на котором работает сервер.
• Компьютер — в данной части записи указывается имя компьютера
(ссылка на запись типа А), на котором имеется служба (где работает
сервер). Если здесь стоит точка, то службы нет.
Пример:
;$ORIGIN firma.cz.
@ IN SOA ...
IN NS
; Следующие строчки определяют, что с помощью протокола telnet
; должно быть ; установлено соединение либо с сервером 1, либо с сер-
; вером 2.
; Сервер 2 в три раза более производительный.
_telnet._tcp IN SRV 0 1 23 serverl.firma.cz.
IN SRV 0 3 23 server2.firma.cz.
; В случае, если серверы 1 и 2 недоступны, администратор должен
; установить соединение с сервером 3:
IN SRV 10 0 23 server3.firma.cz.
; Эксплуатируются два интернет-сервера. Клиент долженустановить
; соединение с сервером 1, а случае недоступности соединение
; устанавливается с сервером 2, но на порте 88:
_http._tcp IN SRV 0 0 80 serverl.firma.cz.
IN SRV 5 0 88 server2.firma.cz.
; Поскольку обычным делом в случае с протоколом^ tp является напи-
; сание WWW перед именем домена, мы добавим еще:
_http.__tcp.www IN SRV 0 0 80 serverl.firma.cz.
IN SRV 5 0 88 server2.firma.cz.
; Мы не должны забывать о записях типа А. С помощью символа @
; специфицируется текущий домен (для того чтобы имя не было
взято ; из предыдущей записи):
463

TCP/IP и DNS в теории и на практике. Полное руководство
@ IN A 10.1.1.2
IN A 10.1.1.2
; Разумеется, мы указываем также записи типа А отдельных серверов:
serverl IN A 10.1.1.1
server2 IN A 10.1.1.2
server3 IN A 10.1.1.3
; Прочие службы не поддерживаются:
*._tcp IN SRV 0 0 0
*._tcp IN SRV 0 0 0
Во всей книге мы последовательно старались избегать использования
звездочек в имени домена. На практике мы много раз убеждались в том,
что звездочки в имени — причина неожиданного возникновения
ошибок, поэтому они используются только в записях типа MX и, возможно,
будут фигурировать в будущем в записях типа SRV.
В чем заключается принцип действия звездочки? Представим себе
пример с записью типа А:
*.firma.cz IN A 10.1.1.10
На любой запрос касательно элемента домена f irma. cz, который явно
не указан на DNS, DNS будет выдавать ответ о том, что адресом
является 10.1.1.10. То есть, что у компьютера 1 pocitacl. f irma. cz — адрес
10.1.1.10, у компьютера 2 pocitac2 . f irma. cz — тоже адрес 10.1.1.10
и т. д. Даже если бы мы и желали этого, при ошибочном написании
(например, когда вместо pocitacl. f irma. cz написано pocitacl. f irma. cz)
DNS не информирует нас об ошибке, а просто возвращает адрес, причем,
скорее всего, не тот, который мы ждем.
14.2.3. Специальные команды для работы с записями DNS
Команда $ORIGIN
В параметре name записи базы данных указывается либо абсолютное
(с точкой на конце), либо относительное (без точки) доменное имя.
Именно к относительному доменному имени автоматически
добавляется имя домена, установленное по умолчанию. Команда $ORIGIN
служит для изменения домена, используемого по умолчанию. В базе
данных DNS может содержаться команда:
464

Глава 14. Реализация сервера имен
$ORIGIN домен_по умолчанию.
С этого момента домен по умолчанию меняется на значение, указанное
как первый параметр команды SORIGIN.
В случае если приводится относительное имя, оно дополняется полным
именем путем добавления домена, указанного в записи типа SOA или в
параметре команды SORIGIN, которая предшествует записи базы данных.
Так команда SORIGIN изменяет имя домена, установленного по
умолчанию:
• Если домен, используемый по умолчанию, не изменен с помощью
команды SORIGIN, то берется домен из команды SOA.
• Если в записи SOA вместо домена стоит символ @, то берется первый
параметр команды primary или secondary из файла /etc/named,
boot.
Команда $INCLUDE
В исходный файл на диске можно вложить еще один файл по команде:
$INCLUDE файл
Файл помещается на место команды. Можно еще указать:
$ INCLUDE файл домен_по умолчанию
Тем самым не только файл станет вложенным, но также будет изменен
и домен, используемый по умолчанию. Изменение домена,
установленного по умолчанию, имеет отношение только к строкам вложенного
файла.
14.2.4. Реализация в Windows Server 2000/2003
На серверах Windows DNS-сервер реализован как служба «Сервер
DNS». Управляет ею из консоли (Microsoft Management Console —
команда MMS) модуль snap-in, именуемый «DNS».
В Windows 2000/2003 можно использовать DNS-сервер как
самостоятельный элемент (точно так же, как и программу named, описанную
в разделе 14.2) или можно DNS включить в Active Directory. Сначала
мы рассмотрим сервер DNS, работающий самостоятельно.
465

TCP/IP и DNS в теории и на практике. Полное руководство
Когда вы в первый раз после установки сервера DNS сделаете
попытку запустить модуль snap-in под названием «DNS», на экране появится
текстовое сообщение с рекомендацией конфигурировать DNS-сервер.
Только после его конфигурирования вы сможете осуществить запуск.
Конфигурирование выбранного сервера осуществляется с помощью
меню, которое активизируется нажатием правой кнопки мыши или
выбором команды Action.
В процессе конфигурирования сервера система задает вопрос
относительно того, должен ли наш сервер быть корневым или нет. Корневой
сервер устанавливается, например, в сети Интранет, если мы хотим,
чтобы в нем были не данные со всего Интернета, а только имена из нашей
внутренней сети (подробности читайте в главе 18). Если мы укажем, что
наш сервер должен быть корневым, то будет сформирован домен «.».
В процессе конфигурирования мы затем можем создать зоны для
отдельных доменов.
Результат конфигурирования сервера показан на рис. 14.2.
Рис. 14.2. Модуль snap-in, именуемый «DNS»
466

Глава 14. Реализация сервера имен
Предположим, что после конфигурирования DNS-сервер начал
работать. Выбрав с помощью правой кнопки мыши «All tasks» , можно
остановить работу сервера, запустить, перезапустить его и т. д.
Допустим, что в каталоге %SystemRoot%\system32\dns имеются
файлы с базами данных DNS:
• файл root. dns, содержащий записи для домена «.»;
• файл cache. dns для зоны Cache/hint.;
• файл firma.cz. dns для зоны firma. cz.;
• файл 1.168.192. in-addr. arpa. dns для обратной зоны.
Данные файлы имеют такой же синтаксис, что и файлы, описанные
в разделе 14.2. Рассмотрим, например, файл firma.cz. dns
(комментарий опущен):
@ IN SOA Id.firma.cz. administrator.firma.cz. (
2 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3 600 ) ; minimum TTL
@ NS ld.firma.cz.
Id A 192.168.1.5
muj-pocitac A 10.1.1.10
Используя правую кнопку мыши в модуле snap-in «DNS», мы можем
отобразить свойства нашего DNS-сервера (см. рис. 14.3). Свойства DNS-
сервера находятся на отдельных вкладках:
• Вкладка Root Hints позволяет редактировать файл cache. dns.
• Вкладка протоколирования Monitoring позволяет регистрировать
в файле отдельные действия сервера. Текстовый файл протокола
формируется в каталоге %SystemRoot%\system32\dns.
• Вкладка Interfaces позволяет указывать сетевые интерфейсы, на
которых сервер ожидает поступление запросов.
• Вкладка Forwarders позволяет разрешить запросы, не обслуженные
сервером.
• Вкладка дополнительных настроек Advanced, при использовании
которых путем выбора пункта «При запуске скачивать данные
467

TCP/IP и DNS в теории и на практике. Полное руководство
зоны» можно указать, откуда должны скачиваться данные — из
каталога %SystemRoot%\system32\dns или из Active Directory.
Если установлено считывание из файлов, то в указанный
каталог мы можем поместить файл boot , синтаксис которого
аналогичен синтаксису файла named.boot системы BIND 4-й версии
(см. п. 14.2.1). Запуск DNS-сервера будет осуществляться в
соответствии с этим файлом.
На рис. 14.3 изображены также вкладки Logging и Security. Весьма
важны также отдельные опции вкладок. На вкладке Advanced можно задать
следующие опции для сервера:
• Запрет рекурсивной передачи данных: сервер не будет обрабатывать
рекурсивные запросы (например, запросы резолверов).
• Создание вторичных соединений: делает возможным zone transfer
и для более старых серверов DNS (например, для более ранней версии
BIND, чем 4.9.4), которые не используют функцию сжатия записей.
• Продолжение или прекращение загрузки данных в кэш-память: при
неудачном прочтении ввиду отсутствия данных зоны сервер
протоколирует ошибки в скачиваемых файлах зоны.
• Активизация циклического алгоритма Round Robin (см. п. 11.8.1).
• Включение режима сортировки в соответствии с сетевой маской.
• Предохранение промежуточной памяти от засорения.
Отдельные параметры DNS-сервера сохранены в в виде параметров
регистра, находящихся в ключе HKEY_LOCAL_MACHINE\SYSTEM\
Current-ControlSet\Services\DNS\Parameters. Приведем хотя
бы некоторые из них:
• BootMethod (типа REG-DWORD): указывает, откуда скачивается
информация баз данных DNS: 1) из файла; 2) из регистра Windows;
3) из Active Directory
• DatabaseDirectory (типа REG-SZ): задает каталог, в котором
находятся базы данных DNS (по умолчанию установлен %SystemRoot%\
system32\dns).
• DisableAutoReverseZone (типа REG_DWORD): открывает
(значение 0) либо закрывает (значение 1) процесс автоматического
генерирования обратных доменов 0 . in-addr .агра (обратное
преобразование 0.0.0.0), 127 . in-addr. агра (обратное преобразо-
468

Глава 14. Реализация сервера имен
вание 127.0.0.1) и 255 . in-addr .arpa (обратное преобразование
255.255.255.255).
• EventLogLevel (типа REG_DWORD): определяет значимость
документируемой информации. 0 — ничего не документируется; 4 -
документируется по максимуму; 2 и 3 — промежуточные ступени.
• Forwarders (типа REG_SZ): содержит список forwarder-серверов,
отделенных друг от друга запятой.
• IsSlave (типа REG_DWORD): 0 — сервер не является
slave-сервером; 1 — наш сервер является slave-сервером.
• ListenAddress (типа REG_BINARY): содержит список IP-адресов,
которые наш сервер слушает.
• LogFHleMaxSize (типа REG_DWORD): содержит максимальный
размер протокола (log).
• LogFilePath (типа REG_DWORD): содержит имя протокола и путь
к нему.
• LogLevel (типа REG_DWORD): содержит таблицу двоичных
данных, которые должны быть протоколированы.
• NoRecursion (REG_DWORD): 0 — сервер обрабатывает DNS-за-
просы по их признакам, то есть рекурсивные запросы — с рекурсией,
нерекурсивные — без рекурсии; 1 — все запросы сервер обрабатывает
без рекурсии.
• UpdateOptions (типа REG_DWORD): содержит побитовую маску.
Присваивая отдельным битам значение 1, мы ограничиваем
динамический update. Самый низкий бит ограничивает динамический
update записей типа SOA. Второй самый низкий бит ограничивает
динамический update записей типа NS. Установив максимальное
значение 80000000 в шестнадцатеричной системе счисления, мы
полностью ограничим динамический update.
Кроме модуля snap-in «DNS» , в Windows 2000/2003 имеется еще и
командно-строковая утилита dnscmd.exe. С ее помощью можно
отобразить информацию о локальном сервере:
dnscmd . /info
DNS-сервером можно управлять с помощью команды net. Так, работу
сервера можно прекратить следующей командой:
net stop dns
469

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 14.3. Свойства DNS-сервера
Если вы желаете активизировать в Windows 2000/2003 службу Active
Directory, то вам необходимо осознавать, что Active Directory будет
использовать DNS для поиска своих служб. Эти службы будут называться
DNS в записях типа SRV, поэтому DNS-сервер должен поддерживать
этот тип записей.
Далее необходимо отметить, что для Active Directory было бы
предпочтительно, если бы эти службы можно было регистрировать на DNS
динамически (с помощью динамического update). Если сервер не
поддерживает динамический update (динамическое обновление), то в блоке
домена имеется файл %systemroot%\System32\conf ig\netlogonme,
содержащий пакет записей типа SRV, которые мы статически помещаем
на DNS.
470

Глава 14. Реализация сервера имен
Теперь с помощью команды dcpromo мы можем установить Active
Directory.
В Active Directory используется пространство имен, которое по
стечению обстоятельств делится на домены, как и пространство имен DNS.
Серверы имен данного пространства имен называются блоками
доменов. Речь идет о двух пространствах имен, которые не имеют ничего
общего друг с другом. Они просто оба интегрированы в одну базу
данных — Active Directory.
Было бы непрактично, если бы компьютер рос it ас . f irma. cz
назывался бы неодинаково в Windows и в TCP/IP. В связи с этим оба
пространства имен используют по стечению обстоятельств одинаковые
имена (идентичные строки в именах). Я понял это в тот момент, когда
мне надо было выдавать сертификаты для объектов этих пространств
имен. В сертификате указывается название объекта.
Имя из пространства DNS (DNSname) пишется в следующей форме:
pocitac . f irma. cz, а имя из пространства имен Active Directory
записывается так: ОС=компьютер,ОС==компания,ОС=сг.
14.3. BIND нового поколения (версии 8 и 9)
Начиная с 8-й версии, BIND полностью переработан. Новая версия
BIND поддерживает некоторые новые механизмы DNS.
Начиная с версии 8.1, BIND поддерживает:
• Динамическую актуализацию DNS — Dynamic update (RFC-2136).
• Уведомление об изменениях в DNS — DNS notify (RFC-1996).
• Инкрементную передачу зоны IXFR (RFC-1995).
Начиная с версии 8.2, BIND поддерживает:
• Негативный Caching (RFC-2308).
• DNS Clarifications (RFC-2181).
• DNSsec (RFC-2065) — подробности читайте в главе 13.6.
• Виртуальные серверы имен.
471

TCP/IP и DNS в теории и на практике. Полное руководство
Начиная с версии 8.2.2, поддерживается функциональная
совместимость с Windows 2000.
Начиная с версии 9, BIND поддерживает:
• Виды — view для решения split DNS.
• Новые типы записей для преобразования доменного имени
в IPverze6.
• Обратный домен ip6 . arpa и формат bit-string для записи
обратного домена IPverze6.
Обзор главных изменений в собственной реализации BIND 8.x по
сравнению с BIND версии 4.x:
• BIND 8-ой версии использует новый конфигурационный файл —
/etc/named.conf,
• BIND 8 позволяет детально конфигурировать протоколирование
сообщений.
• BIND 8 устанавливает контроль доступа с помощью ACL.
• BIND 8 использует новую структуру master-slave.
Обзор главных изменений в реализации BIND версии 9.x по
сравнению с BIND 8.x:
• Способ обработки ошибок в файлах зоны и конфигурационном
файле named.conf.
• Команда $TTL.
• BIND 9-й версии использует по умолчанию так называемый формат
many-answer для zone transfer.
• Административные инструменты — программа rndc.
• BIND 9 — многопоточная программа.
• Поддержка контроля доменных имен.
• Новая библиотека для резолвера Lightweight.
• Полная поддержка для IPverze6.
Существуют разные версии программы BIND для самых различных
операционных систем. Мы тестировали как версию под UNIX, так и версию
под Windows. Версия под Windows имеет ряд следующих преимуществ:
472

Глава 14. Реализация сервера имен
• Отпала необходимость в компиляции, так как в ней содержатся уже
скомпилированные программы. При этом необходимо отметить, что
в особенности компиляция 9-й версии программы осложнена тем,
что, в отличие от других версий, в ее комплект поставки не входит
OpenSSL. Таким образом, если вы хотите активизировать DNSsec, то
для этого заранее надо скомпилировать OpenSSL.
• Сервер имен работает под управлением версий Windows, которые
сами не являются сервером, то есть, например, под Windows 2000
Professional или Windows XP.
• В комплект поставки входят также и проверочные программы,
например dig, которые являются практичными даже тогда, когда вы
используете сервер имен из Windows 2000.
14.4. Конфигурационный файл BIND
Конфигурационный файл программы BIND версии 8 и более поздних
версий, как правило, называется /etc/named, conf.
Конфигурационный файл BIND 8.x составляют команды и комментарии. Команды
заканчиваются точкой с запятой (;). Конфигурационные файлы,
используемые в BIND 4.9x, можно преобразовать в новый формат с помощью
PERL-скрипта named-bootonf .pi, который входит в исходный набор
инструментов BIND 8.
При наличии ошибок в файле named, conf, запуск BIND 9-й версии
вызывает появление фатальной ошибки. Отметим, что предыдущие
версии BIND, как правило, запускались даже тогда, когда некоторые их
функции не работали.
Несмотря на то, что конфигурационный файл нового поколения BIND
имеет новый синтаксис по сравнению с версией 4, синтаксис базы
данных DNS (записей типа SOA, A, PTR, NS и т. д.) остается в BIND 8.x
неизменным. Файлы баз данных для BIND 9-й версии расширены,
например, за счет введения новых типов записей RR. Описание таких
нововведений вы найдете в разделе 14.6.
473

TCP/IP и DNS в теории и на практике. Полное руководство
14.4.1. Команды конфигурационного файла
Следует отметить следующие команды конфигурационного файла BIND:
• ad — задает список IP-адресов, который используется, например,
для управления доступом;
• control — задает управляющий канал, используемый утилитой rndc
(команда используется, начиная с 9-й версии);
• include — вкладывает файл;
• key — определяет данные, используемые при аутентификации и
авторизации с помощью TSIG;
• logging — определяет события, которые будут протоколироваться,
а также то, куда будет сохранена протоколированная информация;
• options — задает общую конфигурацию сервера;
• server — настраивает некоторые свойства для удаленных серверов;
• trusted-keys — задает ключи trusted DNSSEC (команда
используется, начиная с 9-й версии);
• view — задает режим просмотра (команда используется, начиная с 9-й
версии);
• zone — задает зону
Команды logging и option могут быть использованы в
конфигурационном файле только один раз. Некоторые команды конфигурационного
файла могут иметь большое число параметров.
Описание всех параметров превратило бы следующую главу в самую
скучную часть книги. В связи с этим было решено дать подробное
описание только тех параметров, которые используются чаще всего.
Чтобы читатель не почувствовал себя обделенным, а смог получить
представление о возможностях конфигурирования сервера имен,
приведем для каждой команды ее полный синтаксис.
14.4.2. Примеры конфигурирования name server
Для начала, чтобы вам легче было понять, о чем идет речь, приведем
несколько примеров конфигурирования для разных типов именных
серверов.
474

Глава 14. Реализация сервера имен
Кеширующий name server (Caching-only name server)
Текст конфигурационного файла кеширующего name server'a (Caching-
only name server) приведен в листинге 14.1.
Листинг 14.1. Caching-only name server
#
# caching-only name server
#
// доступ к серверу имеют только узлы из двух сетей
acl " povolsite " { 195.47.37.0/24; 195.47.31.0/24; };
// определение группы IP адресов
options {
directory "/etc/namedb"; // рабочий каталог, в котором сохранены
// файлы зоны
pid-file "named.pid"; // файл в рабочем каталоге, в котором
// сохранен PID процесса
allow-query { " povolsite "; }; // запросы IP адресов из группы
//" povolsite " будут удалены сервером
};
// root name servery - зона «hint»
zone "." { type hint; file "root.hint"; };
// обратная маршрутизация для 127.0.0.1
zone "0.0.127.in-addr. arpa" {
type master;
file "localhost. rev";
notify no;
};
Авторитетный name server
Текст конфигурационного файла авторитетного name server'a приведен
в листинге 14.2.
Листинг 14.2. Авторитетный name server
#
# первичный named.conf
#
options {
475

TCP/IP и DNS в теории и на практике. Полное руководство
directory /§tc/master";
pid-file "named.pid"; //файл находится в рабочем
//каталоге, в котором хранится PID процесса
allow-query { any; }; //установленное по умолчанию
//значение подачи запроса разрешено из всех сетей
recursion по; //сервер не выполняет рекурсивные преобразования
logging {
channel protocol {//определение канала для записи ошибок
file "log/protokol.txt" versions 5 ;
severity debug;
};
channel vyst {
file "log/vystup.log";
} ;
category default { //присвоение категории «default»
каналу//«protocol»
} ;
category ncache {
vyst;
} ;
category db {
vyst;
zone '0.0.127 . in-addr.arpa" in {
type master;
file "127.0.0";
} ;
zone " . " in {
type hint;
file "named.cache";
} ;
zone "abcde.cz" in { // name server является первичным
для //домена abcde.cz
type master;
notify yes;
file "abcde.cz.zone";
} ;
zone "pvtnet.cz" in { // name server является вторичным
//(slave) для домена pvtnet.cz
type slave ;
masters { 194.149.105.18;} ;
476

Глава 14. Реализация сервера имен
file "pvtnet.cz.zone";
} ;
zone "pvt.net" in {
type stub;
masters { 194.149.105.18;) ;
file "pvt. net. zone";
} ;
14.4.3. Использование комментариев
Комментарии в конфигурационном файле могут быть представлены
в трех видах:
• /* в виде, принятом в С */;
• //в виде, принятом в C++;
• # в виде, принятом в PERL.
Комментарий в стиле С (V) может означать текстовое примечание в
виде части строки или, напротив, текст, состоящий из нескольких строк,
Комментарий в стиле C++ или PERL означает всегда однострочное
примечание. Точнее сказать, комментарием считается текст, начинающийся
символом // или # и заканчивающийся концом строки.
Внимание!
Не используйте в качестве символа для комментария точку с запятой,
которая здесь означает конец команды.
Пример:
/* Многострочный комментарий в стиле С
заключен между символами «звездочка» и «косая черта» */
// Многострочный комментарий в стиле C++ должен в каждой
// строке начинаться двумя символами «косая черта»
Данная строка не является комментарием и способствует
появлению ошибки
//
• комментарий в стиле PERL
• еще строка комментарий в стиле PERL
477

TCP/IP и DNS в теории и на практике. Полное руководство
14.4.4 Команда acl
Синтаксис:
acl jmeno {
seznam IP adres
} ;
Описание:
Команда acl формирует и дает имя списку IP-адресов, используемых
для контроля доступа. Данный список должен быть задан до его первого
использования.
Предварительно заданными являются следующие списки acl:
• any — обозначает все узлы;
• попе — обозначает пустое множество узлов;
• localhost — обозначает адрес IPverze4 всех интерфейсов в системе;
• localnets — обозначает все узлы в сетях IPverze4, где система имеет
интерфейс.
14.4.5. Список IP-адресов
Синтаксис:
Seznam__IP_adres = l*prvek_seznamu
Seznam_IP_adres = [ " ! " ] (ip_adresa_ip__pref ix I acl_jmeno I seznara_
IP_adresIkey_IO)
Описание:
Список IP-адресов — это список элементов. Элементом могут быть:
• IP-адрес (десятичные числа, отделенные друг от друга точкой).
• IP-префикс (в форме записи с использованием „/").
• Имя ранее заданного списка IP-адресов.
• Вложенный список IP-адресов.
• Имя ключа key ID, заданное в команде key (начиная с 9-й версии).
Если перед элементом мы поставим восклицательный знак «!» , то
данный элемент будет запрещен.
478

Глава 14. Реализация сервера имен
Просмотр списка IP-адресов в процессе их сравнения начинается с
левой стороны. При нахождении первого подходящего элемента процесс
сравнения прекращается. Если сравнение даст положительный
результат, то доступ может быть получен, в противном случае доступ будет
запрещен. Если IP-адрес не найдется в списке, то доступ для компьютера
с данным IP-адресом будет запрещен.
Заданный таким образом список IP-адресов можно использовать в
параметрах остальных команд: allow-query, allow-transfer, allow-update
и listen-on.
Пример:
1.2.3/24; ! 1.2.3.13; # 1.2.3.13 совершенно излишни
! 1.2.3.13; 1.2.3/24; # правильно, доступ разрешен только
IP 1.2.3.13 остальным из
# 1.2.З.* доступ запрещен
14.4.6. Команда controls
Синтаксис:
controls {
inet (ip_adr I *) [ port ip_port ] allow { address_match_
list} keys {key_list };
Описание:
• Команда controls задает канал, используемый административной
утилитой rndc для передачи сигналов серверу имен. Канал в
атрибуте inet задается IP-адресом и портом. По умолчанию используется
порт 953. Посредством данного канала серверу имен можно посылать
сигналы из сети. Использовать каналы разрешено узлам, указанным
в условии allow, с применением ключа, указанного в условии keys.
• Allow — распознавание IP-адресов (список ACL), у которых есть
доступ к каналам. Если составной частью списка ACL является имя
ключа, то оно игнорируется.
• Keys — список имен ключей, которые можно использовать для
аутентификации доступа к каналу. Ключ используется для подписи,
посылаемой в канал.
Если в конфигурационном файле не указана команда controls, то сервер
имен определяет именной канал, заданный IP-адресом 127.0,0.1 или ;;1
479

TCP/IP и DNS в теории и на практике. Полное руководство
(IPv6) и портом 953. Для подписания сообщения можно использовать
ключ, хранящийся в файле: /etc/rndc . key.
Создание ключа /etc/rndc. key обеспечивает утилита rndc-confgen -a.
При переходе от BIND 8-й к 9-й версии можно использовать
конфигурационный файл named, conf без команды controls. Для утилиты
rndc используется канал, описанный выше. Единственное, что нужно
сделать — это сгенерировать соответствующий ключ. После перехода
на 9-ю версию BIND генерирование ключа осуществляется командой
rndc-keygen-a.
Пример использования команды controls приведен в п 14.4.2.
14.4.7. Команда include
Синтаксис:
include cesta;
Описание:
• Команда include вкладывает указанный файл на место, где
находится команда include.
• Команду include нельзя использовать внутри другой команды.
Пример ошибочного использования:
ad int_host { "include ost_host.acl" } ;
Пример:
include "/etc/security/keys.bind";
include "/etc/acls.bind
14.4.8. Команда key
Синтаксис:
key key_id {
algorithm algorithm_ld;
secret secret_string;
} ;
480

Глава 14. Реализация сервера имен
Описание:
Команда key задает ключи шифрования, используемые в TSIG. Ключи
шифрования обозначаются с помощью идентификатора key_id,
который имеет форму доменного имени. Эти ключи используются для
доступа к другим серверам имен.
Ключи шифрования должны быть заданы с помощью команды key перед
тем, как они будут использованы в команде server. Иными словами,
команда key должна быть указана в конфигурационном файле до команды
server. Команду key можно также использовать в рамках команды view.
Команда key, заданная вне view, применяется ко всем view, для которых
явно не указана другая команда key.
• Команда key применяется и для задания ключа, используемого
программой rndc.
• Algorithmic! — это строка, определяющая алгоритм аутентификации.
Единственным поддерживающим алгоритмом является hmac-md5.
• Secret_string — это пароль, используемый алгоритмом. Пароль
зашифрован base-64.
Заданный таким образом ключ может быть использован в команде server
или как элемент списка ACL.
14.4.9. Команда logging —
протоколирование нестандартных ситуаций
Описание команды logging
Синтаксис:
logging {
[ channel channel_name {
( file path_name
[ versions ( number I unlimited ) ]
[ size size_spec ]
I syslog ( kern I user I mail I deamon I auth I syslog I lpr I
news I uucp I cron I authpriv I ftp I
localO I locall I local2 I local3 I
local4 I local5 I local6 I local7 I
I stderr
16 Зак. 518
481

TCP/IP и DNS в теории и на практике. Полное руководство
I null );
[ severity ( critical I error I warning I notice
info I debug [ level ] I dynamic ); ]
[ print-category yes_or_no; ]
[ print-severity yes_or_no; ]
[ print-time yes_or_no; ]
} ; ]
[ category category__name {
channel_name; [ channel_name; ... ]
} ; ]
};
Описание:
Команда logging определяет способ фиксации сообщений об ошибках,
поступивших от сервера имен. Она определяет, какие типы событий
будут протоколироваться. В конфигурации можно указать несколько
команд logging, однако выполняться будет всегда только первая команда
logging.
Сервер имен разделяет типы сообщений на группы, или категории —
categories. В качестве примера категории приведем категорию config,
которая содержит сообщения об ошибках, касающиеся
конфигурационного файла. Особое место занимает категория под названием
default. Данная категория включает в себя все остальные категории,
за исключением тех, которые непосредственно указаны в команде
logging. Список всех категорий сообщений об ошибках вы найдете
в документации к именному серверу, которая входит в каждый
комплект поставки.
Сообщения данной категории записываются посредством каналов —
channels. Каналом определяется, куда и в каком формате будет
записываться сообщение. Как и у категории, у канала есть свое имя.
Таким образом, в команде logging мы задаем, какая категория будет
записываться на тот или иной канал. Если мы не направим какую-либо
категорию ни на один канал, то такая категория будет записываться на тот
же канал, что и категория default. Если мы не укажем в команде logging
категорию default или вовсе не укажем команду logging, то будет
применена следующая настройка по умолчанию:
482

Глава 14. Реализация сервера имен
category "default" {"default_syslog"; "default_debug";};
Одна команда logging может задавать произвольное количество каналов
и категорий.
В BIND 9 команда logging активизируется только после выполнения
всего файла named, conf. В этом отличие этой версии от 8-й версии
BIND, в которой команда активизировалась в момент ее появления
в named. conf, то есть раньше.
Сообщения об ошибках, появившиеся при запуске BIND 9, мы будем
напрасно искать в заданных нами специальных каналах, так как
сообщения с момента запуска сервера записываются на default-канал или,
если мы используем переключатель -g, в стандартный системный файл,
предназначенный для хранения сообщений об ошибках.
Создание канала протоколирования
Теперь подробнее остановимся на задании канала.
Для каждого канала мы должны задать, куда будут записываться
сообщения, насколько важные ошибки будут записываться каналом, а также
нужна ли запись так называемых меток времени.
Канал может записывать сообщения:
• в файл, если мы выберем file — при этом мы можем задать
максимальный размер файла и количество версий;
• в системный журнал, если мы выберем syslog — при этом запись
регулируется конфигурационным файлом syslog. conf ;
• в системный журнал, содержащий сообщения об ошибках, если
осуществлен выбор stderr;
• сообщения не будут записываться, если осуществлен выбор null.
Пример задания канала, именуемого zkusebni_kanal —
«испытательный канал»:
logging {
channel "zkusebni_kanal" {
file "zkusebni.log" versions 4;
print-time yes;
print-category yes;
483

TCP/IP и DNS в теории и на практике. Полное руководство
print-severity yes;
severity warning;
} ;
category default t {
zkusebni_kanal;
} ;
} ;
Канал zkusebni_kanal из примера будет записывать сообщения
в файл zkusebni . log. При каждом перезапуске сервера будет открыт
новый файл. Старый файл будет переименован. У текущей версии
число 0. В канале будут храниться 4 версии файла, более ранние версии
будут автоматически удалены.
Размер файла является неограниченным. В файл будут записываться
метки времени, наименование категории данного сообщения и уровень
значимости ошибки. В канал будут записываться ошибки уровня
значимости warning и более поздних. Также в данный канал будут
записываться все типы сообщений, то есть сообщения всех категорий.
В программе named имеется 4 заранее заданных канала:
• Канал channel default_syslog l
channel default_syslog 1 # Сообщения записываются в системный журнал,
severity info: # Записываются сообщения уровня важности info и выше,
syslog daemon; # Syslog регистрирует, какая часть системы генерирует
# события (Kernet#.mail...).
# Данный канал будет регистрировать
# события, как будто они были сгенерированы
# демонами.
} ;
• Канал channel default_debug
channel default_debug {
file "named.run" : # Сообщения записываются в файл named.run
# в рабочем каталоге.
severity dynamic; # Сообщения записываются в соответствии
# с текущей настройкой
# уровня debug.
} ;
• Канал channel defaul t_stderr 1
channel defaul t_stderr 1 # Сообщения записываются на stderr.
484

Глава 14. Реализация сервера имен
stderr;
severity info;
};
• Канал channel null
channel null {
null; # Все сообщения, отправленные в этот канал, удаляются.
} ;
Помимо этих четырех заранее заданных каналов, администратор DNS-
сервера может задать и другие каналы. Как только канал задан, его уже
нельзя изменить. Однако мы можем модифицировать способы
использования каналов, изменив способ присвоения им категорий.
По умолчанию все сообщения, генерируемые программой named,
отправляются каналам: default_syslog; default_debug; , то есть
в системный журнал и в файл named. run в рабочем каталоге.
14.4.10. Команда options—
настройка глобальных опций dns-cepbepa
Синтаксис:
options {
version version_string; ]
directory path_name; ]
*[ named-xfer path_name;]
tkey-domain domainname; ]
tkey-dhkey key_name key_tag; ]
dump-fн1е path_name; ]
memstatistics-file path_name; ]
pid-file path_name; ]
statistics-file path_name; ]
zone-statistics yes_or_no; ]
auth-nxdomain yes__or_no; ]
*[ deallocate-on-exit yes_or_no; ]
[ dialup dialup_option; ]
*[ fake-iquery yes_or_no; ]
*[ fetch-glue yes_or_no; ]
*[ has-old-clients yes_or_no; ]
485

TCP/IP и DNS в теории и на практике. Полное руководство
*[ host-statistics yes__or__no; ]
[ minimal - responses yes_or_no; ]
[ multiple-cnames yes_or_no; ]
[ notify yes_or_no I explicit; ]
[ recursion yes_or__no yes__or_no; ]
*[ rfc2308-typel yes_or_no; ]
*[ use-id-pool yes_or_no; ]
*[ maintain-ixfr-base yes_or_no; ]
[ forward ( only I first ); ]
[ forwarders { ip_addr [port ip__port] : [ ip_addr [port
ip_port];...]};]
[ check-names ( master I stave I response )( wiarn I fail
I ignore ); ]
[ allow-notify { address_match_l ist }; ]
[ allow-query { address__match__list };]
[ allow-transfer { address_match_list };]
[ al low-recursion { address__match__list };]
[ al 1 ow-v6-synthesi s { address_match_list }; ]
[ blackhole { address_match__list };]
[ listen-on [ port ip_port ] { address__match__list };]
[listen-on-v6 [ port ip_port ] { address_match__list }; ]
[ query-source [ address ( ip_addr I * ) ] [ port (ip_port I *)] ; ]
[ max-transfer-time-in number; ]
[ max-transfer-time-out number; ]
[ max-transfer-idle-in number; ]
[ max-transfer-idle-out number; ]
[ tcp-clients number; ]
[ recursive-clients number; ]
[ serial-query-rate number; ]
[ serial-queries number; ]
[ transfer-format ( one-answer I many-answers ); ]
[ transfers-in number; ]
[ transfers-out number; ]
[ transfers-per-ns number; ]
[ transfer-source (ip4_addr I *) [port ip_port] ; ]
[ transfer-source-v6 (ip6__addr I *) [port ip_port] ; ]
[ notify-source (ip4_addr I *) [port ip_port] ; ]
[ notify-source-v6 (ip6_addr I*) [port ip_port] ; ]
[ also-notify { ip__addr [port ip__port] ; [ ip_addr [port Hp_port] ;...]!;]
[ max-ixfr-log-size number; ]
486

Глава 14. Реализация сервера имен
coresize size_spec ; ]
data size size_spec ; ]
files SHze_spec ; ]
stacksize size_spec ; ]
сleaning-interval number; ]
heartbeat-interval number; ]
interface-interval number; ]
*[ statistics-interval number; ]
*[ topology { address_match_list }];
sortlist { address_match_list }];
[ rrset-order { order_spec ; [ order_spec ; ... ] ] } ;
lame-ttl number; ]
max-ncache-ttl number; ]
max-cache-ttl number; ]
sig - validity - interval number ; ]
*[ min-roots number; ]
use-ixfr yes_or_.no ; ]
provide-ixfr yes_or_.no; ]
request-ixfr yes_or_no; ]
treat-cr-as-space yes_or_no; ]
min-refresh-time number ; ]
max-refresh-time number ; ]
min-retry-time number ; ]
max-retry-time number ; ]
port ip_port; ]
additional-from-auth yes_or_.no;]
additional-from-cache yes_or_no ; ]
random-device path_name ; ]
max-cache-size size_spec ; ]
match-mapped-addresses yes_or_no; ]
};
Параметры, обозначенные символом *, либо не реализуются в BIND 9,
либо их нет в настройках. Описание параметров вынесено в отдельный
раздел (разделе 14.5).
Описание:
С помощью команды option осуществляется настройка глобальных
опций для программы named. Данная команда может использоваться
487

TCP/IP и DNS в теории и на практике. Полное руководство
в конфигурационном файле только один раз. Если команды нет, то
используется исходная настройка.
14.4.11. Команда server
Синтаксис:
server ip_addr {
[ bogus yes_or_no; ]
[ provide-ixfr yes or no; ]
[ request-ixfr yes or no; ]
[ edns yes or no; ]
[ transfers number; ]
[ transfer-format ( one-answer I many-answers ); ]
[ keys { key__id [key_id . . . ] } ; ]
} ;
Описание:
Команда server задает характеристики, связанные с удаленным
сервером имен. Команда может быть на уровне конфигурационного файла
или вложена в команду view. Команда, заданная в рамках view, является
решающей для данного view.
Сервер, предоставляющий ошибочные данные, мы можем обозначить
как bogus. Тем самым мы препятствуем отправлению дальнейших
запросов на данный сервер. Значением bogus, установленным по
умолчанию, является по.
Имя ключа, используемого для подписания запроса, посылаемого на
удаленный сервер, указано в условии keys. Для одного сервера
предусмотрен один ключ.
Остальные параметры команды имеют такое же значение, что и
одноименные параметры команды options. Если параметр указан в команде
сервер, то для данного сервера не будет использоваться значение
параметра, заданное в команде options.
14.4.12. Команда trusted-keys
Синтаксис:
trusted-keys {
488

Глава 14. Реализация сервера имен
string number number number string;
[string number number number string; [... ] ]
} ;
Описание:
Данная команда задает DNSSEC security root. При этом Security root
можно задать, если известен открытый ключ для неавторитетной зоны.
Однако невозможно со стопроцентной гарантией получить данный ключ
с помощью DNS. С того момента, когда ключ обозначается как trusted,
он используется как полноценный ключ для DNSSEC. Резолвер требует
подтверждения DNSSEC для всех данных в субдоменах.
Команда trusted-keys может содержать несколько ключей. Каждый
ключ состоит из доменного имени ключа, признаков, протокола,
алгоритма и ключа, закодированного с помощью алгоритма BASE-64.
14.4.13. Команда view
Синтаксис:
view viewjame [ class ] {
match-clients (address_match_list);
match-destinations iaddress_match_list ) ;
match-recursive-only (yes_or_no);
[ view option; ...]
[zone-statistic yes_or_no;]
[zone_staternent; ...]
} ;
Описание:
Команда view позволяет конфигурировать сервер имен таким образом,
чтобы на один и тот же DNS-запрос он отвечал по-разному в
зависимости от того, кто является отправителем запроса. Такой сервер, например,
может для домена f irma. cz в ответ на запрос из внутренней сети
возвратить информацию об узлах из этого домена, которые находятся во
внутренней сети.
На запрос же из внешней сети он может возвратить информацию только
об узлах из домена f irma. cz, находящихся во внешней сети. Команда
view предлагает элегантное решение для содержимого двух различных
489

TCP/IP и DNS в теории и на практике. Полное руководство
пластов одного домена без необходимости использовать два физических
сервера и управлять двумя серверами имен.
Каждая команда view задает одно DNS-пространство, которое видит
группа клиентов. Группы клиентов задаются при помощи групп ACL.
Сервер использует для передачи данных view, если IP-адрес
клиента, который требует передачи данных, является частью ACL в условии
match-clients и если при этом целевой адрес является частью ACL в
условии match-destinations. По умолчанию для обоих условий настроены
все IP-адреса.
Условие match-recursive-only определяет, что view будет использоваться
только для рекурсивной передачи данных от клиентов, указанных в
условии match-clients. В рамках view с помощью команды zone задаются
зоны.
Для команд view играет роль порядок их очередности в файле named,
conf. DNS-запрос клиента обрабатывается в рамках первой команды
view, при этом клиент должен удовлетворять условиям match-clients
и match-destinations. Клиент видит только зоны, заданные в рамках
данной команды view. Одна зона может быть задана в рамках
нескольких команд view, причем в каждой команде она может иметь иное
содержимое. В рамках view option может быть использовано большинство
опций команды option.
Внимание!
Если вы решите задать в рамках файла named.conf какую-нибудь
команду view, помните, что тогда все зоны должны быть частью
какой-нибудь команды view, то есть весь файл named, conf должен быть
разделен на отдельные view.
Пример конфигурирования с использованием view приведен в
листинге 14.3.
Листинг 14.3. Пример конфигурирования с использованием view
// Name server предназначен для двух сетей, из каждой сети
// видна другая версия домена test.cz
acl "extnet" { 194.17.165.0/24;};
acl "intnet" { 172.17.14.0/24;};
acl "extPM" { 172.17.14.1;}; //обозначение первичного сервера
// для внешней сети
490

Глава 14. Реализация сервера имен
acl "intPM" {172.17.14.2:1; };//обозначение первичного сервера
//для внутренней сети
options {
directory "d:\bind\bind__exe\etc\namedb"; //рабочий каталог
pid-file "named.pid"; // файл, содержащий PID процесса
recursion no; //запрет рекурсивных запросов
allow-query {"extnet"; "intnet";}; //доступ к серверу
//разрешен для сетей 194.17.165.0/24 // и 172.17.14.0/24
view int {//зоны, видимые только для узлов из сети
//172.17.14.0/24
match-clients {172.17.14.0/24; };
option { recursion yes; }; //разрешение на подачу рекурсивных
запросов для узлов из внутренней сети
zone //0.0.127.in-addr.arpa// {
type master;
file "localhost.rev";
notify no;
};
zone " test.cz" {
type slave; // для данной зоны сервер является вторичным
file "int/test.zone "
masters { intPM ;};
notify no;
};
};
view ext { // зоны, видимые для узлов из внешней сети, Из IP
адреса 194.17.165.14
// сервер не преобразовывает, например, запрос в ul.test.cz,
// который имеет IP адрес 194.17.165.30
match-clients {'172.17 .14.0/24;};
options {recursion no;};
zone "test.cz" {
type slave;
file "ext/test.zone ";
masters lextPMI;
491

TCP/IP и DNS в теории и на практике. Полное руководство
notify no;
};
zone "О.О.127.in-addr.arpa" {
type master;
file " localhost .rev " ;
notify no;
};
};
Листинг 14.4. Конфигурирование первичных серверов intPM и extPM
acl "sekNS" { 172.17.57.10;}; //обозначение вторичного сервера имен
options {
recursion по;
allow-query { none; }; //сервер не отвечает ни на какие DNS-
запросы на преобразование а 1
allow-transfег { попе; }; // сервер не разрешает zone
//transfer
notify yes; // сервер посылает сообщения notify
} ;
zone "test.cz" {
type master;
file "test.zone";
allow-query { sekNS; } ; //сервер отвечает на DNS-запросы на
преобразование только вторичному серверу
allow-transfer i sekNS; ); //сервер разрешает zone transfer
только вторичному серверу
} ;
Конфигурирование первичных серверов — extPM и intPM — различается
только содержимым файла базы данных, именуемого test. zone. В
нашем примере вторичный сервер является общим для обеих команд view,
однако каждый первичный сервер имен работает по иному IP-адресу
Оба первичных сервера могут работать на одном компьютере. У
данного компьютера должно быть два IP-адреса, причем каждый сервер имен
должен использовать собственный экземпляр программы named со
своим IP-адресом. Вы спросите: почему? Причина заключается в способе
функционирования запроса zone transfer.
492

Глава 14. Реализация сервера имен
В случае с двумя одинаковыми зонами в разных командах view запрос
zone transfer не способен различить, какую из команд следует
использовать. Поэтому возникает потребность привязать первичный сервер
к каждой из команд view с исключительным IP-адресом.
Soubor
$ttl
@
ns
www
ftp
ul
u2
test
86400
IN
IN
IN
IN
IN
IN
IN
. zone
SOA
NS
A
A
test.cz.kabelova.pvt.cz. (3 86400 600 120960 86400)
ns.test.cz.
172.17.14.23
194.17.165.31
194.17.165.31
172.17.14.30
172.17.14.35
Soubor test_ext.zone
$ttl 86400
@
ns
www
ftp
Ш
IN
IN
IN
IN
SOA
NS
A
A
A
test.cz.kabelova.pvt.cz. (6 86400 600 120960 86400)
ns.test.cz.
172.17.14.23
194.17.165.31
194.17.165.32
Для узлов из сети 172.17.14.0/24 видимой является только зона,
находящаяся в файле test. zone, а не зона из файла test_ext. zone. По
этой причине важно узлы WWW и ftp ( к которым есть доступ из
Интернета и из Интранета) указать в обоих файлах зоны.
14.4.14. Команда zone
Общее описание команды и ее назначения
Синтаксис:
zone domain_name [ ( in I hsI hesiod I chaos ) ] {
type master;
file path_name;
[ check-names ( warn I fail I ignore ); ]
[ allow-update { address_match_list } ;]
[ allow-query { address_match_list } ;]
[ allow-transfer { address_match_list } ;]
493

TCP/IP и DNS в теории и на практике. Полное руководство
[ notify yes_or„no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] } ;
} ;
zone domain_name [ ( in I hs I hesiod I chaos ) ] {
type ( slave I stub );
file path_name;
masters ( ip_addr; [ip_addr; ... ] } ;
[ check-names ( warn I fail I ignore ); ]
[ allow-update { address_match_list } ;]
[ allow-query { address_match__list } ;]
[ allow-transfer { address_match_list } ;]
[ max-transfer-time-in number; ]
[ notify yes_or#/no; ]
[ also-notify { ip_addr; [ ip_addr; ... ] } ;
} ;
zone [ ( in I hs I hesiod I chaos ) ] {
type hint;
file path_name;
[ check-names ( warn I fail I ignore ); ]
} ;
Описание:
Команда zone задает отдельные зоны.
Приведем краткую характеристику отдельных типов зон:
• master — главный источник данных для зоны (в предыдущей версии
BIND речь шла о первичной зоне);
• slave — подчиненная зона является копией главной зоны (в
предыдущей версии речь шла о вторичной зоне);
• stub — зона stub, собственно говоря, является подчиненной, она
заимствует у главного сервера только NS-записи для зоны, а не целую зону;
• hint — в зоне hint приведен список корневых серверов имен,
который используется для поиска корневых серверов;
• forward — в этом случае мы имеем дело не с настоящей зоной, а со
способом обработки запросов на узлы для домена.
494

Глава 14. Реализация сервера имен
Список masters определяет один или несколько IP-адресов, с
которыми slave связывается при актуализации зоны. Если указан параметр file,
то в файл записывается копия. Для зоны типа forward сервер имен
выступает в роли forwarder. За именем зоны может следовать класс. Если
класс не указан, используется in (Internet).
Параметры команды
Большинство параметров команды zone имеет такое же значение, что
и одноименные параметры команды options. Если параметр указан в
команде zone, его значение обладает преимуществом по отношению к
значению параметра в команде options.
• Параметр allow-update — задает узлы, которым разрешено
осуществлять динамический update сервера. По умолчанию динамический
update запрещено осуществлять из всех узлов.
• Параметр update-policy — данный параметр предоставляет
возможность дополнительной, более подробной, настройки правил для
динамического update, чем параметр allow-update. Функцию
разрешения/запрета динамического update мы можем настроить на уровне
доменного имени или группы имен, а не только на уровне всей зоны,
как реализовано в параметре allow-update. Данный параметр
реализован только в 9-й версии BIND. В команде zone мы можем
использовать всегда один из параметров — allow-update или update-
policy.
14.5. Параметры команды options
14.5.1. Спецификация файлов
Параметр directory
В качестве значения параметра directory указывается рабочий каталог
сервера. Каталог может быть представлен в форме абсолютного пути к
нему. Каждый относительный путь к каталогу, указанный в
конфигурационном файле, оценивается по отношению к рабочему каталогу сервера.
В данном каталоге по умолчанию размещается большинство выходных
файлов сервера. Если каталог не указан, то используемым по
умолчанию считается каталог, из которого был запущен сервер.
495

TCP/IP и DNS в теории и на практике. Полное руководство
Параметр named-xfer
Данный параметр своим значением задает путь к программе named-xfer,
который сервер использует для передачи входных данных зоны. Если
путь не указан, то он задается системой. Данный параметр в 9-й версии
не используется. Программа named.xfer является неотъемлемой частью
программы named.
Параметр dump-file
Путь к файлу, в который сервер записывает dump. Сервер
записывает dump при получении сигнала SIGINT или указания от программы
rndc dumpdb. Если путь к файлу не указан, по умолчанию используется
named_dump.db.
Параметр pid-file
В качестве значения этого параметра указывается путь к файлу, куда
сервер записывает свое ID процесса. Если путь не указан, то, как
правило, используется /etc/named.pid nebo /var/run/named.pid.
Параметр statistics-file
Путь к файлу, в который сервер записывает статистические данные.
Статистические данные записываются сервером после получения сигнала
SIGILL или сигнала от программы rndc stats.
Если путь к файлу не указан, то по умолчанию используется named,
stats.
14.5.2. Параметры типа boolean
Параметр auth-nxdomain
Если для этого параметра установлено значение yes, то в ответе
NXDOMAIN (негативном ответе) всегда устанавливается бит АА, даже
если сервер не является авторитетным. В 8-й версии значением,
установленным по умолчанию, является yes, а в 9-й — по.
496

Глава 14. Реализация сервера имен
Параметр fetch-glue
Значением по умолчанию является yes. Если установлено yes, то сервер
добавляет связующие записи. Значение по в настройке можно
использовать в совокупности с recursion no. В 9-й версии данный параметр
не используется.
Параметр multiple-cnames
Если значение этого параметра — yes, то допускается несколько записей
CNAME для доменного имени. По умолчанию установлено по.
Использование нескольких записей CNAME идет вразрез со стандартом и нами
не рекомендуется. Предыдущая версия BIND допускала несколько
записей. BIND версии 9 строго следует правилам, установленным
нормами стандарта по использованию CNAME.
Параметр notify
Если установленным значением является yes, то сервер при
изменении зоны, для которой он является авторитетным, посылает сообщение
Notify (с уведомлением) всем серверам, указанным в записях NS и в
параметре also-notify. Значением по умолчанию является yes.
Нижестоящий сервер, получив понятное для него сообщение Notify, связывается
с главным для данной зоны сервером и при необходимости мгновенно
осуществляет передачу данных зоны.
Использование Notify увеличивает скорость процесса конвергенции
между главным сервером и нижестоящими серверами. Установка
значения по необходима в том случае, если сообщения Notify приводят к
возникновению ошибок или даже влекут за собой крах slave-сервера. Выбор
опции может быть произведен ц команде zone, в этом случае он имеет
преимущество перед настройкой, произведенной в команде option.
Параметр recursion
Если для данного параметра установлено значение yes и DNS-запрос
требует рекурсии, то сервер будет стараться обработать этот запрос.
Если значением данного параметра является по и сервер
непосредственно не знает ответа, то он отсылает клиента к более высокой инстанции.
Значением по умолчанию является yes.
497

TCP/IP и DNS в теории и на практике. Полное руководство
14.5.3. Перенаправление Forwarding
Функцию перенаправления (Forwarding) можно с выгодой для себя
использовать для загрузки большой по объему кэш-памяти и работы с ней
на нескольких серверах. Тем самым уменьшается трафик к внешним
именным серверам.
Функцию Forwarding можно использовать, только если сервер не
является авторитетным для данного запроса и не имеет ответа на него в
кэшпамяти.
Параметр forward
Использовать данный параметр имеет смысл только в том случае, если
в параметре forwarders приводится список серверов, на которые
должны быть пересланы запросы. Значением по умолчанию является first.
Значение first указывает на то, что для обработки запроса сервер делает
попытку установить соединение с forwarder-сервером, если же
последнему не удается обработать запрос, сервер сам пытается сделать это.
Параметр forwarders
В данном параметре указываются IP-адреса серверов для
перенаправления. По умолчанию список является пустым (перенаправление
(forwarding) не осуществляется).
14.5.4. Контроль имен (check-names)
В BIND 8 и в более ранних версиях предусматривалась проверка
доменных имен на наличие запрещенных символов. Вспомним, что
допускаемыми символами являются буквы, цифры и тире. BIND версии 9 не
предусматривает таких проверок, поэтому теоретически можно в
доменном имени использовать произвольный символ. Теоретически
потому, что в большинстве используемых резолверов реализуется контроль
символов, поэтому доменное имя с недопустимыми символами не будет
приниматься резолвером.
Существует три метода настройки функции контроля имен:
• ignore — никакой контроль не осуществляется;
498

Глава 14. Реализация сервера имен
• warn — функция контроля имен активизирована, имена с ошибками
регистрируются, однако процесс обработки данных продолжается;
• fail — функция контроля имен активизирована, имена с ошибками
регистрируются, ошибочные данные удаляются.
Сервер может осуществлять контроль за именами в трех областях: в
файлах главной зоны, в файлах нижестоящей зоны и в ответе на сделанный
запрос. В случае, если установлено check-names response fail и при
этом в качестве ответа сервер должен был бы послать клиенту имя
с ошибками, он отправит ответ REFUSED. Значениями по
умолчанию являются:
• check-names master fail
• check-names slave warn
• check-nained response ignore.
Значение check-names может быть использовано также в команде zone.
В этом случае ему отдается предпочтение перед значением, заданным
в команде options, и при этом не указывается область.
14.5.5. Управление доступом (Access Control)
Отдельные виды доступа к серверу (например, запрос, zone transfer
и т. д.) можно разрешить только некоторым IP-адресам.
Параметр allow-query
Определяет, какие узлы могут сделать текущий запрос. Если здесь
ничего не указано, то по умолчанию текущий запрос разрешается сделать
всем узлам. Значение для allow-query может быть указано также в
команде zone — в таком случае оно обладает преимуществом по
отношению к значению, заданному в команде option.
Параметр allow transfer
Определяет, какие узлы имеют право использовать zone transfer из
сервера. Если здесь ничего не указано, по умолчанию передачу данных зоны
разрешается осуществлять из всех узлов. Значение для allow transfer
499

TCP/IP и DNS в теории и на практике. Полное руководство
может быть указано также в команде zone — в этом случае оно обладает
преимуществом над значением, заданным в команде option.
14.5.6. Сетевые интерфейсы
Параметр listen-on
В этом параметре можно указать интерфейс и порты, откуда сервер
будет принимать запросы, на которые будет отвечать. Параметр listen-on
можно указать несколько раз. Если параметр listen-on не указан, то
сервер слушает на порте 53, на всех интерфейсах.
Пример:
listen-on ( 194.149.100.33; ) ;
listen-on port 2323 ( 1195.47.127.44; 195.47/16 ) ;
Параметр listen-on-verz.e6
Параметр определяет интерфейс и порты, на которых сервер будет
принимать запросы, использующие IPverze6, и отвечать на них. Если
параметр не указан, то сервер не будет реагировать на запросы,
использующие IPverze6.
14.5.7. Передача данных зоны
Параметр max-transfer-time-in
Данный параметр задает количество минут, в течение которых может
длиться передача данных зоны. Если данный процесс займет большее
количество времени, то он будет прекращен. Значением, установленным
по умолчанию, является 120 минут.
Параметр transfer-format
Параметр transfer-format определяет метод передачи данных зоны.
Сервер поддерживает два метода передачи данных зоны:
• one answer — одно DNS-сообщение для передачи одной RR-записи;
• many answers — в одно DNS-сообщение вмещается столько RR-запи-
сей, сколько возможно.
500

Глава 14. Реализация сервера имен
BINt) 9 использует по умолчанию формат many-answer. Это изменение
может способствовать тому, что у вас могут возникнуть затруднения при
использовании slave-серверов тех версий BIND, которые не
поддерживают формат many answer.
Параметр transfers-in
Параметр transfers-in задает максимальное число одновременно
протекающих процессов передачи входных данных зоны. Значением,
установленным по умолчанию, является 10.
Параметр transfers-out
Параметр transfers-out задает максимальное число одновременно
протекающих процессов передачи выходных данных зоны. Значением по
умолчанию является 10. Параметр по-новому реализован в BIND версии 9.
Параметр transfers-per-ns
Параметр transfers-per-ns задает максимальное число одновременно
протекающих процессов передачи входных данных зоны от удаленного
сервера имен. Значением по умолчанию является 2.
14.5.8. Временные интервалы
Параметр clean-interval
Параметр clean-interval в качестве своего значения содержит количество
минут п, через которое сервер будет удалять недействительные записи из
кэш-памяти. По умолчанию установлено значение 60 минут. Если
установлено значение 0, то недействительные записи не удаляются.
Параметр statics-interval
Количество минут п. Статистические данные будут документироваться
каждые п минут. Значением по умолчанию является 60 минут. Если
установлено значение 0, статистические данные не регистрируются.
501

TCP/IP и DNS в теории и на практике. Полное руководство
14.6. Команды редактирования файлов зоны.
Специальные возможности BIND 9
BIND версии 9 вносит изменения и в файлы зоны. Речь идет в основном
о новых командах $TTL и $GENERTE.
14.6.1. Команда $TTL
Существует две возможности: либо в каждом файле зоны должна
фигурировать команда $TTL, которая задает значение TTL,
устанавливаемое по умолчанию для данной зоны, либо в каждой RR-записи
должно быть указано значение TTL. До тех пор, пока это требование
не будет выполнено, сервер при запуске будет выдавать сообщение об
ошибке. BIND версии 8 еще могла использовать значение TTL из
записи типа SOA.
14.6.2. Команда $GENERATE
Команда используется для создания набора RR-записей,
обеспечивающих обратное делегирование подсети. Каждый администратор DNS,
который хотя бы однажды задавал функцию обратного делегирования
для подсети (например, 128 IP-адресов), должно быть, с благодарностью
относится к данной команде.
В главе 16 вы узнаете о том, что для обратного делегирования подсети
необходимо, чтобы в файл зоны было введено несколько записей CNAME.
К примеру, для подсети со 128-ю адресами таких записей будет как раз
128. При этом записи CNAME различаются только в одном месте
IP-адреса (в его конечном байте), причем данное число увеличивается с
каждой записью на единицу (1). Использование директивы обеспечивает
выполнение функции делегирования. Покажем это на примере.
Пример:
Последовательность команд в файле zone:
$ORIGIN 37.47.195.IN-ADDR.ARPA .
$GENERATE 1-2 О NS server$.test.cz.
$GENERATE 1-127 $ CNAME $.0
502

Глава 14. Реализация сервера имен
эквивалентна набору 128-и записей CNAME и 2-х записей NS,
обеспечивающих обратное делегирование.
О . 37.47.19 5.IN-ADDR.ARPA NS server1.test.cz.
0.37.47.195.IN-ADDR.ARPA NS server2.test.cz.
1.37.47.195.in-addr.arpa cname 1.0.37.47.195.in-addr.arpa
2.37.47.195.in-addr.arpa cname 2.0.37.47.195.in-addr.arpa
127.37.47.195.in-addr.arpa cname 127.0.37.47.195.in-addr.arpa
14.6.3 Lightweight resolver
BIND версии 9 во взаимосвязи с поддержкой IPverze6 предлагает новое
решение процесса передачи DNS-запросов. Это решение заключается во
введении новой библиотеки резолверов.
Классические библиотеки, для которых требовалось преобразовывать
IP-адрес в имя и наоборот, использовали циклический резолвер. В
приложения входили библиотеки с резолвером, благодаря чему посылались
запросы на передачу данных локальному серверу имен, как описано
в разделах 11.9 и 11.10.
Циклический резолвер не поддерживает передачу записей типа А6 для
протокола Ipverze6 (см. п. 13.5.2). BIND 9 заменяет циклический резолвер
новым решением. Для передачи данных предлагаются два варианта:
библиотека lightweight resolver и lightweight resolverdaemon. Эти два варианта
осуществляют коммуникацию между собой с помощью протокола LWRES.
Как функционирует данный механизм? Приложение, использующее
IPverze6, компилируется с библиотекой Iwres, которая является
реализацией клиента Iwres. Приложения посылают запрос на преобразование
IP-адреса Iwres-демону (lwresd), который является реализацией Iwres-
сервера. Lwresd — это простой сервер имен для работы с кэш-памятью
(caching only name server).
Данный сервер принимает запросы от приложения в протоколе LWRES,
преобразовывает эти запросы в протокол DNS и отправляет их для
обработки именному серверу. Затем сервер преобразовывает ответ от
сервера имен в протокол Iwres и посылает его приложению. Lwresd способен
осуществлять передачу данных Ipverze4 nIPverze6.
Lwresd по умолчанию принимает запросы, поступающие с IP-адреса
127.0.0.1, на UDP-порте 921. Демон посылает запросы на сервер имен,
503

TCP/IP и DNS в теории и на практике. Полное руководство
К*Щ-
Ш£
"-'• -^ '■:-''' '>
ЩШШЩ-U-^
Пользователь
.;;.*. i.-.:x-
;|:ПР0ТР|ОДЛ ;
'.,:,:,:: il::i
УШ:
РЙШл1ШШ;'1^Ж
ЁЩ?
у^:.Л::::
■/■^'■л
Lwresd
daemon
V^'
<fr—
|||1
\ш*'^--\
lllft
\Шш
УЩ^Ш:::{:::^:,::;-
Iwresd
daemon
шш
гюШМч'Ш'*
т
Пользователь
■;■ ■.••.■■ ■■ •: •■•'
$ш.
щ
£%;■■,;:
Протокол
DNS
Протокол
DNS
С-'
Именной
сервер
Именной сервер
^
/
/ v
Рис. 14.4. Lightweight resolver
указанный в команде nameserver в файле /etc/resolf .conf. Если
ни один из серверов имен не указан в файле или не удалось отправить
запрос, то lwresd сам способен обработать DNS-запрос.
В файл /etc/resolv. conf можно добавить команду Iwserver, которая
задает IP-адрес демона lwresd, если он работает на удаленном
компьютере. Lwresd daemon использует собственный конфигурационный файл
/etc/lwresd. conf . Сервер имен может быть сконфигурирован как
lwresd daemon при использовании команды lwresd в файле named. conf .
14.6.4. Команда Iwres
Синтаксис:
Iwres{
[listen-on { ip_addr [port ip_port] ; [ ip_addr [port ip_
port] : ...] } : ]
view view_name; ]
[ search { domain_name ; [ domain_name; ... ] } ; ]
[ ndots number: ]
} ;
504

Глава 14. Реализация сервера имен
Описание:
Самым важным параметром в команде является параметр listen-on,
задающий список IP-адресов, с которых демон принимает запросы.
Вопрос состоит в том, как этот новый механизм будет работать на
практике. BIND версии 9 уже предлагает классический циклический резолвер,
поддерживающий Ipverze6.
14.7 Инструменты для отладки и управления DNS
14.7.1. Способы контроля над конфигурированием
После конфигурирования сервера имен и его запуска мы должны
проверить правильность его работы. Ошибки DNS очень неприятны, иногда при
таких ошибках приложения даже не начинают работать. Чаще всего
ошибки DNS приводят к значительному замедлению работы всей системы.
Например, если при конфигурировании брандмауэра
обнаруживается длительное время отклика последнего, то, скорее всего, виной тому
неправильная работа DNS. Существуют информационные RFC,
посвященные проблемам DNS. Так, наиболее часто встречаемые ошибки DNS
рассматриваются в RFC-1537, средства же отладки DNS — в RFC-1713.
Контроль над конфигурированием осуществляется двумя способами:
1. Первый способ контроля заключается в том, что мы, вжившись в роль
резолвера, отправляем на DNS-сервер DNS-запросы так, как это
делает резолвер. Мы пытаемся таким образом проверить, придет ли от
сервера имен ответ, соответствующий нашим ожиданиям, или нет.
2. Второй способ контроля — это комплексный контроль (отладка
DNS) с помощью программы, которая знает правила DNS и
осуществляет контроль над выполнением этих правил в доменах, на нашем
сервере имен. Результатом такого способа контроля является список
ошибок, имеющихся в конфигурации конкретного домена.
Оба вышеприведенных способа контроля предполагают, что у нас уже
запущен сервер имен, в результате чего используемые проверочные
программы могут обращаться со своими запросами на работающий сервер
имен. BIND версии 9 теперь предлагает администратору DNS-утилиты,
с помощью которых можно проверить конфигурацию еще до запуска
сервера имен.
505

TCP/IP и DNS в теории и на практике. Полное руководство
В случаях возникновения подозрения о неисправности DNS следует
проверить наличие соединения с Интернетом. Если вы работаете за
персональным компьютером, то проверьте:
1. Правильно ли работает TCP/IP на компьютере с помощью команды:
ping 127.0.0.1
2. Подключены ли вы к маршрутизатору, к локальной сети LAN:
ping IP-адрес маршрутизатора (но ни в коем случае не имя
маршрутизатора!)
3. Установлено ли у вас соединение с локальным сервером имен:
ping 1Р-адрес_сервера имен (но ни в коем случае не название
сервера имен!)
4. Есть ли у вас соединение с окружением:
ping IP-адрес_в__окружении
5. Если у вас есть возможность, проверьте аналогичным образом
наличие соединения с Интернетом из самого сервера имен.
14.7.2. Проверка конфигурационных файлов
Если вы используете BIND версии 9, то мы рекомендуем вам начать
проверку сервера имен с помощью двух полезных программ, которые
могут для вас проверить конфигурационные файлы и обнаружить ряд
маленьких и больших ошибок. Некоторые из обнаруженных ошибок
могут даже препятствовать запуску сервера, при этом их очень сложно
найти иным способом.
Преимущество таких программ заключается в том, что они способны
непосредственно проверять файлы данных, не требуя запуска сервера
имен. Программы named-checkconf и named-checkzone входят в
комплект поставки сервера имен.
Программа named-checkconf
Программа named-checkconf проверяет синтаксис конфигурационного
файла named. conf. Синтаксис команды таков:
named-checkconf [-t directory][filename]
506

Глава 14. Реализация сервера имен
Программа named-checkzone
Программа named-checkzone проверяет синтаксис и содержимое файла
зоны. Синтаксис команды таков:
named-checkzone [-dgv] [-с class] zyne [filename]
14.7.3. Программа nslookup — оптимальный выбор
для тестирования DNS
Общее описание программы
Наиболее часто используемой программой для проверки DNS является
программа nslookup. Эта программа обладает одним большим
преимуществом. В настоящее время она входит в пакет TCP/IP в Unix и в Windows,
поэтому нет необходимости в ее поиске или компиляции.
С помощью программы nslookup мы посылаем DNS-запросы на DNS-
сервер и проверяем, правильные ли ответы выдает сервер. Благодаря
программе nslookup мы можем выступать в роли резолвера, требуя от
сервера имен конечный ответ на наш запрос. Кроме того, с помощью
данной программы мы можем имитировать действия сервера имен,
осуществляющего коммуникацию с другим сервером имен (то есть
требовать лишь частичные ответы).
Все зависит от того, что именно мы хотим проверить с помощью
программы nslookup. По умолчанию данная программа отправляет DNS-
запросы на сервер имен, который настроен в системе как резолвер.
В ОС Unix она посылает запросы на сервер имен, указанный в файле
/etc/resolv.conf.
Программа nslookup запускается в интерактивном режиме командой
nslookup, результатом ее запуска может стать, например, подсказка
(prompt):
Default Server: cbu.pvtnet.cz
Address: 194.149.105.18
>
Ответ информирует нас о том, что сервер cbu.pvtnet.cz в нашей
экспериментальной системе задан в конфигурации резолвера как сервер имен,
используемый по умолчанию. У этого сервера имен следующий IP-адрес:
507

TCP/IP и DNS в теории и на практике. Полное руководство
194.149.105.18. В ответ на обращение программы (prompt) > делаем свой
запрос. Можно, например, запросить IP-адрес или имя какого-нибудь узла.
Задав имя узла, например www.pvt. cz, сервер имен cbu .pvtnet. cz
сделает попытку определить IP-адрес этого узла.
Запрос:
> www.pvt.cz
Server: cbu.pvtnet.cz
Address: 194.149.105.18
Ответ:
Name: www.pvt.с z
Address: 194.149.104.206
>
Задав же IP-адрес, например 194.149.104.206, сервер, используемый по
умолчанию, сделает попытку определить доменное имя узла с данным
IP-адресом.
Запрос:
> 194.149.104.206
Server: cbu.pvtnet.cz
Address: 194.149.105.18
Ответ:
Name: www.pvt.с z
Address: 194.149.104.206
>
Как видно из вышеприведенных примеров, программа nslookup по
умолчанию ищет в DNS соответствующую запись — запись типа А или типа
PTR. С помощью программы nslookup мы можем запросить у сервера
имен любую запись RR. Тип интересующей нас записи задается нами
в программе nslookup при помощи команды:
set querytype=TMn_3anMCM/ которую можно сократить до set
q=TMn записи.
Способ использования мы снова покажем вам на примере. На этот раз
нас будет занимать список серверов, на которые направляется почта для
домена pvt. cz. Мы уже знаем, что в записях MX в файле зоны соответ-
508

Глава 14. Реализация сервера имен
ствующего домена задается, куда направляется почта. Итак, нас
интересуют все записи типа MX, поэтому настроим нужный тип записей (MX):
Запрос:
>set q=mx
> pvt.cz .
Server: cbu.pvtnet.cz
Address: 194.149.105.18
Ответ:
pvt.cz preference = 20, mail exchanger = info.pvt.net
pvt.cz preference = 5, mail exchanger = fw.pvt.cz
pvt.cz preference = 10, mail exchanger = mh.pvt.cz
pvt.cz nameserver = ns.pvt.net
pvt.cz nameserver = nsl.pvt.net
pvt.cz nameserver = snmpO.pvt.net
pvt.cz nameserver = nsO.pipex.net
pvt.cz nameserver = nsl.pipex.net
info.pvt.net internet address = 194.149.104.203
fw.pvt.cz internet address = 194.149.101.194
mh.pvt.cz internet address = 194.149.105.36
ns.pvt.net internet address = 194.149.105.18
nsl.pvt.net internet address = 194.149.103.201
snmp0.pvt.net internet address = 194.149.103.34
ns0.pipex.net internet address = 158.43.128.8
ns0.pipex.net internet address = 158.43.128.103
nsl.pipex.net internet address = 158.43.192.40
nsl.pipex.net internet dddress = 158.43.192.7
>
Для домена pvt. с z почта направляется на узел f w. pvt. с z , а также на
два резервных узла: infо.pvt .net и mh.pvt. cz. Обратите
внимание на то, что программа nslookup выводит на экран не только ответ, но
и прочую информацию из DNS-пакета, полученного от сервера. Кроме
собственно ответа, мы видим также и авторитетные серверы для
домена pvt. cz и IP-адреса всех серверов в ответе. Эту дополнительную
информацию я не буду приводить в следующих примерах, поскольку вам
должно быть все ясно.
509

TCP/IP и DNS в теории и на практике. Полное руководство
Nslookup еще часто используется при определении авторитетных для
домена серверов. На этот раз нас будут интересовать названия серверов
имен, имеющих отношение к данному домену. Необходимую
информацию можно без труда получить, задав тип записи NS:
Запрос:
> set q=ns
> pvt.cz
Server: cbu.pvtnet.cz
Address: 194.149.105.18
Ответ:
pvt.cz natneserver = nsl.pvt.net
pvt.cz nameserver = snmpO.pvt.net
pvt.cz nameserver = nsO.pipex.net
pvt.cz nameserver = nsl.pipex.net
pvt.cz nameserver = ns.pvt.net
Домен pvt. cz передается на 5 авторитетных серверов имен.
Например, если мы не знаем, является ли доменное имя каноническим
или альтернативным, то мы можем воспользоваться настройкой q=any
и определить, таким образом, все записи, относящиеся к данному
доменному имени.
Запрос:
> set q=any
> info.pvt.net
Server: localhost
Address: 127.0.0.1
Ответ:
info.pvt.net CPU = AlphaServer 100 OS = OSF/1
info.pvt.net text = "e-mail: dostalek@pvt.net"
info.pvt.net internet address = 194.149.104.203
В нашем случае доменное имя info.pvt .net фигурирует в 3-х
записях: в записи типа А, типа ТХТ и в записи типа HINFO.
510

Глава 14. Реализация сервера имен
Режим отладки
При поиске ошибки в конфигурации нам часто не хватает информации,
как правило, выдаваемой программой nslookup: мы хотим знать
больше. В этом случае необходимо использовать режим отладки. В
программе nslookup можно настроить два уровня режима отладки: debug и d2.
Уровни режима отладки настраиваются командой set.
Уровень режима отладки debug
Уровень debug позволяет получить детальную информацию из
поступающих DNS-пакетов.
Настройка уровня отладочного режима debug:
> set debug
Если мы обратимся к главе 12 («Протокол DNS» ), то запись,
выводимая на экран в этом режиме отладки, станет более понятной. В записи
отдельные части имеют заголовок. Для того, чтобы можно было лучше
ориентироваться, автор добавил в текст записи комментарий.
Покажем это на примере. Нас будет здесь интересовать IP-адреса узла
testlOO.pvt.net.
Запрос:
> set debug
> testl00.pvt.net
.Server: runner.pvt.cz
Address: 0.0.0.0
Ответ:
Got answer: Первый ответ еще не содержит преобразованный адрес
HEADER:Раздел заглавия
opcode = QUERY, id = 1, rcode = NXDOMAIN
header flags: response, auth. dnswer, want recursion,
recursion avail.
questions = 1, answers = 0, authority records = 1,additional = 0
QUESTIONS: Раздел содержащий запрос
testlO00.pvt.net.pvt.cz, type = A, class = IN
AUTHORITY RECORDS: Раздел об авторитетных серверах
511

TCP/IP и DNS в теории и на практике. Полное руководство
-> pvt.cz
til = 129600 (1 day 12 hours)
origin = mh.pvt.cz
mail addr = hostmaster.pvt.cz
serial = 1996020802
refresh = 10800 (3 hours)
retry = 3 600 (1 hour)
expire = 360000 (4 days 4 hours)
minimum ttl = 129600 (1 day 12 hours)
Второй пакет в нашем случае будет содержать ответ:
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail,
questions = 1, answers = 1, authority records = 4,
additional =• 4
OUESTIONS:
Testl00.pvt.net, type = A. class = IN
ANSUERS:
-> testl00.pvt.net
internet address = 194.149.100.1
ttl = 129175 (1 day 11 hours 52 mins 55 sees)
AUTHORITY RECORDS:
-> pvt.NET
nameserver = NSO.PIPEX.net
ttl = 122697 (1 day 10 hours 4 mins 57 sees)
-> pvt.NET
nameserver = NSl.PIPEX.net
ttJ = 122697 (1 day 10 hours 4 mins 57 sees)
-> pvt.NET
nameserver = ns.pvt.net
ttl = 122697 (1 day 10 hours 4 mins 57 sees)
-> pvt.NET
nameserver = NSl.PVT.net
ttJ = 122697 (1 day 10 hours 4 mins 57 sees)
ADDITIONAL RECORDS:
-> NSO.PIPEX.net
internet address = 158.43.128.8
512

Глава 14. Реализация сервера имен
ttl = 143625 (1 day 15 hours 53 mins 45 sees)
NSl.PIPEX.net
internet address = 158.43.192.7
ttl = 143625 (1 day 15 hours 53 mins 45 sees)
ns.pvt.net
internet address = 194.149.105.18
ttl = 129175 (1 day 11 hours 52 mins 55 'sees)
NSl.PVT.net
internet address = 194.149.103.201
ttl = 129175 (1 day 11 hours 52 mins 55 sees)
Non-authoritative answer:
Name: testl00.pvt.net
Address: 194.149.100.1
Резолвер отправил на сервер имен два запроса и в качестве ответа
получил два пакета. То, почему речь идет о двух запросах, вы уже должны
понимать, прочитав главу о резолвере. Если вам еще не все ясно, я дам
вам подсказку: внимательно посмотрите на доменное имя, которое
запрашивает резолвер.
Уровень режима отладки d2
Уровень d2 позволяет получить детальное описание содержимого
отправляемых пакетов (запросов) и получаемых пакетов (запросов).
Использование уровня режима отладки d2 позволяет получить
полное представление о коммуникации резолвера с именным сервером,
который по результатам выдачи ответов соответствует MS Network
Monitor.
Способ использования данного уровня мы покажем также на примере,
как и в случае с уровнем debug. Вы можете сравнить ответы.
Запрос:
> set d2
> testl00.pvt.net
Server: runner.pvt.cz
Address: 0.0.0.0
17 Зак. 518
513

TCP/IP и DNS в теории и на практике. Полное руководство
Ответ:
SendRequest(), len 40
HEADER:
opcode = OUERY, id = 3, rcode = NOERROR
header flags: query, want recursion
questions = 1,answers = 0,authority records = 0,additional = 0
QUESTIONS:
TestlOO.pvt.net.pvt.cz, type = A, class = IN
Got answer (96 bytes):
HEADER:
opcode = QUERY, id = 3, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion,
recursion avail,
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
Testl00.pvt.net.pvt.cz, type = A, class = IN
AUTHORITY RECORDS:
->pvt .cz
type = SOA, class = IN, dlen = 38
ttl = 129600 (1 day 12 hours)
origin = mh.pvt.cz
mail addr = hostmaster.pvt.cz
serial = 1996020802
refresh = 10800 (3 hours)
retry = 3600 (1 hour)
expire = 360000 (4 days 4 hours)
minimum ttl = 129600 (1 day 12 hours)
SendRequestt(), len 33
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
514

Глава 14. Реализация сервера имен
QUESTIONS:
TestlOO.pvt.net, type = A, class = IN
Got answer (208 bytes):
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 4, additional
QUESTIONS:
Testl00.pvt.net, type = A, class = IN
ANSWERS:
-> testlOO.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.100.1
ttl = 129025 (1 day 11 hours 50 mins 25 sees)
AUTHORITY RECORDS:
-> pvt.NET
type = NS, class = IN, dlen = 15
nameserver = NSO.PIPEX.net
ttl = 122547 (1 day 10 hours 2 mins 27 sees)
-> pvt.NET
type = NS, class = IN, dlen = 6
nameserver = NSl.PIPEX.net
ttl = 122547 (1 day 10 hours 2 mins 27 sees)
-> pvt.NET
type = NS, class. = IN, dlen = 9
nameserver = ns.pvt.net
ttl = 122547 (1 day 10 hours 2 mins 27 sees)
-> pvt .NET
type = NS, class = IN, dlen = 10
nameserver = NSl.PVT.net
ttl = 122547 (1 day 10 hours 2 mins 27 sees)
ADDITIONAL RECORDS:
-> NSO.PIPEX.net
type = A, class = IN, dlen = 4
internet address = 158.43.128.8
ttl = 143475 (1 day 15 hours 51 mins 15 sees)
-> NSl.PIPEX.net
515

TCP/IP и DNS в теории и на практике. Полное руководство
type = A, class = IN, dlen = 4
internet address = 158.43.192.7
ttl = 143475 (1 day 15 hours 51 mins 15 sees)
-> ns.pvt.net
type = A, class = IN, dlen = 4
internet address = 194.149.105.18
ttl = 129025 (1 day 11 hours 50 mins 25 sees)
-> NSl.PVT.net
type = A, class = IN, dlen = 4
internet address = 194.149.103.201
ttl = 129025 (1 day 11 hours 50 mins 25 sees)
Non-authoritative answer:
Name: testl00.pvt.net
Address: 194.149.100.1
>
Замена сервера имен,
используемого по умолчанию
С помощью программы nslookup мы можем отправить DNS-пакет с
запросом на любой сервер имен. Имя проверяемого сервера мы задаем
с помощью команды server.
> server ns.internic.net
После использования данной команды все последующие DNS-запро-
сы будет обрабатывать по-новому настроенный сервер, то есть в нашем
случае сервер ns . internic . net. Эта настройка очень практичная, так
как в большинстве случаев нам кажется из нашей сети LAN, что наш
локальный сервер имен работает правильно. Истинное же суждение мы
можем составить, посмотрев на наш сервер имен с точки зрения другого
сервера имен.
Запись зоны
Если мы хотим, чтобы сервер имен отправил нам полную информацию о
какой-нибудь зоне, надо воспользоваться командой Is -d. В этом случае
мы должны направить запрос на авторитетный для домена сервер. Как
правило, команде Is -d предшествует команда server.
516

Глава 14. Реализация сервера имен
>server ns.pvt.net
> Is -d pvt. cz
Команда Is -d имитирует передачу данных зоны (AXFR) из сервера
имен, поэтому она часто используется при конфигурировании
вторичного сервера имен. С помощью команды Is -d можно без труда
проверить, предоставляет ли первичный сервер имен данные конкретной
зоны вторичному серверу имен для данной зоны.
Если нам не удастся получить ответ от первичного сервера имен с
помощью этой команды, то и вторичному серверу имен, скорее всего, сделать
это не удастся.
Имитация запросов от сервера имен
Если мы хотим имитировать коммуникацию между серверами имен, то
необходимо запретить две опции в настройках программы nslookup,
используемые по умолчанию.
Программа nslookup по умолчанию использует searchlist, то есть, как
резолвер, добавляет по умолчанию домен к доменному имени, после
которого не стоит точка. Запретим это действие командой:
> set nosearch
Nslookup по умолчанию требует от сервера имен рекурсивный, то есть
конечный, ответ. Как нам известно, серверы имен отправляют друг
другу нерекурсивные ответы, поэтому нам необходимо вновь запретить
указанное выше действие. На этот раз командой:
> set norecurse
Наиболее часто встречаемые сообщения
об ошибках программы nslookup
Наиболее часто встречающиеся ошибки таковы:
• No records available — запись требуемого типа не существует.
• No response from server — сервер не работает.
• No information — сервер работает, но не имеет доступа к
информации домена.
517

TCP/IP и DNS в теории и на практике. Полное руководство
• Non-existent domain — не существует обратной записи для названия
именного сервера.
• Can't list domain ... Query refused — сервер работает, но не имеет
доступа к данным домена (срок действия данных истек).
• Unspecified error — точно не установленная ошибка.
14.7.4. Прочие программы,
предназначенные для проверки dns
О некоторых прочих средствах отладки DNS сообщается в RFC-1713.
Там, например, речь идет о программах: ddt2, dnsparse, doc, host,
inetrover и lamer, которые находятся по интернет-адресу: ftp: / / ftp.
uu.net/networking/ip/dns.
Программа Dnswalk
Самой известной программой для отладки DNS является dnswalk.
Причем dnswalk — это скрипт, написанный на языке Perl. Данная
программа «знает» правила для конфигурации DNS и в соответствии
с ними проверяет конфигурацию соответствующего домена. Dnswalk
осуществляет передачу данных зоны из авторитетного сервера имен,
а также проверяет правильность конфигурации домена по различным
критериям.
Программа способна проверять как «прямые», так и «обратные» зоны
домена. Имя проверяемого домена передается программе как параметр,
причем после имени должна стоять точка.
Лучше запускать dnswalk с чужого компьютера, по этой причине в
Интернете существуют Web-серверы, предлагающие формы для проверки
чужих доменов. Такие Web-серверы запускают dnswalk как cgi-script.
Следующий пример иллюстрирует, как используется программа dnswalk
для проверки зоны pvt. net. Точка на конце является обязательной.
$ perl dnswalk pvt.net.
Getting zone transfer of pvt.net. from ns.pvt.net....done.
Checking pvt.net.
SOA=ns.pvt. net. contact=dostalek.pvt.cz.
dhcp-cbu.pvt.net. A 194.149.104.3: no PTR record
518

Глава 14. Реализация сервера имен
dhcp-cbu.pvt.net. А 194.149.104.11:_no PTR record
cbun000e01.pvt.net. 129600 CHAMEpipex-gw.pvt.net.pvt.net.: domain
occurred twice, forgot trailing '.'?
cbun000e01.pvt.net. CHAME pipex-gw.pvt.net.pvt.net.: unknown host
При проверке dnswalk обнаружила сразу три ошибки:
• В домене pvt. net имеется две записи типа А, для которых нет
соответствующей записи PTR. В имени pipex-gw. pvt. net
отсутствует точка на конце, причем CNAME указывает на несуществующий
узел.
• Dnswalk может быть запущена с различными параметрами.
Приведем здесь хотя бы параметры для наиболее часто осуществляемых
проверок.
• Вызов программы dnswalk для проверки домена чаще всего
выглядит следующим образом:
dnswalk - Fralf domena.cz.
Dnswalk доступен на: f tp: / / ftp. math. psu. edu/pub/barr
Программа Dig
Следующей известной программой, используемой для проверки DNS,
является dig. Программа dig отправляет на указанный сервер имен
пакет DNS-query и возвращает пользователю информацию о DNS.
Пользователь может указать, какой сервер должен ответить на запрос, какая
информация его интересует, а также задать дополнительные условия
запроса.
Преимущество данной программы состоит в стандартной форме ответа.
Ответ же вы можете далее обрабатывать с помощью своей программы.
Тогда как nslookup чаще всего используется в интерактивном режиме,
dig, как правило, запускается из пакетов данных.
Типичный синтаксис:
dig ©server domena query-type
После символа @ нами указывается имя сервера, которому мы хотим
отправить запрос. Второй параметр — это имя домена, который мы желаем
проверить. Query-type — нужный тип записи. Вместо строки query-type
519

TCP/IP и DNS в теории и на практике. Полное руководство
мы можем задать произвольный тип записи RR, или строку axfr,
посредством которой делается запрос на передачу данных зоны, или строку
any, которая является запросом на произвольный тип записи.
Пример использования программы dig
В примере необходимо осуществить проверку записей типа тх для домена
pvt. net. Информация запрашивается нами у сервера ns. pvt. net.
dig ©ns.pvt.net pvt.net mx
; <<>> DIG 2.1 <<>> @ns .pvt net pvt.net mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
-»HEADER<<- opcode:
flags: qr aa rd ra
QUESTIONS:
pvt.net, type = MX,
ANSWERS:
pvt. net. 86400
pvt. net. 86400
AUTHORITY RECORDS:
pvt.net. 86400
pvt.net. 86400
pvt.net. 86400
pvt.net. 86400
pvt.net. 86400
QUERY,
; Ques:
class :
status:
1, Ans:
= IN
NOERROR,
2, Auth:
MX '20 mail . uu.net.
MX 10 cbu.pvtnet.cz.
NS ns.pvt.net.
NS nsl.pvt.net.
NS snmp0.pvt.net.
NS ns0.pipex.net.
NS nsl.pipex.net.
ADDITIONAL RECORDS:
-»HEADER<<- opcode: QUERY,
flags: qr aa rd ra ; Ques:
QUESTIONS:
pvt.net, type = MX, class
ANSWERS:
pvt. net. 86400 MX ".
pvt. net. 86400 MX
AUTHORITY RECORDS:
pvt.net. 86400 NS i
pvt.net. 86400 NS i
pvt.net. 86400 NS i
pvt.net. 86400 NS
pvt.net. 86400 NS
;: ADDITIONAL RECORDS:
mail.uu.net. 74570 A
mail.uu.net. 74570 A
mail.uu.net. 74570 A
mail.uu.net. 74570 A
mail.uu.net. 74570 A
mail.uu.net . 74570 A
mail.uu.net. 74570 A
cbu.pvtnet.cz. 86400 A
ns.pvt.net. 86400 A
nsl.pvt.net.
86400 A
192.48.96.15
192.48.96.16
192.48.96.17
192.48.96.5
192.48.96.7
192.48.96.8
192.48.96.14
194.149.105.18
194.149.105.18
id: 10
5, Addit: 15
520

Глава 14. Реализация сервера имен
snmpO.pvt.net.
nsO.pi pex.net.
nsO.pipex.net.
nsl.pipex.net.
nsl .pipex.net.
86400
16958
16958
16970
16970
A
A
A
A
A
194
158
158
158
158
.149.103.34
.43.128.103
.43.128.8
.43.192.7
.43.192.40
;; Total query time: 7 msec
;; FROM: info.pvt.net to SERVER: ns.pvt.net 194.149.105.18
;; WHEN: Tue Aug 18 11:15:20 1998
;; MSG SIZE sent: 25 rcvd: 418
Вместо имени сервера мы можем при вызове программы dig указать IP-
адрес сервера, которому отправлен запрос.
14.8. Дистанционное управление сервером имен.
Программа rndc
Общее описание и методика использования
Программа rndc (remote name server control) позволяет безопасным
образом дистанционно управлять сервером имен. С помощью данной
программы администратор сервера имен может осуществлять действия,
указанные далее в таблице. Программа способна определить PID
сервера имен и послать ему соответствующий сигнал.
Программа rndc разрабатывалась постепенно. Например, 4-я версия для
этой цели предусматривала только сигналы (о сигналах см. раздел 14.9),
которые администратор DNS посылал серверу имен с помощью команд
операционной системы. 8-я версия ввела утилиту ndc, которая предлагала
аналогичный набор функций, однако еще не обеспечивала безопасность.
BIND версии 9 ввела аутентификацию используемого соединения.
Сервер имен версии 9 и его клиент используют для взаимной
идентификации заранее созданный симметричный ключ. Ключ сервера хранится в
файле named, conf, в условии key. У клиента тоже есть ключ, который
находится в файле rndc . key или в конфигурационном файле rndc .conf.
Для генерирования такого общего ключа мы можем использовать
утилиту rndc-confgen -а. Данная утилита создает файл rndc . key. После
этого необходимо обязательно переместить ключ из файла rndc . key
521

TCP/IP и DNS в теории и на практике. Полное руководство
в файл named, conf. При этом важно, чтобы совпадали обозначения
данного ключа, а не только собственно ключ.
Синтаксис вызова программы rndc таков:
rndc [-с config][-s server][-p port][- key] команда
Покажем на примере простой способ использования программы rndc.
Содержимое файла rndc. key:
key "rndc-key" {
algorithm hmac-md5;
secret "WJaYvvX40PPmL0dzv8TSnA==";
};
Часть файла named .conf, относящаяся к утилите rndc:
key "rndc-key" { algorithm hmac-md5; secret
"WJaYvvX40PPmL0dzv8TSnA==" ; ) ;
controls {
inet 194.17.165.23 port 953 allow { 194.17.165.23:194.17.14.
148; 1 keys { "rndc-key"; };
};
Пример использования команды rndc stop:
$rndc -y etc\rndc.key -s 194.17.165.23 stop
Сервер имен вводит в протокол следующие строки и на этом
прекращает свою работу:
Маг 25 10:48:46.902 stopping command channel on 194.17.14.148*953
Mar 25 10:48:46.902 no longer listening on 127.0.0.1#53
Mar 25 10:48:46.902 no longer listening on 194.17.165.23#53
Mar 25 10:48:46.972 exiting
Пример использования команды rndc status:
$rndc -y etc\rndc.key -s 194.17.165.23 status
Запись:
number of zones: 5
debug level: 0
xfers running: 0
522

Глава 14. Реализация сервера имен
xfers deferred: О
soa queries in progress: 0
query logging is OFF
server is up and running
Более детальную информацию о программе и ее конфигурировании вы
найдете в документации, которая входит в каждый комплект поставки
BIND.
Обзор команд программы rndc
Команда Значение
reload Перезагрузка конфигурационного файла и файлов зоны
reconfig Перезагрузка конфигурационного файла и новых или
видоизмененных файлов зоны, неизмененные файлы зоны сюда
не входят
stats Запись статистических данных в файл
querylog Включение функции протоколирования запросов на сервер
имен
dumpdb Запись кэш-памяти сервера в dump-файл
stop Остановка работы сервера и запись изменений, полученных
в результате IXFR или динамического update файлов
halt Незамедлительная остановка работы сервера
trace Увеличение значения уровня отладочного режима сервера на
единицу
notrace Установка уровня отладочного режима сервера на ноль
flush Чистка кэш-памяти сервера
status Предоставление информации о состоянии сервера
523

TCP/IP и DNS в теории и на практике. Полное руководство
14.9. Сигналы
Методика использования сигналов
Программе named можно отправить в системе Unix сигнал с помощью
команды kill. Посредством сигналов можно осуществить аналогичное
количество действий, что и с помощью программы rndc. Как правило,
обрабатываются следующие сигналы: HUP, INT,
ЮТ, KILL, TERM, USR1 и USR2. На конкретную реализацию
сервера имен могут оказывать влияние параметры компиляции программы
named.
В команде kill в качестве второго параметра выступает
идентификатор процесса (PID). Идентификатор процесса — номер, под которым
работает программа named — можно узнать, например, с помощью
команды ps. Впрочем, программа named при своем запуске
записывает номер процесса в файл /cesta/named.pid. Изменить
местоположение и имя данного файла можно при компиляции программы
named.
Например, для сигнала HUP синтаксис команды kill будет выглядеть
следующим образом:
kill -HUP "cat /cesta/named.pid"
Сигнал HUP
С помощью сигнала HUP вы можете заставить сервер имен снова
загрузить данные с диска. Конечно, данный сигнал обычно не позволяет
очистить кэш-память.
Сигнал INT
Сигнал INT вызывает загрузку всех данных (авторитетных и
неавторитетных) из памяти в файл, который, как правило, называется /tmp/
named_dump. db.
Пример фрагмента файла:
; Dumped at Fri Feb 16 18:12:49 1996
; Note: Cr=(auth.answer.addtnl ,cache) tag only shown for
; non-auth RR's
; Note: NT=milliseconds for any A RR which we've ujbed as a nameserver
524

Глава 14. Реализация сервера имен
; - Cache & Data -
$ORIGIN
;Cr=addt
.
518339
518339
518339
518339
518339
518339
518339
518339
518339
86348
:nl
/workgroup 548
Cz
$0RIG1N
96
$ORIGIN
16
$ORIGIN
230
$ORIGIN
1
$ORIGIN
0
$ORIGIN
L
172768
172768
172768
172768
172768
172768
48.192,
518384
518384
518384
518384
IN
IN
IN
IN
IN
IN
IN
IN
IN
Ш
NS A.ROOT-SERVERS.
NS H.ROOT-SERVERS.
NS B.ROOT-SERVERS,
NS С.ROOT-SERVERS,
NS D.ROOT-SERVERS,
NS E.ROOT-SERVERS
NS I.ROOT-SERVERS.
NS F.ROOT-SERVERS.
NS G.ROOT-SERVERS.
. NET.
, NET.
NET.
. NET.
, NET.
NET.
.NET.
NET.
NET.
SCA A.ROOT-SERVERS.NET.roSIMASI^ (
1996021400 10800 900 604800 86400 )
IN
IN
IN
IN
IN
IN
IN
IN-
IN
IN
IN
IN
A NXDOMAIN;-$
NS NS.EUNET.cz.
NS NS.CESNET.CZ.
NS NS.EU.NET.
NS SUNIC.SUNET.SE.
NS NS.UU.NET.
NS SPARKY.ARL.MIL.
■ ADDR.ARPA.
NS NS.UU.NET.
NS UUCP-GW-1.
NS UUCP-GW-2.
NS NS.EU.NET.
96.48.192.IN-ADDR.ARPA.
86385 IN
147.IN-
518391
518391
16.230.
3591
PTR relay6.UU.NET.
■ADDR.ARPA.
IN
IN
147.
IN
NS BUBO.VSLIB.CZ.
NS NS.CESNET.CZ.
IN-ADDR.ARPA.
PTR bubo.vsi ib.cz.
0.127.IN-ADDR.ARPA.
IN
SOA
. 94082701
IN
0.0.127
IN
NS
;Cr=addtnl
;Cr=addtnl
;Cr=a<Wtnl
;Cr=addtnl
;Cr=addtnl
;Cr=addtnl
;Cr=addtnl
;Cr=addtnl
;Cr=addtnl
;Cr=addtnl
;Cr^=addtnl
;Cr=addtnl
mh.pvt.cz hostmaster.pvt.cz. (
10800 3600 360000 129600 )
mh.pvt.cz.
.IN-ADDR.ARPA.
PTR
localhost.
525

TCP/IP и DNS в теории и на практике. Полное руководство
$ORIGIN 85.193.IN-ADDR.ARPA.
240 IN SOA mh.pvt.cz. hostmaster.pvt.cz.(
1996020801 28800 3600 604800 864000 )
IN NS mh.pvt.cz.
IN NS runner.pvt.cz.
IN NS ns.eunet.cz.
$ORIGIN 240.85.193.IN-ADDR.ARPA.
1 IN PTR Ceske-Budejovice.pvt.cz.
$ORIGIN INTERNIC.NET.
NS 3600 IN A 198.41.0.4 ; NT=683
Сигнал ЮТ
Сигнал ЮТ вызывает загрузку статистических данных, как правило,
в файл /tmp/named. stats. Например:
### (824490113) Fri Feb 16 18:01:53 1996
551359 time since boot (sees) количество секунд от начала
551359 time since reset (sees)
6317 08 input packets количество входящих пакетов
637 573 output packets количество исходящих пакетов
621627 queries число запросов
0 iqueries количество инверсных запросов
552 duplicate queries число повторных запросов по достижении
интервала
13053 responses количество ответов от удаленных именных серверов
282 duplicate responses количество дублируемых ответов
серверов имен
42 6098 OK answers количество верных ответов
178 FAIL answers количество ошибочных ответов
2 FORMERR answers количество ответов с отказом
3 525 system queries количество ответов локального
сервера
3 prime cache calls количество считываений данных
корневых серверов
2 checkjs calls количество заполнений поля TTL,
характеризующих доступ к корневому серверу имен,
после каждого заполнения данные будут сохранены
в соответствующем файле
345 bad responses dropped количество ошибочных ответов
от удаленных серверов
526

Глава 14. Реализация сервера имен
2 martian responses количество ответов, посланных
«марсианами» (ответы от неизвестных, удаленных
серверов)
194894 negative responses cached количество кэшированных
отрицательных ответов
О Unknown query types количество запросов на неизвестные
типы записей
520940 A queries количество запросов на записи типа А
14 NS queries запросы
316 CNAME queries запросы CNAME
819 SOA queries запросы SOA
2 MR queries запросы MR
13 045 PTR queries запросы PTR
86064 MX queries запросы MX
2 AXFR queries запросы AXFR (zone transfer)
42 5 ANY queries запросы ANY (*)
Сигнал KILL
Аварийное завершение работы программы named.
Сигнал TERM
Обычное завершение работы программы named.
Сигналы USR1 и USR2
С помощью сигнала USR1 включается отладочный режим загрузки дан-
ныхвфайл /tmp/ named, run. Следующий сигнал USR1 повышает
уровень отладочного режима, то есть количество протоколируемой
информации. Всего предусмотрено два уровня. Сигнал USR2 сразу вызывает
полное выключение отладочного режима (без постепенного понижения
уровня режима). Загрузка данных в отладочном режиме предполагает
также фиксирование отдельных действий сервера имен.
Приведем пример регулировки уровня 1. Имеется в виду
преобразование имени test97 .pvt .net в IP-адрес. Поскольку имя было задано
без точки на конце, то, прежде всего к имени домена было добавлено по
умолчанию еще имя домена pvt .net. Преобразование test97 .pvt.
527

TCP/IP и DNS в теории и на практике. Полное руководство
net. pvt. cz осуществить не удалось, поэтому за этим следует попытка
осуществить преобразование test97.pvt.net. Запрос был
отправлен на авторитетный сервер имен для домена pvt. net с IP-адресом
158.43.128.8.
Debug turned ON, Level 1 (Kill -USRl ...)
datagam from [193.85.240.30] .1824, fd 5, len 39; now Fri Feb 16 18:18:56 1996
req: niookup(test97.pvt.net.pvt.cz) id 512 type=l
req: found 'test97.pvt.net.pvt.cz' as 'pvt.czl (cname=0)
ns_req: answer - [193 . 85 . 240.30] .1824 fd=5 id=2 Local
datagram from [193.85.240.30] .1825, fd 5, len 32; now Fri Feb 16 18:18:56
req: niookup(test97.pvt.net) id 768 type=l
req: found 'test97.pvt.net' as 'pvt.ne (cname=0)
forw: forw - [158.43.128.8].53 ds=7 nsid=72 id=3 Oms retry 4sec
datagram from [158.43.128.8].53, fd 5, len 196; now Fri Feb 16 18:18:57 1996
updatejnsg: msglen:196, c:9
update failed (-10)
send_msg - [193.85.240.30] (UDP 5 1825) id=3
Debug turned OFF (kill -USR2 ...)
14.10. Десять наиболее часто нарушаемых правил
в конфигурации DNS
Правило 1. Каждый узел в Интеренете должен иметь правильно
заведенное в DNS доменное имя. Некоторые службы контролируют наличие
доменного имени в DNS и при его отсутствии не осуществляют
коммуникацию с узлом.
Правило 2. Доменное имя не может содержать другие символы,
кроме букв ACSII, цифр и тире. Имя не может состоять только из цифр,
а также начинаться или заканчиваться символом тире. Хотя символ
подчеркивания допускается использовать в доменном имени в RFC-
1033, однако этот символ не является в соответствии с RFC-1033
стандартом. Во многих реализациях его использование проблематично,
поэтому принципиально мы избегаем использования символа
подчеркивания.
Правило 3. В конце полного доменного имени должна стоять точка. За
IP-адресом точка не ставится.
528

Глава 14. Реализация сервера имен
Правило 4. В электронном адресе в записи SOA символ @ должен быть
заменен точкой.
Правило 5. В правой части записи NS должно быть указано
каноническое имя, в правой части данной записи не может быть указан IP-адрес.
Правило 6. Запись А и запись PTR должны содержать в себе
идентичную информацию.
Правило 7. В записях PTR, MX, NS и CNAME справа не может быть
указано альтернативное имя. Если вы хотите, чтобы имя узла и домена
совпадали друг с другом, используйте следующую конструкцию:
firma.cz. IN NS nsl.firma.cz.
IN NS ns2.firma.cz
IN A 1.2.3.4
Правило 8. Для каждой записи А должна существовать запись PTR.
У узла с несколькими IP-адресами может быть несколько записей PTR.
Правило 9. Lame delegation — авторитетный сервер имен не
содержит сведений о домене. Этот состояние часто возникает после
удаления вторичного сервера имен. Классический пример lame delegation —
это ситуация, в которой первичный сервер имен работает правильно,
тогда, как вторичный сервер имен имеет ошибочную конфигурацию
(отсутствует запись в named.boot, не осуществлена передача данных
зоны и т. д.).
Далее может быть так, что в домене высшего уровня в качестве
авторитетного сервера для домена настроен ^сконфигурированный сервер
имен. Представьте себе, что откуда-то пришел запрос на имя данного
домена.
Вышестоящий сервер имен отвечает, что его отправитель должен
послать очередной запрос нашему неправильно сконфигурированному
серверу имен. Отправитель делает запрос несконфигурированному
серверу имен, который должен быть авторитетным для данного домена,
однако сервер не знает, что ответить.
Правило 10. Интегрированная запись (glue) не указывается в
обратных доменах. Если сервер имен имеет несколько IP-адресов, то для всех
IP-адресов в вышестоящем домене должна иметься запись glue.

Глава 15 РЕГИСТРАЦИЯ
И ДЕЛЕГИРОВАНИЕ ДОМЕНОВ
МЕТОДИКА ДЕЛЕГИРОВАНИЯ
ДОМЕНОВ
ПРИМЕР 1. ДЕЛЕГИРОВАНИЕ ДОМЕНА:
СТАНДАРТНАЯ СИТУАЦИЯ
ПРИМЕР 2. РАСШИРЕНИЕ КОМПАНИИ
РЕГИСТРАЦИЯ ДОМЕНА
TCP/IP и DNS в теории и на практике. Полное руководство

15.1. Методика делегирования доменов
Процесс делегирования домена состоит из следующих этапов:
• Установка первичного сервера имен.
• Настройка вторичного сервера имен или аренда сервера имен
провайдера.
• Запрос на делегирование домена к домену высшего уровня.
• Если домен является доменом второго уровня, то нужна
регистрация домена в базе данных интернет-реестра.
Представим, что где-то в мире есть волшебная страна,
использующая домен верхнего уровня tld (top-level domain) как код страны. Это
домен верхнего уровня — как .com, .ru, .ua, .cz и т. д. Менеджер TLD-
домена контролирует первичный сервер домена tld, имя этого
сервера — ns . manager-t Id. tld. Вторичные серверы этого домена
поддерживаются хорошими друзьями менеджера домена TLD — хост-
мастерами других TLD, которые одинаково доступны в любом месте
земного шара.
Компания Company Ltd зарегистрировала и использует домен
company . tld; она имеет выделенное подключение к Интернету и сама
администрирует свой собственный сервер имен. Если бы у компании было
коммутируемое (dial-up) соединение, то она бы не смогла
самостоятельно администрировать свой сервер имен. В этом случае администрация
возлагалась бы на интернет-провайдера.

TCP/IP и DNS в теории и на практике. Полное руководство
15.2. Пример 1. Делегирование домена:
стандартная ситуация
Хостмастер компании решает, какой компьютер будет первичным
сервером имен компании. Сервер будет называться ns . company . t Id, его
IP-адрес — 194.149.10.11. Сервер ns . company, t Id работает под
управлением Unix и BIND (конфигурация типа Windows 2000/2003).
Вторичный сервером будет сервер провайдера — ns . provider . net.
Следующий список демонстрирует отдельные конфигурационные
файлы и их секции, необходимые для делегирования.
branch
Корневые серверы имен
Ответственные за gTLD и ccTLD:
ns.manager-tld.tld
Серверы имен: ns.company.tld,
ns.provider.net
Серверы имен: ns.branch.company.tld,
ns.company.tld
Рис. 15.1. Делегирование домена
Сервер ns.company.tld
Данный сервер является первичным сервером зоны company . t Id
Листинг 15.1. Файл named.boot
primary
company.tld
company.tld.zone
Листинг 15.2. Файл company.tld.zone
IN SOA ns.company.tld hostmaster.company.tld (
1998082402 ; Серийный номер
28800 ; Обновлять каждые 8 часов
72 0 0 ; Повторная попытка через 2 часа
532

Глава 15. Регистрация и делегирование доменов
604800 ; Истекает через 7 дней
86400 ) ; мин. TTL 1 день
; NS-записи, определяющие авторитетные серверы имен
IN NS ns.company.tId.
IN NS ns.provider.net.
; А-запись для сервера ns.company.tId
ns IN A 194.149.10.11
-. .Сервер ns. provider. net
Данный сервер является вторичным сервером для зоны company . t Id.
Листинг 15.3. Файл named.boot
secondary company.tld 194.149.10.11 company.tId.zone
Давайте убедимся в том, что первичный и вторичный серверы
корректно настроены и нормально работают. Для этого мы будем использовать
программу nslookup. Проверку можно производить с любого
компьютера сети, но только не с первичного или вторичного серверов домена tld.
Запустим программу nslookup и введем команду server ns.company.tld.
Данная команда указывает резолверу, что для разрешения имен должен
использоваться сервер ns.company.tld. С помощью команды Is -d
выведем содержимое сконфигурированной зоны. Теперь проделаем то
же самое с вторичным сервером имен. Вы должны увидеть аналогичное
содержимое зоны. Если данная команда не выводит содержимое зоны,
вы должны проверить, правильно ли настроены ваши серверы.
Кроме программы nslookup можно использовать более дружественную
программу dig или какую-нибудь другую программу, например, dnswalk.
Если вы хотите запретить просмотр зоны (рекомендуется из
соображений безопасности), сделайте следующее:
1. Разрешите чтение всей зоны без ограничений, но в зону поместите
всего одну или две ресурсные записи.
2. Разрешите делегирование зоны администратору зоны высшего уровня.
3. Настройте ограничения, позволяющие трансфер зоны между
авторитетными серверами данной зоны, и заполните базу данных зоны
реальными данными.
533

TCP/IP и DNS в теории и на практике. Полное руководство
Сервер ns .manager-tld. tld
Это первичный сервер домена tld. Администратор домена tld должен
добавить следующую информацию в файл конфигурации зоны tld (на
сервере ns .raanager-tld. tld).
Листинг. 15.4. Файл tld.zone
; NS-записи, необходимые для делегирования домена
company IN NS ns.company.tld.
IN NS ns.provider.net.
; запись для сервера ns.company.tld:
ns.companyIN A 194.149.10.11
Суть данной регистрации в следующем: ваша зона будет доступна с
любого компьютера Интернета, а не только с тех компьютеров, резолверы
которых настроены на ваш сервер имен, как было показано в
предыдущем пункте.
15.3. Пример 2. Расширение компании
Компания Company Ltd расширилась, и теперь у нее появился
филиал. Для этого филиала планируется создать гюддомен домена
company . tld — домен branch, company .tld. У филиала будет свой сервер
имен, названный ns . branch. company. tld. IP-адрес этого сервера —
194.149.10.129. Вторичным сервером имен для филиала будет сервер
ns . company . tld.
Рассмотрим листинги отдельных файлов конфигурации — точнее, их
отдельные секции, определяющие необходимое делегирование.
Строки, выделенные курсивом, относятся к делегированию домена branch.
company, tld. Эти строки нужно добавить в файлы конфигурации из
предыдущего примера.
534

Глава 15. Регистрация и делегирование доменов
Сервер ns. company. com
Листинг 15.5. Файл NAMED.BOOT
primary company.tld company.tld.zone
secondary branch.company.tld 194.149.10.129
branch.company.tld.zone
Листинг 15.6. Файл COMPANY.TLD.ZONE
@ IN SOA ns.ocnpany. tld hostmaster .company .tld (
1998082402 ; Серийный номер
28800 ; Обновлять каждые 8 часов
72 00 ; Повторная попытка
через 2 часа
604800 ; Истекает через 7 дней
86400 ) ; мин. TTL 1 день
; NS-записи, определяющие авторитетные серверы имен
IN NS ns.company.tld.
IN NS ns.provider.net.
; А-запись для сервера ns.company.tld:
ns IN A 194.149.10.11
делегирование поддомена branch.company.tld
сопровождается следующими NS-записями:
branch IN NS ns.branch.company.tld.
IN NS ns.company.tld.
; А-запись для сервера nsbranch.company.tldz
ns.branch IN A 194.149.10.129
Сервер ns.branch.company.tld
Листинг 15.7. Файл NAMED.BOOT
primary
branch.company.tld
branch.company.tld.zone
535

TCP/IP и DNS в теории и на практике. Полное руководство
Листинг 15.8. Файл branch.company.tld.zone
@ IN SOA ns.company.tld hostmaster.company.tld (
1998082402 ; Серийный номер
2 880 0 ; Обновлять каждые 8 часов
72 00 ; Повторная попытка через
2 часа
604800 ; Истекает через 7 дней
86400 ) ; мин. TTL 1 день
; авторитетные серверы имен
IN NS ns.branch.company.tld.
IN NS ns.company.tld.
; запись типа А для сервера ns.branch.company.tld
ns IN A 194.149.10.129
Запись типа А для сервера филиала также должна быть включена в
домен высшего уровня, то есть она должна быть добавлена в файл
конфигурации сервера имен, делегирующего поддомен. В нашем примере
первичный сервер филиала должен быть включен в файл конфигурации
первичного сервера компании — ns . company . tld.
Аналогично в TLD-зоне есть А-запись, используемая для
делегирования имени ns . company. tld.
Как только вы сконфигурируете и запустите первичный и вторичный
серверы для домена company. tld, все узлы, резолверы которых
«направлены» на ваши серверы, смогут транслировать имена домена company .tld.
Но наша цель заключается в том, чтобы наша зона транслировалась
всеми узлами Интернета, а не только теми, чьи резолверы настроены на
наши серверы. Для этого нужно, чтобы домен высшего уровня
делегировал наши серверы имен. Вы должны запросить делегирование домена
company, tld с серверами ns . company, tld и ns .provider.net.
15.4. Регистрация домена
Регистрация домена происходит не бесплатно. Вы можете оплатить
регистрацию лично или через вашего интернет-провайдера.
Предварительно вам следует выбрать способ оплаты: варианты, как правило,
предлагаются организацией, выполняющей регистрацию.
536

Глава 15. Регистрация и делегирование доменов
Прежде всего, нужно выяснить, какая организация занимается
регистрацией поддоменов в выбранном вами домене высшего уровня.
Предположим, вы хотите зарегистрировать домен в домене .ru. Заходим на
сайт организации IANA (whois.iana.org), вводим имя домена высшего
уровня, получаем «координаты» компании и контактную информацию
хостмастера (администратора).
Используя полученную информацию, вы можете попытаться
зарегистрировать домен. В главе 17 мы поговорим об IANA более подробно.
Рис. 15.2. Первый шаг: поиск организации, отвечающей за регистрацию домена
Например, для домена .ru мы увидим:
[whois.iana.org]
IANA Whois Service
Domain: ru
ID: ru
Registrant:
537

TCP/IP и DNS в теории и на практике. Полное руководство
Organization: Russian Institute for Public Networks
Addressl: 1 Kurchatov Square
City: Moscow
Administrative Contact:
Name: Alexei P. Platonov
Organization: Russian Institute for Public Networks
Addressl: 1 Kurchatov Square
City: Moscow
Technical Contact:
Name: Network Coordination Centre
Organization: Russian Institute for Public Networks
Addressl: 1 Kurchatov Square
City: Moscow
Country: Russian Federation
Postal Code: 123182
Phone: + 7 095 737 0601
Fax: +7 095 737 0602
Email: ru-ncc@ripn.net
Registration Date: Ol-January-1985
Last Updated Date: 29-January-2003
URL for registration services: http://www.ripn.net/nic/
dns/en/index.html
Nameserver Information:
В Интернете можно найти так называемые сервисы регистрации — вы
подаете заявку на регистрацию домена, вам выставляют счет, вы его
оплачиваете и через пару часов получаете в свое распоряжение домен.
Регистрационные сервисы позволяют зарегистрировать домены разных
уровней: .com, .ru, .ua, .com.ru, .com.ua, .oreg и т. д. Одним из таких
сервисов является www. imena.com.ua. Регистрационные сервисы — это
самый простой способ регистрации домена.

Глава 16 делегирование
И РЕГИСТРАЦИЯ
ОБРАТНЫХ ДОМЕНОВ
ВИДЫ И ТИПЫ ОБРАТНЫХ ДОМЕНОВ
ПРИМЕР ДЕЛЕГИРОВАНИЯ
ОБРАТНОГО ДОМЕНА
РЕГИСТРАЦИЯ ОБРАТНОГО ДОМЕНА
TCP/IP и DNS в теории и на практике. Полное руководство

16.1. Виды и типы обратных доменов
Обратное преобразование — это преобразование IP-адреса в доменное
имя. Как мы уже знаем, запись, задающая присоединение IP-адреса к
доменному имени, называется PTR. Обратное преобразование используют
такие программы, как, например, ftp, traceroute и т. д. При отсутствии
в DNS обратной записи для доменного имени некоторые службы
(например, ftp) могут отказаться корректно работать, поэтому нельзя
забывать о записях PTR и об обратных доменах.
Формирование и делегирование обратного домена всегда осуществляется
для сети IP-адресов. Например, для сети 194.149.177 в DNS должен быть
создан и делегирован обратный домен 177.149.194. in-addr. агра.
Обратный домен никак не взаимосвязан с классическим доменом. В
одном обратном домене могут находиться (и часто находятся) доменные
имена из различных доменов.
Типы обратных доменов различают в зависимости от размера
используемой сети. Пользователь обычно применяет сеть размером 256
IP-адресов — сеть класса С или подсеть класса С. У провайдеров может быть
также сеть класса В. По количеству IP-адресов различают всего три
варианта обратных доменов:
1. Назначено 255 адресов класса С (как адрес класса В, то есть префикс
/16). Данная ситуация является типичной не для обычных
пользователей, а скорее для интернет-провайдеров.
2. Назначен один или несколько адресов класса С, число которых
меньше или больше 255 и которые не образуют префикс /16.
3. Назначен интервал между IP-адресами (меньше, чем один адрес
класса С).

Глава 16. Делегирование и регистрацияобратных доменов
Делегирование обратных доменов для сетей классов В и С не входит
в спектр обязанностей сотрудников национального информационного
центра сети (Network Information Center). Этим занимаются
международные организации, которые устанавливают IP-адреса.
Для Европы делегирование обратных доменов обеспечивается
организацией RIPE. Именному серверу RIPE ns . ripe . net делегируются
обратные домены для сети IP-адресов, которые RIPE устанавливает для
провайдеров (например, 193-in-addr . агра, 194 . in-addr . агра,
195 . in-addr. агра и т. д.).
RIPE делегирует обратные домены для меньших интервалов IP-адресов
сети класса С серверам имен провайдеров или конечных пользователей.
Обратный домен, как и классический, должен быть делегирован как
минимум двум серверам имен. Работа вторичного именного сервера
для обратного домена обычно обеспечивается провайдерами на их
серверах имен.
Делегирование обратного домена, как и делегирование классического
домена, состоит из нескольких шагов:
1. Конфигурирование первичного сервера имен.
2. Конфигурирование вторичного сервера имен.
3. Делегирование обратного домена.
4. Регистрация обратного домена.
Процедуру делегирования обратного домена мы покажем на примере
(см. раздел 16.2).
16.2. Пример делегирования обратного домена
16.2.1. Конфигурационные файлы
В примере мы используем знакомую нам фирму «ООО Фирма»:
• Пользователь фирмы «ООО Фирма» использует для подключения
своих компьютеров к Интернету сеть 194.149.10.0, то есть сеть
класса С. У данной фирмы есть свой собственный сервер имен на
компьютере с именем ns . firma.cz и IP-адресом 194.149.10.11.
• На узле ns . firma.cz установлены ОС Unix и BIND.
541

TCP/IP и DNS в теории и на практике. Полное руководство
• Управляющий фирмы должен обеспечить делегирование обратного
домена 117 .149 .194 . id-addr .агра серверу имен ns . firma.cz .
Работа вторичного сервера имен для обратного домена будет
обеспечиваться провайдером на узле ns .provider .net (см. рис. 16.1).
in-addr.arpa
Серверы имен: ns.hpe.net,
Серверы имен: ns.ripe.net,...
Серверы имен: ns.firma.cz, ns.provider.cz
ns.firma.cz
Рис. 16.1. Делегирование обратного домена для компьютера ns. firma .cz.
Далее следуют отдельные конфигурационные файлы, то есть их части,
используемые в процессе делегирования.
Сервер ns. firma. cz
Листинг 16.1. Файл named.boot
Primary 10.149.194.in-addr.агра 10.149.194.zone
Листинг 16.2. Файл 10.l49. 194.zone
IN SOA ns.firma.cz hostmaster.firma.cz (
1998082402
28800
7200
604800
86400 )
Serial
Refresh 8 hours
Retry 2 hour
Expire 7 days
Minimum TTL 1 day
542

Глава 16. Делегирование и регистрацияобратных доменов
IN NS ns.firma.cz.
IN NS ns.provider.net.
11 IN PTR ns.firma.cz.
Сервер ns. provider. net
Листинг 16.3. Файл named.boot
Secondary 10.149.194.in-addr.arpa 10.149.194.zone 194.149.10.11
Сервер ns. ripe. net
(авторитетный сервер для вышестоящего домена)
Листинг 16.4. Файл 149.194.zone
10 IN NS ns.firma.cz.
IN NS ns.provider.net.
16.2.2. Описание
Делегирование домена функционирующим серверам имен
осуществляется организацией RIPE. Управляющий фирмы должен обратиться
с просьбой о делегировании домена к управляющему организации RIPE,
для чего имеется специальная форма. Описание процедуры и пример
приведены в разделе 16.1.
Данная фирма имеет филиал в городе Ческе Будейовице. Этот филиал
использует 128 IP-адресов, то есть сеть 194.149.10.128 - 194.149.10.255.
Филиал фирмы в Ческе Будейовице имеет свой собственный сервер
имен с именем ns . cbu . f irma . cz и IP-адресом 194.149.10.129. В связи
с этим имеет смысл, чтобы обратный домен для подсети 194.149.10/25
был делегирован серверу имен ns . cbu . f irma . cz.
На практике этот пример является относительно типичным, поэтому мы
будем использовать его здесь в качестве образца делегирования
обратного домена для подсети. Однако сначала немного теории.
Делегирование обратных доменов для подсети не используется со
времени появления DNS. Обратные домены для подсетей описаны в RFC-
2317 и называются Classless IN-ADDR. ARPA delegation. Исиоль-
543

TCP/IP и DNS в теории и на практике. Полное руководство
зуемый метод совместим с механизмом DNS и не требует модификации
используемого программного обеспечения.
Делегирование домена Classless IN-ADDR.ARPA решает одну
неприятную проблему. С ней райьше приходилось сталкиваться клиенту,
у которого установлена подсеть IP-адресов и имеется свой сервер имен.
Ему приходилось самому управлять классическим доменом, при этом
обратный домен находился в ведении провайдера. Каждый раз при
добавлении новой записи типа А приходилось связываться с провайдером
и просить его добавить запись PTR в обратный домен.
Задумаемся еще об обозначении обратного домена для подсети. Если
у клиента установлена сеть С 194.149.10, то у него имеется обратный
домен 10 .149 .194 . in-addr. агра. Узел с IP-адресом 194.149.10.11
в обратном домене обозначается как 11.10.149 .194 . in-addr . агра.
Если у клиента имеется подсеть 194.149.10.128, то у него имеется
обратный домен 128 .10 .149-194 . in-addr .агра. Обозначение обратного
домена для подсети необычно тем, что содержит четыре числа,
отделенные друг от друга точкой, как и IP-адрес. Узел с IP-адресом 194.149.10.130
в обратном домене обозначается как 13 0 .128.10.149.194. in-addr.
агра, что еще более необычно.
Собственно говоря, речь идет об искусственно созданной конструкции, в
которой осуществлен принцип формировании доменного имени. Для того,
чтобы данная конструкция казалась еще более странной, вышестоящий
сервер имен использует запись типа PTR, указывающую на запись типа
CNAME, заданную на сервере имен более низкого уровня (см. рис. 16.2).
ш in-add г. агра
194 Серверы имен: ns.ripe.net,...
149 Серверы имен: ns.ripe.net,...
10 Серверы имен: ns.firma.cz, ns.provider.cz
128 Серверы имен: ns.cbu.firma.cz, ns.firma.cz
129
ns.cbu.firma.cz
Рис. 16.2. Делегирование С las si ess in-addr . arpa
544

Глава 16. Делегирование и регистрацияобратных доменов
16.2.3. Конфигурационные файлы
(продолжение)
Продолжим рассмотрение предыдущего примера. Далее следуют
отдельные конфигурационные файлы, то есть их части, обеспечивающие
делегирование обратного домена для подсети 194.149-10.128.
Добавим в конфигурационные файлы из предыдущего примера строки,
относящиеся к делегированию домена 128.10.149 .194 . in-addr . агра.
Строки выделены курсивом.
Сервер ns. f irma. cz
Листинг 16.5. Файл named.boot
Primary 10.149.194.in-addr.агра 10.149.194.zone
secondary 128.10.149.194. in-addr.arpd 194.149.10.129
128.10.149.194.zone
Листинг 16.6. Файл 10.149.194.zone
IN SOA
11
128
129
130
131
132
133
134
... Atd.
254
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
IN
ah
IN
NS
NS
PTR
NS
NS
CNAME
CNAME
CNAME
CNAME
CNAME
CNAME
CNAME
ns.firma.cz hos
1998082402
28800
7200
604800
86400 )
ns.firma.cz.
ns.provider.cz.
ns.firma.cz.
ns.cbu.firma.cz
ns.firma.cz .
129.128.10.149.
130.128.10.149.
131.128.10.149.
132.128.10.149.
133.128.10.149.
134.128.10.149.
tmaster.firma.cz (
; Serial
; Refresh 8 hours
; Retry 2 hour
; Expire 7 days
; Minimum TTL 1 day
194.in-addr.arpa.
194.in-addr.arpa.
194.in-addr.arpa.
194.in-addr.arpa.
194.in-addr.arpa.
194.in-addr.arpa.
254.128.10.149.194.in-addr.arpa.
18 Зак. 518
545

TCP/IP и DNS в теории и на практике. Полное руководство
Сервер ns. cbu. f irma. cz
Листинг 16.7. Файл named. boot
Primary 128.10.149 .194 . in-addr-arpa 128.10.149.194.zone
Листинг 16.8. Файл 128 .10 .149 .194 . zone
IN
SOA
ns .cbu. firma.cz hostmaster.cbu.firiua.cz (
129
130
131
... Atd.
254
IN
IN
IN
IN
IN
az
IN
NS
NS
PTR
PTR
PTR
PTR
1998082502
28800
7200
604800
86400 )
ns.cbu.firma.cz.
ns.firma.cz.
ns.cbu.firma.cz.
jmenol.cbu.firma.cz.
Serial
Refresh 8 hours
Retry 2 hour
Expire 7 days
Minimum TTL 1 day
jmeno2.cbu.fi rma.cz.
jmeno.cbu.firma.cz.
16.3. Регистрация обратного домена
Регистрацию домена мы можем осуществить только в том случае, если
у нас имеется по крайней мере два достаточно хорошо
функционирующих сервера для соответствующих обратных доменов.
При этом существует два варианта регистрации:
1. Регистрация обратного субдомена второго уровня. У провайдера
установлен блок из 255-ти адресов класса С (в качестве адреса
класса В). Сервер имен ns.ripe.net содержит ссылку (записи типа
NS) на этот блок (адрес класса В) на сервере имей провайдера.
Сервер имен провайдера, в свою очередь, содержит ссылку (записи типа
NS) на серверы имен клиентов. Сервер имен ns.ripe.net в этом
случае должен быть обязательно вторичным сервером имен по
отношению к серверу имен провайдера для соответствующего блока.
546

Глава 16. Делегирование и регистрацияобратных доменов
2. Регистрация обратного домена третьего уровня. У провайдера
установлен блок адресов, количество которых меньше, чем 255. В этом
случае сервер имен ns . ripe . net содержит записи типа NS,
ссылающиеся непосредственно на именной сервер клиента. Далее мы
будем заниматься исключительно вторым случаем.
Регистрация обратных доменов осуществляется в соответствии с RIPE-185.
При этом форма содержит следующие элементы:
inetnum
netname
descr
country
admi n-c
tech-c
aut-sys (число AS)
rev-srv (компьютер с авторитетным сервером имен для обратного
домена)
changed
source: RIPE
Далее следуют записи типа NS, которые мы хотим поместить в
конфигурационный файл сервера имен ns . ripe. net. Достаточно привести записи
для первой сети и в том случае, когда мы регистрируем интервал сети.
Листинг 16.9. Пример запроса на регистрацию обратного домена
From: dostalek@pvt.cz
То: RIPE Hostmaster <auto-inaddr@ripe.net>
Subject: 96 - 111.149.194. in-addr.arpa delegation please
Please deleg6te 96 - 111.149.194. . in-addr.arpa as specified below.
Thank you!
For the PVT Corporation
Libor Dostalek
inetnum: 194.149.96.0 - 194.149.111.255
netname: PVTNET
descr: PVT Czech Internet Provider Network
country: CZ
547

TCP/IP и DNS в теории и на практике. Полное руководство
admin-c: FD14-RIPE
tech-c: LD11-RIPE
rev-srv: ns.pvt.net
rev-srv: nsl.pvt .net.
changed: dostalek@pvt.cz 960205
source: RIPE
96.149 IN NS ns.pvt.net
96.149 IN NS nsl.pvt.net.
Ответ будет отрицательным при наличии синтаксической ошибки или
неправильно сконфигурированного сервера имен, поскольку робот
auto-inaddr@ripe.net осуществляет не только проверку
синтаксиса, но и проверку DNS клиента.
Если ответ положительный, то он будет отправлен не только вам, но
и администратору ns . ripe. net, который вручную осуществляет
актуализацию конфигурационного файла сервера имен ns . ripe . net
(помещает в него переданные записи типа NS). Внеся изменения,
администратор посылает вам e-mail.
Если время отклика робота составляет всего несколько минут, то время,
за которое вы получите ответ от администратора ns . ripe. net, может
быть приблизительно равным неделе.

Глава 17
ИНТЕРНЕТ-РЕЕСТРЫ
МЕЖДУНАРОДНЫЕ ОРГАНИЗАЦИИ
РЕГИОНАЛЬНЫЕ ИНТЕРНЕТ-РЕЕСТРЫ
(RIR)
КОДЫ СТРАН И RIR
IPV4-AflPECA И НОМЕРА АС
ИНТЕРНЕТ-РЕЕСТРЫ
ИЛИ КАК ПОЛУЧИТЬ В УПРАВЛЕНИЕ
ЧАСТЬ ИНТЕРНЕТА
ДЕЛЕГИРОВАНИЕ ДОМЕНОВ ВТОРОГО
УРОВНЯ
TCP/IP и DNS в теории и на практике. Полное руководство

17.1. Международные организации
Об истории развития Интернета и организаций, занимающихся его
поддержкой, можно написать отдельную и очень интересную книгу. В
данной же книге я буду предельно краток. Место рождения Интернета —
Соединенные Штаты Америки. Финансирование развития Интернета
производилось за счет налогоплательщиков. В начале 90-х годов
прошлого века была создана новая структура организаций Интернета.
В финансировании Интернета теперь приняли участие конечные
пользователи, то есть мы с вами, оплачивая услуги интернет-провайдеров.
Кроме доступа к Интернету, любой пользователь может купить себе
собственный домен, сделав еще один взнос в развитие всемирной сети.
Провайдеры, в свою очередь, перечисляют полученные от
пользователей деньги (конечно же, не все) международным организациям
Интернета — провайдерам высшего уровня.
Для нас, как для конечных пользователей Интернета, важны следующие
организации:
• RFC-редактор — данная организация издает RFC-стандарты
(http: //www.rfc-editor.org). Чтобы лучше понять отдельные
стандарты, я рекомендую прочитать RFC 2026.
• IANA (The Internet Assigned Numbers Authority) —
Администрация адресного пространства Интернета. Web-сайт этой организации
можно найти по адресу: www. iana . org. Чем же занимается IANA?
• Регистрацией доменов верхнего уровня — TLD (http: //www.
iana . org/domain-names . htm).
• Распределением адресного пространства, то есть назначением IP-
адресов (IPv4 и IPv6).

Глава 17. Интеренет-реестры
• Назначением различных номеров, например, номеров
автономных систем (AS), номеров различных протоколов и т. д. (database;
http://www.iana.org/numbers.html).
Вся эта структура находится под руководством корпорации ICANN,
преамбула на web-странице которой гласит: «ICANN
(Интернет-корпорация назначения имен и номеров) — некоммерческая организация,
сформированная для распределения IP-адресов, назначения номеров
протоколов, управления системой доменных имен и корневыми
серверами имен».
ICANN — это государственная организация, работающая под
руководством правительства США. ICANN заключила контракт с IANA,
позволяющий выполнять IANA некоторые функции ICANN (эти функции
были указаны выше).
Для нас (конечных пользователей Интернета) наиболее важны
следующие функции ICANN (как было сказано выше, часть функций берет на
себя IANA):
• Создание и управление региональными интернет-реестрами.
Региональным интернет-реестрам (RIR) отводится часть адресного
пространства, которое они вправе распределять по своему усмотрению
между местными интернет-провайдерами. На данный момент
выделены следующие регионы:
• Европа и Ближний Восток;
• Африка;
• Северная Америка;
• Латинская Америка вместе с Карибами;
• Азия и регион Тихого Океана.
• Администрирование и делегирование доменов высшего уровня
(TLD). Назначаются коды стран (ccTLD — TLD country codes),
а также общие TLD (generic TLD, gTLD), например, gTLDcom —
TLD-менеджер, отвечающий за домен .com. Определение TLD-ме-
неджера — процесс довольно сложный.
• Поддержка корневых серверов DNS. Данная функция жизненно
важна для всего Интернета — ведь без DNS останутся только одни
IP-адреса.
551

TCP/IP и DNS в теории и на практике. Полное руководство
Корневые
серверы DNS
Рис. 17.1. Отношения между отдельными организациями
17.2. Региональные интернет-реестры (RIR)
Географически мир разделен на пять регионов. Возможно, вы подумали,
что за каждым регионом закреплена отдельная интернет-организация,
но на самом деле на данный момент создано только четыре
региональных интернет-реестра (RIR), поскольку пока в пятом особой
необходимости нет:
• RIPE NCC (Reseaux IP Europeans Network Coordination Centre) —
Европейский центр координации IP-сетей. Занимается
администрированием следующих регионов: Европа, Ближний Восток, часть
Северной Африки (до Экватора). Сайт: http: / /www. ripe . net.
• ARIN — администрирует Северную Африку и Южную Африку.
Сайт: http: / /www. arin. net.
• APNIC — администрирует Тихоокеанский регион и Азию. Сайт:
http://www.apnic.net.
• LACNIC — администрирует Латинскую Америку и Карибы. Сайт:
http://www.lacnic.net
Конечные пользователи не связываются непосредственно с RIR. Связь
с ними обычно происходит через локальные интернет-реестры (LIR),
552

Глава 17. Интеренет-реестры
которыми в большинстве случаев являются провайдеры. Например, вам
нужен собственный IP-адрес (или даже целая IP-подсеть) и домен. Вы
идете к провайдеру и договариваетесь с ним об этом, а он, в свою
очередь, договаривается с NIR. Стоп! А это что такое?
NIR — это национальный интернет-реестр. Ведь в одном регионе может
быть несколько стран. RIR отвечает в целом за регион, NIR — за
страну, a LIR — за отдельно взятую часть области или города (ведь в одном
городе может быть несколько десятков провайдеров). Как видите, даже
провайдеры связываются с RIR не напрямую, а через посредника.
За RIR закрепляется определенная часть адресного пространства IP-
адресов. При этом RIR распределяет это пространство среди NIR, а те,
в свою очередь, среди LIR. В базе данных RIR находится информация
об ответственных автономных системах, их номерах и IP-адресах. Также
в базу данных вносится вся контактная информация об
администраторах этих систем: название организации, имя сетевого администратора,
адрес, телефоны и т. д.
База данных RIR общедоступна. Для ее просмотра используется команда
whois. Web-интерфейс этой команды доступен на сайте каждого RIR (см.
адреса выше). На сервере RIPE (www. ripe. net) также есть эта база данных.
RIR разрабатывают нормы, которые должны соблюдаться LIR (то есть
провайдерами) и конечными пользователями. Например, RIPE создает
свои нормы, a APNIC — свои. Каждая RIPE-норма называется «RIPE-
число» (то есть RIPE-159). Все RIPE-нормы доступны по адресу f tp: / /
ftp. ripe. net /ripe/docs/. А с APNIC-нормами можно
ознакомиться на сайте этой организации.
Региональные реестры также отвечают за делегирование обратных
доменов. Например, если за данным RIR закреплена подсеть 193.0.0.0/8,
то этот RIR отвечает за обратный домен 193 . in-arddr . arpa.
17.3. Коды стран и RIR
Информация для данной главы была позаимствована с сайта http: / /
www. ripe. net. Описание TLD отдельных стран в соответствии с ISO-
3166 было взято с сайта организации ISO — http: //www. iso.org/
iso/en/prods-services/iso3166ma/02iso-3166-code-lists/
index.html.
553

TCP/IP и DNS в теории и на практике. Полное руководство
За каждой страной закреплен свой TLD — домен верхнего уровня,
например, за Россией — .ru, за Украиной — .иа. Домены верхнего уровня
разных стран и отвечающие за их поддержку RIR указаны в таблице 17.1.
Таблица 17.1. Домены верхнего уровня и соответствующие им RIR
Страна
АФГАНИСТАН
АЛБАНИЯ
АЛЖИР
АМЕРИКАНСКИЕ ОСТРОВА САМОА
АНДОРРА
АНГОЛА
АНТАРКТИКА
АНТИГУА и БАРБУДЫ
АРГЕНТИНА
АРМЕНИЯ
АРУБА
АВСТРАЛИЯ
АВСТРИЯ
АЗЕРБАЙДЖАН
БАГАМЫ
БАХРЕЙН
БАНГЛАДЕШ
БАРБАДОС
БЕЛОРУССИЯ
БЕЛЬГИЯ
БЕЛИЗ
БЕНИН
БЕРМУДЫ
БУТАН
БОЛИВИЯ
БОСНИЯ И ГЕРЦЕГОВИНА
БОТСВАНА
ОСТРОВ БОУВЕТ
БРАЗИЛИЯ
БРИТАНСКАЯ ТЕРРИТОРИЯ ИНДИЙСКОГО ОКЕАНА
БРУНЕЙ
БОЛГАРИЯ
БУРКИНА-ФАСО
БУРУНДИ
КАМБОДЖА
КАМЕРУН
КАНАДА
МЫС ВЕРДЕ
Код страны
AF
AL
DZ
AS
AD
АО
AQ
AG
AR
AM
AW
AU
AT
AZ
BS
BH
BD
BB
BY
BE
BZ
BJ
BM
ВТ
BO
BA
BW
BV
BR
IO
BN
BG
BF
Bl
KH
CM
CA
CV
RIR
APNIC
RIPE
RIPE
APNIC
RIPE
ARIN
ARIN
ARIN
LACNIC
RIPE
LACNIC
APNIC
RIPE
RIPE
ARIN
RIPE
APNIC
ARIN
RIPE
RIPE
LACNIC
RIPE
ARIN
APNIC
LACNIC
RIPE
ARIN
ARIN
LACNIC
APNIC
APNIC
RIPE
RIPE
ARIN
APNIC
RIPE
ARIN
RIPE 1
554

Глава 17. Интеренет-реестры
Продолжение табл. 17.1
Страна
КАЙМАНОВЫ ОСТРОВА
ЦЕНТРАЛЬНОАФРИКАНСКАЯ РЕСПУБЛИКА
ЧАД
ЧИЛИ
КИТАЙ
ОСТРОВ РОЖДЕСТВА
КОКОСОВЫЕ ОСТРОВА
КОЛУМБИЯ
КОМОРЫ
КОНГО
ДЕМОКРАТИЧЕСКАЯ РЕСПУБЛИКА КОНГО
КОСТА-РИКА
КОТ-Д'ИВУАР
ХОРВАТИЯ
КУБА
КИПР
ЧЕШСКАЯ РЕСПУБЛИКА
ДАНИЯ
ДЖИБУТИ
ДОМИНИКА
ДОМИНИКАНСКАЯ РЕСПУБЛИКА
ВОСТОЧНЫЙ ТИМОР
ЭКВАДОР
ЕГИПЕТ
САЛЬВАДОР (ЦЕНТРАЛЬНАЯ АМЕРИКА)
ЭКВАТОРИАЛЬНАЯ ГВИНЕЯ
ЭРИТРЕЯ
ЭСТОНИЯ
ЭФИОПИЯ
ФОЛЬКЛЕНДСКИЕ (МАЛЬДИВСКИЕ) ОСТРОВА
ФИДЖИ
ФИНЛЯНДИЯ
ФРАНЦИЯ
ФРАНЦУЗСКАЯ ГВИАНА
ФРАНЦУЗСКАЯ ПОЛИНЕЗИЯ
ФРАНЦУЗСКИЕ ЮЖНЫЕ ТЕРРИТОРИИ
ГАБОН
ГАМБИЯ
ГРУЗИЯ
ГЕРМАНИЯ
ГАНА
ГИБРАЛТАР
ГРЕЦИЯ
Код страны
KY
CF
TD
CL
CN
СХ
СС
СО
км
CG
CD
CR
CI
HR
си
CY
CZ
DK
DJ
DM
DO
TL
EC
EG
SV
GQ
ER
ЕЕ
ET
FK
FJ
Fl
FR
GF
PF
TF
GA
GM
GE
DE
GH
Gl
GR
RIR
ARIN
RIPE
RIPE
LACNIC
APNIC
APNIC
APNIC
LACNIC
APNIC
ARIN
ARIN
LACNIC
RIPE
RIPE
LACNIC
RIPE
RIPE
RIPE
RIPE
ARIN
LACNIC
APNIC
LACNIC
RIPE
LACNIC
RIPE
RIPE
RIPE
RIPE
LACNIC
APNIC
RIPE
RIPE
LACNIC
APNIC
APNIC
RIPE
RIPE
RIPE
RIPE
RIPE
RIPE
RIPE I
555

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 17.1
Страна
ОСТРОВ ГРЕНЛАНДИЯ
ГРЕНАДА
ОСТРОВ ГВАДЕЛУПА
ГУАМ
ГВАТЕМАЛА
ГВИНЕЯ
ГВИНЕЯ-БИССАУ
ГАЙАНА
ГАИТИ
ВАТИКАН
ГОНДУРАС
ГОНКОНГ
ВЕНГРИЯ
ИСЛАНДИЯ
ИНДИЯ
ИНДОНЕЗИЯ
ИРАН
ИРАК
ИРЛАНДИЯ
ИЗРАИЛЬ
ИТАЛИЯ
ЯМАЙКА
ЯПОНИЯ
ИОРДАНИЯ
КАЗАХСТАН
КЕНИЯ
КОРЕЙСКАЯ НАРОДНАЯ ДЕМОКРАТИЧЕСКАЯ РЕСПУБЛИКА
РЕСПУБЛИКА ЮЖНАЯ КОРЕЯ
КУВЕЙТ
КЫРГЫЗСТАН
ЛАОС
ЛАТВИЯ
ЛИВАН
ЛЕСОТО
ЛИБЕРИЯ
ЛИВАН
ЛИХТЕНШТЕЙН
ЛИТВА
ЛЮКСЕМБУРГ
МАКАО
МАКЕДОНИЯ
МАДАГАСКАР
МАЛАВИ
Код страны
GL
GD
GP
GU
GT
GN
GW
GY
НТ
VA
HN
НК
ни
IS
IN
ID
IR
IQ
IE
IL
IT
JM
JP
JO
KZ
KE
KP
KR
KW.
KG
LA
LV
LB
LS
LR
LY
LI
LT
LU
MO
MK
MG
MW
RIR
RIPE
ARIN
ARIN
APNIC
LACNIC
RIPE
RIPE
LACNIC
LACNIC
RIPE
LACNIC
APNIC
RIPE
RIPE
APNIC
APNIC
RIPE
RIPE
RIPE
RIPE
RIPE
ARIN
APNIC
RIPE
RIPE
RIPE
APNIC
APNIC
RIPE
RIPE
APNIC
RIPE
RIPE
ARIN
RIPE
RIPE
RIPE
RIPE
RIPE
APNIC
RIPE
APNIC
ARIN
556

Глава 17. Интеренет-реестры
Продолжение табл. 17.1
Страна
МАЛАЙЗИЯ
МАЛЬДИВЫ
МАЛИ
МАЛЬТА
МАРШАЛОВЫ ОСТРОВА
МАРТИНИКА
МАВРИТАНИЯ
МАВРИКИЙ
МАЙОТТА
МЕКСИКА
МИКРОНЕЗИЯ, ОБЪЕДИНЕННЫЕ ГОСУДАРСТВА
МОЛДОВА, РЕСПУБЛИКА
МОНАКО
МОНГОЛИЯ
МАРОККО
МОЗАМБИК
НАМИБИЯ
НАУРУ
НЕПАЛ
НИДЕРЛАНДЫ
НИДЕРЛАНДСКИЕ АНТИЛЫ
НОВАЯ КАЛЕДОНИЯ
НОВАЯ ЗЕЛАНДИЯ
НИКАРАГУА
НИГЕР
НИГЕРИЯ
НИУЭ
НОРФОЛКСКИЙ ОСТРОВ
СЕВЕРНЫЕ МАРИАНСКИЕ ОСТРОВА
НОРВЕГИЯ
ОМАН
ПАКИСТАН
ПАЛАУ
ПАЛЕСТИНСКАЯ ТЕРРИТОРИЯ
ПАНАМА
ПАПУА-НОВАЯ ГВИНЕЯ
ПАРАГВАЙ
ПЕРУ
ФИЛИППИНЫ
ПОЛЬША
ПОРТУГАЛИЯ
ПУЭРТО-РИКО
КАТАР
Код страны
MY
MV
ML
МТ
МН
MQ
MR
ми
YT
MX
FM
MD
МС
MN
МА
MZ
NA
NR
NP
NL
AN
NC
NZ
NI
NE
NG
NU
NF
MP
NO
ОМ
РК
PW
PS
PA
PG
PY
РЕ
PH
PL
PT
PR
QA
RIR
APNIC
APNIC
RIPE
RIPE
APNIC
ARIN
RIPE
APNIC
APNIC
LACNIC
APNIC
RIPE
RIPE
APNIC
RIPE
ARIN
ARIN
APNIC
APNIC
RIPE
LACNIC
APNIC
APNIC
LACNIC
RIPE
RIPE
APNIC
APNIC
APNIC
RIPE
RIPE
APNIC
APNIC
RIPE
LACNIC
APNIC
LACNIC
LACNIC
APNIC
RIPE
RIPE
ARIN
RIPE
557

TCP/IP и DNS в теории и на практике. Полное руководство
Продолжение табл. 17.1
Страна
РУМЫНИЯ
РОССИЙСКАЯ ФЕДЕРАЦИЯ
РУАНДА
САНТАЛУЧИЯ
САНТА ВИНСЕНТ И ГРЕНАДИНЫ
ОСТРОВА САМОА
САН-МАРИНО
САУДОВСКАЯ АРАВИЯ
СЕНЕГАЛ
СЕЙШЕЛЫ
СЬЕРРА-ЛЕОНЕ
СИНГАПУР
СЛОВАКИЯ
СЛОВЕНИЯ
СОЛОМОНОВЫ ОСТРОВА
СОМАЛИ
ЮЖНАЯ АФРИКА
ИСПАНИЯ
ШРИ-ЛАНКА
СУДАН
СУРИНАМ
СВАЗИЛЕНД
ШВЕЦИЯ
ШВЕЙЦАРИЯ
СИРИЙСКАЯ АРАБСКАЯ РЕСПУБЛИКА
ТАЙВАНЬ, ПРОВИНЦИЯ КИТАЯ
ТАДЖИКИСТАН
ТАНЗАНИЯ
ТАИЛАНД
ТОГО
ТОНГА
ТРИНИДАД И ТОБАГО
ТУНИС
ТУРЦИЯ
ТУРКМЕНИЯ
УГАНДА
УКРАИНА
ОБЪЕДИНЕННЫЕ АРАБСКИЕ ЭМИРАТЫ
ВЕЛИКОБРИТАНИЯ
СОЕДИНЕННЫЕ ШТАТЫ
ОТДАЛЕННЫЕ ОСТРОВА СОВДИНЕННЫХ ШТАТОВ
УРУГВАЙ
УЗБЕКИСТАН
Код страны
RO
RU
RW
LC
VC
WS
SM
SA
SN
SC
SL
SG
SK
SI
SB
SO
ZA
ES
LK
SD
SR
SZ
SE
CH
SY
TW
TJ
TZ
TH
TG
TO
TT
TN
TR
TM
UG
UA
AE
GB
US
UM
UY
UZ
MR
RIPE
RIPE
ARIN
ARIN
ARIN
APNIC
RIPE
RIPE
AlPE
APNIC
RIPE
APNIC
RIPE
RIPE
APNIC
RIPE
ARIN
RIPE
APNIC
RIPE
LACNIC
ARIN
RIPE
RIPE
RIPE
APNIC
RIPE
ARIN
APNIC
RIPE
APNIC
LACNIC
RIPE
RIPE
RIPE
RIPE
RIPE
RIPE
RIPE
ARIN
ARIN
LACNIC
RIPE |
558

Глава 17. Интеренет-реестры
Продолжение табл. 17.1
Страна
ВЕНЕСУЭЛА
ВЬЕТНАМ
ВИРГИНСКИЕ БРИТАНСКИЕ ОСТРОВА
ВИРГИНСКИЕ ОСТРОВА (США)
ЗАПАДНАЯ САХАРА
ЙЕМЕН
ЮГОСЛАВИЯ
ЗАМБИЯ
ЗИМБАБВЕ
Код страны
VE
VN
VG
VI
ЕН
YE
YU
ZM
ZW
RIR
LACNIC
APNIC
ARIN
ARIN
RIPE
RIPE
RIPE
ARIN
ARIN
Европейские TLD-менеджеры формируют так называемый Центр —
CENTR (COUNCIL OF EURPOEAN NATIONAL TOP-LEVEL
DOMAIN REGISTERS). Более подробная информация о Центре доступна
по адресу http: //www. centr. org.
Рис. 17.2. Азия
559

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 17.3. Африка
Рис. 17.4. Европа
560

Глава 17. Интеренет-реестры
Рис. 17.5. Северная Америка
Рис. 17.6. Южная Америка
561

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 17.7. Австралия и Океания
Рис. 17.8. Карибы
562

Глава 17. Интеренет-реестры
Рис. 17.9. Ближний Восток
17.4. IPv4-адреса и номера АС
Распределение блоков IP-адресов можно найти по адресу: http://
www. iana.org/ipaddress/ip-addresses .htm. Некоторые части
адресного пространства IPng были представлены в таблице 8.4. Ниже
приведено распределение 1Ру4-адресов:
061.0.0.0 -
062.0.0.0 -
063.0.0.0 -
080.0.0.0 -
193.0.0.0 -
199.0.0.0 -
200.0.0.0 -
202.0.0.0 -
204.0.0.0 -
210.0.0.0 -
212.0.0.0 -
216.0.0.0 -
217.0.0.0 -
218.0.0.0 -
- 061.255.255.255
- 062.255!255.255
- 069.255.255.255
- 082.255.255.255
- 195.255.255.255
- 199.255.255.255
- 200.255.255.255
- 203.255.255.255
- 209.255.255.255
- 211.255.255.255
- 213.255.255.255
- 216.255.255.255
- 217.255.255.255
- 223.255.255.255
- APNIC
-RIPE
-ARIN
-RIPE
-RIPE
-ARIN
- LACNIC
- APNIC
-ARIN
- APNIC
-RIPE
-ARIN
-RIPE
- APNIC
563

TCP/IP и DNS в теории и на практике. Полное руководство
Также нужно упомянуть об интервалах IP-адресов для корпоративных
сетей (intranet):
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
Распределение интервалов номеров автономных систем по
региональным реестрам подобно распределению интервалов IP-адресов.
Само распределение номеров вы найдете по следующему адресу
http://www.iana.org/numbers.html. Согласно RFC-193Q,
номера автономных систем 64512 — 65534 зарезервированы для безопасных
корпоративных сетей.
17.5. Интернет-реестры
или как получить в управление
часть Интернета
Чтобы стать провайдером, прежде все вам нужно связаться с RIR.
Однако RIR «разговаривают» только с LIR. Поэтому вам нужно сначала
стать LIR — локальным интернет-реестром. Давайте рассмотрим то, что
для этого надо.
17.5.1 Регистрация локального интернет-реестра (LIR)
В зависимости от вашего RIR процедура и правила регистрации LIR
могут отличаться. Ознакомиться с порядком регистрации можно на сайте
вашего RIR:
• Для RIPE весь процесс регистрации описан в RFC-257:
http://www.ripe.net/ripe/docs/internet-registries.html
• Для APNIC нужные сведения вы получите по адресу:
http://www.apnic.net/member/membersteps.html
• Для ARIN вам нужно посетить страничку:
http://www.arin.net/membership/index.html
• Для LACNIC — http: //lacnic .net/en/mem.html
564

Глава 17. Интеренет-реестры
Сконцентрируем свое внимание на нашем региональном реестре — RIPE
NCC (к слову, это самый старый реестр).
Итак, создание нового локального реестра по его правилам состоит из
трех шагов:
1. Создание в списке RIPE элемента, описывающего новый локальный
реестр.
2. Ознакомление с процедурой регистрации.
3. Заключение договора между новым локальным реестром и RIPE.
Чтобы все это выполнить, вам не потребуется лично являться в
учреждения, отстаивать очереди у кабинетов чиновников — будет достаточно
возможностей обычной электронной почты.
17.5.2. Когда договор заключен...
Пройдя регистрацию, как новый локальный реестр, вы, прежде всего,
должны сделать следующее:
1. Распределить предоставленный вам интервал IP-адресов между
вашими клиентами.
2. Получить номер автономной системы (АС), связанный с вашей сетью.
3. Зарегистрировать объект маршрутизации, описывающий
маршрутизацию между отдельными АС и вашей сетью.
17.5.3. Базы данных RIPE
Базы данных RIPE используются для хранения информации об
интернет-объектах в Европе: об интервалах IP-адресов, доменах, объектах
маршрутизации и т. д. Поскольку все эти объекты кем-то администри-
руются, в базе данных RIPE содержится контактная информация
администраторов этих объектов.
Вся данная информация содержится в виде объектов различных типов,
наиболее используемыми из которых являются объекты:
• inetnum,
• domain (домен),
• person (персона),
565

TCP/IP и DNS в теории и на практике. Полное руководство
• role (роль),
• aut-num.
Объект Inetnum
Данный объект описывает интервал назначенных IP-адресов. Он
содержит сам IP-интервал, имя владельца — физического или юридического
лица, контактную информацию, то есть телефон или адрес
ответственного за диапазон человека, с которым можно связаться в случае
возникновения проблем с этим IP-интервалом.
Объект inetnum связывается с объектом Персона, который содержит
однозначный идентификатор (RIPE-handle) администратора данного
интервала.
Пример:
inetnum:
netname:
descr:
country:
admin-c:
tech-c:
rev-srv:
rev-srv:
status:
changed:
changed:
source:
194.149.96.0 - 194.149.111.255
PVTNET
PVT Czech Internet Provider Network
CZ
HP1171-RIPE
HP1171-RIPE
ns.pvt.net
nsl.pvt.net
ASSIGNED PA
dostalek@pvt.cz 19960524
kabelova@pvt.cz 19990111
RIPE
Нужно учитывать, что объекты, подобные этому, могут встречаться в
базах данных других RIR. Рассмотрим, например, объект из базы данных
APNIC:
inetnum:
netname:
descr:
descr:
descr:
descr:
country:
203.0.0.0 - 203.63.255
AUNIC-AU
Telstra Internet
5/49 0 North Bourne Av.
Dixson
Canberra ACT 2903
AU
566

Глава 17. Интеренет-реестры
admin-c: GH105
tech-c: GH105
remarks: nationalnic
notify: dbmon@apnic.net
mnt-by: MAIN-APNIC-AP
changed: paulg@apnic.net 19981029
source: APNIC
Объект Domain (Домен)
Данный объект описывает домен и содержит имя домена, информацию
о пользователе, который зарегистрировал домен, а также информацию
о серверах имен домена:
Пример:
domain:
descr:
descr:
admin-c:
tech-c:
zone-c:
nserver:
mnt-by:
changed:
source:
pvt.cz
PVT, Ltd
Ceske Budejovice
LD3-RIPE
PB25-RIPE
LD3-RIPE
ns.pvt.net nsl.pvt.net snmpO.pvt.net
net nsl.pipex.net
CZ-DOMREG
ors@Czechia.EU.net 981114
RIPE
nsO.pipex
Объекты Person (Персона) и Роье(Роль)
Регистрация контактных лиц осуществляется с помощью объекта
Person (Персона). Данный объект описывает одно контактное лицо:
фамилию, имя, адрес, номер телефона, номер факса и электронный
адрес (e-mail).
Объект Role (Роль) описывает роль, выполняемую контактным лицом,
например, роль администратора. Совсем необязательно, чтобы одну
роль (функцию) выполнял один человек: администраторов может быть
несколько — каждый администратор выполняет свои функции. Поэтому
объект Role (Роль) может содержать несколько RIPE-идентификато-
ров администраторов.
567

TCP/IP и DNS в теории и на практике. Полное руководство
Рассмотрим примеры объектов Person (Персона) и Role (Роль):
role: Hostmaster PVTNET
address: Prague
e-mail: hostmaster@pvt.net
admin-c: PS2771-RIPE
admin-c: JD1802-RIPE
admin-c: AK291-RIPE
tech-c: PS2771-RIPE
nic-hdl: HP1171-RIPE
not i fу: hm-dbm-msgs@ripe.net
changed: kabelova@pvt.cz 19990122
source: RIPE
person: Petr Svihalek
address: PVT a.s.
address: Podvinny mlyn 2178/6
address: Prague 9
address: 190 00
phone: +420 2 66198432
fax-no: +420 2 66198678
e-mail: svihalek@pvt.net
nic-hdl: PS2771-RIPE
changed: svihalek@pvt.net 19990211
source: RIPE
Объект Aut-num
Объект Aut-num описывает автономную систему, особенно
маршрутизацию между соседними автономными системами.
Пример:
aut-num: AS5490
descr: PVTNET
descr: PVT public IP network
descr: Czech Republic
as-in: from AS701 100 accept ANY
as-in: from AS702 100 accept ANY
as-in: from AS8593 100 accept ANY
as-in: from AS2819 100 accept AS2819
as-in: from AS6881 100 accept AS1902 AS2605 AS2686 AS2852 AS5407
568

Глава 17. Интеренет-реестры
as-in: from AS6881 100 accept AS5578
as-in: from AS6881 100 accept AS5588 AS5620 AS6706 AS6721 AS6740
as-in: from AS6881 100 accept AS6881
as-in: from AS6881 100 accept AS8248 AS8316 AS8593 AS8679 AS8747
as-in: from AS6881 100 accept AS8913
as-out: to AS2819 announce AS5490
as-out: to AS701 announce AS5490
as-out: to AS702 announce AS5490
as-out: to AS8593 announce AS5490
as-out: to AS6881 announce AS5490
default: AS701 100
admin-c: JD1802-RIPE
admin-c: PS2771-RIPE
tech-c: MM107-RIPE
tech-c: IV15-RIPE
notify: ripe-notify@pvt.net
mnt-by: ASPVT-MNT
changed: hostmaster@pvt.net 19990127
source: RIPE
Объект маршрутизации
Объект этого типа содержит информацию об автономной системе и ее
IP-интервале.
Пример:
route:
descr:
origin:
mnt-by:
changed:
source:
194.149.96.0/19
PVTNET
AS5490
ASPVT-MNT
drdak@pvt.net 970403
RIPE
Объект Mntner
Данный объект используется для аутентификации во время
обслуживания объекта, то есть объект в базе данных может быть
модифицирован только определенным человеком, прошедшим
аутентификацию.
569

TCP/IP и DNS в теории и на практике. Полное руководство
Пример:
mntner: DOSTALEK
descr: Libor Dostalek
admin-c: LD3-RIPE
tech-c: LD3-RIPE
upd-to: dostalek@pvt.cz
mnt-nfy: dostalek@pvt.cz
auth: CRYPT-PW dCGQHlDfjU4to
mnt-by: DOSTALEK
changed: dostalek@pvt.cz 960410
changed: kabelova@pvt.cz 980604
source: RIPE
Просмотр содержимого базы данных
Для просмотра базы данных используется программа whois, доступная
по адресу ftp://ftp.ripe.net/tools. Также на серверах RIR
доступны web-интерфейсы этой программы — вам не нужно загружать
программу и запускать ее со своего компьютера, достаточно зайти на
определенную страничку и ввести запрос к базе данных.
Рассмотрим пример работы с программой. Предположим, что нам
нужно запросить информацию об объекте inetnum 194.149.101.0.
Запрашивать будем из базы данных whois . ripe. net. Параметр -h программы
whois используется для указания сервера whois:
whois -h whois.ripe.net 194.149.111.255
inetnum: 194.149.96.0 - 194.149.111.255
netname: PVTNET
descr: PVT Czech Internet Provider Network
country: CZ
admin-c: HD915-RIPE
admin-c: IS845-RIPE
В результате выполненного запроса кроме объекта inetnum
отображается и другая информация, например, контактная информация.
Идентификатор персоны (контактного лица) записывается в виде XXn-RIPE,
570

Глава 17. Интеренет-реестры
где XX — это инициалы контактного лица, an — однозначный номер
(в пределах группы одинаковых инициалов). При вводе объекта
Персона в базу данных пользователь использует RIPE-идентификатор
AUTO-1XXX, который автоматически заменяется однозначным
идентификатором. RIPE-идентификатор указывается в строке nic-handle
объекта Персона.
Мы также можем получить всю ключевую информацию об
определенном домене (только для доменов первого и второго уровней, то есть для
.cz или .pvt.cz), например:
whois -h whois.ripe.net pvt.cz
domain:
descr:
descr:
admin-c:
tech-c:
zone-c:
nserver:
changed:
source:
pvt.cz
PVT, Ltd.
Ceske Budejovice
LD3-RIPE
PB25-RIPE
LD3-RIPE
mh.pvt.cz ns.eunet.cz
ors@Czechia.EU.net 960402
RIPE
...Далее следует контактная информация.
Вместо программы whois часто используется программа telnet. Сервис
whois работает на 43-м порту, поэтому мы можем легко подключиться
к этому порту с помощью telnet:
telnet whois.ripe.net 43
последовательность команд
Я рекомендую вам воспользоваться командой help, чтобы получить
синтаксис и описание всех команд. Кроме того, web-интерфейс программы
whois можно найти по адресу: http: / /www. ripe . net.
17.5.4. Связь с RIPE
Связь с RIPE производится исключительно по e-mail. Ваши запросы
нужно отправить на определенный e-mail адрес RIPE. После этого RIPE
возвращает идентификацию вашего запроса в начале темы сообщения.
571

TCP/IP и DNS в теории и на практике. Полное руководство
Идентификация записывается в форме NCC#номер, то есть, например,
NCC#1234567. Данный идентификатор будет повторяться во всех
дальнейших ответах на данный запрос.
Получение нескольких ответов на один вопрос происходит довольно
часто, поскольку запрос сначала обрабатывается роботом, а затем —
персоналом RIPE. Сначала вы получаете ответ от робота, а затем — от
персонала.
Изменение базы данных
Только авторизированное лицо может вводить, модифицировать или
удалять объекты. Соответствующие запросы на ввод новых данных
в базу данных RIPE, модифицирование или удаление объекта
выполняются по e-mail: они отправляются на адрес: auto-dbm@ripe.net.
Письма по этому адресу получает робот.
Если запрос формально корректен, и вы имеете право на
модифицирование базы данных, робот обрабатывает ваш запрос и отправляет вам
информационное сообщение об этом. Если в запросе есть ошибка, робот
отправляет вам сообщение об ошибке с просьбой исправить ее и
повторить запрос. Детальное описание ошибки приводится в письме.
Как добавить объект в базу данных
Сначала вам нужно создать бланк — пустую форму для описания
объекта. Пустые формы описаны в RIPE-нормах (например, в RIPE-159
находится описание регистрации обратного домена).
Форма состоит из ключевых слов, заканчивающихся двоеточием. После
него должно быть указано значение.
Рассмотрим пример пустой формы для создания нового объекта inetnum:
inetnum:
netname:
descr:
descr:
country:
admin-c:
tech-c:
notify:
572

Глава 17. Интеренет-реестры
changed:
source:
RIPE
Пример заполнения формы можно найти в самой базе данных — просто
посмотрите, как заполняются объекты данного типа. Заполненную
форму нужно отправить для обработки по адресу: auto-dbm@ripe . net.
Через пару минут вы получите сообщение от робота: или
отрицательный, если вы допустили ошибку (с описанием ошибки, как говорилось
выше); или о том, что база данных успешно обновлена.
Рассмотрим пример «общения» с роботом:
Листинг 17.1. Запрос
Subject: LONGACK
Date: Thu, 10 Sep 1998 09:32:06 +0100
From: Alena Kabelova <kabelova@pvt.cz>
To: auto-dbm@ripe.net
inetnum:
netname:
descr:
descr:
descr:
descr:
country:
admin-c:
tech-c:
status:
changed:
source:
person:
address:
address:
phone:
fax-no:
nic-hdl:
changed:
source:
195.47.38.31
195.47.38.16
DIGITIS
Digitis a.s.
Skalova 2490
Tabor
390 02
cz
AUTO-1LJ
AUTO-1LJ
ASSIGNED PA
kabelova@pvt.cz 980910
RIPE
Libor Jinda
Skalova 2490
390 02 Tabor
+420 361 281 685
+420 361 281 634
AUTO-1LJ
kabelova@pvt.cz 980910
RIPE
573

TCP/IP и DNS в теории и на практике. Полное руководство
person: Tomas Sevcik
address: Hroznova 2
address: 656 06 Brno
phone: +420 05 43321304
fax-no: +420 05 43211148
e-mail: sevcik@zeus.cz
nic-hdl: AUTO-2TS
changed: kabelova@pvt.cz 980910
source: RIPE
Листинг 17.2. Ответ
Subj ect: SUCCEEDED: LONGACK
Date: 10 Sep 1998 07:33:21 -0000
From: RIPE Database Management <ripe-dbm@ripe.net>
To: Alena Kabelova <kabelova@pvt.cz>
В теле письма говорится, что запрос был успешно обработан, но чтобы
изменения вступили в силу, нужно подождать 10 минут.
> From: Alena Kabelova <kabelova@pvt.cz>
> Subject: LONGACK
> Date: Thu, 10 Sep 1998 09:32:06 +0100
> Msg-Id: <35F78E86.A60E23A7@pvt.cz>
Обновлению подверглись следующие объекты.
New OK
New OK
New OK
[person] LJ460-RIPE (Libor Jinda)
[person] TS2088-RIPE (Tomas Sevcik)
[inetnum] 195.47.38.16 - 195.47.38.31
Обратите внимание, как указываются идентификаторы
администраторов. Вам не нужно указывать реальные RIPE-идентификаторы — за
вас это сделает робот. Вместо идентификатора можно просто написать
AUTO-nXX, где п — это порядковый номер, а XX — инициалы
администратора. Вот почему в рассмотренном примере идентификаторы указаны
в форме AUTO-1LJ и AUTO-2TS.
Как модифицировать объект базы данных
Если вам нужно модифицировать объект в базе данных, лучше всего
извлечь из нее исходный объект, модифицировать его и отправить моди-
574

Глава 17. Интеренет-реестры
фицированный объект обратно по адресу auto-dbm@ripe . net, указав
в теме сообщения служебное слово LONGACK. Как показано в
предыдущем примере, вам нужно подождать ответа несколько минут.
Вы должны иметь в виду, что ключевые данные не могут быть
модифицированы. Например: компания изменяет имя своего домена. Невозможно
изменить объект существующего домена. Если вам нужно изменить имя
объекта, сначала нужно удалить объект, а потом создать его заново.
Как удалить объект
Удаление объекта подобно его модификации. Сначала описание старого
объекта должно быть введено в файл. После этого нужно добавить строку:
delete: my_e-mail_address [почему]
Вы должны ввести ваш e-mail и указать причину удаления объекта.
Файл нужно отправить на auto-dbm@ripe. net.
17.5.5. Назначение IP-адресов
и номеров автономных систем.
Регистрация обратных доменов
В этих случаях связь с RIPE происходит в два этапа:
1. Вы отправляете заполненную форму с вашим запросом, который
проверяется роботом (программой).
2. После формальной проверки данный запрос обрабатывается
персоналом. Вы будете проинформированы о ходе выполнения вашего
запроса по e-mail. Имейте в виду, что ответ от робота может прийти
через пару минут (максимум — через несколько часов), а ответа от
персонала можно ждать сутками.
Работа с базой данных RIPE описана в документе RIPE-238.
17.5.6. Распределение адресного пространства
Запрос на распределение адресного пространства производится в
соответствии со стандартом RIPE-235 «Форма запроса на распределение
адресного пространства IPv4». Форму в ASCII-формате может отправить
только LIR. Отправлять ее нужно по адресу: hostmaster@ripe . net.
575

TCP/IP и DNS в теории и на практике. Полное руководство
Провайдер должен заполнить такие же формы для своих клиентов и
отправить их в RIPE на одобрение. Провайдер может официально
выделить IP-адрес клиенту и ввести соответствующий объект в базу данных,
но только после того, как запрос будет одобрен RIPE.
Данная процедура довольно длинная, RIPE должен убедиться, что
провайдер работает удовлетворительно (проверить качество его работы),
и только после этого он может назначить провайдеру окно IP-адресов.
Окно — это общее число адресов, которые провайдер может
распределять между своими клиентами без предшествующего одобрения RIPE.
То есть теперь эти IP-адреса принадлежат провайдеру, и он вправе делать
с ними всё, что захочет. Окно обычно представляется в форме префикса,
то есть, если провайдеру нужно 256 адресов, ему назначается окно /24.
Важно отметить, что окно — это общее количество адресов провайдера.
Например, пусть у нашего провайдера есть окно /24 (256 адресов). Какой-
то клиент запросил у провайдера 128 адресов. Провайдер выделил ему их.
Теперь у провайдера осталось 128 адресов. Со временем клиенту
понадобилось еще 192 адреса. В этом случае провайдер вынужден повторно
послать запрос RIPE — на расширение окна, потому что 128+192 > 256.
В этом случае возможны два варианта распределения адресного
пространства:
• Выделенное адресное пространство будет назначено провайдеру,
и он может распоряжаться им, как ему заблагорассудится.
• Выделенное адресное пространство может быть назначено
непосредственно конкретному клиенту провайдера, который запросил
расширение адресного пространства.
Итак, провайдер обычно распределяет IP-адреса клиентам из того
интервала, который был ему выделен RIPE. При необходимости
провайдер может запросить дополнительное количество адресов.
После выделения дополнительных адресов, необходимо ввести
информацию о клиенте в базу данных RIPE. При выделении адресов клиенту
в базе данных создается объект inetnum. В него вносится информация
о клиенте. Идентификаторы ответственных администраторов
указываются в виде AUTO-nXX, где п — порядковый номер, а XX — инициалы
администратора. Рассмотрим пример:
inetnum: 194.149.100.0 - 194.149.100.15
netname: MY
576

Глава 17. Интеренет-реестры
descr: Private dealer Bloody Joseph
admin-c: AB23-RIPE
tech-c: CD98-RIPE
changed: hostmaster@joseph.cz
source: RIPE
17.5.7. Защита и контроль над изменениями в базе RIPE.
Уведомление и авторизация объектов
Ясно, что любой пользователь не может изменить базу данных RIPE —
иначе в Интернете воцарится полный хаос. В документе RIPE-223
«Работа с базой данных RIPE» описывается защита базы данных,
позволяющая модифицировать базу данных только авторизированным лицам.
При этом предусмотрено два механизма:
• Уведомление (нотификация) — самый простой метод контроля над
изменениями в базе данных. При этом вы указываете адрес
электронной почты, на который будут приходить сообщения об
изменении вашего объекта в базе данных. То есть запретить изменения вы
не можете, но, по крайней мере, вы будете постоянно в курсе дел.
Согласитесь, это не очень перспективно. Если вас это заинтересовало,
то в объект добавляется метка Notify:, а в качестве ее значения
указывается адрес (e-mail), на который будет приходить уведомление.
• Авторизация — более сложный, но и более эффективный метод,
контролируемый объектом mntner (maintainer). Сначала нужно создать
сам объект mntner (данный объект может создать только персонал
RIPE). Затем с помощью метки mnt-by: ссылаться на созданный
объект mntner.
Рассмотрим элементы объекта mntner:
mntner: Имя объекта (прописными буквами)
descr:
admin-c:
tech-c:
upd-to: Адрес e-mail, на который будет приходить уведомление
в случае, если неавторизированный пользователь
попытается изменить объект
mnt-ntf: Аналогично notify
auth: Тип авторизации, возможны значения:
19 Зак.518
577

TCP/IP и DNS в теории и на практике. Полное руководство
remarks:
changed:
source:
NONE (no authorization)
MAIL-FROM *@pvt.net.cz
CRYPT-PW зашифрованный пароль
PGPKEY
RIPE
Используются четыре типа авторизации:
1. NONE — без авторизации.
2. MAIL-FROM — с использованием имени компьютера, с которого
был отправлен запрос.
3. CRYPT-PW — с использованием пароля, сохраненного в объекте
mntner в закодированном виде.
4. PGPKEY — самая надежная аутентификация с использованием
PGP.
Авторизация CRYPT-PW позволяет обновлять объект, только если
в нем есть метка password: [ваш_пароль] в самом начале письма
с обновлением.
Пароль указывается сразу в зашифрованном виде. Зашифровать его
можно с помощью команды crypt в UNIX.
Авторизация MAIL-FROM позволяет обновлять объекты, только если
поле FROM содержит домен отправителя в качестве второго параметра
(в нашем случае, домен pvtnet. cz). Это не очень надежный способ
авторизации.
Пример:
mntner:
descr:
descr:
admin-c:
admin-c:
tech-c:
tech-c:
upd-to:
mnt-ntfy:
auth:
ASPVT-MNT
PVT a.s.
Internet Service Provider
BB31-RIPE
FD14-RIPE
LD11-RIPE
MM107-RIPE
registr@pvt.cz
registr@pvt.cz
MAIL-FROM *@pvt.cz
578

Глава 17. Интеренет-реестры
notify: registr@pvt.cz
mnt-by: ASPVT-MNT
changed: belousov@pvt.cz 951128
source: RIPE
17.6. Делегирование доменов второго уровня
С точки зрения IANA и администраторов корневых серверов,
определенный TLD-менеджер обслуживает конкретный TLD. С точки зрения
конечных пользователей и особенно с точки зрения провайдеров,
ситуация не столь проста. Мы должны иметь в виду, что TLD-менеджер
также гарантирует регистрацию доменов второго уровня (SLD, second level
domain), которые широко используются в разных странах. Во многих
странах регистрацией SLD занимается отдельная организация — Центр
сетевой информации (Network Information Center, NIC).
Наиболее вероятно, вы столкнетесь с одним из следующих типов
регистрации SLD:
• Регистрацией SLD занимается одна организация. Данная
организация управляет серверами определенного TLD, регистрирует SLD
и, в то же время, разрешает споры относительно доменных имен —
когда два (или более) клиента претендуют на одно и то же доменное
имя.
• Имеется одна центральная организация, которая только управляет
серверами имен и помогает решать споры относительно доменных
имен. Данная организация не занимается регистрацией SLD.
Регистрируют SLD непосредственно провайдеры. Конечные
пользователи за регистрацией SLD обращаются к своим провайдерам. Между
этой центральной организацией и провайдером находится одно
промежуточное звено — LRR (Last Resort Registry), то есть
вспомогательный реестр. Его задача состоит в том, чтобы принять «к себе»
клиентов провайдера в случае, если провайдер прекращает свою
деятельность. Ведь если провайдер закрывается, его клиенты
теряют регистрацию SLD, а этого нельзя допустить — следовательно, за
поддержку таких SLD будет отвечать LRR.

Глава 18
DNS В ЗАКРЫТЫХ
КОРПОРАТИВНЫХ СЕТЯХ
ЗАКРЫТЫЕ КОРПОРАТИВНЫЕ СЕТИ
И СВЯЗАННЫЕ С НИМИ DNS-ПРОБЛЕМЫ
КОРНЕВОЙ DNS-CEPBEP
В WINDOWS SERVER 2000/2003
TCP/IP и DNS в теории и на практике. Полное руководство

18.1. Закрытые корпоративные сети
и связанные с ними DNS-проблемы
Слово «закрытые», применительно к сетям, означает, что данная
корпоративная сеть (intranet) не подключена к Интернету. В главе 19 мы
поговорим о том, как защитить сеть, подключенную к Интернету, с помощью
брандмауэра. А сейчас речь пойдет о настройке DNS; то есть будем
считать, что ваша сеть вообще не подключена к Интернету. Казалось бы, что
может быть проще настройки DNS в закрытой сети? Но, на самом деле,
не так все просто, как кажется.
Предположим, что у вашей компании есть домен company. com. Имядоме-
на может быть абсолютно произвольным — хоть microsoft. com — ведь
ваша сеть не имеет доступа к Интернету. Вам предстоит сконфигурировать
один первичный сервер DNS и, хотя бы один, вторичный, то есть для нужд
DNS вам будет нужно как минимум два компьютера.
Резолверы клиентов вашей сети (то есть всех остальных компьютеров сети)
нужно настроить на эти серверы DNS. На рис. 18.1 показано, как клиент
запрашивает у сервера DNS разрешение имени узла server. company. com
в IP-адрес.
Все будет прекрасно работать, пока клиент не отправит запрос серверу
на разрешение имени server. ompany. com, то есть запрос, в котором
имеется какая-нибудь ошибка (пусть даже в одном символе). В
результате такой банальной ошибки сервер «повиснет» на относительно
долгое время — несколько десятков секунд, а, на протяжении этого времени,
десятки других клиентов будут ждать от него ответов. Ясно, что никому
такая работа сервера не понравится. Что же произошло?
Офисный сервер имен сконфигурирован только на обслуживание
домена company. com и ничего не знает о домене ompany. com. Ему остается

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 18.1. Разрешение имени server, company. com в IP-адрес
Рис. 18.2. Сервер корпоративной сети безуспешно пытается «достучаться»
до корневых серверов имен в Интернете

Глава 18. DNS в закрытых корпоративных сетях
лишь запросить преобразование доменного имени ompany. com у
корневых серверов имен, которые помогут ему найти авторитетный сервер
этого домена.
Но запросы вашего сервера так и не дойдут до корневых серверов имен,
поскольку ваша сеть не подключена к Интернету. Образно говоря,
дейтаграммы с запросом к корневым серверам будут отброшены на границе
вашей сети. Сервер имен будет упорно ждать ответа. По истечении
определенного времени он отправит клиенту сообщение об ошибке.
Терпеливый пользователь подождет и дождется сообщения об ошибке, но
большинство пользователей перезагрузит компьютер.
Прежде всего, администратор сервера (то есть вы) должен осознать, что
корневые серверы имен недоступны из корпоративной сети, потому что
она не подключена к Интернету. Также вы должны помнить о том, что
данные о корневых серверах имен загружаются в кэш сервера имен при
его загрузке. Файл кэша называется /var/named/named, ca.
Удаление этого файла — не самое удачное решение, к тому же, не
приводящее ни к какому результату. Сервер имен, не обнаружив файл кэша,
попытается обратиться к некоторым корневым серверам имен,
IP-адреса которых «зашиты» в самом сервере имен.
Решение показано на рис. 18.3.
1 Рис. 18.3. Корпоративный корневой сервер имен возвращает отрицательный ответ:
«В вашей сети нет домена ompany. com»
583

TCP/IP и DNS в теории и на практике. Полное руководство
Вместо удаления файла кэша вам нужно создать корневой сервер имен
вашей компании. Все запросы, не касающиеся домена company.com,
будут направлены к этому корневому серверу. Он просто будет
отправлять отрицательные ответы — мол, нет такого сервера, и все. Обращение
к корневому серверу вашей сети будет намного быстрее, чем
безуспешное ожидание ответа от корневого DNS-сервера Интернета, который
недоступен из вашей сети. Для корневого сервера вашей сети вам даже не
будет нужен еще один компьютер — сервер можно настроить на текущем
компьютере, создав первичный сервер имен для корневого домена.
18.2. Корневой DNS-сервер
в Windows Server 2000/2003
Если DNS-сервер не сконфигурирован как корневой, и файл %SystemRoot % \
system32\dns\cache.dns не существует (попросту говоря, удален),
Windows 2000 не предпринимает попыток «достучаться» до корневых
серверов имен.
В документации по Windows 2000/2003 сказано, что для работы сервера
имен в закрытой интрасети (корпоративной сети) достаточно удалить
файл %SystemRoot%\system32\dns\cache.dns.
При конфигурировании первичного сервера DNS система спросит вас,
желаете ли вы создать корневой сервер имен. В этом случае система
создаст файл зоны %SystemRoot%\system32\dns\root .dns для
корневого сервера. Позже, если вы хотите настроить DNS-сервер в качестве
корневого сервера, вам нужно будет создать новую forwarding-зону и
назвать ее «.».

Глава 19
DNS И FIREWALL
ОБЩАЯ DNS: ДЛЯ ИНТЕРНЕТА
И ЛОКАЛЬНОЙ СЕТИ
СЕРВЕР ИМЕН, ИНСТАЛЛИРОВАННЫЙ
НА БРАНДМАУЭРЕ
ДУБЛИРОВАННЫЙ DNS
TCP/IP и DNS в теории и на практике. Полное руководство

Брандмауэр (он же бастион, межсетевой экран и firewall)
отделяет внутреннюю сеть компании (корпоративную сеть) от Интернета.
Брандмауэр, кроме того, что предоставляет компьютерам компании
доступ к Интернету, защищает внутреннюю сеть от вторжения извне,
то есть из Интернета. Как выглядит брандмауэр? Обычно это
работающий под управлением UNIX или Windows 2000 Server компьютер,
на котором могут быть запущены различные сервисные приложения —
пакетный фильтр, DNS-сервер, прокси-сервер, web-сервер, почтовый
сервер и т. д.
Предположим, что домен нашей компании, как и в предыдущей главе,
называется company.com. Этот домен используется как для
внутренней сети, так и для внешней, то есть для Интернета. Домен company. com,
используемый для Интернета, скорее всего, будет содержать всего
несколько записей — www.company.com, mail.company.com и т. д.
А вот домен company.com, используемый в домашних целях, может
содержать десятки, сотни и даже тысячи записей различных компьютеров.
Выходит, что у нас есть два домена company . com, в каждом из
которых разное количество записей, но ведь имя-то у них одно и то же.
Как их различить? В Интернете не может быть двух доменов с
одинаковым именем. Но если одно из одинаковых имен будет
использоваться только в локальной сети, никаких недоразумений возникнуть
не должно.
Проблема может возникнуть с брандмауэром как таковым. На
брандмауэре будут запущены приложения (например, прокси-сервер),
которым нужно работать и с интернет-версией домена company. com, и
с локальной версией домена, имеющей то же название. Брандмауэр —
это единственный сервер сети, который «общается» непосредственно
с другими узлами Интернета. Все остальные узлы локальной сети «не
видны» извне.

Глава 19. DNS и Firewall
Приложения, запущенные на брандмауэре (прокси-сервер),
используют резолвер для разрешения доменных имен. Сервер имен также может
быть запущен на брандмауэре. Нужно отметить, что если сервер имен
запущен на брандмауэре, то не нужно настраивать резолвер на этот узел,
то есть на 127.0.0.1.
При подключении интрасети к Интернету возникают две проблемы.
Первая — это подключение брандмауэра и назначение IP-адреса.
Вторая — взаимосвязь DNS и брандмауэра. Если ваш сервер имен,
например, BIND v9.2 и выше, используется на брандмауэре, проблему можно
считать решенной с помощью техники просмотров. С другой стороны,
данная техника используется довольно редко и поддерживается не
всеми серверами имен. В этой главе мы рассмотрим проблемный вариант,
когда техника просмотров не используется или не поддерживается
сервером. Мы проанализируем некоторые ситуации, основанные на
реальных сценариях.
19.1. Общая DNS:
для Интернета и локальной сети
Самое простое решение заключается в общем использовании базы
данных DNS Интернетом и локальной сетью. Но это нам не подходит по
двум причинам:
• Адреса локальной сети (например, 10/8, 172.16/12 или 192.168/16)
нельзя использовать в Интернете.
• Даже если у вас для каждого компьютера есть свой реальный
IP-адрес, который можно использовать в Интернете, «общая» база данных
DNS — не самое лучшее решение, поскольку тогда каждому
желающему была бы доступна информация о структуре сети, а она обычно
является конфиденциальной.
Наиболее существенный вопрос при конфигурировании DNS на
брандмауэре заключается в следующем: будут ли по локальной сети
транслироваться адреса Интернета, или же по ней будут транслироваться только
внутренние адреса локальной сети (то есть передаваться дейтаграммы
только с внутренними адресами)?
587

TCP/IP и DNS в теории и на практике. Полное руководство
19.1.1. Трансляция всего Интернета по локальной сети
Если Интернет транслируется по локальной сети, локальная сеть должна
маршрутизировать кроме своих IP-адресов еще и IP-адреса Интернета,
то есть реальные интернет-адреса. При этом возникают два
отрицательных эффекта:
1. Маршрутизация локальной сети должна быть готова к такому
повороту событий, то есть все IP-адреса, не принадлежащие локальной
сети, должны быть перенаправлены на брандмауэр. Вроде бы в
настройках нет ничего сложного — просто нужно создать запись
default (маршрут по умолчанию) в таблицах маршрутизации каждого
компьютера и каждого маршрутизатора локальной сети. Проблема
возникнет чуть позже, потому что хранение данной записи в
таблицах маршрутизации каждого маршрутизатора локальной сети,
особенно в огромных сетях, — задача не из легких.
2. Сетевые администраторы, отвечающие за безопасность сети,
должны определенным образом настроить сеть, чтобы защитить ее от
атак извне, которые возможны при такой схеме настройки
брандмауэра. Если по сети транслируются только адреса локальных сетей,
то есть 10/8, 172.16/12 или 192.168/16, адрес атакующего может
быть легко вычислен, поскольку он выходит за рамки указанных
диапазонов. Тут все просто: если адрес не принадлежит адресу
нашей сети, значит, дейтаграмму с этим адресом нужно отбросить.
Если же по сети разрешается трансляция реальных IP-адресов, то
не совсем понятно, что с ними делать: это может быть и полезная
информация* которую запросил клиент нашей сети, и дейтаграмма
атакующего злоумышленника. То есть ситуация немного
усложняется и приходится использовать другие, более сложные, методы
защиты.
Передача адресов Интернета по локальной сети используется в двух
случаях:
1. Если на брандмауэре запущен прозрачный прокси-сервер.
Прозрачный прокси абсолютно незаметен для пользователей сети — они
вообще не подозревают о его существовании. Особенно дружественно
прозрачный прокси настроен на работу с РОРЗ, http, ftp, telnet и др.
Если пользователь хочет зарегистрироваться с помощью telnet на
каком-то удаленном интернет-узле, скажем на www.msn.com, ему
совсем не обязательно сначала регистрироваться на прокси-сервере —
588

Глава 19. DNS и Firewall
пользователь просто вводит команду telnet www. playboy. com. Таким
образом, у пользователя складывается впечатление, что его
компьютер — часть Интернета, и пользователь работает непосредственно
с удаленным узлом. Хотя, на самом деле, он работает с прозрачным
прокси, который принимает запросы к удаленному узлу, связывается
с ним, получает ответ и отправляет его компьютеру локальной сети,
отправившему запрос.
Но программу telnet используют далеко не все пользователи
локальной сети. Чаще к www. msn. com они обращаются с помощью
интернет-браузера. Браузеры также без проблем работают с прозрачным
прокси — им «кажется», что они работают непосредственно с
удаленным узлом.
По большому счету, в обработке РОРЗ-запросов прозрачным
прокси особой нужды нет. Сотрудники компании обычно используют
корпоративный РОРЗ-сервер, а для подключения к нему прокси не
нужен. Даже если у сотрудника есть ящик на каком-то бесплатном
почтовом сервере, скажем, на mail. г и, и он из локальной сети не
может обратиться к нему по РОРЗ, он без проблем может
использовать web-интерфейс и подключиться к mail. г и с помощью браузера.
2. На брандмауэре должен быть установлен пакетный фильтр — это
особенно важно для безопасности внутренней сети.
Брандмауэр обычно выступает в качестве первичного сервера имен (то
есть на брандмауэре установлен сервер DNS) домена company.com
(см. рис. 19.1), который является общим первичным сервером как для
Интернета, так и для корпоративной сети.
Наличие хотя бы двух серверов DNS — первичного и вторичного —
отличное решение. Но, в случае с подключенной к Интернету
корпоративной сетью, вам нужно как минимум три сервера DNS. Один сервер будет
первичным — как правило, он должен быть запущен на брандмауэре.
Два остальных — вторичные серверы: один сервер для локальной сети,
а другой — для Интернета, который обычно запускается на сервере
провайдера. Это делается опять-таки для дублирования основного сервера
в случае его временной недоступности. Ведь, если вторичный сервер
будет только в Интернете, то, в случае неполадки брандмауэра, можно
считать, что работа всей локальной сети будет остановлена — ведь
разрешать имена будет некому.
589

TCP/IP и DNS в теории и на практике. Полное руководство
Internet
Клиент
Вторичный
сервер имен
для company.com
Firewall
первичный
сервер имен
для company.com
Вторичный
сервер имен
для company.com
Forwarder
Рис. 19.1. Брандмауэр выступает в качестве первичного сервера имен
В локальной сети вторичный сервер можно развернуть на любом
принадлежащем ей компьютере. Если клиент локальной сети запросит
разрешение имени другого домена непосредственно у брандмауэра, то
брандмауэр запросит один из корневых серверов Интернета помочь ему
разрешить имя, переданное клиентом.
А вот если клиент запросит это же имя (например, www. msn. com) у
вторичного сервера, может возникнуть небольшая проблема. Ведь
вторичный сервер не подключен к Интернету и не может обратиться к
корневому серверу Интернета за помощью. Но чтобы разрешение имени
всё-таки произошло, вторичный сервер локальной сети
конфигурируется как подчиненный (slave) сервер первичного сервера (forwarder).
Запрос будет передан форвард-серверу (первичному), а после того, как
он разрешит имя, ответ (то есть IP-адрес) будет возвращен вторичному
серверу локальной сети, а затем — клиенту.
590

Глава 19. DNS и Firewall
19.1.2. По локальной сети
ПЕРЕДАЮТСЯ ТОЛЬКО ВНУТРЕННИЕ АДРЕСА
Давайте рассмотрим другую ситуацию. Трансляция интернет-адресов по
локальной сети вообще не нужна. На брандмауэре запущен
прокси-сервер. Перед установкой соединения с удаленным сервером клиент
должен наладить соединение с прокси-сервером, который потом установит
соединение с удаленным сервером. Поэтому прокси-сервер должен быть
в состоянии разрешить имя удаленного сервера. Вся дальнейшая связь
с Интернетом — только через прокси-сервер.
Чтобы лучше понять все только что сказанное, рассмотрим эти два
примера:
1. Подключение к www.msn.com из Интернета с помощью telnet, то
есть непосредственное подключение. Telnet обычно использует
порт 23, но никто вам не мешает указать порт 80 (HTTP) вместо 23.
Мы вводим команду telnet www. msn. com 80. Когда соединение
будет установлено, мы вводим следующую команду (уже в программе
telnet):
GET / HTTP/1.0
<Enter> <Enter>
Данная команда просто получит файл index.html (домашнюю
страницу). <Enter> — это клавиша на клавиатуре.
2. Подключение к www.msn.com из локальной сети через прокси-
сервер. Чтобы подключиться к www.msn.com мы сначала должны
подключиться к нашему прокси-серверу, например, telnet proxy 8080
(proxy — это имя прокси-сервера, а 8080 — это порт, обычно
используемый прокси-сервером). Чтобы получить index. html, мы
должны ввести команду:
GET http://www.msn.com HTTP/1.0
<EnterxEnter>
Видите разницу? Именно так работает браузер через прокси-сервер.
Конечно, для обычного пользователя разница практически
незаметна — все равно в результате он просмотрит страничку www. msn. com.
Обратите внимание: вы передали прокси-серверу имя удаленного
узла, а не его IP-адрес. На рис. 19.2 показано, как сконфигурировать
DNS локальной сети так, чтобы это не вызывало трансляции адресов
Интернета по локальной сети.
591

TCP/IP и DNS в теории и на практике. Полное руководство
Internet
Клиент
Вторичный
сервер имен
для company.com
Firewall
первичный
сервер имен
для company.com
Клиент
Intranet
Корневой
сервер имен
внутренней сети
Вторичный
сервер имен
для company.com
>Ч ч Итерация , • т
Рис. 19.2. Конфигурация DNS локальной сети
В локальной сети настраивается корневой сервер имен. Если DNS-
запрос содержит имя, не принадлежащее домену company. com,
запрос будет направлен корневому серверу, на что тот ответит: «В сети
нет других доменов».
В этом случае нам нужно четыре сервера DNS. Два будут находиться
«за брандмауэром» — корневой сервер локальной сети и вторичный
сервер имен; первичный сервер будет запущен на брандмауэре, и еще
один вторичный сервер имен будет запущен на сервере провайдера.
Важно отметить, что если клиент настроит свой резолвер
непосредственно на брандмауэре, то первичный сервер разрешит любой
интернет-адрес. Поэтому резолверы клиентов должны быть
направлены на внутренние серверы имен.

Глава 19. DNS и Firewall
19.2. Сервер имен,
инсталлированный на брандмауэре
Если мы хотим иметь две раздельные зоны для домена company. com,
первичный интернет-сервер нужно расположить на брандмауэре, а
вторичный интернет-сервер — на компьютере интернет-провайдера. Вторая
раздельная пара первичный/вторичный сервер устанавливается внутри
сети Интранет.
В результате мы имеем две возможности. Первая — в установлении
преобразования всего Интернета в Интранет, и вторая — в преобразовании
только интранет-зоны в Интранет.
19.2.1. Преобразование в локальной сети всего Интернета
Мы имеем две раздельные пары серверов имен (см. рис. 19.3). Одна из
пар ориентирована на Интранет, другая — на Интернет.
Первая проблема заключается в том, что приложения, запускаемые на
брандмауэре, например прокси, нуждаются в информации из зоны
Интранета (company. com), в то время как они также нуждаются в
информации из всех остальных интернет-доменов. Эта потребность
обеспечивается не установкой резолвера брандмауэра непосредственно перед
сервером имен брандмауэра, а на пути к доступному в зоне Интранета
серверу имен Интранета.
Если приложение на брандмауэре нуждается в преобразовании,
например www.playboy.com, то происходит запрос сервера имен
Интранета (стрелка 1 на рис. 19.3) для осуществления данного преобразования.
Сервер имен Интранета является подчиненным сервером,
посылающим все запросы, который он неспособен обработать, на брандмауэр
(см. стрелку 2 на рис. 19.3).
Сервер имен брандмауэра имеет доступ к корневому серверу имен
(см. стрелку 3 на рис. 19.3) и, в связи с этим, может осуществить
преобразование. Результат возвращается обратно подчиненному серверу,
который немедленно передает его клиенту на брандмауэре.
Клиент Интранета запрашивает преобразование у сервера имен
Интранета. Если это преобразование в локальном домене, клиент получает
ответ. Если необходимо преобразование в домене Интернета, такой запрос
осуществляется через брандмауэр.
593

TCP/IP и DNS в теории и на практике. Полное руководство
Рис. 19.3. Две раздельные пары серверов имен
19.2.2. Преобразование в локальной сети
без преобразования в интернете
Отсутствие преобразования Интернета в Интранет означает, что
необходимо создать корневой сервер имен Интранета (см. рис. 19.4).
Интересно, что имеется как минимум два сервера имен в Интранете, и каждый
из них имеет различные функции. Первый (обозначен как первичный
сервер имен на рис. 19.4) используется брандмауэром.
Если клиент Интранета направляет преобразование прямо на этот
сервер имен, сервер имен будет успешно осуществлять любое
преобразование из Интернет — или интранет-зоны company.com. Однако, это
594

Глава 19. DNS и Firewall
нежелательно, поскольку преобразование клиентов Интранета
происходит прямо через сервер имен Интранета, который использует корневой
сервер имен Интранета.
Корневой сервер имен Интранета препятствует преобразованию других
доменов.
Internet
КлиентЛ
Intranet
Корневой
сервер имен
Вторичный
сервер имен
для company.com
Firewall
первичный
сервер имен
для company.com
~~г~
резолвер
\ >
Корневой
сервер имен
внутренней сети
форвардер
Первичный
сервер имен
для company.com
форвардер
Вторичный
сервер имен
для company.com
итерация
Рис. 19.4. Обращение к корневому серверу имен Интранета
19.3. Дублированный DNS
Если мы хотим иметь для Интернета и Интранета раздельные зоны, то,
в случае совпадения имен, их нужно разместить на отдельных
компьютерах. Но в некоторых случаях этого не удается сделать, прежде всего,
595

TCP/IP и DNS в теории и на практике. Полное руководство
по экономическим причинам (денег жалко на два компьютера). В этом
случае запуск первичного сервера имен домена company. com как для
Интернета, так и для Интранета производится на одном компьютере.
Это и называется дублированием DNS.
В то время как в больших компаниях много различных серверов
работают только на нужды локальной сети, обеспечивая операции с
именами, небольшие фирмы часто вынуждены инсталлировать DNS-сервер
локальных имен в качестве дополнительного к серверу имен,
работающему с именами Интернета. В этом случае два сервера имен
запускаются на брандмауэре (два процесса). Каждый из них запускается на
отдельном порте. На рис. 19.5 показано, что сервер имен Интернета
запущен на порте 7035, в то время как сервер имен Интранета запущен
на порте 8053.
Internet
Клиент
\
:"■
. s~
Преобразование
www.playboy.com
В
Клиент
Intran
Bt
/
Пре
serve
. ' •;
У
/
DNS proxy
port 53 л
/
образование
г.сотрапу.сот
V *' •
\
-
%
^
<
^
^
Корн
серве|
евой
эимен
' Сервер имен
внешней сети
' порт 7053
Сервер имен
внешней сети
порт 8053
Рис. 19.5. Сервер имен Интернета запущен на порте 7035,
а сервер имен Интранета — на порте 8053.
596

Глава 19. DNS и Firewall
Важно, что клиент вообще обращается к стандартному порту 53, и его
совершенно не касаются никакие сложности с двойными серверами
имен, существованием портов 7053 и 8053. Это возможно благодаря
использованию DNS-прокси, который запускается на стандартном порте
брандмауэра сервера имен. При этом DNS-прокси обеспечивает
идентификацию источников запроса. Соотнеся их с содержащейся у себя
информацией, DNS-прокси перенаправляет их либо на сервер имен порта
7053, либо на сервер имен порта 8053.
Запрос может прийти:
• От клиента Интернета — тогда он обслуживается сервером имен
Интернета (порт 7053 на рис. 19.5).
• От клиента Интранета — тогда возможны два случая:
1. запрос на преобразование из домена company. com
поддерживается сервером имен Интранета (порт 8053 на рис. 19.5);
2. запрос на преобразование из другого интернет-домена
посылается на DNS-прокси для принятия решения:
• если мы хотим преобразовать Интернет в Интранете, то
тогда запрос поддерживается через сервер имен Интернета (порт
7053 на рис. 19.5);
• если мы не хотим преобразовать другие интернет-домены
в Интранете, то тогда мы даем отрицательный ответ.
Отметим, что у нас нет другого (то есть вторичного) сервера имен.
Отрицательный ответ выдается непосредственно DNS-прокси.

Глава 20 ЗАЩИТНЫЕ МЕХАНИЗМЫ
И УЯЗВИМОСТИ TCP/IP И DNS
БЕЗОПАСНОСТЬ И УЯЗВИМОСТИ IP
БЕЗОПАСНОСТЬ И УЯЗВИМОСТИ DNS
TCP/IP и DNS в теории и на практике. Полное руководство

20.1. Безопасность и уязвимости IP
Уязвимости IP
Даже на первый взгляд любая система, построенная на базе модели
TCP/IP, выглядит совершенно не надежной. Поскольку пересылаемые
пакеты данных могут сначала проходить по одному маршруту, потом по
другому, а затем — по третьему, по сути, они являются открытыми для
каждого пользователя, у которого возникнет желание их прочесть. Так,
например, предполагается, что маршрутизаторы (или компьютеры,
выступающие в качестве маршрутизаторов) при перенаправлении пакетов
данных считывают только заголовки из них (для определения адресата).
Однако ничто не мешает им прочитать и весь пакет данных. Это тем более
настораживает, если принять во внимание, что большая часть интернет-
трафика проходит через достаточно ограниченное количество
высокоскоростных линий (например, линий, связывающих разные континенты
или провайдерские пулы). Таким образом, большая часть трафика в
какие-то моменты своего пути проходит через некоторое, ограниченное
количество маршрутизаторов. Следовательно, в глобальном масштабе
не составляет большого труда «прослушивать» весь Интернет, получив
контроль над несколькими маршрутизаторами.
В реальности это могут позволить себе только государственные службы.
В «обычной» жизни злоумышленник стремится прослушать лишь
какой-то фрагмент сети, например, принадлежащей определенной
компании. Для этого он пытается получить контроль над компьютером
(маршрутизатором), расположенным рядом с интересующим его
фрагментом сети, так как через этот фрагмент с высокой степенью
вероятности пойдет либо весь трафик компании, либо его часть. Или
злоумышленник старается перенаправить трафик «прослушиваемой» компании
через себя, чтобы иметь к нему доступ.

TCP/IP и DNS в теории и на практике. Полное руководство
На сегодняшний момент существует огромное количество программ,
позволяющих осуществлять анализ пакетов (анализаторы пакетов). При
этом даже если пересылаемые данные зашифрованы, из пакетов все
равно можно получить необходимую информацию. Конечно, дешифровать
весь зашифрованный трафик не представляется возможным (слишком
большие мощности для этого нужны). Однако, наибольший интерес, как
правило, вызывают лишь определенные пакеты, например, пакеты с
паролями.
Так вот, обычно передача паролей осуществляется в числе первых
пакетов при обращении к какому-либо ресурсу. Таким образом, достаточно
перехватить лишь первые две-три дюжины пакетов.
Программа-анализатор это и делает. Потом в «спокойном режиме» можно передать
сохраненные данные программе-дешифровщику, а поскольку большинство
паролей не отличается сложностью и замысловатостью, при
правильном подходе взломать их не составит большого труда.
Помимо пассивного прослушивания в рамках TCP/IP можно
осуществлять и активные нападения. Более того, нападать на какой-либо ресурс
(сетевую службу), как правило, гораздо легче, чем ее прослушивать.
Отсюда и повсеместная, всеобщая распространенность сетевых атак.
Методы атак на TCP/IP
Наиболее характерными являются следующие виды атак на сетевые
приложения (службы), работающие на основе протокола TCP/IP:
• DoS-атаки (DoS — Denial of Service) — так называемые атаки на
«отказ в обслуживании». При этом атакуемое приложение (служба)
перегружается большим количеством обычных, либо
деформированных запросов, обработка которых занимает большое количество
времени. В обоих случаях служба (приложение, сервер) «зависает»,
и пользователям с ней становится невозможно работать. Также
можно выделить так называемые DDoS-атаки (DDoS, Distributed Denial
of Service — распределенный отказ в обслуживании) — это те же
самые DDoS-атаки, только осуществляемые с нескольких устройств.
• Хищение сеанса (Session Hijacking) — случаи, когда
злоумышленник пытается перехватить действующие сеансы связи посредством
специально заготовленных IP-пакетов, которые передаются ими их
системам функции управления. Это достаточно сложная, комплекс-
600

Глава 20. Защитные механизмы и уязвимости TCP/IP и DNS
ная атака, в ходе которой имитируются действия
зарегистрированного пользователя с целью получения доступа к системе.
• Анализ трафика (pocket sniffing, сниффинг). Об этом мы как раз
говорили в предыдущем разделе: злоумышленник получает контроль
над устройством (каналом), через которое осуществляется передача
данных, и с помощью специального программного обеспечения
анализирует трафик, например, на наличие в нем паролей к
защищенным ресурсам.
• Атака через слабые места в реализациях некоторых IP-служб.
Злоумышленник выявляет или узнает из каких-либо источников об
уязвимостях той или иной сетевой службы (в рамках той или иной
операционной системы), выясняет, активизирована ли эта служба на
компьютере «жертвы», и производит атаку. Получить информацию
об уязвимости в реализации той или иной службы особого труда
не составляет, так как в большинстве случаев она появляется в
открытых источниках (дабы предупредить общественность).
Единственной мерой защиты от подобных атак является либо правильная
перенастройка службы (или установка патча) — так как при
выявлении уязвимости, как правило, быстро разрабатывается «заплатка»
для нее, либо выключение службы. Одной из самых уязвимых и
подверженных атакам служб является служба удаленной регистрации
(remote logon service).
• Спуфинг (Spoofing) — подмена адреса отправителя, благодаря чему
пакеты с данными выдаются за пакеты доверительных ресурсов.
Принципы IP-защиты
В качестве рекомендаций по защите IP-служб от атак можно выделить
следующее:
• Отключение неиспользуемых IP-служб. Как говорится, если службы
нет, то и атаковать ее невозможно. Данная рекомендация
обусловлена тем, что во многих операционных системах и устанавливаемых
приложениях по умолчанию включаются некоторые сетевые
службы, которые не используются. Так вот, необходимо жестко
контролировать перечень работающих сетевых служб и, по возможности,
сокращать их количество.
601

TCP/IP и DNS в теории и на практике. Полное руководство
• Блокирование неиспользуемых портов. Каждый открытый порт, по
сути, может служить источником (лазейкой) для атаки. Существует
множество решений для этого. Выявить открытые порты
злоумышленнику труда не составит, так как сканеров портов сейчас тоже
«пруд пруди». Рекомендуется по возможности отключать
следующие порты (при этом напоминаем, что следует различать ТСР-пор-
ты и UDP-порты):
♦ TCP 53 — передача зоны DNS,
♦ UDP 69 — служба (демон) tftpd,
♦ TCP 87 — связующий порт,
♦ TCP 111, UDP 111, TCP 2049, UDP 2049 - службы SunRPC
и NFC,
♦ TCP в диапазоне 512..514 — команды г в BSD Unix,
♦ TCP и UDP в диапазоне 135..139 - NetBIOS,
♦ TCP 515 - служба Ipd,
♦♦♦ TCP 540 — служба uucpd,
♦ TCP 2000, UDP 2000 - служба openwindows,
♦ TCP и UDP с номерами от 6000 — служба X Windows.
• Пресечение использования спуфинга внутренних адресов —
ситуация, когда злоумышленник пытается проникнуть в сеть, выдавая свои
пакеты, приходящие извне, за внутренние пакеты сети. При этом
необходимо иметь ввиду, что внутренние пакеты никогда не приходят
в сеть извне, через выходной маршрутизатор (шлюз, брандмауэр).
• Запрет доступа по умолчанию. В рамках этого правила
необходимо запрещать, а не разрешать по умолчанию доступ пользователям
к ресурсам и сервисам сети. Разрешение производится лишь в виде
исключения (например, при правильно введенном пароле).
• Запрет внешнего доступа к важным хостам вашей внутренней сети.
В рамках этого правила старайтесь располагать ресурсы, к которым
открыт общий доступ из сети, на не критичных компьютерах сети,
атаки на которые не приведут к непоправимым последствиям.
• Постоянное тестирование сети на предмет безопасности.
Постоянно проводите тестовые попытки самим вторгнуться в вашу сеть.
Это поможет вам понять, какими путями будет идти злоумышлен-
602

Глава 20. Защитные механизмы и уязвимости TCP/IP и DNS
ник, а также позволит проверить вашу сеть и выявить (вам, а не
злоумышленнику) ее уязвимости в защите.
• Фильтрация нежелательных адресов.
20.2. Безопасность и уязвимости DNS
20.2.1. Уязвимости
Проблема безопасности применительно к службе DNS заключается
в том, что эта служба фактически не имеет никакой защиты. При этом,
когда компьютер-клиент посылает запрос на разрешение имени
серверу DNS и получает ответ, он по умолчанию считает ответ верным,
а сервер DNS — подлинным. В то же время между
компьютером-клиентом и сервером DNS пакет с ответом проходит, как правило, через
некоторое количество промежуточных узлов, на каждом из которых он
может быть подменен. Последствия же подмены могут быть самыми
разными, в зависимости от того, что и где именно было
сфальсифицировано.
Для того чтобы сфальсифицировать данные DNS, злоумышленник
может использовать несколько методов. Рассмотрим их в порядке
возрастания масштаба атаки [2].
• Злоумышленник отправляет подложный DNS-ответ (в нашем
примере — с неверным адресом хоста www.goodbank. com)
атакуемому хосту host .victim, com. Ответ отправляется от имени сервера
после того, как хост выслал серверу соответствующий запрос. Атака
направлена против одного хоста.
• Злоумышленник отправляет подложный DNS-ответ серверу
ns.victim.com, когда тому требуется найти адрес сервера
www.goodbank.ru. Сфальсифицированные данные сохраняются
в кэше сервера'ns.victim.com в течение указанного
злоумышленником времени жизни записи, которое может быть очень
большим. Действие атаки распространяется на все хосты, использующие
ns .victim, com в качестве своего DNS-сервера. Эту атаку
называют cache poisoning — отравление кэша.
• Злоумышленник от имени первичного сервера ns . goodbank. com
производит передачу сфальсифицированной зоны goodbank.com
на вторичный сервер ns2.goodbank.com. Таким образом, зло-
603

TCP/IP и DNS в теории и на практике. Полное руководство
умышленник вводит в заблуждение все DNS-серверы Интернета,
которые обращаются к ns2.goodbank.com за официальной
информацией о зоне goodbank. com, и, следовательно, все хосты,
которые пользуются услугами этих серверов — словом, значительную
часть Интернета.
• Используя динамическое обновление, злоумышленник
изменяет базу данных зоны goodbank. com на первичном сервере
ns.goodbank.com. В этом случае весь Интернет будет
пользоваться данными зоны goodbank.com, сфальсифицированными
злоумышленником [2].
20.2.2. Инструменты и механизмы защиты
Технология защиты TSIG
Из сказанного выше следует, что безопасность передачи данных DNS,
а особенно безопасность передачи зоны и динамического обновления,
имеет исключительно большое значение. Документ RFC-2845 вводит
механизм защиты передаваемых данных с помощью алгоритма MD5.
Механизм называется TSIG и заключается в том, что в каждое DNS-co-
общение добавляется виртуальная запись, содержащая хэш сообщения
и секретного ключа, известного только отправителю и получателю.
Запись TSIG называется виртуальной, потому что она не находится в базе
данных, а формируется динамически для каждого DNS-сообщения [2].
Для вычисления хэша на вход алгоритма MD5 подается блок данных,
содержащий секретный ключ, хэш запроса (если данное DNS-сообще-
иие является ответом), заголовок DNS-сообщения (не включая ТСР-
или UDP-заголовок), записи, содержащиеся в сообщении, и переменные
TSIG, среди которых: имя ключа, время создания сообщения и
допустимое расхождение часов отправителя и получателя. После того, как хэш
вычислен, в конец сообщения добавляется запись TSIG, содержащая
вышеуказанные переменные и собственно вычисленный хэш.
Получатель сообщения также вычисляет хэш, как описано выше,
используя свою копию секретного ключа, и если вычисленный хэш совпадает
с полученным в сообщении, это значит, что сообщение было
действительно отправлено легитимным узлом и не было изменено по дороге.
Механизм TSIG позволяет аутентифицировать любые DNS-сообщения:
передачу зоны, динамическое обновление и обычные запросы и ответы.
604

Глава 20. Защитные механизмы и уязвимости TCP/IP и DNS
Но позволяет только между хостами, знающими секретный ключ
(каждая пара хостов может иметь свой секретный ключ).
Очевидно, что это решение не масштабируется для всего Интернета
и не помогает в борьбе с отравлением кэша, но хорошо подходит для
защиты передачи данных между заранее определенными хостами: между
первичным и вторичными серверами зоны; между первичным сервером
и хостами, авторизованными для выполнения динамического
обновления; между сервером DNS и клиентами из его домена.
DNSSEC
Для обеспечения достоверной передачи DNS-данных в масштабе
Интернета в систему DNS вводятся расширения, называемые DNSSEC
(RFC-2535, а также RFC-2536,2537,2541,3008). Основная идея DNSSEC
состоит в использовании асимметричного шифрования для
присоединения цифровой подписи к передаваемым данным [2].
Как известно, асимметричное шифрование предполагает наличие
открытого и секретного ключей. Секретный ключ известен только
администратору первичного сервера зоны. Записи из базы данных зоны
пропускаются через хэширующий алгоритм (как правило, MD5), и
получившийся <отпечаток> шифруется с помощью секретного ключа —
так получается цифровая подпись.
Она заносится в базу данных зоны в виде записи специального типа SIG
и присоединяется к передаваемым данным при ответе на запрос.
Подчеркнем, что сами данные передаются в открытом виде (можно было
бы шифровать и собственно данные, но алгоритмы асимметричного
шифрования требуют большого объема вычислений, а данные DNS по
своей природе являются открытой информацией (требуется только
удостоверить ее подлинность), следовательно, целесообразнее шифровать
короткий хэш, чем весь объем данных).
Открытый ключ известен всем потенциальным получателям; он
хранится в базе данных зоны в записи специального типа KEY и может быть
востребован с помощью обычного запроса. Приняв данные и подпись,
получатель расшифровывает подпись с помощью открытого ключа.
Потом он вычисляет хэш полученных данных и сравнивает с тем, что
получилось после расшифровки подписи. Если хэши совпадают, то,
во-первых, данные действительно были отправлены владельцем секретного
ключа и, во-вторых, данные не были изменены при передаче.
605

TCP/IP и DNS в теории и на практике. Полное руководство
В отличие от TSIG, DNSSEC не требует от получателя знания
секретного ключа, что позволяет обойти неразрешимую задачу распространения
секретного ключа по всем возможным DNS-серверам глобальной сети
и решить проблему обеспечения достоверности передачи DNS-данных
в масштабе Интернета. Платой за это является существенное (в
несколько раз) увеличение базы данных каждой зоны и повышенные требования
к процессорной мощности DNS-серверов, которая требуется для
выполнения операций асимметричного шифрования и дешифрации.
Для реализации механизма DNSSEC вводятся три новых типа записей:
KEY, SIG и NXT. Подчеркнем, что все указанные записи генерируются
автоматически, а не составляются вручную.
Запись типа KEY содержит открытый ключ зоны, закодированный для
текстового представления с помощью алгоритма Base64.
Запись типа SIG содержит цифровую подпись для набора записей.
Набором являются все записи одного типа для одного доменного имени:
например, все записи типа MX для exmpl. г и. Получив запрос
определенного набора записей, сервер возвращает требуемые данные, а вместе
с ними — запись SIG, которая их удостоверяет. Цифровая подпись
также кодируется с помощью Base64. Кроме собственно цифровой подписи
запись SIG содержит время создания подписи и момент истечения ее
срока годности.
В заключении раздела, посвященного DNSSEC, перечислим программы
из пакета BIND 9, предназначенные для генерации ключей и записей
SIGhNXT[2].
• dnssec-keygen — генератор ключей,

dnssec-makekeyset — создание файла для подписи ключа
вышестоящей зоной,
dnssec-signkey — подпись ключа нижестоящей зоны,
dnssec-signzone — создание записей SIG и NXT в базе данных зоны.
Список литературы, использованный при подготовке
РУССКОГО ИЗДАНИЯ КНИГИ
ММамаев, http://www.nag.ru/goodies/netbook/ch2.html
M. Мамаев, С. Петренко. Безопасность DNS. http: / / i2r. rusf und. ru/
static/450/out_12033.shtml