Если вы не уверены, работает ли и верно ли настроен сетевой интерфейс вашего компьютера, потребуйте эту информацию от 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:
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, которая показывает локальную таблицу соответствий 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.
Она прослеживает весь путь пакета, но по умолчанию инспектируются и показываются не более чем тридцать " 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 такова: программа отправляет пакеты с адресом получателя, путь до которого мы хотим проследить. В поле
Когда это случится, сообщение об ошибке будет иным: "порт не обслуживается" (ведь порт специально задан таким, чтобы он не обслуживался).
Программа traceroute посылает три пакета с каждым из значений TTL, чтобы подсчитать среднее время прохождения пакета до каждого из промежуточных маршрутизаторов. Если ответ от какого-нибудь маршрутизатора не пришел за пять секунд, traceroute выводит звездочку ( * ) вместо времени ответа маршрутизатора, и это символизирует превышение тайм-аута.
Анализ маршрута пакета с помощью traceroute не всегда возможен, так как в некоторых сетях пересылка пакетов на нестандартные порты запрещена, а в некоторых – запрещена пересылка пакетов ICMP, в которые пакуются ответы маршрутизаторов типа "истекло TTL вашего пакета". Кроме того, пакеты разных типов могут проходить через маршрутизаторы по разным путям. Одинаковые пакеты могут быть направлены разными путями, в зависимости от загрузки сети. Поэтому маршрут пакета, показанный с помощью traceroute, верен только на момент выполнения этой программы. Вы можете применять traceroute и для проверки маршрутизации вашей сети. Например, если пакеты, предназначенные внешней сети, не отправляются на основной шлюз, а ищут другой путь (это будет видно traceroute при попытке отследить путь пакета), то это верный признак сбоя в настройках.
Программа traceroute имеет ряд ключей для изменения параметров пересылаемых пакетов – смотрите man traceroute.
Для анализа и модификации локальной таблицы маршрутизации применяется программа route. Выше, в лекции 3, обсуждались ее синтаксис и воздействие на таблицу маршрутов в ядре. Используйте программу route для добавления статических маршрутов и внесения оперативных изменений в маршрутизацию через ваш компьютер, когда это необходимо.
Безопасность в сети – это тема для отдельной книги или даже целого многотомника, поэтому здесь мы рассмотрим только основные аспекты, связанные с обеспечением безопасности систем Solaris в сети.
Безопасность системы в сети основывается на том, что:
Картина получилась идеальной. Если вы работаете в компании, где все происходит в точности так, как здесь описано, вы – счастливый человек!
Что надо сделать, чтобы приблизиться к идеалу?
Для того, чтобы все программы работали так, как вы ожидаете, следует:
root, то и не надо этого делать!Ограничение набора служб, к которым можно обратиться, также как и ограничение досутпа к каждой службе в отдельности, мы рассмотрим ниже, в разделе "ограничение доступа к сетевым службам". О протоколировании работы демонов заботятся программисты, которые их пишут, поэтому администратору надо знать лишь, где хранятся файлы протокола и к чему они относятся. Об этом рассказывает лекция 7.
Для того, чтобы использовать только безопасные протоколы в сети:
telnet всегда применяйте secure shell (ssh) ;finger );Запретите всем пользователям системы (себе – тоже!):
Список глупостей можно продолжить, но мы ограничимся призывом вести себя осторожно: от нас зависит безопасность сетей в большом числе организаций!
Сетевые службы делятся на два типа: запускаемые в начале работы системы и запускаемые по запросу. Те, что запускаются в начале работы, обычно работают постоянно, до завершения работы системы или до аварийного завершения. К таким службам относятся все демоны с относительно высокой постоянной нагрузкой, которые должны давать быстрый ответ клиенту: почтовые серверы, веб-серверы, демоны sshd и многие другие. К запускаемым по запросу относятся службы, которые нужны реже, и между скоростью доступа к ним и эффективностью использования ресурсов часто выбирается эффективность (что означает запуск по запросу – незачем отнимать ресурсы у системы, запуская постоянно действующие, но редко требуемые процессы). К службам второго типа относятся telnetd,
Службы по запросу запускает демон inetd. При запуске или при получении сигнала SIGHUP он читает файл конфигурации /etc/inetd.conf, где определено, какие службы можно запускать по запросу и какие программы при этом следует запускать.
Демон 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
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbse
rverd
#
# Sun KCMS Profile Server
#
100221/1 tli rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_ser
ver
#
# 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
dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd
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.meta
medd
# 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
# RSTATD - rstat daemon
rstatd/2-4 tli rpc/datagram_v wait root /usr/lib/netsvc/rstat/rp
c.rstatd rpc.rstatd
Для ограничения доступа к сетевым службам прежде всего следует отменить запуск всех служб, доступ к которым вы предоставлять не намерены. Для служб, запускаемых по запросу, это можно сделать, просто поставив знак комментария # (решетка) перед строкой, в которой указана соответствующая служба. Службы (демоны), запускаемые в начале работы системы, выключаются тоже довольно просто – достаточно удалить запускающий их скрипт из каталога /etc/rc?.d. Если они запускаются напрямую из /etc/inittab, закомментируйте соответствующую строку в этом файле.
В Solaris 10 и более новых версиях системы запретить службу еще проще – достаточно дать команду svcadm disable <имя_службы>.
После того, как мы гарантировали запуск только необходимых нам служб, приходит время определить специфические права доступа к этим службам. Мы можем ограничить доступ к ним из тех или иных источников. Можно сделать это посредством фильтра пакетов, как описано в лекции 3, либо внеся изменения в файл /etc/hosts.allow, в случае использования TCP wrapper'a – программы tcpd. Для включения механизма TCP wrapper'a при работе через inetd следует в файле /etc/default/inetd параметру ENABLE_TCPWRAPPERS присвоить значение YES (по умолчанию установлено NO, что означает "не использовать TCP wrapper").
Протокол PPP (Point-to-Point Protocol) был разработан для связи по последовательным каналам, таким, как коммутируемые телефонные каналы, соединения через последовательные порты и т.д. С помощью протокола PPP можно установить канал связи и передавать по нему пакеты любых протоколов – TCP/IP, IPX/SPX, NetBIOS. Нас в приложении к UNIX интересует настройка работы с TCP/IP поверх PPP.
Протокол PPP предполагет возможность выполнения следующих операций:
Для установления связи может потребоваться аутентификация, поэтому программы, работающие с PPP, должны уметь запрашивать и передавать аутентификационную информацию (имя и пароль, в некоторых случаях – зашифрованные).
Подробная документация по настройке PPP в Solaris 9 содержится, в частности, в документе "Solaris 9 System Administrator Collection >> System Administration Guide: Resource Management and Network Services" по адресу http://docs. sun.com/db/doc/806-4076?q=ppp, а обзор PPP в Solaris 9 имеется по адресу http://docs.sun.com/db/doc/806-4076/6jd6amr63?q=pppa=view
В системах Solaris начиная с Solaris 2.4 и до Solaris 8 включительно для обеспечения связи по протоколу PPP использовалась утилита aspppd, вызывавшая нарекания из-за сложности настройки и использования. В Solaris 9 она заменена на более стандартную и удобную программу
Сейчас для установления соединений через PPP в UNIX-системах используют сервер
Программа
При соединении двух компьютеров по протоколу PPP каждый из них рассматривается как равноправный участник соединения. Любой участник может предъявить к соединению свои требования: запросить определенный IP-адрес для себя или другого участника, потребовать аутентификацию и т.д. Если второй участник соглашается с требованием или его собственные требования не противоречат запрошенным, соединение устанавливается. Если требования участников противоречивы, то соединение не устанавливается.
Настройки программы /etc/ppp. Основные файлы настроек
Синтаксис вызова
pppd параметры
Параметры должны включать имя_устройства и скорость.
Имя устройства последовательного порта
В Solaris, как и в некоторых других системах UNIX, файл устройства, используемый для приема соединения через последовательный порт, и файл устройства, используемый для инициироваиня такого соединения, – это два разных файла. Входящие соединения принимаются устройствами /dev/ttyd*, а исходящие создаются через /dev/. Имя устройства, например, для входящих соединений через COM2, будет /dev/ttyd1 ( ttyd0 – COM1, ttyd1 – COM2), а для исходящих через COM2 – /dev/cua1.
Если Вы настраиваете сервер удаленного доступа, надо заранее записать в конфигурацию модема (т.е. в S0=1 и S1=1 для того, чтобы модем снимал трубку с первого звонка.
Для непосредственного общения с модемом удобно использовать простейшую терминальную программу cu:
cu –l /dev/cua1.
Если никакая программа не общается с /dev/cua1 в данный момент, то cu подключится к порту COM2. Теперь можно набирать команды модема: все, что будет набрано, попадет в последовательный порт. Для выхода из cu надо набрать ~. (тильда, затем точка) и подождать немного. Программа cu не умеет мгновенно отсоединяться.
Обращаться к устройствам напрямую с помощью cu может только root. Это умолчание можно изменить, установив нестандартные права доступа к файлам устройств /dev/ и /dev/ttyd*.
Параметры /etc/ppp/options. Если все ppp-сессии на сервере будут однотипными (одна скорость, соединение через один и тот же модем, звонки всегда только входящие), в этот файл можно записать все параметры /etc/passwd всем пользователям, которые используют этот сервер как сервер удаленного доступа.
cat /etc/ppp/options /dev/cuaa0 # устройство 57600 # скорость crtscts # управл. сигн. RTS/CTS modem # модем, использовать DTR debug # протоколирование сессии passive # устанавливать соед. и ждать* dns1 193.114.38.65 # установить DNS 193.114.38.5:193.114.38.4 #назначить адреса local:dialup** -detach # не уходить в background lock # блокировка порта по типу UUCP
Параметр debug включает протоколирование сессии. Программа syslog() все управляющие входящие и исходящие пакеты в удобочитаемой форме. Запись происходит от имени источника daemon с уровнем debug. Подробнее об источниках и уровнях записей в syslogd см. syslog.conf(4).
Параметр modem указывает, что нужно использовать сигналы управления модемом. Программа CD (connect-script, и "передергивает" (коротко выключает, затем включает) сигнал connect-script.
Если нужно установить индивидуальные настройки .ppprc, которые будут прочитаны демоном /etc/ppp/ options и могут содержать дополнительные сведения для него.
Выдача /etc/ppp/options.ttyd1. В каждом таком файле можно указать конкретный адрес удаленного клиента, и тот будет получать разные адреса при соединении с разными последовательными портами сервера. В то же время, каждому порту сервера и его удаленному клиенту на этом порте при такой настройке всегда будет соответствовать фиксированная пара адресов, жестко определенная для каждого последовательного порта сервера.
Кроме этого, можно вообще ничего не писать в /etc/ppp/options про назначение адресов. По умолчанию всем позвонившим на сервер удаленного доступа ppp0, ppp1 и т.д.
Приведенный пример предполагает, что пользователи при дозвонке на сервер удаленного доступа не применяют стандартный протокол аутентификации в Windows-системах, так называемый
Если требуется настроить аутентификацию с применением /etc/passwd, нужно записать в файл /etc/ppp/options параметр login. При этом пользователь, который соединяется с сервером удаленного доступа с использованием /etc/passwd, и в /etc/ppp/. Формат записей в последнем таков:
имя_клиента имя_сервера пароль IP-адрес
В каждом из полей может стоять *, обозначающая допустимость любого значения. Как правило, строка аутентификации в
ivan * KqZXV5-u *
Эта строка определяет имя и пароль пользователя ivan, которому разрешено соединяться с этим сервером.
В некоторых версиях login пароль, записанный в /etc/ppp/, сначала считается незашифрованным. Поэтому любой, прочтя этот файл, может ввести в строку пароля именно то, что записано в этом файле, и будет аутентифицирован.
Только во вторую очередь предполагается, что пароль там зашифрован. В таких /etc/ppp/options, что нужно считать пароль, записанный в
Есть, таким образом, две схемы организации сервера удаленного доступа.
getty (стандартная программа, обслуживающая вход на любой терминал, кроме login и password, которые пользователь сообщает вручную или с использованием скрипта на своей машине. Затем, уже после входа в систему, для пользователя запускается pppd /etc/passwd.ttymon на тот последовательный порт, где находится модем, напускается pppd pppd /etc/ppp/pap -secrets.Запуск ttymon для определенных терминалов контролируется в /etc/inittab в системах System V, включая Solaris. Старые версии Solaris и большинство других операционных систем используют программу getty вместо ttymon, в новых версиях Solaris программа getty может быть вызвана так же, поскольку файл getty здесь представляет собой символическую ссылку на ttymon.
Файл /etc/ppp/ может содержать как строки для аутентификации удаленных клиентов, так и строки, которые соответсвуют аутентификации самого user.
При настройке клиента удаленного доступа нужно добавить несколько строк в файл параметров, чтобы заставить
Если мы звоним на сервер удаленного доступа, организованный по типу 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/ на нашем компьютере (который звонит удаленному серверу) должна быть строка
myname * mypassword *
Когда соединение с удаленной системой должно быть постоянным (например, нам нужно постоянное соединение с провайдером по модему), можно написать простой скрипт, который будет запускать
#!/bin/sh while sleep 3 do /usr/sbin/pppd done
"Засыпание" на три секунды нужно на всякий случай – чтобы дать проблеме, из-за которой завершился KILL. Такой цикл удобно оформить в виде скрипта, запускающегося при старте системы.
Вместо такого "вечного" цикла можно воспользоваться параметром demand. Он запускает дозвонку
Кроме этого, надо помнить о возможности запускать /etc/inittab, указав тип запуска respawn (запустить заново в случае завершения). Нужно выбрать только один из рассмотренных способов поддержания постоянного соединения с помощью
Производительность сети в большей степени зависит от используемого сетевого оборудования, чем от настроек системы. Фактически, некоторую оптимизацию может дать изменение параметра 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 или коммутатор, в который воткнут ваш быстрый компьютер?) либо медленная дисковая подсистема получателя или отправителя данных.
Если вы не уверены, работает ли и верно ли настроен сетевой интерфейс вашего компьютера, потребуйте эту информацию от 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:
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, которая показывает локальную таблицу соответствий 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.
Она прослеживает весь путь пакета, но по умолчанию инспектируются и показываются не более чем тридцать " 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 такова: программа отправляет пакеты с адресом получателя, путь до которого мы хотим проследить. В поле
Когда это случится, сообщение об ошибке будет иным: "порт не обслуживается" (ведь порт специально задан таким, чтобы он не обслуживался).
Программа traceroute посылает три пакета с каждым из значений TTL, чтобы подсчитать среднее время прохождения пакета до каждого из промежуточных маршрутизаторов. Если ответ от какого-нибудь маршрутизатора не пришел за пять секунд, traceroute выводит звездочку ( * ) вместо времени ответа маршрутизатора, и это символизирует превышение тайм-аута.
Анализ маршрута пакета с помощью traceroute не всегда возможен, так как в некоторых сетях пересылка пакетов на нестандартные порты запрещена, а в некоторых – запрещена пересылка пакетов ICMP, в которые пакуются ответы маршрутизаторов типа "истекло TTL вашего пакета". Кроме того, пакеты разных типов могут проходить через маршрутизаторы по разным путям. Одинаковые пакеты могут быть направлены разными путями, в зависимости от загрузки сети. Поэтому маршрут пакета, показанный с помощью traceroute, верен только на момент выполнения этой программы. Вы можете применять traceroute и для проверки маршрутизации вашей сети. Например, если пакеты, предназначенные внешней сети, не отправляются на основной шлюз, а ищут другой путь (это будет видно traceroute при попытке отследить путь пакета), то это верный признак сбоя в настройках.
Программа traceroute имеет ряд ключей для изменения параметров пересылаемых пакетов – смотрите man traceroute.
Для анализа и модификации локальной таблицы маршрутизации применяется программа route. Выше, в лекции 3, обсуждались ее синтаксис и воздействие на таблицу маршрутов в ядре. Используйте программу route для добавления статических маршрутов и внесения оперативных изменений в маршрутизацию через ваш компьютер, когда это необходимо.
Безопасность в сети – это тема для отдельной книги или даже целого многотомника, поэтому здесь мы рассмотрим только основные аспекты, связанные с обеспечением безопасности систем Solaris в сети.
Безопасность системы в сети основывается на том, что:
Картина получилась идеальной. Если вы работаете в компании, где все происходит в точности так, как здесь описано, вы – счастливый человек!
Что надо сделать, чтобы приблизиться к идеалу?
Для того, чтобы все программы работали так, как вы ожидаете, следует:
root, то и не надо этого делать!Ограничение набора служб, к которым можно обратиться, также как и ограничение досутпа к каждой службе в отдельности, мы рассмотрим ниже, в разделе "ограничение доступа к сетевым службам". О протоколировании работы демонов заботятся программисты, которые их пишут, поэтому администратору надо знать лишь, где хранятся файлы протокола и к чему они относятся. Об этом рассказывает лекция 7.
Для того, чтобы использовать только безопасные протоколы в сети:
telnet всегда применяйте secure shell (ssh) ;finger );Запретите всем пользователям системы (себе – тоже!):
Список глупостей можно продолжить, но мы ограничимся призывом вести себя осторожно: от нас зависит безопасность сетей в большом числе организаций!
Сетевые службы делятся на два типа: запускаемые в начале работы системы и запускаемые по запросу. Те, что запускаются в начале работы, обычно работают постоянно, до завершения работы системы или до аварийного завершения. К таким службам относятся все демоны с относительно высокой постоянной нагрузкой, которые должны давать быстрый ответ клиенту: почтовые серверы, веб-серверы, демоны sshd и многие другие. К запускаемым по запросу относятся службы, которые нужны реже, и между скоростью доступа к ним и эффективностью использования ресурсов часто выбирается эффективность (что означает запуск по запросу – незачем отнимать ресурсы у системы, запуская постоянно действующие, но редко требуемые процессы). К службам второго типа относятся telnetd,
Службы по запросу запускает демон inetd. При запуске или при получении сигнала SIGHUP он читает файл конфигурации /etc/inetd.conf, где определено, какие службы можно запускать по запросу и какие программы при этом следует запускать.
Демон 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
100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd rpc.ttdbse
rverd
#
# Sun KCMS Profile Server
#
100221/1 tli rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_ser
ver
#
# 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
dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd
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.meta
medd
# 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
# RSTATD - rstat daemon
rstatd/2-4 tli rpc/datagram_v wait root /usr/lib/netsvc/rstat/rp
c.rstatd rpc.rstatd
Для ограничения доступа к сетевым службам прежде всего следует отменить запуск всех служб, доступ к которым вы предоставлять не намерены. Для служб, запускаемых по запросу, это можно сделать, просто поставив знак комментария # (решетка) перед строкой, в которой указана соответствующая служба. Службы (демоны), запускаемые в начале работы системы, выключаются тоже довольно просто – достаточно удалить запускающий их скрипт из каталога /etc/rc?.d. Если они запускаются напрямую из /etc/inittab, закомментируйте соответствующую строку в этом файле.
В Solaris 10 и более новых версиях системы запретить службу еще проще – достаточно дать команду svcadm disable <имя_службы>.
После того, как мы гарантировали запуск только необходимых нам служб, приходит время определить специфические права доступа к этим службам. Мы можем ограничить доступ к ним из тех или иных источников. Можно сделать это посредством фильтра пакетов, как описано в лекции 3, либо внеся изменения в файл /etc/hosts.allow, в случае использования TCP wrapper'a – программы tcpd. Для включения механизма TCP wrapper'a при работе через inetd следует в файле /etc/default/inetd параметру ENABLE_TCPWRAPPERS присвоить значение YES (по умолчанию установлено NO, что означает "не использовать TCP wrapper").
Протокол PPP (Point-to-Point Protocol) был разработан для связи по последовательным каналам, таким, как коммутируемые телефонные каналы, соединения через последовательные порты и т.д. С помощью протокола PPP можно установить канал связи и передавать по нему пакеты любых протоколов – TCP/IP, IPX/SPX, NetBIOS. Нас в приложении к UNIX интересует настройка работы с TCP/IP поверх PPP.
Протокол PPP предполагет возможность выполнения следующих операций:
Для установления связи может потребоваться аутентификация, поэтому программы, работающие с PPP, должны уметь запрашивать и передавать аутентификационную информацию (имя и пароль, в некоторых случаях – зашифрованные).
Подробная документация по настройке PPP в Solaris 9 содержится, в частности, в документе "Solaris 9 System Administrator Collection >> System Administration Guide: Resource Management and Network Services" по адресу http://docs. sun.com/db/doc/806-4076?q=ppp, а обзор PPP в Solaris 9 имеется по адресу http://docs.sun.com/db/doc/806-4076/6jd6amr63?q=pppa=view
В системах Solaris начиная с Solaris 2.4 и до Solaris 8 включительно для обеспечения связи по протоколу PPP использовалась утилита aspppd, вызывавшая нарекания из-за сложности настройки и использования. В Solaris 9 она заменена на более стандартную и удобную программу
Сейчас для установления соединений через PPP в UNIX-системах используют сервер
Программа
При соединении двух компьютеров по протоколу PPP каждый из них рассматривается как равноправный участник соединения. Любой участник может предъявить к соединению свои требования: запросить определенный IP-адрес для себя или другого участника, потребовать аутентификацию и т.д. Если второй участник соглашается с требованием или его собственные требования не противоречат запрошенным, соединение устанавливается. Если требования участников противоречивы, то соединение не устанавливается.
Настройки программы /etc/ppp. Основные файлы настроек
Синтаксис вызова
pppd параметры
Параметры должны включать имя_устройства и скорость.
Имя устройства последовательного порта
В Solaris, как и в некоторых других системах UNIX, файл устройства, используемый для приема соединения через последовательный порт, и файл устройства, используемый для инициироваиня такого соединения, – это два разных файла. Входящие соединения принимаются устройствами /dev/ttyd*, а исходящие создаются через /dev/. Имя устройства, например, для входящих соединений через COM2, будет /dev/ttyd1 ( ttyd0 – COM1, ttyd1 – COM2), а для исходящих через COM2 – /dev/cua1.
Если Вы настраиваете сервер удаленного доступа, надо заранее записать в конфигурацию модема (т.е. в S0=1 и S1=1 для того, чтобы модем снимал трубку с первого звонка.
Для непосредственного общения с модемом удобно использовать простейшую терминальную программу cu:
cu –l /dev/cua1.
Если никакая программа не общается с /dev/cua1 в данный момент, то cu подключится к порту COM2. Теперь можно набирать команды модема: все, что будет набрано, попадет в последовательный порт. Для выхода из cu надо набрать ~. (тильда, затем точка) и подождать немного. Программа cu не умеет мгновенно отсоединяться.
Обращаться к устройствам напрямую с помощью cu может только root. Это умолчание можно изменить, установив нестандартные права доступа к файлам устройств /dev/ и /dev/ttyd*.
Параметры /etc/ppp/options. Если все ppp-сессии на сервере будут однотипными (одна скорость, соединение через один и тот же модем, звонки всегда только входящие), в этот файл можно записать все параметры /etc/passwd всем пользователям, которые используют этот сервер как сервер удаленного доступа.
cat /etc/ppp/options /dev/cuaa0 # устройство 57600 # скорость crtscts # управл. сигн. RTS/CTS modem # модем, использовать DTR debug # протоколирование сессии passive # устанавливать соед. и ждать* dns1 193.114.38.65 # установить DNS 193.114.38.5:193.114.38.4 #назначить адреса local:dialup** -detach # не уходить в background lock # блокировка порта по типу UUCP
Параметр debug включает протоколирование сессии. Программа syslog() все управляющие входящие и исходящие пакеты в удобочитаемой форме. Запись происходит от имени источника daemon с уровнем debug. Подробнее об источниках и уровнях записей в syslogd см. syslog.conf(4).
Параметр modem указывает, что нужно использовать сигналы управления модемом. Программа CD (connect-script, и "передергивает" (коротко выключает, затем включает) сигнал connect-script.
Если нужно установить индивидуальные настройки .ppprc, которые будут прочитаны демоном /etc/ppp/ options и могут содержать дополнительные сведения для него.
Выдача /etc/ppp/options.ttyd1. В каждом таком файле можно указать конкретный адрес удаленного клиента, и тот будет получать разные адреса при соединении с разными последовательными портами сервера. В то же время, каждому порту сервера и его удаленному клиенту на этом порте при такой настройке всегда будет соответствовать фиксированная пара адресов, жестко определенная для каждого последовательного порта сервера.
Кроме этого, можно вообще ничего не писать в /etc/ppp/options про назначение адресов. По умолчанию всем позвонившим на сервер удаленного доступа ppp0, ppp1 и т.д.
Приведенный пример предполагает, что пользователи при дозвонке на сервер удаленного доступа не применяют стандартный протокол аутентификации в Windows-системах, так называемый
Если требуется настроить аутентификацию с применением /etc/passwd, нужно записать в файл /etc/ppp/options параметр login. При этом пользователь, который соединяется с сервером удаленного доступа с использованием /etc/passwd, и в /etc/ppp/. Формат записей в последнем таков:
имя_клиента имя_сервера пароль IP-адрес
В каждом из полей может стоять *, обозначающая допустимость любого значения. Как правило, строка аутентификации в
ivan * KqZXV5-u *
Эта строка определяет имя и пароль пользователя ivan, которому разрешено соединяться с этим сервером.
В некоторых версиях login пароль, записанный в /etc/ppp/, сначала считается незашифрованным. Поэтому любой, прочтя этот файл, может ввести в строку пароля именно то, что записано в этом файле, и будет аутентифицирован.
Только во вторую очередь предполагается, что пароль там зашифрован. В таких /etc/ppp/options, что нужно считать пароль, записанный в
Есть, таким образом, две схемы организации сервера удаленного доступа.
getty (стандартная программа, обслуживающая вход на любой терминал, кроме login и password, которые пользователь сообщает вручную или с использованием скрипта на своей машине. Затем, уже после входа в систему, для пользователя запускается pppd /etc/passwd.ttymon на тот последовательный порт, где находится модем, напускается pppd pppd /etc/ppp/pap -secrets.Запуск ttymon для определенных терминалов контролируется в /etc/inittab в системах System V, включая Solaris. Старые версии Solaris и большинство других операционных систем используют программу getty вместо ttymon, в новых версиях Solaris программа getty может быть вызвана так же, поскольку файл getty здесь представляет собой символическую ссылку на ttymon.
Файл /etc/ppp/ может содержать как строки для аутентификации удаленных клиентов, так и строки, которые соответсвуют аутентификации самого user.
При настройке клиента удаленного доступа нужно добавить несколько строк в файл параметров, чтобы заставить
Если мы звоним на сервер удаленного доступа, организованный по типу 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/ на нашем компьютере (который звонит удаленному серверу) должна быть строка
myname * mypassword *
Когда соединение с удаленной системой должно быть постоянным (например, нам нужно постоянное соединение с провайдером по модему), можно написать простой скрипт, который будет запускать
#!/bin/sh while sleep 3 do /usr/sbin/pppd done
"Засыпание" на три секунды нужно на всякий случай – чтобы дать проблеме, из-за которой завершился KILL. Такой цикл удобно оформить в виде скрипта, запускающегося при старте системы.
Вместо такого "вечного" цикла можно воспользоваться параметром demand. Он запускает дозвонку
Кроме этого, надо помнить о возможности запускать /etc/inittab, указав тип запуска respawn (запустить заново в случае завершения). Нужно выбрать только один из рассмотренных способов поддержания постоянного соединения с помощью
Производительность сети в большей степени зависит от используемого сетевого оборудования, чем от настроек системы. Фактически, некоторую оптимизацию может дать изменение параметра 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 или коммутатор, в который воткнут ваш быстрый компьютер?) либо медленная дисковая подсистема получателя или отправителя данных.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.