Сетевые соединения: наблюдение и исправление неполадок

Настройка клиента удаленного доступа

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

Если мы звоним на сервер удаленного доступа, организованный по типу 1, то options выглядит примерно так:

/dev/cuaa0
57600
crtscts
modem
debug
defaultroute
passive
-detach
lock
connect "chat -f /etc/ppp/chat.x"

Файл /etc/ppp/chat.x при этом должен быть примерно таким:

'' ATDT3258752 CONNECT \r name:-BREAK-name: pppfil ssword: e.67FGq1

Здесь в скрипте соединения указан номер телефона ( 3258752 ), по которому мы дозваниваемся. Это – телефон провайдера или сервера удаленного доступа в нашей организации (можно использовать PPP-соединения как для подключения к Интернету, так и для соединения двух площадок одной компании между собой). Помните, что команда ATDT означает тоновый набор, для набора в импульсном режиме, который обычно применяется на городских АТС в России, следует использовать команду ATDP. В данном примере предполагается, что имя пользователя для соединения с удаленным сервером – pppfil, а пароль (незашифрованный) – e.67FGq1.

Если сервер, на который мы звоним, организован по типу 2, то файл options выглядит примерно так:

/dev/cuaa0
57600
crtscts
modem
debug
defaultroute
passive
-detach
lock
user myname

Поскольку здесь мы явным образом указываем имя пользователя, которое следует использовать для аутентификации на удаленном сервере, в файле /etc/ppp/pap-secrets на нашем компьютере (который звонит удаленному серверу) должна быть строка

myname * mypassword *

Когда соединение с удаленной системой должно быть постоянным (например, нам нужно постоянное соединение с провайдером по модему), можно написать простой скрипт, который будет запускать pppd снова, если он почему-то завершится:

#!/bin/sh
while sleep 3
do
/usr/sbin/pppd
done

"Засыпание" на три секунды нужно на всякий случай – чтобы дать проблеме, из-за которой завершился pppd, время самоустраниться. Цикл бесконечный, прервать его можно только посылкой сигнала KILL. Такой цикл удобно оформить в виде скрипта, запускающегося при старте системы.

Вместо такого "вечного" цикла можно воспользоваться параметром demand. Он запускает дозвонку pppd по приходу пакета, который нужно отправить по dial-up каналу.

Кроме этого, надо помнить о возможности запускать pppd из файла /etc/inittab, указав тип запуска respawn (запустить заново в случае завершения). Нужно выбрать только один из рассмотренных способов поддержания постоянного соединения с помощью pppd – одновременно их использовать не следует во избежание путаницы и запуска "лишних" копий программы.

Производительность сети

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

Проблема: в сети все в порядке, кроме скорости

Бывает так: сеть в полном порядке, netstat бодро сообщает, что ошибок и коллизий не имеется, новенькое сетевое оборудование цинично смотрит на нас матовым боком, а скорость передачи через сеть оставляет желать лучшего. В этом, кроме оборудования, могут быть виноваты неверно настроенные драйверы (поглядите: вы ожидаете full-duplex на интерфейсе, но сообщает ли вам о нем ifconfig или коммутатор, в который воткнут ваш быстрый компьютер?) либо медленная дисковая подсистема получателя или отправителя данных.