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

Работоспособность сети

Проверка настроек: 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 такова: программа отправляет пакеты с адресом получателя, путь до которого мы хотим проследить. В поле TTL TTL - время жизни пакета, измеряется в секундах. Этот показатель определяет, какое максимальное время пакет может провести в очередях маршрутизаторов на отправку. В большинстве маршрутизаторов пакет не задерживается дольше чем на одну секунду, но согласно RFC791 маршрутизатор должен уменьшить TTL, проходящего через него пакета не менее чем на одну секунду, поэтому поле TTL фактически определяет максимально допустимое число пересылок пакета от одного маршрутизатора к другому. Такая пересылка называется "hop". IP-пакета для начала ставится число 1. В поле номера порта ставится номер заведомо неиспользуемого порта (обычно это большое число). Естественно, первый же маршрутизатор на пути пакета сообщает, что TTL пакета истекло. Ответ маршрутизатора учитывается и выводится на экран, а затем посылается пакет с TTL, равным двум. Ответ про истечение времени присылает следующий маршрутизатор по пути следования пакета, и так происходит до тех пор, пока пакет не дойдет до получателя. Когда это случится, сообщение об ошибке будет иным: "порт не обслуживается" (ведь порт специально задан таким, чтобы он не обслуживался).

Программа traceroute посылает три пакета с каждым из значений TTL, чтобы подсчитать среднее время прохождения пакета до каждого из промежуточных маршрутизаторов. Если ответ от какого-нибудь маршрутизатора не пришел за пять секунд, traceroute выводит звездочку (*) вместо времени ответа маршрутизатора, и это символизирует превышение тайм-аута.

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

Программа traceroute имеет ряд ключей для изменения параметров пересылаемых пакетов - смотрите man traceroute.

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

Безопасность системы в компьютерной сети

Безопасность в сети - это тема для отдельной книги или даже целого многотомника, поэтому здесь мы рассмотрим только основные аспекты, связанные с обеспечением безопасности систем Solaris в сети.

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

Что надо сделать, чтобы приблизиться к идеалу?

Для того чтобы все программы работали так, как вы ожидаете, следует:

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

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

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

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

Сетевые службы

Сетевые службы делятся на два типа: запускаемые в начале работы системы и запускаемые по запросу. Те, что запускаются в начале, обычно функционируют постоянно, до завершения работы системы или до аварийного завершения. К таким службам относятся все демоны с относительно высокой постоянной нагрузкой, которые должны давать быстрый ответ клиенту: почтовые серверы, 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 или коммутатор, к которому подсоединен ваш быстрый компьютер?) или медленная дисковая подсистема получателя или отправителя данных.