Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

492

Глава 12. Сетевая безопасность

-i имя

Определяет имя входящего сетевого интерфейса, для которого справед-

ливо правило. Правило действует только на пакеты, полученные через

этот интерфейс. Символ + в конце имени позволяет задавать интерфейсы

по маске (eth+ соответствует всем Ethernet-интерфейсам, имена которых

начинаются с eth).

-о имя

Определяет имя исходящего сетевого интерфейса, для которого справед-

ливо правило. Правило действует только на пакеты, передаваемые через

этот интерфейс. Символ + в конце имени позволяет задавать интерфейсы

по маске (eth+ соответствует всем Ethernet-интерфейсам, имена которых

начинаются с eth).

-f

Указывает, что правило относится только ко второму и последующим

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

Примеры команд iptables

Если собрать все описанные средства, мы получим брандмауэр, способный

защитить сеть. Предположим, что у нас есть Linux-маршрутизатор, подклю-

ченный к сетевому периметру с адресом 172.16.12.254 через интерфейс ethO

и к внешней сети с адресом 192.168.6.5 через интерфейс ethl. Кроме того,

предположим, что в сетевом периметре лишь два сервера - сервер sendmail и

сервер Apache. Вот пример команд iptables, которые мы могли бы выпол-

нить на этой Linux-системе с целью защиты сетевого периметра:

iptable -F INPUT

iptables -F FORWARD

iptables -A INPUT -i ethl -j DROP

iptables -A FORWARD -i ethl -s 172.16.0.0/16 -j DROP

iptables -A FORWARD -o ethl -d 172.16.0.0/16 -j DROP

iptables -A FORWARD -d 172.16.12.1 25 -j ACCEPT

iptables -A FORWARD -d 172.16.12.6 80 -j ACCEPT

iptables -A FORWARD -j DROP

Первые две команды при помощи ключа -F очищают наборы правил, с кото-

рыми мы намереваемся работать. Третья команда предписывает удалять все

пакеты из внешней сети, адресованные процессам Linux-маршрутизатора.

Мы не хотим, чтобы к процессам маршрутизатора обращался кто-либо из

внешнего мира.

Следующие две команды предписывают удалять пакеты, передаваемые во

внешний мир с внутреннего адреса. Если пакеты приходят через внешний

интерфейс и имеют внутренний адрес, они удаляются. Точно так же, если

пакеты, передаваемые через внешний интерфейс, имеют конечный адрес в

локальной сети, они удаляются. Эти правила говорят, что если пакеты из

внешней сети (проходящие через интерфейс ethl) некорректно используют

адреса внутренней сети (172.16), кто-то пытается организовать атаку, осно-

ванную на подделке пакетов, и такие пакеты следует удалять.

Последнее напутствие 493

Следующие два правила практически идентичны. Они предписывают при-

нимать пакеты, если пункт назначения и номер порта соответствуют кон-

кретному серверу. Например, порт 25 - это порт SMTP, а 172.16.12.1- адрес

почтового сервера, тогда как порт 80 - это порт HTTP, а 172.16. 12.6 - адрес

веб-сервера. Мы принимаем такие входящие соединения, поскольку они ад-

ресованы нужным системам. Последнее правило запрещает пропускать лю-

бой другой трафик.

Эти примеры иллюстрируют мощь встроенных механизмов фильтрации Li-

nux и содержат достаточный объем информации, чтобы вы могли начать са-

мостоятельную работу. Разумеется, при создании боевого брандмауэра мож-

но и нужно сделать гораздо больше. Если вы хотите узнать больше о команде

iptables, обратитесь к книгам «Создание защиты в Интернете» (Building In-

ternet Firewalls) и «Безопасность Linux» (Linux Security) в поисках более

подробных примеров.

Последнее напутствие

Я не специалист по безопасности, я сетевой администратор. С моей точки

зрения, хорошая безопасность - это хорошее системное администрирование,

и наоборот. По большей части эта глава состоит из практических советов.

Этих советов, вероятно, будет достаточно во многих случаях, но, разумеет-

ся, не во всех.

Потрудитесь узнать, существует ли уже руководящий документ по безопас-

ности для вашей сети или системы. Если существуют правила, нормы, зако-

ны, определяющие курс действий, следуйте им. Ни при каких обстоятельст-

вах не совершайте действий, направленных на нарушение установленной

для вашей площадки системы безопасности.

Абсолютно защищенных систем не бывает. Независимо от объема принятых

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

Разработайте план восстановления после происшествий и сделайте все необ-

ходимое, чтобы даже в наихудшем случае была возможность восстановиться

с минимальными потерями времени и данных.

Тем, кого интересуют дополнительные подробности по безопасности, я реко-

мендую прочесть следующие документы и книги:

• RFC 2196, Site Security Handbook (Учебник по безопасности сетевых пло-

щадок), Б. Фрейзер (В. Fraser), September 1997.

• RFC 1281, Guidelines for the Secure Operation of the Internet (Указания no

безопасной работе сети Интернет), Р. Пефья (R. Pethia), С. Крокер

(S. Crocker), Б. Фрейзер (В. Fraser), November 1991.

• «Practical Unix and Internet Security» (Практическая безопасность Unix и

Интернет), Симеон Гарфинкел (Simson Garfinkel) и Джин Спеффорд (Ge-

ne Spafford), O'Reilly & Associates, 1996.

• «Linux Security» (Безопасность Linux), Рамон Хонтанон (Ramon Honta-

non), Sybex, 2001.

494

Глава 12. Сетевая безопасность

• «Building Internet Firewalls» Элизабет Цвики (Elizabeth Zwicky), Саймон

Купер (Simon Cooper) и Брент Чапмен (Brent Chapman), O'Reilly & Associ

ates, 2000.

• «Linux Firewalls» Роберт Зиглер (Robert Ziegler), New Riders, 2000.

• «Firewalls and Internet Security» (Брандмауэры и безопасность в Интер-

нете), Уильям Чезвик (William Cheswick) и Стивен Белловин (Steven Bel

lovin), Addison Wesley, 1994.

Резюме

Доступ к сети и компьютерная безопасность имеют прямо противоположные

цели. Подключение компьютера к сети повышает его уязвимость. Чтобы оп-

ределить, какие типы защиты использовать и насколько ревностно защи-

щать свои системы, необходимо оценить потребность в защищенности. Раз-

работайте письменный план обеспечения безопасности площадки, определя-

ющий процедуры действий и документирующий связанные с безопасностью

обязанности сотрудников всех уровней.

Безопасность сети - это, по сути дела, хорошая безопасность отдельных сис-

тем. Проверка подлинности пользователей, эффективные способы наблюде-

ния за системой, а также хорошо подготовленные системные администрато-

ры - вот залог хорошей безопасности. Существуют инструменты, облегчаю-

щие решение подобных задач. SSH, OPIE, Tripwire, OpenSSL, iptables, TCP-

оболочки, шифрование и брандмауэры - все они в вашем распоряжении.

Э. Цвики, С. Купер и Б. Чапмен «Создание защиты в Интернете». - Пер. с англ. -

СПб: Символ-Плюс, 2002.

Роберт Зиглер «Брандмауэры в Linux». - Пер. с англ. - Вильяме, 2000.

• Подход к проблеме

• Инструменты

диагностирования

• Проверка наличия подключения

• Разрешение проблем

доступа к сети

• Проверка маршрутизации

• Проверка службы имен

• Анализ проблем протоколов

• Пример исследования

для протокола

Разрешение

проблем TCP/IP

Задачи сетевого администрирования делятся на две очень непохожих кате-

гории: настройка и отладка. Задачи настройки связаны с предсказуемыми

явлениями: они требуют обстоятельных познаний в синтаксисе команд, но

просты и прямолинейны. Когда система корректно настроена, редко возни-

кает причина изменять настройки. Процесс настройки пов торяется каждый

раз после установки новой версии операционной системы, но с минимальны-

ми вариациями.

Напротив, диагностирование сетевых проблем связано с непредвиденными

явлениями. Разрешение проблем часто требует знаний не столько обстоя-

тельных, сколько концептуальных. Сетевые проблемы обычно неповтори-

мы, и иногда их сложно решать. Разрешение проблем - важная составная

часть обеспечения стабильности и надежности работы сети.

В этой главе мы обсудим инструменты администратора, помогающие под-

держивать сеть в хорошем рабочем состоянии. Но просто хороших инстру-

ментов недостаточно. От хорошего инструмента отладки мало толку, если он

используется наобум. Эффективное диагностирование требует методичного

подхода к обнаружению проблем, а также базовых познаний в принципах

работы сети. Мы начнем с выбора подхода к сетевой проблеме.

Подход к проблеме

Чтобы правильно подойти к проблеме, необходимы базовые познания в

TCP/IP. Первые главы этой книги рассказывают об основах TCP/IP и содер-

жат достаточный для разрешения большинства сетевых проблем объем те-

496

Глава 13. Разрешение проблем TCP/IP

матических сведений. Знание того, как TCP/IP маршрутизирует данные по

сети, между отдельными узлами и между уровнями стека протоколов, важ-

но для понимания сетевой проблемы. При этом знание подробностей функ-

ционирования каждого из протоколов обычно не требуется. Если вам пона-

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

ника, а не пытаться восстановить по памяти.

Не все проблемы TCP/IP похожи, и не все проблемы можно решить одним

способом. Однако ключом к разрешению любой проблемы является понима-

ние, в чем проблема заключена. Найти ответ на этот вопрос не так просто,

как кажется на первый взгляд. «Внешний вид» проблемы временами обман-

чив, а «настоящая» проблема часто скрыта многочисленными уровнями

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

решение часто оказывается очевидным.

Прежде всего, соберите подробнейшую информацию о том, что именно про-

исходит. Если о проблеме сообщает пользователь, поговорите с ним. Узнай-

те, с каким приложением связан сбой. Определите имя и IP-адрес удаленно-

го узла, имя и адрес узла пользователя. Какое сообщение об ошибке было по-

лучено? По возможности воспроизведите проблему в процессе беседы с поль-

зователем. Дайте пользователю повторно выполнить приложение. Если

возможно, воспроизведите проблему на своей собственной системе.

Действуя с системы пользователя и других систем, уточните следующие мо-

менты:

• Возникает ли подобная проблема в других приложениях на узле пользова-

теля или же проблема связана с единственным приложением? В послед-

нем случае дело может быть в неверной настройке приложения либо в

том, что это приложение не поддерживается удаленным узлом. Из сообра-

жений безопасности многие системы блокируют работу отдельных служб.

• Проблема возникает при взаимодействии с единственным удаленным уз-

лом, всеми удаленными узлами либо только определенной «группой»

удаленных узлов? Если такой удаленный узел один, проблема может

быть связана именно с ним. Если же под подозрение попадают сразу все

удаленные узлы - проблема, вероятно, в системе пользователя (в особен-

ности если подобная проблема не возникает у других узлов локальной се-

ти). Если же под вопросом только узлы определенных подсетей или внеш-

них сетей, проблема может быть связана с маршрутизацией.

• Присутствует ли та же проблема на других локальных системах? Не за-

будьте проверить другие системы той же подсети. Если проблема возни-

кает только на узле пользователя, сосредоточьте усилия на этой машине.

Если проблема возникает на всех системах подсети, сосредоточьтесь на

маршрутизаторе этой подсети.

Разобравшись с симптомами проблемы, представьте себе все протоколы и

устройства, через которые проходят данные. Это убережет от чрезмерных

упрощений и предположений, что причина известна уже до начала тестиро-

вания. Воспользуйтесь своими познаниями в TCP/IP, чтобы сосредоточить

Подход к проблеме 497

внимание на наиболее вероятных причинах проблемы, но при этом сохра-

няйте непредвзятый подход.

Советы по разрешению проблем

Здесь я привожу ряд полезных советов по разрешению проблем. Они не яв-

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

могут пригодиться.

• Подходите к проблемам методично. Руководствуйтесь в тестировании ин-

формацией, накопленной в процессе всех тестов. Не вздумайте по наитию

резко менять курс тестирования, если нет уверенности, что вы потом смо-

жете продолжить тест с того же места.

• Разбирайте проблему постепенно, разделяя ее на удобоваримые части.

Выполняйте тестирование для каждой части, прежде чем перейти к сле-

дующей. Например, при проверке сетевого подключения проверяйте по-

очередно все сегменты сети, пока источник проблемы не будет найден.

• Ведите учет проведенных тестов и полученных результатов. Сохраняйте

сведения о каждой из возникавших проблем - на случай их повторного

появления.

• Подходите к вопросу непредвзято. Не стройте предположений относи-

тельно истинной природы проблемы. Некоторые всегда валят проблемы

на свою сеть, тогда как другие постоянно считают источником проблем

удаленный сервер. Некоторые настолько хорошо «знают», в чем пробле-

ма, что игнорируют результаты тестирования. Не делайте подобных оши-

бок. Проверяйте все возможности и в своих действиях исходите из пока-

зателей тестов.

• Помните о барьерах безопасности. Брандмауэры могут блокировать рабо-

ту программ ping и trace route и даже сообщения об ошибках ICMP. Если

проблемы сосредоточены вокруг конкретной удаленной сетевой площад-

ки, проверьте, не защищена ли она брандмауэром.

• Внимательно относитесь к сообщениям об ошибках. Формулировки сооб-

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

ные намеки, позволяющие решить проблему.

• Воспроизводите проблему, о которой вам сообщили, самостоятельно. Не

слишком полагайтесь на отчет пользователя о проблеме. Пользователь,

вероятно, рассматривал ее только на прикладном уровне. Если необходи-

мо, используйте файлы данных пользователя для воспроизведения проб-

лемы. Даже если проблему не удается воспроизвести, зафиксируйте под-

робности на будущее.

• Причиной большинства проблем служат человеческие ошибки. Некоторые

из подобных ошибок можно избежать, если предоставить пользователям

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

• Своевременно информируйте пользователей, поскольку это сокращает

число дублирующихся сообщений о проблемах и позволяет избежать слу-

498

Глава 13. Разрешение проблем TCP/IP

чаев, когда несколько системных администраторов занимаются одной и

той же проблемой совершенно независимо друг от друга. Возможно, что

кто-то уже встречался ранее с этой проблемой и может поделиться полез-

ными идеями на тему ее решения.

• Не рассуждайте о возможных причинах возникновения проблемы в раз-

говоре с пользователем. Оставьте это для разговоров с коллегами по сети.

Эти соображения могут быть восприняты пользователем в качестве от-

кровения, и быстро превратятся в слухи. Эти слухи заставят пользовате-

лей избегать использования нормальных сетевых служб и подорвут уве

ренность в вашей сети. Пользователям нужны решения проблем, но ни-

как не жаргонная болтовня.

• Работайте с небольшим набором простых инструментов диагностирова-

ния. В случае большинства программ TCP/IP можно обойтись инструмен-

тами, описанными в этой главе. Приобретение навыков работы с новым

инструментом часто отнимает больше времени, чем решение проблемы

при помощи старого, знакомого инструмента.

• Тщательно изучите проблему в своем участке сети, прежде чем начинать

поиск владельцев удаленной системы с целью скоординировать с ними

усилия по тестированию. Наибольшая сложность в диагностировании се-

тевых проблем заключена в том, что не всегда есть доступ к системам по

обе стороны канала. Во многих случаях вообще неизвестно, кто управля-

ет удаленной системой. Чем больше сведений вы получите на своей сторо-

не, тем проще будет задача, если придется в итоге связаться с админист-

ратором удаленной системы.

• Не пренебрегайте очевидными решениями. Поврежденный или плохо

подключенный кабель вполне может оказаться действительной причи-

ной проблемы. Проверьте штекеры, разъемы, кабели и коммутаторы.

Мелочи способны вызывать серьезные сложности.

Инструменты диагностирования

Поскольку причины большинства проблем просты, приобретение четкого

представления о проблеме зачастую и является решением. К сожалению, это

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

ющих подготовить атаку на самую трудноизлечимую проблему. Существует

множество средств диагностики - начиная от коммерческих систем со спе-

циализированным программным и аппаратным обеспечением стоимостью

многие тысячи долларов и заканчивая бесплатными программами из ком-

плекта поставки системы Unix. Кроме того, следует иметь под рукой некото-

рые инструменты.

Для работы с сетевым оборудованием и кабелями пригодится простейший

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

отверток, однако не исключено, что возникнет необходимость в специализи-

рованных инструментах. Например, для присоединения разъема RJ-45 к не-

Инструменты диагностирования

499

экранированной витой паре (UTP) требуется использование специального об-

жимного инструмента. Как правило, проще всего купить готовый набор ин-

струментов для сетевых работ у вашего поставщика кабельной продукции.

Полноценный кабельный тестер также полезен. Современные кабельные

тестеры - это небольшие портативные устройства с клавиатурой и жидко-

кристаллическим экраном, позволяющие тестировать как коаксиальные,

так и UTP-кабели. Выбор тестов производится с клавиатуры, а результаты

отображаются на жидкокристаллическом экране. Интерпретировать ре-

зультаты не нужно - устройство делает все за вас и выводит сообщение об

ошибке в виде простого текста. К примеру, тест кабеля может привести к

выводу сообщения «Short at 74 feet». Из этого сообщения можно понять, что

в кабеле присутствует замыкание в 74 футах

от тестера. Что может быть

проще? Качественные инструменты тестирования упрощают поиск, а зна-

чит, и разрешение проблем с кабелями.

Весьма полезным элементом тестировочного оборудования может стать пра-

вильно настроенный портативный компьютер. Установите программное

обеспечение TCP/IP. Возьмите компьютер с собой, направляясь к пользова-

телю, сообщившему о сетевой проблеме. Отсоедините кабель Ethernet от

пользовательской системы и подключите его к своему портативному ком-

пьютеру. Выполните настройку с подходящим адресом из подсети пользова-

теля и перезагрузитесь. Затем прозвоните различные системы сети при по-

мощи программы ping и подключитесь к одному из серверов пользователя.

Если все работает, ошибка, скорее всего, связана с компьютером пользовате-

ля. Пользователи доверяют такому тесту, поскольку он воспроизводит то,

что они делают ежедневно. Пользователи больше доверяют портативному

компьютеру, чем непонятному прибору для тестирования, отображающему

сообщение «No faults found» (Нет ошибок). Если же тестирование дает сбой,

проблема, вероятно, связана с сетевым оборудованием или подключением.

И вот тогда на сцене появляется тестер для кабелей.

Другим преимуществом использования портативного компьютера в качест-

ве инструмента тестирования является его врожденная гибкость. Он позво-

ляет работать с широким спектром приложений для тестирования, диагнос-

тики и управления. Установите Unix на этот портативный компьютер и ра-

ботайте с программами, описанными в этой главе, как с настольного, так и с

портативного компьютера.

В этой книге сделан упор на бесплатные или «встроенные» программные ди-

агностические инструменты систем Unix. Программные инструменты, об-

суждаемые в этой главе, а также многие другие описаны в документе RFC

1470, FYI on a Network Management Tool Catalog: Tools for Monitoring and De-

bugging TCP/IP Internets and Interconnected Devices (Информативный доку-

мент по каталогу инструментов управления сетями: инструменты для наблю-

дения и отладки Интернет-сетей TCP/IP и взаимосвязанных устройств).

Броский заголовок и полезный документ! Документ в некоторой степени уста-

Около 22 метров. - Примеч. перев.

500

Глава 13. Разрешение проблем TCP/IP

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

Инструменты, перечисленные в каталоге и описанные в этой книге:

ifconfig

Предоставляет сведения о базовых настройках интерфейса. Полезна для

поиска неверных IP-адресов, некорректных масок подсетей, а также невер-

ных широковещательных адресов, ifconfig подробно описывается в главе 6.

Данный инструмент поставляется в составе операционной системы Unix.

агр

Предоставляет информацию о преобразовании адресов Ethernet/IP. Мо-

жет использоваться для обнаружения систем локальной сети, при на-

стройке которых использовался неверный IP-адрес, агр описывается в

этой главе и используется в примерах главы 2. агр входит в состав Unix.

netstat

Предоставляет самую разнообразную информацию. Повсеместно исполь-

зуется для вывода подробной статистики по каждому из сетевых интер-

фейсов, по сетевым сокетам, а также таблицам маршрутизации, netstat

многократно упоминается в этой книге, а подробнее всего в главах 2, 6 и 7.

netstat входит в состав Unix.

ping

Позволяет определить, доступен ли удаленный узел, ping отображает ста-

тистику по потерянным пакетам и времени доставки. Программа ping опи-

сана в главе 1 и используется в главе 7. ping также входит в состав Unix.

nslookup

Предоставляет информацию о службе имен DNS. nslookup подробно опи-

сывается в главе 8 и входит в состав программного пакета BIND.

dig

Также предоставляет информацию о службе имен. По функциональности

схожа с nslookup.

traceroute

Выводит информацию о каждом из транзитных участков маршрута, по

которому проходит пакет от вашей системы до удаленной.

snoop

Анализирует отдельные пакеты, которыми обмениваются узлы сети,

snoop - это анализатор протоколов TCP/IP, включенный в состав системы

Solaris 8. Он позволяет изучать содержимое пакетов, включая заголов-

ки, и наиболее полезен для анализа проблем, связанных с протоколами,

tcpdump - инструмент с аналогичными функциями, он поставляется в сис-

темах Linux.

В этой главе описаны все перечисленные инструменты, даже те, что уже

описывались ранее. Мы начнем с программы

ping,

которая при отладке при-

меняется чаще любого другого инструмента диагностирования.

Проверка наличия подключения 501

Проверка наличия подключения

Команда ping проверяет, можно ли получить доступ к удаленному узлу с ва-

шего компьютера. Эта простая функциональность крайне полезна при тес-

тировании сетевого подключения, независимо от того, в каком приложении

возникла проблема, ping позволяет определить, в каком направлении следу-

ет проводить дальнейшее тестирование - сетевого соединения (более низкие

уровни) или же приложения (верхние уровни). Если ping сообщает, что паке-

ты достигают удаленной системы и возвращаются обратно, проблема поль-

зователя, вероятно, связана с верхними уровнями. Если пакеты не могут

вернуться, дело, скорее всего, в протоколах более низкого уровня.

Пользователь часто сообщает о сетевой проблеме, заявляя, что не может от-

крыть сеанс telnet (или

ftp,

или же отправить почту, или что-то еще) на опре-

деленном удаленном узле. И тут же подкрепляет свое утверждение словами,

что раньше все работало. В таких случаях, если возможность подключения к

удаленному узлу оказывается под вопросом, ping - очень полезное средство.

Выполните прозвонку удаленного узла, указанного вам пользователем. Ес-

ли ping сообщает, что все в порядке, попросите пользователя прозвонить

узел. Если и на этот раз пакеты проходят, сосредоточьте дальнейший анализ

в области конкретного приложения, с которым возникают проблемы у поль-

зователя. Возможно, пользователь пытается наладить сеанс telnet с узлом,

который предоставляет только анонимный ftp-доступ. Возможно, узел не

работал именно в тот момент, когда пользователь попытался решить свою

задачу. Попросите пользователя попробовать еще раз и очень внимательно

наблюдайте за всеми его действиями. Если пользователь все делает правиль-

но, однако ошибка в приложении по-прежнему возникает, может потребо-

ваться тщательный анализ приложения при помощи snoop и даже обраще-

ние к администратору удаленной системы.

Если ваша ping-прозвонка проходит успешно, a ping с пользовательской ма-

шины дает сбой, проверьте настройки пользовательской системы, а также

протестируйте отличия путей к удаленному узлу от вашей машины и от ма-

шины пользователя.

Если ваши ping-команды или ping-команды пользователя дают сбой, внима-

тельно отнеситесь к любым сообщениям об ошибках. Сообщения об ошибках

ping - полезные проводники в планировании дальнейшего тестирования.

Конкретика сообщений может варьироваться от реализации к реализации,

однако основных типов ошибок существует не так много:

Unknown host (Неверный узел)

Имя удаленного узла не может быть преобразовано службой имен в IP-ад-

рес. Могут быть виноваты серверы имен (ваш локальный сервер имен или

сервер удаленной системы), имя узла может быть неверным, или же воз-

никли неполадки в сети, разделяющей вашу систему и удаленный сервер.

Если известен IP-адрес удаленного узла, попробуйте выполнить для него

команду

ping.

Если удалось связаться с узлом по его IP-адресу, в сбоях ви-

новата служба имен. Воспользуйтесь nslookup или dig для тестирования