Для чого потрібний файл networks у windows. Що має бути у файлі networks

Доброго часу, шановні читачі. Публікую другу частину. У поточній частині основний упор зроблено на реалізацію мережі в Linux(як налаштувати мережу на Linux, як продіагностувати мережу на Linux і підтримувати в робочому стані мережну підсистему на Linux).

Налаштування TCP/IP у Linux для роботи в мережі Ethernet

Для роботи з мережними протоколами TCP/IP в Linux достатньо лише петльового інтерфейсуАле якщо необхідно об'єднати хости між собою, природно, необхідна наявність мережного інтерфейсу, каналів передачі даних (наприклад кручена пара), можливо, будь-якого мережного обладнання. Також, необхідна наявність встановлених ( , та інших.), зазвичай поставляються в . Також потрібна наявність для мережі (наприклад /etc/hosts) та підтримку мережі .

Параметри мережі

Почнемо розуміння мережевих механізмів Linux з ручного конфігурування мережі, тобто з нагоди, коли IP адресамережного інтерфейсу статичний. Отже, при налаштуванні мережі необхідно врахувати і налаштувати наступні параметри:

IP-адреса- як уже говорилося в першій частині статті – це унікальна адреса машини, у форматі чотирьох десяткових чисел, розділених крапками. Зазвичай, під час роботи у локальній мережі, вибирається із приватних діапазонів, наприклад: 192.168.0.1

Маска підмережі- так само, 4 десяткові числа, що визначають, яка частина адреси ставитися до адреси мережі/підмережі, а яка до адреси хоста. Маска підмережі є числом, яке складається (у двійковій формі) за допомогою логічного І, з IP-адресою і внаслідок чого з'ясовується, до якої підмережі належить адреса. Наприклад, адреса 192.168.0.2 з маскою 255.255.255.0 належить підмережі 192.168.0.

Адреса підмережі- Визначається маскою підмережі. При цьому для петлевих інтерфейсів не існує підмереж.

Широкомовна адреса- адреса, яка використовується для відправлення широкомовних пакетів, які отримають усі хости підмережі. Зазвичай він дорівнює адресі підмережі зі значенням хоста 255, тобто для підмережі 192.168.0 широкомовним буде 192.168.0.255, аналогічно, для підмережі 192.168 широкомовним буде 192.168.255.255. Для петлевих інтерфейсів немає широкомовного адреси.

IP адреса шлюзу- Це адреса машини, що є шлюзом за умовчанням для зв'язку із зовнішнім світом. Шлюзів може бути кілька, якщо комп'ютер підключено до кількох мереж одночасно. Адреса шлюзу не використовується в ізольованих мережах (не підключених до глобальної мережі), тому що даним мережам нікуди відправляти пакети поза мережею, те саме ставитися і до петлевих інтерфейсів.

IP-адреса сервера імен (DNS - сервера)- адреса сервера, що перетворює імена хостів в IP адреси. Зазвичай надається провайдером.

Файли налаштувань мережі у Linux (конфігураційні файли)

Для розуміння роботи мережі в Linux, я обов'язково порадив би ознайомитися зі статтею " ". В цілому, вся робота Linux заснована на , який народжується при завантаженні ОС і плодить своїх нащадків, які в свою чергу і виконують всю необхідну роботу, запуск bash або демона. Так, і все завантаження Linux заснована на , в яких прописана вся послідовність запуску дрібних утиліт з різними параметрами, які послідовно запускаються/зупиняються під час запуску/зупинки системи. Аналогічно запускається мережна підсистема Linux.

Кожен дистрибутив Linux має злегка відрізняється від інших механізм ініціалізації мережі, але загальна картина, гадаю, після прочитання буде зрозуміла. Якщо переглянути стартові скрипти мережевої підсистеми будь-якого дистрибутива Linux, то, як налаштувати конфігурацію мережі за допомогою конфігураційних файлів, стане більш-менш зрозумілим, наприклад у Debian (за основу візьмемо цей дистрибутив) за ініціалізацію мережі відповідає скрипт /etc/init.d/networking, переглянувши який:

Net-server:~#cat /etc/init.d/networking #!/bin/sh -e ### BEGIN INIT INFO # Provides: networking # Required-Start:mountkernfs -Start: ifupdown # Should-Stop: ifupdown # Default-Start: S # Default-Stop: 0 6 # Short-Description: Raise network interfaces. ### END INIT INFO PATH = "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin" [ -x /sbin/ifup ] || exit 0 . /lib/lsb/init-functions process_options() ( [ -e /etc/network/options ] || ) check_network_file_systems() ( [ -e /proc/mounts ] ||<&0 < /proc/mounts while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network devices still mounted." exit 0 ;; esac case $FSTYPE in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs) log_warning_msg "not deconfiguring network interfaces: network file systems still mounted." exit 0 ;; esac done exec 0<&9 9<&- } check_network_swap() { [ -e /proc/swaps ] || return 0 exec 9<&0 < /proc/swaps while read DEV MTPT FSTYPE REST; do case $DEV in /dev/nbd*|/dev/nd*|/dev/etherd/e*) log_warning_msg "not deconfiguring network interfaces: network swap still mounted." exit 0 ;; esac done exec 0<&9 9<&- } case "$1" in start) process_options log_action_begin_msg "Configuring network interfaces" if ifup -a; then log_action_end_msg $? else log_action_end_msg $? fi ;; stop) check_network_file_systems check_network_swap log_action_begin_msg "Deconfiguring network interfaces" if ifdown -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; force-reload|restart) process_options log_warning_msg "Running $0 $1 is deprecated because it may not enable again some interfaces" log_action_begin_msg "Reconfiguring network interfaces" ifdown -a --exclude=lo || true if ifup -a --exclude=lo; then log_action_end_msg $? else log_action_end_msg $? fi ;; *) echo "Usage: /etc/init.d/networking {start|stop}" exit 1 ;; esac exit 0

можна знайти кілька функцій, які перевіряють наявність підключених мережевих файлових систем ( check_network_file_systems(), check_network_swap()), а також перевірку існування якогось поки що незрозумілого конфігу /etc/network/options (функція process_options()), а в самому низу, конструкцією case "$1" inі відповідно до введеного параметра (start/stop/force-reload|restart або будь-яке дуге) робить певні дії. З цих самих " певних дій", з прикладу аргументу start видно, що спочатку запускається функція process_options, далі відправляється в лог фраза Configuring network interfaces, і запускається команда ifup -a. Якщо подивитися man ifup , то видно, що дана команда читає конфіг з файлу /etc/network/interfacesі згідно з ключем -aзапускає всі інтерфейси, що мають параметр auto.

ifup and ifdown commands можуть бути використані для configure (або, respectively, deconfigure) мережевих interfaces, базованих на interface definitions в файлі /etc/network/interfaces.

-a, --all
Якщо ведеться до, якщо всі interfaces marked auto. Interfaces є brought up in the order in which they are defined in /etc/network/interfaces. Якщо ведеться доки не з'явиться, впливає на всі визначені interfaces. Interfaces є brought down in the order in which they are currently listed in the state file. Лише interfaces defined in /etc/network/interfaces will be brought down.

ip-server:~# cat /etc/network/interfaces # Цей файл наведено на веб-сторінках доступних на вашій системі # і як вона буде активована. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet dhcp allow-hotplug eth2 iface eth2 inet static address broadcast 192.168.1.255

У цьому конфізі рядки allow-hotplugі auto- це синоніми та інтерфейси будуть підняті за командою ifup -a. Ось, власне, і весь ланцюг роботи мережевої підсистеми. Аналогічно, в інших дистрибутивах: у RedHat та SUSE мережа запускається скриптом /etc/init.d/network. Розглянувши його, можна знайти, де лежить конфігурація мережі.

/etc/hosts

Цей файл зберігає список IP адресі відповідних їм (адрес) імен хостів.Формат файлу нічим не відрізняється від мастдайного:

Ip-server:~# cat /etc/hosts # ip host.in.domain host 127.0.0.1 localhost 127.0.1.1 ip-server.domain.local ip-server 192.168.1.1 ip-server.domain.local ip-server

Історично цей файл використовувався замість DNS. В даний час файл також може використовуватися замість служби DNS, але тільки за умови, що у вашій мережі кількість машин вимірюється в одиницях, а не в десятках або сотнях, тому що в такому випадку доведеться контролювати коректність даного файлу на кожній машині.

/etc/hostname

Цей файл містить NetBIOS-ім'я хоста:

Ip-server:~# cat /etc/hostname ip-server

Цей файл зберігає імена та адреси локальної та інших мереж. Приклад:

Ip-server:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 home-network 192.168.1.0

При використанні цього файлу, мережами можна керувати на ім'я. Наприклад, додати маршрут не route add 192.168.1.12 , а route add.

/etc/nsswitch.conf

Файл визначає порядок пошуку імені хоста/мережі, за дане налаштування відповідають рядки:

Для хостів: hosts: files dns Для мереж: networks: files

Параметр files вказує використовувати вказані файли (/etc/hostsі /etc/networksвідповідно), параметр dns вказує використовувати службу dns.

/etc/host.conf

Файл визначає параметри дозволу імен для резолвера

Ip-server:~# cat /etc/host.conf multi on

Цей файл вказує бібліотеці resolv - повертати всі допустимі адреси вузла, які зустрілися у файлі /etc/hosts, а не лише першу з них.

/etc/resolv.conf

Цей фал визначає параметри механізму перетворення мережевих імен IP адреси. Простою мовою, визначає налаштування DNS. Приклад:

IP-сервер:~# cat /etc/resolv.conf nameserver 10.0.0.4 nameserver 10.0.0.1 search domain.local

Перші 2 рядки вказують сервера DNS. Третій рядок вказує домени пошуку. Якщо при дозволі імені, ім'я не буде FQDN-іменем, то цей домен підставиться у вигляді "закінчення". Наприклад при виконанні команди ping host адреса, що прингується, перетворюється на host.domain.local. Інші параметри можна почитати в man resolv.conf. Дуже часто, в Linux використовується динамічна генерація файлу, за допомогою т.зв. програми /sbin/resolvconf.Ця програма є посередником між службами, що динамічно надають сервера імен (наприклад DHCP client) та службами, які використовують дані сервера імен. Для того щоб використовувати файл, що динамічно генерується /etc/resolv.conf, необхідно зробити цей файл символічним посиланням на /etc/resolvconf/run/resolv.conf. У деяких дистрибутивах шлях може бути іншим, про це обов'язково буде написано в man resolvconf.

Налаштування мережі

Ознайомившись з основними файлами конфігурації, можна подивитися на . Вище вже говорилося про команду ifup, ifdown, але ці кошти не зовсім універсальні, допустимо в дистрибутивах RH даних команд за замовчуванням немає. Крім того, в нових дистрибутивах з'явився новий високорівневий засіб управління мережею, яка належить пакету iproute. Йому (пакету iproute) я присвячу. А в поточному посту я його не розглядатиму. Команди, описані нижче належать .

Отже, щоб бути впевненим у працездатності команди у будь-якому дистрибутиві Linux, необхідно користуватися двома основними командами-старичками. Це , та arp. Перша команда ( відповідає за налаштування мережевих інтерфейсів(ip, маска, шлюз), друга () - налаштування маршрутизації, третя (arp) - управління arp-таблицею. Хочеться зауважити, що виконання даних команд без відключення стандартного скрипту запуску SystemV мережної підсистеми внесе зміни лише до першого перезавантаження/перезапуску мережевої служби, т.к. якщо розкинути мізками, то можна зрозуміти, що скрипт /etc/init.d/networkingпри черговому запуску перечитає вказані вище конфіги та застосує старі налаштування. Відповідно, вихід для постійної установки налаштувань - або команда ifconfig з відповідними параметрами - вписати в або поправити руками відповідні конфіги мережевих інтерфейсів.

Так само, якщо виконується команда ifconfig з відсутніми параметрами(наприклад лише IP адреса), то інші доповнюються автоматично (наприклад, бродкаст адреса додається за замовчуванням з хостовою адресою, що закінчується на 255 і маска підмережі за замовчуванням береться 255.255.255.0).

Маршрутизаціядля наявних інтерфейсів у сучасних ядрах завжди автоматично піднімається силами ядра. Точніше сказати, прямі маршрути в мережу згідно з налаштуваннями IP і підмережі, в яку дивиться піднятий інтерфейс формуються автоматично, силами ядра. Поле gateway (шлюз) для таких записів показує адресу вихідного інтерфейсу або *. У старих версіях ядра (номер ядра з якого маршрути стали підніматися автоматично - не підкажу) необхідно було додавати маршрут вручну.

Якщо є необхідність організувати свої маршрути, необхідно скористатися . Даною командою можна додавати та видаляти маршрути, але знову ж таки, це допоможе тільки до перезапуску /etc/init.d/networking (або іншого скрипту, що відповідає за мережу у Вашому дистрибутиві). Щоб маршрути додавалися автоматично, необхідно так само, як і з командою ifconfig - додати команди додавання маршрутів до rc.local, або поправити руками відповідні конфіги мережевих інтерфейсів (наприклад, Deb - /etc/network/options).

За якими правилами формуються маршрути до мереж, я в

Діагностика мережі Linux

Існує велика кількість інструментів діагностики мережі в Linux, часто вони дуже схожі на утиліти від Microsoft. Я розгляну три основні утиліти діагностики мережі, без яких виявити неполадки буде проблематично.

Думаю, що дана утиліта знайома чи не кожному. Робота цієї утиліти полягає в відправціт.зв. пакетів ICMPвіддаленому серверу, який буде вказано у параметрах команди, сервер повертає відправлені команди, а pingпідраховує часпотрібне відправленому пакету, щоб дійти до сервера та повернутися. Наприклад:

# ping ya.ru PING ya.ru (87.250.251.3) 56(84) bytes of data. 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=1 ttl=57 time=42.7 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=2 ttl=42 time= from www.yandex.ru (87.250.251.3): icmp_seq=3 ttl=57 time=42.5 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq=4 ttl=57 time=42.5 .yandex.ru (87.250.251.3): icmp_seq=5 ttl=57 time=41.9 ms ^C --- ya.ru ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min/ avg/max/mdev = 41.922/42.588/43.255/0.500 ms

Як видно, з наведеного прикладу, pingвиводить нам купу корисної інформації. Насамперед, ми з'ясували, що можемо встановити з'єднання з хостом ya.ru(Іноді кажуть, що "хост ya.ru нам доступний"). По-друге, ми бачимо, що DNS працює коректно, тому що "пінговане" ім'я було коректно перетворено на IP адресу (PING ya.ru (87.250.251.3)). Далі, в полі icmp_seq= вказана нумерація пакетів, що відправляються. Кожному пакету, що відправляється, послідовно присвоюється номер і якщо в даній нумерації будуть "провали", то це нам розповість про те, що з'єднання з "пінгованим" нестійке, а так само може означати, що сервер, якому шлють пакети перевантажений. За значенням time=ми бачимо, скільки часу пакет мандрувавдо 87.250.251.3 та назад. Зупинити роботу утиліти ping можна клавішами Ctrl+C.

Так само, утиліта pingцікава тим, що може дозволити побачити, де виникли проблеми. Припустимо, утиліта pingвиводить повідомлення network not reachable (мережа недоступна)або інше аналогічне повідомлення. Це, швидше за все, говорить про некоректне налаштування вашої системи. У такому випадку можна надіслати пакети за IP-адресою провайдера, щоб зрозуміти, де виникає проблема (між локальним ПК або "далі"). Якщо Ви підключені до Інтернету через маршрутизатор, можна надіслати пакети по його IP. Відповідно, якщо проблема проявитися вже на цьому етапі, це говорить про неправильне конфігурування локальної системи, або про пошкодження кабелю, якщо маршрутизатор відгукується, а сервер провайдера немає, то проблема - в каналі зв'язку провайдера і т.д. Нарешті, якщо невдачею завершилося перетворення імені в IP, можна перевірити зв'язок з IP, якщо відповіді будуть надходити коректно, можна здогадатися, що у DNS.

Слід зазначити, що ця утиліта не завжди надійний інструмент для діагностики. Видалений сервер може блокувати відповіді на запити ICMP.

traceroute

Простою мовою, команда називається трасування маршруту. Як можна зрозуміти з назви - дана утиліта покаже яким маршрутом йшли пакети до хоста. Утиліта tracerouteдещо схожа на pingале відображає більше цікавої інформації. Приклад:

# traceroute ya.ru traceroute to ya.ru (213.180.204.3), 30 hops max, 60 byte packets 1 243-083-free.kubtelecom.ru (213.132.83.243) 6.408 ms 6.306 .kubtelecom.ru (213.132.64.65) 2.761 ms 5.787 ms 5.777 ms 3 lgw.kubtelecom.ru (213.132.75.54) 5.713 ms 5.701 ms 5.636 94.186.6.177) 81.430 ms 81.581 ms 81.687 ms 5 cat26.Moscow.gldn.net (194.186.10.118) 47.789 ms 47.888 ms 48.011 ms 6 213.33.201.230 (213.33.2 4) 41.106 ms 7 carmine-red-vlan602.yandex.net (87.250. 242.206) 41.199 ms 42.578 ms 42.610 ms 8 www.yandex.ru (213.180.204.3) 43.185 ms 42.126 ms 42.679 ms

Як видно, можна простежити маршрут від маршрутизатора провайдера 243-083-free.kubtelecom.ru (213.132.83.243) (Південь Росії) до кінцевого хоста в www.yandex.ru (213.180.204.3) у Москві.

dig

Ця утиліта надсилає запити серверам DNS та повертає інформацію про заданий домен. Приклад:

#[email protected] roboti.ru;<<>> DiG 9.3.6-P1<<>> @ns.kuban.ru roboti.ru; (1 server found);; Global options: printcmd;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64412 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;roboti.ru. IN A ;; ANSWER SECTION: roboti.ru. 448 IN A 72.52.4.90 ;; AUTHORITY SECTION: roboti.ru. 345448 IN NS ns1.sedoparking.com. roboti.ru. 345448 IN NS ns2.sedoparking.com. ;; Query time: 102 msec ;; SERVER: 62.183.1.244#53(62.183.1.244) ;; WHEN: Thu Feb 17 19:44:59 2011 ;; MSG SIZE rcvd: 94

Команда digнадіслала запит серверу DNS - ns.kuban.ru (@ns.kuban.ru- цей параметр вказувати не обов'язково, у такому разі джерелом інформації про DNS буде взято сервер з налаштування вашої системи) про доменне ім'я roboti.ru. В результаті чого отримала відповідь, в якій ми можемо побачити в розділі ANSWER SECTIONінформацію про IP адреси домену, у розділі AUTHORITY SECTIONінформацію про т.зв. авторитетних серверів DNS. Третій рядок знизу говорить про те, який сервер надав відповідь.

Інші утиліти діагностики

ping, dig та інші утиліти діагностики з параметрами можна знайти в пості .

Підключення нової мережної карти

Підключення та запуск нової мережної карти зводиться до виконання кількох кроків:

1. Фізичне підключення картки

3. Перегляд виводу на виявлення нової мережевої карти:

Подивимося висновок ДО підключення нової картки:

Server:~# dmesg | grep eth [ 4.720550] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.130191] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network 2: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [15.681056] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps

у висновку видно, що в системі є 2 мережні карти eth1 та eth2. Підключаємо третю і дивимося висновок:

Server:~# dmesg | grep eth [ 4.720513] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 5.132029] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network : e1000_probe: Intel(R ) PRO/1000 Network Connection [ 39.274875] udev: renamed network interface eth2 to eth3 [ 39.287661] udev: renamed network interface eth1_rename_ren to eth2 [ 45.670744] e0 Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 46.237232] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 96.977468] E1000: eth3: e1000_p Flow Control: RX

У dmesgми бачимо, що з'явилася нова мережа - eth3, яка насправді - eth2, але перейменована менеджером пристроїв udev на eth3, а eth2 - це насправді перейменована eth1 (про udev ми поговоримо в окремому пості). Поява нашої нової мережевої в dmesgнам каже, що мережева карта підтримуєтьсяядром та коректно визначилася. Залишилася справа за малим - налаштувати новий інтерфейс у /etc/network/interfaces(Debian), тому що ця карта не була ініціалізована стартовим скриптом /etc/init.d/network. ifconfigцю карту бачить:

Server:~# ifconfig eth3 eth3 Link encap:Ethernet HWaddr 08:00:27:5f:34:ad inet6 addr: fe80::a00:27ff:fe5f:34ad/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1 1 RX packets:311847 errors:0 dropped:0 overruns:0 frame:0 TX packets:126 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:104670651 (99.8 MiB) 16184 (15.8 KiB)

але знову ж таки - не конфігурує. Як конфігурувати мережеву карту говорилося вище.

Резюме

Думаю, на сьогодні це все. Коли почав писати цю статтю, думав, що впишуся в один пост, але він вийшов величезний. Тому було вирішено розбити статтю на дві. Разом, я постарався викласти не покрокове хауту з налаштування мережі, а викласти принцип і пояснити розуміння того, як же запускається і працює мережа в Linux. Дуже сподіваюся, що це мені вдалося. Буду радий вашим коментарям та доповненням. Згодом статтю доповнюватиму.

Після того, як Ви розділили на підмережі свою мережу, Ви повинні підготуватися до простого пошуку адреси на ім'я, яке використовує файл /etc/hosts . Якщо Ви не збираєтеся використовувати DNS або NIS для цього, Ви повинні розміщувати всі хости у файлі hosts .

Навіть якщо Ви хочете використовувати DNS або NIS, можна мати деяке підмножина імен та /etc/hosts . Наприклад, якщо Ви хочете мати певний вид пошуку на ім'я навіть, коли мережні інтерфейси не запущені, наприклад, під час завантаження. Це не тільки питання зручності, але також дозволяє використовувати символічні імена хостів у скриптах rc . Таким чином, при зміні IP-адрес, Ви повинні тільки копіювати оновлений файл hosts на всі машини замість того, щоб редагувати велику кількість файлів rc . Зазвичай Ви будете розміщувати всі локальні імена та адреси в hosts додаванням їх на будь-який gateway та NIS-сервер, якщо вони використовуються.

Також під час перевірки Ви повинні переконатися, що сервер імен використовує інформацію лише з файлу hosts . Програмне забезпечення DNS або NIS може мати прикладні файли, які можуть дати дивні результати при їх використанні. Щоб змусити всі програми використовувати виключно /etc/hosts під час пошуку IP-адреси хоста, потрібно відредагувати файл /etc/host.conf . Закоментуйте всі рядки, що починаються з ключового слова order і вставте рядок:

order hosts

Конфігурація бібліотеки сервера імен буде детально описана у розділі 6 .

Файл hosts містить один запис на рядок, що складається з IP-адреси, імені хоста і необов'язкового списку псевдонімів. Поля відокремлюються пробілами або табуляцією, поле адреси повинне починатися в першій колонці. Все, що слідує після символу #, розцінюється як коментар та ігнорується.

Ім'я хоста може бути повністю кваліфікованим або заданим щодо локального домену. Для vale Ви ввели б у hosts повністю кваліфіковане ім'я, vale.vbrew.com, а також vale саме по собі так, щоб було відоме і офіційне ім'я та коротке локальне.

Приклад файлу hosts для Virtual Brewery наведено нижче. Два спеціальні імені, vlager-if1 і vlager-if2, задають адреси для обох інтерфейсів, що використовуються на vlager .

Яким є практичне використання файлу /etc/networks ? Наскільки я розумію, у цьому файлі можна вказати імена мереж. Наприклад:

[email protected]:~# cat /etc/networks default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 google-dns 8.8.4.4 [email protected]:~#

Однак, якщо я спробую використати це мережеве ім'я, наприклад, в ip утиліті, він не працює:

[email protected]:~# ip route add google-dns 104.236.63.1 dev eth0 Error: an inet prefix is expected rather than "google-dns". [email protected]:~# ip route add 8.8.4.4 via 104.236.64.1 dev eth0 [email protected]:~#

Яким є практичне використання файлу /etc/networks ?

2 Solutions collect form web for “практичне використання файлу / etc / networks”

Як написано на сторінці посібника, файл /etc/networks має описувати символічні імена мереж. З мережею це означає мережевий адресу з хвостом.0 в кінці. Підтримуються лише прості мережі класу A, B або C.

У вашому прикладі запис google-dns неправильний. Це не мережа A, B або C. Це відношення ip-address-hostname, тому воно належить /etc/hosts. Фактично запис по default також не відповідає.

Припустимо, у вас є IP-адреса 192.168.1.5 із вашої корпоративної мережі. Запис у /etc/network міг би бути наступним:

Corpname 192.168.1.0

При використанні таких утиліт, як route або netstat, ці мережі перекладаються (якщо ви не пригнічуєте роздільну здатність з прапором -n). Таблиця маршрутизації може виглядати так:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

Команда IP ніколи не використовує ім'я вузла для введення, тому ваш приклад навряд чи має значення. Також ви помістили ім'я хоста в /etc/networks, а не в ім'я мережі!

Записи з /etc/networks використовуються інструментами, які намагаються перетворити числа на імена, наприклад команду (застарілий) route . Без відповідного запису він показує:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref

Якщо тепер додати рядок mylocalnet 192.168.0.0 до /etc/networks:

# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 mylocalnet

Насправді це ніколи не використовується.

Go!

Протокол мережної файлової служби (Network File Server, NFS) – це відкритий стандарт на надання користувачеві віддаленого доступу до файлових систем. Створені на його основі централізовані файлові системи полегшують щоденне виконання таких завдань як резервне копіювання або перевірка на віруси, а об'єднані дискові розділи простіше обслуговувати, ніж безліч невеликих і розподілених.

Крім того, що система NFS надає можливість централізованого зберігання, вона виявилася дуже корисною і для інших додатків, включаючи роботу з бездисковими та тонкими клієнтами, розбиття мережі на кластери, а також для спільно працюючого міжплатформного програмного забезпечення.

Найкраще розуміння як самого протоколу, так і деталей його реалізації дозволить легше впоратися із практичними завданнями. Ця стаття присвячена NFS і складається з двох логічних частин: спочатку описується сам протокол та цілі, поставлені при його розробці, а потім реалізації NFS у Solaris та UNIX.

З ЧОГО ВСЕ ПОЧИНАЛОСЯ...

Протокол NFS розроблений компанією Sun Microsystems й у 1989 р. з'явився у Internet як документа RFC 1094 під такою назвою: «Специфікація протоколу мережевої файлової системи» (Network File System Protocol Specification, NFS). Цікаво відзначити, що і стратегія компанії Novell на той час була спрямована на подальше вдосконалення файлових служб. Донедавна, поки рух за відкриті коди ще не набрало чинності, Sun не прагнула розкривати секрети своїх мережевих рішень, проте навіть тоді в компанії розуміли всю важливість забезпечення взаємодії з іншими системами.

У документі RFC 1094 містилися дві первісні специфікації. На момент його публікації Sun розробляла вже наступну, третю версію специфікації, яка викладена в RFC 1813 "Специфікація протоколу NFS, версія 3" (NFS Version 3 Protocol Specification). Версія 4 цього протоколу визначена в RFC 3010 "Специфікація протоколу NFS, версія 4" (NFS Version 4 Protocol).

NFS широко використовується на всіх типах вузлів UNIX, мережах Microsoft і Novell, а також у таких рішеннях компанії IBM, як AS400 і OS/390. Будучи невідомою за межами мережевого «королівства», NFS, мабуть, найпоширеніша платформно-незалежна мережна файлова система.

ПРАЦЕМ БУВ UNIX

Хоча NFS - платформно-незалежна система, її прабатьком є UNIX. Іншими словами, ієрархічність архітектури та методи доступу до файлів, включаючи структуру файлової системи, способи ідентифікації користувачів та груп та прийоми роботи з файлами – все це дуже нагадує файлову систему UNIX. Наприклад, файлова система NFS, будучи за структурою ідентичної файлової системи UNIX, монтується у ній. При роботі з NFS на інших операційних системах ідентифікаційні параметри користувачів та права доступу до файлів зазнають перетворення (mapping).

NFS

Система NFS призначена для застосування у клієнт-серверній архітектурі. Клієнт отримує доступ до файлової системи, яка експортується сервером NFS, за допомогою точки монтування на клієнті. Такий доступ зазвичай прозорий для клієнтської програми.

На відміну від багатьох клієнт-серверних систем, NFS для обміну інформацією використовує виклики віддалених процедур (Remote Procedure Calls, RPC). Зазвичай клієнт встановлює з'єднання із заздалегідь відомим портом і потім, відповідно до особливостей протоколу, надсилає запит на виконання певної дії. У разі виклику віддалених процедур клієнт створює виклик процедури та відправляє його на виконання серверу. Детальний опис NFS буде наведено нижче.

Як приклад припустимо, що клієнт змонтував каталог usr2 в локальної кореневої файлової системі:

/root/usr2/ -> remote:/root/usr/

Якщо клієнтському додатку необхідні ресурси цього каталогу, він просто надсилає запит операційній системі на нього та на ім'я файлу, а той надає доступ через клієнта NFS. Наприклад розглянемо просту команду UNIX cd, яка «нічого не знає» про мережеві протоколи. Команда

Cd /root/usr2/

розмістить робочий каталог на віддаленій файловій системі, "навіть не здогадуючись" (користувачу теж немає в цьому необхідності), що файлова система є віддаленою.

Отримавши запит, сервер NFS перевірить наявність у даного користувача права на виконання дії, що запитується, і в разі позитивної відповіді здійснить його.

ПОЗНАЙОМИМОСЯ БЛИЖЧЕ

З погляду клієнта, процес локального монтування віддаленої файлової системи засобами NFS складається з кількох кроків. Як згадувалося, клієнт NFS подасть виклик віддаленої процедури виконання її на сервері. Зауважимо, що в UNIX клієнт є однією програмою (команда mount), тоді як сервер насправді реалізований у вигляді кількох програм з наступним мінімальним набором: служба перетворення портів (port mapper), демон монтування (mount daemon) і сервер NFS .

Спочатку клієнтська команда mount взаємодіє зі службою перетворення портів сервера, що очікує запити через порт 111. Більшість реалізацій клієнтської команди mount підтримує кілька версій NFS, що підвищує можливість знаходження спільної для клієнта та сервера версії протоколу. Пошук ведеться, починаючи з найстаршої версії, тому коли загальна буде знайдена, вона автоматично стане і найновішою версією з підтримуваних клієнтом і сервером.

(Викладений матеріал орієнтований на третю версію NFS, оскільки вона найпоширеніша на даний момент. Четверта версія більшістю реалізацій поки що не підтримується.)

Служба перетворення портів сервера відгукується на запити відповідно до протоколу та порту, на якому працює демон монтування. Клієнтська програма mount спочатку встановлює з'єднання з демоном монтування сервера, потім передає йому за допомогою RPC команду mount. Якщо дана процедура виконана успішно, то клієнтська програма з'єднується з сервером NFS (порт 2049) і, використовуючи одну з 20 віддалених процедур, визначених у RFC 1813 і наведених нами в Таблиці 1, отримує доступ до віддаленої файлової системи.

Сенс більшості команд інтуїтивно зрозумілий і не викликає жодних труднощів у системних адміністраторів. Нижче наведений листинг, отриманий за допомогою tcdump, ілюструє команду читання, створювану командою UNIX cat для прочитання файлу з ім'ям test-file:

10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012010 eth0 > 192.168.1.254. 3476097947 > 192.168.1.252.2049: 144 lookup fh 32,0/ 224145 "test-file" 10:30:16.012729 eth0 192.168.1.254.34 ,0/224307 (DF) 10:30: 16.012729 eth0 192.168.1.254.3476097947: reply ok 128 lookup fh 32,0/224307 (DF) 10:30:16.013124 eth0 > 192.168. 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013124 eth0 > 192.168.1.25 3492875163 > 192.168.1.252.2049: 140 read fh 32,0/ 224307 4096 bytes @ 0 10:30:16.013650 eth0 192.168.1.288. 10:30:16.013650 eth0 192.168.1.254.3492875163 : reply ok 108 read (DF)

NFS традиційно реалізується з урахуванням UDP. Однак деякі версії NFS підтримують TCP (у специфікації протоколу визначено підтримку TCP). Головна перевага TCP - ефективніший механізм повторної передачі у ненадійно працюючих мережах. (У разі UDP, якщо сталася помилка, повне повідомлення RPC, що складається з декількох пакетів UDP, пересилається заново. За наявності TCP заново пересилається лише зіпсований фрагмент.)

ДОСТУП У NFS

У реалізаціях NFS зазвичай підтримуються чотири способи надання прав доступу: за допомогою атрибутів користувача/файлу, на рівні ресурсів, що розділяються, на рівні головного вузла, а також у вигляді комбінації інших методів доступу.

Перший спосіб ґрунтується на вбудованій UNIX системі прав доступу до файлів для індивідуального користувача або групи. Для спрощення обслуговування ідентифікація користувачів та груп має бути однаковою для всіх клієнтів та серверів NFS. Захист слід ретельно продумати: в NFS можна необережно надати такий доступ до файлів, який не планувався при їх створенні.

Доступ на рівні ресурсів, що розділяються, дозволяє обмежувати права, дозволивши лише певні дії, незалежно від приналежності файлу або привілеїв UNIX. Наприклад, роботу з файловою системою NFS можна обмежити лише читанням. Більшість реалізацій NFS дозволяє додатково обмежити доступ на рівні ресурсів, що розділяються конкретними користувачами та/або групами. Наприклад, групі "Відділ кадрів" дозволяється перегляд інформації і не більше.

Доступ на рівні головного вузла дозволяє монтувати файлову систему тільки на конкретних вузлах, що, взагалі кажучи, гарна ідея, оскільки файлові системи можуть легко створюватись на будь-яких вузлах, які підтримують NFS.

Комбінований доступ просто поєднує вищеописані види (наприклад, доступ на рівні ресурсів, що розділяються з доступом, що надається конкретному користувачеві) або дозволяє користувачам роботу з NFS тільки з певного вузла.

NFS У СТИЛІ «ПІНГВІН»

Матеріал, що стосується Linux, базується на системі Red Hat 6.2 з ядром версії 2.4.9, яка поставляється з пакетом nfs-utils версії 0.1.6. Існують і новіші версії: на момент написання цієї статті останнє оновлення пакета nfs-utils мало номер 0.3.1. Його можна завантажити на адресу: .

Пакет nfs-utils містить наступні файли, що виконуються: exportfs, lockd, mountd, nfsd, nfsstat, nhfsstone, rquotad, showmount і statd.

На жаль, іноді підтримка NFS викликає плутанину у адміністраторів Linux, оскільки наявність тієї чи іншої функціональної можливості залежить від номерів версій як ядра, так і пакета nfs-utils. На щастя, в даний час стан справ у цій галузі покращується: останні дистрибутивні комплекти включають нові версії і того, і іншого. Для попередніх випусків у розділі 2.4 документа NFS-HOWTO наводиться повний список функціональних можливостей системи, наявних для кожної комбінації ядра та пакету nfs-utils. Розробники підтримують зворотну сумісність пакета з попередніми версіями, приділяючи багато уваги забезпеченню безпеки та усунення програмних помилок.

Підтримка NFS слід ініціювати під час компіляції ядра. Якщо необхідно, до ядра потрібно додати і можливість роботи з NFS версії 3.

Для дистрибутивів, що підтримують linuxconf, легко налаштувати служби NFS як для клієнтів, так і для серверів. Однак швидкий спосіб встановлення NFS за допомогою linuxconf не дає інформації про те, які файли були створені або редаговані, що дуже важливо знати адміністратору для розуміння ситуації у разі збою системи. Архітектура NFS в Linux має слабкий зв'язок з версією BSD, тому необхідні файли та програми підтримки легко знайти адміністраторам, які працюють з BSD, Sun OS 2.5 або більш ранніми версіями NFS.

Файл /etc/exports, як і в попередніх версіях BSD, визначає файлові системи, до яких дозволено доступ клієнтам NFS. Крім того, він містить низку додаткових можливостей, що стосуються питань управління та безпеки, надаючи адміністратору засіб для тонкого налаштування. Це текстовий файл, що складається із записів, порожніх або закоментованих рядків (коментарі починаються із символу #).

Припустимо, що ми хочемо надати клієнтам доступ тільки для читання каталогу /home на вузлі Lefty. Цьому /etc/exports відповідатиме наступний запис:

/home (ro)

Тут нам необхідно повідомити систему, які каталоги ми збираємось зробити доступними за допомогою демона монтування rpc.mountd:

# exportfs -r exportfs: В /home (ro) не вказано ім'я вузла, введіть *(ro) щоб уникнути попередження #

При запуску команда exportfs виводить попередження про те, що /etc/ exports не обмежує доступ до окремого вузла, і створює відповідний запис /var/lib/nfs/etab з /etc/exports, що повідомляє, які ресурси можна переглянути за допомогою cat:

# cat /var/lib/nfs/etab /home (ro,async,wdelay,hide,secure,root_squash, no_all_squash,subtree_check, secure_locks, mapping=identity,anonuid=-2,anongid=-2)

Інші параметри, перелічені у вигляді списку в etab, включають стандартні значення, що використовуються NFS. Деталі будуть описані нижче. Щоб надати доступ до каталогу /home, необхідно запустити відповідні служби NFS:

# portmap # rpc.mountd # rpc.nfsd # rpc.statd # rpc.rquotad

У будь-який момент після запуску демона монтування (rpc.mountd) можна дізнатися про окремі файли, доступні для виведення, можна, переглянувши вміст файлу /proc/fs/nfs/exports:

# cat /proc/fs/nfs/exports # Version 1.0 # Path Client(Flags) # IPs /home 192.168.1.252(ro,root_squash,async, wdelay) # 192.168.1.252 #

Те саме можна переглянути і за допомогою команди showmount з параметром -e:

# showmount -e Export list for lefty: /home (everyone) #

Забігаючи кілька вперед, скажу, що команду showmount можна використовувати для визначення всіх змонтованих файлових систем, або, іншими словами, щоб з'ясувати, які вузли є клієнтами NFS для системи, на якій запущена команда showmount. Команда showmount -a виведе всі клієнтські точки монтування:

# showmount -a All mount points on lefty: 192.168.1.252:/home #

Як зазначалося вище, більшість реалізацій NFS підтримує різні версії цього протоколу. Реалізація в Linux дозволяє обмежувати список версій NFS, що запускаються, шляхом вказівки ключа -N для демона монтування. Наприклад, для запуску третьої версії NFS, і тільки її, введіть наступну команду:

# rpc.mountd -N 1 -N 2

Вибагливим користувачам може здатися незручним, що в Linux демон NFS (rpc.nfsd) знаходиться в режимі очікування пакетів версій 1 і 2, хоча це досягає бажаного ефекту відмови від підтримки відповідного протоколу. Сподіватимемося, що розробники наступних версій внесуть необхідні виправлення і зможуть домогтися більшої узгодженості компонентів пакета щодо різних версій протоколу.

«ЗАПЛИВ З ПІНГВІНАМИ»

Доступ до конфігурованої вище Lefty, що експортується файловою системою NFS на базі Linux, залежить від клієнтської операційної системи. Стиль установок для більшості операційних систем сімейства UNIX збігається зі стилем або вихідних систем Sun OS і BSD, або новішої Solaris. Так як ця стаття присвячена обом системам, Linux і Solaris, розглянемо клієнтську конфігурацію Solaris 2.6 з точки зору встановлення з'єднання з Linux-версією NFS, описаної нами вище.

Завдяки властивостям, успадкованим Solaris 2.6, її легко налаштувати для роботи клієнтом NFS. Для цього потрібна лише одна команда:

# mount -F nfs 192.168.1.254:/home /tmp/tmp2

Припустимо, що попередня команда mount виконана успішно, тоді команда mount без параметрів виведе наступне:

# mount / on /dev/dsk/c0t0d0s0 read/write/setuid/ largefiles on Mon Sep 3 10:17:56 2001 ... ... /tmp/tmp2 on 192.168.1.254:/home read/ write/remote on Mon Sep 3 23:19:25 2001

Давайте проаналізуємо висновок tcpdump, отриманий на вузлі Lefty після того, як користувач ввів команду ls /tmp/tmp2 на вузлі Sunny:

# tcpdump host lefty і host sunny -s512 06:07:43.490583 sunny.2191983953 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 (DF) 06:07:n. . 2191983953: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF) 06:07:43.491397 sunny.2191983954 > lefty.mcwn. DF) 06:07:43.491463 lefty. mcwrite.n.nfs > sunny.2191983954: reply ok 120 access c0001 (DF) 06:07:43.492296 sunny.2191983955 > lefty.mcwrite.n.nfs, 182 bytes @ 0x000000000 (DF) 06:07:43.492417 lefty.mcwrite.n.nfs > sunny.2191983955: reply ok 1000 readdirplus (DF)

Ми бачимо, що вузол Sunny запитує ls описувач файлу (fh), на що вузол Lefty у відповідь посилає OK і повертає структуру каталогу. Потім Sunny перевіряє дозвіл на право доступу до вмісту каталогу (132 access fh) і отримує відповідь з дозволом Lefty. Після цього вузол Sunny, використовуючи процедуру readdirplus, зчитує повний вміст каталогу. Виклики віддалених процедур описані в документі RFC 1813 та наведені нами на початку цієї статті.

Хоча послідовність команд для доступу до віддалених файлових систем дуже проста, низка обставин може призвести до некоректного монтування системи. Перед монтуванням каталогу точка монтування має вже існувати, інакше її необхідно створити за допомогою команди mkdir. Зазвичай єдиною причиною помилок на стороні клієнта є відсутність локального каталогу для монтування. Більшість проблем, пов'язаних з NFS, зобов'язані своїм походженням невідповідності між клієнтом і сервером або некоректної конфігурації сервера.

Найпростіше усунути проблеми на сервері з вузла, на якому працює сервер. Однак, коли адміністрування сервера займається замість вас хтось інший, це не завжди можливо. Швидкий спосіб переконатися, що відповідні служби сервера правильно налаштовані - використовувати команду rpcinfo з параметром -p. З вузла Solaris Sunny можна визначити, які процеси RPC зареєстровані на вузлі Linux:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind 100000 2 udp 111 rpcbind 100024 1 udp 692 status 19000 p 1024 mountd /100005 3 tcp 1024 mountd 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100021 1 udp 1026 nlockmgr 100021 3 udp 1026 nlockmgr 100021 4 udp 1026 nlockmgr #

Зауважимо, що тут наводиться інформація про версії, що досить корисно, коли для роботи системи потрібна підтримка різних протоколів NFS. Якщо будь-яка служба не запущена на сервері, така ситуація має бути виправлена. У разі невдалого монтування команда rpcinfo -p дозволить з'ясувати, що служба mountd на сервері не працює:

# rpcinfo -p 192.168.1.254 program vers proto port service 100000 2 tcp 111 rpcbind ... ... 100021 4 udp 1026 nlockmgr #

Команда rpcinfo дуже корисна для з'ясування, чи активний той чи інший віддалений процес. Параметр -p - найважливіший із ключів. Для ознайомлення з усіма можливостями rpcinfo зверніться до довідкової сторінки man.

Інший корисний засіб – команда nfsstat. З її допомогою можна дізнатися, чи звертаються клієнти до експортованої файлової системи, а також вивести статистичну інформацію відповідно до версії протоколу.

Зрештою, ще одним досить корисним інструментом визначення причин збоїв системи є tcpdump:

# tcpdump host lefty і host sunny -s512 tcpdump: listening on eth0 06:29:51.773646 sunny.2191984020 > lefty.mcwrite.n.nfs: 140 lookup fh Unkn1:1 9 lefty.mcwrite.n.nfs > sunny.2191984020: reply ok 116 lookup ERROR: No such file or directory (DF) 06:29:51.774593 sunny.2191984021 > lefty.mcwrite.n.nfs: 128 getattr fh Unknown/1 ( DF) 06:29:51.774670 lefty.mcwrite.n.nfs > sunny.2191984021: reply ok 112 getattr DIR 40755 ids 0/0 sz 0x000001000 (DF528) 06 22 > lefty.mcwrite.n.nfs : 140 lookup fh Unknown/1"test.c" (DF) 06:29:51.775357 lefty.mcwrite.n.nfs > sunny.2191984022: reply ok 116 lookup EDF: 51.776029 sunny.2191984023 > lefty.mcwrite.n.nfs: 184 create fh Unknown/1 "дослідження. RROR: Permission denied (DF)

Наведений вище листинг, отриманий після виконання інструкції touch test.c, відображає наступну послідовність дій: спочатку команда touch намагається отримати доступ до файлу на ім'я test.c, потім вона шукає каталог з цим же ім'ям, а після невдалих спроб намагається створити файл test.c що також не призводить до успіху.

Якщо файлова система змонтована, більшість типових помилок пов'язані з звичайними правами доступу UNIX. Використання uid або NIS+ у Sun допомагає уникнути глобального встановлення прав доступу на всі файлові системи. Деякі адміністратори практикують «відкриті» каталоги, коли права доступу на їх читання надаються «усьому світу». Однак цього слід уникати причин безпеки. Навіть відкинувши у бік проблеми захисту, все одно доведеться визнати такий підхід хибною практикою, оскільки користувачі рідко створюють дані з наміром зробити їх доступними для читання всім поспіль.

Звертання привілейованого користувача (root) до змонтованих файлових систем NFS трактуються по-особливому. Щоб уникнути надання привілейованому користувачеві необмеженого доступу, запити від нього трактуються так, ніби вони надходять від користувача nobody («ніхто»). Цей ефективний механізм обмежує доступ привілейованого користувача глобально доступними для читання та дозволеними для запису файлами.

СЕРВЕР NFS, ВЕРСІЯ SOLARIS

Конфігурування Solaris для роботи як сервер NFS так само просто, як і у випадку з Linux. Однак команди та розташування файлів дещо відрізняються. Під час початкового завантаження Solaris після досягнення рівня завантаження 3 (run level 3) автоматично запускаються служби NFS та експортуються всі файлові системи. Для запуску цих процесів уручну введіть команду:

#/usr/lib/nfs/mountd

Щоб запустити демон монтування та сервер NFS, введіть:

#/usr/lib/nfs/nfsd

Починаючи з версії 2.6 у Solaris для вказівки файлових систем, що експортуються, більше не використовується файл експорту. Тепер файли експортуються за допомогою команди share. Припустимо, ми хочемо дозволити дистанційним вузлам змонтувати /export/home. Введемо для цього наступну команду:

Share -F nfs /export/home

Заходи щодо забезпечення безпеки

БЕЗПЕКА В LINUX

Деякі системні служби NFS на основі Linux мають додатковий механізм обмеження доступу за допомогою керуючих списків або таблиць. На внутрішньому рівні цей механізм реалізований за допомогою бібліотеки tcp_wrapper, яка для формування списків контролю доступу використовує два файли: /etc/hosts.allow та /etc/hosts/deny. Вичерпний огляд правил роботи з tcp_wrapper виходить за рамки цієї статті, основний принцип полягає в наступному: зіставлення спочатку проводиться з etc/hosts.allow, а потім з /etc/hosts. deny. Якщо правило не знайдено, то запитувана системна служба не представляється. Щоб оминути останню вимогу і забезпечити дуже високий рівень безпеки, можна додати наступний запис: /etc/hosts.deny:

ALL: All

Після цього можна використовувати /etc/ hosts.allow, щоб встановити той чи інший режим роботи. Наприклад файл /etc/hosts. allow, який я використовував при написанні цієї статті, містив такі рядки:

Lockd:192.168.1.0/255.255.255.0 mountd:192.168.1.0/255.255.255.0 portmap:192.168.1.0/255.255.255.0 rquotad:52.55 :192.168.1.0/255.255.255.0

При цьому дозволяється певний вид доступу до вузлів до надання доступу на рівні додатків. У Linux доступом на рівні програм керує файл /etc/exports. Він складається із записів у наступному форматі:

Експортований каталог (пробіл) вузол | мережа (опції)

«Експортований каталог» - це каталог, обробка запиту якого дозволена демону nfsd. "Вузол|мережа" - це вузол або мережа, що мають доступ до файлової системи, що експортується, а "опції" визначають ті обмеження, які демон nfsd накладає на використання даного розділюваного ресурсу, - доступ тільки для читання або перетворення ідентифікатора користувача (user id mapping) .

У наступному прикладі всьому домену mcwrite.net надано доступ у режимі тільки для читання /home/mcwrite.net:

/home/mcwrite.net *.mcwrite.net(ro)

Інші приклади можна знайти на довідковій сторінці exports man.

БЕЗПЕКА NFS У SOLARIS

У Solaris можливості надання доступу до NFS аналогічні Linux, проте в цьому випадку обмеження задаються за допомогою певних параметрів у команді share з ключем -o. Наступний приклад показує, як дозволити монтування в режимі лише для читання /export/mcwrite.net на будь-якому вузлі домену mcwrite.net:

#share -F nfs -o ro=.mcwrite.net/export/mcwrite.net

Довідкова сторінка man для share_nfs докладно описує надання доступу за допомогою керуючих списків Solaris.

Ресурси Internet

У NFS і RPC не обійшлося без "дір". Взагалі, NFS не слід використовувати при роботі в Internet. Не можна робити «дірки» в брандмауерах, надаючи будь-який доступ через NFS. Необхідно ретельно стежити за всіма латами, що з'являються, для RPC і NFS, в чому можуть допомогти численні джерела інформації з питань безпеки. Два найбільш популярні джерела - Bugtraq і CERT:

Перший можна регулярно переглядати у пошуках необхідної інформації або скористатися підпискою на періодичну розсилку новин. Другий надає, можливо, не таку оперативну, в порівнянні з іншими, інформацію, зате в досить повному обсязі і без відтінку сенсаційності, властивої деяким сайтам, присвяченим інформаційній безпеці.

Іноді помилки мережі та інші системні помилки Windows можуть бути пов'язані з проблемами в реєстрі Windows. Декілька програм може використовувати файл networks, але коли ці програми видалені або змінені, іноді залишаються "осиротілі" (помилкові) записи реєстру Windows.

В принципі, це означає, що в той час, як фактичний шлях до файлу міг бути змінений, його неправильне колишнє розташування досі записано в реєстрі Windows. Коли Windows намагається знайти файл за цим неправильним посиланням (на розташування файлів на вашому комп'ютері), може виникнути помилка мереж. Крім того, зараження шкідливим програмним забезпеченням могло пошкодити записи реєстру, пов'язані з Microsoft Windows. Таким чином, ці пошкоджені записи реєстру Windows необхідно виправити, щоб вирішити проблему в корені.

Редагування реєстру Windows вручну з метою видалення ключів мережі, що містять помилки, не рекомендується, якщо ви не є фахівцем з обслуговування ПК. Помилки, допущені під час редагування реєстру, можуть призвести до непрацездатності вашого ПК і завдати непоправної шкоди вашій операційній системі. Насправді навіть одна кома, поставлена не в тому місці, може перешкодити завантаженню комп'ютера!

У зв'язку з подібним ризиком ми рекомендуємо використовувати надійні інструменти очищення реєстру, такі як WinThruster (розроблений Microsoft Gold Certified Partner), щоб просканувати та виправити будь-які проблеми, пов'язані з networks. Використовуючи очищення реєстру, ви зможете автоматизувати процес пошуку пошкоджених записів реєстру, посилань на відсутні файли (наприклад, викликають помилку networks) та неробочих посилань усередині реєстру. Перед кожним скануванням автоматично створюється резервна копія, яка дозволяє скасувати будь-які зміни одним кліком та захищає вас від можливого пошкодження комп'ютера. Найприємніше, що усунення помилок реєстру може різко підвищити швидкість та продуктивність системи.

Попередження:Якщо ви не є досвідченим користувачем ПК, ми не рекомендуємо редагувати реєстр Windows вручну. Некоректне використання Редактора реєстру може призвести до серйозних проблем і вимагати повторної інсталяції Windows. Ми не гарантуємо, що проблеми, які є результатом неправильного використання Редактора реєстру, можуть бути усунені. Ви користуєтеся Редактором реєстру на свій страх та ризик.

Перед тим, як вручну відновлювати реєстр Windows, необхідно створити резервну копію, експортувавши частину реєстру, пов'язану з мережами (наприклад, Microsoft Windows):

Натисніть на кнопку Почати.
Введіть " command" рядку пошуку... ПОКИ НЕ НАТИСНІТЬ ENTER!
Утримуючи клавіші CTRL-Shiftна клавіатурі, натисніть ENTER.
Буде відображено діалогове вікно для доступу.
Натисніть Так.
Чорний ящик відкривається миготливим курсором.
Введіть " regedit" та натисніть ENTER.
У Редакторі реєстру виберіть ключ, пов'язаний із мережами (наприклад, Microsoft Windows), для якого потрібно створити резервну копію.
В меню ФайлВиберіть Експорт.
В списку Зберегти увиберіть папку, до якої потрібно зберегти резервну копію ключа Microsoft Windows.
В полі ім'я файлувведіть назву файлу резервної копії, наприклад, резервна копія Microsoft Windows.
Переконайтеся, що у полі Діапазон експортувибрано значення Вибрана гілка.
Натисніть Зберегти.
Файл буде збережено з розширенням.reg.
Тепер у вас є резервна копія запису реєстру, пов'язаного з мережею.

Наступні кроки при ручному редагуванні реєстру не будуть описані в цій статті, оскільки з ймовірністю можуть призвести до пошкодження вашої системи. Якщо ви бажаєте отримати більше інформації про редагування реєстру вручну, будь ласка, ознайомтеся з посиланнями нижче.