NFSv4 забезпечує уніфікований мережевий доступ

Network File System (NFS) є частиною світу безкоштовних операційних систем і патентованих різновидів UNIX з середини 1980-х років. Але не всі адміністратори знають, як вони працюють, або чому з'являються нові версії. Знання NFS важливо просто тому, що ця система є життєво необхідною для уніфікованого доступу по UNIX-мереж. Дізнайтеся про те, як в останній версії NFS (NFSv4) було вирішено багато проблеми, особливо проблеми захисту, що проявилися у версіях 2 і 3.


Файлова система – це необхідність. Ми працюємо на комп'ютерах, що надають доступ до принтерів, камерам, баз даних, віддаленим датчикам, телескопів, компіляторам і мобільним телефонам. Ці пристрої мають мало спільного – зокрема, багато хто з них стали реальністю вже після того, як Інтернет став повсюдним явищем (наприклад, електронні фотокамери та мобільні пристрої, що виконують функції маленьких комп'ютерів). Проте всім їм необхідна файлова система для зберігання і захищеного доступу до інформації.


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


Мережеві файлові системи та інші священнодійства


Багато в чому обмін даними є не більше ніж копіюванням інформації на великі відстані. Мережеві протоколи були не єдиним засобом, завдяки якому став можливий загальний обмін даними. У Зрештою, кожна комп'ютерна система повинна перетворювати датаграми в що-небудь зрозуміле для операційної системи на іншому кінці. TCP – це дуже ефективний протокол передачі, але він не оптимізований для забезпечення швидкого доступу до файлів або для віддаленого управління прикладним програмним забезпеченням.


Розподілені обчислення проти мережних


Традиційні мережеві протоколи не багато можуть запропонувати для організації обчислень, розподілених між комп'ютерами і, тим більше, між мережами. Тільки нерозумні програмісти покладалися б на протокол передачі даних і оптичні кабелі для організації паралельних обчислень. Зазвичай ми покладаємося на послідовну модель, в якій після встановлення з'єднання починають працювати протоколи канального рівня, які виконують досить складну процедуру вітання між мережевими картами. Паралельні обчислення та розподілені файлові системи більше не залежать від IP або Ethernet. В даний час ми можемо їх просто не брати до уваги, кажучи про продуктивність. Однак проблеми захисту – це інша справа.


Однією з ланок головоломки є спосіб організації доступу до файлів в комп'ютерній системі. Зараз для системи, що здійснює доступ до файлів, є несуттєвим, чи доступні необхідні файли на одному комп'ютері, або вони розташовані з яких-небудь причин на декількох комп'ютерах. В даний час семантика файлової системи і структури даних файлової системи є двома дуже різними темами. Семантика файлової системи Plan 9 або розподіленої файлової системи AFS-стилю (Andrew File System) приховує спосіб організації файлів або спосіб відображення файлової системи на апаратне та мережеве забезпечення. NFS не обов'язково приховує спосіб зберігання файлів та каталогів на віддалених файлових системах, але вона також не розкриває дійсний апаратний спосіб зберігання файлових систем, каталогів і файлів.


NFS: Рішення UNIX-проблеми


Доступ до розподіленої файлової системи, тим не менше, вимагає дещо більше пари команд, які дозволяють користувачам монтувати каталог, який розташований на іншому комп'ютері в мережі. Sun Microsystems зіткнулася з цією проблемою кілька років тому, коли починала поширювати щось, назване Remote Procedure Calls (RPCs), або NFS.


Основною проблемою, яку намагалися вирішити в Sun, був спосіб підключення декількох UNIX-комп'ютерів для організації єдиної розподіленої робочого середовища без необхідності переписувати семантику файлової системи UNIX і додавати занадто велику кількість структур даних, специфічних для розподілених файлових систем – цілісність кожної системи повинна була бути збережена, одночасно надаючи користувачам можливість роботи з каталогом на іншому комп'ютері без виникнення небажаних затримок або обмежень у їхньому робочому процесі.


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


NFS – це RPC


NFS традиційно визначається як RPC-додаток, що вимагає наявності TCP для NFS-сервера, а також або TCP, або іншого не перенавантажувати мережу протоколу для NFS-клієнта. Організація Internet Engineering Task Force (IETF) опублікувала Request for Comments (RFC) для RPC в RFC 1832. Інший життєво важливий для функціонування NFS-реалізації стандарт описує формати даних, які використовуються NFS; він був опублікований в RFC 1831 як документ "External Data Representation" (XDR).


Інші RFC мають справу з захистом і алгоритмами шифрування, що використовуються при обміні інформацією для аутентифікації під час NFS-сесій, але ми спочатку зупинимося на базових механізмах. Одним з протоколів, які нас цікавлять, є протокол Mount, описаний в Додатку 1 RFC 1813.


Цей RFC описує, які протоколи забезпечують функціонування NFS, але в ньому не описується, як NFS функціонує в даний час. Ви вже дізналися дещо важливе, а саме – NFS-протоколи задокументовані у вигляді IETF-стандартів. Після того, як остання версія NFS застрягла на цифрі 3, RPC-протоколи не розвивалися далі інформаційної фази RFC і сприймалися, в основному, як не виходять за межі інтересів (Приблизно) величезної інженерної робочої групи Sun Microsystems і патентованих різновидів UNIX. З 1985 року Sun випустила кілька версій NFS, на кілька років предвосхитившей більшість сучасних різновидів файлових систем. Sun Microsystems передала контроль над NFS організації IETF в 1998 році, і велика частина роботи над NSF версії 4 (NFSv4) проводилася під егідою IETF.


Тобто, працюючи сьогодні з RPC і NFS, ви працюєте з версією, яка відображає інтереси компаній і груп, що не мають відношення до Sun. Однак багато інженери Sun зберігають глибокий інтерес до розробки NFS.


NFS версії 3


NFS у своєму втіленні у вигляді версії 3 (NFSv3) не зберігає свій стан (не є stateful), а NFSv4 зберігає. Це фундаментальне вираження сьогодні чи когось дивує, хоча світ TCP / IP, на якому побудована NFS, здебільшого не зберігає свого стану (stateless) – факт, який допомагає компаніям, що виробляють програмне забезпечення для аналізу трафіку і системи захисту, відчувати себе досить добре.


Протокол NFSv3 повинен був покладатися на кілька додаткових протоколів для прозорого монтування каталогів на віддалених комп'ютерах, щоб не залежати від використовуваних на них механізмів файлових систем. NFS не завжди досягала успіху в цьому. Хороший приклад – протокол Mount викликав початковий ідентифікатор файлу, в той час як протокол Network Lock Manager займався блокуванням файлу. Обидві операції потребували в поточному стані, який протокол NFSv3 не надавав. Отже, мали місце складні взаємодії між рівнями протоколів, які не відображали аналогічні механізми потоків даних. Крім того, якщо додати той факт, що створення файлу та каталогу в Microsoft ® Windows ® здійснюється абсолютно не так, як в UNIX, ситуація ще більше ускладниться.


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


Протокол NFSv3 був також готовий для роботи з файловими системами, що підтримують Unicode – перевага, яке до кінця 1990-х років залишалося в деякій мірі чисто теоретичним. Він добре відповідав семантиці файлової системи UNIX і став причиною створення конкуруючих реалізацій файлових систем, таких як AFS і Samba. Не дивно, що Windows-підтримка була бідною, але файлові сервери Samba забезпечували загальний доступ до файлів для систем UNIX та Windows.


NFS версії 4


Протокол NFSv4 є, як ми відзначили, протоколом, що зберігають свій стан. Така поведінка зробили можливим кілька радикальних змін. Ми вже згадували, що повинні викликатися допоміжні протоколи, тому що процеси користувацького рівня були усунені. Замість них усі операції з відкриття файлу і досить багато RPC-викликів були реалізовані у вигляді операцій файлової системи рівня ядра.


Всі NFS-версії визначали кожну одиницю роботи в поняттях операцій RPC-клієнта і сервера. Кожен NFSv3-запит вимагав досить значної кількості RPC-дзвінків і викликів операцій відкриття портів для видачі результату. Версія 4 спростила це, ввівши поняття так званої складовою (compound) операції, до якої належить велика кількість операцій над об'єктами файлової системи. Прямим ефектом, зрозуміло, стало значно меншу кількість RPC-дзвінків і менший обсяг даних, які потрібно передавати по мережі, навіть при тому, що кожен RPC-виклик ніс, по суті, більше даних, виконуючи значно більший обсяг роботи. Було приблизно підраховано, що RPC-виклики в NFSv3 вимагали в п'ять разів більша кількість клієнт-серверних взаємодій в порівнянні зі складовими RPC-процедурами.


RPC, насправді, більше не має такої важливості, і, по суті, служить оболонкою (wrapper) над кількома операціями, інкапсульованого в NFSv4-стеці. Також це зміна зробило стек протоколу набагато менш залежним від семантики файлової системи. Але це не означає, що операції файлової системи інших операційних систем були проігноровані: наприклад, для спільного використання Windows-ресурсів потрібно збереження стану при викликах відкриття ресурсу. Збереження стану не тільки полегшує аналіз трафіку, але при реалізації на рівні семантики файлової системи робить операції файлової системи значно більш доступними для контролю. Виклики відкриття ресурсів із збереженням стану дозволяють клієнтам кешувати файлові дані і стан – те, що в іншому випадку відбувалося б на сервері. У реальному житті (у якій Windows-клієнти поширені повсюдно) організація прозорої та уніфікованої роботи NFS-серверів з розділяються Windows-ресурсами коштує витраченого вами часу на налаштування NFS-конфігурації.


Використання NFS


Установка NFS, загалом, аналогічна установці Samba. На стороні сервера ви визначаєте файлові системи або каталоги для експорту або спільного використання; клієнтська сторона монтує ці каталоги. Після монтування віддаленим клієнтом NFS-каталогу цей каталог стає доступний так само, як будь-який інший каталог локальної файлової системи. Налаштування NFS на сервері – це простий процес. Як мінімум, ви повинні створити або відредагувати файл / etc / exports і запустити NFS-демон. Для налаштування більш захищеною NFS-служби ви повинні також відредагувати файли / etc / hosts.allow і / etc / hosts.deny. NFS-клієнт вимагає виконання тільки команди mount. Додаткова інформація та параметри описані в оперативній документації по Linux ® (man page).


NFS-сервер


Записи у файлі / etc / exports мають зрозумілий формат. Для організації спільного доступу до файлової системи змініть файл / etc / exports і опишіть файлову систему (з параметрами) у наступному загальному форматі:






 каталог (або файлова система) client1 (option1, option2) client2 (option1, option2)

Загальні параметри


Для налаштування вашої NFS-реалізації є кілька загальних параметрів. До них відносяться:



Відображення користувачів


Через відображення користувачів в NFS ви можете ототожнити псевдопользователя чи реального користувача і групи з користувачем, що працюють з NFS-томом. NFS-користувач має права користувача або групи, які дозволяє відображення. Використання єдиного (generic) користувача і групи для NFS-томів забезпечує рівень захисту і гнучкість без значних зусиль з адміністрування.


При використанні файлів на NFS-монтованої файлової системі користувальницький доступ зазвичай "пригнічується" (squashed). Це означає, що користувач звертається до файлів як анонімний користувач, який має доступ до цих файлів тільки з читання. Це поведінка особливо важливо для користувача root. Проте, існують ситуації, коли ви хочете, щоб користувач звертався до файлів на віддаленій системі як root або який-небудь інший визначений користувач. NFS дозволяє вказати користувача (за ідентифікаційним номером користувача (UID) і ідентифікаційному номеру групи (GID)) для доступу до віддалених файлів, і ви можете заборонити нормальна поведінка "придушення" за замовчуванням.


До параметрів відображення користувачів відносяться:



У лістингу 1 наведені приклади записів / etc / exports.


Лістинг 1. Приклади записів / etc / exports





/opt/files 192.168.0.*
/opt/files 192.168.0.120
/ Opt / files 192.168.0.125 (rw, all_squash, anonuid = 210, anongid = 100)
/opt/files *(ro, insecure, all_squash)

Перший запис експортує каталог / opt / files для всіх хостів мережі 192.168.0. Наступний запис експортує / opt / files для одного хоста: 192.168.0.120. Третій запис вказує хост 192.168.0.125 і надає доступ по читанню / запису до файлів з правами користувача, який має user id=210 і group id=100. Останній запис використовується для загальнодоступного каталогу й дозволяє доступ тільки з читання і тільки під обліковим записом анонімного користувача.


NFS-клієнт







 



Застереження

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


Для використання NFS у ролі клієнта на клієнтському комп'ютері повинен виконуватися rpc.statd і portmap. Ви можете виконати команду ps -ef для перевірки присутності двох цих демонів. Якщо вони працюють (як і повинні), ви можете монтувати експортований сервером каталог за допомогою такої спільної команди:






mount server:directory  local mount point

Взагалі кажучи, при монтуванні файлової системи ви повинні працювати як користувач root. На віддаленому комп'ютері ви можете використовувати наступну команду (у припущенні, що NFS-сервер має IP-адресу 192.168.0.100):






mount 192.168.0.100:/opt/files  /mnt

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






mount -t nfs 192.168.0.100:/opt/files /mnt

Віддалений каталог повинен монтуватися без жодних проблем, якщо ви коректно налаштували сервер. Тепер виконайте команду cd для переходу в каталог / mnt, потім команду ls для перегляду файлів. Для того щоб зробити таке монтування постійним, ви повинні змінити файл / etc / fstab і створити запис, аналогічну наступною:






192.168.0.100:/opt/files  /mnt  nfs  rw  0  0

Примітка: Додаткова інформація по записах / etc / fstab наведена в оперативній довідці за fstab.


Критика NFS







 



Критика сприяє поліпшенню

Критика, пов'язана з захищеністю NFS, була причиною багатьох поліпшень в NSFv4. Творці нової версії провели реальні заходи щодо посилення захищеності клієнт-серверних взаємодій. Фактично, вони вирішили реалізувати абсолютно нову модель системи захисту.


Для розуміння моделі системи захисту ви повинні ознайомитися з інтерфейсом прикладного програмування Generic Security Services (GSS-API) версії 2, редакції 1. GSS-API повністю описаний в RFC 2743, який, на жаль, є одним з найбільш складних для розуміння RFC-документів.


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


З'єднання між NFS-клієнтами і серверами захищаються за допомогою так званої (досить поверхово) системи захисту strong RPC. NFSv4 використовує стандарт Open Network Computing Remote Procedure Call (ONCRPC), визначений в RFC 1831. Система захисту повинна була бути посилена, тому замість простої аутентифікації (відомої як AUTH_SYS) як обов'язкова частина протоколу NFSv4 була визначена і реалізована різновид заснованої на GSS-API системи захисту, відома під назвою RPCSEC_GSS. До найбільш важливим доступним в NFSv4 механізмам захисту відносяться Kerberos версії 5 і LIPKEY.


Якщо Kerberos має обмеження при використанні в Інтернет, то у LIPKEY є приємне перевага – працюючи як Secure Sockets Layer (SSL), він запитує у користувачів їх імена і паролі, уникаючи, в той же час, TCP-залежності від SSL – залежності, яку NFSv4 не поділяє. Ви можете налаштувати NFS на реалізацію різновидів системи захисту, якщо RPCSEC_GSS не потрібно. Попередні версії NFS не мали такої можливості і, отже, не могли забезпечити якісний захист, цілісність даних, вимоги щодо аутентифікації або типи шифрування.


Протокол NFSv3 піддався істотною критиці в області захищеності. Якщо NFSv3-сервери працювали по TCP, було абсолютно реально запускати NFSv3-мережі через Інтернет. На жаль, потрібно було також відкривати кілька портів, що призводило до появи декількох добре розрекламованих дір у системі захисту. Зробивши порт 2049 обов'язковим для NFS, стало можливим використання NFSv4 з брандмауерами (firewall) без необхідності приділяти занадто велику увагу тому, які порти прослуховували інші протоколи, наприклад, протокол Mount. Таким чином, виключення протоколу Mount мало кілька позитивних ефектів:



До цих пір чи NFS поза конкуренцією?


NFSv4 замінює NFSv3 на більшості систем UNIX і Linux. Як мережева файлова система NSFv4 має мало конкурентів. Життєздатним конкурентом могла б вважатися Common Internet File System (CIFS) / Server Message Block (SMB), виходячи з того, що вона присутня у всіх різновидах Windows і (в даний час) в Linux. AFS ніколи не мала великого комерційного впливу; в ній надавали особливого значення елементам розподілених файлових систем, які полегшували міграцію і реплікацію даних.


Готові до використання Linux-версії NFS були випущені після досягнення ядром версії 2.2, але однією з найбільш загальних невдач версій ядра Linux було те, що Linux прийняв NFSv3 досить пізно. Фактично, пройшло багато часу до того, коли Linux став повністю підтримувати NSFv3. З появою NSFv4 цей недолік був швидко усунутий і повну підтримку NSFv4 реалізували не тільки в Solaris, AIX і FreeBSD.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*