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

 

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

Работоспособность сети
Проверка настроек: ifconfig
Если вы не уверены в том, что сетевой интерфейс вашего компьютера работает или что он верно настроен, потребуйте эту информацию от ifconfig
ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu
8232 index 1 inet 127.0.0.1 netmask ff000000
elxl0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4>
mtu 1500 index 2 inet 192.168.5.33 netmask ffffff00
broadcast 192.168.5.255 ether 0:60:8:cb:3b:c0
elxl0:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,
IPv4> mtu 1500 index 2 inet 194.200.0.1
netmask ffffff00 broadcast 194.200.0.255

Обратите внимание: псевдонимы интерфейсов и интерфейсы, не являющиеся сетевыми адаптерами Ethernet, не имеют MAC-адреса.
Сетевые интерфейсы, от которых ожидается работа в данный момент, должны присутствовать, иметь корректные IP-адреса, маски и верные MAC-адреса (00:00:00:00:00 в поле MAC-адреса вывода ifconfig говорит о том, что драйвер сетевого адаптера не считал адрес или не нашел адаптер). Кроме того, работающий интерфейс обязан находиться в состоянии UP. Не забывайте давать команду
ifconfig имя_устройства plumb

для активизации интерфейса, если интерфейс добавлен вручную. Эта команда создает необходимые драйверу сетевого адаптера потоки для работы с TCP/IP и открывает доступ к устройству. До того, как будет дана эта команда, интерфейс не будет показан в выводе ifconfig -a, даже если драйвер и сетевой адаптер работают нормально.
Как узнать, работает ли ваша сеть? Попробуйте зайти по адресу www.playboy.com и сразу узнаете, есть ли доступ в Интернет. Лично я использую для проверки, есть ли связь с Сетью, менее одиозные сайты, например, домашнюю страницу главной финской сети FUNET. Это не так отвлекает от работы. В частности, потому, что на www.funet.fi почти все написано по-фински, а финский язык я знаю в объеме приветствий на вокзале. Может быть, стоит попробовать www.playboy.fi?
Проверка связи: ping
Для того чтобы выяснить, работает ли сеть в офисе, достаточно обратиться к соседнему компьютеру. А вдруг на нем нет web-сайта? Тогда на помощь приходит маленькая, но важная программа ping:
ping IP-address

Вместо IP-адреса можно использовать имя компьютера:
ping geba.urupinsk.ru

Программа ping посылает маленький (обычно - 56 байт) пакет указанному компьютеру, а тот должен ответить таким же пакетом. Наш компьютер измеряет время прохождения пакетов туда и обратно и показывает его. Некоторые версии ping, в том числе и ping в Solaris 9, по умолчанию сообщают не время прохождения пакета, а сам факт ответа ("host is alive"). Если все же требуется время прохождения, вызывайте ping с ключом s:
ping -s ftp.chg.ru
PING ftp.chg.ru: 56 data bytes
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=0. time=63. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=1. time=51. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=2. time=26. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=3. time=18. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=4. time=42. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=5. time=18. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=6. time=19. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=7. time=95. ms
64 bytes from ftp.chg.ru (193.233.9.194): icmp_seq=8. time=48. ms
^C
----ftp.chg.ru PING Statistics----
9 packets transmitted, 9 packets received, 0% packet loss
round-trip (ms) min/avg/max = 18/42/95

Если ping показывает, что пакеты не проходят, это может случиться по нескольким причинам. Иногда ping выдает однозначную диагностику, а иногда приходится прерывать его, т.к. программа замирает в ожидании ответа, который никак не приходит.
Диагностика host is down говорит о том, что маршрутизация пакетов до искомого компьютера работает, а сам компьютер - нет. Возможно, его выключили, отключили от компьютерной сети или перевели в однопользовательский режим для профилактики.
Диагностика no route to host показывает, что маршрутизация пакетов до адресата не работает. Возможной причиной может быть сбой в таблице маршрутизации вашего компьютера (например, отсутствует запись об основном шлюзе).
Проверка соответствия адресов: arp
Если попытка "пинговать" тот или иной адрес в локальной сети дает странные результаты, может пригодиться программа arp, которая показывает локальную таблицу соответствий MAC-адресов и IP-адресов в сети:
arp -a
Net to Media Table: IPv4
Device IP Address      Mask          Flags    Phys Addr
------ --------------- --------------- --- ---------------
elxl0 hp5l              255.255.255.255       00:50:ba:03:b6:47
elxl0 baclan.q.spb.ru 255.255.255.255     00:60:b0:3c:99:05
elxl0 ip-119.q.spb.ru 255.255.255.255     00:10:5a:72:dd:9c
elxl0 192.168.5.72     255.255.255.255     00:e0:29:9b:79:cd
elxl0 lib.q.spb.ru     255.255.255.255     00:e0:29:9e:f3:3b
elxl0 sunny            255.255.255.255 SP  00:60:08:cb:3b:c0
elxl0 192.168.5.11       255.255.255.255        00:e0:29:44:66:08
elxl0 mask.q.spb.ru    255.255.255.255     00:e0:29:48:63:64
elxl0 192.168.1.29     255.255.255.255     00:e0:b0:5a:66:90
elxl0 192.168.5.225    255.255.255.255     00:10:5a:73:6c:6b
elxl0 192.168.5.208    255.255.255.255     00:e0:29:64:9e:e7
elxl0 192.168.5.183    255.255.255.255     00:e0:29:61:29:42
elxl0 192.168.5.158    255.255.255.255     00:e0:29:64:8f:b9
elxl0 BASE-ADDRESS.MCAST.NET 240.0.0.0  SM    01:00:5e:00:00:00

Если сбой в arp-таблице произошел на компьютере, который является основным шлюзом для многих компьютеров в сети, то выход из сети может оказаться заблокированным для всех пакетов, которые пытаются выйти за пределы сети.
Проверка маршрутов: traceroute и route
Чтобы проследить путь, по которому пакет данных движется к месту назначения, проходя по дороге через маршрутизаторы, используют программу traceroute.
Она прослеживает весь путь пакета, при этом по умолчанию инспектируются и показываются не более чем тридцать "hop'ов". Hop (читается "хоп") - это один переход от одного сетевого интерфейса до другого. Если говорят, что до получателя - один hop, это значит, что в дороге пакет не пройдет ни через один маршрутизатор, выполнит только один переход - от отправителя к получателю:
traceroute to ftp.chg.ru (193.233.9.194), 64 hops max, 40 byte packets
1 gw-lost.nw.ru (195.19.204.65) 1.138 ms 1.083 ms 1.153 ms
2 vo-lergo.nw.ru (195.19.203.71) 1.589 ms 2.071 ms 1.734 ms
3 ing-e0.nw.ru  (195.19.194.68) 1.173 ms 0.920 ms 0.939 ms
4 msk-ix.nw.ru  (193.232.244.225) 11.615 ms 12.053 ms 12.310 ms
5 rbnet-ian.nw.ru (195.19.194.2) 13.991 ms 13.800 ms 11.989 ms
6 MSK-M9-RBNet-4.RBNet.ru (195.209.14.157) 12.579 ms 13.382 ms 12.549 ms
7 Moscow-BNS045-ATM4-0-2.free.net (147.45.20.33) 14.262 ms 14.077 ms 12.622 ms
8 Moscow-BNS042-Gig0-1-21.free.net (147.45.21.2) 13.695 ms 15.291 ms 13.944 ms
9 ftp.chg.ru  (193.233.9.194) 19.936 ms 20.208 ms 18.559 ms

Идея traceroute такова: программа отправляет пакеты с адресом получателя, путь до которого мы хотим проследить. В поле TTLIP-пакета для начала ставится число 1. В поле номера порта ставится номер заведомо неиспользуемого порта (обычно это большое число). Естественно, первый же маршрутизатор на пути пакета сообщает, что TTL пакета истекло. Ответ маршрутизатора учитывается и выводится на экран, а затем посылается пакет с TTL, равным двум. Ответ про истечение времени присылает следующий маршрутизатор по пути следования пакета, и так происходит до тех пор, пока пакет не дойдет до получателя. Когда это случится, сообщение об ошибке будет иным: "порт не обслуживается" (ведь порт специально задан таким, чтобы он не обслуживался).
Программа traceroute посылает три пакета с каждым из значений TTL, чтобы подсчитать среднее время прохождения пакета до каждого из промежуточных маршрутизаторов. Если ответ от какого-нибудь маршрутизатора не пришел за пять секунд, traceroute выводит звездочку (*) вместо времени ответа маршрутизатора, и это символизирует превышение тайм-аута.
Анализ маршрута пакета с помощью traceroute не всегда возможен, так как в некоторых сетях пересылка пакетов на нестандартные порты запрещена, а в некоторых - запрещена пересылка пакетов ICMP, в которые пакуются ответы маршрутизаторов типа "истекло TTL вашего пакета". Кроме того, пакеты разных типов могут проходить через маршрутизаторы по разным путям. Одинаковые пакеты могут быть направлены разными путями, в зависимости от загрузки сети. Поэтому маршрут пакета, показанный с помощью traceroute, верен только на момент выполнения этой программы. Вы можете применять traceroute и для проверки маршрутизации вашей сети. Например, если пакеты, предназначенные внешней сети, не отправляются на основной шлюз, а ищут другой путь (это будет видно посредством traceroute при попытке отследить путь пакета), то это верный признак сбоя в настройках.
Программа traceroute имеет ряд ключей для изменения параметров пересылаемых пакетов - смотрите man traceroute.
Для анализа и модификации локальной таблицы маршрутизации применяется программа route. В лекции 13 обсуждались ее синтаксис и воздействие на таблицу маршрутов в ядре. Используйте программу route для добавления статических маршрутов и внесения оперативных изменений в маршрутизацию через ваш компьютер, когда это необходимо.


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

Картина получилась идеальной. Если вы работаете в компании, где все происходит в точности так, как здесь описано, вы - счастливый человек!
Что надо сделать, чтобы приблизиться к идеалу?
Для того чтобы все программы работали так, как вы ожидаете, следует:

  1. регулярно следить за сообщениями о найденных в ПО уязвимостях. Для этого существует ряд списков рассылки, на которые вы можете подписаться совершенно бесплатно. Наиболее толковый вариант, по-моему, рассылка от CERT (Computer Emergency Response Team) - зайдите на www.cert.org и проверьте сами!
  2. всегда устанавливать рекомендованные рассылкой от CERT или производителем системы заплатки и обновления системы или отдельных программ; об установке программ в Solaris рассказывает лекция 12;
  3. строго следовать рекомендациям производителей программ, например, если сказано, что демона squid нельзя запускать от имени привилегированного пользователя root, то и не надо этого делать!

Ограничение набора служб, к которым можно обратиться, так же как и ограничение доступа к каждой службе в отдельности, мы рассмотрим ниже, в разделе "Ограничение доступа к сетевым службам". О протоколировании работы демонов заботятся программисты, которые их пишут, поэтому администратору надо знать лишь, где хранятся файлы протокола и к чему они относятся. Об этом говорится в лекции 16.
Применяйте только безопасные протоколы в сети, для этого:

  • вместо telnet всегда используйте secure shell (ssh);
  • используйте https вместо http там, где через web-интерфейс передаются конфиденциальные данные;
  • запрещайте на сервере протоколы, позволяющие узнавать информацию о вашей сети (например, finger);
  • пользуйтесь только теми программами, назначение которых вам известно.

Запретите всем пользователям системы (себе - тоже!):

  • передавать важные пароли открытым текстом через сеть;
  • сообщать кому-либо свой пароль в системе;
  • реагировать на провокационные сообщения по e-mail (мошенники уже пытались убедить вас в том, что вам нужно где-то перерегистрироваться и сообщить им свой пароль?);
  • оставлять свой пароль записанным на видном месте;
  • придумывать примитивные пароли.

Список глупостей можно продолжить, но мы ограничимся призывом вести себя осторожно: от нас зависит безопасность сетей в большом числе организаций!
Сетевые службы
Сетевые службы делятся на два типа: запускаемые в начале работы системы и запускаемые по запросу. Те, что запускаются в начале, обычно функционируют постоянно, до завершения работы системы или до аварийного завершения. К таким службам относятся все демоны с относительно высокой постоянной нагрузкой, которые должны давать быстрый ответ клиенту: почтовые серверы, web-серверы, демоны sshd и многие другие. К запускаемым по запросу относятся службы, которые нужны реже, и между скоростью доступа к ним и эффективностью использования ресурсов часто выбирается эффективность (незачем отнимать ресурсы у системы, запуская постоянно действующие, но редко требуемые процессы). К службам второго типа относятся telnetd, ftpd и другие.
Службы по запросу запускает демон inetd. При запуске или при получении сигнала SIGHUP он читает файл конфигурации /etc/inetd.conf, где определено, какие службы можно запускать по запросу, и какие программы при этом следует запускать.

Процесс inetd

Демон inetd выполняет функцию привратника: как только пакет приходит к воротам системы, inetd определяет, какой процесс надо запустить, чтобы пакет смог добраться по назначению - к этому процессу. Программа inetd сверяет номер порта назначения в пакете с номером порта назначения в файле /etc/inetd.conf - там этот номер в мнемоническом виде указан в первой колонке. Для выяснения соответствия между номерами портов и их мнемоническими обозначениями служит файл /etc/services. Ниже приводится сокращенный пример файла /etc/inetd.conf:

time  stream tcp6  nowait root  internal
time  dgram  udp6  wait  root  internal
# 
# Echo, discard, daytime, and chargen are used primarily for testing.
#
echo    stream  tcp6    nowait  root    internal
echo    dgram   udp6    wait    root    internal
discard        stream  tcp6    nowait  root    internal
discard        dgram   udp6    wait    root    internal
daytime        stream  tcp6    nowait  root    internal
daytime        dgram   udp6    wait    root    internal
chargen        stream  tcp6    nowait  root    internal
chargen        dgram   udp6    wait    root    internal
#
#
# RPC services syntax:
# <rpc_prog>/<vers> <endpoint-type> rpc/<proto> <flags> <user> \
# <pathname> <args>
#
# <endpoint-type> can be either "tli" or "stream" or "dgram".
# For "stream" and "dgram" assume that the endpoint is a 
# socket descriptor. <proto> can be either a nettype or a 
# netid or a "*". The value is first treated as a nettype. If
# it is not a valid nettype then it is treated as a netid. The
# "*" is a short-hand way of saying all the transports 
# supported by this system, ie. it equates to the "visible"
# nettype. The syntax for <proto> is:
#       *|<nettype|netid>|<nettype|netid>{[,<nettype|netid>]}
# For example: 
# dummy/1 tli rpc/circuit_v,udp wait root /tmp/test_svc test_svc
#
# Solstice system and network administration class agent server 
# 100232/10  tli  rpc/udp  wait  root  /usr/sbin/sadmind sadmind
#
# rpc.cmsd is a data base daemon which manages calendar 
# data backed by files in /var/spool/calendar
#
#
# Sun ToolTalk Database Server
#
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbse
#
# Sun KCMS Profile Server
#
100221/1 tli rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_server
#
# Sun Font Server
#
fs  stream  tcp  wait  nobody  /usr/openwin/lib/fs.auto   fs
#
# CacheFS Daemon
#
100235/1 tli rpc/ticotsord wait root /usr/lib/fs/cachefs/cachefsd cachefsd
100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd
# METAD - SLVM metadb Daemon
100229/1  tli rpc/tcp wait root /usr/sbin/rpc.metad rpc.metad
# METAMHD - SLVM HA Daemon
100230/1 tli rpc/tcp wait root /usr/sbin/rpc.metamhd rpc.metamhd
# METAMEDD - SLVM Mediator Daemon
100242/1 tli rpc/tcp wait root /usr/sbin/rpc.metamedd rpc.metamedd
# LPD - Print Protocol Adaptor (BSD listener)
printer stream tcp6 nowait root /usr/lib/print/in.lpd in.lpd
# RSHD - rsh daemon (BSD protocols)
shell  stream tcp   nowait root  /usr/sbin/in.rshd    in.rshd
shell  stream tcp6  nowait root  /usr/sbin/in.rshd    in.rshd
# RLOGIND - rlogin daemon (BSD protocols)
login stream tcp6 nowait root /usr/sbin/in.rlogind  in.rlogind
# REXECD - rexec daemon (BSD protocols)
exec  stream tcp   nowait root  /usr/sbin/in.rexecd in.rexecd
exec  stream tcp6  nowait root  /usr/sbin/in.rexecd in.rexecd
# COMSATD - comsat daemon (BSD protocols)
comsat dgram  udp   wait  root  /usr/sbin/in.comsat in.comsat
# TALKD - talk daemon (BSD protocols)
talk  dgram  udp   wait  root  /usr/sbin/in.talkd   in.talkd
# FINGERD - finger daemon
finger stream tcp6 nowait nobody /usr/sbin/in.fingerd in.fingerd
    

Ограничение доступа к сетевым службам
Для ограничения доступа к сетевым службам прежде всего следует отменить запуск всех служб, доступ к которым вы предоставлять не намерены. Для служб, запускаемых по запросу, это можно сделать, просто поставив знак комментария # (решетка) перед строкой, в которой указана соответствующая служба. Службы (демоны), запускаемые в начале работы системы, выключаются тоже довольно просто - достаточно удалить запускающий их скрипт из каталога /etc/rc?.d. Если они запускаются напрямую из /etc/inittab, закомментируйте соответствующую строку в этом файле.
После того, как мы гарантировали запуск только требуемых нам служб, приходит время определить специфические права доступа к этим службам. Мы можем ограничить доступ к ним из тех или иных источников. Можно сделать это посредством фильтра пакетов, как описано в лекции 13, либо внеся изменения в файл /etc/hosts.allow, в случае использования TCP wrapper - программы tcpd. Для включения механизма TCP wrapper при работе через inetd следует в файле /etc/default/inetd параметру ENABLE_TCPWRAPPERS присвоить значение YES (по умолчанию установлено NO, что означает "не использовать TCP wrapper>).
Производительность сети
Производительность сети в большей степени зависит от используемого сетевого оборудования, чем от настроек системы. Фактически, некоторую оптимизацию может дать изменение параметра MTU (maximum transmission unit) с помощью ifconfig, если трафик через сеть однороден и можно точно определить превалирующие размеры пакетов.
Однако с помощью ряда инструметов можно оценить, как идут дела в сети.
Используйте
netstat -i

для получения статистики по интерфейсам системы:
netstat -i
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
lo0 8232 loopback localhost 21456 0   21456          0       0       0
elxl0 1500 sunny       sunny   12728 0 2331           0       0       0

Проблема: много коллизий в сегменте
Если netstat сообщает о большом количестве коллизий на интерфейсе, это может говорить о перегрузке сегмента сети. Вспомните, не генерирует ли какая-нибудь программа излишний или паразитный трафик, нельзя ли избежать передачи каких-то данных через сеть? Для тщательного изучения ситуации пригодится программа tcpdump, которая выводит на экран (перенаправьте вывод в файл для последующего анализа!) заголовки каждого пакета, проходящего мимо вашего сетевого интерфейса. Большое число коллизий также может говорить о том, что давно пора сменить старый дешевый концентратор (hub) на новый коммутатор (switch) - ведь сегодня коммутатор стоит дешевле, чем концентратор в свое время!
Проблема: ошибки на интерфейсе
Некоторое число ошибок на интерфейсе допустимо, но если оно явно пропорционально трафику через интерфейс и превышает 1% от общего числа пересылок (это видно по выводу netstat), стоит изучить состояние кабелей. Может быть, на одном из них стоит стул? Или его жестоко зажали между стойками? Нет? Тогда наверное кто-то завязал на нем несколько узелков на память... Помните также, что плохо обжатые, небрежно подсоединенные или сильно запыленные вилки на кабеле, временные патч-корды, ставшие постоянными, также могут быть причиной проблем в сети. Значительное число ошибок на интерфейсе (10% и более) может сигнализировать о неисправности сетевого адаптера.
Проблема: в сети все в порядке, кроме скорости
Бывает и так: сеть в полном порядке, netstat бодро сообщает, что ошибок и коллизий не имеется, новенькое сетевое оборудование цинично смотрит на нас матовым боком, а скорость передачи через сеть оставляет желать лучшего. В этом, кроме оборудования, могут быть виноваты неверно настроенные драйверы (например, вы ожидаете full-duplex на интерфейсе, но сообщает ли вам о нем ifconfig или коммутатор, к которому подсоединен ваш быстрый компьютер?) или медленная дисковая подсистема получателя или отправителя данных.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика