Головна / Встановлення та налаштування / Для чого потрібен файл networks в windows. Що таке Networks і як його виправити? Версії і варіації

Для чого потрібен файл networks в windows. Що таке Networks і як його виправити? Версії і варіації

Etc папка це папка в якій знаходяться такі текстові файли hosts, lmhosts.sam, networks, protocol, services це стандартний зміст папки etc для Windows XP і Windows 7.

Все про папку etc

Знайти де знаходиться папка etc просто, тисніть «Пуск» - «Комп'ютер» - « Локальний диск С »-« Windows »-« System32 »-« drivers »-« etc ».

Які файли в папці etc

Якщо у вас пропала папка etc то можете завантажити папку etc Windows 7 і для Windows 8.

Тепер опишу як відновити папку etc, скачавши архів папки etc розархівуйте її. Скопіюйте тільки etc, знайдіть де вона повинна бути і вставте. Папка etc для Windows 7 нічим не відрізняється від папки etc для Windows XP. Вміст папки etc Windows 7 відрізняється від Windows 8. У Windows 8 на два файли в etc папці більше: hosts.backup і hosts.rollback. Повний зміст папки etc Windows 8 hosts, lmhosts.sam, networks, protocol, services, hosts.backup і hosts.rollback. Віруси зазвичай змінюють вміст двох файлів це файл hosts в папці etc і файл services в папці etc. Відкривати файли в etc папці можна за допомогою блокнота.

Доброго часу, шановні читачі. Публікую другу частину. У поточній частині основний упор зроблений на реалізацію мережі в 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 $ local_fs # Required-Stop: $ local_fs # Should -Start: ifupdown # Should-Stop: ifupdown # Default-Start: S # Default-Stop: 0 6 # Short-Description: Raise network interfaces. ### END INIT INFO PATH \u003d "/ 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] || return 0 log_warning_msg "/ etc / network / options still exists and it will be IGNORED! Read README.Debian of netbase." ) check_network_file_systems () ([-e / proc / mounts] || return 0 if [-e /etc/iscsi/iscsi.initramfs]; then log_warning_msg "not deconfiguring network interfaces: iSCSI root is mounted." exit 0 fi exec 9<&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.

The ifup and ifdown commands may be used to configure (or, respectively, deconfigure) network interfaces based on interface definitions in the file / etc / network / interfaces.

-a, --all
If given to ifup, affect all interfaces marked auto. Interfaces are brought up in the order in which they are defined in / etc / network / interfaces. If given to ifdown, affect all defined interfaces. Interfaces are brought down in the order in which they are currently listed in the state file. Only interfaces defined in / etc / network / interfaces will be brought down.

ip-server: ~ # cat / etc / network / interfaces # This file describes the network interfaces available on your system # and how to activate them. 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 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254 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-server: ~ # 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. Я розгляну 3 основні утиліти діагностики мережі, без яких виявити неполадки буде проблематично.

Думаю, що дана утиліта знайома чи не кожному. Робота цієї утиліти полягає в відправціт.зв. пакетів 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 \u003d 1 ttl \u003d 57 time \u003d 42.7 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq \u003d 2 ttl \u003d 57 time \u003d 43.2 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq \u003d 3 ttl \u003d 57 time \u003d 42.5 ms 64 bytes from www.yandex.ru (87.250.251.3): icmp_seq \u003d 4 ttl \u003d 57 time \u003d 42.5 ms 64 bytes from www .yandex.ru (87.250.251.3): icmp_seq \u003d 5 ttl \u003d 57 time \u003d 41.9 ms ^ C --- ya.ru ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4012ms rtt min / avg / max / mdev \u003d 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 \u003d вказана нумерація відправляються пакетів. Кожному відправляється пакету послідовно присвоюється номер і якщо в даній нумерації будуть "провали", то це нам розповість про те, що з'єднання з "пінгуемим" нестійкий, а так само може означати, що сервер, з яким шлють пакети перевантажений. за значенням time \u003dми бачимо, скільки часу пакет подорожував до 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 ms 6.193 ms 2 065-064-free .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 ms 4 KubTelecom-lgw.Krasnodar.gldn.net (194.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.201.230) 43.322 ms 41.783 ms 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 і повертає інформацію про заданому домені. приклад:

# Dig @ ns.kuban.ru roboti.ru;<<>\u003e DiG 9.3.6-P1<<>\u003e @ Ns.kuban.ru roboti.ru; (1 server found) ;; global options: printcmd ;; Got answer: ;; - \u003e\u003e 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 Connection [15.285527] e1000: eth2: 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 Full Duplex, Flow Control: RX

у висновку видно, що в системі є 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 Connection [5.534684] e1000: eth2: 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] e1000: eth2: e1000_watchdog: NIC 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_watchdog: NIC Link is Up 1000 Mbps Full Duplex, 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 1500 Metric: 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) TX bytes: 16184 (15.8 KiB)

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

резюме

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

Коли мова йде про комп'ютерні мережі, часто можна почути згадка NFS. Що таке означає ця абревіатура?

Це протокол розподіленої файлової системи, спочатку розроблений компанією Sun Microsystems в 1984 році, що дозволяє користувачеві на клієнтському комп'ютері отримувати доступ до файлів через мережу, подібно доступу до локального сховища. NFS, як і багато інших протоколи, ґрунтується на системі Open Network Computing Remote Procedure Call (ONC RPC).

Іншими словами, що таке NFS? Це відкритий стандарт, визначений в Request for Comments (RFC), що дозволяє будь-якому реалізувати протокол.

Версії і варіації

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

NFS v2

Версія 2 спочатку працювала тільки по протоколу User Datagram Protocol (UDP). Її розробники хотіли зберегти серверну сторону без блокування, реалізованої за межами основного протоколу.

Інтерфейс віртуальної файлової системи дозволяє виконувати модульну реалізацію, відображену в простому протоколі. До лютого 1986 року було продемонстровано рішення для таких операційних систем, як System V release 2, DOS і VAX / VMS з використанням Eunice. NFS v2 дозволяв зчитувати тільки перші 2 ГБ файлу через 32-розрядних обмежень.

NFS v3

Перше речення з розробки NFS версії 3 в Sun Microsystems було озвучено незабаром після випуску другого дистрибутива. Головною мотивацією була спроба пом'якшити проблему продуктивності синхронної записи. До липня 1992 року практичні доробки дозволили вирішити багато недоліків NFS версії 2, залишивши при цьому лише недостатню підтримку файлів (64-розрядні розміри і зміщення файлів).

підтримку 64-бітних розмірів і зсувів файлів для обробки даних розміром понад 2 гігабайт (ГБ);
підтримку асинхронної записи на сервері для підвищення продуктивності;
додаткові атрибути файлів у багатьох відповідях, що дозволяють уникнути необхідності їх повторного отримання;
операцію READDIRPLUS для отримання даних і атрибутів разом з іменами файлів при скануванні каталогу;
багато інших поліпшення.

Під час введення версії 3 підтримка TCP як протоколу транспортного рівня почала збільшуватися. Використання TCP як засіб передачі даних, виконаного з використанням NFS через WAN, стало дозволяти передавати великі розміри файлів для перегляду і запису. Завдяки цьому розробники змогли подолати межі обмежень у 8 КБ, що накладаються протоколом призначених для користувача дейтаграм (UDP).

Що таке NFS v4?

Версія 4, розроблена під впливом Ендрской файлової системи (AFS) і блоку повідомлень сервера (SMB, також звана CIFS), включає в себе підвищення продуктивності, забезпечує кращу безпеку і вводить протокол з дотриманням встановлених умов.

Версія 4 стала першим дистрибутивом, розробленим в Цільовий групі Internet Engineering Task Force (IETF) після того, як Sun Microsystems передала розробку протоколів стороннім фахівцям.

NFS версія 4.1 спрямована на надання підтримки протоколу для використання кластерних розгортання серверів, включаючи можливість надання масштабується паралельного доступу до файлів, розподіленим між декількома серверами (розширення pNFS).

Новітній протокол файлової системи - NFS 4.2 (RFC 7862) - був офіційно випущений в листопаді 2016 року.

інші розширення

З розвитком стандарту з'явилися і відповідні інструменти для роботи з ним. Так, WebNFS, розширення для версій 2 і 3, дозволяє протоколу мережевого доступу до файлових систем легше інтегруватися в веб-браузери і активувати роботу через брандмауери.

Різні протоколи сторонніх груп стали також асоціюватися з NFS. З них найбільш відомими виступають:

Network Lock Manager (NLM) з підтримкою протоколу байтів (доданий для підтримки API-блокування файлів UNIX System V);
віддаленої квоти (RQUOTAD), який дозволяє користувачам NFS переглядати квоти на зберігання даних на серверах NFS;
NFS через RDMA - адаптація NFS, яка використовує дистанційний прямий доступ до пам'яті (RDMA) як засіб передачі;
NFS-Ganesha - сервер NFS, що працює в просторі користувача і підтримує CephFS FSAL (рівень абстракції файлової системи) з використанням libcephfs.

платформи

Network File System часто використовується з операційними системами Unix (такими як Solaris, AIX, HP-UX), MacOS від Apple і Unix-подібними ОС (такими як Linux і FreeBSD).

Він також доступний для таких платформ, як Acorn RISC OS, OpenVMS, MS-DOS, Microsoft Windows, Novell NetWare і IBM AS / 400.

Альтернативні протоколи віддаленого доступу до файлів включають в себе блок повідомлень сервера (SMB, також званий CIFS), протокол передачі Apple (AFP), базовий протокол NetWare (NCP) і файлову систему сервера OS / 400 (QFileSvr.400).

Це пов'язано з вимогами NFS, які орієнтовані здебільшого на Unix-подібні «оболонки».

При цьому протоколи SMB і NetWare (NCP) застосовуються частіше, ніж NFS, в системах під управлінням Microsoft Windows. AFP найбільш широко поширений в платформах Apple Macintosh, а QFileSvr.400 найбільш часто зустрічається в OS / 400.

типова реалізація

Припускаючи типовий сценарій в стилі Unix, в якому одного комп'ютера (клієнту) потрібен доступ до даних, що зберігаються на іншому (сервер NFS):

Сервер реалізує процеси Network File System, запущені за замовчуванням як nfsd, щоб зробити свої дані загальнодоступними для клієнтів. Адміністратор сервера визначає, як експортувати імена і параметри каталогів, зазвичай використовуючи файл конфігурації / etc / exports і команду exportfs.
Адміністрування безпеки сервера гарантує, що він зможе розпізнавати і стверджувати перевіреного клієнта. Конфігурація його мережі гарантує, що відповідні клієнти можуть вести переговори з ним через будь-яку систему брандмауера.
Клієнтська машина запитує доступ до експортованих даними, як правило, шляхом видачі відповідної команди. Вона запитує сервер (rpcbind), який використовує порт NFS, і згодом підключається до нього.
Якщо все відбувається без помилок, користувачі на клієнтській машині зможуть переглядати та взаємодіяти з встановленими файловими системами на сервері в межах дозволених параметрів.

Слід звернути увагу і на те, що автоматизація процесу Network File System також може мати місце - можливо, з використанням etc / fstab і / або інших подібних засобів.

Розвиток на сьогоднішній день

До 21-го сторіччя протоколи-конкуренти DFS і AFS не досягнули будь-якого великого комерційного успіху в порівнянні з Network File System. Компанія IBM, яка раніше придбала всі комерційні права на вищевказані технології, безоплатно передала велику частину вихідного коду AFS спільноті вільних розробників програмного забезпечення в 2000 році. Проект Open AFS існує і в наші дні. На початку 2005 року IBM оголосила про завершення продажів AFS та DFS.

У свою чергу, в січні 2010 року компанія Panasas запропонувала NFS v 4.1 на основі технології, що дозволяє поліпшити можливості паралельного доступу до даних. Протокол Network File System v 4.1 визначає метод поділу метаданих файлової системи з розташування певних файлів. Таким чином, він виходить за рамки простого поділу імен / даних.

Що таке NFS цієї версії на практиці? Вищевказана особливість відрізняє його від традиційного протоколу, який містить імена файлів і їх даних під одним прив'язкою до сервера. При реалізації Network File System v 4.1 деякі файли можуть розподілятися між багатовузлових серверами, проте участь клієнта в поділі метаданих і даних обмежена.

При реалізації четвертого дистрибутива протоколу NFS-сервер являє собою набір серверних ресурсів або компонентів; передбачається, що вони контролюються сервером метаданих.

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

Після того, як Ви розділили на підмережі свою мережу, Ви повинні підготуватися до простого пошуку адреси по імені, використовує файл / 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.