Документ взят из кэша поисковой машины. Адрес оригинального документа : http://uneex.lorien.cs.msu.su/PspoClasses/080703
Дата изменения: Unknown
Дата индексирования: Sat Apr 9 23:30:44 2016
Кодировка: UTF-8
PspoClasses/080703 - UNИX

Сетевые сервисы и настройка сети

Модули

Готов?

Название модуля

Чтение (ак. ч.)

Подготовка (астр. ч.)

Написание (дни)

уровень

Maintainer

Started

Should be done

End date

{OK} 90%

Преобразование имен и IP-адресов: теория

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov, VsevolodKrishchenko

{OK} 90%

Преобразование имен и IP-адресов: практика

1

1

1

1

PavelSutyrin, DmitryChistikov, VsevolodKrishchenko

{OK} 90%

Сетевые сервисы

1

1

1

1

MaximByshevskiKonopko, VladimirLysikov, VsevolodKrishchenko

{OK} 90%

Настройка сетевых интерфейсов

1

1

1

1

ConstantinYershow, ОльгаТочилкина, VsevolodKrishchenko

4

4

4

4

(./)

Готово: 0 (0%)

0

0

{X}

Не готово: 4 (100%)

4

4

Необходимые знания

Материалы

Полиси

  • На данный момент для координирования работ используется макрос ExtractModules (тот же, что и в PspoModules). Возможно, впоследствии будет написано нечто более специфичное для данных работ.

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

    0%

    Сырой конспект

    20%

    Дешифрованный конспект

    50%

    Конспект, переведенный на русский язык

    70%

    Вычитанный конспект

    90%

    Иллюстрирование, расстановка ссылок, перенос в модули

    100%

    Результат работ над частью лекций проверен FrBrGeorge

  • Как только Вы считаете, что закончили свою часть работы, просьба установить соответствующее количество процентов
  • Промежуточное количество процентов в промежуточных сохранениях приветствуется

Пожелания к ролям

  • Расшифровка ? по возможности полное восстановление структуры и смысла лекции по конспектам и (если есть необходимость) по аудиозаписям. в эту задачу входит расстановка имеющихся иллюстраций (typescript, konsole.log, снимки экрана)

  • Перевод на русский ? выравнивание стилистки и корректировка владения русским языком. Просьба не очень самовыражаться (чтобы не создавать стилистического разнобоя)

  • Вычитка ? проверка получившегося текста на (1) соответствие действительности (2) доходчивость (в том числе на предмет нехватки иллюстраций)

CategoryPolicy

Лекции

Преобразование имен и IP-адресов: теория

Назначение службы доменных имен DNS

Из всех многочисленных сетевых служб, работающих на прикладном уровне и обрабатывающие сетевые запросы клиентов, существует одна без которой и всем остальным работать очень тяжело, если вообще возможно. Эта служба называется DNS (Domain Name Service --- служба доменных имен).

Рассмотрим, чем назначение службы имен. В прошлый раз мы говорили о том, на каких условиях, как и кем раздаются ip-адреса (ICAAN, региональные провайдеры, локальные, и т.д.). Если посмотреть на технологию маршрутизации, то можно увидеть, что структура сети с точки зрения IP-адресов строго подчиняется топологии: если несколько компьютеров объединены в единую локальную сеть, то у них будет одинаковый адрес сети, а если компьютеры находятся в разных локальных сетях,то у них будут различающиеся IP-адреса в части адреса сети. Если какая-нибудь организация сначала получила десять адресов из диапазона, а затем ей оказалось этого мало и она получила еще сто, то, тем не менее, эти два диапазона IP-адресов вполне могут быть совершенно разными, поскольку они отражают не тот факт, какая конкретная организация ими владеет, а тот факт, какая "часть" интернета ими занята, т.е. топологию.

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

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

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

История возникновения DNS

Важное добавление: соответствие имени и ip-адреса. Во времена, когда адресов в интернете было где-то около 15, существовал файл под названием /etc/hosts, который содержал базу данных по всем именам этих адресов. Его формат очень простой --- IP-адрес и имена, ему соответствующие (файл это используется и сейчас, но обычно хранит только имена самого компьютера).

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

  • во-первых, оказалось, что администраторы сетей почему-то хотят сами именовать свои компьютеры;
  • во-вторых --- администраторы всех компьютеров на свете почему-то не хотят скачивать постоянно /etc/hosts из центрального хранилища, предпочитая писать /etc/hosts собственноручно, и он, естественно, не совпадает у всех компьютеров в интернете.

В какой-то момент стало очевидным то, что файлом /etc/hosts дело ограничиться не может и что надо создать некую систему, которая сама преобразовывала строковое имя в числовой адрес и обратно. Но если общего файла не существует, то надо использовать некую программу с этими функциями. А тогда появилась идея: поскольку администраторы сами пишут /etc/hosts, то пусть они и дальше сами раздают имена компьютерам в своей области владения, т.е.: ты администрируешь какие-то компьютеры --- значит, раздать им имена --- тоже твоя обязанность. Таким образом, решается задача --- преобразования доменных имен в адреса и обратно.

Решение задачи состоит в том что у каждого системного администратора есть свой файл преобразования хостов и IP-адресов. Точнее не файл, а специальная таблица (ее вид зависит от используемого DNS-сервера), распределенная по вышеизложенной схеме.

Организация системы доменных имен

Мировая система доменных имен организована следующим образом: существует несколько корневых серверов, которые ни в коем случае не знают все имена всех компьютеров в сети (и, более того, не обязаны этого знать). Вместо этого они содержат информацию о так называемых зонах DNS, состоящих из одного имени. Например, существуют зоны ru, com, info, de и так далее. Во-первых, они знают о том, какие имена первого уровня существуют в принципе, поскольку их относительно немного. Недавно их было совсем мало --- в старых справочниках по интернету указывались только com, net, org, edu, gov и еще несколько зон, связанных с государствами, по двух-буквенным кодам. В какой-то момент было принято решение сильно расширить диапазон, а недавно приняли решение, что для записи имен зон будет использоваться кодировка юникод, что позволит создать имена зон на национальных алфавитах.

Итак, корневые DNS-сервера знают о всех существующих зонах, то есть о том, какие вообще бывают окончания у доменных имен. Помимо этого, они также знают адреса серверов, обладающих информацией о содержимом этих зон --- т.е. о компьютерах, имена которых кончаются на окончание зоны. Указанные сервера называются серверами имен или NS-серверами (nameservers). Корневые сервера выдают ответ на вопрос довольно простого свойства --- во-первых, существует ли в принципе такое имя (проверяя окончание), и, если оно существует, то где находится сервер (точнее, серверы) имен, знающие про имена с такими окончаниями.

Если посмотреть в словаре слово домен, мы узнаем, что оно появилось очень давно, и означает оно область владений феодального вассала. Феодальная структура была устроена пирамидально и самое главное - по принципу (соблюденному и в DNS) "вассал моего вассала --- не мой вассал". Т.е. сервер отвечает за своих непосредственных подчиненных, и не отвечает за прямых подчиненных, которые не являются непосредственными.

Рассмотрим доменное имя cs.msu.ru. Сервер, который отвечает за зону ru, отвечает только за сервера имен тех хостов, которые имеют двусложные имена, оканчивающиеся на "ru" (www.ru, msu.ru и т.д). А если в имени больше составляющих, то сервер имен зоны ".ru" не обязан знать ip-адрес сервера имен хоста, хотя он может и хранить его в силу разных причин. Но он обязан знать адрес сервера имен хоста msu.ru. Дальше запрашивается сервер имен msu.ru, а он уже обязан ответить, кто такой cmc.msu.ru либо сообщить его сервер имен, и так далее. В итоге мы получим в ответ либо ip-адрес, либо сообщение о том, что такого домена нету.

По сути, мы описали иерархическую распределенную базу данных. Если мы почитаем документацию к bind (сервер имен, часто использующийся в Linux),то увидим, что это не просто база данных, ведь там можно хранить что угодно --- любые текстовые поля, любые поля, соответствующие IP-адресам. Существует также RFC, описывающий, как хранить внутри текстовых полей данные разного типа.

Производительность и надежность системы доменных имен

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

  1. Каждая таблица с записью соответствия IP-адреса доменному имени содержит в себе информацию. о том, в течение какого времени эта таблица, во-первых, действительна, а в-вторых, может не меняться, то есть ее время жизни и задержка на изменение. Таким образом, если мы один раз выяснили, что имени cs.msu.ru соответствует некий адрес, то в течение времени задержки на изменение --- т.е. времени, в течении которого эта запись гарантированно не будет меняться --- мы можем эту запись поместить в кеш доменных имен и не обращаться за ним к серверам имен в дальнейшем. Каждая такая таблица имеет свое время жизни (около недели), и время, в течение которого содержимое считается актуальным. Это сильно снижает нагрузку, поскольку в первый раз происходит взаимодействие по всей иерархии DNS, а в следующие разы взаимодействия не происходит, пока время задержки на изменение еще не истекло. И даже когда время актуальности истечет, то возможно, что не будет происходить все преобразование имени, а произойдет всего лишь запрос вышестоящему серверу имен, не обновились ли данные у него. И если он отвечает "нет", то записью можно пользоваться дальше.
  2. Чем больше в распределенной системе узлов, тем ниже совокупная надежность самой системы. Для борьбы с этим тоже годится использование кеширования. Сильно повышает надежность требование, чтобы NS-серверов было более одного. И желательно, чтобы у них были существенно разные IP-адреса, например в разных сетях класса B. При этом для удобства администратора система устраивается так, что пользователю было абсолютно все равно, какой из NS-серверов ему ответил. Все NS-сервера равноправны. Вопрос: а как несчастный администратор будет редактировать файлы сразу на двух машинах, которые лежат в абсолютно разных местах интернета? Ответ: на самом деле среди этих машин есть главная, но об этом знает только администратор, и обычно он редактирует файл только на ней, а остальные просто скачивают с нее.
  3. Некоторое ограничение свободы обычного пользователя. Дело вот в чем: если вы обращаетесь к какому-либо NS-серверу с запросом относительно преобразования IP-адреса, никакого отношения к домену, за который отвечает этот сервер, не имеющего, то он имеет право ответить "не знаю". Такой запрос (на который можно получить ответ "не знаю") называется нерекурсивным. Все DNS-сервера в сети отвечают на нерекурсивные запросы. Другой вариант: когда вы обращаетесь к серверу с т.н. рекурсивным запросом, тогда NS-сервер самостоятельно обращается к корневому и так далее. В итоге либо преобразование будет произведено, либо вам ответят, что нет такого имени, либо вам ответят, что время запроса превысило лимит. И в отличие от нерекурсивного запроса, рекурсивные запросы обычно разрешены только для "своих" машин, т.е. решение, удовлетворяет ли сервер рекурсивные запросы или нет, принимает системный администратор этого сервера. В результате получается так, что далеко не все компьютеры могут посылать далеко не всем NS-серверам рекурсивные запросы. Как правило существует два уровня: существует некая группа адресов, которым доверяют и они могут посылать рекурсивные запросы, а остальным нельзя.

Таким образом, конечные пользователи обычно работают с кеширующим сервером имен, расположенном в локальном сети, который, в свою очередь, обычно передает рекурсивные запросы к кеширующему серверу имен провайдера.

../dns01.png

Схема преобразования DNS-имени cs.msu.ru в его ip-адрес с учетом всего сказанного выше представлена на рисунке. Предполагается, что требуемый адрес не найден ни в одном кеше, и поэтому система DNS выполняет максимально возможное число запросов. На практике каждый DNS-ответ возвращает адреса нескольких серверов имен (в данном случае --- до семи), но для простоты на рисунке указан только один.

Преобразование имен и IP-адресов: практика

Файл /etc/resolfv.conf

Обратимся теперь собственно к ПСПО. Посмотрим на файл /etc/resolv.conf: 

# cat /etc/resolv.conf
# Generated by dhcpcd for interface eth0
search prov.ru
nameserver 194.190.241.162
nameserver 194.226.215.65

Как видно, в нашем случае в нем всего четыре строки, первая из которых - комментарий. В строках вида nameserver ip-адрес указаны адреса DNS-серверов. Строка search имя_домена означает, что преобразование доменного имени в IP-адрес будет происходить следующим образом: если указано не полное имя домена, а только имя компьютера, то имя_домена будет приписано к имени компьютера через точку, и только затем имя будет преобразовываться в IP-адрес.

Библиотека libresolv

Преобразование имени в адрес и обратно используется в большом количестве различных программ. Программы-браузеры, утилиты типа ping и telnet -- неужели все они при своей работе читают этот файл? На самом деле эту работу за них проделывает специальная библиотека --- libresolv, или попросту resolver на общепринятом сленге. Отметим, что одно из достоинств операционной системы GNU/Linux как раз и состоит в том, что большинство используемых программ --- свободные, а потому, реализовав однажды применяемый алгоритм и оформив его в виде библиотеки под свободной лицензией, мы позволяем разработчикам других программ пользоваться нашей библиотекой и не задумываться над механизмом выполнения подобных операций.

С использованием libresolv связан следующая тонкий момент. В операционной системе эта библиотека работает на довольно низком уровне, причем часть кода должна выполняться практически с правами суперпользователя. Понятно, что это может представлять серьезную угрозу в случае некорректной работы этой библиотеки, в случае обнаружения в ней ошибки. Поэтому в ПСПО ALT Linux для библиотеки преобразования имен создано специальное изолированное окружение. Для обновления необходимых для работы библиотеки данных (конфигурационных файлов) есть специальная команда: 

# update_chrooted conf

Эта команда записывает множество различных конфигурационных файлов из /etc в различные нуждающиеся в них изолированные окружения. В ПСПО используется сразу несколько изолированных окружений для различных сервисов, которые могут быть потенциально опасными. На самом деле это означает, что занимающиеся вопросами безопасности в ALT Linux люди не уверены, что в коде соответствующих программ нет ошибок, а потому считают нужным эти программы изолировать. Запущенная в изолированном окружении программа может пользоваться только той частью файловой системы, в которой она запущена - это некоторый специально выделенный каталог и все дерево его подкаталогов. Именно туда и следует копировать конфигурационные файлы. В нашем случае изолированное окружение для библиотеки преобразования имен находится в /var/resolv: 

# ls /var/resolv/
etc  lib  var

Конфигурационные файлы в изолированном окружении (как и в основной файловой системе) лежат в каталоге etc: 

# ls /var/resolv/etc/
host.conf  hosts  localtime  nsswitch.conf  resolv.conf  services

Среди них, как и ожидалось, есть и hosts, и resolv.conf. Присутствует здесь и файл services. Сама библиотека и используемые ее библиотеки лежат в /var/resolv/lib. 

# ls /var/resolv/lib/
libnsl.so.1        libnss_hesiod.so.2         libnss_nis.so.2
libnss_dns.so.2    libnss_mdns4.so.2          libnss_nisplus.so.2
libnss_files.so.2  libnss_mdns4_minimal.so.2  libresolv.so.2

Как видим, здесь есть libnss и libnsl, нужные для работы resolver'a, а также сам libresolv. Еще раз отметим, что при изменении хотя бы одного из конфигурационных файлов в /etc (кроме файлов в каталоге /etc/net, о которых будет рассказано далее) необходимо выполнить команду update_chrooted conf для обновления конфигурации ограниченных окружений.

Прямое и обратное преобразование

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

Заметим, что обратное преобразование производят и вспомогательные утилиты, например утилита traceroute для обнаружения последовательности маршрутизаторов до некоторого адреса: 

$ traceroute www.ru 
...
7  msk-bgw1-ae0-350.rt-comm.ru (217.106.2.157)  51.970 ms  53.449 ms  53.882 ms
8  msk-dsr8-ge8-19.rt-comm.ru (217.106.1.134)  43.304 ms  44.741 ms *
9  iki-c1-vl10.demos.net (194.87.0.111)  49.192 ms * *
10  www.ru (194.87.0.50)  14.069 ms  14.148 ms  14.271 ms

Здесь доменное имя www.ru было преобразовано в IP-адрес 194.87.0.50, на который и отправлялись пакеты. IP-адреса обнаруженных маршрутизаторов преобразовывались в их DNS-имена. Заметим, что явного указания выполнять это преобразование мы не давали. Чтобы утилита traceroute таких преобразований не выполняла, следует вызывать ее с ключом -n.

Для явного преобразования IP-адресов в доменные имена и обратно можно использовать несколько специальных утилит. Не все из них одинаково удобны для пользователя (одна --- nslookup --- вообще считается устаревшей). Посмотрим на простейшую из них - hostinfo: 

$ hostinfo ya.ru
address: 213.180.204.8
hostname: ya.ru
aliases:

Она выводит простейшую информацию о запрошенном доменном имени. Попадают в ее вывод также псевдонимы адреса: если в сети у одной и той же машины есть несколько имен, то соответствие всех этих имен данному IP-адресу также можно выяснить с помощью DNS.

Более сложная программа для преобразования имен в адреса и обратно называется host: 

$ host -a ya.ru
Trying "ya.ru"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60336
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru.                         IN      ANY

;; ANSWER SECTION:
ya.ru.                  7030    IN      NS      ns5.yandex.ru.
ya.ru.                  7030    IN      NS      ns1.yandex.ru.
ya.ru.                  7030    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7030    IN      NS      ns5.yandex.ru.
ya.ru.                  7030    IN      NS      ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru.          345430  IN      A       213.180.204.1
ns1.yandex.ru.          345430  IN      A       213.180.193.1

Received 142 bytes from 194.190.241.162#53 in 66 ms

Примерно так же работает и программа dig из пакета bind-utils: 

$ dig ya.ru

; <<>> DiG 9.3.5 <<>> ya.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50939
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  7012    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7012    IN      NS      ns5.yandex.ru.
ya.ru.                  7012    IN      NS      ns1.yandex.ru.

;; ADDITIONAL SECTION:
ns5.yandex.ru.          345412  IN      A       213.180.204.1
ns1.yandex.ru.          345412  IN      A       213.180.193.1

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:54:40 2008
;; MSG SIZE  rcvd: 114

Начинающиеся с точки с запятой строки --- это комментарии. Формат выдачи соответствует формату хранения данных в распределенной базе данных DNS. Видно, что имени ya.ru соответствует IP-адрес 213.180.204.8, а за зону ya.ru отвечают два доменных сервера: ns1.yandex.ru и ns5.yandex.ru. На всякий случай dig вывела также IP-адреса этих серверов (заметим, что это действительно адреса из двух различных сетей класса B), а также различную статистику в комментариях: сколько времени заняло ожидание ответа, кто на самом деле ответил на запрос и пр. Заметим, что наш запрос был обслужен локальным сервером, указанным в /etc/resolv.conf. Добавим теперь в командную строку новый параметр: 

$ dig ya.ru @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> ya.ru @ns5.yandex.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54389
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  7200    IN      A       213.180.204.8

;; AUTHORITY SECTION:
ya.ru.                  7200    IN      NS      ns1.yandex.ru.
ya.ru.                  7200    IN      NS      ns5.yandex.ru.

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul  3 17:56:50 2008
;; MSG SIZE  rcvd: 82

Результаты не поменялись, однако на запрос ответил сам сервер ns5.yandex.ru. Это как раз та самая ситуация, когда мы обратились к серверу, непосредственно отвечающему за нужную нам зону. Попробуем обратиться к этому же серверу с другим запросом: 

$ dig cdrom.com @ns5.yandex.ru

; <<>> DiG 9.3.5 <<>> cdrom.com @ns5.yandex.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42056
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com.                     IN      A

;; Query time: 6 msec
;; SERVER: 213.180.204.1#53(213.180.204.1)
;; WHEN: Thu Jul  3 17:57:19 2008
;; MSG SIZE  rcvd: 27

Обратим внимание, что сервер отказался обслуживать рекурсивный (по умолчанию) запрос. По сути дела, он ответил: "Не знаю". Понятно, что у держателей ya.ru нет никаких причин отвечать на рекурсивные DNS-запросы от посторонних (для них) узлов.

Что же будет, если мы обратимся к местному серверу? 

$ dig cdrom.com

; <<>> DiG 9.3.5 <<>> cdrom.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58456
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;cdrom.com.                     IN      A

;; AUTHORITY SECTION:
cdrom.com.              300     IN      SOA     cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; Query time: 300 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:57:55 2008
;; MSG SIZE  rcvd: 90

Итак, домен cdrom.com существует (об этом говорит запись типа SOA - state of authority), а IP-адреса у него нет, - весьма полезная информация. Запросим теперь записи произвольных типов (-t any): 

$ dig cdrom.com -t any

; <<>> DiG 9.3.5 <<>> cdrom.com -t any
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24171
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;cdrom.com.                     IN      ANY

;; ANSWER SECTION:
cdrom.com.              3600    IN      MX      10 pike.cdrom.com.
cdrom.com.              300     IN      TXT     "v=spf1 include:spf-dc1.digitalriver.com include:spf-dc2.digitalriver.com include:spf-dc7.digitalriver.com include:spf-dc5.digitalriver.com include:spf-dc6.digitalriver.com ~all"
cdrom.com.              0       IN      SOA     cdrom.com. root.digitalriver.com. 2007100313 600 300 604800 300

;; AUTHORITY SECTION:
cdrom.com.              172757  IN      NS      3dns1.digitalriver.com.
cdrom.com.              172757  IN      NS      3dns3.digitalriver.com.
cdrom.com.              172757  IN      NS      dc7dns01.digitalriver.com.

;; ADDITIONAL SECTION:
pike.cdrom.com.         3600    IN      A       204.216.28.222
3dns1.digitalriver.com. 172757  IN      A       208.217.74.35
3dns3.digitalriver.com. 172757  IN      A       66.192.77.35
dc7dns01.digitalriver.com. 172757 IN    A       81.21.144.40

;; Query time: 202 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 17:58:37 2008
;; MSG SIZE  rcvd: 427

Прокомментируем полученный вывод. В базе данных DNS могут лежать записи разного вида. Запись типа A (адрес) - эта одна из многих возможностей. Существуют (и это мы уже видели) также записи типа NS --- адреса серверов имен (NameServers). У домена cdrom.com есть машина, которая пересылает почту (запись типа MX --- Mail eXchanger). Приоритет у этого почтового сервера 10 (дело в том, что их может быть несколько), а называется он pike.cdrom.com. Есть у cdrom.com и запись типа TXT, в которой хранится ассоциированный с доменом текст (в данном случае это SPF --- специальная информация, часто используемая для борьбы со спамом). Есть запись типа SOA (которую мы уже видели), содержащая служебную информацию ("серийный номер" 2007100313, который обычно составляется на основе текущих даты и времени; время жизни и пр.). Дальше в выводе dig есть дополнительная информация, о которой сейчас говорить не будем.

Выполним теперь с помощью dig обратное преобразование (-x) для IP-адреса 213.180.204.8, который мы получили при запросе о ya.ru: 

$ dig -x 213.180.204.8

; <<>> DiG 9.3.5 <<>> -x 213.180.204.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2747
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;8.204.180.213.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
8.204.180.213.in-addr.arpa. 13746 IN    PTR     ya.ru.

;; AUTHORITY SECTION:
204.180.213.in-addr.arpa. 8820  IN      NS      ns1.yandex.net.
204.180.213.in-addr.arpa. 8820  IN      NS      ns2.yandex.net.

;; ADDITIONAL SECTION:
ns1.yandex.net.         64148   IN      A       213.180.193.1
ns2.yandex.net.         64148   IN      A       213.180.199.34

;; Query time: 6 msec
;; SERVER: 194.190.241.162#53(194.190.241.162)
;; WHEN: Thu Jul  3 18:02:26 2008
;; MSG SIZE  rcvd: 141

Как видно, соответствия IP-адресов именам лежат в отдельной базе. Тип соответствующих записей называется PTR (pointer --- указатель). Интересно отметить, в какой форме представляются в этой базе IP-адреса. Запрашивается по сути дела домен следующего вида: IP-адрес, записанный "наоборот", к которому через точку приписана строка in-addr.arpa. Почему так? Дело тут в алгоритме, по которому раздаются диапазоны адресов. Пусть мы получили, к примеру, адреса 213.180.0.0/16. Это означает, что ответственный за этот домен сервер имен должен отвечать на обратные запросы для всех соответствующих компьютеров. Но как это сделать, ведь база DNS устроена по другому принципу и, например, за имена cs.msu.ru и cmc.msu.ru отвечает один и тот же сервер? При создании сервера, ответственного, например, за поддиапазон 213.180.204.0/24, разумно записывать числа из IP-адресов в обратном порядке. Соответствующая зона будет выглядеть как 204.180.213.in-addr.arpa, логика же работы DNS не изменится! Действительно, принципиальной разницы между доменами msu.ru и 204.180.213.in-addr.arpa с этой точки зрения нет.

Служба whois

Вернемся к поставленной ранее задаче. Как узнать, какой организации принадлежит тот или иной IP-адрес или диапазон? Для этого есть служба whois. Действительно, система DNS не предназначена для выяснения административных отношений. Ее удобно использовать для построения распознаваемой топологии сети, связанной с этими отношениями. Система whois же привязана к регистрации доменных имен. Данная процедура проводится либо системным администратором, который может выделить для тех или иных целей поддомен, либо специальной организацией, торгующей доменными именами, скажем, второго уровня (к примеру, в зоне .ru). Во втором случае при регистрации домена он заносится в соответствующую базу данных. Выполним запрос к этой базе: 

$ whois ya.ru
% By submitting a query to RIPN's Whois Service
% you agree to abide by the following terms of use:
% http://www.ripn.net/about/servpol.html#3.2 (in Russian)
% http://www.ripn.net/about/en/servpol.html#3.2 (in English).

domain:     YA.RU
type:       CORPORATE
nserver:    ns5.yandex.ru.
nserver:    ns1.yandex.ru.
state:      REGISTERED, DELEGATED
org:        YANDEX, LLC.
phone:      +7 495 7397000
fax-no:     +7 495 7397070
e-mail:     noc@yandex.net
registrar:  RUCENTER-REG-RIPN
created:    1999.07.12
paid-till:  2008.08.01
source:     TC-RIPN
Last updated on 2008.07.03 18:04:47 MSK/MSD

Итак, домен ya.ru зарегистрирован, права на управление им переданы администратору. Указана организация, телефон, факс, почтовый адрес. Поле "Registrar" - это регистратор (указана дата регистрации и дата, до которой использование этого доменного имени считается оплаченным). Обратим внимание на службу регистрации - их несколько, поэтому совершенно необязательно whois будет работать именно так. Вообще, алгоритм выяснения whois'а довольно хитр. К примеру, запрашивая информацию по доменам вида *.us, можно иногда получить специальный идентификационный номер с предложением позвонить по особому номеру телефона ("заплатите нам столько-то и мы вам все расскажем").

Серверов службы whois на свете довольно много, а процедура их регистрации весьма причудлива. Как следствие, результаты whois-запросов могут быть весьма непредсказуемы. К примеру, ответ на запрос whois google.com может содержать более двухсот строк, причем полезными, по-видимому, можно считать менее половины из них.

Можно производить поиск информации whois и по IP-адресам: 

$ whois 62.117.85.102
% This is the RIPE Whois query server #3.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html

% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '62.117.85.0 - 62.117.85.255'

inetnum:      62.117.85.0 - 62.117.85.255
netname:      COMCOR-PROGTEH
descr:        Network for ZAO NPO "Progteh"
country:      RU
admin-c:      CNA3-RIPE
tech-c:       CNA3-RIPE
status:       ASSIGNED PA
mnt-by:       AS8732-MNT
source:       RIPE # Filtered

person:         Chicherov Nikolay Andreevich
e-mail:         sysadmin@progtech.ru
address:        Russia, Mosk. obl., g.Zhukovskiy, Amet-Han Sultana
phone:          +7 495 824831031
mnt-by:         AS8732-MNT
nic-hdl:        CNA3-RIPE
source:         RIPE # Filtered

% Information related to '62.117.64.0/18AS8732'

route:        62.117.64.0/18
descr:        comcor.ru
origin:       AS8732
mnt-by:       AS8732-MNT
source:       RIPE # Filtered

% Information related to '62.117.85.0/24AS35475'

route:          62.117.85.0/24
descr:          Progtech ISP
origin:         AS35475
mnt-by:         AS8732-MNT
source:         RIPE # Filtered

Как видно, информация взята из RIPE --- это регистратор, который раздает адреса в России. В основном ответе указано, что диапазон 62.117.85.0/24 выдан ЗАО "НПО Прогтех", есть соответствующий адрес сайта, а также адрес: Московская область, город Жуковский и т. д. К какой же автономной системе принадлежит этот диапазон? Это comcor, чей диапазон 62.117.64.0/18. Они этот диапазон "нарезали" и отдали поддиапазон 62.117.85.0/24 "вниз". Вообще, это вполне разумная информация, из которой ясно, кто реальный владелец данного IP-адреса и кто ему этот IP-адрес выдал.

Сетевые сервисы

На прикладном уровне стека TCP/IP существует множество разнообразных протоколов, например протокол обмена почтой SMTP или протокол обмена файлами FTP. Общая схема работы сетевой программы-сервера, реализующего один из этих протоколов, следующая: она принимает данные, передаваемые программой-клиентом на определенный порт TCP или UDP, обрабатывает их, и отправляет ответ клиенту. Запросы и ответы протокола прикладного уровня часто являются командами в виде обычного текста.

Операционная система предоставляет специальный инструмент для создания серверов такого типа. Этот инструмент --- механизм сокетов. Сокеты предоставляют интерфейс синхронного и асинхронного обмена данными. В случае синхронного, или блокирующего, обмена в случае отсутствия данных для чтения при чтении из сокета программа будет ждать, пока эти данные появятся; в случае асинхронного, или неблокирующего, взаимодействия, программа продолжит работу. Сокеты в UNIX-системах могут иметь различное физическое представление. Кроме сетевых сокетов, которые могут передавать данные с одного компьютера на другой, существуют и локальные сокеты Unix, находящиеся в файловой системе. Интерфейс работы с обоими видами сокетов одинаков, за исключением создания сокета. Сетевые сокеты являются низкоуровневым программным интерфейсом к транспортному уровню сетевого взаимодействия в лице протокола TCP или UDP.

Работающие на машине с ПСПО программы, передающие данные по сети, используют для доступа к сети именно механизм сокетов. Однако, существует способ создания простых сетевых сервисов, не требующий изучения программирования сокетов. Он напоминает объединение команд в конвейер, с тем отличием, что ввод-вывод должен производиться асинхронно. Стандартные же программы окружения Unix являются "фильтрами", которые преобразовывают ввод и выдают результат на вывод синхронно. Для решения это проблемы существует сетевой супер-сервер xinetd, а ранее эту же задачу решал сервер inetd. Сам он не реализует сетевого сервиса, но дает возможность сделать из программы, которая работает с синхронным вводом-выводом, сетевой сервис, который принимает данные по сети и передает их обратно в сеть.

Попробуем создать с помощью xinetd сетевую службу, которая будет выдавать текущую дату. Для этого создадим файл с полным именем /etc/xinetd.d/test и со следующим содержанием: 

service test
{
        disable         = no
        type            = UNLISTED
        socket_type     = stream
        protocol        = tcp
        port            = 10000
        wait            = no
        user            = nobody
        server          = /bin/date
}

Эта запись означает, что создаваемый сервер будет принимать TCP-соединения на порт 10000 и передавать принятую информацию команде /bin/date, которая игнорирует ввод и выдает текущую дату. Запускаться эта команда будет от имени пользователя nobody. Теперь перезапустим сервер xinetd: 

# service xinetd restart
Service xinetd is not running.   [PASSED]
Staring xinetd service:          [ DONE ]

Проверим работоспособность сервиса, подключившись к нему командой netcat localhost 10000: 

$ netcat localhost 10000
Fri Jul  4 04:31:17 MSD 2008

А если мы укажем в поле server команду /bin/cat, то наш сервер будет отправлять полученные данные обратно отправителю (эхо-сервер).

В системе ALT Linux и ПСПО по умолчанию все встроенные службы супер-сервера xinetd выключены. Кроме того, по умолчанию в файле /etc/xinetd.conf указано, что к службам xinetd можно подключаться только с локальной машины, но не с другого компьютера по сети: only_from = 127.0.0.1. После любых изменениях в файле /etc/xinetd.conf и в файлах каталога /etc/xinetd.d супер-сервер следует перезапустить.

Настройка сетевых интерфейсов и DHCP

Рассмотрим теперь, как работает система настройки сетевых адресов etcnet в нашем дистрибутиве, как она получает настройки сети и как она их применяет. Для этого перейдем в каталог настроек /etc/net, где находятся три подкаталога (ifaces, options.d, scripts) и файл sysctl.conf.

  • В файле /etc/net/sysctl.conf находятся параметры ядра Linux, относящиеся к сетевой подсистеме. Нам, как пользователям школьного дистрибутива, этот файл обычно не нужен, за одним исключением: если нам необходимо настроить машину, работающую IP-маршрутизатором, то нужно присвоить отвечающей за маршрутизацию переменной значение 1: 

    $ grep forward /etc/net/sysctl.conf
#IPv4 packet forwarding.
net.ipv4.ip_forward = 0

Теперь рассмотрим каталоги, где находятся настройки самого etcnet.

  • В каталоге /etc/net/scripts лежат всевозможные программы, написанные на языке программирования Shell, которые выполняют различные функции. Обычно нет необходимости запускать их вручную и изменять. С помощью этих программ подсистема etcnet управляет сетевыми подключениями, запуская их в зависимости от своих параметров настройки.

  • В каталоге /etc/net/ifaces находятся подкаталоги, в которых описаны параметры сетевых интерфейсов. Каждому сетевому интерфейсу соответствует свой каталог: 

     $ ls  /etc/net/ifaces
 default eth0 lo eth1 lo unknown

    Кроме того, здесь находятся каталоги default и unknown. Настройки из первого из них применяются ко всем интерфейсам, а настройки из второго --- к не указанным в /etc/net/ifaces интерфейсам. Можно перейти в директорию интерфейса и создать, например, файл ipv4address.

  • Наконец, есть директория /etc/net/options.d, в которой находятся общие настройки системы etcnet и пути к используем программам, например к ip. Обычно изменять в ней что-либо нет необходимости.

Рассмотрим подробнее настройки сетевого интерфейса на примере каталога /etc/net/ifaces/eth0. Во-первых, в нем уже имеется файл options, где указывается, включен ли интерфейс и получает ли он адрес автоматически: 

$ cat /etc/net/ifaces/eth0/options
BOOTPROTO=dhcp-ipv4ll
DISABLED=no

С помощью опции BOOTPROTО можно управлять механизмом получения IP-адресов. Обычно указано, что BOOTPROTO=dhcp. Для статической настройки необходимо указать BOOTPROTО=static. Если указано BOOTPROTO=ipv4ll, то для машины будет выбран не использующийся в сети IP-адрес (обычно это означает, что интерфейс не будет нормально функционировать). Возможны и комбинированные значения: например,если написать BOOTPROTO=dhcp?ipv4ll, то в случае, если по протоколу DHCP настройки получить не удастся, они будут получены по ipv4ll сетевой службой Avahi.

Отметим, что файл /etc/resolv.conf с адресами серверов DNS не относится к etcnet. Однако, в etcnet существует возможность изменять данный файл в зависимости от используемого сетевого интерфейса, для чего достаточно создать файл с тем же именем resolv.conf к каталоге интерфейса, например /etc/net/ifaces/eth0/resolv.conf. Обычно в этом нет потребности, потому что если интерфейс настраивается по протоколу DHCP, то DHCP-клиент автоматически запишет полученые адреса DNS-серверов.

Указав BOOTPROTО=static в файле options, настроим интерфейс вручную. Для указания адреса необходимо в файле ipv4address указать собственно IP-адрес и маску, а в файле ipv4route --- адрес маршрутизатора по умолчанию: 

# cd /etc/net/ifaces/eth0
# echo '192.168.200.100/24' > ipv4address 
# echo 'default via 192.168.200.1' > ipv4route

После сделанных изменений можно остановить сетевой сервис, выполнив команду  service network stop  и убедиться, что оба интерфейса выключены командой  ip a . После этого можно запустить их: service network start. После этого, сделав  ip r, убедимся, что все настроено: 

# ip r
192.168.200.100/24 dev eth0 proto kernel scope link src 192.168.200.100
default via 192.168.200.1 dev eth0

Стоит отметить, что система etcnet крайне мощная, она позволяет практически любую проблему решить при помощи изменения своей конфигурации. По команде man etcnet можно увидеть все настройки etcnet. Помимо того, что etcnet хорошо документирован, он содержит огромное количество примеров. Чтобы убедиться в этом, можно выполнить, например, rpm -ql etcnet.

Системой etcnet поддерживается технология ifrename. Она позволяет переименовывать сетевые интерфейсы буквально на лету. Для чего это нужно? В современном ядре GNU/Linux возможна следующая ситуация: модуль,загрузившийся первым, получает нулевой номер интерфейса (eth0), тот, который загрузится вторым, получает первый номер (eth1) и так далее. Если бы это делалось последовательно, они бы всегда загружались в одинаковом порядке, потому что сетевые карты на сетевой шине, как правило, нумеруются одинаково. Но поскольку модули сетевых карт загружаются одновременно, часто бывает так, что сегодня первой загрузилась нижняя карточка, а второй верхняя, а завтра --- наоборот. Существует несколько вариантов решения этой проблемы, в нашем случае механизм достаточно прост: при установке дистрибутива считываются MAC-адреса сетевых карт, формируется файл /etc/iftab с соответствием имен интерфейсов и MAC-адресов, и затем всегда происходит переименование. При замене в компьютере с несколькими сетевыми картами одной из них данный файл желательно отредактировать вручную.

Протокол DHCP и настройка DHCP-клиента

Обратимся снова к протоколу уровня приложений DHCP. Для того, чтобы упростить настройку и подключение к сети для пользователя и администратора, существует служба DHCP, которая позволяет DHCP-клиентам получать от DHCP-сервера IP-адрес и маску сети, маршрутизатор по умолчанию, адреса DNS-серверов и другие настройки. Протокол DHCP работает предназначен даже для машин, у которых нет даже IP-адреса. Поэтому лучше разложить на части процедуру настройки по DHCP. Итак, основной настройкой, которую можно выдать и получить по DHCP, является IP-адрес. Существует протокол ARP, который по IP-адресу позволяет узнать MAC-адрес. В случае, когда мы знаем свой MAC-адрес и не знаем свой IP-адрес, возникает обратная ситуация, для ее разрешения изначально существовал протокол RARP (Reverse Address Resolution Protocol). В настоящее время протоколов, которые производят подобные преобразования, три: RARP, BOOTP (Bootstrap Protocol) и DHCP (Dynamic Host Configuration Protocol). Протокол RARP находится между сетевым и интерфейсным уровнем; он предназначен для преобразования своего MAC-адреса в IP-адрес. Протокол BOOTP более сложный, чем RARP, при помощи него кроме сетевого адреса можно получить имя файла, который надо скачать по tftp, что позволяет создавать бездисковые рабочие станции, загружающиеся по сети. Протокол DHCP является развитием BOOTP и очень широко используется.

Во всех случаях должен существовать сервер, который принимает запросы и выдает необходимую информацию. Крайне нежелательной является ситуация, когда таких серверов в одной локальной сети более одного, и каждый думает по-своему. Клиентом посылается широковещательный (если нет адреса конкретного DHCP-сервера) Ethernet-фрейм, который принимается компьютером с установленной сетевой службой DHCP, которая раздает IP согласно таблице соответствий IP и MAC-адресов и высылает клиенту Ethernet-фрейм с ответом. Таким образом, протокол DHCP --- позволяет получить все сетевые настройки, про которые было сказано выше. Кроме того, по протоколу DHCP машина может получить несколько сотен настроек, в том числе такие, у которых имени нет, а есть только номер. Например, настройка номер 318. Какая? Какую придумаем, такая и будет, лишь бы клиент понимал, что с нею делать дальше. Итак, основные настройки, выдаваемые по DHCP:

  • IP-адрес;
  • маска сети;
  • адрес DNS-сервера;
  • маршрутизатор по умолчанию и вся таблица маршрутизации;
  • если это сетевая загрузка, то адрес файла, который надо закачать, и адрес сервера, с которого надо его закачать;
  • ряд дополнительных настроек.

Чтобы сделать автоматическую настройку сети в etcnet, достаточно задать в каталоге интерфейса в файле options параметр BOOTPROTO=dhcp и перезагрузить сетевую службу следующей командой: 

# service network restart

.

Сетевые профили в системе etcnet

В каталоге /etc/net/ifaces/eth0 может лежать несколько файлов с именами вида options#имяпрофиля, ipv4adress#имяпрофиля, ipv4route#имяпрофиля. Каждый такой файл содержит настройки к определенному сетевому профилю. Это удобно, например, когда компьютер используется и дома и в офисе, а протокол DHCP не используется хотя бы в одном из мест работы. Никаких дополнительных сущностей, за исключением имени файла, для настройки не нужно. Более того, у службы network есть не только стандартные команды, но и дополнительные вида service network startwith home, которые позволяют выбрать, какой профиль будет использован при включении сети.

Теперь проиллюстрируем на практике сказанное выше относительно профилей etcnet. Создадим следующие настройки для интерфейса eth0: в профиле home система получает настройки вручную, а по умолчанию с помощью DHCP.

Для этого сделаем следующее.

  • Переходим в каталог интерфейса: 
     # cd /etc/net/ifaces/eth0

  • Открываем в текстовом редакторе файл options, например командой mcedit options, заполняем его следующим содержимым: 

     ONBOOT=yes
 DISABLED=no
 BOOTPROTO=dhcp

  • Открываем в текстовом редакторе файл options#home, например командой mcedit options#home, заполняем его следующим содержимым: 

     DISABLED=no
 BOOTPROTO=static
  • Задаем вручную IP-адрес, адреса маршрутизатора по умолчанию и DNS-сервера для профиля home: 
     # echo '192.168.0.4/24' > ipv4address#home
 # echo 'default via 192.168.0.1' > ipv4route#home
 # echo 'nameserver 192.168.0.1' > resolv.conf#home

Настройка сети завершена, теперь при команде 

# service network restartwith home

будет грузится профиль home со статическими настройками, а при команде 

# service network restart

будет загружен профиль по-умолчанию с получением настроек по DHCP.

PspoClasses/080703 (последним исправлял пользователь VsevolodKrishchenko 2008-08-02 00:53:15)