1.4.Принципы работы DNS
1.4.1 Отображение символьных адресов на IP-адреса: служба DNS
DNS (Domain Name System) - это распределенная база данных, поддерживающая иерархическую систему имен для идентификации узлов в сети Internet. СлужбаDNS предназначена для автоматического поиска IP-адреса по известному символьному имени узла. Спецификация DNS определяется стандартами RFC 1034 и 1035. DNS требует статической конфигурации своих таблиц, отображающих имена компьютеров в IP-адрес.
Протокол DNS является служебным протоколом прикладного уровня. Этот протокол несимметричен - в нем определены DNS-серверы и DNS-клиенты. DNS- серверы хранят часть распределенной базы данных о соответствии символьных имен и IP-адресов. Эта база данных распределена по административным доменам сети Internet. Клиенты сервера DNS знают IP-адрес сервера DNS своего административного домена и по протоколу IP передают запрос, в котором сообщают известное символьное имя и просят вернуть соответствующий ему IP- адрес.
Если данные о запрошенном соответствии хранятся в базе данного DNS-сервера, то он сразу посылает ответ клиенту, если же нет - то он посылает запрос DNS- серверу другого домена, который может сам обработать запрос, либо передать его другому DNS-серверу. Все DNS-серверы соединены иерархически, в соответствии с иерархией доменов сети Internet. Клиент опрашивает эти серверы имен, пока не найдет нужные отображения. Этот процесс ускоряется из- за того, что серверы имен постоянно кэшируют информацию, предоставляемую по запросам. Клиентские компьютеры могут использовать в своей работе IP-адреса нескольких DNS-серверов, для повышения надежности своей работы.
База данных DNS имеет структуру дерева, называемого доменным пространством имен, в котором каждый домен (узел дерева) имеет имя и может содержать поддомены. Имя домена идентифицирует его положение в этой базе данных по отношению к родительскому домену, причем точки в имени отделяют части, соответствующие узлам домена.
|
|
Корень базы данных DNS управляется центром Internet Network Information
Center. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Имена этих доменов должны следовать международному стандарту ISO 3166.
Для обозначения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций используются следующие аббревиатуры:
. com - коммерческие организации (например, microsoft.com);
. edu - образовательные (например, mit.edu);
. gov - правительственные организации (например, nsf.gov);
. org - некоммерческие организации (например, fidonet.org);
. net - организации, поддерживающие сети (например, nsf.net).
Каждый домен DNS администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Каждый домен имеет уникальное имя, а каждый из поддоменов имеет уникальное имя внутри своего домена. Имя домена может содержать до 63 символов. Каждый хост в сети Internet однозначно определяется своим полным доменным именем (fully qualified domain name,
FQDN), которое включает имена всех доменов по направлению от хоста к корню.
Пример полного DNS-имени: citint.dol.ru.
1.4.2. Основные домены верхнего уровня
Общие домены верхнего уровня созданы для всего сообщества Интернет. Первоначально было создано семь доменов: COM, NET, ORG, INT, EDU, GOV, MIL. Тогда, в 1984 году, в документах, принятых при утверждении этих доменов, было указано, что такого их количества "будет достаточно, и появления новых доменных зон не ожидается".
|
|
Однако рост сети Интернет превзошел все прогнозы, и у мирового сообщества пользователей Сети увеличилась потребность в числе и типах доменов верхнего уровня.
В 2001 году было принято решение о введении еще семи новых доменных зон: INFO, BIZ, NAME, COOP, MUSEUM, AERO и PRO. В настоящее время все семь новых доменов общего пользования работоспособны в полном объеме.
Домены СOM, NET, ORG.
Домены СOM, NET, ORG - первые общие домены верхнего уровня, появившиеся в 1984 г. согласно решению международной организации ICANN, созданной мировым сообществом для распределения адресного пространства сети Интернет. На данный момент это самые распространенные домены в мире.
Изначально домен СOM предназначался для коммерческих организаций, домен ORG - для некоммерческих организаций, и домен NET - для всех, кто связан с развитием сетей и телекоммуникационных технологий. Однако со временем регистрация доменов в этих зонах стала совершенно свободной, и зарегистрировать домен в них может любой желающий.
Домены общего пользования COM и NET администрирует компания VeriSign, а доменом ORG с начала 2003 года управляет некоммерческая организация PIR.
Домены INT, EDU, GOV, MIL.
Домены INT, EDU, GOV, MIL также появились в 1984 г. и сразу стали "специальными" или, как их называют специалисты, "ограниченного использования".
|
|
• Домен INT создан исключительно для регистрации доменных имен международными организациями. Решение о регистрации доменов в этой зоне принимается международной организацией IANA при условии соблюдения регистрантом целого ряда требований. Этот домен единственный из первых специальных, в котором могут зарегистрировать доменное имя иностранные (по отношению к США), в том числе российские и украинские организации.
• Домен EDU содержит около 5000 имен, и также как домены GOV и MIL находится под контролем американского правительства. Прежде право зарегистрировать имя в домене EDU имели только университеты и колледжи с четырехгодичным курсом обучения, но теперь к ним присоединятся и более мелкие образовательные учреждения США. Регистрация проводится на бесплатной основе.
• Домен GOV создан исключительно для федеральных государственных учреждений США, и регистрацией доменных имен в этом домене занимается Правительственный сетевой информационный центр Government-Wide Registration Service.
• Домен MIL находится под контролем американского правительства, в частности Департамента Госбезопасности США. Специалисты именно этого Департамента ведут базу доменных имен домена MIL, предназначенного только для военных организаций и учреждений, отвечающих за безопасность страны.
Новые домены верхнего уровня.
• Домен INFO
Домен INFO - один из новых общих доменов верхнего уровня, которые добавлены по решению ICANN к существующим доменам. Домен INFO рассчитан на всех, кто желает разместить информацию о себе, своем предприятии, товаре или услуге в сети Интернет.
Согласно данным, опубликованным компанией Afilias LLC, которой поручено поддерживать базу всех адресов в зоне INFO, спустя три месяца после начала регистрации доменов в этой зоне было зарегистрировано около 60.000 адресов, из них 60% - европейцами (лидеры по количеству имен) или другими не американцами. Такую популярность INFO на европейском рынке представители Afilias объясняют тем, что слово INFO интуитивно понятно людям, разговаривающим практически на любом языке.
• Домен BIZ
Домен BIZ (от английского слова business - бизнес, дело, коммерческая деятельность) - один из новых общих доменов верхнего уровня, предназначен для коммерческих организаций, предприятий и корпораций, каким-либо образом представляющим себя в Интернете. До сих пор в том значении, в каком должен выступить домен BIZ, использовался и продолжает использоваться домен COM, открытый для регистрации в 1984 г. и включающий в себя 28 миллионов доменных имен.
Широкий интерес, проявленный в ходе предварительной регистрации доменов второго уровня в зоне BIZ, показал, что корпоративные пользователи действительно заинтересованы в сайтах этой зоны, видя в них дополнительную возможность для распространения информации о своей деятельности среди клиентов и партнеров по бизнесу. Аналитики отмечают превзошедший ожидания спрос на эту услугу. Появление новой доменной зоны является важным шагом к решению проблемы дефицита доменов, возникшей в результате перенасыщенности традиционных зон (COM, NET, ORG).
Поддержку домена осуществляет компания NeuLevel.
• Домен MUSEUM
17 октября 2001 г. ICANN подписала договор с Ассоциацией управления доменом MUSEUM об управлении общим доменом верхнего уровня MUSEUM. Из семи принятых ICANN в ноябре 2000 г. доменов верхнего уровня три являются специальными: MUSEUM, AERO и PRO. Домен MUSEUM первым из них заработал в международной системе доменных имен.
Этот специальный домен предназначен для музеев, а также организаций различных форм собственности, имеющих отношение к музейному делу. Кроме того, зарегистрировать домен могут частные лица, профессионально связанные с этой сферой деятельности.
Порядок регистрации в домене MUSEUM несколько отличается от порядка регистрации в других доменах верхнего уровня. Ассоциация управления доменом MUSEUM заявила о достаточно жесткой политике, поддерживаемой в отношении этого домена. Администратор домена MUSEUM Ассоциация MuseDoma не будет формально регистрировать домены второго уровня, право каждого претендента зарегистрировать домен в зоне MUSEUM будет рассмотрено индивидуально.
• Домен NAME
Домен NAME предназначен для всех, кто хотел бы зарегистрировать в Интернет свое имя и фамилию в качестве доменного имени. Администратором доменной зоны является аккредитованная ICANN английская компания Global Name Registry Limited.
Домен NAME предназначен исключительно для частных лиц, а не для компаний.
• Домен COOP
Ассоциация NCBA, являющаяся филиалом DotCooperation LLC (DCLLC), назвала дату начала регистрации в домене COOP. 30 января 2002 г. все кооперативы во всем мире смогут зарегистрировать домены в зоне COOP. Эта дата была объявлена сразу после подписания соглашения с ICANN об управлении доменом COOP 21 ноября 2001 г.
• Домен AERO
AERO – один из семи новых доменов верхнего уровня, утвержденных ICANN 16 ноября 2000 г. Администрирование этой доменной зоны, предназначенной к использованию в основном в индустрии авиаперевозок и путешествий, поручено международной телекоммуникационной группе Societe Internationale de Telecommunications Aeronautiques SITA, объединяющей авиаперевозчиков вот уже более 50 лет.
Зарегистрировать домен в зоне AERO могут организации и физические лица, так или иначе связанные с аэроиндустрией.
• Домен PRO
С утверждением в 2001 г. семи новых доменов верхнего уровня ICANN выбрала для каждого из них компанию-регистратуру. Регистратурой домена PRO, который начнет функционировать последним, стала компания RegistryPro. В домене PRO будут созданы домены второго уровня.med.pro, law.pro и т.д., регистрировать доменные имена в которых смогут лицензированные и аккредитованные специалисты соответствующей сферы.
RegistryPro создаст список профессий, для которых будет создан собственный поддомен. Также в новом доменном пространстве появятся поддомены, связанные с географическим месторасположением. Исследования показали, что для профессионалов предпочтительней иметь сайты с доменами в профессиональной зоне PRO. Более 35 миллионов лицензированных специалистов: адвокатов, докторов, бухгалтеров в странах с высоким уровнем развития Интернет обеспечат скорое наполнение доменной зоны PRO.
Домен PRO предназначен для создания в сети Интернет областей для профессионалов в различных отраслях деятельности. Например, квалифицированный врач может зарегистрировать домен JamesRClarke.med.pro, что позволит пользователям во всем мире понять, что он аккредитован в области медицины. В то же самое время, адвокат может зарегистрировать для себя доменное имя JamesRClarke.law.pro. Кроме того, новая доменная зона доступна профессиональным компаниям и ассоциациям, которые могут зарегистрировать в домене PRO доменные имена, созвучные с названиями компаний или их товарными знаками.
1.4.3 Система доменных имен BIND
Cистема доменной адресации BIND состоит из трех компонентов: системы имен, или базы данных имен; сервера имен и resolver?а. Рассмотрим общий принцип работы сервера имен.
Любой сервер имен имеет зону своей ответственности. Для того чтобы получить адреса или имена машин, которые не входят в зону его ответственности, сервер обращается к другим серверам имен. В принципе в поисках адреса или имени запрос может пропутешествовать до корня системы доменов, а затем снова спуститься до локального сервера имен. При поиске имени resolver формирует запрос и посылает его своему серверу имен. Сервер имен пытается найти имя в своей базе данных. Если ему это удается, то ответ возвращается resolver?у, в противном случае он запрашивает сервер, стоящий выше него в иерархии доменов. Этот сервер обычно называют корневым. Корневой сервер находит сервер, в чей домен попадает указанное в запросе имя, и указывает адрес этого сервера серверу, с которого поступил запрос. Сервер, найденный корневым сервером, называют удаленным сервером. Локальный сервер устанавливает взаимодействие с удаленным сервером и получает от последнего необходимую информацию.
Рис. 4.1. Общий принцип работы сервера имен.
Кроме алгоритма взаимодействия самих серверов, интерес представляет и алгоритм формирования запроса программой, запрашивающей адрес. Обычно рассматривают три случая: однословное имя, имя с точкой на конце и составное имя. При указании однословного имени
/usr/paul>telnet polyn
происходит обращение к файлу синонимов (aliases), который указывается в переменной окружения, например, HOSTALIASES в HP-UX, или каким-либо другим способом. Файл синонимов обычно имеет структуру типа:
polyn polyn.net.kiae.su
Если в качестве имени указано имя с точкой на конце, то его и используют для поиска адреса и никакой дополнительной информации к нему не добавляют.
Если указано составное имя, то сначала его проверяют в местном домене, если адрес не найден, то к имени добавляют имя местного домена. Если снова адрес не будет найден, то добавляют имя вышестоящего домена. Если имя вышестоящего домена состоит из одного слова, то его не добавляют к указанному в запросе адресу, например:
/usr/paul/telnet apollo.polyn
При этом на машине указано имя текущего домена polyn.kiae.su. Проверены будут следующие имена: apollo.polyn; apollo.polyn.polyn.kiae.su; apollo.polyn.kiae.su. Последнее имя будет найдено в базе данных локального сервера и будет возвращен IP-адрес этой машины.
При организации своего сервера имен следует принять во внимание, что для этого его следует зарегистрировать в организации, которая предоставляет IP-услуги. Во многих книгах по Internet написано, что следует обращаться в INTERNIC или в NOC EUnet и приводятся их адреса. Вообще говоря, это не совсем правильно. В материалах RIPN (некоммерческий европейский Internet) указано, что обращаться следует в RELARN. При регистрации коммерческой сети следует обращаться к представителю этой сети в регионе. Представителем EUnet является Relcom, сети Sprint -- RuSprint, GLASNET -- российский GLASNET, Telecom -- Sovam Teleport. В общем случае свои доменные адреса следует регистрировать там же, где получают IP-адреса.
Различают четыре вида серверов: primary master сервер; secondary master сервер; caching сервер; удаленный (remote) сервер.
• Primary master сервер -- это сервер, который поддерживает свою базу данных имен и обслуживает местный домен.
• Secondary master сервер -- это сервер, который обслуживает свой домен, но данные об адресах части своих машин получает по сети с другого сервера.
• Caching сервер не имеет своего домена. Он получает данные либо с одного из master серверов, либо из буфера.
• Удаленный сервер -- это обычный master сервер, который установлен на удаленной машине. Программы обращаются к нему по сети.
Обычно, адрес сервера указывается в файле /etc/resolv.conf. При выборе типа сервера имен, который будет использоваться на машине, следует принять во внимание следующие соображения:
Primary или secondary master серверы устанавливаются обычно на машинах, которые являются шлюзами для локальных сетей. Вообще говоря, сервер имен может быть установлен на любой компьютер локальной сети. Но он будет только один на зону. При выборе машины для установки сервера имен следует принимать в расчет то обстоятельство, что многие реализации серверов держат базы данных имен в оперативной памяти. При этом часто подгружается информация и с других серверов. Все это может вызвать задержки при разрешении запроса на адрес по имени машины, если для сервера имен будет использоваться маломощный компьютер.
Если нужно получить преимущества работы со своим собственным сервером имен реально не управляя доменом, то можно установить только кэширующий сервер, который будет погружать информацию с master серверов и использовать ее для поиска IP-адресов.
При работе на рабочих станциях или персональных компьютерах, которые не являются шлюзами и не используются для публичного сервиса, имеет смысл использовать удаленные сервера, что облегчает проблемы с администрированием сервера имен.
Любой сервер имен настраивается своими служебными файлами. Программа, которая выполняет функции BIND, называется named. При запуске этой программы считывается файл /etc/named.boot. В этом файле указаны: тип сервера, какой зоне он принадлежит и где расположены файлы его базы данных. Файлы базы данных не имеют жесткого разделения, но обычно администраторы их разделяют на: файлы описания хостов и зоны; файл адресов удаленных серверов этой же зоны; файл адресов корневых серверов имен.
1.4.4 Автоматизация процесса назначения IP-адресов узлам сети - протокол DHCP
Как уже было сказано, IP-адреса могут назначаться администратором сети вручную. Это представляет для администратора утомительную процедуру. Ситуация усложняется еще тем, что многие пользователи не обладают достаточными знаниями для того, чтобы конфигурировать свои компьютеры для работы в интерсети и должны поэтому полагаться на администраторов.
Протокол Dynamic Host Configuration Protocol (DHCP) был разработан для того, чтобы освободить администратора от этих проблем. Основным назначением DHCP является динамическое назначение IP-адресов. Однако, кроме динамического, DHCP может поддерживать и более простые способы ручного и автоматического статического назначения адресов.
В ручной процедуре назначения адресов активное участие принимает администратор, который предоставляет DHCP-серверу информацию о соответствии IP-адресов физическим адресам или другим идентификаторам клиентов. Эти адреса сообщаются клиентам в ответ на их запросы к DHCP-серверу.
При автоматическом статическом способе DHCP-сервер присваивает IP-адрес (и, возможно, другие параметры конфигурации клиента) из пула наличных IP-адресов без вмешательства оператора. Границы пула назначаемых адресов задает администратор при конфигурировании DHCP-сервера. Между идентификатором клиента и его IP-адресом по-прежнему, как и при ручном назначении, существует постоянное соответствие. Оно устанавливается в момент первичного назначения сервером DHCP IP-адреса клиенту. При всех последующих запросах сервер возвращает тот же самый IP-адрес.
При динамическом распределении адресов DHCP-сервер выдает адрес клиенту на ограниченное время, что дает возможность впоследствии повторно использовать IP-адреса другими компьютерами. Динамическое разделение адресов позволяет строить IP-сеть, количество узлов в которой намного превышает количество имеющихся в распоряжении администратора IP-адресов.
DHCP обеспечивает надежный и простой способ конфигурации сети TCP/IP, гарантируя отсутствие конфликтов адресов за счет централизованного управления их распределением. Администратор управляет процессом назначения адресов с помощью параметра "продолжительности аренды" (lease duration), которая определяет, как долго компьютер может использовать назначенный IP-адрес, перед тем как снова запросить его от сервера DHCP в аренду.
Примером работы протокола DHCP может служить ситуация, когда компьютер, являющийся клиентом DHCP, удаляется из подсети. При этом назначенный ему IP-адрес автоматически освобождается. Когда компьютер подключается к другой подсети, то ему автоматически назначается новый адрес. Ни пользователь, ни сетевой администратор не вмешиваются в этот процесс. Это свойство очень важно для мобильных пользователей.
Протокол DHCP использует модель клиент-сервер. Во время старта системы компьютер-клиент DHCP, находящийся в состоянии "инициализация", посылает сообщение discover (исследовать), которое широковещательно распространяется по локальной сети и передается всем DHCP-серверам частной интерсети. Каждый DHCP-сервер, получивший это сообщение, отвечает на него сообщением offer (предложение), которое содержит IP-адрес и конфигурационную информацию.
Компьютер-клиент DHCP переходит в состояние "выбор" и собирает конфигурационные предложения от DHCP-серверов. Затем он выбирает одно из этих предложений, переходит в состояние "запрос" и отправляет сообщение request (запрос) тому DHCP-серверу, чье предложение было выбрано.
Выбранный DHCP-сервер посылает сообщение DHCP-acknowledgment (подтверждение), содержащее тот же IP-адрес, который уже был послан ранее на стадии исследования, а также параметр аренды для этого адреса. Кроме того, DHCP-сервер посылает параметры сетевой конфигурации. После того, как клиент получит это подтверждение, он переходит в состояние "связь", находясь в котором он может принимать участие в работе сети TCP/IP. Компьютеры-клиенты, которые имеют локальные диски, сохраняют полученный адрес для использования при последующих стартах системы. При приближении момента истечения срока аренды адреса компьютер пытается обновить параметры аренды у DHCP-сервера, а если этот IP-адрес не может быть выделен снова, то ему возвращается другой IP-адрес.
В протоколе DHCP описывается несколько типов сообщений, которые используются для обнаружения и выбора DHCP-серверов, для запросов информации о конфигурации, для продления и досрочного прекращения лицензии на IP-адрес. Все эти операции направлены на то, чтобы освободить администратора сети от утомительных рутинных операций по конфигурированию сети.
Однако использование DHCP несет в себе и некоторые проблемы. Во-первых, это проблема согласования информационной адресной базы в службах DHCP и DNS. Как известно, DNS служит для преобразования символьных имен в IP-адреса. Если IP-адреса будут динамически изменятся сервером DHCP, то эти изменения необходимо также динамически вносить в базу данных сервера DNS. Хотя протокол динамического взаимодействия между службами DNS и DHCP уже реализован некоторыми фирмами (так называемая служба Dynamic DNS), стандарт на него пока не принят.
Во-вторых, нестабильность IP-адресов усложняет процесс управления сетью. Системы управления, основанные на протоколе SNMP, разработаны с расчетом на статичность IP-адресов. Аналогичные проблемы возникают и при конфигурировании фильтров маршрутизаторов, которые оперируют с IP-адресами.
Наконец, централизация процедуры назначения адресов снижает надежность системы: при отказе DHCP-сервера все его клиенты оказываются не в состоянии получить IP-адрес и другую информацию о конфигурации. Последствия такого отказа могут быть уменьшены путем использовании в сети нескольких серверов DHCP, каждый из которых имеет свой пул IP-адресов.
1.5. Принципы и основные протоколы маршрутизации в Интернет
1.5.1 Основные принципы IP-маршрутизации
Как уже было сказано раньше, протокол IP не является протоколом ориентированным на соединение. Следовательно, решение о направлении IP-пакета на тот или иной сетевой интерфейс принимается шлюзом в момент прохождения через него пакета. Данное решение принимается на основании таблицы маршрутов, имеющаяся на каждом компьютере, который поддерживает стек протоколов TCP/IP.
Прежде чем перейти к описанию самой процедуры, введем пример сети, на которой будем рассматривать маршрутизацию пакетов (рисунок 5.1).
Рис. 5.1. Пример фрагмента локальной сети.
На рисунке 2.21 изображены два фрагмента подсетей (144.206.160.0 и 144.206.128.0) сети класса B (144.206.0.0). Машина с интерфейсами, которые имеют адреса 144.206.160.32 и 144.206.130.137 - это шлюз между двумя подсетями, а машина с адресом сетевого интерфейса 144.206.130.3 - это шлюз сети с другой сетью, которая подключена к Internet.
Рассмотрим сначала путь пакета от машины с адресом 144.206.160.40 к машине с адресом 144.206.160.33. Пусть, к этой машине пользователь 144.206.160.40 еще не обращался. В рамках такого обмена машине достаточно знать только свой IP-адрес. Прежде чем отправить пакет, модуль ARP проверит, существует ли соответствие между IP-адресом получателя и физическим адресом какого-либо интерфейса включенного в локальную сеть. В нашем случае такого соответствия еще нет, поэтому в сеть будет отправлен широковещательный запрос на получение физического адреса по заданному IP-адресу. В ответ машина 144.206.160.33 сообщит свой адрес, после чего пакет будет отправлен в сеть. В поле физического адреса в фрейме протокола канального уровня будет указан адрес машины 144.206.160.33. Такая процедура была разработана для Ethernet, но в последнее время ARP стали применять и для других физических сред.
Отправим пакет машине из другой подсети 144.206.130.138. На широковещательный запрос мы ответа не получим. Но пакет отправлять как-то надо. Для этой цели в описании маршрутов пакетов всегда есть IP-адрес, на который следует отправлять пакеты по умолчанию, если нет другого способа их рассылки. Естественно, что это адрес шлюза. Для машины 144.206.160.40 таким адресом является адрес 144.206.160.32. Физический адрес этого интерфейса получают точно также, как мы до этого получили физический адрес интерфейса 144.206.160.33. Различие здесь заключается в том, что в первом случае адреса получателя и отправителя во фрейме физического протокола совпадали с адресами, которые указаны для IP-адресов из IP-пакета в таблице ARP. В случае шлюза здесь можно обнаружить несоответствие. Во фрейме в качестве получателя будет указан адрес интерфеса 144.206.160.32, в то время как в IP-пакете будет указан IP-адрес 144.206.130.138. Но ведь этому IP-адресу соответствует совсем другой физический адрес. Другой адрес будет соответствовать в сети Ethernet, если же речь идет о FrameRelay, то там может применяться относительная система адресации, что может приводить к равенству физических адресов.
Получив таким образом пакет модуль IP машины шлюза определяет, что это не его адрес указан в IP-пакете. После такого открытия IP-модуль шлюза принимает решение о дальнейшей отправке пакета. Отправлять пакет в тот же интерфейс, из которого он получен - бессмысленно, поэтому модуль IP никогда не отправляет пакеты назад. Следовательно, происходит поиск нужного интерфейса и через него снова рассылается широковещательный запрос ARP. В нашем случае такой запрос вернет для IP-адреса 144.206.130.138 физический адрес машины и пакет будет отправлен по этому адресу.
Если пакет отправляется в Internet, то шлюз не найдет физического адреса машины, и будет вынужден воспользоваться адресом рассылки по умолчанию. Таким образом, пакет попадет на шлюз через 144.206.130.3 и там будет решаться его судьба.
При рассмотрении стека протоколов TCP/IP на компьютере с одним сетевым интерфейсом было не очень понятно, зачем IP дублирует физический адрес, например, Ethernet, ведь каждому адресу Ethernet ставился в соответствие один IP-адрес. При рассмотрении архитектуры стека протоколов шлюза этот вопрос становится более понятным.
Из рисунка 5.2 видно, что таблица ARP создается для каждого интерфейса. Для получения таких таблиц можно использовать команду arp, где в качестве аргумента надо указать имя интерфейса. Модуль IP для шлюза общий и таблица маршрутов, а именно, она и используется модулем для перенаправления пакетов на интерфейсы, также общая.
Рис. 5.2. Архитектура шлюза 144.206.130.137-144.206.160.32.
1.5.2 Разбиения адресного пространства сети на подсети