klevoz.ru страница 1
скачать файл

Въпроси на работата в TCP/IP мрежа


В тази глава ще разгледаме конфигурационните решения, които трябва да вземете, когато свързвате вашата Linux машина към TCP/IP мрежа, в това число избирането на IP адрес, име на хост и въпросите на маршрутизирането. Тази глава ви дава основата, от която се нуждаете, за да разберете какво изисква конфигурирането, а следващите глави описват средствата, които ще използвате за целта.

Можете да научите повече за комплекта протоколи TCP/IP и принципите в него от тритомника Internetworking with TCP/IP от Douglas R. Comer (издание на Prentice Hall). За по-детайлно ръководство по управлението на TCP/IP мрежа, вижте TCP/IP Network Administration от Craig Hunt (издание на O’Reilly).


Мрежови интерфейси


За да скрие разнообразието в оборудването, което може да се използва в мрежови среди, TCP/IP дефинира абстрактен интерфейс, който се използва за достъп до хардуера. Този интерфейс предлага комплект от операции, които са едни и същи за всички видове хардуер и се използват основно за изпращане и приемане на пакети.

За всяко периферно мрежово устройство в ядрото трябва да съществува съответния интерфейс. Например, Ethernet интерфейсите в Linux се наричат с имена като eth0 и eth1; PPP-интерфейсите (разгледат се в Глава 8, Протоколът PPP) са ppp0 и ppp1, а на FDDI-интерфейсите се дават имена като fddi0 и fddi1. Тези имена на интерфейси се използват само за нуждите на конфигурирането, когато искате да посочите конкретно физическо устройство в дадена конфигурационна команда, но нямат значение извън тази употреба.

Преди да бъде използван за работа в TCP/IP мрежа, на интерфейса трябва да бъде зададен IP адрес, който служи за идентифицирането му при комуникиране с останалия свят. Този адрес е различен от името на интерфейса, което споменахме по-горе. Ако сравните интерфейса с врата, адресът е като табелката с името, поставена на нея.

Могат да бъдат зададени и други параметри на устройството, например максималната големина на дейтаграма, която може да бъде обработена от конкретен хардуер. Тази големина се обозначава като MTU (съкращение от Maximum Transfer Unit – максимална единица за предаване). По-късно ще ви запознаем и с други атрибути. За щастие, повечето атрибути имат разумни подразбиращи се стойности.


IP Адреси


Както споменахме в Глава 1, Въведение в работата в мрежа, мрежовият протокол IP възприема адресите като 32-битови числа. На всяка машина трябва да бъде зададен уникален в мрежовата среда номер.* Ако поддържате локална мрежа, която няма TCP/IP трафик с други мрежи, можете да зададете тези номера според личните си предпочитания. Съществуват няколко интервали от IP адреси, които са резервирани за такива частни мрежи. Тези интервали са посочени в Таблица 2-1. За сайтове в Интернет, обаче, номерата се определят от централен пълномощен орган, наречен NIC (Network Information Center - мрежов информационен център)+.

IP адресите се разделят за четивност на четири осембитови числа, наречени октети. Например, quark.phisycs.groucho.edu има IP адрес 0х954С0С04, който се записва като 149.76.12.4. Този формат често се нарича точкувано четиризначно означаване (dotted quad notation).

Друга причина за това означаване е, че IP адресите сe разделят на мрежов номер, който се съдържа в левите октети, и номер на хост, който е останалата част от адреса. Когато се обърнете към NIC за IP адреси, не получавате адрес за всеки отделен хост, който планирате да използвате. Вместо това, получавате номер на мрежа и правото да задавате адреси на хостовете от вашата мрежа според предпочитанията си, като използвате всички валидни IP адреси в обхвата на мрежата.

Размерът на частта, предназначена за хостовете, зависи от размера на мрежата. За задоволяване на различните нужди бяха създадени няколко класа мрежи, които дефинират местата, на които се разделя IP адреса. Класовете мрежи са описани по-долу:


Клас А


Клас А включва мрежите от 1.0.0.0 до 127.0.0.0. Номерът на мрежата се съдържа в първия октет. Този клас осигурява 24-битова част за номер на хост, позволяваща всяка мрежа да съдържа около 1,6 милиона хоста.

Клас В


Клас В обхваща мрежите от 128.0.0.0 до 191.255.0.0. Номерът на мрежата е в първите два октета. Този клас дефинира 16,320 мрежи с по 65,024 хоста във всяка.

Клас С


Мрежите от клас С са от 192.0.0.0 до 223.255.255.0, като номерът на мрежата се съдържа в първите три октета. Този клас съдържа около 2 милиона мрежи с по 254 хоста.

Класове D, E и F


Адресите, попадащи в обхвата от 224.0.0.0 то 254.0.0.0 са или експериментални, или са запазени за използване за специални цели и не задават номер на мрежа. Например услугата IP Multicast, която позволява да се предават данни едновременно до много точки от една интернет, използва адреси от този обхват.

Ако се върнем към примера в Глава 1, ще видим, че 149.76.12.4, адресът на quark, указва хост 12.4 от мрежата от клас В 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. Първият се нарича маршрут по подразбиране, а вторият е т.нар. loopback адрес (адрес-примка). Подразбиращият се маршрут се използва при определяне на пътя, по който IP препраща дейтаграми.

Мрежата 127.0.0.0 е запазена за IP трафик, който е локален за вашия хост. Обикновено, адресът 127.0.0.1 се задава на специален интерфейс, наречен примка (loopback), който работи като затворена верига. Всеки IP пакет, който се изпрати през този интерфейс от TCP или UDP, ще бъде върнат към тях, все едно, че току-що пристига от някоя мрежа. Това ви позволява да разработвате и тествате мрежов софтуер, без въобще да използвате “истинска” мрежа. Освен това, мрежата-примка ви дава възможност да използвате мрежов софтуер на самостоятелен хост. Това не е толкова необичайно, колкото изглежда на пръв поглед; например, много UUCP-сайтове изобщо нямат IP връзка, но въпреки това на тях работи системата за новини INN. За правилна работа под Linux, INN изисква loopback интерфейс.

Някои адресни интервали от всеки от мрежовите класове са отделени и обозначени като “запазени” или “частни”. Тези адреси са резервирани за използване от частни мрежи и не се маршрутизират в Интернет. Обикновено те се използват от организации, изграждащи своя собствена вътрешна мрежа, но дори при малки мрежи администраторите ги смятат за полезни. Запазените мрежови адреси са показани на Таблица 2-1.



Таблица 2-1. Интервали на IP адреси, запазени за частна употреба.

Клас

Мрежи

А

10.0.0.0 до 10.255.255.255

С


192.168.0.0 до192.168.255.0

Разпознаване на адреси


След като видяхте как се образуват IP адресите, вероятно се питате как те се използват в една Ethernet или Token Ring мрежа за адресиране на отделните хостове. В крайна сметка, тези протоколи имат свои собствени адреси за обозначаване на хостовете, които нямат абсолютно нищо общо с един IP адрес, нали така? Правилно.

За съпоставяне на IP адресите с адресите на физическата мрежа е необходим механизъм. Използваният механизъм се нарича ARP (съкращение от Address Resolution Protocol – протокол за разпознаване на адреси). Всъщност, ARP не е ограничен до Ethernet и Token Ring и се използва и с други типове мрежи, например протокола AХ.25 за аматьорско радио. Идеята, лежаща в основата на ARP е това, което правят повечето хора, когато трябва да намерят г-н Х в тълпа от 150 души: човекът, който го търси, вика достатъчно високо, така че всеки да го чуе и очаква г-н X да отговори, ако е там. Когато отговори, научаваме кой е той.

Когато ARP иска да определи Ethernet адреса, съответствуващ на даден IP адрес, той използва една възможност на Ethernet, наречена broadcasting (предаване до всички), при която дейтаграмата се адресира едновременно до всички станции в мрежата. Broadcast-дейтаграмата, изпратена от ARP, съдържа запитване за IP адреса. Всеки хост, който получи това запитване, сравнява търсения адрес със своя собствен IP адрес и ако двата съвпадат, връща ARP отговор на питащия хост. След получаване на отговора, питащия хост може да извлече Ethernet-адреса на изпращача от неговия отговор.

Може би се сега се питате, как един хост може да достигне до Интернет адрес, който се намира в мрежа на другия край на света. Отговорът на този въпрос се съдържа в маршрутизацията, с която именно се намира физическото място на един хост в мрежата. Ще разгледаме този въпрос в следващия раздел.

Сега нека поговорим още малко за ARP. След като хоста открие един Ethernet адрес, той го запазва в своя ARP кеш, така че да не се налага да го търси отново следващия път, когато иска да изпрати дейтаграма на въпросния хост. Все пак, не е много разумно тази информация да се пази завинаги; Ethernet картата на отдалечения хост може да бъде заменена поради технически проблеми и информацията в ARP записа ще стане невалидна. Ето защо, записите в ARP кеша се анулират след определено време, което инициира нова процедура за определяне на IP адреса.

Понякога е необходимо да се намери IP адреса, съответстващ на даден Ethernet адрес. Това се случва например, когато бездискова машина иска да зареди операционна система от сървър в мрежата, което е често срещана ситуация в локалните мрежи. Бездисковият клиент, обаче, практически няма информация за самия себе си, освен своя Ethernet адрес! Затова, той изпраща broadcast съобщение, съдържащо заявка към сървъра за зареждане да му предостави IP адрес. В тази ситуация се използва друг протокол, наречен RARP (Reverse Address Resolution Protocol – протокол за обратно разпознаване на адреси). Заедно с протокола BOOTP, той служи за дефиниране на процедурата за зареждане на операционна система от бездисковите клиенти в мрежата.


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


Сега ще се заемем с въпроса за намирането на хоста, към който отиват дейтаграмите според техния IP адрес. Различните части от адреса се обработват по различни начини; вашата работа е да настроите файловете, които указват как да се обработва всяка част.

IP мрежи


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

IP мрежите са структурирани по подобен начин. Целият Интернет се състои от множество независими мрежи, наричани автономни системи. Всяка система извършва вътрешна маршрутизация между своите хостове, така че задачата за доставяне на една дейтаграма се свежда до намиране на път до мрежата на получаващия хост. След като дейтаграмата пристигне в произволен хост от тази конкретна мрежа, по-нататъшната обработка се извършва изключително от самата мрежа.


Подмрежи


Тази структура се отразява чрез разделяне на IP адреса на мрежова част и хост-част, както споменахме по-горе. По подразбиране, получаващата мрежа се извлича от мрежовата част на IP адреса. Затова, хостове с еднакви IP мрежови номера трябва да се намират в една и съща мрежа.*

Има смисъл да се приложи подобна схема и вътре в мрежата, защото тя може да се състои от стотици по-малки мрежи, като най-малките единици са физически мрежи като Ethernet. Затова IP ви позволява да разделите една IP мрежа на множество подмрежи.

Една подмрежа се грижи за доставянето на дейтаграми до определен диапазон от IP адреси. Това е разширение на концепцията за разделяне на битовите полета, както е при класовете A, B и C. Мрежовата част обаче сега е разширена като включва няколко бита от частта на хоста. Броят на битовете, които се интерпретират като номер на подмрежата, се дава от така наречената маска на подмрежата (subnet mask) или мрежова маска (netmask). Това също е 32-битово число, което определя битовата маска за мрежовата част на IP адреса.

Университетската мрежа на GMU е пример за такава мрежа. Тя има номер на мрежа от клас В - 149.76.0.0, следователно нейната мрежова маска е 255.255.0.0.

Вътрешно, университетската мрежа на GMU се състои от множество по-малки мрежи като различните факултетски локални мрежи. Затова, обхвата на IP адресите е разделен на 254 подмрежи – от 149.76.1.0 до 149.76.254.0. Например, Факултетът по Теоретична физика използва мрежа с номер 149.76.12.0. Университетската опорна мрежа е самостоятелна мрежа с номер 149.76.1.0. Тези подмрежи използват съвместно един и същи номер на IP мрежа, но третият октет се използва, за да се разграничават помежду си. Следователно, тяхната маска на подмрежа е 255.255.255.0.

На Фигура 2-1 е показано как 149.76.12.4, адресът на quark, се интерпретира различно, когато се възприема като обикновена мрежа от клас В, и когато се използват подмрежи.

Няма никакво значение, че техниката за генериране на подмрежи е само едно вътрешно деление на мрежата. Подмрежите се създават от собственика на мрежата (или администраторите). Често подмрежите се създават, за да отразят съществуващи граници, били те физически (между две Ethernet мрежи), административни (между два факултета) или географски (между два района), а правата над всяка подмрежа се делегират на някой представител. Тази структура обаче се отразява само на вътрешното поведение на мрежата и е напълно невидима за външния свят.

Фигура 2-1. Разделяне на мрежа от клас В на подмрежи.

Клас В Мрежова част хост-част

Клас В с подмрежа Мрежова част подмрежа хост-част


Шлюзове


Разделянето на подмрежи е не просто от полза на организациите; често то е естествен резултат от хардуерни граници. Видимата област на един хост от дадена физическа мрежа, например Ethernet, е много ограничен: той може да разговаря само с хостове от неговата мрежа. Всички други хостове могат да бъдат достигнати само чрез специално предназначени за целта машини, наречени шлюзове (gateway). Шлюзът е хост, който е свързан едновременно към две или повече физически мрежи и е конфигуриран да препраща пакети между тях.

На фигура 2-2 е показана част от мрежовата топология на GMU. Хостове, които са едновременно в две подмрежи, са показани с двата си адреса.

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

Самият sophus е свързан към две различни подмрежи: тази на Математическия факултет и университетската опорна мрежа. Достъпът му до всяка от тях е през различен интерфейс – съответно eth0 и fddi0. И сега, какъв IP адрес трябва да му зададем? В коя подмрежа трябва да е хоста – в 149.76.1.0 или в 149.76.4.0?

Фигура 2-2. Част от мрежовата топология на GMU

Mathematics Department

Математически факултет

Theoretical Physics Department

Факултет по Теоретична физика

Groucho Computing Center



Изчислителен център на GMU

Отговорът е “и в двете”. На sophus са зададени адресите 149.76.1.1 за работа в мрежата 149.76.1.0 и 149.76.4.1 за работа в мрежата 146.76.4.0. На шлюза трябва да се зададе по един IP адрес за всяка мрежа, към която принадлежи. Тези адреси – заедно със съответната мрежова маска – са свързани с интерфейса, през който се извършва достъпа до подмрежата. Затова, съответствията между интерфейса и адресите за sophus биха изглеждали например така:

Интерфейс

Адрес

Мрежова маска

eth0

149.76.4.1

255.255.255.0

lo


127.0.0.1

255.0.0.0

Последният ред описва loopback интерфейса lo, за който говорихме по рано.

В общия случай можете да игнорирате малката разлика между свързването на адрес към хост или към негов интерфейс. За хостове, които са само в една мрежа (като erdos), можете да обозначавате хоста с еди-кой-си IP адрес, въпреки че, ако говорим стриктно, Ethernet интерфейса е този, който има въпросния IP адрес. Разграничаването е действително важно само, когато става въпрос за шлюз.


Таблица за маршрутизиране


Сега ще насочим вниманието си върху това, как IP избира шлюз, който да използва за доставяне на дейтаграми до отдалечена мрежа.

Видяхме, че когато erdos изпраща дейтаграма за quark, проверява адреса на получателя и определя, че той не е в локалната мрежа. Ето защо erdos изпраща дейтаграмата на подразбиращия се шлюз sophus, който сега е поставен пред същата задача. sophus определя, че quark не е свързан към нито една от мрежите, с които този шлюз е свързан директно, така че трябва да намери друг шлюз, чрез който да препрати дейтаграмата. Правилният избор би бил niels, шлюзът към локалната мрежа на Физическия факултет. Затова sophus се нуждае от информация, за да асоциира мрежата на получателя с подходящ шлюз.

За тази цел IP използва таблица, която съдържа съответствия между мрежите и шлюзовете, чрез които те могат да бъдат достигнати. Тази таблица трябва да съдържа и един универсален запис (маршрут по подразбиране); това е шлюз, който е асоцииран с мрежа 0.0.0.0. Всички адреси съответстват на този маршрут, защото не е необходимо да съвпада нито един от 32-та бита. Затова, пакетите към една неизвестни мрежи се изпращат по подразбиращия се маршрут. Таблицата за маршрутизиране на sophus може да изглежда например по този начин:

Мрежа

Мрежова маска

Шлюз

интерфейс

149.76.1.0

255.255.255.0

-

fddi0

0.0.0.0


0.0.0.0

149.76.1.2

fddi0

Ако ви се налага да използвате маршрут до мрежа, към която sophus е свързан директно, не се нуждаете от шлюз; затова колоната на шлюза в такъв случай съдържа тире.

Процесът за определяне дали даден адрес съответства на конкретен маршрут е математическа операция. Този процес е много прост, но изисква познаването на двоичната аритметика и логика. Един маршрут съответства на получателя, ако след извършване на Логическо И (AND) между адреса на мрежа и мрежовата маска, резултатът е равен точно на резултата от Логически И между адреса на получателя и мрежовата маска.

Превод: маршрутът може да се използва, ако битовете от адреса на мрежа, задавани от мрежовата маска (започвайки от най-левия бит от първия байт на адреса) съвпадат с аналогичните битове в адреса на получателя.

Когато реализацията на IP търси най-добрия маршрут до получателя, тя може да намери записи за няколко маршрута, които съответстват на крайната цел. Например, знаем, че подразбиращия се маршрут съответства на всеки получател, но за дейтаграми, предназначени за локално свързани мрежи може да се използва и техния локален маршрут. Как IP решава кой маршрут да използва? Именно тук мрежовата маска играе важна роля. Макар че и двата маршрута водят до получателя, единият маршрут има по-дълга мрежова маска от другия. По-горе споменахме, че мрежовата маска се използва за разделяне на нашето адресно пространство на малки мрежи. Колкото по-дълга е мрежовата маска, толкова по-добре съвпада с адреса на получателя; когато препращаме дейтаграми, трябва винаги да избираме маршрута, който има най-дълга мрежова маска. Маршрутът по подразбиране има мрежова маска с дължина нула бита, а в показаната по-горе конфигурация, локално свързаните мрежи имат 24-битова мрежова маска. Ако дейтаграма съответства на локално свързана мрежа, тя ще бъде насочена към съответното устройство, вместо да се следва маршрута по подразбиране, защото маршрутът към локалната мрежа съответства с по-голям брой битове. Единствените дейтаграми, които ще бъдат насочени по подразбиращия се маршрут, са тези, които не съответстват на никой друг маршрут.

Можете да създадете таблици за маршрутизация по разнообразни начини. За малки локални мрежи, обикновено най-ефективно е те да се конструират ръчно и да се зададат на IP по време на началното зареждане с помощта на командата route (виж Глава 5, Конфигуриране на TCP/IP мрежа). За по-големи мрежи, таблиците се създават и настройват по време на работа от демони за маршрутизация; тези демони се работят на централни хостове в мрежата и обменят информация за маршрутите, за да определят “оптимални” маршрути между свързаните мрежи.

В зависимост от размера на мрежата трябва да използвате различни протоколи за маршрутизация. За маршрутизиране вътре в автономни системи (като тази на университета GMU) се използват вътрешни протоколи за маршрутизиране. Най-известен от тях е протоколът RIP (Routing Information Protocol), който се реализира от BSD-демона routed. За маршрутизиране между автономни мрежи трябва да се използват протоколи за външно маршрутизиране като EGP (External Gateway Protocol) или BGP (Border Gateway Protocol). Тези протоколи и RIP са реализирани в демона gated на Университета в Cornell.


Метрични стойности


Изборът на най-добър маршрут до получателя-хост или мрежа се извършва с динамична маршрутизация според броя ретранслации (hops). Ретранслациите съответстват на шлюзовете, през които трябва да премине дейтаграмата, преди да достигне до хоста или мрежата, за които е адресирана. Колкото по-къс е маршрутът, толкова по-добре го оценява RIP. Много дългите маршрути с 16 и повече ретранслации се считат за неизползваеми и се отхвърлят.

RIP управлява вътрешната за локалната мрежа информация за маршрутизиране, но на всички хостове трябва да работи gated. По време на зареждането си, gated търси всички активни мрежови интерфейси. Ако открие повече от един активен интерфейс (без да се брои loopback интерфейса), демона предполага, че хостът комутира пакети между различни мрежи и активно ще обменя и разпространява информация за маршрутите. В противен случай, той само пасивно ще приема актуализациите на RIP и ще обновява локалната таблица за маршрутизация.

Когато разпространява информация от локалната таблица за маршрутизация, gated изчислява дължината на маршрута като използва така наречената метрична стойност, свързана с реда от таблица за маршрутизация. Тази метрична стойност се задава от системния администратор при конфигурирането на маршрута и би следвало да отразява реалното тегло на маршрута.* Ето защо, метриката на един маршрут до подмрежа, към която хостът е свързан директно, трябва винаги да бъде нула, докато маршрут, минаващ през два шлюза трябва да има метрика две. Не е нужно да се занимавате с метриката, ако не използвате RIP или gated.

Протоколът ICMP


Съществува един помощен протокол на IP, за който още не сме говорили. Това е протоколът ICMP (Internet Control Message Protocol – протокол за управляващи съобщения в Интернет), използван от мрежовия код в ядрото, за да се обменят съобщения за грешки с други хостове. Като пример ще допуснем, че отново сте на erdos и искате да се свържете с telnet с порт 12345 на quark, но за този порт няма слушащ процес. Когато първият TCP пакет за този порт пристигне в quark, мрежовото ниво ще разпознае това и незабавно ще върне ICMP съобщение на erdos, с което съобщава, че “портът е недостъпен”.

Протоколът ICMP предоставя множество различни съобщения, много от които се отнасят за различни грешки. Има обаче едно много интересно съобщение, наречено съобщение за пренасочване (redirect message). То се генерира от маршрутизиращия модул, когато открие, че друг хост го използва като шлюз, въпреки че съществува и по-кратък маршрут. Например, след стартирането на erdos, неговата таблица за маршрутизация може да бъде непълна. Тя може да съдържа маршрути до мрежата на Математическия факултет, до опорната FDDI мрежа и подразбиращия се маршрут, сочещ към шлюза на Изчислителния център на GMU (gcc1). С тази конфигурация, пакетите за quark ще бъдат изпратени до gcc1 вместо до niels – шлюза на Физическия факултет. Когато получи такава дейтаграма, gcc1 ще забележи, че това е лош избор на маршрут и ще препрати пакета към niels, като междувременно върне ICMP съобщение за пренасочване на sophus, с което му съобщава за по-добрия маршрут.

Това изглежда като много разумен начин за избягване на ръчното настройване на маршрутите, с изключение на най-важните от тях. Все пак, имайте предвид, че разчитането на схемите за динамично маршрутизиране, независимо дали са RIP или съобщенията за пренасочване на ICMP, не винаги е добра идея. Пренасочването на ICMP и RIP предлага малък или никакъв избор за проверка дали дадена информация за маршрутизиране наистина е автентична. Тази ситуация позволява на злонамерени негодници да разрушат целия вътрешен трафик на вашата мрежа или дори по-лоши неща. Ето защо, мрежовият код на Linux разглежда съобщенията за пренасочване за адрес на мрежа като съобщения за пренасочване за адрес на хост. Това намалява пораженията от една евентуална атака, като ги ограничава само до един хост, вместо до цялата мрежа. Недостатък на този подход е, че води до генериране на малко повече трафик в случай на легитимни заявки, тъй като за всеки хост се генерира ICMP съобщение за пренасочване. В днешни дни по принцип се счита за лоша практика да се разчита на ICMP пренасочването.

Разпознаване на имена на хостове


Както описахме по-горе, адресирането в TCP/IP мрежа, поне в IPv4, е свързано с 32-битовите номера. Все пак, едва ли ще можете да запомните повече от няколко такива числа. Ето защо, хостовете обикновено са известни с “обикновени” имена като gauss или strange. Намирането на IP адреса, съответстващ на тези имена, е грижа на приложението. Този процес се нарича разпознаване името на хоста (hostname resolution).

Когато едно приложение трябва да намери IP адреса на даден хост, то се обръща към библиотечните функции gethostname(3) и gethostbyaddr(3). Традиционно, тези и редица свързани с тях процедури са групирани в отделна библиотека, наречена resolverlibrary; в Linux тези функции са част от стандартната библиотека libc. Затова, разговорно тази колекция от функции се нарича “резолвера” (the resolver). Конфигурирането на резолвера на имена е описано подробно в Глава 6, Конфигуриране на услугата за имена и резолвера.

В малки мрежи като една Ethernet мрежа или дори клъстер от такива мрежи, не е много трудно да се поддържат таблици със съответствията между имената на хостовете и техните адресите. Тази информация обикновено се пази във файл, наречен /etc/hosts. Когато добавятe/премахватe хостове или променяте адресите им, всичко, което трябва да направите, е да актуализирате файла hosts на всички хостове. Очевидно, това става много трудно в мрежи, които се състоят от повече от няколко машини.

Едно решение на този проблем е Мрежовата информационна система (NIS), разработена от Sun Microsystems, която разговорно се нарича YP или Жълти Страници. NIS съхранява файла hosts (и друга информация) в база данни в главен хост, от където клиентите могат да я извличат при нужда. Все пак, този подход е подходящ само за мрежи със среден размер като локалните, защото изисква централно поддържане на цялата база данни hosts и разпространяването й до всички сървъри. Инсталирането и конфигурирането на NIS е разгледано подробно в Глава 13, Мрежова информационна система.

В Интернет, адресната информация отначало също беше пазена в една база данни – файлът HOSTS.TXT. Този файл се поддържаше от организацията NIC (Network Information Center – мрежов информационен център) и трябваше да се изтегля и инсталира върху всички участващи сайтове. Когато мрежата се разрасна, възникнаха множество проблеми с тази схема. Освен административните дейности при периодичното инсталиране на HOST.TXT, натоварването на сървърите, които го разпространяваха, също стана много голямо. Имаше дори още по-сериозен проблем – всички имена трябваше да бъдат регистрирани от NIC, която трябваше да гарантира, че те да не се повтарят.

Ето защо, през 1994 г. беше внедрена нова схема за разпознаване на имената: DNS (Domain Name System – система за имена на домейни). DNS беше разработена от Paul Mockapetris и беше адресирана едновременно и към двата проблема. Ще разгледаме подробно DNS в Глава 6.



* Най-често използваната в Интернет версията на IP Протокола е Версия 4. Бяха положени много усилия за разработването на заместител, наречен IP Версия 6. IPv6 използва различна схема за адресация и по-дълги адреси. Съществува реализация на IPv6за Linux, но тя още не беше готова за документиране, когато подготвяхме това издание. Поддръжката на IPv6 в ядрото на Linux е добра, но освен това е необходимо да бъдат модифицирани и голям брой мрежови приложения.

+ Най-често IP адресите се задават от доставчика, от когото купувате IP достъп. Въпреки това, можете да се обърнете и директно към NIC, за да получите IP адрес за вашата мрежа, като изпратите e-mail до hostmaster@internic.net или чрез формата на адрес http://www.internic.net/

* Автономните системи са малко по-общи. Те могат да се състоят от повече от една IP мрежа.

* Можете да мислите за теглото на маршрута, в най-простия случай като за броя на необходимите ретранслации, за да се достигне до получателя. Точното определяне на теглото на маршрута може да бъде като изящно изкуство в сложните мрежови топологии.
скачать файл



Смотрите также:
Въпроси на работата в tcp/ip мрежа
205.23kb.
Серверы и клиенты
57.78kb.