Глава 20. Введение в сети TCP/IP

Глава 20. Введение в сети TCP/IP

Русский перевод: Вадим Лопатюк

20.1. Читателям

Эта глава разъясняет различные аспекты работы сети. Что предполагает помощь начинающим людям с небольшими познаниями сети. Она соотоит из трех больших частей. Мы начнем с рассмотрения главной части работы сети и основных концепций. Затем, во второй части, мы рассмотрим в деталях настройки различных типов сети и в третьей части раздела работы сети изучим некоторые «продвинутые» аспекты, для углубления познаний, полученных в первых двух разделах.

Предполагается что читатель знаком с основными задачами системного администратора: как войти под пользователем root, редактировать файлы, менять разрешения, останавливать процессы, и т.д. См. остальные главы этого руководства пользователя NetBSD и например [AeleenFrisch] для более глубокого ознакомления с данной темой. Кроме того, Вам необходимо знать как оперировать утилитами, которые будут здесь использоваться, например Вы должны знать как использовать telnet, FTP, ... Я не буду объяснять основные свойства каждой утилиты, пожалуйста обратитесь к соответствующим страницам помощи, спискам рассылки или используйте информацию из других частей данного документа.

Данное введение в работу сетей TCP/IP было написано с целью предоставить начинающим базовые познания. Если Вы действительно желаете узнать об этом все, прочтите [CraigHunt]. Эта книга содержит не только основы, но и разъясняет также все принципы, сервисы и содержит их детальное описание. Это прекрасно, я люблю это! :-)

20.2. Поддерживаемые сетевые протоколы

Существует блок из протоколов, поддерживаемых NetBSD, большинство из которых унаследовано и от предшественника NetBSD, 4.4BSD, и в последствии расширено и улучшено. Первый и самый важный, на сегодняшний день - DARPA протокол контроля доставки/Интернет протокол (Transmission Control Protocol/Internet Protocol - TCP/IP). Другие наборы протоколов доступные в NetBSD, включают сетевую систему Xerox (Xerox Network System - XNS) которая осуществляет лишь UCB подключение изолированных машин к сети, блок протоколов Apple - AppleTalk и блок протоколов ISO, CCITT X.25 и ARGO TP. Которые теперь используются лишь некоторыми специализированными приложениями.

Сегодня, TCP/IP - самый широко распространенный протокол из упомянутых выше. Он поддерживается практически всем аппаратным обеспечением и операционными системами, а также это самый используемый протокол в гетерогенном окружении. Так, если Вы хотите соединить компьютер с NetBSD к какой-либо другой машиной в домашней сети, или Вы хотите интегрировать его в сеть Вашей компании или университета, TCP/IP будет лучшим выбором. С другой стороны IP version 4 уже «стар» , но NetBSD также поддерживает "новый" IP version 6 (IPv6) начиная с NetBSD 1.5, благодаря соучастию в коде проекта KAME.

Однако другие блоки протоколов, такие как DECNET, Новелловский IPX/SPX или Microsoft's NetBIOS на данный момент не поддерживаются NetBSD. Эти протоколы отличаются от TCP/IP тем, что они очень специфичны, по сравнению с остальными, которые хоршо определены некоторыми RFC и другими открытыми стандартами.

20.3. Поддерживаемые носители

Стек протокола TCP/IP ведет себя одинаково, вне зависимости от лежащего в основе носителя и NetBSD поддерживает широкий их спектр, среди которых Ethernet (10/100/1000Мбод), Arcnet, последовательная линия, ATM, FDDI, оптоволокно, USB, HIPPI, FireWire (IEEE 1394) и Token Ring.

20.3.1. Последовательная линия

Вот несколько причин использовать TCP/IP в последовательном подключении.

  • Если удаленный хост доступен только через телефон, Вы можете использовать для доступа к нему модем.

  • Большинство компьютеров имеют последовательный порт, а кабель, необходимый для этого, очень дешев.

Недостаток последовательного подключения - он медленнее чем другие методы. NetBSD может использовать лишь 115200 bit/s, что намного медленнее чем, например, Ethernet, минимум которого 10 Мбит/с и Arcnet 4 Мбит/с.

Вот два возможных протокола соединения хоста с NetBSD с другим хостом, используя последовательную линию (возможно через телефонную линию):

  • Интернет протокол последовательной линии (Serial Line IP - SLIP)

  • Протокол «точка-точка» (Point to Point Protocol - PPP)

Здесь выбор зависит от используемого удаленного соединения: через модем или статическое подключение (нуль-модемное или выделенная линия). Если Вы подключаетесь через модем, лучше использовать PPP так как он позволяет автоматически получать IP-адреса и маршруты, которые довольно болезненно настраиваются вручную. Если Вы желаете подключиться к другой машине через прямое соединение - используйте SLIP, так как он поддерживается всеми операционными системами и более прост в настройках с фиксированным адресом и маршрутами.

PPP на прямом соединении немного более сложен в настройке, так здесь проще инициировать «рукопожатие» (handshake) по истечению времени; SLIP, не инициируется рукопожатием, т.е. Вы начинаете с одной стороны и тогда другая сторона получает первый пакет, котрый необходимо отправлять через линию.

[RFC1331] и [RFC1332] описывают PPP и TCP/IP через PPP. SLIP определен в [RFC1055].

20.3.2. Ethernet

Ethernet это носитель, наиболее часто используемый для построения локальных сетей (LAN) для подключения машин в ограниченном пространстве, таком как офис, компания или университетский городок. Ethernet основан на шинной структуре через которую много машин могут соединяться и обмениваться информацией между двумя узлами за промежуток времени, оба узла должны рестартовать обмен по истечении некоторого промежутка времени. Технические характеристики данного носителя: Чувствительный к передаче множественный доступ с определением коллизии CSMA/CD (Carrier Sense w/ Multiple Access and Collision Detection).

Изначально, аппаратное обеспечение Ethernet состоит из толстого (желтого) кабеля, соединяющего машины с использованием специального разъема, который прокалывает оплетку кабеля. Его предшественник назывался 10base5, использовал разъем типа BNC для соединения в специальных T-коннекторах с терминаторами на обоих концах шины. Сегодня, ethernet в основном использует линии на витой паре, применяемой в топологии типа «звезда», содержащей концентраторы или маршрутизаторы. Линии на витой паре дали этому типу носителя има - 10baseT для 10 Мбит/с сетей и 100baseT для 100 Мбит/с. В маршрутизируемом окружении, которое также отличается от коммуникаций через узлы, маршрутизатор может находиться в полно или полудуплексном режиме.

20.4. Формат адреса TCP/IP

TCP/IP использует 4-байтовые (32-битовые) адреса в теперешней реализации (IPv4), также называемые IP-адресами (Internet-Protocol адреса), для адресации хостов.

TCP/IP позволяет любым двум машинам общаться напрямую. Чтобы это осуществить все хосты, находящиеся в сети, должны иметь уникальный IP адрес. Чтобы гарантировать это, IP адреса контролируются одной центральной организацией - InterNIC. Она выдает определенные диапазоны адресов (сетевых адресов) напрямую сайтам, желающим войти в структуру Интернет или Интернет провайдерам, которые, в свою очередь, выдают адреса своим пользователям.

Если Ваш университет или компания подключены к Интернет, то он(она) имеет (как минимум) один такой сетевой адрес для собственных нужд, обычно полученный не напрямую от InterNIC, а через поставщика услуг Интрнет (Internet Service Provider ISP).

Если Вы всего лишь хотите запустить вашу частную сеть для дома, см. далее как «создать» Ваши собственные IP адреса. Тем не менее, если Вы хотите подключить Вашу машину к (реальной :-) Интренет, Вы должны получить IP адреса от Вашего локального администратора сети или провайдера.

IP адреса обычно записываются в «четырехчисловом с точками» формате - четыре байта записываются в десятеричной системе (наиболее значимые байты идут первыми), и разделяются точками. Например, 132.199.15.99 должен быть верным адресом. Другой способ записи IP адреса: можно использовать одно 32-битное шестнадцатеричное слово, например, 0x84c70f63. Это не так удобно как четырехчисловая форма, но также используется довольно часто (см. далее!).

Иметь доступ к сети не означает ничего более кроме установки вышеописанных 32 бит адреса в определенное значение. Некоторые биты используются для идентификации сети и называются сетевыми битами. Оставшиеся биты могут использоваться для адресации хостов в этой сети, их называют битами хоста. Рисунок 20.1, « IPv4 адреса делятся на большую часть определяющую сеть - и меньшую определяющую хост. » иллюстрирует разделение.

Рисунок 20.1. IPv4 адреса делятся на большую часть определяющую сеть - и меньшую определяющую хост.

IPv4 адреса делятся на большую часть определяющую сеть - и меньшую определяющую хост.

В приведенном выше адресе 132.199.0.0 (биты хоста выставлены в 0 в сетевом адресе), адрес хоста в этой сети - 15.99.

Откуда мы узнали что адрес хоста длинной 16 бит? Ну, это определяется провайдером, который предоставляет Ваши сетевые адреса. В классах междоменной маршрутизации (classless inter-domain routing CIDR) используемых теперь, размер поля хоста обычно находится в пределах от 2 до 16 бит, а количество бит сети пишется после сетевого адреса и отделяется «/», например, 132.199.0.0/16 говорит о том, что в данной нотации 16 сетевых бит. Когда говорят о «размере» сети, обычно имеется в виду «/16», «/24», и т.д.

До использования CIDR, использовались четыре класса сетей. Каждая начиналась с определенного набора битов, идентифицирующих ее. Вот эти четыре класса:

  • Сласс A начинается с «0» как самого значимого бита. Следующие семь бит адреса класса A определяют сеть, оставшиеся 24 бита могут использоваться для адресации хостов. Так в одной сети класса A может быть до 224 хостов. Вероятно нет необходимости для Вас (или Вашего университета, или компании, или чего-либо еще) использовать все пространство адресов класса A.

    В нотации CIDR сеть класса A с ее восемью битами сети это «/8».

  • Класс B начинается с «10» как самых значимых бит. Следующие 14 бит используются для адреса сети, оставшиеся 16 бит используются для адресации более 65000 хостов. Адреса класса B сегодня используются очень редко, они используются в основном компаниями и университетами редко встречающимся в адресном пространстве IPv4.

    В нотации CIDR сеть класса B с ее шестнадцатью битами сети будет описана как «/16».

    Возвращаясь к предыдущему примеру, Вы можете видеть что 132.199.15.99 (или 0x84c70f63, который здесь более уместен!) находится в сети класса B, так как 0x84... = 1000... (двоичная система).

    Следовательно, адрес 132.199.15.99 может быть разделен на адрес ести 132.199.0.0 и адрес хоста 15.99.

  • Класс C определяется по MSB со «110», позволяет адресовать лишь 256 (в действительности: лишь 254, см. далее) хостов в каждой из 221 возможных сетей класса C. Адреса класса C обычно используются в (небольших) компаниях.

    В нотации CIDR сеть класса C с ее двадцатью четырьмя битами сети будет описана как «/24».

  • Остальные адреса, начиная со «111». Используются в специальных целях (например, широковещательные адреса) и сейчас нас не интересуют.

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

Если отделить адрес хоста от адреса сети, легко получим «сетевую маску». В этой маске все биты сети установлены в «1», биты хоста «0». Таким образом, соединив вместе IP-адреса и сетевую маску логической функцией AND, получим адрес сети.

Продолжая наш пример, 255.255.0.0 возможная маска сети для 132.199.15.99. Если добавить эту маску, останется адрес сети 132.199.0.0.

Для адресов в нотации CIDR, количество бит сети скажут нам сколько значащих бит адреса необходимо установить в «1» чтобы получить сетевую маску для рассматриваемой сети. Для классовой адресации, каждый класс сети имеет фиксированную предустановленную маску:

  • Класс A (/8): предустановленная маска сети: 255.0.0.0, первый байт адреса: 1-127

  • Класс B (/16): предустановленная маска сети: 255.255.0.0, первый байт адреса: 128-191

  • Класс C (/24): предустановленная маска сети: 255.255.255.0, первый байт адреса: 192-223

Еще одно понятие, упоминаемое здесь - «широковещательный адрес». При обращении к этому адресу, все хосты рассматриваемой сети получат отправленное сообщение. Широковещательный адрес характеризуется установленными в «1» всеми битами хоста.

Говоря о 132.199.15.99 с сетевой маской 255.255.0.0, широковещательный адрес должен получиться 132.199.255.255.

Вы можете спросить: Но если я хочу использовать для адресации хостов все биты «0» или «1»? Ну, это не будет работать, так как сетевой и широковещательный адреса должны существовать! По этому, сеть класса B (/16) может содержать 216-2 хостов, а класса C (/24) не может содержать более 28-2 = 254 хостов.

С другой стороны кроме всех этих категорий адресов, существует специальный IP адрес 127.0.0.1 который всегда ссылается на «локальный» хост, т.е. если Вы обратитесь к 127.0.0.1 Вы будете общаться сами с собой без какой-либо сетевой активности. Это иногда используется программами, установленными на Вашей машине или для проигрывания окружения, если у Вас нет других хостов, подключенных к Вашей сети.

Давайте соберем вместе знания полученные в этом разделе:

IP адрес

32-битный - адрес, содержащий биты хоста и сети.

Адрес сети

IP адрес со всеми битами хоста, установленными в «0».

Маска сети

32-битная маска с «1» для битов сети и «0» для битов хоста.

Широковещательный адрес

IP адрес со всеми битами хоста выставленными в «1».

Адрес локального хоста (locahost)

IP адрес всегда равный 127.0.0.1.

20.5. Подсети и маршрутизация

После подробного обсуждения сетевых масок, адресов сети, хоста и других, я должен сказать, что это еще не вся правда.

Представьте ситуацию в Вашем университете, который обычно использует адреса класса B (/16), допустим имеется до 216 ~= 65534 хостов в этой сети. Может быть лучше иметь все эти машины в одной сети, но это просто невозможно из-за ограничений транспортных носителей зачастую используемых на данный момент.

Например, при использовании «тонкого» ethernet, максимальная длинна кабеля будет 185 метров. Даже с повторителями, в которых усиливается сигнал, этого будет не достаточно чтобы покрыть все необходимое расположение машин. С другой стороны, максимальное количество хостов на линию ethernet не может превышать 1024 и Вы потеряете часть производительности если перейдете этот предел.

Так, теперь вы в тупике? Имеете адрес, который позволяет использовать более 60000 хостов, но связаны носителем который позволяет использовать намного меньше этого предела?

Ну, конечно нет! :-)

Решение в разделении «большой» сети класса B на несколько меньших сетей, обычно называемых подсетями. Эти подсети лишь позволят иметь, скажем, 254 хостов в них (т.е. Вы разделите одну большую сеть класса B на несколько сетей класса C!).

Чтобы это сделать, Вам нужно изменить Вашу сетевую маску, увеличив количество сетевых бит и уменьшив количество бит хоста в ней. Для этого обычно достаточно границы байта, но Вы не обязаны делать это именно так. Так, часто Ваша сетевая маска не будет 255.255.0.0 как поддерживается сетью класса B, но ее можно установить в 255.255.255.0.

В нотации CIDR, Вы теперь запишете «/24» вместо «/16» показав, что 24 бита адреса используются для идентификации сети и подсети, вместо 16-ти которые использовались до этого.

Это даст Вам один добавочный байт сети для присвоения каждой (физической!) сети. Все 254 хоста в этой подсети смогут теперь обращаться напрямую к любому другому и Вы сможете создать 256 таких сетей класса C. Это должно удовлетворить Ваши требования.

Чтобы понять лучше этот момент, давайте продолжим наш предыдущий пример. Скажем наш хост 132.199.15.99 (я буду называть его dusk с этого момента; поговорим об назначении имен хостам позже) имеет маску сети 255.255.255.0 и таким образом он в подсети 132.199.15.0/24. Давайте, кроме того, введем еще немного хостов с которыми мы можем работать, см. Рисунок 20.2, «Наша демонстрационная сеть».

Рисунок 20.2. Наша демонстрационная сеть

Наша демонстрационная сеть

В данной сети, dusk может обращаться напрямую к dawn, так как они оба находятся в одной подсети. (Здесь имеются другие компьютеры подключенные к подсети 132.199.15.0/24, но на данный момент они для нас не имеют значения)

Но что, если dusk понадобится обратиться к хосту из другой подсети?

Тогда трафик пройдет через один или больше шлюзов (маршрутизаторов), которые подключены в две подсети. Поэтому, маршрутизатор всегда имеет 2 различных адреса, по одному для каждой подсети. Маршрутизатор функционально прозрачен, т.е. Вам не нужно обращаться к нему чтобы достичь хостов с «другой» стороны. Вместо этого, Вы обращаетесь к этому хосту непосредственно и пакеты будут правильно смаршрутизированы.

Например. Скажем dusk необходимо получить несколько файлов с локального ftp сервера. Так dusk не может достичь ftp непосредственно (потому что он в другой подсети), все эти пакеты будут перенаправлены к нему через «основной шлюз» (defaultrouter) rzi (132.199.15.1), который знает куда перенаправить пакеты.

Dusk знает адрес основного шлюза в его сети (rzi, 132.199.15.1), и он перенаправит любые пакеты адресованные не этой подсети, т.е. перенаправит все IP пакеты в которых третий байт адреса не 15.

Тогда (основной)маршрутизатор отправит пакеты назначенному хосту, также как и в сеть сервера FTP.

В данном примере, все пакеты перенаправляются в сеть 132.199.1.0/24, просто потому что это базовая сеть, самая важная часть сети, которая переносит весь трафик, который передается между разными сетями. Почти все остальные сети, находящиеся рядом с 132.199.15.0/24 подключаются к основной сети аналогичным способом.

Но что, если мы подключим еще одну подсеть к 132.199.15.0/24 кроме 132.199.1.0/24? Сходная ситуация отображена на Рисунок 20.3, «Подключение одной подсети к другой».

Рисунок 20.3. Подключение одной подсети к другой

Подключение одной подсети к другой

Если мы теперь из dusk попытаемся достичь хоста, который расположен в подсети 132.199.16.0/24, то это не должно маршрутизироваться на rzi, а прямиком отправится на route2 (132.199.15.2). Dusk должен знать о необходимости перенаправлять эти пакеты на route2 и отправлять все остальные на rzi.

Когда конфигурируется dusk, Вы говорите ему отправлять все пакеты для подсети 132.199.16.0/24 на route2, и все остальные на rzi. Вместо определения этих значений по умолчанию 132.199.1.0/24, 132.199.2.0/24, и т.д., 0.0.0.0 может использоваться для определения основного маршрутизатора.

Возвращаясь к Рисунок 20.2, «Наша демонстрационная сеть», здесь аналогичная проблема когда dawn хочет отправить сообщение на noon, который подключен к dusk через последовательную линию. Тогда посмотрим на IP адрес, noon кажется что он подключен к сети 132.199.15.0, но это не так. Вместо этого dusk используется как шлюз и dawn должен отправлять эти пакеты на dusk, который будет перенаправлять их на noon. То, каким образом dusk принимает пакеты которые адресованы не ему, а другому хосту (noon) называется «arp проксирование».

То же происходит когда хост из другой подсети хочет отправить пакет на noon. Он отправляет пакет dusk (возхможно смаршрутизированный через rzi).

20.6. Концепция сервиса имен

В предыдущем разделе, когда мы говорили о хостах, мы обращались к ним по IP адресам. Это было необходимо чтобы сформировать представление о различных типах адресов. Когда говорят о хостах, то в основном удобнее использовать «имена», как мы делали, когда говорили о маршрутизации.

Большинству приложений безразлично выдаете вы им IP адрес или имя хоста. Тем не менее, внутри они используют IP адреса и есть несколько способов сопоставить имена хостов с IP адресами, каждый из которых имеет свой собственный метод конфигурации. В этом разделе мы рассмотрим смысл каждого способа, в следующей главе, мы поговорим о конфигурационной части.

Преобразование из имен хостов (и доменных имен) в IP адреса заключается в части программного обеспечения, называемой «resolver (разрешатель)». Это не дополнительный сервис, но некоторые библиотеки, которые обычно привязываются ко всем приложениям, используют сетевые вызовы. Тогда resolver попытается вернуть по предоставленному Вами имени хоста его IP адрес. См. [RFC1034] и [RFC1035] для получения более детальной информации по resolver.

Имена хостов обычно длинной до 256 символов и содержат буквы, цифры и символы («-»); регистр игнорируется.

Для сетей и подсетей возможно (и желательно) группировать хосты в домены и поддомены. Когда получаете Ваш сетевой адрес, Вы обычно также получаете доменное имя от Вашего провайдера. Так подсети, представляют Ваши поддомены. С другой стороны, касаемо IP адресов, (под)домены на прямую не зависят от (под)сетей; например, один домен может содержать хосты из разных подсетей.

Рисунок 20.2, «Наша демонстрационная сеть» отображает следующее: обе подсети 132.199.1.0/24 и 132.199.15.0/24 (и остальные) являются частью поддомена «rz.uni-regensburg.de». Домен университета Резенбурга получен от его IP провайдера «uni-regensburg.de» («.de» для Германии), поддомен «rz» для вычислительного центра, компьютерного центра.

Имена хостов, поддоменные и доменные имена разделяются точками («.»). Также возможно использовать более одного уровня поддоменов, хотя обычно это не практикуется. Примером может быть runetbsd.devnet.apk.od.ua.

Имя хоста, включающее (под)домен также называется полным доменным именем (fully qualified domain name FQDN). Например, IP адрес 132.199.15.99 принадлежит хосту с FQDN dusk.rz.uni-regensburg.de.

Ранее я говорил что IP адрес 127.0.0.1 всегда принадлежит локальному хосту, независимо от «реального» IP адреса хоста. Следовательно, 127.0.0.1 всегда соотносится с именем «localhost».

Три различных способа преобразования имен хостов в IP адреса: /etc/hosts, сервис доменных имен (Domain Name Service - DNS) и сетевой информационный сервис (Network Information Service - NIS).

20.6.1. /etc/hosts

Первый и самый простой способ преобразования имен хостов в IP адреса - использование таблицы, говорящей какие IP адреса принадлежат каким именам хостов. Эта таблица находится в файле /etc/hosts в следующем формате:

IP адрес  имя хоста [псевдоним [...]]

Строки, начинающиеся с символа «#» определяются как комментарии. Остальные строки содержат один IP адрес и соответствующее(ие) имя(имена) хоста(ов).

Невозможно присвоить несколько IP адресов одному хосту, даже если Вы подумали о мрашрутизаторе. Например rzi в действительности имеет два определенных имени, для каждого адреса: rzi и rzia (но, пожалуйста, не спрашивайте меня какое имя принадлежит какому адресу!).

Выдача хосту нескольких псевдонимов может быть удобна, если Вы хотите определить Вашему хосту предоставлять специальные услуги под этим именем, так обычно поступают с FTP серверами. Первое (саме левое) имя обычно реальное (каноническое) имя хоста.

Также выдача псевдонимов удобна для назначения полного имени хоста (включая домен) как канонического имени и использовать только это имя хоста (без домена) как псевдоним.

Важно: Здесь должно быть соотношение localhost к 127.0.0.1 в /etc/hosts!

20.6.2. Сервис доменных имен (DNS)

/etc/hosts присущи проблемы, характерные для больших сетей: когда добавляется даже один хост или у одного хоста меняется адрес, файлы /etc/hosts на всех машинах должны быть изменены! Это не только занимает время, это также, очень возможно приведет к ошибкам и несоответствиям, влекущим за собой проблемы.

Другой способ - оставить одну таблицу (базу данных) имен хостов для сети и делать клиентские запросы к этому «серверу имен». Обновлять нужно будет лишь один сервер имен.

Это основная идея заложенная в сервис доменных имен (DNS).

Обычно, используется один сервер имен на каждый домен (далее DNS) и каждый хост (клиент) в этом домене знает какой это домен и к какому серверу имен в этом домене обращаться.

Когда сервер получает запрос о хосте, который не находится в этом домене, он перенаправляет запрос к любому DNS домена в запросе или узнает какой DNS запрашивать в данном домене. Если DNS, перенаправляющий запрос, не знает как его обработать, он перенаправляет его к DNS одной ступенью выше. Это не бесконечно, существуют несколько «корневых (root)» серверов, которые знают обо всех доменах.

См. Глава 23, Система доменных имен для детального ознакомления с DNS.

20.6.3. Сервис сетевой информации (NIS/YP)

Желтые страницы (Yellow Pages - YP) были предложены Sun Microsystems. Название было изменено на сервис сетевой информации (Network Information Service NIS) потому что YP уже были торговой маркой British telecom. Так, когда я говорю о NIS вы будете знать, что я имею в виду. ;-)

Он имеет довольно немного конфигурационных файлов в Unix системе и часто изменению подлежит лишь один из файлов соединенных хостов. Эти хосты группируются вместе в домене NIS (который не имеет ничего общего с доменами, построенными с использованием DNS!) и обычно содержатся в одном кластере рабочих систем.

Например конфигурационные файлы разделяемые среди этих хостов: /etc/passwd, /etc/group - и последний, но немаловажный - /etc/hosts.

Так, Вы можете «злоупотреблять» NIS для получения уникального преобразования имен в адреса на всех хостах в одном (NIS-)домене.

Единственный недостаток, который не позволяет везде использовать NIS для этого преобразования: в отличие от DNS, NIS не предоставляет возможности разрешать имена хостов, которых нет в таблице. Здесь нет хостов «уровнем выше» которые сервер NIS может запросить и преобразование не состоится! Sun'овский NIS+ содержит решение этой проблемы, но так как NIS+ доступен только на системах Solaris, этого слишком мало сейчас для нас.

Не поймите меня не правильно: NIS это хороший способ управления, например, пользовательской информацией (/etc/passwd, ...) в кластере рабочих систем, это просто не очень удобно для разрешения имен хостов.

20.6.4. Другое

Методы разрешения имен описанные выше обычно используются сегодня для разрешения имен хостов в IP адреса, но они не единственные. В основном, может использоваться любой механизм баз данных, но они не используются в NetBSD. Давайте быстро посмотрим, что Вам может встретиться.

С NIS-подобной иерархией структуры данных, NIS+ не предполагает рассмотрения в этой части. Хотя таблицы могут устанавливаться так, что если запрос не может быть обработан доменным сервером, его может обработать «вышестоящий» домен. Например, Вы можете выбрать домен содержащий список всех хостов (пользователей, групп,...) которые действительны для всей компании, который определяет это для каждого подразделения, и т.д. NIS+, на сегодняшний день, не используется массово, даже Sun вернула назад NIS по умолчанию.

В последнем столетии, был создан стандарт X.500 для объединения как простых баз данных типа /etc/hosts так и комплексных, иерархических систем, которые могут использоваться сегодня, например, в DNS. X.500 не имел реального успеха, в основном из-за того, что пытался сделать слишком много одновременно. Урезанная версия, доступная сегодня как легковесный протокол доступа к каталогам (Lightweight Directory Access Protocol LDAP), который стал популярен в последнее время для управления данными как пользователей, так и хостов и другого в маленьких и средних организациях.

20.7. Интернет протокол следующего поколения - IPv6

20.7.1. Будещее интернет

Согласно экспертам, Интернет, который мы знаем, столкнется с проблемами в ближайшие несколько лет. Это произойдет из-за быстрого роста и ограничений в его устройстве, это будет точка, когда не останется больше свободных адресов, доступных для подключения новых хостов. Тогда будет невозможно добавить новых web серверов, новые пользователи не смогут получить учетную запись у провайдеров, новые машины не смогут получить доступ к web или участвовать в онлайн играх - некоторые люди могут назвать это серьезной проблемой.

Некоторые проблемы можно решить. Один из популярных способов - не получать уникальный всемирный адрес для каждой пользовательской машины, а в основном назначить им «локальные» адреса, и скрыть некоторые машины за официальным, глобальным уникальным адресом. Это достигается так называемой «Трансляцией сетевых адресов» (Network Address Translation - NAT), также известной как IP маскарадинг). Это имеет недостатки, так машины, скрытые за глобальным адресом не могут быть адресованы и, как результат этого, не может быть открыто соединение с теми - кто использует онлайновые игры, одноранговые сети, и т.д. Более подробно недостатки NAT, можно рассмотреть в [RFC3027].

Избавиться от проблем с Интернет адресами можно отказавшись от старого Инетрнет протокола у которого такие ограничения возможности адресации и используя новый протокол, не имеющий таких ограничений. Протокол или, в действительности, набор протоколов, используемый машинами для соединения в сегодняшнем Интернете - блок TCP/IP (Transmission Control Protocol, Internet Protocol, протокол контроля передачи и Интернет протокол), и версия 4, которая используется сейчас, имеет все недостатки, описанные ранее. Переход на другую версию протокола, не имеющую этих недостатков, конечно необходимо чтобы эта версия существовала, сегодня очень актуален. Интернет протокол версии 6 (IPv6) полностью покрывает любые возможные в будущем требования к адресному пространству и также рассчитан на такие вещи как секретность, шифрование и лучшую поддержку мобильных технологий.

Пропустим основные понятия нынешних принципов работы IPv4, этот текст рассчитан как введение в протокол IPv6. Покрыты изменения в формате адреса и разрешении имен. Параллельно почитайте Раздел 25.4, «IPv6 соединения и переход сквозь 6to4», здесь объясняется как использовать IPv6 даже если Ваш провайдер не предлагает испльзование простого и эффективного механизма перехода, называемого 6to4. Цель - выйти в онлайн с IPv6, приведены примеры конфигурации для NetBSD.

20.7.2. Чем хорош IPv6?

Когда говоришь людям о миграции с IPv4 на IPv6, вопрос, который Вы обычно слышите: «зачем?». Это имеет смысл сделать по следующим причинам:

  • Большее адресное пространство

  • Поддержка мобильных устройств

  • Встроенная безопасность

20.7.2.1. Большее адресное пространство

Большее адресное пространство, предлагаемое IPv6, саме очевидное отличие от IPv4. В то время как сегодняшняя архитектура Интернет базируется на 32-битной адресации, новая версия имеет для этого 128 возможных бит. Благодаря увеличенному адресному пространству рабочие окружения, такие как NAT, больше не понадобятся. Это позволит сделать IP соединения полностью безусловными как для сегодняшних, базирующихся на IP, машин так и для, набирающих популярность, мобильных устройств, таких как PDA и мобильные телефоны, которые получат полный IP доступ через GPRS и UMTS.

20.7.2.2. Мобильность

Пока припомним мобильные устройства и IP, еще одно важное условие: нужно иметь в виду что нужен некий специальный протокол, поддерживающий мобильность, и осуществляющий это протокол, называемый - «мобильный IP» (Mobile IP) - одно из требований ко всему стеку IPv6. Таким образом, если Вы перейдете на IPv6, Вы получите поддержку роуминга между разными сетями, каждый раз как Вы покидаете одну сеть и входите в другую. Поддержка роуминга возможна также и с IPv4, но здесь есть несколько условий, которые необходимо выполнить, пока это заработает. С IPv6 Вам это не понадобится - поддержка мобильности одно из требований дизайна IPv6. См. [RFC3024] чтобы более подробно ознакомиться с требованиями, которые необходимо выполнить для осуществления мобильной адресации IP в IPv4.

20.7.2.3. Безопасность

Кроме поддержки мобильности, безопасность также является требованием для преемника сегодняшней версии Интернет протокола. Как результат - стек протокола IPv6 требует включения IPsec. IPsec позволяет идентифицировать, шифровать и сжимать любой IP трафик. В отличие от протоколов уровня приложения, таких как SSL или SSH, весь IP трафик между двумя узлами может быть обработан без установки каких бы то ни было приложений. Что позволяет всем приложениям использовать шифрование и идентификацию и эта политика может быть установлена на межхостовой (или даже межсетевой) основе, но не межприложенческой/сервисной. Для ознакомления с IPsec список документации можно найти в [RFC2411], корневой протокол описан в [RFC2401].

20.7.3. Отличия от IPv4

После беглого ознакомления со всеми важнейшими свойствами IPv6, здесь мы детально рассмотрим основы IPv6. Небольшое понимание работы IPv4 получено и отличия в IPv6 отмечены. Начнем с адресов IPv6, их разделения на различные типы и того как получить широковещательный адрес, после чего обсудим уровень IP в части изменений в разрешении имен и что нового в DNS для IPv6.

20.7.3.1. Адресация

Адрес IPv4 это 32-битное значение, которое обычно записывается в «четырехчисловм с точками» виде, где каждая «четверть» представляет байт со значением от 0 до 255, например:

127.0.0.1

Это, теоретически, позволяет даресовать до 232 или ~4 биллионов хостов, для подключения к интренет сегодня. Из-за группировки не все адреса еще доступны.

Адреса IPv6 используют 128 бит, которые в результате предоставляют 2128 теоретически адресуемых хостов. Это позволит адресовать действительно большое количество машин и конечно покроет все сегодняшние требования, плюс все новомодные КПК и телефоны IP телефонии без каких-либо проблем в ближайшем будущем. При написании адресов IPv6, они обычно представляются группами по 16 бит, записанных как четыре шестнадцатеричных цифры, и группы разделяются двоеточием. Например:

fe80::2a0:d2ff:fea5:e9f5

Здесь виден особый нюанс - серия последовательных нулей может быть один раз заменена двойным двоеточием «::» в адресе IPv6. Таким образом вышеуказанный адрес соответствует fe80:0:00:000:2a0:d2ff:fea5:e9f5 - ведущие нули в группах можно пропускать, а «::» может использоваться в адресе IPv6 лишь один раз.

Чтобы сделать адреса удобнее, они разбиваются на две части, которые содержат биты идентифицирующие сеть, в которой находится машина, и биты идентифицирующие машину в (под)сети. Эти биты известны как биты сети и биты хоста, и в обоих: IPv4 и IPv6, биты сети находятся «слева», самые значимые биты в IP адресе, а биты хоста «справа», наименее значимые биты, как показано на Рисунок 20.4, « Адреса IPv6 также разделены на более значимые биты сети и менее значимые биты хоста ».

Рисунок 20.4. Адреса IPv6 также разделены на более значимые биты сети и менее значимые биты хоста

Адреса IPv6 также разделены на более значимые биты сети и менее значимые биты хоста

В IPv4, граница проводится с помощью сетевой маски, которая используется для маскировки всех битов сети/хоста. Типичные примеры 255.255.0.0 использует 16 бит для адресации сети, и 16 бит для машины, или 255.255.255.0 который захватывает еще 8 бит чтобы иметь возможность адресовать 256 подсетей в сети класса B.

Когда адресация перешла с классовой адресации к CIDR маршрутизации, граница между битами сети и хоста установилась на 8 битной отметке, и как результат маска сети стала выглядеть уродливо и не очень удобно. Как замена, количество битов сети используемых для получения адреса, обозначает границу, например:

10.0.0.0/24

это тоже самое, что маска сети 255.255.255.0 (24 1-бита). Данная используется в IPv6:

2001:638:a01:2::/64

говорит нам, что адрес использует первые (самые левые) 64 бита как адрес сети, и последние (самые правые) 64 бита используются для идентификации машины в сети. Биты сети часто называют (сетевым) «префиксом», и «длинной префикса» здесь будет 64 бита.

Часто схема адресации в IPv4 совпадает с (старыми) сетями класса B и класса C. С сетью класса C (/24), Вы имеете 24 бита назначенных вашему провайдеру, и оставшиеся 8 бит, назначенных вам. Если хотите добавить любую подсеть сюда, Вы остановитесь на «нечетной» сетевой маске, более подходящей для этого. В таком случае проще использовать сеть класса B (/16), в которой лишь 16 назначены провайдеру, что позволяет организовать подсеть, т.е. разделить правые биты на две части. Одну для адресации подсети сайта и одну для адресации хостов в этой подсети. Обычно для этого достаточно выделить один байт (8 бит). Использование сетевой маски 255.255.255.0 (или префикса /24) позволит гибко управлять каждой из больших сетей. Естественно здесь верхний предел составляет до 254 машин на подсеть и 256 подсетей.

Со 128 битами доступными для адресации в IPv6, часто используется похожая схема, только с более широкими полями. Провайдеры обычно назначают /48 сетей, которые оставляют 16 бит для подсетей и 64 бита хоста.

Рисунок 20.5. Адреса IPv6 имеют схожую структуру с адресами класса B

Адреса IPv6 имеют схожую структуру с адресами класса B

Теперь пространство для сетей и подсетей более чем достаточно, использование 64 бит для адресации хостов выглядит излишеством. Маловероятно, что Вам захочется иметь несколько биллионов хостов в одной подсети, так какая идея в этом заключена?

Идея в фиксации пространства шириной в 64 бита для идентификации хоста, которые не назначены им в ручную, в наши дни обычно делается для IPv4. Вместо, IPv6 адресов хоста рекомендуется (не обязательно!) создавать, так называемые, EUI64 адреса. EUI64 адреса - так называется ширина в 64 бита и производится от MAC адресов лежащих в основе сетевого интерфейса. Например для ethernet, 6 байт (48 бит) MAC адрес обычно представляется с шестнадцатеричными битами «fffe» в середине и битом маркера устанавливающего адрес как уникальный (что истинно для Ethernet), например MAC адрес

01:23:45:67:89:ab

в результате EUI64 адрес

03:23:45:ff:fe:67:89:ab

который, в свою очередь, представляет биты хоста для адреса IPv6

::0323:45ff:fe67:89ab

Эти биты хоста теперь могут использоваться для автоматического назначения IPv6 адресов хостам, которые поддерживают автоконфигурацию хостов IPv6, все что необходимо для получения полного адреса IPv6 - это первые биты (сети/подсети), и IPv6 предлагает решение и для их автоматического назначения.

Когда в сети машин говорят об IP, там обычно существует один маршрутизатор действующий как шлюз во внешнюю сеть. В пространстве IPv6, этот маршрутизатор отправит «объявляющую маршрутизатор» информацию, которую клиенты ожидают получить во время операции или запрашивают при загрузке системы. Маршрутизатор предоставит информацию, включая данные адреса маршрутизатора и какой у него префикс адреса. С этой информацией и сгенерированным хостом адресом EUI64, на хосте IPv6 можно посчитать его IP адрес, и теперь его не нужно назначать вручную. Конечно маршрутизатор продолжает нуждаться в небольшой настройке.

Маршрутизатор предоставляет информацию, составляющую чать протокола обнаружения окружения (Neighbor Discovery Protocol - NDP, см. [RFC2461]), являющегося преемником ARP протокола IPv4. В отличие от ARP, NDP производит не только поиск адреса IPv6 для MAC адреса (часть запрос/предоставление окружения), но также предоставляет услуги по маршрутизации и обслуживаемым префиксам, используемым для автоконфигурации хостов IPv6, как описано в предыдущем параграфе.

20.7.3.2. Множественные адреса

В IPv4, хост обычно имеет один IP адрес на сетевой интерфейс или даже на машину если стек IP это позволяет. Только очень редкие приложения как веб сервера позволяют на машинах иметь белее одного IP адреса. В IPv6 это не так. Для каждого интерфейса в нем не один уникальный глобальный IP адрес, а еще два других адреса: локальный адрес связи и локальный адрес места. Локальный адрес связи имеет префикс fe80::/64 и биты хоста полученные из EUI64 адреса интерфейса. Локальный адрес связи используется для контактов хостов и маршрутизаторов только в той же самой сети, адреса не видимы и не достижимы из остальных подсетей. Если необходимо, это способ другого использования глобальных адресов (как назначенных провайдером), или использование локального адреса места. Локальный адрес места назначается сетевым адресом fec0::/10, и подсети и хосты могут быть адресованы просто как назначенная провайдером сеть. Единственное отличие в том, что адреса не видимы машинам извне, так как находятся в другой сети, и их адрес «локального места» находится в другой физической сети (если это все назначено). Как с 10/8 сетью в IPv4, адрес локального места может использоваться, но также не существовать. Для IPv6 обычно имеется назначенные хостам локальный адрес связи и глобальный IP адрес. Локальный адрес места довольно необычен в наши дни и не заменяет глобальный уникальный адрес если требуется глобальное подключение.

20.7.3.3. Множественные (мультивещательные) запросы (multicasting)

В окружении IP, есть три способа обратиться к хосту: одиночный запрос (unicast), широковещательный запрос (broadcast) и множественный запрос (multicast). В основном используются прямые обращения через адрес для одиночного запроса. В IPv4, адрес одиночного запроса это «обычный» IP адрес назначенный конкретному хосту, со всеми установленными битами адреса. Широковещательный адрес используется для адресации всех хостов в той же IP подсети и имеет биты сети, установленные в адрес сети, и все биты хоста, установленные в «1» (который можно просто получить использовав маску подсети и некоторые побитовые операции). Адреса множественных запросов используются для достижения количества хостов в той же группе множественного запроса, в которой машины могут быть разбросаны по всей Интернет. Машины должны явно включаться в мультивещательные группы и в этом случае существует специальные адреса IPv4, используемые для множественных запросов, расположенные в подсести 224/8. Мультивещание не очень широко используется в IPv4, лишь некоторые приложения типа MBone широковещательных аудио и видео утилит их используют.

В IPv6, адрес одиночного запроса используется тот же, что и в IPv4, никаких сюрпризов - все биты сети и хоста предназначаются для идентификации целевых сети и машины. Широковещательные запросы в IPv6 более не поддерживаются тем же образом как в IPv4, здесь входят в игру множественные запросы. Адреса в сети ff::/8 зарезервированы для мультивещательных приложений, и здесь существует два специальных мультивещательных адреса, которые заменяют широковещательные адреса из IPv4. Один - это мультивещательный адрес «все маршрутизаторы», другой - для «всех хостов». Адреса, специфичные для подсети, т.е. маршрутизатор подключенный к двум независимым сетям может адресовать все хосты/маршрутизаторы в любой из подсетей к которым подключен. Здесь адреса:

  • ff0X::1 для всех хостов

  • ff0X::2 для всех маршрутизаторов,

Где «X» здесь это ID связи области, идентифицирующий сеть. Обычно он начинается с «1» для области «локального узла», «2» для первого соединения и т.д. Имейте в виду, что это особенно подходит для двух сетевых интерфейсов подключенных в одно соединение, таким образом получаем двойную ширину полосы пропускания:

Рисунок 20.6. Несколько интерфейсов соединенных в одну связь с одним ID области связи

Несколько интерфейсов соединенных в одну связь с одним ID области связи

Одно из использований мультивещательного запроса ко «всем хостам» запрос в окружении кода NDP, где каждая машина, желающая общаться с другой машиной отправляет запрос к группе «все хосты», а машина в запросе ожидает реакции.

20.7.3.4. Разрешение имен в IPv6

После кучи слов об адресации в IPv6, все еще остается надежда, что здесь существует способ абстрагироваться от всех этих длинных и ужасных адресов IPv6 с какими-нибудь хорошенькими именами хостов, как было в IPv4, и конечно он есть.

Разрешение имен в IP адреса в IPv4 обычно заключается в одном из трех способов: использовать простую таблицу в /etc/hosts, использовать сетевой информационный сервис (Network Information Service - NIS, раньше YP) или через систему доменных имен (Domain Name System - DNS).

Как здесь написано, NIS/NIS+ через IPv6 сейчас возможен толлько в Solaris 8, для содержания базы данных и передачи, используя расширение RPC.

Имея простую адрес<->имя карту как /etc/hosts Что поддерживается всеми стеками IPv6. С реализацией KAME используемой в NetBSD, /etc/hosts содержит адреса IPv6 также как адреса IPv4. Простой пример «localhost» входит в установку NetBSD по умолчанию:

127.0.0.1    localhost
::1      localhost

Для DNS, здесь не появилось фундаментально новых концепций. Имена IPv6 разрешаются с помощью записи AAAA - как подразумевается в имени - указывает на сущность соответствующую четырехкратной записи A. Запись AAAA содержит имя хоста в левой половине, по аналогии с A, а в правой его IPv6 адрес, например:

noon   IN  AAAA 3ffe:400:430:2:240:95ff:fe40:4385

Для обратного разрешения, IPv4 использует зону in-addr.arpa, и далее записаны байты (в десятеричном виде) в обратном порядке, т.е. более значимые байты более справа. Для IPv6 все похоже, только его шестнадцатеричные цифры представляют 4 используемые бита вместо десятеричных цифр, и записи источников существуют под различные домены, ip6.int.

Так, чтобы обратно разрешить вышеописанный хост, Вам необходимо вставить в Ваш /etc/named.conf что-то типа:

zone "0.3.4.0.0.0.4.0.e.f.f.3.IP6.INT" {
  type master;
  file "db.reverse";
};

и в файл зоны db.reverse Вы вставите (помимо обычных записей типа SOA и NS):

5.8.3.4.0.4.e.f.f.f.5.9.0.4.2.0.2.0.0.0 IN PTR noon.ipv6.example.com.

Адреса возвращенные здесь, записаны одна шестнадцатеричная цифра за другой, начиная с менее значимой (самой правой), разделенные точками, как обычно делается в файлах зон.

Запомните, если настраивать DNS для IPv6 - будьте осторожны с версией используемого программного обеспечения DNS. BIND 8.x будет понимать записи AAAA, но он не будет разрешать имена через IPv6. Для этого вам необходим BIND 9.x. Зато, BIND 9.x поддерживает несколько записей источников, что еще обсуждается, но официально не введено. Самая заметная здесь запись - A6, которая позволяет легко изменять префикс провайдера.

Подводя итог, этот раздел рассказал о технических отличиях между IPv4 и IPv6 для адресации и разрешения имен. Некоторые детали, такие как опции IP заголовков, QoS и потоки здесь умышленно опущены, что не делает этот документ более комплексным, чем необходимо.

Обновлено: 16.03.2015