Linux це повний та вільний до розповсюдження клон операційної системи UNIX для систем базованих на процесорах сумісних з Intel 386/486/Pentium. Під Linux працює велика кількість програмного забезпечення, включаючи X Window, Emacs; Linux підтримує роботу з TCP/IP мережами (включаючи SLIP/PPP/ISDN).

Linux це оригінальна розробка Linus-а Torvald-а (Гельсінки, Фінляндія). Через два роки Linux став одною з найпопулярніших версій серед вільних до розповсюдження unix-ів, і на зараз його продовжує розробляти велика кількість людей з різних куточків світу.

 

 

2. Введення в мережі

2.1 Історія

Ідея мереж є ймовірно такою ж старою як і власне телекомунікацій. Поглянемо на людей що жили в кам'яному віці і використовували барабани для передачі повідомлень між окремими людьми. Припустимо печерна людина A хоче запросити B для гри в кидання камінням один в одного, але вони занадто далеко щоб B міг почути як A б'є в барабан. Який вибір у A? Він може 1) піти пішки до B, 2) взяти більший барабан, або 3) просить C, який живе між ними, щоб той переправив повідомлення. Останній варіант і називається мережею.

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

В цьому керівництві ми опишемо два типи мереж : базованих на UUCP, та базованих на TCP/IP. Це протокольні набори та програмне забезпечення яке дозволяє обмінюватися данними між двома комп'ютерами. В цій главі ми оглянемо типи мереж та торкнемось їхніх основнних принципів.

Ми означуюмо мережу як набір хостів які здатні спілкуватись один з одним, часто покладаючись на послуги хостів-посередників для передачі данних між учасниками. Хост - не завжди комп'ютер - це може бути і X-термінал чи спеціальний принтер. Невеликі скупчення хостів називають також сайтами (site).

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

2.2 UUCP мережі

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

UUCP було розроблено Bell Laboratories в 1977 році для зв'язку між розробниками Unix. В середині 1978 ця мережа вже нараховувала понад 80 сайтів. Вони використовували email та віддалений друк. Однак головним призначенням системи було розповсюдження нового програмного забезпечення та bugfixes. На зараз UUCP не обмежуються підтримкою тільки середовища Un*x. Існують як безкоштовні так і комерційні версії для різноманітних платформ, включаючи AmigaOS, DOS, Atari's TOS, то що.

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

Не дивлячись на ці обмеження, все ще існує велика кількість UUCP мереж у всьому світі, підтримувані в основному hobbyists, які надають приватно доступ до мереджі за розумні ціни. Головною причиною популярності UUCP є її дешевизна : в порівнянні з під'єднанням до The Big Internet Cable. Для того ж щоб зробити ваш комп'ютер UUCP вузлом вам потрібен лише модем, власне UUCP та інший UUCP вузол який бажає годувати вас поштою та новинами.

2.2.1 Як використовувати UUCP

Ідея UUCP досить проста (на що і вказує назва) : дозволяє копіювати файли від одного хоста до іншого, а також дозволяє виконувати певні операції на віддаленому хості.

Припустимо що ваша машина має доступ на віддалений хост swim, і ви хочете виконати команду lpr щоб щось надрукувати. Тоді ви повинні набрати наступне в вашій командній стрічці щоб надрукувати цю книгу на машині swim :

$ uux -r swim!lpr !netguide.dvi

Цю роботу виконує uux (команда з набору UUCP), заплановуючи завдання для swim. Це завдання складається з передачі файла netguide.dvi та роздруку його за допомогою lpr. Прапорець -r повідомляє uux що віддалену систему не треба викликати негайно, а зберігати завдання поки не буде встановлено з'єднання. Це називається спулінг.

Іншою особливістю UUCP є те, що вона дозволяє переправляти завдання та файли через декілька хостів, якщо ті співпрацюють. Припустимо що swim з попереднього прикладу має UUCP з'єднання з groucho, який містить великий архів програм для Un*x. Для того щоб скачати файл tripwire-1.0.tar.gz на ваш сайт, ви повинні набрати :

$ uucp -mr swim!groucho!~/security/tripwire-1.0.tar.gz

trip.tgz

Створене завдання дасть запит swim щоб той отримав файл від groucho та переслати його на ваш хост, де UUCP запише його у файл trip.tgz і повідомити вас через пошту про доставлення файлу. Це буде виконано за три кроки. На першому ваш сайт перешле завдання на swim. Коли swim встановить з'єднання з groucho в наступний раз, він завантажить звідти файл. Кінцевий крок - передача файлу з swim на ваш хост.

Найбільш важливими послугами які надають UUVP мережі на сьогодні є електронна пошта та новини. Ми повернемось до них пізніше, а зараз тільки коротко опишемо кожну з них.

Електронна пошта - коротко email - дозволяє вам листуватись з користувачами віддалених хостів без необхідності мати доступ до цих хостів. Завдання переправлення листа від вашого сайта до сайта призначення повністю покладене на систему обробки пошти. В середовищі UUCP пошта звичайно транспортується за допомогою команди rmail на сусідньому хості, пропускаючи адрес отримувача та саме повідомлення. rmail відправляє повідомлення сусідньому хосту, і так далі, поки це повідомлення не досягне місця призначення. Ми розглянемо це детальніше в главі 14.

Новини краще всього бути описані як вид BBS (bulletin board system). Найбільш часто цей термін означає новини Usenet, яка є найбільш широко відомою мережею обміну новинами з приблизно 120,000 учасників. Походження Usenet відноситься до 1979 року, коли, після випуску UUCP з новим Unix V7, три аспіранти задумали організувати загальний обмін інформацією в межах співтовариства Unix. Вони створили деякі скрипти, які і стали першою системою мережевих новин. В 1980 ця мережа об'єднала науковців двох університетів Північної Кароліни. Хоча Usenet було розроблено для базованих на UUCP мереж, на зараз його використання не обмежено тільки одним типом мереж.

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

В UUCP мережах новини передаються через UUCP з'єднання : вибираються всі статті з потрібних груп і пакуються в пачки. Їх надсилають приймаючій стороні де вони передаються команді rnews для розпакування та подальшої обробки.

На закінчення : UUCP це вибір для великої кількості архівних dial-up сайтів які надають загальнодоступний безкоштовний доступ. Ви можете з'єднатись з ними подзвонивши на їхню UUCP, ввійти як користувач guest, та зкачати потрібні файли. Гостьовий вхід здебільшо вхід та пароль подібний до guest/guest або подібний.

2.3 TCP/IP мережі

Хоча UUCP може бути розумним вибором для дешевих dial-up мережевих з'єднань, але існує багато ситуацій в яких технологія зберегти-і-передати (store-and-forward) недостатньо гнучка, наприлад в локальних мережах (LAN). Частіш за все LAN складається з невиликої кількості комп'ютерів розташованих в одному будинку чи навіть на одному поверсі і створюється для забезпечення однорідного робочого середовища. Здебільшого локальна мережа використовується для спільного використання файлів різними комп'ютерами та для виконання програмного забезпечення встановленого на одній машині на інших машинах.

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

Вибором при використанні Un*x систем --- і великої кількості не Un*x сайтів --- є TCP/IP. В цій секції ми оглянемо основні концепції TCP/IP.

2.3.1 Введення в TCP/IP мережі

Зачатки TCP/IP прослідковуються в дослідному проекті DARPA (Defense Advanced Research Projects Agency) 1969 року фінасованому Сполученими Штатами. Було створено експерементальний варіант мережі ARPANET, яку у 1975 було перетворено в експлуатаційну.

В 1983 році новий протокольний набір TCP/IP був прийнятий як стандарт і всі хости мережі почали його використовувати. Коли ARPANET переріс в Internet (ARPANET закінчив існування в 1990 році) то використання набору TCP/IP розповсюдилось на мережі за межами Internet. Найбільш відомими є використання TCP/IP в локальних мережах на базі Un*x, але з появою швидкісного цифрового телефонного обладнання, як то ISDN, може стати транспортним протоколом для dialup мереж.

Для більш конкретного розгляду TCP/IP та прикладів у цій та наступних секціях ми будемо використовувати Groucho Marx University (GMU), розташованого де небудь в Fredland. Більшість відділів працюють в своїх власних локальних мережах, деякі - об'єднані в одну, ще інші мають по кілька мереж на відділ. Всі вони пов'язані між собою за допомогою високошвидкісного з'єднання.

Припустимо що ваша Linux система erdos з'єднана з LAN через Un*x хост в Mathematics Departament. Для доступу до машини, скажімо quark, Physics Departament ви повинні набрати наступну команду :

           $ rlogin quark.physics

           Welcome to Physics Departament at GMU

           (ttyq2) login:

У відповідь на запрошення ви повинні ввести назву входу, наприклад andres, та ваш пароль. Після чого ви ввійдете в шелл на машині quark за допомогою якого ви зможете працювати з системою ніби ви знаходитесь за її консоллю. Після того як ви вийдете з шелла ви негайно повернетесь до запрошення вашої власної системи. Ви всього-навсього використовували один з миттєвих, діалогових сервісів TCP/IP : віддалений вхід (remote login).

При входженні на quark ви можете захотіти виконувати програми X11, наприклад програму виведення на принтер, або в'ювер PostScript. Щоб вказати таким програмам що ви хочете відображати результати роботи на вашому локальному дисплеї треба встановати змінну середовища DISPLAY :

           $ export DISPLAY=erdos.maths:0.0

Якщо після цього ви запустите вашу прикладну програму, то вона ввійде в контакт з вашим X-сервером а не з quark, і буде відображати всі вікна на вашому екрані. Звичайно потрібно щоб X11 було запущено на вашій машині (erdos). Це досягається завдяки тому що TCP/IP дозволяє quark та erdos обмінюватись X11 пакетами, що дає вам враження роботи в одній системі. В цьому питанні мережа практично прозора.

Іншою дуже важливою прикладною програмою в TCP/IP мережах є NFS (Network File Sytem - Мережева Файлова Система). Це інший засіб створення мережі прозорою який дозволяє монтувати каталоги з інших хостів мережі так, ніби це локальні файлові системи. Наприклад всі домашні каталоги користувачів знаходяться на центральному сервері, з якого всі інші хости локальної мережі монтують відповідні каталоги. Результатом цього буде те, що користувачі зможуть працювати з будь-якої локальної машини. Таким ж чином можна встановлювати пакети які потребують багато дискового простору (наприклад TeX) тільки на одній машині, та експортувати відповідні каталоги на інші комп'ютери. Ми повернемось до NFS в 12 главі.

Звичайно, це тільки приклади того що ви можете робити в TCP/IP мережах - меж можливостям практично не існує.

Тепер ми ближче розглянемо роботу TCP/IP мережі, що потрібно для того щоб ви розуміли як і для чого ви повинні конфігурувати вашу машину. Ми почнемо з досліджень апаратного забезпечення і повільно пройдемо наш шлях.

2.3.2 Ethernet-и

Найбільш популярний тип апаратного забезпечення який використовується в локальних мережах - Ethernet. Хости з'єднуються одним кабелем за допомогою конекторів, taps або трансиверів. Звичайний ethernet має досить низьку вартість, дозволяє передавати данні в мережі з швидкістю 10 Мбіт за секунду і є найбільш популярним в цьому класі.

Ethernet-и бувають трьох типів : тонкий, товстий та вита пара. Тонкий та товстий Ethernet використовують коаксильний кабель який відрізняється товщиною і максимальною довжиною на якій ви можете приєднувати хости. Тонкий Ethernet використовує T-подібні ``BNC'' конектори, які ви вставляєте в кабель та закручуєте ззаду комп'ютера. Використання товстого Ethernet вимагає щоб ви просверлили в кабелі маленький отвір і під'єднали його до трансивера за допомогою ``vampir taps''. До трансивера може бути під'єднано один чи більше хостів. Максимальна тонкого та товстого Ethernet - 200 та 500 метрів відповідно; тому їх ще називають 10base-2 та 10base-5. Вита пара використовує кабель зкручений з двох мідних дротів які також використовуються в звичайному телефонному обладнвнні, але потребує додаткового апаратного забезпечення. Відомий також як 10base-T.

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

Більшість людей надають перевагу тонкому Ethernet-у, так як це найдешевший варіант : карти для PC мають вартість близько 50 US$, кабель кілька центів за метер. Однак для велико-маштабних мереж перевагу слід надати товстому Ethernet-у. Наприклад в Департаменті Математики GMU використовується товстий Ethernet, що дозволяє не припиняти роботу мережі при під'єднанні нового хоста.

Один з недоліків технології Ethernet - обмеження на довжину кабелю яке не дозволяє використовувати його інакше як в локальній мережі. Однак кілька сегментів мережі Ethernet може бути з'єднано за допомогою повторювачів (repeaters), мостів (bridges) або маршрутизаторів (routers). Повторювачі просто копіюють сигнали між двома чи більше сегментами так, щоб всі ethernet-и в сегментах могли діяти як в одному сегменті. Часові обмеження потребують щоб між будь-якими двома хостами мережі не знаходилось більше чотирьох репітерів. Мости та маршрутизатори працюють за більш складною системою : вони аналізують данні що до них надходять та передають їх далі якщо хост не знаходиться в локальній мережі.

Ethernet працює подібно до системної шини - хост може посилати пакети (або фрейми) розміром до 1500 байт іншому хосту з такою ж картою ethernet. Адресою хоста є шестибайтне число зашите в ПЗУ карти Ethernet. Частіш за все ця адреса записується як послідовність байт в шістнадцятковому записі розділених двокрапкою : aa:bb:cc:dd:ee:ff.

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

2.3.3 Інші типи апаратного забезпечення

В великих мережах, як наприклад Університет Groucho Marx, ethernet здебільшого не єдиний тип використовуваного обладнання. В університеті наприклад всі відділи пов'язані з бекбоном за допомогою оптоволоконного кабелю під управлінням FDDI (Fiber Distributed Data Interface). FDDI використовує зовсім інший принцип передачі данних : який базується на передачі по колу маркерів, що дозволяє станції послати фрейм (данні) тільки приєднавши його до маркера. Головними перевагами FDDI є швидкість передачі данних до 100 Mbps та максимальна довжина кабелю до 200 км.

Для віддалених мережевих з'єднань використовується різноманітне обладнання базоване на стандарті X.25. Велика кількість так званих Загальнодоступних Мереж Данних (Public Data Network), наприклад Tymnet в США, Datex-P в Німеччині, надають цю послугу. X.25 вимагає специфічного обладнання яке називається PAD (Packet Assembler/Disassembler). X.25 використовує свій власний набір мережевих протоколів, але досить часто використовується для з'єднання мереж під управлінням TCP/IP та іншими протоколами. IP пакети не можуть бути просто перетворені в X.25 (і навпаки), вони енкапсулюються в X.25 та передаються по мережі.

Досить часто радіоаматори використовують X.25 обладнання для об'єднання своїх комп'ютерів в мережі; це так зване пакетне радіо або ham радіо. Протокол який використовується в ham радіо називається AX.25 (створений на основі X.25).

Інші методи дозволяють використовувати низькошвидкісні але дешеві послідовні лінії для dial-up під'єднання. Для цього використовуються інші протонколи передачі пакетів, як то SLIP чи PPP, які буде описано нижче.

2.3.4 Inetrnet Protocol

Звичайно ви були б не проти обмежитись використанням у вашій мережі тільки Ethernet-ами. Ідеально ви хотіли би могти використовувати мережу не залежно від типу апаратного забезпечення та кількості хостів. Для прикладу в великих мережах типу GMU може бути кілька підмереж Ethernet які з'єднані певним чином. Так математичний відділ використовує дві Ethernet підмережі : перша - швидкісна - для викладачів та дипломованих спеціалістів, друга - повільна - для студентів. Обидві підмережі з'єднані з університетським backbone за допомогою FDDI.

Такий зв'язок опрацьовується присвяченим хостом, так званим шлюзом (gateway), який працює з вхідними та вихідними пакетами копіюючи їх між двома Ethernet-ами та оптоволоконним кабелем. Для прикладу якщо ви знаходитесь в відділі математики і хочете ввійти на quark в відділі фізики з вашого Linux хоста, то мережеве програмне забезпечення не може послати пакети на quark безпосередньо, так як той не зноходиться в тому самому сегменті мережі. Тому в цбому випадку програмне забезпечення покладається на шляз як на експедитора (forwarder). Шлюз (його назва sophus) передасть ці пакети через бекбон на шлюз в відділі фізики - niels, а вже niels передасть його на хост призначення. Передачу данних між erdos та quark зображено на ілюстрації 2.3.4 (з вибаченнями для Guy L. Steele).

Така схема передачі данних віддаленому хосту називається маршрутизацією; в цьому контексті пакети ми часто будемо згадувати як датаграми. Для полегшення обмін датаграмами управляється у відповідності до одного протоколу, який є апаратно незалежним, і називається IP - Internet Protocol. В главі 3 ми детальніше розглянемо IP та супутні проблеми більш детально.

Головною перевагою IP є те, що він дозволяє об'єднати фізично різні мережі в одну однорідну мережу. Це так звана міжмережевість (internetworking), і як результат ``meta-network'' яка називається internet. Зверніть увагу на різницю між internet та Internet; остання - офіційна назва одної з глобальних мереж internet.

Звичайно що IP також потребує апаратно незалежної схеми адресації. Це досягнуто за допомогою присвоєння кожному хосту унікального 32-ох бітного номера, так званої IP адреси. Здебільшо IP адреса записується як чотири десяткових числа (кожна частина - 8 біт) розділених точками. Наприклад quark має IP адресу 0x954C0C04 яку також можна записати як 149.76.12.4. Цей метод запису називається dotted quad.

Таким чином ми зараз маємо три різних типи адресів : перший це назва хоста - наприклад quark, друга - це IP адреса, і на кінець існує адреса апаратного забезпечення (в нашому випадку це 6-ти байтна адреса Ethernet-а). Всі вони павинні певним чином відповідати одна одній, щоб коли Ви наберете rlogin quark, то мережеве програмне забезпечення повинно знайти IP адресу quark, а коли IP доставить данні до підмережі Ethernet в відділ фізики то воно пованно знайти відповідну до IP адреси адресу самої карти Ethernet. Все це звучить досить страшно.

Ілюстрація 1. Три кроки передачі датаграм від erdos до quark.

Детальніше ми розглянемо всі ці питання в главі 3. На зараз цього достатньо щоб знати що такі кроки по визначенню адрес називаються hostname resolution, для знаходження IP адреси за назвою хоста та address resolution для знаходження адреси апаратного забезпечення хоста.

2.3.5 IP через послідовні лінії

При послідовних з'єднаннях найчастіше використовується і є станартом ``de facto'' SLIP - Serial Line IP. Існує модифікація SLIP з компресією заголовків - CSLIP. Цей протокол є значно кращим від SLIP при використанні низькошвидкісних каналів зв'язку (4). Інший протокол передачі данних через послідовні з'єднання - PPP - Point-to-Point Protocol. PPP більш `продвинутий' ніж SLIP (особливо стадія встановлення з'єднання). Головною перевагою PPP перед SLIP є можливість передавати датаграми і інших відмінних від IP типів.

2.3.6 Transmission Control Protocol

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

Найважливіше що ви повинні знати про IP - це його ненадійність. Припустимо що десять людей почали скачувати останній реліз XFree86 з FTP сервера GMU через ваш ethernet. Об'єм трафіку в цьому випадку може бути завеликим для того щоб шлюз міг обробити його, так як він занадто повільний і обмежений в пам'яті. Якщо в цьому випадку ви пошлете пакет на quark то shopus не маючи вільних буферів не зміг би передати пакет далі. IP вирішує цю проблему просто - відмовляється від пакету (відповідно пакет безповоротньо втрачається). Тому відповідальність за перевірку цілісності та повноти данних лягає на підтримуючі зв'язок хости; у випадку помилки данні передаються повторно.

Це забезпечується за допогою протоколу TCP (Transmission Control Protocol) який працює поверх IP і забезпечує надійність служб. Важливою особливістю TCP є те, що він використовує IP для того що дати Вам видимість простого зв'язку між двома процесами на вашому хості та віддаленій машині, так, щоб ви не задумувались яким чином передаються ваші данні. TCP з'єднання працює подібно до двонапрямленого програмний канал (pipes) яке дозволяє писати та читати з нього. Думайте про це як про телефонну розмову.

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

В прикладі з rlogin, програма-клієнт (rlogin) відкриває порт на erdos, та під'єднується до порта 513 на quark, на якому висить сервер - rlogind. Таким чином встановлюється TCP з'єднання. Використовуючи це з'єднання, rlogind виконує процедуру авторизації та запускає шелл. Стандартний вхідний та вихідний потік переадресовуються на TCP з'єднання, так, щоб будь-які данні які ви наберете на своїй машині у відповідь на запрошення передадуться через TCP потік та сприймуться віддаленим шелом як стандартний вхід.

 

 

2.3.7 User Datagram Protocol

Звичайно TCP не єдиний користувачський протокол в TCP/IP сережах. Хоча TCP підходить для звернень типу rlogin, але великі затрати спричиняють неможливість використання в прикладних програмах типу NFS. Замість нього в таких випадках використовують подібний до TCP протокол UDP - User Datagram Protocol. Подібно до TCP, UDP також дозволює прикладній програмі під'єднатись до послуги на певному порті на віддаленій машині, але він на встановлює з'єднання для цього. Замість цього, протокол UDP дозволяє просто посилати окремі пакети на місце призначення (що відповідає його назві).

Припустіть що Ви змонтували ієрархію каталогу TeX з центрального NFS сервера (garois), і хочете подивитись документ в якому описано як використовувати LaTeX. Ви запускаєте редактор який для початку читає весь файл. Однак це займе досить багато часу : створити TCP з'єднання, отримати файл, відправити підтвердження. Замість цього робиться запит на galois, який посилає файл кількома UDP пакетами, що є значно швидше. Однак UDP не вміє опрацювувати помилки передачі пакетів та їх втрату. Ці обов'язки залишаються за прикладною програмою (у цьому випадку за NFS).

2.3.8 Детальніше про порти

Порти можуть розглядатись як точки приєднання для мережевих з'єднань. Якщо прикладна програма хоче запропонувати певну послугу, вона приєднується до певного порта та очікує запитів від клієнтів (цей процес також називають прослуховування порта - listening on the port). Клієнт який хоче використати цю послугу приєднується до порта на локальному хості і з'єднується з портом сервісу на віддаленій машині.

Важливою особливістю портів є те, що як тільки було встановлено з'єднання між клієнтом та сервером, інша копія сервера приєднується до порта і очікує звернень від інших клієнтів. Це дозволяє, для прикладу, декілька паралельних віддалених входів на той самий хост (при чому всі клієнти будь під'єднані до сервера через порт 513). TCP здатен розрізняти всі ці з'єднання одне від одного, так як вони відрізняються портами або хостами з якими відбувається з'єднання. Наприклад якщо ви двічі ввійдете на quark з erdos то локальний rlogin буде в першому випадку використовувати порт 1023, а другий - 1022. Однак на quark він буде під'єднаний до одного порта - 513 в обох випадках.

Цей приклад показує використання портів як точок зустрічі, де клієнт під'єднується до певного порта щоб отримати певну послугу. Для того щоб клієнт знав потрібний номер порта, повинно бути досягнена згода між адміністраторами обох систем про призначені сервісами номери портів. Для послуг тапу rlogin ці номери повинні встановлюватись централізовано. Станадартний варіант розміщення номерів регулярно випускає IETF (Internet Engineering Task Force) в RFC що називається Assigned Numbers. Linux використовує файл /etc/services для опису розміщення призначених для служб номерів. Детальніше описано в секції 10.3.

Коштує вказати що хоча і TCP, і UDP приєднуються на однакові порти, вони все одно не вступають в протиріччя. Це означає що, для прикладу, TCP порт 513 відрізняється від порта 513 UDP. Фактично ці порти слугують для доступу до двох відмінних послуг, TCP до rlogin, а UDP до rwho.

2.3.9 Бібліотека сокетів

В операційних системах Un*x, програмне забезпечення що забезпечує виконання всіх завдань та протоколів описаних вище знаходиться в ядрі, так само це і в Linux. Найбільш відомий програмний інтерфейс до мережі в Un*x світі - Berkeley Socket Library. Його назва походить від популярної аналогії в якій порти розглядаються як гнізда (сокети), та під'єднання до порта як включення (pluging in). В бібліотеку входять : запит (bind(2)) для виклику вказаного віддаленого хоста, транспортний протокол, та служби з допомогою яких програми можуть під'єднуватись або прослуховувати (запити connect(2), listen(2) та accept(2)). Бібліотека сокетів є дещо більш загальною - вона підтримує не лише один класс базованих на TCP/IP сокетів (сокети AF INET), а також і клас що вказує на локальні під'єднання до машини (AF UNIX). Деякі програми можуть також використовувати інші класи, типу XNS (Xerox Networking System) протокол, або X.25.

В Linux бібліотека сокетів - частина стандартної C бібілотеки libc. На зараз підримуються тільки сокети AF INET та AF UNIX, але робиться все, щоб включити підтримку протоколів мережі Novell, так, щоб один чи більше клас сокетів було добавлено.

2.4 Мережі в Linux

Будучи результатом концентрованих зусиль програмістів у всьому світі, Linux, з самогих початків, не міг існувати без глобальної мережі. Тому і не дивно що вже на початкових стадіях розробки, кілька людей розпочали роботу по підтримці мереж в Linux. UUCP працювала в Linux майже з самого початку, робота по підтримці TCP/IP в Linux почалась осінню 1992 року, коли Ross Biro та інші створили те, що тепер відоме як Net-1.

Після того як в травні 1993 Ross припинив подальшу роботу Fred van Kempen розпочав роботу над новим варіантом повністю переробивши основну частину коду. Це продовження називається Net-2. Перший загальнодоступний реліз - Net-2d - було зроблено літом 1992 (як частина ядра 0.99.10), і з тих пір він розвивається та підтримується кількома людьми (найбільш відомий Net-2Debugged від Alan Cox). Після тяжкої відладки та багаточисельних удосконалень Alan змінив назву на Net-3 і включив його в Linux 1.0. Це версія мережевого коду яка офіціно включається у всі ядро до тепер.

Net-3 підтримує драйвера пристроїв для різноманітних карт Ethernet, а також SLIP (для роботи через послідовних ліній), PLIP (для паралельних ліній). З Net-3 Linux досить непогано показав себе в роботі в локальних мережах, показуючи час роботи без перевантаження (uptimes) вищий ніж деякі комерційні Un*x-и. На данний момент ведуться роботи по забезпеченню необхідної стабільності та надійності для використання Linux в якості Internet хоста.

Навколо цих засобів обслуговування існує кілька проектів продовження яких буде збільшувати багатосторонність Linux. Драйвер для PPP (протокол point-to-point, інший варіант роботи через послідовні лінії), знаходиться в стадії Beta, драйвер AX.25 для ham radio - в стадії Alpha. Alan Cox також розробив драйвер для Novell IPX протоколу, але подальша розробка повної підтримки Novell призупинена через небажання Novell забезпечити розробника необхідною документацією. Іншим багатообіцючим проектом є samba - вільний для розповсюдження NetBIOS сервер для Un*x написаний Andrew Tridgell (~5).

2.4.1 Інші напрямки розробок

В той же час Fred продовжив розробку, назвавши нову версію Net-2e, в якії практично повністю наново переглянув мережевий рівень. На час написання кнаги Net-2e все ще розповсюджується як Beta. Найбільш відомою зміною в Net-2e є ідея DDI, Device Driver Interfce. DDI пропонує однорідний доступ та конфігурування всіх мережевих пристроїв та протоколів.

Інша цікава розробка для TCP/IP мереж - драйвер ISDN для Linux та FreeBSD який написав Matthias Urlichs. Для цього він інтегрував в ядро Linux-у частину мережевого коду BSD.

В найближчому майбутньому повинна бути дороблена Net-3. Зараз Alan працює над підтримкою протоколу AX.25 що використовуються в любительському радіо. Крім того він працює над ідеєю модулів (module), що принесло би свіжий подих в мережевий код. Модулі дозволять Вам добавляти драйвери в кернел прямо під час роботи (дозагружати в пам'ять).

Хоча всі ці варіанти мережевого коду в Linux забезпечують виконання одних і тих же послуг, існують великі відмінності між ними на рівнях ядра та пристроїв. Тому ви не зможете зконфігурувати систему використовуючи скажімо в ядрі код Net-2e а інструменти від Net-2d чи Net-3 та навпаки. Це стосується лише команд що працють з нутрощами ядра напряму; мережеві прикладні програми та інструменти (наприклад rlogin чи telnet) будуть працювати на будь якій з версій коду.

Однак всі ці різноманітні версії мережі не повинні хвилювати Вас. Якщо Ви не берете участі у розробці, Ви не повинні хвилюватись яка ж версія TCP/IP коду використовується у Вас. Офіційні випуски ядер завжди супроводжуються набором інструментів сумісним з мережевим кодом ядра.

2.4.2 Звідки можна забрати мережевий код

Остання версія мережевого коду для Linux можна знайти на різних анонімних FTP. Офіційним FTP сайтом для Net-3 є sunacm.swan.ac.uk, його дзеркало можна знайти на sunsite.unc.edu в system/Network/sunacm. Найостанніший комплект патчів та повна двійкова версія Net-2e знаходиться на ftp.aris.com. BSD-подібний код від Matthias Urlich є на ftp.ira.uka.de в каталозі /pub/system/linux/netbsd.

Останні версії ялра можна знайти на nic.funet.fi в каталозі /pub/OS/Linux/PEOPLE/Linus; на sunsite та tsx-11.mit.edu існує дзеркало цього каталогу.

2.5 Підтримка вашої системи

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

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

Результат роботи будь-якої програми що запускалась з cron, поинен бути відправлений адміністратору через пошту. По замовчуванню більшість програм посилають звіт про помилки, статистику вакористання, та просто статистику на root. Це має зміст тільки у тому випадку, якщо користувач root часто входить на машину; але ще краще переправляти всю пошту root-а на Вашу персональну адресу використовуючи поштові аліаси як це описано в глві 15.

І все ж як старанно Ви б не конфігурували Ваш сайт, Закони Мерфі гарантують що в кінцевому рахунку якась проблема вилізе. Тому підтримка системи також означає доступність для побажань та зауважень. Звичайно люди очікують що адміністраторові системи можна принаймі написати як root, але існуюють і інші адреси які здебільшо використовуються для можливості написати листа людині відповідальній за певне технічне обслуговування. Наприклад зауваження що до функціонування пошти найчастіше адресуються на postmaster; проблеми з системою новин можуть бути надіслані на newsmaster або usenet. Пошта відносно служби назв надсилається на hostmaster.

2.5.1 Безпека системи

Іншим дуже важливим аспектом адміністрування системи в мережевому середовищі є захист вашої системи та корисувачів від зловмисників. Легковажність в управлінні системами надає багато можливестей людям з поганим смаком : асортимент атаки починаючи з гостьових входів (guest) до Ethernet snooping, що може привести до фальшивих поштових повідомлень, втрати данних, порушення безпеки ваших користувачів. Ми згадаємо деякі специфічні проблеми при обговоренні певних тем де вони будуть зачеплені, та деякі загальні методи захисту.

У цьому розділі ми розглянемо кілька прикладів та базових методів по забезпеченню безпеки вашої системи. Звичайно ми не можемо повністю розглянути всі проблеми безпеки системи, ми тільки коротко розглянемо деякі з тих які можуть виникнути. Тому варто прочитати якусь книгу спеціально призначену проблемам захисту, особливо якщо ваша система працює в мережі. Ми радимо книгу Simon Garfinkel ``Practical UNIX Security'' (див. [ GETST "security" ]).

Безпека системи розпочинається з хорошого адміністрування системи. Це включає в себе перевірку прав володіння і доступу до всіх важливих файлів і каталогів, контроль використання првілегійованих входів, тощо. Програма COPS, для прикладу, буде перевіряти вашу файлову систему та конфігураційні файли на незвичні прва доступу та інші аномалії. Також варто застосовувати деякі прийоми щодо користувачських паролів, для того, щоб їх важче було зламати. Наприклад при використанні shadow password вимагається щоб пароль складався не менше 5 букв, що у ньому були букви верхнього, нижнього регістрів та цифри.

При створенні послуг доступних через мережу, впевніться, що ви встановили найменший необхідний рівень доступу (least privilege) і що ви не дозволили програмі робити речі яких вона не потребує для того щоб працювати як необхідно. Наприклад ви не повинні дозволяти програмі робити setuid на привелигійованих користувачів (якщо це не обговорено явно). Також якщо ви хочете обмежити доступ до якоїсь послуги, Ви повинні чітко це вказати в конфігурації програм які за це відповідатимуть. Наприклад якщо Ви хочете дозволити бездисковій станції завантажуватись з вашого хоста, Ви повинні встановити TFTP (trivial file transfer protocol) так, щоб станція могла зкачати базову конфігурацію з каталогу /boot. І в той же час Ви не повинні дозволяти необмежений доступ, інакше TFTP дозволить будь-якому користувачеві (з будь-якого куточку світу) зкачати будь-який загальнодоступний файл з Вашої системи. Якщо це не те чого Ви хочете, то чому б не обмежити доступ TFTP тільки каталогом /boot?

Продовжуючи цю думку ви можете захотіти обмежити використання певних послуг користувачами з певних хостів. в главі 10 ми розглянемо tcpd, який може це робити для різним мережевих програм-послуг.

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

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

 

 

 

 

3. Введення в організацію TCP/IP мереж

Тепер ми звернемось до проблем які виникнуть при під'єднанні вашої Linux машини до TCP/IP мережі таких як IP адреси, імена хостів, та різних проблем маршрутизації. Ця глава дасть вам підготовку яку Ви потребуєте для того щоб розуміти що ж Вам потріюно встановлювати, в подальших главах буде описано яким чином та які інстструменти потрібні для того щоб зробити це.

3.1 Мережеві інтерфейси

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

Для кожного перефирійного пристрою який ви хочете використовувати для організації мережі повинен бути присутнім в ядрі відповідний інтерфейс. Наприклад інтерфейси карт Ethernet в Linux називаються eth0, eth1..., SLIP інтерфейси - sl0, sl1, і т.д. Ці імена використовуються для конфігурування, коли Ви хочете вказати специфічний фізичний пристрій ядру. Ніякого значення крім цього вони не мають.

Щоб мати можливість використовувати інтерфейс для побудови TCP/IP мережі, йому повинен бути призначена IP адреса яка використовується як індифікаційний код при зв'язку з зовнішнім світом. Ця адреса відмінна від імені інтерфесу; якщо інтерфейс порівняти з дверми, тоді адреса - прикріплена на них табличка.

Звичайно, існують і інші параметри значення яких може бути встановленим; один з них - максимальний розмір датаграми яка може бути опрацьованою певним пристроєм що називаєьбся MTU (Maximum Transfer Unit). Інші параметри буде описано нижче.

3.2 IP адреси

Як згадувалось у попередній главі, прийнята в IP мережах адреса є 32-бітним числом. Кожна машина в мережі повинна мати унікальну адресу в мережі. Якщо ваша локальна мережа не має TCP/IP з'єднання з іншими мережами, ви можете використовувати будь-які адреси за вашим бажанням. Однак, для сайтів Inernet адреси виділяються NIC (Network Information Center).

Для більш легкого розуміння IP адреса розбита на чотири 8-ми бітних числа, названі октетом. Наприклад : quark.physics.groucho.edu має IP адресу 0x954C0C04, яке може бути описною як 149.76.12.4. Цей формат часто згадуються як dotted quad запис.

Іншою причиною використання dotted quad є те, що IP адреси розбиті на номер мережі, який знаходиться на початку, та номер хоста. При зверненні до NIC ви не отримаєте адреси для кожного окремо взятого хоста які ви плануєте використовувати. Замість цього вам надасться номер мережі, що дозволить призначати IP адреси у межах певного діапазону хостам мережі за вашим бажанням.

В залежності від розмірів мережі кількість адресів може бути більшою або меншою. Для розділу різних потреб існує кілька класів мереж від яких залежить максимальна ктлькість адремів для хостів.

Якщо ми повернемось до прикладу з попередньої глави, ми побачимо що адреса quark (149.76.12.4) відповідає хосту 12.4 в мережі класу B 149.76.0.0.

Як ви могли помітити, в вищезгаданому списку не всі можливі значення чисел використовуються в хостовій частині адреси. Це тому що номери хостів 0 та 255 зарезервовані для спеціального використання. Адреса в якій всі біти хостової частини дорівнюють 0 описує адресу мережі, а якщо всі біти хостової частини встановлені в 1 - то вона називається broadcast адресою. Таким чином адреса 149.76.255.255 не може бути адресою окремого хоста, але стосується (описує) всі хости мережі 149.76.0.0.

Існують також дві зарезервовані адреси мережі : 0.0.0.0 та 127.0.0.0. Перша називається маршрутом по замовчуванню, а друга - адреса петлі. Маршрут по замовчуванню використовується для маршрутизування IP пакетів (детальніше ми зупинимось на цьому нижче).

Мережа 127.0.0.0 зарезервована для IP трафіку локально на вашому хості. Найчастіше адреса 127.0.0.1 буде призначена спеціальному інтерфейсу на вашому хості, який називається інтерфейс петлі (loopback) і працює подібно до зациклене коло. Будь-який IP пакет переданий йому від TCP чи UDP буде так, ніби він надійшов з іншої мережі. Це дозволить вам розробляти та тестувати програмне забезпечення мережі без використання ``реальної'' мережі. Також це буде корисним якщо ви хочете використовувати мережеве програмне забезпечення на окремому (не під'єднаному до мережі) хості. Це може виглядати не так як звучить; для прикладу велика кількість UUCP сайтів не мають IP під'єднання взагалі, однак потребують роботи системи новин INN. Для роботи під Linux, INN потребує інтерфейс петлі.

3.3 Знаходження адреси (Address resolution)

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

Правильно. Саме тому є потреба в механізмі перетворення IP адреси в Ethernet адресу. Цей механізм називається Address Resolution Protocol (ARP). ARP не обмежений у використанні тільки з Ethernet, він також використовується в таких мережах як ham radio та подібних. Ідея що лежить в основі ARP така ж яку використовують більшість людей при пошуку пана X. Ample в натовпі (нехай з 150 людей): вони ідуть по колу викрикуючи його ім'я, поки він сам не відклинеться (якщо він є в натовпі).

Коли ARP хоче вияснити Ethernet адресу відповідну данній IP адресі, він використовує особливість Ethernet відому як ``broadcast'', при якій датаграми адресуються усім хостам в мережі одночасно. Датаграма broadcast посланий від ARP містить запит на IP адресу. Кожен хост який отримає запит порівнює його з власною IP адресою, і якщо вони співпадають, ARP відповідає хосту який давав запит. Тоді хост що давав запит може взяти Ethernet адресу з відповіді.

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

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

Інколи необхідно зробити обернену операцію - знайти IP адресу пов'язану з данною Ethernet адресою. Це відбувається коли бездискова станція хоче завантажитись з сервера в мережі, що є стандартною ситуацією в багатоьох локальних мережах. Бездисковий клієнт практично немає ніякої інформації відносно себе, крім Ethernet адреси. Тому він надсилає broadcast повідомлення, щоб сервер повідомив йому його IP адресу. Для цього і існує протокол RARP - Reverse Address Resolution Protocol. Разом з протоколом BOOTP, це дозволяє описати процедуру завантаження бездискового клієнта через мережу.

3.4 IP маршрутизація

3.4.1 IP мережі

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

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

3.4.2 Підмережі

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

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

Підмережа відповідає за доставку данних до певного діапазону IP адресів які є частиною IP мережі. Класи A, B та C описують мережеву частину IP адреси. Крім того мережеву частину може бути розширено за допомогою кількох біт хостової частини. Біти що інтерпретуються як номер підмережі називаються підмережевою маскою або маскою мережі (netmask). Це також 32-х бітне число що означує розрядну (біт) маску для мережевої частини IP адреси.

Ілюстрація 2.Підмережі в мережі класу B

Мережа університетського містечка Grounco Marx University - приклад такої мережі. Це мережа класу B з номером 149.76.0.0 і тому її маска - 255.255.0.0.

Сама ж мережа GMU складається з декількох менших мереж, типу локальних мереж різних відділів. Тому мережа розбита на 254 підмережі з адресами підмереж від 149.76.1.0 по 149.76.254.0. Наприклад відділ теоритичної фізики має адресу мережі 149.76.12.0. Бекбон університетського містечка використовує свою власну мережу з адресою 149.76.1.0. Всі підмережі мають спільну адресу мережі, а третій байт адреси використовується для того щоб відрізняти їх між собою. Таким чином всі вони будуть використовувати підмережеву маску 255.255.255.0.

На ілюстрації 3.4.2 показано як 149.76.12.4, адреса quark, інтерпретується по різному коли адресу як звичайна з класу B, та коли використовуються підмережі.

Слід зауважити що розбиття на підмережі (оскільки техніка створення підмереж описана) є внутрішньою справою мережі. Підмережі створються мержевим адміністратором. Часто підмережі створюються щоб відобразити існуючі границі: фізичні (між двома Ethernet підмережами), або адміністративні (між двома відділами), або географічні; і повноваження по цих підмережах надаються певній особі. Однак ця структура діє тільки в середині мережі і повністю невидима для зовнішнього світу.

3.4.3 Шлюзи.

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

Для того щоб IP міг легко розпізнати чи знаходиться хост у локальній фізичній мережі, різні фізичні мережі повинні мати різні IP адреси. Наприклад 149.76.4.0 зарезервовано для хостів локальної мережі математиків. При спробі передачі данних на quark, програмне забезпечення на erdos побачить що його IP адреса 149.76.12.4, і що він знаходиться у іншій фізичній мережі і може бути досягнутим лишень через шлюз (по замовчуванню sophus).

sophus безпосередньо звязаний з двома різними підмережами: відділом математики та університетським містечком. Ці підмережі доступні через різні інтерфейси, eth0 та fddi0 відповідно. І які ж адреси їм присвоєно? З підмережі 149.76.1.0 чи 149.76.4.0?

Відповідь: з обох. При обміні данними з хостами підмережі відділу математики sophus повинен використовувати IP адресу 149.76.4.1, а з backbone - 149.76.1.4.

Таким чином шлюз повинен мати по одній IP адресі на кожну мережу до якої його під'єднано фізично. Ці адреси разом з netmask пов'язані з інтерфейсом підмережі через який до них потрібно звертатись. Таким чином розкладка інтерфейсів та адресів на sophus повинна бути приблизно така :

        ----------------------------------------

        +-------+-------------+----------------+

        |iface  |    address  |       netmask  |

        +-------+-------------+----------------+

        +-------+-------------+----------------+

        |eth0   | 149.76.4.1  | 255.255.255.0  |

        |fddi0  | 149.76.1.4  | 255.255.255.0  |

        |lo     | 127.0.0.1   | 255.0.0.0      |

        +-------+-------------+----------------+

        +-------+-------------+----------------+

Ілюстрація 3.Частина топології мережі Grouncho Marx University.

Останнє входження описує інтерфейс петлі lo, який описано вище.

На ілюстрації 3.4.3 показано частину мережевої топології Grouncho Marx University (GMU). Хости що знаходяться в двох підмережах показано з обома адресами.

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

3.4.4 Таблиця маршрутизації

Тепер ми зосередимо увагу на тому як IP вибирає шлюз для доставки данних до віддаленої мережі.

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

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

        -----------------------------------------

        +------------+-------------+------------+

        |Network     | Gateway     | Interface  |

        +------------+-------------+------------+

        +------------+-------------+------------+

        | 149.76.1.0 | -           | fddi0      |

        | 149.76.2.0 | 149.76.1.2  | fddi0      |

        | 149.76.3.0 | 149.76.1.3  | fddi0      |

        | 149.76.4.0 | -           | eth0       |

        | 149.76.5.0 | 149.76.1.5  | fddi0      |

        |...         | ...         | ...        |

        | 0.0.0.0    | 149.76.1.2  | fddi0      |

        +------------+-------------+------------+

        +------------+-------------+------------+

Маршрути до мереж до яких sophus під'єднаний безпосередньо не потребують шлюзу; тому замість шлюзу вказано ``-''.

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

В залежності від розміру мережі можуть використовуватись різні протоколи маршрутизації. Для маршрутизації в середині автономних систем (наприклад університетської мережі) використовуються протоколи внутрішньої маршрутизації. Найбільш відомий з них - RIP (Routing Information Protocol), який підтримується демоном BSD - routed. Для маршрутизації між автономними системами використовуються протоколи зовнішньої маршрутизації типу EGP (External Gateway Protocol) та BGP (Border Gateway Protocol). Ці протоколи (і RIP також) підтримуються демоном gated розробленим Корнелівському університеті.

3.4.5 Метрична вартість

Динамічна маршрутизація базована на RIP вибирає найкращий маршрут до хоста чи мережі призначення за допомогою числа `хопів', яке означає через скільки шлюзів пройдуть данні перш ніж досягнуть місця призначення. Найкоротший маршрут вважається найкращим. Дуже довнгі марщрути (16 і більше хопів) вважаються як непридатні для використання і ігноруються.

Щоб використовувати RIP для управління інформацією про маршрутизацією в вашій локальній мережі, ви повинні виконувати gated на всіх хостах мережі. Під час завантаження gated перевіряє всі активні мережеві інтерфейси. Якщо існує більше ніж один активний інтерфейс (не рахуючи інтерфейсу петлі), то gated вважає що хост передає данні між різними мережами, і буде активно обмінюватись інформацією про маршрутизацію. В іншому випадку він буде просто пасивно отримувати RIP данні з змінами і відповідно змінювати локальну таблицю маршрутизації.

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

3.5 Internet Control Message Protocol

IP має супутній протокол про який ми ще не згадували. Це Internet Control Message Protocol (ICMP) і використовується він мережевим кодом ядра щоб передавати повідмлення про помилки та подібну інформацію на інші хости. Припустимо що ви знову знаходитесь на erdos і хочете за допомогою telnet звернутись до порта 12345 на quark, але на quark на цьому порті немає жодної програми. Коли перший TCP пакет для цього порта буде доставлено на quark, мережевий рівень розпізнає це і негайно відправить на erdos повідомлення ``Port Unreachable''.

Існує велика кількість повідомлень які розуміє ICMP, більшість з них - повідомлення про помилки. Однак існує одне дуже цікаве повідомлення - Redirect, яке генерується при знаходженні коротшого маршруту. Наприклад, після завантаження таблиці маршрутів на машині sophus, може виявитись, що вона неповна (містити маршрути до математичної мережі, до FDDI бекбону та маршрут по замовчуванню на шлюз в Комп'ютерному Центрі Grouncho - gcc1). Тому всі пакети для quark надсилались на gcc1, а не напряму через niels (шлюз у відділі Фізики). При отриманні таких данних, gcc1 побачить що це не найкращий маршрут, він передасть данні niels і в той же час поверне на sophus повідамлення ICMP Redirect про цей кращий маршрут.

Цей метод здається дуже розумним шляхом уникати потреби встановлювати "руками" будь-які маршрути крім основних. Однак попереджуємо, що використання динамічної схеми маршрутизації (будь то RIP або ICMP повідомлення Redirect) є не завжди хорошою ідеєю. Повідомлення ICMP Redirect та RIP мають невеликі можливості або взагалі не пропонують механізму підтвердження достовірності деякої інформації стосовно маршрутизації. Це дозволяє людям з поганими намірами порушити нормальну роботу вашої мережі, або зробити ще щось гірше. В зв'язку з цим існує кілька версій мережевого коду ядра Linux які опрацьовують повідомлення Redirect тільки для маршрутів хостів, а повідомлення про маршрути мереж ігноруються.

3.6 Система доменних назв (Domain Names System)

3.6.1 Знаходження назви хоста

<> Як описано вище, адресація в TCP/IP базується на 32-ох бітних числах. Але навряд чи ви зможете запам'ятати більше ніж кілька адресів. Тому хости мають ще `звичайну' назву - наприклад gauss чи strange. Для того того щоб мати можливість працювати з такими іменами потрібно найти IP адресу що відповідає певній назві. Цей процес і називається host name resulution.

Программа, якій потрібно знайти IP адресу данного хоста за назвою, не повинні використовувати своїх власних процедур знаходження хоста і його IP адреси. Замість цбого потрібно покладатись на бібліотечні функції gethostbyname(3) та gethostbyaddr(3), які забезпечують прозорість та сумісність. Традиціно ці та ще кілька подібних функцій згруповуються в окрему бібліотеку - бібліотеку resolver; в Linux ці функції частина стандартної бібліотеки libc.

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

Одним з вирішень цієї проблеми є NIS, Network Information System, що розроблена фірмою Sun Microsystems (в розмовній мові відома як YP, Yellow Pages -- Жовті Сторінки). NIS зберігає файл hosts (та іншу інформацію) в базі данних на основному хості, з якого клієнти можуть взяти потрібну їм інформацію. Цей підхід підходить лишень для мереж середніх розмірів типу LAN, так як необхідно зберігати повну базу hosts централізовано, і роздавати її всім серверам.

На початку, в Internet адресна інформація зберігалась в єдиній базі данних HOSTS.TXT. Цей файл знаходився в Network Information Center (або NIC), і повинен був зкачуватись та встаноновлюватись на всі підключені сайти. Коли мережа виросла то почали з'являтись деякі проблеми. Так як базу HOSTS.TXT потрібно було ругулярно обновлювати, то навантаження на центральний сервер стало занадто великим. Ще більш серйозною проблемою було те, що кожна назва повинна була реєструватись в NIC, який перевіряв чи ця назва вже не використовується.

Тому в 1984 році була прийнята нова схема вирішення назв - Domain Name System. DNS було розроблено Paul Mockapetris і він вирішує обидві проблеми одночасно.

3.6.2 Введення в DNS

DNS організовує назви хостів в ієрархію доменів. Домен (область) - набір сайтів що пов'язані певним чином --- наприклад формують якусь певну мережу (наприклад всі машини університетського містечка, або всі машини мережі BITNET), або належать певній організації (наприклад урядові США) або вони просто знаходяться географічно близько. Наприклад всі університети згруповані в домен edu, кожен Коледж чи Університет використовує окремий піддомен в який входять всі його хости. Університет Groucho Marx може мати домен groucho.edu, локальна мережа Математичного відділу - maths.groucho.edu. До назв хостів мережі відділу додавався би цей домен - відповідно машину erdos можна назвати erdos.maths.groucho.edu. Такий запис називається повною доменною назвою (або FQDN) і є унікальним ідентифікатором цього хоста для решти світу.

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

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

Ілюстрація 4. Частина назв доменів першого порядку

Технічно, перші чотири домена належать американській (США) частині Internet, але ви також можете побачити неамериканські сайти в цих доменах. Особливо це помітно для домену net. Однак домени mil та gov використовуються виключно в США.

За межами США кожна країна використовує свій власний двохбуквенний домен першого порядку (верхній домен) як це описано ISO-3166. Фінляндія, наприклад, використовує домен fi, домен fr використовується Францією, de - Німеччиною, au - Австралією і т.д.. Всі домени нижчих порядків (другого, третього, і т.д.) NIC кожної країни організовує за своїм бажанням. Австралія, для прикладу, має домену другого порядку подібнт до міжнародних доменів першого порядку : com.au, edu.au і т.д.. Інші, як наприклад Німеччина, не використовують цей додатковий рівень, що призводить до використання досить довгих назв доменів які безпосередньо стосуються організацій що керують відповідним доменом. Наприклад можна побачити хости типу ftp.informatik.uni-erlangen.edu. Віднесемо це до німецької ефективності.

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

Тепер, організувавши простір назв в ієрархії доменних назв, легко вирішується проблема унікальності назв; з DNS, назва хоста повинна бути унікальною тільки в межах домена для того щоб бути унікальною для решти світу. Крім того повні доменні назви досить прості для запам'ятовування. І вже це є непоганим резоном для розбиття великого домену на декілька піддоменів.

Але DNS дозволяє вам ще більше: дозволяє вам делегувати повноваження по піддоменах їх адміністраторам. Наприклад основний адміністратор GMU міг би створити піддомени для кожного відділу; ми вже зустрічались з математичним та фізичними піддоменами вище. Коли адміністратор побачив що мережа в відділі Фізики занадто велика і хаотична для управління ззовні (в кінці кінців фізики відомі як група буйних людей), він передав контроль над доменом physucs.groucho.edu адміністраторам цієї мережі. В цьому випадку вони зможуть призначати хостам назви та одреси локальної мережі як їм заманеться, без втручання ззовні.

На закінчення звернемо увагу, що простір назв розділюється на зони, кожна з яких містить домен. Зверніть увагу що зона відрізняється від домену: домен groucho.edu охоплює всі хости в мережі університету, в той час як зона grouch.edu містить лишень ті хости які безпосередньо управляються Комп'ютерним Центром (для прикладу у відділі Математики). Хости у відділі Фізики належать іншій зоні - physics.grouch.edu. На ілюстрації 3.6.2 початок зони відмічено кружком справа від назви домена.

3.6.3 Пошук назв через DNS

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

А тепер ми підійшли до дійсно цікавої частини стосовно DNS. Якщо вам потрібно дізнатись IP адресу erdos, то, DNS скаже, піди спитайся в людей що керують цим, і вони дадуть відповідь.

Фактично, DNS це гігантська розподілена база данних.Це досягається за допомогою так званих серверів назв що володіють інформацією стосовно данного домену чи набору доменів. Для кожної зони існує принаймі два, а частіш за все і більше, серверів імен що володіють авторизованою інформацією про хости в цій зоні. Щоб отримати IP адресу erdos, все, що потрібно зробити - з'єднатись з сервером для зони groucho.edu, який і надасть необхідні данні.

Ви можете думати що це легше описується, ніж виконується. Яким ж чином я можу взнати адресу сервера назв для Університету Groucho Marx? Якщо ваш комп'ютер не обладнаний персональним оракулом, то ви можете використати для цього DNS. Якщо ваша прикладна програма дасть запит про erdos, то для початку вона зв'яжеться з локальним сервером назв, який спродукує так званий інтераційний запит. Це буде запит до серера імен кореневого домена про машину erdos.maths.groucho.edu. Кореневий сервер назв розпізнає, що ця назва не належить його зоні повноважень, але належить десь глибоко в зоні edu. Таким чином, він повідомить, що потрібно ввійти в контакт з одним з серверів зони edu, список яких він надішле разом з їхніми адресами. Після цього ваш локальний сервер назв звернеться до одного з цих серверів, наприклад a.isi.edu. Подібним чином a.isi.edu повідомить, що зоною groucho.edu керують люди Університету, і направить вас до їхнього сервера. Локальний сервер назв звернеться з запитом стосовно erdos до одного з відповідальних за зону groucho.edu серверів, який накінець розпізнає назву як таку що належить його зоні і поверне IP адресу хоста erdos.

Це показує, наскільки великий трафік створюється при спробі знайти звичайну IP адресу, але все це ніщо у порівнянні з тією кількістю даних, які передавались би при використанні HOSTS.TXT. Але все ще існують щляхи для вдосконалення цієї схеми.

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

Звичайно що сервер назв не буде зберігати цю інформацію постійно, він відмовиться від неї через деякий час. Цей інтервал називається `час життя' (time to live - TTL). Кожен запис в базі данних DNS має присвоєний адміністратором зони TTL.

3.6.4 Domain Name Servers

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

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

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

Звичайно, ви можете хотіти використовувати сервер назв який не буде авторизованим для жодного домену (5). Такий сервер все одно може опацьовувати DNS запити від програм що працюють в локальній мережі та кешувати отриману інформацію. Такі сервери називаються caching-only серверами.

3.6.5 База данних DNS

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

Одиниця інформації в базі данних DNS називається записом ресурсів (resource record або RR). Кожен запис має тип (описує, які данні знаходяться в записі) та клас (задає тип мережі, до якої це застосовується). Останній потрібен для опису різних схем адресації, наприклад для IP (клас IN), або для Hesiod мереж (використовується в MIT), та багатьох інших. Типовим типом запису є A запис що зв'язує повну доменну назву з IP адресою.

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

Зараз ми не будемо розглядати всі типи записів (ми розглянемо їх в пізнішій главі), але все таки дамо кілька прикладів та коротко їх розглянемо. На ілюстрації 3.6.5 показано частину бази данних DNS яка завантажується в сервер назв для зони physics.groucho.edu.

Крім записів A та CNAME, на початку файлу ви можете побачити кілька спеціальних записів. Це запис SOA - Start of Autorisity (початок зони), в якому міститься основну інформацію сервера зони для якої він є головним. Наприклад тут описано значення по замовчуванню TTL для всіх записів.

Зверніть увагу, що всі назви в файлі які не закінчуються крапкою розглядаються відносно домену groucho.edu. Спеціальна назва ``@'' використовується в записі SOA для звернення до назви домену.

Ми розглянули вище сервер назв для домену grouncho.edu. Але так чи інакше цей сервер повинен знати щось стосовно зони physics, щоб переправляти запити до відповідного сервера назв. Це досягається за допомогою пари записів: запис NS описує повну доменну назву сервера назв, та запис A що описує IP адресу цього сервера. Так як ці записи тримають разом простір назв то їх часто називають glue (клеїними) записами. Ці записи - єдиний випадок коли батьківська зона фактично містить інформацію стосовно хоста з дочірньої зони. glue записи в зоні physics.groucho.edu показано на ілюстрації 3.6.5.

3.6.6 Зворотній пошук

            ;

            ; Authoritative Information on physics.groucho.edu

            @                     IN    SOA         {

                                 niels.physics.groucho.edu.

                                 hostmaster.niels.physics.groucho.edu.

                                 1034             ; serial no

                                 360000           ; refresh

                                 3600             ; retry

                                 3600000          ; expire

                                 3600             ; default ttl

                               }

            ;

            ; Name servers

                                  IN    NS       niels

                                  IN    NS       gauss.maths.groucho.edu.

            gauss.maths.groucho.edu. IN A        149.76.4.23

            ;

            ; Theoretical Physics (subnet 12)

            niels                 IN    A        149.76.12.1

                                  IN    A        149.76.1.12

            nameserver            IN    CNAME    niels

            otto                  IN    A        149.76.12.2

            quark                 IN    A        149.76.12.4

            down                  IN    A        149.76.12.5

            strange               IN    A        149.76.12.6

            ...

            ; Collider Lab. (subnet 14)

            boson                 IN    A        149.76.14.1

            muon                  IN    A        149.76.14.7

            bogon                 IN    A        149.76.14.12

            ...

Ілюстрація 5. Частина файлу named. hosts для відділу фізики.

Ми поговорили про пошук IP адреси хоста, але інколи потрібно з'ясувати канонічну назву хоста за його адресою. Це так званий метод зворотнього пошуку і використовується він деякими мережевими службами для індентифікації клієнта. При використанні тільки hosts файлу, зворотній пошук буде просто проглядати файл для знаходження хоста у якого IP адреса співпадає з запитом. При використанні DNS не існує проблем з пошуком назв. Для цього є спеціальний домен - in-addr.arpa, який містить IP адреси всіх хостів в оберненій dotted-quad формі. Наприклад IP адресі 149.76.12.4 відповідає 4.12.76.149.in-addr.arpa. Тип RR такого запису (зв'язок між адресою та назвою хоста) - PTR.

            ;

            ; Zone data for the groucho.edu zone.

            @                   IN       SOA          {

                                 vax12.gcc.groucho.edu.

                                 hostmaster.vax12.gcc.groucho.edu.

                                 233              ; serial no

                                 360000           ; refresh

                                 3600             ; retry

                                 3600000          ; expire

                                 3600             ; default ttl

                               }

            ....

            ;

            ; Glue records for the physics.groucho.edu zone

            physics             IN     NS        niels.physics.groucho.edu.

                                IN     NS        gauss.maths.groucho.edu.

            niels.physics       IN     A         149.76.12.1

            gauss.maths         IN     A         149.76.4.23

            ...

Ілюстрація 6. Частина файлу named.hosts для GMU.

Створеня зони авторифікації звичайно має на увазі що адміністраторам надається повний контроль над тим як вони призначають адреси хостам. Так як вони адмініструють одну або кілька IP мереж чи підмереж, існує також відношення один-да-багатьох між зонами DNS та IP мережами. Наприклад відділ фізики має підмережі 149.76.8.0, 149.76.12.0 та 149.76.14.0.

Як наслідок, нові in-addr.arpa зони повинні бути створені разом з зоною physics і делеговані аміністраторам мережі відділу: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa та 14.76.194.in-addr.arpa. В іншому випадку, при встановлені в лабораторії Collider нового хоста було б потрібно контактувати з адміністратором старшого домену щоб прописати нову адресу в їхньому файлі зони in-addr.arpa.

База зони для підмережі 12 показано на ілюстрації 3.6.6. Відповідні glue записи в базі данних їх батьківської зони показано на ілюстрації 3.6.6.

            ;

            ; the 12.76.149.in-addr.arpa domain.

            @                IN     SOA   {

                                 niels.physics.groucho.edu.

                                 hostmaster.niels.physics.groucho.edu.

                                 233 360000 3600 3600000 3600

                               }

            2                IN     PTR       otto.physics.groucho.edu.

            4                IN     PTR       quark.physics.groucho.edu.

            5                IN     PTR       down.physics.groucho.edu.

            6                IN     PTR       strange.physics.groucho.edu.

Ілюстрація 7. Частина файлу named.rev для підмережі 12.

            ;

            ; the 76.149.in-addr.arpa domain.

            @                   IN       SOA          {

                                 vax12.gcc.groucho.edu.

                                 hostmaster.vax12.gcc.groucho.edu.

                                 233 360000 3600 3600000 3600

                               }

            ...

            ; subnet 4: Mathematics Dept.

            1.4              IN     PTR      sophus.maths.groucho.edu.

            17.4             IN     PTR      erdos.maths.groucho.edu.

            23.4             IN     PTR      gauss.maths.groucho.edu.

            ...

            ; subnet 12: Physics Dept, separate zone

            12               IN     NS       niels.physics.groucho.edu.

                             IN     NS       gauss.maths.groucho.edu.

            niels.physics.groucho.edu. IN  A 149.76.12.1

            gauss.maths.groucho.edu. IN  A   149.76.4.23

            ...

Ілюстрація 8. Частина файлу named.rev для мережі 149.76.

Одним важливим наслідком є те що зони можуть бути створені лишень як супернабори IP мереж, і, що більш важливо, що їх мережеві маски повинні вирівнюватись на границю байта. Всі підмережі в Університеті Groucho Marx мають маски 255.255.255.0, і тому для кожної з них може бути створена зона in-addr.arpa. Однак якщо мережева маска має значення 255.255.255.128, то створення зон для підмережі 149.76.12.128 було б неможливим - неіснує ніякої можливості повідомити DNS що домен 149.76.149.in-addr.apra розділений на дві зони, з назвами хостів що розташовані від 1 до 127 та від 128 до 255 відповідно.

 

 

 

4. Конфігурування апаратного забезпечення мережі

4.1 Пристрої, драйвери, та інше

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

Спочатку, звичайно, існують безпосередньо апаратні засоби ЕОМ, для прикладу - карта Ethernet : це пластина з епоксидної смоли з великою кількістю маленьких чипів з незрозумілими номерами на них що знаходиться в гнізді вашого PC. Це - те що ми називаємо пристроєм.

Для того щоб ви могли використовувати карту Ethernet в ядрі Linux повинні бути представлені спеціальні функції які розуміють яким чином звертатись до пристрою. Ці функції називаються драйверами пристрою. Linux, наприклад, має драйвери пристроїв для кількох марок карт Ethernet які мають подібний набір функцій. Ці драйвери відомі як ``Becker Series Drivers'' і названі так за іменем їх автора Donald Becker. Іншим прикладом є драйвер D-Link який працює з кишеньковим адаптером D-Link що під'єднується через парарлельний порт.

Але що ж ми маємо на увазі коли говоримо що драйвер ``handles'' прострій? Давайте повернемось до вищезгаданої карти Ethernet. Драйвер повинен бути здатним зв'язатись з картою що дозволяє передавати команди та данні пристрою і в той же час карта повинна перадавати драйверу всі отримані данні.

В PC, цей зв'язок здійснюється через область пам'яті вводу-виводу яка розміщується на розташованих на платі регістрах. Всі команди та данні які ядро посилае карті повинні пройти через ці регістри. Пам'ять вводу-виводу повинна бути описана початковою (стартовою) чи базвовою адресою. Типововими базовими адресами карт Ethernet є 0x300 або 0x360.

Звичайно, ви не повинні хвилюватись відносно будь-яких проблем апаратних засобів ЕОМ типу базового адресу, так як під час завантаження ядро робить спробу розпізнати місцезнаходження карти. Це називається autoprobing і означає що ядро читає декілька місцезнаходжень пам'яті та порівнює зчитані данні з тими що були би при наявній Ethernet карті. Щоправда існують карти Ethernet які не розпізнаються автоматично; це інколи буває з дешевими картами котрі не є повністю сумісними клонами стандартних карт. Також ядро буде робити спробу знайти тільки один пристрій при завантаженні - якщо ж у вас більше, ви повинні описати ядру це явно.

Іншим параметром який ви можете повідомити ядру є IRQ (interrupt request channel). Компоненти апаратних засобів зазвичай переривають ядро коли потребують уваги, наприклад коли надходять данні або відбувається спеціальна ситуація. В PC переривання можуть відбуватись на одному з 16 спеціальних каналів які нумеруються від 0 до 15. Номер переривання призначений пристрою і називається IRQ.

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

Інтерфейси ідентифіковані за допомогою імен. Ці імена описані в ядрі і їм не відповідають файли пристроїв з катологу /dev. Вживані для інтерфейсів Ethernet імена - eth0, eth1 і т.д. Імена інтерфейсів здебільшо залежать від порядку в якому вони сконфігуровані. Наприклад перший знайдений пристрій Ethernet буде мати ім'я eth0, другий -eth1 і так далі. Є одне виключення з правила - імена інтерфейсів SLIP які присвоюються динамічно. Тобто кожного разу при встановленні SLIP з'єднання інтерфейс прикріплюється до послідовного порта.

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

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

            .

            .

           This processor honours the WP bit even when in supervisor mode. Good.

           Floppy drive(s): fd0 is 1.44M

           Swansea University Computer Society NET3.010

           IP Protocols: ICMP, UDP, TCP

           PPP: version 0.2.1 (4 channels) OPTIMIZE FLAGS

           TCP compression code copyright 1989 Regents of the University of California

           PPP line discipline registered.

           SLIP: version 0.7.5 (4 channels)

           CSLIP: code copyright 1989 Regents of the University of California

           dl0: D-Link DE-600 pocket adapter, Ethernet Address: 00:80:C8:71:76:95

           Checking 386/387 coupling... Ok, fpu using exception 16 error reporting.

           Linux version 1.1.11 (okir@monad) #3 Sat May 7 14:57:18 MET DST 1994

Це демонструє що ядро відкомпільоване з TCP/IP да драйверами SLIP, CSLIP, та PPP. Третя стрічка знизу повідомляє що адаптер D-Link був знайдений і встановлюється як інтерфейс dl0. Якщо ви маєте кілька різних Ethernet карт, ядро буде звичайно друкувати всі починаючи з eth0, супроводжуючи описом типу знайденої карти. Якщо ви маєте встановлену Ethernet карту але повідомлення такого типу про неї не буде, значить ядро не може самостійно її віднайти. Що робити в таких випадках буде описано нижче.

4.2 Конфігурування ядра

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

Щоб правильно управляти системою Linux ви повинні бути знайомими з побудовою ядра. Основи цього описані в книзі Matt Welsh's ``Installation and Getting Started'', яка є частиною проекту Linux Documentation Project. В цій секції, ми будемо обговорювати тілько ті опції конфігурації які торкаються організації мережі.

При виконанні make config, спочатку ви будете змушені відповісти на загальні питання конфігурації, типу включення/виключення емуляції матиматичного сопроцесора та таке інше. Одне з таких питань - підтримка TCP/IP мереж. Ви повинні відповісти ствердно якщо ви хочете отримати ядро що підтримує мережі.

4.2.1 Опції ядра для Linux 1.0 та вище

Після завершення загальної частини опцій, вас буде опитано на рахунок підтримки різноманітних розширень що можуть підтримуватись в Linux, наприклад SCSI драйвери, то що. Наступний список запитань відноситься до підтримки мереж. Точний набір опцій конфігурації постійно змінюється в зв'язку з розробкою. Типовий набір опцій що пропонується великою кількістю версій ядра близько 1.0 та 1.1 (коментарії подано в italic) :

           *

           * Network device support

           *

           Network device support? (CONFIG ETHERCARDS) [y]

Не дивлячись на назву макро що показане в дужках, ви повинні відповісти ствердно якщо ви хочете використовувати будь-який тип пристроїв орґанізації мережі, незалежно від того чи це Ethernet, SLIP, чи PPP. При відповіді y на це питання, підтримка пристроїв типу ethernet дозволяється автоматично. Підтримку для інших типів драйверів треба дозволяти окремо :

           SLIP (serial line) support? (CONFIG SLIP) [y]

            SLIP compressed headers (SL COMPRESSED) [y]

           PPP (point-to-point) support (CONFIG PPP) [y]

           PLIP (parallel port) support (CONFIG PLIP) [n]

Ці питання торкаються різних протоколів рівня зв'язку (link layer) що підтримуються в Linux. SLIP дозволяє транспортувати IP пакети через послідовні лінії. Вибір компресії заголовків забезпечує підтримку CSLIP, який стискає заголовки TCP/IP пакетів до трьох байт. Зверніть увагу на те що вибір цієї опції не означає автоматичного звернення до CSLIP, а тільки підтримку функцій для нього на рівні ядра.

PPP - інший протокол передачі данних через послідовні лінії. Він більш гнучкий ніж SLIP, і не прив'язаний до IP - підтримується, наприклад, IPX. Так як підтримка PPP була завершена тільки недавно, цього вибору може і не бути у вашій версії ядра.

PLIP забезпечує передачу IP пакетів поверх з'єднання через паралельні порти. Це головним чином використовується для під'єднання до машин під управлінням MS-DOS.

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

           NE2000/NE1000 support (CONFIG NE2000) [y]

           WD80*3 support (CONFIG WD80x3) [n]

           SMC Ultra support (CONFIG ULTRA) [n]

           3c501 support (CONFIG EL1) [n]

           3c503 support (CONFIG EL2) [n]

           3c509/3c579 support (CONFIG EL3) [n]

           HP PCLAN support (CONFIG HPLAN) [n]

           AT1500 and NE2100 (LANCE and PCnet-ISA) support (CONFIG LANCE) [n]

           AT1700 support (CONFIG AT1700) [n]

           DEPCA support (CONFIG DEPCA) [n]

           D-Link DE600 pocket adaptor support (CONFIG DE600) [y]

           AT-LAN-TEC/RealTek pocket adaptor support (CONFIG ATP) [n]

           *

           * CD-ROM drivers

           *

            ...

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

           NFS filesystem support (CONFIG NFS FS) [y]

4.2.2 Опції ядра для Linux 1.1.14 та вище

Починаючи з версії Linux 1.1.14, в якому добавлено підтримку IPX (alpha), процедура конфігурації дещо змінена. Загальна секція тепер запитує чи бажаєте ви включити підтримку мережі взагалі. Це зразу ж супроводжується кількома питаннями відносно орґанізації мережі.

           *

           * Networking options

           *

           TCP/IP networking (CONFIG INET) [y]

Щоб використовувати базовані на TCP/IP мережі, ви повинні відповісти ствердно на це питання. Якщо ж ви відмовитесь, то ви все ще можете ввімкнути підтримку мереж базованих на IPX.

           IP forwarding/gatewaying (CONFIG IP FORWARD) [n]

Ви повинні включити цю опцію якщо ваша система діє як шлюз (gateway) між двома Ethernet сегментами, чи між Ethernet та SLIP, то що. Для використання так званого firewall ви повинні вимкнути цю опцію. Firewalls дозволяє хосту що має з'єднання з двома чи більше мережами не маршрутизуючи трафік між ними. Це дозволяє забезпечити користувачів внутрішних (закритих) мереж орґанізацій вільним доступом назовні при мінімальному ризику для мережі. Користувачі будуть вільно входити на машину і використовувати послуги Internet, але внутрішні машини компанії будуть захищені від зовнішньої атаки так як вхідні з'єднання не зможуть подолати firewall.

           *

           * (it is safe to leave these untouched)

           *

           PC/TCP compatibility mode (CONFIG INET PCTCP) [n]

Ця опція вмикає режим сумісності з деякими версіями PC/TCP, комерційного пакету для DOS з використанням протоколив TCP/IP. Якщо ви ввімкнете цю опцію, ви будете нормально працювати з звичайними Un*x машинами, але швидкодія на повільних з'єднаннях може зменшитись.

           Reverse ARP (CONFIG INET RARP) [n]

Ця функція дозволяє RARP, Reverse Address Resolution Protocol. RARP використовується бездисковими станціями та X терміналами для отримання IP адреси при завантаженні. Ви повинні дозволити RARP тільки якщо ви плануєте обслуговувати такого типу клієнтів. Остання версія пакету мережевих програм (net-0.32d) містить корисну маленьку програму rarp яка дозволить вам добавляти системи в кеш rarp.

           Assume subnets are local (CONFIG INET SNARL) [y]

При посилці данних через TCP, ядро повинно розбивати потік на декілька пакетів перед передачею їх IP. Для хоста що знаходиться в локальній мережі (наприклад Ethernet) будуть використовуватись більші за розміром пакети ніж для машини з'єднання з якою проходить через кілька хостів. Якщо ви не ввімкнете SNARL, ядро буде сприймати місцевими тільки ті мережі з якими є безпосереднє з'єднання. Однак якщо ви глянете на мережі классу B в Groucho Marx University то всі вони є локальними, хоча під'єднання в кожної з них є тільки до одної чи двох. Якщо ви дозволите SNARL, то ядро буде вважати що всі підмережі локальні та використовувати великі пакети при обміні данними зі всіма хостами в університетському містечку.

Якщо ви хочете використовувати менші розміри пакетів для передачі данних на окремий хост (наприклад при передачі данних через SLIP з'єднання), ви повинні використовувати опцію mtu як це описано в кінці цієї глави.

           Disable NAGLE algorithm (normally enabled) (CONFIG TCP NAGLE OFF) [n]

Правило Nagle дозволюя уникати відправлення дуже малих IP пакетів (званих також tinygrams). Tinygrams здебільшо створюються діалоговими мережевими програмами які видправляють окремі стрічки, як то telnet або rsh. Tinygram можуть стати особливо неприємними на низькошвидкісних каналах типу SLIP. Алгоритм Nagle пробує уникнути їх стримуючи передачу данних TCP в деяких випадках. Ви можете відключити алгоритм якщо у вас пропадають (dropped) пакети.

           IPX protocol (CONFIG IPX) [n]

Дозволяє підтримку для IPX, транспортного протоколу що використовується Novell NetWare. Підтримка IPX все ще знаходиться в розробці і не є повноцінною. Єдина користь з цього - можливість обміну данними з базованими на IPX програмами для DOS та маршрутизувати трафік між вашими базованими на Novell мережами через PPP з'єднання. Підтримка протоколів Novell високого рівня не очікується в найближчому майбутньому, так як їх специфікації доступні за великі кошти і підпадають під домовленість про нерозповсюдження.

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

          Dummy net driver support (CONFIG DUMMY) [y]

Фіктивний драйвер реально нічого не робить, але може бути корисним на окремому чи SLIP хості. Це - в основному замаскований інтерфейс петля. Причиною щоб використовувати цей драйвер може бути використання SLIP при відсутності Ethernet - в цьому випадку цей інтерфейс буде тримати вашу IP адресу весь час. Більш детально це питання буде обговорено в секції 6.7.7.

4.3 Тур по мережевих пристроях Linux

Ядро Linux підтримує ряд драйверів для апаратних засобів різних типів обладнання. В цій секції дано короткий огляд типів драйверів та імен інтерфейсів що використовуються для них.

Існує ряд стандартних імен для інтерфейсів в Linux, які внесені в розташований нижче список. Якщо драйвери підтримують більше ніж один інтерфейс то імена до них перечисляються - наприклад - eth0, eth1 і т.д.

             Lo локальний інтерфейс петля. Використовується для тестових

                цілей. Працює подібно до закритого кругообігу в якому будь

                яка послана датаграма буде негайно повернена на мережевому

                рівні хоста. Існує тільки один пристрій петля і немає сенсу

                в його більшій чи меншій кількості.

           Ethn n-а Ethernet карта. Це ім'я інтерфейса для більшості

                Ethernet карт.

            Dln Ім'я інтерфейсу для D-Link DE-600 адаптерів, одного з типів

                пристрою Ethernet. Має спеціальне ім'я в зв'язку з тим що

                працює через паралельний порт.

            Sln n-ий SLIP інтерфейс. Інтерфейси SLIP зв'язані з послідовними

                лініями в порядку їх розміщення для SLIP; тобто перша

                послідовна лінія встановлена (піднята) для SLIP стає sl0 і

                т.д. Ядро підтримує до чотирьох інтерфейсів SLIP.

           Pppn n-ий PPP інтерфейс. Як і SLIP інтерфейс, PPP зв'язаний з

                послідовною лінією переведеною в режим PPP. На данний момент

                підтримується до чотирьох PPP інтерфейсів.

          Plipn n-ий PLIP інтерфейс. PLIP передає IP датаграми через

                паралельні лінії. До трьох PLIP інтерфесів підтримується.

                Вони ініціалізуються драйверами PLIP під час завантаження і

                при'єднані до відповідних паралельних портів.

Для інших інтерфейсних драйверів які можуть бути добавлені в майбутньому, типу ISDN чи AX.25 будуть вводитись інші імена. Драйвери для IPX (базовий протокол мереж Novell) та AX.25 (використовується в ham radio) на стадії розробки, але все ще у версії alpha.

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

4.4 Встановлення Ethernet

Біжучий мережевий код Linux підтримує різноманітні Ethernet карти. Більшість драйверів були написані Donald Becker (becker@super.org), який є автором Becker Series Drivers для карт що базуються на чипі 8390 фірми National Seminconductor. Існуює також кілька драйверів для продукції фірми D-Link, серед них драйвер для D-Link pocket adaptor що дозволяє доступатись до Ethernet через паралельний порт. Цей драйвер написано Bjrn Ekwall (bj0rn@blox.se). Драйвер для DEPCA написаний David C. Davies (davies@wanton.lkg.dec.com).

4.4.1 Кабелі для Ethernet

Якщо ви встановлюєте Ethernet вперше в житті, декілька слів відносно прокладки та монтажу кабеля. Ethernet потребує високої надійності з'єднань, а на обох кінцях кабелю повинні бути термінатори - 50 Ом-ні резистори. Ви не повинні мати інших розгалужень (наприклад три кабелі що під'єднано у формі зірки). Якщо ви використовуєте коаксильний кабель з T та BNC конекторами, то BNC конектор повинен під'єднуватись до конектора на платі безпосередньо; ви не повинні вставляти додатковий сегмент кабелю між ними.

Якщо ви під'єднуєтесь до thicknet, ви можете з'єднати ваші хости через трансивер (інколи також відомий як Ethernet Attachment Unit). Ви можете підключити трансивер в 25-піновий AUI порт на вашій карті безпосередньо або використовуючи захищений кабель.

4.4.2 Підтримка пристроїв

Повний список підтримуваних карт знаходиться в Ethernet HOWTO яке щомісячно посилається в comp.os.linux.anounce Paul Gortmaker.

Нижче подано список найбільш відомих пристроїв що підтримуюьться в Linux. Біжучий список з HOWTO приблизно в три рази більший. Навіть якщо ви знайдете карту що є у вас в цьому списку - перевірте HOWTO, там інколи можна знайти важливі деталі відносно деяких карт. Одною з таких деталей є використання деякими базованими на DMA Ethernet картами того ж самого DMA каналу по замовчуванню що і Adpaptec 1542 SCSI. Якщо ви не перемістите одну з плат на інший канал то закінчиться тим, що ваша карта Ethernet запише данні на довільне місце на вашому твердому диску.

      3Com EtherLink 3c503, 3c503/16, 3c507 та 3c509 підтримуються. 3c501

                також підтримується, але він занадто повільний щоб його

                коштувало використовувати.

      Novell Eagle NE1000, NE2000, та їх різноманітні клони. NE1500 та NE2100

                підтримуються також.

      Western Digital/SMC WD8003 та WD8013 (те саме що й SMC Elite і SMC

                Elite Plus), а також більш нова SMC Elite 16 Ultra.

      Hewlett Packard HP 27252, HP 27247B, та HP J2405A.

         D-Link DE-600 pocket adaptor, DE-100, DE-200, та DE-220-T. Існує

                патч для DE-650-T, яка є PCMCIA картою.

            DEC DE200 (32K/64K), DE202, DE100, та DEPCA rev E.

      Allied Teliesis AT1500 та AT1700.

Щоб використовувати одну з цих карт з Linux, ви можете використовувати готове ядро з нових дистрибутивів Linux. Вони мають вбудовані драйвери для всіх цих карт. Пізніше варто зкомпілювати власне ядро з під'єднанням тільки потрібних драйверів.

4.4.3 Автопошук Ethernet

Під час завантаження, код Ethernet спробує знайти вашу карту та розпізнати її тип. Карти шукаються по наступних адресах та в такому порядку :

      ------------------------------------------------------

      +--------------+-------------------------------------+

      | Карта        |             Адреса для пошуку       |

      +--------------+-------------------------------------+

      | WD/SMC       | 0x300, 0x280, 0x380, 0x240          |

      | SMC 16 Ultra | 0x300, 0x280                        |

      | 3c501        | 0x280                               |

      | 3c503        | 0x300, 0x310, 0x330, 0x350, 0x250,  |

      |              | 0x280, 0x2a0, 0x2e0                 |

      | NEx000       | 0x300, 0x280, 0x320, 0x340, 0x360   |

      | HP           | 0x300, 0x320, 0x340, 0x280, 0x2C0,  |

      |              | 0x200, 0x240                        |

      | DEPCA        | 0x300, 0x320, 0x340, 0x360          |

      +--------------+-------------------------------------+

      +--------------+-------------------------------------+

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

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

В Net-3 це можна зробити використовуючи дві різні схеми. Перший шлях - замінити чи добавити інформацію в файлі drivers/net/Space.c вихідномого коду ядра який містить всю інформацію про драйвери. Це рекомендується в тому випадку якщо ви знайомі з мережевим кодом. Ще кращий шлях полягає у забезпеченні ядра потрібною інформацією під час завантаження. Якщо ви використовуєте lilo для завнтаження системи, ви можете передати потрібні параметри ядру записавши їх в кінці файлу lilo.conf. Щоб повідомити ядро про використання пристрою Ethernet ви можете встановити наступні параметри :

           ether=irq,base addr,param1,param2,name

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

Перший параметер встановлює призначений для пристрою IRQ. По замовчуванню ядро спробує автоматично віднайти IRQ-канал пристрою. Драйвер 3с503 має особливість яка дозволяє йому вибирати вільне IRQ зі списку (5, 9, 3, 4) та відповідно конфігурувати карту для його використання.

Параметер base addr встановлює базову адресу вводу/виводу карти; при значенні нуль ядро буде шукати його з описаного вище списку.

Наступні два параметри можуть використовуватись по різному різними картами. Для карт з розділюваною (shared) пам'ятю, наприклад WD80x3, можна означити початкову та кінцеву адресу області розділюваної пам'яті. Інші карти здебільшо використовують param1 для встановлення рівню відладкової інформації яка буде відображатись. 0 (по замовчуванню) означає відключення режиму відладки, 8 - максимальний рівень, а від 1 до 7 - відповідні рівні відладки. Драйвер 3c503 використовує param2 для вибору внутрішнього (по замовчуванню) чи зовнішнього (значення - 1) трансивера. Згадані вище карти використовують BNC конектори, всі інші - AUI порт.

Якщо у вас дві Ethernet карти, то першу Linux розпізнає сам, а параметри для другої ви можете передати через lilo. Але перш за все ви повинні пересвідчитись щоб драйвер випадково спочатку не знаходив другу карту, чи взагалі не знаходив жодної. Ви можете передати ядру щоб воно не використовувало певну адресу (базову адресу другого пристрою) при пошуку першого.

Наприклад, щоб Linux встонивив другу карту Ethernet на 0x300 як eth1, ви повинні передати наступні параметри ядру :

           reserve=0x300,32 ether=0,0x300,eth1

Опція reserve робить недоступною описану адресу вводу/виводу деякої карти при автопошуці пристроїв. Ви можете також використовувати параметри ядра для перозначення автопошуку для пристрою :

           reserve=0x340,32 ether=0,0x340,eth0

Щоб вимкнути режим автопошуку повністю, ви повинні встановити змінну base addr в -1 :

           ether=0,-1,eth0

4.5 Драйвер PLIP

PLIP (Parallel Line IP) є дешевим шляхом для створення мережі, якщо ви хочете з'єднати тільки два комп'ютери. Він використовує паралельний порт та спеціальний кабель і дозволяє досягати швидкості від 10 до 20 kBps.

PLIP був розроблений у Crynw, Inc. Цей проект досить винахідливий (чи, якщо ви надаєте перевагу, хакерський) : досить довгий час паралельні порти на PC використовувались тільки для передачі данних на принтер; тобто вісім ліній данних могли використовуватись тільки для цього, і не інакше. PLIP обходить це обмеження використовуючи п'ять ліній стану порту, що обмежує передачу всіх данних тільки nibbles (половиною байта). Цей режим передачі відомий як zero PLIP. На сьогодні однонаправлені порти майже не використовуються і існує розширення PLIP яке використовує повний 8 розрядний інтерфейс.

На данний момент Linux підтримує єдиний спосіб - 0. На відміну від більш ранніх версій PLIP коду тепер він сумісний з PLIP розробленим Crynwr, а також PLIP драйвер від NCSA telnet. Щоб з'єднати дві машини використовуючи PLIP вам потрібен спеціальний кабель що продається в деяких магазинах як ``Null Printer'' або ``Turbo Laplink'' кабель. Ви, однак, можете легко зробити його самі як показано в Додатку 20.3.

PLIP драйвер для Linux - вихід для багатьох обмежених в коштах. Данна версія розроблена та підтримується Niible Yutaka. При компіляції ядра з підтримкою PLIP створюються мережеві інтерфейси для кожного з доступних портів принтера. plip0 відповідає lp0, plip1 - lp1 і т.д. Розташування інтерфейсів відповідно до портів на цей час :

      --------------------------------

      +-----------+-----------+------+

      |Interface  | I/O Port  | IRQ  |

      +-----------+-----------+------+

      | plip0     | 0x3BC     | 7    |

      | plip1     | 0x378     | 7    |

      | plip2     | 0x278     | 5    |

      +-----------+-----------+------+

      +-----------+-----------+------+

Якщо ви хочете сконфігурувати ваш порт принтера іншим чином то ви повинні змінити відповідні значення в drivers/net/Space.c в вихідниках ядра та зібрати нове ядро.

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

4.6 Драйвер SLIP та PPP

SLIP (Serial Line IP) та PPP (Point-to-Point Protocol) - широко використовувані протоколи для пересилання IP пакетів через послідовні лінії. Велика кількість орґанізацій пропонують dialup SLIP та PPP на машини для доступу в Internet, надаючи таким чинам IP під'єднання приватним особам (іншим чином це навряд чи можливо).

Для використання SLIP чи PPP не потрібні ніякі модифікації апаратних засобів PC. Ви можете використовувати будь-який послідовний порт. Так як конфігурування послідовного порта не відноситься до будування мереж TCP/IP то цьому присвячено окрему главу (глава 5).

 

 

 

 

Встановлення апаратного забезпечення

Велика кiлькiсть людей що працюють з мережею на своїх власних PC не мають грошей для оплати пiд'єднання до Internet через канал T1. Щоб мати можливiсть користуватися поштою та новинами використовуються пiд'еднання по протоколу SLIP, UUPC-мережi та BBS, що надають доступ через звичйну загальнодоступну телефонну мережу.

Ця глава описує як правильно сконфiгурувати ваше програмне забезпечення для нормальної роботи, сюди не входить опис конфiгурування вашого модему - про те як його сконфiгурувати ви можете прочитати в Serial HOWTO Greg Hankins яке регулярно друкується в конференцiї comp.os.linux.announce.

5.1 Комунiкацiйне програмне забезпечення для роботи з модемом.

Велика кiлькiсть комунiкацiйних пакетiв доступна пiд Linux. Багато з них є термiнальними програмами якi дозволяють користувачевi дзвонити на iнший комп'ютер i працювати як звичайний термiнал. Традицiйною для Un*x термiнальною програмою є kermit. Вона,щоправда,досить спартаньська, є бiльш комфортабельнi програми що пiдтримують записну книжку телефонних номерiв, мову скриптiв для виклику та входу на вiддалену систему, iнше. Одною з таких програм є minicom. Є також термiнальнi пакети пiд X, наприклад seyon.

Також е досить багато працюючих пiд Linux BBS. Деякi з них доступнi на sunsite.unc.edu в каталозi /pub/Linux/system/BBS.

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

Цей тип комунiкацiйного програмного забезпечення називаеться UUCP. Це є набір програм які копiюють файли з одного хоста на iнший, виконують програми на вiддаленiй машинi, то що. Це є найбiльш вживаний транспорт для пошти та новин в приватних мережах. Пакет UUCP Ian Taylor, який працює пiд Linux, буде описаний в наступній главі. Iнше неiнтерактивне комунiкацiйне забезпечення використовуеться, для прикладу, в Fidonet. Портоване програмне забезпечення Fidonet, типу ifmail,також є доступним.

SLIP (serial line Internet Protocol) можна використовувати як в релальному часi так i неiнтерактивно. Багато людей використовують SLIP для зв'язку з своєю унiверситетською мережею чи iншими загально- доступними SLIP серверами для використання FTP, то що. SLIP також може використовуватися для постiйних та напiвпостiйних зв'язкiв LAN-to-LAN, хоча ISDN є бiльш професiйним вирiшенням.

5.2 Введення в послiдовнi пристрої.

Звичайно iмена послiдовних пристроiв в Un*x починаються з ttys. Це скорочення вiд Teletype(tm), яке використовувалось в раннiх версiях Unix як термiнал. Цей термін на данний час використовуеться для рiзних символьних термiналiв. Проте в цiй главi буде розлянуто рзглянуто term виключно щодо пристроїв ядра.

Linux пiдтримує три класи ttys: (вiртуальнi) консолi, псевдо термiнали (подiбно до двонапрямлених pipe, використовується програмами типу X11), i послiдовнi пристрої. Останнi також рахуються як ttys, тому вони дозволяють проводити сессiю через послiдовне пiд'єднання; це може бути вiддалений термiнал чи вiддалений комп'ютер зв'язаний через телефонну лiнiю.

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

Серед найбільш важливих параметрiв є швидiсть лiнiї та її парнiсть. Крiм того е також прапорцi (flags) для перетворення у верхнiй чи нижнiй регiстри символiв,то що.Драйвер tty може також пiдтримувати рiзноманiтнi описи лiнiй якi використовуються рiзними драйверами пристроїв. Для прикладу, драйвер SLIP для Linux використовуе спецiальний опис лінії.

Існує деяка неоднозначність відносно того як вимірювати швидкість лінії.Коректним термiном є Bit rate, який описує швидкiсть лiнiї в бiтах на секунду (bit per second або bps). Iнколи ви можете почути термiн Baud Rate - це не зовсiм коректно. Цi два термiни не є взаємозамiнюваними. Baud Rate описує фiзичну швидкiсть послiдовного пристрою в символах за секунду. Bit rate описуе бiжучий стан присутнього послiдовного з'єднання мiж двома точками, i означає середню швидкiсть передачi данних в бiтах за секунду. Важливо знати що їх значення здебільшого різні, так як пристрої в основному кодують більше одного біта за елетричний імпульс.

5.3 Доступ до послiдовних пристроiв.

Подiбно до всiх пристроїв в Un*x системах, послiдовнi доступнi через спецiальнi файли пристроїв що знаходятья в каталозi /dev. Є два рiзних типи файлiв пристроїв що зв'язанi з послiдовними драйверами кожного порта, по одному файлу пристрою кожного типу. Залежно вiд того через який файл вiдбуваеться доступ пристрiй буде поводитися по рiзному.

Перший тип файлів пристроїв використовується для вхiдних дзвiнкiв; їх старший номер (major number) е 4, а файли називаються ttyS0, ttyS1, то що. Другий тип використовується для вихiдних дзвiнкiв через порт; файли пристроїв назифаються cua0, i т.д., їх старший номер - 5.

Молодший номер є однаковим для обох типiв. Якщо ви маєте модем на одному з послiдовних портiв вiд COM1 до COM4, то молодшим номером має бути 63 + номер COM порта. Якщо ваш setup вiдрiзняеться вiд цього, для прикладу коли ви виористовуєте багатопортову (multiport) карту, будь ласка перечитайте Serial HOWTO.

Припустимо ваш модем знаходиться на COM2. Його молодше число 65, i його старше число 5 для вихiдних дзвiнкiв. Це має бути пристрiй cua1 з цими номерами. Прогляньте послiдовнi ttys в каталозi /dev. Колонки 5 i 6 є старшим та молодшим номерами вiдповiдно :

      $ ls -l /dev/cua*

      crw-rw-rw-   1 root     root       5,  64 Nov 30 19:31 /dev/cua0

      crw-rw-rw-   1 root     root       5,  65 Nov 30 22:08 /dev/cua1

      crw-rw-rw-   1 root     root       5,  66 Oct 28 11:56 /dev/cua2

      crw-rw-rw-   1 root     root       5,  67 Mar 19  1992 /dev/cua3

Якщо цих пристроiв немае, ви повиннi створити їх : зайдiть пiд super-user i наберiть

      # mknod -m 666 /dev/cua1 c 5 65

      # chown root.root /dev/cua1

Деякi люди радять створити символьний зв'язок /dev/modem з вашим пристроєм, це тi неуважнi користувачi якi не можуть запам'ятати що це cua1. Запам'ятайте, що ви не можете використовувати modem в однiй програмi i реальний файл пристрою в iншiй. Це тому, що програми використовують lock файли для ознаки зайнятостi пристрою. lock файл для пристрою cua1 буде LCK..cua1. Використання рiзних файлiв пристроїв для одного порта створює ситуацiю коли програми не можуть розпiзнати lock файли iнших програм i використовують пристрiй одночасно. Як результат обидвi програми взагалi не працюють.

5.4 Послiдовне апаратне забезпечення.

На данний момент Linux пiдтримуе рiзнi типи послiдовних карт що базованi на стандартi RS-232. RS-232 на зараз найбiльш розповсюджений стандарт для послiдовних комунiкацiй в свiтi PC. Він використовує певну кількість провідників для передачі одиночних бітів та синхронізації. Додатковi лiнiї можуть використовуватися для визначення наявностi несучої (використовуеться в модемах), та handshake.

Хоча апаратна handshake і не є обов'язковою, її використання є корисним. Це дозволяе будь-якiй з двох станцiй дати сигнал готовностi прийому данних або iнша станцiя може робити паузу до прийняття всiх вхiдних данних. Лiнiї використовуванi для цього називаються ``Clear to Send'' (CTS) та ``Ready to Send'' (RTS), вiдповiдно, handshake такого типу називаеться ``RTS/CTS''.

В PC RS-232 iнтерфейсi використовуються UART чипи, вiдомi як National Semiconductor 16450, чи бiльш нова версiя NSC 16550A (2). Деякi виробники (наприклад внутрiшнiх модемiв на базi набору Rockwell) також використовують рiзноманiтнi сумiснi з 16550 чипи.

Головна рiзниця мiж 16450 та 16550 є в тому що новий чип має 16-ти байтний буфер - FIFO, тодi як старий має тiльки однобайтний. Це означає що 16450 нормально працює на швидкостях не вище 9600, для вищих потрiбен 16550-сумiсний чип. Крiм цих двох чипiв Linux пiдримуе 8250, який є оригiнальним UART для PC-AT.

По замовчуванню, ядро бачить чотири стандартних послiдовних плати вiд COM1 по COM4. Їм вiдповiдають молодшi номери файлiв пристроїв вiд 64 до 67, як описано вище.

Якщо ви хочете конфiгурувати вашi послiдовнi порти самостiйно, ви можете iнсталювати програму setserial Ted Tso яка виконується з скрипта rc.serial. Цей скрипт повинен знаходитись в каталозi /etc/rc.d i виконуватись пiд час завантаження системи. Типовий скрипт rc.serial ви можете побачити нижче :

      # /etc/rc.serial - serial line configuration script.

      #

      # Do wild interrupt detection

      /sbin/setserial -W /dev/cua*

      # Configure serial devices

      /sbin/setserial /dev/cua0 auto irq skip test autoconfig

      /sbin/setserial /dev/cua1 auto irq skip test autoconfig

      /sbin/setserial /dev/cua2 auto irq skip test autoconfig

      /sbin/setserial /dev/cua3 auto irq skip test autoconfig

      # Display serial device configuration

      /sbin/setserial -bg /dev/cua*

Будь-ласка перегляньте документацiю до вашої версiї setserial для уточнення параметрiв.

Якщо ваша послiдовна карта не детектується, або команда setserial з параметром -bg видає некоректнi результати, ви можете самостiйно встановити правильнi параметри. Користувачi внутрiшнiх модемiв базованих на Rockwell повiдомляють про неправильне визначення UART. Для прикладу, setserial повiдомляе про те що UART - 16450, хоча насправдi вiн є 16550. Ви можете прямо вказати потрiбнi вам параметри :

      /sbin/setserial  /dev/cua1  auto irq skip test autoconfig 

      uart 16550

Де опцiї вiдповiдно - COM порт, базовий адрес, IRQ. Будь ласка прочитайте manual pages setserial(8).

Якщо ваш модем пiдтримує апаратний handshake,ви можете включити її. Незрозумiло, але бiльшiсть комунiкацiйних програм не встановлюють її по замовчуванню; ви повиннi зробити це самi. Найкращим шляхом буде виклик команди stty з скрипта rc.serial :

      $ stty crtscts < /dev/cua1

Для перевiрки чи включена апаратна handshake, виконайте :

      $ stty -a < /dev/cua1

Вам буде повернуто статус всiх прапорцiв для вашого пристрою; прапорець перед яким знаходиться мiнус, як наприклад -crtscts, означае що вiн вiдключений.

Служба назв та конфігурування resolver-а

Як обговорювалось в главі 3, базовані на TCP/IP мережі можуть використовувати різні схеми перетворення назв хостів в IP адресу. Самий простий шлях - використовувати таблицю хостів з файлу /etc/hosts, що правда цей шлях не надає переваг які існують при розбитті на зони. Такий варіант може використовуватись тільки у невеликій мережі яка управляється одним адміністратором і не маює IP трафіку з зовнішнім світом. Формат файлу hosts описано в главі 6.

В іншому випадку ви можете використовувати BIND - Berkeley Internet Name Domain Service для кониертації назв хостів в IP адресу. Конфігурування BIND може бути досить складним, але якщо це зроблено ви зможете легко вносити зміни в топологію мережі. В Linux, як і в багатьох інших Un*x подібних системах, сервіс назв підтримується за домомогою named. При запуску він завантажує набір базових файлів в кеш і очікує запитів від віддалених чи локальних користувачських прочесів. Існує кілька різних шляхів конфігурування BIND. Деякі з них не вимагають що б ви запускали сервер назв на кожній машині.

У цій главі подано ескіз того як використовувати сервер назв. Якщо ви збираєтесь використовувати BIND у великій мережі або для повноцінного зв'язку з Internet, то вам варто підшукати якусь книгу про BIND, як то наприклад Cricket Liu's ``DNS and BIND'' (див. [ GETST "liu-dns" ]). Для більш сучасної інформації ви також можете звернутись до приміток релізу які знаходяться в вихідниках BIND. Існує також телеконференція присвячена DNS - comp.protocols.tcp-ip.domains.

7.1 Бібліотека resolver

Коли ми говоримо ``resolver'', ми то не обговорюємо якусь спеціальну програму а про звернення до resolver бібліотеки яка є набором функцій що знаходяться в стандартній бібліотеці C. Базовими її функціями є gethostbyname(2) та gethostbyaddr(2) яка розшукуює IP адресу хоста за назвою та навпаки. Вони можуть бути сконфігуровані щоб просто шукати інформацію про хост, опитувати сервери назв, або використовувати базу данних хостів NIS (Network Information Service). Інші програми, наприклад smail, можуть включати різні драйвери для будь-якого з них і потребують спеціальної опису.

7.1.1 Файл host.conf

Головний файл настройки вашого resolver є host.conf. Він знаходиться в каталозі /etc і вказує resolver-у доступні сервіси та в якому порядку використовувати.

Опції в host.conf повинні знаходитись в окремих стрічках. Поля розділяються символами табуляції або пробілу. Cимволом hash (#) розпочинаються коментарії які завершуються новою стрічкою.

Допустимі опції :

          order Описує порядок в якому будуть викликатись сервіси.

                Доступними є bind для звернення до сервера назв, hosts для

                прогляду /etc/hosts та nis для пошуку через NIS. Можуть бути

                встановленними деякі з них або всі. Порядок в якому вони

                вказані є порядком звернення до них.

          multi Може бути встановлено on або off. Ця опція описує чи може

                хост в /etc/hosts мати кілька IP адрес. Цей режим здебільшо

                згадується як ``multi-homed''. Немає значення при DNS та NIS 

                запитах.

        nospoof Як описано в попередній главі, DNS дозволяє вам знаходити

                назву хоста через IP адресу за допомогою домена in-addr.arpa.

                Спроби серверів імен видати фальшиву назву хоста називається 

                ``spoofing''. Для захисту від цього resolver повинен бути

                сконфігурованим для порівняння оригінальної IP адреси хоста

                з отриманою через запит. Якщо вони не співпадають назва не

                береться до уваги і повертається помилка. Цей режим

                вмикається за допомогою nospoof on.

          alert Аргументами цієї опції можуть бути on або off. Якщо опція

                ввімкнена то будь-які spoof спроби (див.вище) будуть

                записуватись в syslog.

           trim Аргументом в цій опції має бути домен який буде відсікатися

                від назви хоста перед пошуком. Це може знадобитись для

                пошуку входжень назв хостів без локального домену. Пошук

                хоста з добавленим локальним доменом дозволяє його відсікти,

                що дозволяє успішно проводити пошук в /etc/hosts.

                     Опції trim накопичуються що робить можливим вважати ваш

                хост як локальний для кількох доменів.

Простий файл для vlager показано нижче:

           # /etc/host.conf

           # We have named running, but no NIS (yet)

           order   bind hosts

           # Allow multiple addrs

           multi   on

           # Guard against spoof attempts

           nospoof on

           # Trim local domain (not really necessary).

           trim    vbrew.com.

7.1.2 Змінні середовища для resolver

Значення встановлені в host.conf можуть бути змінені за допомогою змінних середовища :

      RESOLV HOST CONF Описує файл конфігурації який буде читатись замість

                /etc/host.conf

      RESOLV SERV ORDER Пепреписує порядок звернення описаний в host.conf.

                Опціями можуть бути hosts, bind та nis розділені пробілом,

                комою, двокрапкою чи крапкою з омою ';'.

      RESOLV SPOOF CHECK Регулює реакцію системи на spoofing. Повністю

                відключається опцією off. Значення warn та warn off вмикає

                перевірку на spoof та вмикає або не вмикає запис в лог

                відповідно. Значення * вмикає перевірку на spoof а запис в

                лог залишає як було описано в host.conf.

      RESOLV MULTI Значення on та off можуть використовуватись для

                переозначення опції multi з файлу host.conf.

      RESOLV OVERRIDE TRIM DOMAIN Ця змінна середовища описує список доменів

                якими буде замінено список взятий з host.conf.

      RESOLV ADD TRIM DOMAIN Ця змінна середовища описує список доменів які

                буде добавлено до відповідного списку з host.conf.

7.1.3 Конфігурування звернень сервера назв --- resolv.conf

При конфігуруванні бібліотеки звернень (resolver) для використання служби назв BIND для пошуку хостів, ви повинні також вказати який сервер назв буде використовуватись. Для цього існує спеціальний файл - resolv.conf. Якщо цей файл відсутній або пустий resolver вважатиме що сервер назв знаходиться на вашій локальній машині.

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

Найбільш важливою для resolv.conf опцією є nameserver в якій вказується IP адреса сервера назв для вашої машини. Якщо ви задасте кілька серверів імен то вони будуть викликатись в порядку розташування. Тому першим ви повинні подати найбільш надійний сервер. На данний момент підтримується до трьох серверів назв одночасно.

Якщо опцію nameserver опущено то resolver спробує з'єднатись з сервером назв на локальному хості.

Дві інших опції - domain та search - вказують домен який буде по замовчуванню додаватись до назви хоста у випадку якщо BIND не зможе успішно вирішити перший запит. Опція search описує список доменів розділених пробілами або табуляціями.

Якщо не вказано опцію search то список по замовчуванню формується з локального домену використовуючи його безпосередньо плюс всі батьківські домени до кореня. Назва локального домену можна задати використовуючи команду domain. У випадку якщо жодної з команд не вказано resolver отримує цю інформацію через системний виклик getdomainname(2).

Якщо це звучить для вас незрозуміло, розгляньте цей приклад файлу resolv.conf для Virtual Brewery.

           # /etc/resolv.conf

           # Our domain

           domain         vbrew.com

           #

           # We use vlager as central nameserver:

           nameserver     191.72.1.1

При пошуку назви vale, resolver спочатку спробує знайти vale, а при його відсутності vale.vbrew.com і після нього vale.com.

7.1.4 Захищеність від помилок resolver-а

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

Хоча пожежі в університетському містечку трапляються нечасто, все ж варто передбачити і таку можливіть та прийняти запобіжні міри проти подібних випадків.

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

Іншим виходом може бути підтримка резервної таблиці хостів для вашого домену чи LAN в /etc/hosts. В /etc/host.conf ви пованні включити стрічку `order bind host' для того щоб resolver звертався до файлу hosts у випадку неможливості зв'язатись з центральним сервером назв.

7.2 Використання named

Програма яка забезпечує службу назв доменів на більшості Un*x машинах називається named (вимовляється name-dee). Це програма-сервер спочатку розроблена для підтримки в BSD служби назв клієнтами та можливо іншими серверами назв. Біжуча версія яка використовується зараз в Linux називається BIND-4.8.3. Нова версія, BIND-4.9.3, на зараз перебуває на beta тестуванні і скоро повинна бути доступна в Linux.

Ця секція потребує деякого розуміння основ роботи DNS. Якщо наступна інформація буде незрозумілою для вас - то ви можете звернутись до глави 3 повторно (там описано основи DNS).

Частіше усього named стартує під час завантаження системи та працює поки працює машина. Головним конфігураційним файлом для named є /etc/named.boot та інших файлів які містять данні відносно зв'язків між доменними назвами та адресами і т.п. (такі файли називаються файлами опису зон). Формат і семантику цих файлів буде описано в наступній секції.

Для запуску named просто наберіть :

           # /usr/sbin/named

у відповідь на запрошення. named завантажить конфігкраційний файл named.boot та всі файли зон вказані там, запише номер процесу в /var/run/named.pid, завантажить інформацію з усіх вказаних primary серверів (якщо необхідно). Після цього він почне очікувати DNS запитів через 53 порт

7.2.1 Файл named.boot

Файл named.boot є досить маленьким і описує тільки файли в яких зберігається інформація про зони та вказівники на інші сервери назв. Коментарії у файлі починаються з крапки з комою ';' і завершуються символом нової стрічки. Перш ніж більш детально розглянути формат named.boot глянемо на простий файл з машини vlager поданий на ілюстрації 7.2.1 (2)

Команди cache та primary показані у цьому прикладі завантажують інформацію в named з базових файлів які описані в другому аргументі. Ці файли містять текстове представлення DNS записів яке ми розглянемо нижче.

                ;

                ; /etc/named.boot file for vlager.vbrew.com

                ;

                directory     /var/named

                ;

                ;             domain                   file

                ;---------------------------------------------------

                cache         .                        named.ca

                primary       vbrew.com                named.hosts

                primary       0.0.127.in-addr.arpa     named.local

                primary       72.191.in-addr.arpa      named.rev

Ілюстрація 9. Файл named.boot для vlager.

В цьому прикладі ми конфігуруємо named як primary сервер для трьох доменів використовуючи вираз primary. Перший з них встановлює named як primary сервер для vbrew.com з файлом данних зони named.hosts. Ключове слово directory вказує, що всі файли з описом зон знаходяться в /var/named.

Входження cache є досить специфічне і повинно бути присутнім на всіх машинах які використовують сервер назв. Ця функція дає named дві інструкції - ввімкнути кеш, та завантажити з описаного файлу (named.ca в нашому прикладі) хінти кореневих серверів назв. Ми повернемось до опису хінтів сервера назв нижче.

Нижче подано список найбільш важливих операторів які ви можете використовувати в named.boot.

      directory Описує каталог в якому знаходяться файли опису зон. Імена 

                файлів можуть даватись відносно цього каталогу. Може бути

                описано кілька каталогів використовуючи повторно directory.

                Відповідно до стандарту файлової системи Linux це повинен

                бути /var/named.

        primary Його аргументами повинні бути домен та ім'я файлу

                відповідно, оголошує місцевий сервер як авторизований для

                данного домену. named, як primary сервер, завантажує

                інформацію про зону з описаного файлу.

                     В будь-якому випадку завжди буде існувати принаймі одне

                входження primary в boot файлі : зворотня карта для

                локальної мережі (127.0.0.0).

      secondary Ця опція отримує домен, список  адресів та ім'я файлу як

                аргументи. Встановлює місцевий сервер як secondary для

                вказаного домену.

                     secondary сервер також тримає авторизовані данні

                відносно домену, але він не бере ці данні з файлів, а пробує

                їх завантажити з primary сервера. Для цього повинна бути

                вказана принаймі одна IP адреса в списку адрес. Локальний

                сервер спробує встановити з'єднання з доступними серверами в

                порядку їх подання і запише інформацію в резервний файл,

                назва якого є третім аргументом. У випадку якщо сервер не

                зможе зв'язатись з жодним поданим сервером данні буде

                завантажено з цього резервного файлу.

                     named буде пробувати через однакові проміжки часу

                обновити данні про зону (буде пояснено нижче при описі

                типу запису SOA).

          cache Ця опція потребує домен та назву файлу як аргументи. Файл

                містить хінти для кореневого (root) сервера і які є списком

                вказівників на кореневі сервери імен. Розпізнаються тільки

                записи типів NS та A. Аргумент домену повинен бути кореневим

                доменом ``.''.

                     Ця інформація є вельми важливою для named : якщо в

                завнатажувальному файлі відсутній оператор cache то named не

                використовуватиме локальний кеш взагалі. Це може призвести

                до зниження швидкодії та  завантаження мережі якщо наступний

                сервер знаходиться за межами лоальної мережі. Крім того

                named не зможе звертатись до жодного кореневого сервера

                назв, і таким чином не зможе вирішувати ніякі адреси крім

                авторизованих для нього. Виключенням з цього правила є

                використання forwarding серверів (опис опції forwarders

                див. нижче).

      forwarders Цей оператор потребує список адрес як аргумент. IP адреси в

                цьому списку описують список серверів назв до яких буде

                звертатись named якщо він не зможе знайти данні в локальному

                кеші. Звернення до серверів відбувається в порядку їх

                розташування.

          slave Ця опція встановлює сервер назв в режим ``раба''. Тобто

                сервер ніколи не буде виконувати рекурсивні запити

                самостійно, а буде переадресовувати їх на сервери вказані в

                списку forwards.

Існує два оператори - sortlist та domain - які ми не будем описувати. Додатково також існують дві директиви які можуть викорисовуватись в файлах баз данних зон ($INCLUDE та $ORIGIN). Вони так рідко дійсно необхідні що ми також опустимо їх опис.

7.2.2 Файли баз данних DNS

Файли які включає named (наприклад named.hosts) завжди пов'язані з певним доменом який називється ориджин (origin). Це домени вказані в командах cache та primary. В межах такого файлу ви можете вказувати домен чи ім'я хоста відносно цього домену. Назва данна в файлі конфігурації розглядається як абсолютна якщо вона закінчується одною крапкою (`.'), в іному випадку назва вважається відносною до ориджина. Назва ориджину згадується за допомогою символа `@'.

Всі данні що знаходяться у файлах розділені на записи ресурсів (resource record - далі RR). Вони є найменшою одиницею інформації доступної через DNS. Кожен RR має тип. Наприклад запис типу A є картою відношень назви хоста до IP адреси, а запис типу CNAME описує псевдонім для хоста. Для прикладу дивись ілюстрацію 7.2.3 ! на сторінці (???), яка демонструє файл named.hosts для brewery.

Записи в файлах мають однаковий формат :

           [domain] [ttl] [class] type rdata

Поля розділяються пробілами або табуляціями. Входження може займати кілька рядків - якщо відкрито фігурну дужку ({) перед символом завершення стрічки до закриття (}). Коментарії розпочинаються символом крапки з комою і закінчуються символом завершення стрічки.

         domain Домен для стрічки. Якщо не вказано жодного імені то

                використовується домен попереднього запису.

            ttl Щоб заставити resolvers відмовитись (забути) від запису

                через певний час для кожного запису встановлюється ttl

                (``time to live'' - час життя). Поле ttl описує час в

                секундах поки інформація вважається істинною після як вона

                була завантажена на сервер. Описується десятковим числом з

                максимальною кількістю цифр 8.

                     Якщо поле ttl не встановлено то то значення по

                замовчуванню береться з поля minimum відповідного запису SOA.

          class Це клас адреси, IN для IP адресації та HS для класу Hesiod.

                В TCP/IP мережах використовується тільки клас IN.

                     Якщо клас для запису не вказано то береться клас

                попереднього запису.

           type Тип запису. Найбільш вживані типи - A, SOA, PTR та NS.

                Детальніше типи записів буде розглянуто в наступних секціях.

          rdata В цьому полі знаходяться данні пов'язані з RR. Формат поля

                залежить від типу запису (нижче буде буде описано формат

                данних для кожного типу окремо).

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

            SOA

                     Описує зону авторизації (SOA розшифровується як ``Start

                of Authority''). Означає що наступні записи містять

                авторизовану інформацію для данного домену. Кожен файл який

                включається за допомогою оператора primary повинен містити

                запис типу SOA для описаної зони. Поле rdata складається з

                наступних данних :

                   origin Кононічна назва хоста primary сервера для данної

                          зони. Здебільшо подається як абсолютне ім'я.

                  contact Електронна адреса відповідальної за підтримку

                          домена особи (замість символа '@' вживається

                          крапка). Для прикладу якщо відповідальною для

                          Virtual Brewery є janet то поле повинно містити

                          janet.vbrew.com.

                   serial Номер версії файла зони, задається як єдине

                          десяткове число. Кожного разу при зміні данних

                          в файлі це число повинно збільшуватсь.

                               Серійний номер використовується secondary

                          серверами для розпізнавання випадку коли

                          інформацію про зону було змінено. Щоб не

                          використовувати застарілі данні secondary сервер

                          дає запит на primary відносно SOA запису, порівнює

                          серійний номер запису з тим що  знаходиться в

                          кеші. Якщо номер змінився то secondary сервер

                          приймає всю базу данних зони від primary сервера.

                  refresh Встановлює інтервал в секундах очікування для

                          secondary сервера після якого він повинен

                          обновити SOA запис з primary сервера.

                          Записується як восьмизначне десяткове число.

                               В загальному топологія мереж не змінюється

                          часто навіть для великих мереж, тому значення

                          числа повинно приблизно дорівнювати 1 дню, а для

                          малих мереж може бути навіть більшим.

                    retry Описує інтервал часу після якого secondary сервер

                          повинен повторити спробу контакту з primary

                          сервером в разі невдалого завершення запиту або

                          обновлення інформації про зону. Значення не

                          повинно бути надто малим, інакше тимчасова відмова

                          у роботі сервера або проблеми мережі можуть

                          заставити secondary сервер даремно витрачати

                          ресурси мережі. Найкращим значення для цього поля

                          буде інтервал від пів години до години.

                   expire Встановлює час в секундах після якого сервер

                          знищує всі данні про зону якщо він не зміг

                          зв'язатись за цей час з primary сервером.

                          Здебільшо встановлюють дуже велике число. Graig

                          Hunt ([ GETST "hunt-tcpip" ]) рекомендує

                          встановлювати значення 42 дні.

                  minimum Встановлює значення по замовчуванню ttl для RR

                          зони в яких воно не вказано явно. Вказує іншим

                          серверам імен після якого інтервалу вони повинні

                          відмовитись від RR. Немає ніякого зв'язку з часом

                          оновлення данних зони для secondary сервера.

                               Значення minimum варто встановлювати як можна

                           більшим, особливо для LAN де топологія мереж

                           практично ніколи не змінюється. Найкращим

                           варіантом буде значення від тиждня до місяця. У

                           випадку якщо окремий запис може змінюватись

                           частіше ви можете вказати його явно для запису.

              A

                     Пов'язує IP адресу з назвою хоста. Поле rdata містить

                адресу у вигляді чотирьох розділених крапкою чисел.

                      Для кожного хоста повинна бути тільки один запис типу

                A. Назва хоста вказане в цьому записі є канонічною назвою. Всі

                інші назви для цього хоста називається псевдонімами та

                повинні вказувати на канонічну назву з використанням запису

                типу CNAME.

             NS

                     Запис цього типу вказує на базові сервери назв данної

                зони. Для пояснення для чого потрібні записи типу NS дивись

                секцію 3.6. Поле данних містить назву хоста сервера назв. Для 

                знаходження хоста повинен бути присутнім запис типу A для 

                данного хоста який описує його IP адресу.

          CNAME

                     Зв'язує псевдонім хоста з канонічною назвою. Канонічною

                назвою хоста вважається кожен запис типу A з файлу зони;

                псевдоніми просто зв'язані з канонічним записом CNAME, але

                не можуть мати будь-які інші записи будь-якого типу.

            PTR

                     Запис цього типу використовується для зв'язування назв

                з домену in-addr.arpa з назвою хоста. Використовується для

                зворотнього розміщення IP адрес до назв хостів.

             MX

                     Цей запис оголошує відповідальний за обмін поштою для

                домена хост. Для чого потрібні MX описується в секції 14.4.1

                в главі 14. Синтаксис запису типу MX :

                     [domain] [ttl] [class] MX preference host

                     host задає назву хоста як відповідального за обмін

                поштою для домена. Кожен запис цього типу містить число

                preference. Програма доставки пошти для доставки пошти для

                домену буде перебирати всі хости вказані в записах типу MX

                для данного домену до успішного завершення операції.

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

                від найменшого до найбільшого.

          HINFO Запис цього типу описує апаратне та програмне забезпечення

                системи. Синтаксис запису такий :

                     [domain] [ttl] [class] HINFO hardware software

                     В полі hardware описується апаратне забезпечення що

                використовується на хості. Опис доступних значень для цього

                поля знаходиться в ``Assigned Numbers'' (RFC-1340). Якщо

                значення пробіл чи табуляцію, то воно повинно починатись та

                закінчуватись подвійними кавичками. Поле software описує

                назву операційної системи. Можливі значення цього поля

                знаходяться в то му ж ``Assigned Numbers'' RFC.

 

 

7.2.3 Створення базових файлів

На ілюстраціях 7.2.3, 7.2.3, 7.2.3 та 7.2.3 зображено приклади файлів для сервера назв мережі brewery розташованих на хості vlager. В наслідок досить простої топології обговорюваної мережі і файли прикладів досить прості. Якщо вам потрібно побудувати більш складну мережу перечитайте книжку ``DNS and BIND'' Cricket Liu та Paul Albitz ([ GETST "liu-dns" ]).

В кеш файлі named.ca, зображеному на ілюстрації 7.2.3, показано приклад hint записів для кореневого сервера назв. В типовову файлі кешу прийнято описувати декілька серверів назв. Ви можете отримати біжучий список серверів назв для кореневого домену використовуючи інструмент nslookup як це описано в кінці цієї глави

                ;

                ; /var/named/named.ca          Cache file for the brewery.

                ;                We're not on the Internet, so we don't need 

                ;                any root servers. To activate these

                ;                records, remove the semicolons.

                ;

                ; .                99999999   IN    NS  NS.NIC.DDN.MIL

                ; NS.NIC.DDN.MIL   99999999   IN    A   26.3.0.103

                ; .                99999999   IN    NS  NS.NASA.GOV

                ; NS.NASA.GOV      99999999   IN    NS  128.102.16.10

Ілюстрація 10. Файл named.ca.

7.2.4 Перевірка конфігурації сервера назв.

                ;

                ; /var/named/named.hosts       Local hosts at the brewery

                ;                               Origin is vbrew.com

                ;

                @                   IN  SOA   vlager.vbrew.com. (

                                              janet.vbrew.com.

                                              16         ; serial

                                              86400      ; refresh: once per day

                                              3600       ; retry:   one hour

                                              3600000    ; expire:  42 days

                                              604800     ; minimum: 1 week

                                              )

                                    IN  NS    vlager.vbrew.com.

                ;

                ; local mail is distributed on vlager

                                    IN  MX    10 vlager

                ;

                ; loopback address

                localhost.          IN  A     127.0.0.1

                ; brewery Ethernet

                vlager              IN  A     191.72.1.1

                vlager-if1          IN  CNAME vlager

                ; vlager is also news server

                news                IN  CNAME vlager

                vstout              IN  A     191.72.1.2

                vale                IN  A     191.72.1.3

                ; winery Ethernet

                vlager-if2          IN  A     191.72.2.1

                vbardolino          IN  A     191.72.2.2

                vchianti            IN  A     191.72.2.3

                vbeaujolais         IN  A     191.72.2.4

Ілюстрація 11. Файл named.hosts.

Існує прекрасний інструмент для перевірки дій вашого сервера назв. Ця програма називається nslookup і може використовуватись як в діалоговому режимі так і в режимі командної стрічки. В останньому випадку ви просто викликаєте його

           nslookup hostname

після чого ця програма дасть запит на сервер назв вказаний в resolv.conf відносно hostname. (Якщо в цьому файлі описано кілька серверів то вибір між ними буде проходити випадковим чином).

                ;

                ; /var/named/named.local       Reverse mapping of 127.0.0

                ;                               Origin is 0.0.127.in-addr.arpa.

                ;

                @                   IN  SOA   vlager.vbrew.com. (

                                              joe.vbrew.com.

                                              1          ; serial

                                              360000     ; refresh: 100 hrs

                                              3600       ; retry:   one hour

                                              3600000    ; expire:  42 days

                                              360000     ; minimum: 100 hrs

                                              )

                                    IN  NS    vlager.vbrew.com.

                1                   IN  PTR   localhost.

Ілюстрація 12. Файл named.local.

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

Коли nslookup запускається без аргументів, він покаже на екрані хост сервера назв і ввійде в діалоговий режим. Символ '>' означає запрошення - після нього і набирається назва відносно якої ви хочете дати запит. По замовчуванню тип запиту встановлюється для класу A в якому містяться IP адреси пов'язані з доменними назвами.

Ви можете змінити тип запиту за допомогою команди ``set type=type'', де type один з типів RR описаних вище в секції 7.2 або ANY.

Наприклад ви можете спробувати наступний діалог :

                ;

                ; /var/named/named.rev         Reverse mapping of our IP addresses

                ;                               Origin is 72.191.in-addr.arpa.

                ;

                @                   IN  SOA   vlager.vbrew.com. (

                                              joe.vbrew.com.

                                              16         ; serial

                                              86400      ; refresh: once per day

                                              3600       ; retry:   one hour

                                              3600000    ; expire:  42 days

                                              604800     ; minimum: 1 week

                                              )

                                    IN  NS    vlager.vbrew.com.

                ; brewery

                1.1                 IN  PTR   vlager.vbrew.com.

                2.1                 IN  PTR   vstout.vbrew.com.

                3.1                 IN  PTR   vale.vbrew.com.

                ; winery

                1.2                 IN  PTR   vlager-if1.vbrew.com.

                2.2                 IN  PTR   vbardolino.vbrew.com.

                3.2                 IN  PTR   vchianti.vbrew.com.

                4.2                 IN  PTR   vbeaujolais.vbrew.com.

Ілюстрація 13. Файл named.rev.

           $ nslookup

           Default Name Server:  rs10.hrz.th-darmstadt.de

           Address:  130.83.56.60

           > sunsite.unc.edu

           Name Server:  rs10.hrz.th-darmstadt.de

           Address:  130.83.56.60

           Non-authoritative answer:

           Name:    sunsite.unc.edu

           Address:  152.2.22.81

Якщо ви спробуєте дати запит на назву яка не прив'язана до жодної IP адреси, але було знайдено записи інших типів в базі DNS - nslookup поверне помилку та повідомлення ``No type A record found''. Тип запиту ви можете змінити за допомогою команди ``set type''. Для прикладу щоб отримати SOA запис відносно unc.edu ви повинні виконати :

           > unc.edu

           *** No address (A) records available for unc.edu

           Name Server:  rs10.hrz.th-darmstadt.de

           Address:  130.83.56.60

           > set type=SOA

           > unc.edu

           Name Server:  rs10.hrz.th-darmstadt.de

           Address:  130.83.56.60

           Non-authoritative answer:

           unc.edu

                   origin = ns.unc.edu

                   mail addr = shava.ns.unc.edu

                   serial = 930408

                   refresh = 28800 (8 hours)

                   retry   = 3600 (1 hour)

                   expire  = 1209600 (14 days)

                   minimum ttl = 86400 (1 day)

           Authoritative answers can be found from:

           UNC.EDU nameserver = SAMBA.ACS.UNC.EDU

           SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

Таким чином ви можете дати запит для MX записів, то що. Використання типу ANY дасть вам можливість отримати всі данні пов'язані з данною назвою.

           > set type=MX

           > unc.edu

           Non-authoritative answer:

           unc.edu preference = 10, mail exchanger = lambada.oit.unc.edu

           lambada.oit.unc.edu     internet address = 152.2.22.80

           Authoritative answers can be found from:

           UNC.EDU nameserver = SAMBA.ACS.UNC.EDU

           SAMBA.ACS.UNC.EDU       internet address = 128.109.157.30

Практичним застосуванням nslookup може бути отримання біжучого списку кореневих серверів назв для файлу named.ca. Ви можете зробити це даючи запит для всіх записів типу NS пов'язаних з кореневим доменом :

           > set typ=NS

           > .

           Name Server:  fb0430.mathematik.th-darmstadt.de

           Address:  130.83.2.30

           Non-authoritative answer:

           (root)  nameserver = NS.INTERNIC.NET

           (root)  nameserver = AOS.ARL.ARMY.MIL

           (root)  nameserver = C.NYSER.NET

           (root)  nameserver = TERP.UMD.EDU

           (root)  nameserver = NS.NASA.GOV

           (root)  nameserver = NIC.NORDU.NET

           (root)  nameserver = NS.NIC.DDN.MIL

           Authoritative answers can be found from:

           (root)  nameserver = NS.INTERNIC.NET

           (root)  nameserver = AOS.ARL.ARMY.MIL

           (root)  nameserver = C.NYSER.NET

           (root)  nameserver = TERP.UMD.EDU

           (root)  nameserver = NS.NASA.GOV

           (root)  nameserver = NIC.NORDU.NET

           (root)  nameserver = NS.NIC.DDN.MIL

           NS.INTERNIC.NET internet address = 198.41.0.4

           AOS.ARL.ARMY.MIL        internet address = 128.63.4.82

           AOS.ARL.ARMY.MIL        internet address = 192.5.25.82

           AOS.ARL.ARMY.MIL        internet address = 26.3.0.29

           C.NYSER.NET     internet address = 192.33.4.12

           TERP.UMD.EDU    internet address = 128.8.10.90

           NS.NASA.GOV     internet address = 128.102.16.10

           NS.NASA.GOV     internet address = 192.52.195.10

           NS.NASA.GOV     internet address = 45.13.10.121

           NIC.NORDU.NET   internet address = 192.36.148.17

           NS.NIC.DDN.MIL  internet address = 192.112.36.4

Повний список команд які підтримує nslookup отримується за допомогою команди help з самого nslookup.

7.2.5 Інші корисні інструменти

Існує кілька інструментів які допоможуть вам адмініструвати BIND. Тут ми коротко оглянемо два з них. Будь-ласка звертайтесь до документації яка поставляється разом з цими програмами для більш детальної інформації про їх використання.

hostcvt допоможе вам для встановлення BIND конвертуючи файл /etc/hosts в конфігураційний файл для named. Програма генерує входження і пряму (A), і зворотню (PTR) адресу, зберігаючи псевдоніми. Звичайно вона не зробить усю роботу за вас, оскільки, наприклад, ви можете хотіти змінити деякі часові значення в SOA записі або добавити MX записи, тощо. Але все ж програма може допомогти зекономити вам кілька таблеток асперину. hostcvt знаходиться в поставці BIND, але його можна знайти і на багатьох анонімних FTP серверах присвячених Linux.

Після встановлення вашого сервера назв ви можете захотіти протестувати його конфігурацію. Найкращим, і (на мою думку) єдиним інструментом для цього є dnswalk, написаний на perl пакет який проходиться по вашій базі данних, відшукуючи помилки та перевіряючи цілісність інформації. Недавно dnswalk було поміщено в comp.sources.misc, відповідно його можна знайти всіх FTP серверах які архівують цю групу (наприклад на ftp.uu.net, але я готовий сперечатись що ви знаєте і ближчі до вас сервери).

 

 

IP через послідовну лінію

Протоколи передачі через послідовний інтерфейс, SLIP та PPP, дозволяють під'єднуватись до Internet небагатим людям. Крім модема та карти послідовних портів (бажано з буфером FIFO) ніякого спеціального апаратного забезпечення не вимагається. Використання SLIP є не набагато важчим за використання mailbox і все більша кількість приватних організацій пропонують dialup-IP за доступну кожному ціну.

Існують обидва (і SLIP, і PPP) драйвери для Linux. SLIP підтримується вже довший час і працює надійно. PPP драйвер розроблено недавно Michael Callahan та Al Longyear. Він буде описаний в наступній главі.

8.1 Загальні вимоги

Для використання SLIP чи PPP, ви повинні настроїти підтримку вашої мережі як описано в попередніх главах. Як мінімум, ви повинні встановити інтерфейс looback та підтрімку name resolution. Коли ви під'єднаєтесь до Internet, ви можливо захочете використовувати DNS. Найпростішим шляхом для цього є встановити адрес якогось сервера імен в ваш файл resolv.conf (цей сервер буде викликатись тільки при активному SLIP з'єднанні). Найкраще встановити ім'я машини на яку ви входите.

Запам'ятайте, що це не є оптимальний варіант, так як всі пошуки імен будуть проводитись через ваше SLIP/PPP з'єднання. Якщо ви турбуєтесь відносно пропускної здатності, ви можете встановити caching-only сервер імен. Він не буде справжнім сервером імен, а тільки як перемикач для всіх DNS запитів спродуктованих на вашому хості. Перевага цієї схеми в тому, що створюваний кеш буде працювати так, щоб більість запитів відправлялись по лінії тільки раз. Файл named.boot для caching-only сервера може бути приблизно таким :

          ; Named.boot file for caching-only server

           directory /var/named

           primary    0.0.127.in-addr.arpa  db.127.0.0 ; loopback net

           cache .                db.cache   ; root servers

Крім цього файлу name.boot, ви також повинні створити файл db.cache з списком діючих кореневих серверів імен. Як це зробити описано в в кінці глави Resolver Configuration.

8.2 Функціонування SLIP

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

В деяких операційних системах дравер SLIP - є окремою програмою; в Linux, це - частина ядра, що робить його швидшим. Це вимагає, проте, щоб послідовна лінія переходила в режим SLIP явно. Це досягається за допомогою спеціальної дисциплтни tty лінії SLIPDISC. В той час як tty знаходиться в нормальній дисципліні лінії (DISC0), воно буде обмінюватися данними тільки з тими процесами, що використовують звичайні read(2) та write(2) запити, і SLIP драйвер неспроможний читати чи писати на tty. При SLIPDISC ролі міняються : тепер запис/читання для будь-якої користувачської програми заблоковано, а от SLIP драйвер отримувати та передавати данні прямо на послідовний порт.

SLIP драйвер безпосередньо розпізнає кілька варіантів протоколу SLIP. Окрім звичайного SLIP, це розпізнається CSLIP - який здійснює компресію заголовків відому як Van Jacobson header compression на вихідних пакетах. Це поліпшення для інтерактивних сессій у всіх відношеннях гідне уваги. Додатково існують шестибітні версії для кожного з цих протоколів.

Простий шлях переключення послідовної лінії в режим SLIP - використання програми slattach. Припустимо ваш модем на /dev/cua3, і ви успішно ввійшли на SLIP сервер. Ви повинні виконати :

           # slattach /dev/cua3 &

Ця команда перемкне discipline лінії cua3 в SLIPDISC і приєднає його до одного з мережевих SLIP інтерфейсів. Якщо це ваше перше активоване SLIP з'єднання, то воно буде приєднано до sl0, друге відповідно до sl1, і так далі. На зараз ядро підтримує до восьми одночасних SLIP з'єднаннь.

Режим інкапсуляції по замовчуванню для slattach - CSLIP. Ви можете вибрати будь-який інший режим використовуючи ключ -p. Для використання звичайного SLIP (без компрессії), ви повинні використати

           # slattach -p slip /dev/cua3 &

Інші режими - cslip, slip6, cslip6 (для шестибітних версій SLIP), та adaptive для adaptive SLIP. Останній дозволяє ядру визначати який з типів енкапсуляції використовує віддалена машина.

Пам'ятайте, що ви повинні використовувати той самий метод що і у віддаленої машини. Для прикладу, якщо cowslip використовує CSLIP то ви також повинні його використовувати. Симтомом неспівпадання буде те, що при запуску команди ping на віддалений хост ви не будете отримувати відповіді на пакети. Якщо ж запутити ping з віддаленого хоста до вас, ви зможете повідомлення типу ``Can't build ICMP header'' на вашій консолі. Одним з шляхів поборення цієї проблеми є використання adaptive SLIP.

slattach дозволяє вам використовувати не тільки SLIP, а і інші протоколи, що використовують послідовну лінію, типу PPP чи KISS (один з протоколів що використовується в ham radio). Для більш детального опису дивись сторінки man slattach (8).

Після під'єднання через лінію до SLIP драйвера ви повинні сконфігурувати мережевий інтерфейс. Це робиться за допомогою команд ifconfig та route. Для прикладу з vlager ми під'єднуємся до сервера cowslip. Ви повинні виконати :

           # ifconfig sl0 vlager pointopoint cowslip

           # route add cowslip

           # route add default gw cowslip

Перша команда конфігурує інтерфейс як point-to-point з'єднання з cowslip, а друга та третя команди встановлюють маршрут на cowslip та маршрут по замовчуванню використовуючи cowslip як міст.

Після завершення SLIP з'єднання, ви перш за все повинні знищити усі маршрути на cowslip використовуючи команду route з опцією del, знищити інтерфейс, та послати slatach сингал hangup. Після цього ви повинні розірвати модемне з'єднання за допомогою термінальної програми :

           # route del default

           # route del cowslip

           # ifconfig sl0 up

           # kill -HUP 516

8.3 Використання dip

Ви можете захотіти автоматизувати вищезгаданий процес, щоб просто викликати просту програму яка послідовно виконає всі потрібні дії. Для цього і існує dip. На момент написання цього тексту біжуча версія - dip v3.3.7. Існує багато патчів до данної версії розроблених великою кількістю людей, всі ці напрями будуть об'єднані в майбутніх версіях.

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

Для того щоб мати можливість конфігурувати SLIP інтерфейс, dip повинен мати привілегії root. Але в цьому випадку всі користувачі які будуть використовувати dip для через SLIP будуть мати права root. Це досить небезпечно - вони зможуть конфігурувати інтерфейси та маршрутизацію, що може негативно вплинути на маршрутизацію у вашій мережі. Гірше того, це дасть можливість їм підключатись до будь-якого SLIP сервера і робити небезпечні атаки на вашу мережу. Таким чином, якщо ви хочете дозволити вашим користувачам fire up з'єднання через SLIP, напишіть невеличку програму-бар'єр для кожного SLIP-сервера що планується використовувати, і запускайте цю програму з dip при встановленні зв'язку. Тоді ця програма спокійно може запускатись з правами root.

8.3.1 Приклад скрипта

Приклад скрипта зображено в розділі 8.3.1. Він може бути використаний для з'єднання з cowslip використовуючи dip з ім'ям скрипта як аргументом :

            # Sample dip script for dialing up cowslip

            # Set local and remote name and address

            get $local vlager

            get $remote cowslip

            port cua3                # choose a serial port

            speed 38400              # set speed to max

            modem HAYES              # set modem type

            reset                    # reset modem and tty

            flush                    # flush out modem response

            # Prepare for dialing.

            send ATQ0V1E1X1r

            wait OK 2

            if $errlvl != 0 goto error

            dial 41988

            if $errlvl != 0 goto error

            wait CONNECT 60

            if $errlvl != 0 goto error

            # Okay, we're connected now

            sleep 3

            send rnrn

            wait ogin: 10

            if $errlvl != 0 goto error

            send Svlagern

            wait ssword: 5

            if $errlvl != 0 goto error

            send hey-juden

            wait running 30

            if $errlvl != 0 goto error

            # We have logged in, and the remote side is firing up SLIP.

            print Connected to $remote with address $rmtip

            default                  # Make this link our default route

            mode SLIP                # We go to SLIP mode, too

            # fall through in case of error

           error:

            print SLIP to $remote failed.

Іллюстрація 14. Простий приклад скрипта для dip

           # Dip cowslip.dip

           DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)

           Written Fred N. van Kempen, MicroWalt Corporation.

           connected o cowslip.moo.com with addr 193.174.7.129

           #

Після з'єднання з cowslip і включення SLIP, dip від'єднується від терміналу і переходить в background режим. Тепер ви можете використовувати звичані мережеві сервіси. Для розірвання з'єднання запустіть dip з ключем -k. В цьому випадку буде послано hangup сигнал dip процесу використовуючі файл з індифікацйним номером /etc/dip.pid.

           # dip -k

В мові скриптів dip-у, ключові слова з знаком доллару попереду описують змінні. dip має наперед означений список змінних що будуть перечислені нижче. Для прикладу : $remote та $local описують ім'я віддаленої та локальної машини для SLIP з'єднання.

Перші дві команди в скрипті наведеному вище це команди get, які встановлюють змінні для dip. Це є імена локальної та віддаленої машини - vlager та cowslip відповідно.

Наступні п'ять команд встановлюють лінію та модем. Команда reset посалає на модем ініціалізаційну стрічку; для Hayes-сумісних модемів це команда ATZ. Наступна стрічка очищує буфер відповідей модема так, щоб вхідний діалог в наступних кількох стрічках працював як слід. Цей діалог є послідовним: набір номера 41988 (телефонний номер cowslip), і реєстрація в системі як користувач Svlager з паролем hey-jude. Команда wait очікує від модема стрічку, данну як перший аргумент; другий аргумент описує час на протязі якого буде очікуватись стрічка. Команда if використовується для перевірки чи не було помилок під час виконання команд.

Завершальні команди виконуються після входу в віддалену систему : default - встановлює маршрут по замовчуванню на всі хости на це з'єднання та mode що встановлює режим SLIP на лінії та конфігурує інтерфейс та таблицю маршрутів.

8.3.2 Опис dip

Не дивлячись на широке застосування dip не є добре документованим. В цій секції ми дамо короткий опис більшості команд dip. Ви можете проглянути список всіх команд що підтримуються - запустіть dip в тестовому режимі та викличте допомогу командою help. Для того щоб зрозуміти синтаксис будь-якої команди введіть її без аргументів; відповідно команди що не потребують аргументів не видадуть короткої допомоги .

           $ dip -t

           DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93)

           Written Fred N. van Kempen, MicroWalt Corporation.

           DIP> help

           DIP knows about following commands:

                   databits default  dial     echo     flush

                   get      goto     help     if       init

                   mode     modem    parity   print    port

                   reset    send     sleep    speed    stopbits

                   term     wait

           DIP> echo

           Usage: echo on|off

           DIP>

Всі наступні приклади відображають DIP> як запрошення ввести команду в тестовому режимі, та реакцію програми. Приклади в яких немає цього запрошення є скриптами.

8.3.2.1 Команди управління модемом

Існує кілька команд що дозволяють конфігурувати вашу послідовну лінію та модем. Деякі з них - явні, типу port, який вибирає послідовний порт, а також speed, databits, stopbits та parity, які встановлюють параметри лінії.

Команда modem вибирає тип модема. На зараз підримується тільки HAYES (тільки великикими літерами). Ви повинні потурбуватись про сумісність dip з модемом, в іншому випадку можуть не виконуватись команди dial та reset. Команда reset посилає команду переініціалізації модема що залежить від типу модема. Для Hayes-сумісних модемів це ATZ.

Команда flush очищує потік відповідей (responses) модема. В іншому випадку сценарій з'єднання може мпрацювати неправильно, так як він прочитає відповіді модема OK що залишились від попередніх команд.

Команда init описує ініціалізаційну стрічку що буде послана в модем перед набиранням номера. По замовчуванню для Hayes модемів - ``ATE0Q0V1X1'', яка включає режим луни (echo), довгий результатний код та вибирає blind dialing (не перевіряти несучу).

Команда dial посилає ініціалізаційну стрічку для модему та дзвонить на віддалену систему. По замовчування команда dial для Hayes модемів - ATD.

8.3.2.2 echo і term

Команда echo вікористовується для відладки, вона виводить на консоль dip все що посилається на послідовний пристрій. Виключається викликом команди echo off.

dip також дозволяє вийти з режиму скрипта і тимчасово перейти в термінальний режим. Ви можете використовувати dip подібно до будь-якої термінальної програми, що пише та читає з послідовної лінії. Щоб вийти з цього режиму натисніть `Ctrl-]'.

8.3.2.3 Команда get

get - встановлення змінних для dip. Найпростішим шляхом є присвоєння змінній значення константи - як це описано в наведеному вище прикладі. Також ви можете інтерактивно присвоювати значення змінній через запрошення користувачеві використовуючи замість числа ключове слово ask :

           DIP> get $local ask

           Enter value for $local:

Третім методом є присвоєння значення змінній з віддаленого хоста. На перший погляд дивно, але це може бути корисним у деяких випадках : інколи SLIP сервер не дозволяює вам використовувати вашу власну IP адресу для з'єднання через SLIP, а буде кожного разу присвоювати вам кожного разу іншу адресу коли ви входите в систему, друкуючи деяке повідомлення що інформує вас відносно присвоєної вам адреси. Якщо ви побачите щось типу ``Your address: 193.174.7.202'', ви повинні вставити такі стрічки у ваш скрипт :

           wait address: 10

           get $locip remote

8.3.2.4 Команда print

За допомогою цієї команди можна виводити текст на консоль dip-а з якої його було запущено. Будь яка з змінних dip-а може бути використана в команді print. Наприклад :

           DIP> print Using port $port at speed $speed

           Using port cua3 at speed 38400

8.3.2.5 Змінні

dip розпізнає тільки наперед означений набір змінних. Імена змінних завжди починаються з символа доллара та мусять бути написані в буквами нижньому регістрі.

Змінні $local та $locip описують ім'я та IP адресу локального хоста. При присвоєнні значення $local імені хоста dip автоматично присвоює значення змінній $locip. І навпаки при присвоєнні спочатку значення $locip.

$remote та $rmtip описують те ж саме для віддаленого хоста. $mtu описує число MTU для з'єднання.

Тільки цим п'ятьом змінним можна прямо присвоювати значення використовуючи команду get. Всі інші змінні можуть бути встановлені тільки через відповідні команди, але можуть використовуватися в команді print; це - $modem, $port та $speed.

$errlvl - змінна, що описує результат роботи попередньої команди. Значення 0 означає успшне завершення, усі інші - помилку.

8.3.2.6, Команди if та goto

Команда if є командою умовного переходу. Її синтаксис такий

           if expression goto label

Де expression повинен бути простим порівнянням між одною з змінних $errlvl, $locip чи $rmtip та цілим числом. Оператором порівняння може бути одним з : ==, !=, <, >, <=, та >=.

Команда goto продовжує виконання скрипта починаючи з наступної після мітки стрічки. Мітка повинна починатися з початку лінії і завершуватися символом двокрапки.

8.3.2.7 send, wait і sleep

Ці команди допомагють описати простий chat скрипт в dip. send посилає аргумент в послідовну лінію. Змінні не підтримуються, але розпізнаються всі С-подібні символьни послідовності такі як n та b. Символ тильда (~) - замінюється на послідовність ввід/перевід стрічки (Return/newline).

Першим аргументом команди wait є символьна стрічка. Команда сканує весь вхідний потік з послідовної лінії поки не зустріне цю стрічку. В стрічці не може бути символів "пусто" (space). Також ви можете задати другий аргумент для команди - це максимальний час за який повинна бути сприйнята стрічка; якщо ж стрічка сприйнята не буде то в $errlvl повернеться це число.

Команда sleep може бути використана для затримки на певний інтерал часу, вираженого в секундах, наприклад для очікування успішного завершення будь-якої вхідної послідовності (login sequence).

8.3.2.8 mode і default

Ці команди використовуються для встановлення послідовної лінії в режим SLIP та конфігурування інтерфейсу.

Команда mode - остання команда що виконується dip-ом перед переходом в режим демона. Якщо помилка не трапляється, то команда не повертається.

Команда mode вимагає ім'я протоколу як аргумент. На зараз dip підтримує SLIP та CSLIP як діючі імена. Біжуча версія dip не підтримує adaptive SLIP.

Після включення режиму SLIP на послидовній лінії, dip виконує ifconfig для конфігурування інтерфейсу як point-to-point лінку, та route для встановлення маршруту до віддаленого хоста.

Якщо, крім того ж, перед командою mode dip виконає команду default, то буде створено default маршрут на це SLIP з'єднання.

8.4 Робота в режимі сервера

Встановлення вашого клієнта SLIP було тяжкою частиною. Тепер про конфігурування вашого хоста як SLIP сервера, що є набагато простішим.

Одним з шляхів для цього є використання dip в режимі сервера, який в цьому випадку досягається як diplogin. Основним конфігураційним файлом є /etc/diphosts, в якому описані імена входів та пов'язані з ними адреси. Також ви можете використовувати sliplogin (перенесено з BSD), який підтримує велику кількість гнучких конфігураційних схем що дозволяє вам виконувати скрипти оболонки кожен раз при під'єднанні чи роз'єднанні. На зараз версiя sliplogin - бета.

Обидві програми вимагають щоб ви встановили вхід для SLIP клієнта. Для прикладу: щоб дозволити використовувати SLIP Arthur Dent з dent.beta.com, ви повинні завести вхід на dent добавивши таку стрічку у ваш файл passwd :

           dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

Після цього ви повинні встановити пароль для dent використовуючи passwd.

Тепер при вході dent в систему dip буде запускатись як сервер. Находить Из того, если он является indeed permitted к use SLIP, это будет выглядеть user name В /etc/diphosts. Цей файл деталізує права доступу та параметри з'єднання для кожного SLIP користувача. Просте входження для dent повинно виглядати приблизно так :

           dent::dent.beta.com:Arthur Dent:SLIP, 296

Перше (поля розділяються двокрапкою) поле - ім'я користувача що повинне відповідати його імені в passwd. В другому полі може бути описаний додатковий пароль (див. нижче). Третє - ім'я чи IP адреса викликаючого хоста. Далі - інформаційне поле (коментарій) без спеціального призначення. Наступне поле описує параметри з'єднання. Це розділений комою список що описує протокол (на зараз SLIP та CSLIP) та очікуване MTU.

При вході dent в систему, diplogin бере інформацію відносно нього з файлу diphosts, і, якщо друге поле не пусте, друкує запрошення для ``external security password''. Стрічка введена користувачем порівнюється з (нешифрованим) паролем з diphosts. Якщо вони не співпадають то спроба входження відкидаеться.

В іншому випадку diplogin конвертує послідовну лінію в SLIP або CSLIP режим та встановлює інтерфейс і маршрутизацію. Це з'єднання буде активне допоки користувач не від'єднається або модем не втратить несучої. Тоді diplogin поверне послідовну лінію в нормальний режим та завершить роботу.

Diplogin потребує привілегій суперюзера. Якщо ви не можете запустити dip з правами root, ви повинні скопіювати dip в diplogin замість лінка. В цьому випадку diplogin-у можна безпечно робити setuid без впливу на dip.