Основи на TCP/IP

[netman]

Първоначално написано от protoberans от [url="http://www.vmrejata.info/tcpip.html"

http://www.vmrejata.info/tcpip.html[/url]]Глава 11 Превеждане на имената - Name Resolution


Вместо запомняне на IP адреси за хората е по-лесно да помнят имена. Администраторите дават имена на компютрите, които значат нещо - например IVAN_PC, DRAGAN_PC или PROTOBERANS_PC. В интернет на уеб сайтовете се дава лесно за запомняне име като www.vmrejata.info. По този начин можем да запомним имената на хостовете в нашата мрежа и имената на сайтовете, които обичаме да посещаване. Но TCP/IP не може да се свърже с друг компютър само с думи, на TCP/IP му е нужен IP адрес. Затова имената, които ползваме трябва да бъдат обърнати в IP адреси преди TCP/IP да направи каквото и да е с тях. Конвертирането или превеждането на името в IP адрес се нарича name resolution. След като името е превърнато в IP адрес, хоста може да определи дали местоназначението е локално или отдалечено и да продължи с комуникацията. Ситуацията е подобна на търсене на телефонен номер, когато всичко което знаете е едно име.

Да разберем конвертирането на имената

Конвертиране на името е процес на откриване на IP адрес отговарящ на зададено име. Защото обичаме да ползваме думи за машините а TCP/IP използва IP адреси, трябва да имаме метод или механизъм, който да направи размяната.
Например уеб сайта www.vmrejata.info има IP адрес 89.252.241.24, когато ползвам уеб браузър за мен е по лесно да запомня www.vmrejata.info отколкото да помня IP адреса. Ако напиша в уеб браузъра 89.252.241.24, тогава няма да има нужда от конвертиране на името, защото аз вече съм въвел IP адреса на уеб сървъра, който хоства търсяния от мен сайт. Ако напиша www.vmrejata.info тогава TCP/IP ще има нужда да преведе тези многозначителни думи в IP адрес.

Има няколко начина за трансформиране на имената в IP адреси. В зависимост от приложението, което пита за превод на името последователността на методите които ще ползва TCP/IP е различна.
Приложенията, които биха питали TCP/IP за трансформиране на името в IP адрес попадат в две категории, в зависимост от това какъв тип приложение пита за превода, TCP/IP ползва един от тези два метода:

* конвертиране на хост имена
* конвертиране на NetBIOS имена

Всеки метод приминава през няколко стъпки. TCP/IP по реда на тези стъпки търсейки съответстващия на името IP адрес. Стъпките са подредени така, че първата стъпка има най-голям шанс да преведе името а последната най-малка вероятност, по този начин имената се конвертират колкото е възможно по-бързо и ефективно.
Ако се опитате да отворите уеб сайта ww.vmrejata.info (забележете грешката), TCP/IP е премине през целия процес за конвертиране на хост имена, преди да ви каже, че има грешка. Конвертирането на www.vmrejata.info обикновенно отнема максимум три стъпки, превода на имената може да отнеме по-малко от максималния брой стъпки.

Какво представлява конвертиране на хост имена

Най-често ползвания метод за превеждане на обикновенни имена (като хост името tihomir) към IP адрес е метода за конвертиране на хост имена (host name resolution). Повечето TCP/IP приложения ползват този метод. Конвертирането на хост имената в IP адреси преминава през 7 стъпки, преди да съобщи за грешка TCP/IP ще премине през всяка от тези стъпки. Тези стъпки са:

1. Локален хост
2. Файла HOSTS
3. DNS
4. Кеш на NetBIOS имена
5. WINS
6. Броудкаст
7. Файа LMHOSTS

Някои от често срещаните приложения, които следват метода за конвертиране на хост имена са Ping, FTP и уеб браузърите (HTTP).

Какво представлява конвертиране на NetBIOS имена

Някои мрежови приложения на Microsoft са написани на Application Programming Interface (API) наречен NetBIOS. Това означава, че програмистите са ползвали общ интерфейс за да помогнат на приложението да комуникира по-добре с останалите компютри в мрежата. Тези приложения са определяни като NetBIOS приложения.
NetBIOS приложенията ползват NetBIOS имена, които още се наричат имена на компютри. По начало NetBIOS името и хост името съвпадат. В зависимост от това какво приложение търси съответстващия на името IP адрес се ползва NetBIOS или хост името.
Метода за конвертиране на NetBIOS имена има шест стъпки, които TCP/IP следва за да намери IP адреса. Ако TCP/IP не успее да намери IP адреса след като премине през тях тогава на потребителя се показва съобщение за грешка. Шесте стъпки са:

1. Кеш на NetBIOS имена
2. WINS
3. Броудкаст
4. Файла LMHOSTS
5. Файла HOSTS
6. DNS

Приложения ползващи NetBIOS имена са Windows Explorer и мрежови приложения на Microsoft, които ползват командите net use и net view.

Свавнение между конвертирането на хост имената и конвертирането на NetBIOS имената

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

конвертиране на хост имена ***** конвертиране на NetBIOS имена
Локален хост ********************** Кеш на NetBIOS имена
Файла hosts *********************** WINS
DNS ****************************** Броудкаст
Кеш на NetBIOS имената ************* Файла LMHOSTS
WINS ***************************** Файла HOSTS
Броудкаст ************************* DNS
Файла LMHOSTS

Някои от стъпките записани в таблицата се ползват само когато компютъра търсещ превода на името ползва Microsoft TCP/IP клиент. Има и възможност TCP/IP клиента да бъде настроен да не ползва всички стъпки. Например клиента може да не е настроен да ползва WINS като метод за конвертиране например, ако клиента не е конфигуриран да ползва WINS тази стъпка се прескача.
Реда за стъпките е и реда по които трябва да се мине когато се търси разрешение на проблеми свързани с конвертирането на имената. Администратора трябва да внимава кой списък ползва когато търси проблема.

Да разберем конвертирането на хост имената

Конвертиране на хост имена се появява при повечето TCP/IP програми и приложения. Това е по често срещания метод за конвертиране на имена в IP адреси. Всички TCP/IP хостове имат име на хост, конфигурирано в TCP/IP аксесоарите на хоста.
В тази секция ще разгледаме от близо всяка стъпка при процеса на конвертиране на хост имена. Нека ползваме пример с ping-ване на www.vmrejata.info. Инструмента ping се ползва, за да се провери дали може да се комуникирате с друг хост ползвайки TCP/IP. Ping ползва TCP/IP,за да изпрати ping пакет до друг хост искайки другия хост да отговори. Преди да може TCP/IP да изпрати ping пакет, тойтрябва да намери IP адреса на www.vmrejata.info. Има няколко стъпки, които хоста ще предприеме, за да конвертира приятелското име в IP адрес. Щом успее да конвертира името IP адреса ще бъде предаден на Интернет слоя на TCP/IP където ще се определи дали хоста (www.vmrejata.info) е локален или отдалечен и дапродължи комуникацията.
Понеже Ping попадав категорията конвертиране на хост имена, стъпките които TCP/IP стека ще премине ще бъдат:
1. Локален хост
2. Файла HOSTS
3. DNS
4. Кеш на NetBIOS имена
5. WINS
6. Броудкаст
7. Файа LMHOSTS
Някои от тези стъпки се отнасят за специфични Microsoft-ски реализации. Повечето хостове днес са Microsoft хостове, стъпките които ще бъдат прескочени за не-Microsofts-ки хостове ще бъдат споменати в редовете надолу.

Локален хост/local host (HOSTNAME)

Първата стъпка в процеса на конвертиране на хост име е да се провери дали локалния компютър (този който се ползва като източник) не е и хоста, който се търси. Toзи процес е известен като local host (локален хост). Local host е метод при който TCP/IP проверява дали името на хоста, на който се изпълнява конвертирането не е същото като името което се конвертира. Може би хоста на който седите е и този хост, който търсите. Не пренебрегвайте най-лесния възможен отговор.
Приложението HOSTNAME може дапомогне за отговор на този въпрос, то се ползва за откриване името на хоста на който седите. В командния ред напишете HOSTNAME инатиснете enter. На екрана ще се изпише името на локалния компютър:

tihomir@ubook:~$ hostname
ubook
tihomir@ubook:~$

Погледнете, че в този пример името на локалния компютър е ubook. Сега този хост знае, че не е www.vmrejata.info. Ако TCP/IP види, че името показано от инструмента HOSTNAME е същото като името, на което се търси превод задачата е изпълнена. TCP/IP може да ползва IP адресана този хост като адрес на получател.
В повечето случаи двете имена са различни, така че TCP/IP продължава със следващите стъпки в процеса опитвайки се да даде отговор на въпроса "какъв е IP адреса на www.vmrejata.info?

Като администратор можете да ползвате приложението HOSTNAME като инструмент когато търсите решение на възникнал проблем, без да е нужно да отваряте няколко диалогови прозореца.

Файла HOSTS

Втората стъпка, която TCP/IP ползва е да погледне въвфайла HOSTS, той е обикновен ASCII текстов файл, който съдържа хост имена и IP адреси. Файла може да съдържа локални и отдалечени имена и IP адреси. Понеже тази стъпкасе преминава рано в процеса на конвертиране на хост имена, този файлтрябва да съдържа често посещавани хост имена и IP адреси. Този файл действа по подобен начин на вашия личен телефонен бележник.
Файла HOSTS няма разширение, той се казва просто HOSTS. Местонахождението на файла зависи от използваната операционна система. Следващата таблица показва къде се намира той, на почесто срещаните операционни системи.

Операционна система ********************** Директория
Windows 95, 98 ************************ \SYSTEMROOT\SYSTEM
Windows NT,2000, XP, 2003,Vista, 2008 *****\SYSTEMROOT\SYSTEM32\DRIVERS\ETC
NetWare ****************************** SYS:\ETC
Unix ********************************* /etc

Файла HOSTS съдържа IP адреси следвани от интервал и после е записано съответсващото име. Например, за да запишете превода на www.vmrejata.info трябва да въведете този ред:
89.252.241.24 www.vmrejata.info
Ако желаете може да въведете по-просто или алтернативно име, нещо по-лесно за писане или запомняне от пълния URL адрес. Когато TCP/IP претърси HOSTS файла и намери думата която сте ползвали в уеб браузара, тогава имаме успешно конвертиране. Следващия пример показва как могат да изглеждат тези редове в HOSTS файла:

89.252.241.24 *** www.vmrejata.info
89.252.241.24 *** vmrejata
89.252.241.24 *** uroci

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

Domain Name System (DNS)

Domain Name System (DNS) е интернет механизъм за свързване на всички хост имен и IP адреси в интернет. DNS е разпределена и свързана система за конвертиране на имена в IP адреси. DNS е система подобна на среда в която всички оператори на телефонни номера са свързани заедно, така че вашето запитване да бъде предадено към подходящия оператор.
Всички URL адреси, за които търсите конвертиране в интернет се намаират в DNS база данни.. някъде там. Администратор на DNS база данни е въвел името и IP адреса в базата данни. Когато ползвате браузър и поискате www.vmrejata.info, www се отнася за услугата, vmrejata за хост името, .info се отнася за част от домейн пространството където се намира този хост. URL е комбинация от услуга, име на хост и домейн където може да бъде намерен този хост. Тези база данни са свързани, когато се опитате да получите конвертиране на даден адрес, DNS сървъра който се опитва даполучи отговора за вас може да бъде пренасочен към друг DNS сървър и така докато конвертира името или докато разбере, че неможе да конвертира името. Ако TCP/IP на този етап се провали да намери IP адреса на този етап, шансовете за успешно конвертиране на името стават малки. Следващите методи и стъпки се отнасят само за Microsoft TCP/IP клиенти опитващи се да получат конвертиране на хост име.

Кеш на NetBIOS имена

Следващата стъпка при конвертирането на хост имена е кеша на NetBIOS имена, който се използва при Microsoft-ските версии на TCP/IP. Когато ползвате Microsoft TCP/IP клиент, TCP/IP гледа в кеша на NetBIOS имена. Това е списък в RAM паметта на локалния компютър, който съдържа наскоро конвертирани NetBIOS имена в IP адреси. Възможно е хост името за което TCP/IP търси IP адреса в момента да е NetBIOS име на машина, която е търсена наскоро. NetBIOS имената в кеша са като телефонни номера написани на бележки и оставени край телефона. Тези бележки имат записани на тях имена и телефони, които сте набирали наскоро. Те са само временни и могат да се затрият скоро.
Подобно на това NetBIOS имената, които са търсени наскоро и са намерени прилежащите им IP адреси се поставят в кеша на NetBIOS имена са кратък период от време. Преди TCP/IP да продължи със следващите стъпки в процеса на конвертиране на името, Microsoft TCP/IP клиента гледа в този кеш. Ако TCP/IP не получи отговора от NetBIOS кеша търсенето продължава с WINS.

SCOPE ID

	NetBIOS scope ID може да бъде конфигурирано като параметър на Microsoft TCP/IP хост. Scope ID-то сегментира една физическа мрежа в логически мрежи. Ако е важно за два хоста в една и съща мрежа да ползват едно и също NetBIOS име или два хоста в една и съща мрежа да бъдат изолирани един от друг може да се ползва scope ID. Той е незадължителен параметър на NetBIOS и TCP/IP конфигурацията.
	Когато конфигурирате TCP/IP на Microsoft хост, scope ID полето се използва рядко. При разрешаването на TCP/IP проблеми обаче scope ID-то може да се превърне в проблем ако е в употреба. Ако два хоста имат различни scope ID-та те немогат да ползват NetBIOS, за да комуникират.
	В TCP/IP мрежа, NetBIOS имената са уникални идентификатори използвани от NetBIOS за конвертиране на имена. Затова неможе два хоста да имат еднакви NetBIOS имена. Scope ID-то разбива NetBIOS мрежата в логически мрежи. Например в полето scope ID на компютрите в счетоводството администратора може да въведе SCHET. Тези хостове могат да се наименуват например HOST1.SCHET или HOST2.SCHET. В друг отдел NetBIOS хостовете могат да имат идентификатор MARKETING и тези хостове могат да се идентифицират като HOST1.MARKETING или HOST2.MARKETING. При този пример администратора е създал 2 логически NetBIOS мрежи, но те са физически в една мрежа. Все пак хостове със scope ID SCHET немогат да комуникират с хостовете, чието scope ID е MARKETING. Scope ID-to трябва да е едно и също за да е възможна NetBIOS комуникацията в една и съща мрежа. Повечето администратори оставят това поле празно.

Windows Internet Naming Service (WINS)

Тази стъпка се преминава само ако хоста искащ конвертиране на името е конфигуриран да използва Windows Internet Naming Service (WINS). Хост неконфигуриран да ползва WINS ще пропусне тази стъпка. WINS представлява сървът за NetBIOS имена на Microsoft.
WINS сървъра пази база на всичките NetBIOS имена и IP адреси на хостове, които са регистирани с този сървър или са въведени ръчно от администратор. Администратора конфигурира Microsoft компютрите в мрежата да регистрират динамично техните NetBIOS имена с един и същ WINS сървър. Когато машина бъде включена, тя се регистрира в централния WINS сървър. Когато друг клиент се нуждае от конвертиране на това NetBIOS име, той се свързва със специалния за това оператор WINS и той връща положителен отговор с IP адреса или отрицателен отговор, казващ че това име неможе да бъде намерено.

Повече информация за настройването на WINS можете да прочетете в глава 14.

Ако на този етап TCP/IP все още не е открил IP адреса на дадено име, TCP/IP започва да се "тревожи" и предприема отчаени мерки.

Броудкаст

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

Файла LMHOSTS

Файла LMHOSTS много прилича на файла HOSTS. Той е ACII текстов файл и съдържа IP адреси, но вместо имена на хостове в него има NetBIOS имена. Във файла LMHOSTS няма алтернативни имена както при файла HOSTS, в този файл може да има само действителни NetBIOS имена. LMHOSTS се ползва само при Microsoft TCP/IP клиенти. Ако клиента не е конфигуриран да проверява файла LMHOSTS или не е Microsoft TCP/IP клиент, тази стъпка се прескача. Файла LMHOSTS се намира в същата папка както и файла HOSTS, за да го намерите по-лесно мойе да се консултирате с таблицата в секцията за файла HOSTS.
Файла LMHOSTS се състои от IP адреси и NetBIOS имена, ето пример за съдържанието на такъв файл:

192.168.1.199 *** DB_SRV ****** #PRE
192.168.1.40 **** WIN2K3_TS *** #PRE
192.168.1.29 **** PROTOBERANS

Някои записи в LMHOSTS имат пояснение в края което разширява употребата им. Първия и втория ред например имат пояснението #PRE. Когато компютъра се зарежда и TCP/IP се стартира, TCP/IP ще погледне във файла LMHOST за записи, които имат #PRE и когато TCP/IP намери такива записи те биват поставени кеша на NetBIOS имена за неопределено време. Когато TCP/IP се опита да конвертира NetBIOS име в IP адрес, то името ще бъде веднага намерено в кеша с NetBIOS имена. Така ще имаме по-бързо конвертиране на NetBIOS имената, защото те бързо ще бъдат намирани!

Командата nbtstat се използва за преглеждане съдържанието на NetBIOS кеша. Тази команда има няколко допълнителни опции, по важните три от тях можете да видите в следващата таблица:

опция описание
-c Показва текущото съдържание на NetBIOS кеша
-r Изтрива всички записи в NetBIOS кеша и зарежда наново всички записи с отметка #PRE от файла LMHOSTS
-n Показва списък с NetBIOS имената, под които тази машина е позната

Да разберем конвертирането на NetBIOS имената

Понеже NetBIOS имената се използват почти само от няколко Microsoft продукта, конвертирането на NetBIOS имена се появява рядко. Приложение ползващо NetBIOS имена по същество ползва същите стъпки, които ползва и TCP/IP приложение ползващо хост имена. Тези стъпки обаче имат различна последователност, ето ги отново:

Пример за приложение ползващо NetBIOS имена е net view:
net view \\ACC
Този ред извиква показване на всички споделени ресурси на хост с NetBIOS име ACC.

Стъпките в цикъла за конвертиране на NetBIOS името:

1. Понеже това приложение ползва NetBIOS имена, първото място където трябва да погледнем е кеша на NetBIOS имена. Възможно е името да е превеждано наскоро или да е поставено в кеша от файла LMHOSTS.
2. Ако името не е в NetBIOS кеша, TCP/IP пита WINS сървър. Ако хостовете в тази мрежа са настроени да ползват WINS сървър шансовете са добри WINS сървъра да има списък със NetBIOS името за което този хост се опитва да намери IP адрес.
3. Ако WINS не успее или хоста не е настроен да ползва WINS сървър, TCP/IP броудкаства съобщение в мрезата опитвайки се да намери отговор.
4. Ако NetBIOS името не е конвертирано след броудкаста, TCP/IP гледа във файла LMHOSTS.
5. Ако името не е във LMHOSTS то може би е във файла HOSTS.
6. И накрая ако името все още не е конвертирано, TCP/IP опитва с DNS.

Ако някой от тези методи успее ще бъдат изписани споделените ресурси на машината с име ACC. Следващия екран показва командата и успешното и изпълнение:

C:\DOCUME~1\ADMINI~1>net view \\acc
	Shared resources at \\acc

	Share name	 Type  Used as  Comment

	---------------------------------------
	Drago		  Disk
	konstantza	 Disk
	makedonia	  Disk
	online		 Disk
	rocossmartpro  Disk
	SmartPro	   Disk
	smartpro2004   Disk
	The command completed successfully.

Ако никой от тези методи не успее да конвертира името в IP адрес, се появява съобщение за грешка:

C:\USERS\TIHOMIR>net view \\acc
	System error 53 has occurred.

	The network path was not found.

[netman]

Първоначално написано от protoberans от [url="http://www.vmrejata.info/tcpip.html"

http://www.vmrejata.info/tcpip.html[/url]]Глава 12 Domain Name System (DNS)


В предходната глава научихте за конвертирането на имена в TCP/IP адреси. Най-важната стъпка при конвертирането на хост имена в IP адреси е използването на DNS. DNS е начин за конвертиране на лесни за употреба и значещи нещо имена в IP адреси. Понеже в интернет има милиони сайтове, управляването на единен списък на имена към IP адреси е нериалистично. DNS системата е проектирана да разпредели и координира натоварването по конвертиране на имената.
Две важни задачи които DNS решава са:

1. Конвертиране на хост имена от интернет в IP адреси за локални хостове
2. Конвертиране на хост имена от локалната мрежа в IP адреси за останалите хостове в интернет

Какво е DNS?

Както научихте в глава 11, Domain Name System (DNS) е разпределена база даннина хост имена и IP адреси в интернет. Ако всички хостове в интернет бяха в една голяма база данни, тя щеше да бъде огромна и неефективна. Но в началото на Интернет първоначалната идея е била съхранението на всички имена на хостове и техните IP адресида бъде в един единствен файл. В ранните дни на интернет хост имената на сайтовете свързани в интернет и техните IP адреси са били пазени в един единствен файл наречен HOSTS.TXT. Този файле бил поддържан от Stanford Research Institute Network Information Center (SRI-NIC). Когато се добавял нов хост към разрастващата се мрежа,се добавял и нов прост запис в HOSTS.TXT с името и адреса на новия хост. Ако вие сте били един от хостовете в интернет, свързвате се със сървъра на SRI-NIC и сваляте последната версия на HOSTS.TXT файла. Когото искате да се свържите към друг хост, можете да ползвате името му и TCP/IP ще прегледа HOSTS.TXT, за да преведе името в IP адрес. HOSTS.TXT файла бил променян постоянно и за да бъде вашияфайл актуален е трябвало да си го сваляте периодично. Но с разрастването на интернет този файл станал неуправляем, броя на промените във файла и броя на хостовете които трябвало да свалят файла растял прогресивно. Тази система се превърнала в тясно място в процеса на конвертиране на имената. През Ноември 1987, DNS бива представен като решение на проблема, DNS е описан в RFC 1034 и 1035.

DNS в интернет

Вместо да пази всички хост и мена и IP адреси в един неуправляем файл, DNS разпределя задачата в интернет. Всички хост имена в интернет са разделени в различни домейни или категории. Домейните от най високо ниво са категории на хост имена - например, комерсиални организации са в .com домейна, образователни организации в .edu домейн. Тези домейни от най-високо ниво са в последствие разделени в домейни от второ ниво и т.н. Примери за домейни от второ ниво са vmrejata.info и abv.bg.
Всеки домейн от най-високото ниво управлява база данни на домейните от второ ниво. Домейните от второ ниво управляват следващото ниво и т.н. Лесен начин да разберете какво представлява интернет е да погледнете карта на пространството от домейн имена. Пространството от домейн имена е термин ползван за да опредили как е разделен Интернет. Корена на това пространство е root, той е представен от точка ".". Илюстрацията по долу представя част от интернет домейн пространството. Root е на върха в дървото от домейни и е представен от точка, домейните от най-високо ниво съдържат база данни, които сочат към DNS сървърите от следващото ниво. Например .com DNS сървъра съдържа база данни, която казва къде се намират всички .com DNS сървъри. DNS сървъра vmrejata съдържа база данни за имена на хостове и услуги, за които да се прдага конвертиране. Например може да съдържа записи, www, ftp, links и други имена за които DNS трябва да предложи конвертиране.



Конвертиране на имена с DNS

Когато TCP/IP ползва DND като метод за конвертиране, хоста който се опитва да получи IP адрес по дадено име се нарича resolver. Resolver-a изпраща съобщение до DNS сървър търсейки помощ. Пакета казва "Хей DNS сървър, можеш ли да ми кажеш IP адреса на www.vmrejata.info?

Запитване към DNS сървър

Когато администратор конфигурира IP адрес на хост, наред с другите параметри той конфигурира и DNS сървър. DNS сървъра може да е в същата мрежа или може да е при интернет доставчика. Когато хост има нужда от превод на име, той изпраща заявка към въведения DNS сървър, този сървър преглежда своята база данни за да види дали може да отговори на въпроса без външна помощ. Ако DNS сървъра може да отговори на въпроса, той ще изпрати отговора на resolver-а и конвертирането завършва.
Ако DNS сървъра не знае отговора, той ще има нужда от външна помощ и ще попита root сървър за имена. Има 13 root сървъра за имена, те са стратегически разположени и имат IP адресите на сървърите с домейн имена от най-високо ниво. Всеки DNS сървър има IP адресите на тези 13 root сървъра автоматично инсталирани в локалните си база данни. Затова всеки DNS сървър може да пита всеки от тези 13 root сървъра за конвертиране на търсеното име.

Запитване сървър за имена

След като DNS сървъра има адреса на root сървъра той може да започне процеса за конвертиране на име. Първото което ще направи DNS сървър от малка мрежа за която никой нищо не знае е да попита големия и мощен root сървър с имена дали той знае IP адреса на www.vmrejata.info.
Root сървъра има IP адреси на домейн сървърите от най-високо ниво и root сървъра отговаря на нашия малък DNS сървър казвайки. "Не познавам www.vmrejata,info но имам адреса на .info" и root сървъра изпраща най-добрата информация която има IP адреса на .info
Сега малкия DNS сървър има адреса на .info той взима информацията и я кешира. Малкия DNS сървър ще пази толкова дълго този адрес в паметта си колкото му е казано от DNS сървъра изпрати му информацията. DNS съръра кешира информацията, защото скоро може и друг хост да попита за конвертиране на URL в домейн .info, като има кеширан адреса DNS сървъра няма да има нужда да притеснява root сървъра отново.
Ползвайки получения адрес DNS сървъра изпраща запитване към .info домейн сървъра и пита за превод на www.vmrejata.info. Сървърът .info няма IP адреса на www.vmrejata.info но има IP адреса на vmrejta.info. Сървърът .info изпраща отговор на DNS сървъра и казва, "Незнам IP адреса на www.vmrejata.info но знам IP адреса на vmrejata.info".
Когато DNS сървъра получи отговор от .info сървъра, той кешира IP адреса на vmrejata.info и позле изпраща запитване до vmrejata.info питайки за IP адреса на www.vmrejata.info.
DNS сървъра при vmrejata.info знае адреса на www.vmrejata.info и го изпраща на DNS сървъра.

Приключване на конвертирането

Сега DNS сървъра има IP адреса на www.vmrejata.info, кешира го и изпраща пакет с IP адреса до resolver-a. Сега resolver-a има IP адреса и изпраща HTTP искане до IP адреса изпратен му от DNS сървъра.
Със всичките тези парчета кеширана информация, DNS сървъра има част от работата (или цялата рабора) ако някой друг resolver го попита за нещо в .info, vmrejata.info или за www.vmrejata.info.

Какво са Recursive и Iterative запитванията

След като бъде изпратено запитване от resolver към DNS сървър, DNS сървъра отговаря с IP адреса или със съобщение за грешка. DNS сървъра скрива цялата работа която трябва да се свърши по време на процеса на конвертиране на URL името. Запитването изпратено от resolver-a до DNS сървъра се нарича recursive запитване. Recursive запитване означава, "Дай ми отговор или ми дай грешка, но не ми давай нищо по средата."
След това DNS сървъра пита други сървъри да му помогнат при конвертирането, запитването което DNS сървър изпраща до друг DNS сървър се нарича iterative запитване. Iterative запитването пита за най-добрия възможен отговор, "Ако нямаш отговор на целия въпрос, моля дай ми нещо с което можеш да помогнеш." Iterative запитванията може да се повторят няколко пъти докато DNS сървъра продължава да пита останалите сървъри за имена, "Помогни ми до колкото можеш.". Затова и другите сървъри отговарят с най-доброто, което имат. Iterative запитванията са скрити от resolvera, той иска отговор но не се интересува колко сървъра помагат при конвертиране на името.

Поддържане на базата данни

Основна задача на DNS сървъра е до осигурява конвертиране за ресолверите конфигурирани да ползват този DNS сървър. Друга важна задача е да поддържа база данни на хост имена и IP адреси. После когато към DNS сървъра бъде отправено запитване, той гледа първо в своята база данни за да установи дали отговора го има там. Администратора на DNS сървър трябва да напише хост имена и IP адреси в базата данни, която DNS сървъра ползва за да изпълнява заявки.
Например администратора на DNS сървъра vmrejata.info, прави запис в базата данни на този сървър и казва, че www.vmrejata.info има IP адрес 89.252.241.24. Когато DNS сървъра vmrejata.info бъде запитан за IP адреса на www.vmrejata.info, той ще отговори с правилния адрес.
Сървъра .info има запис в неговата база данни, който посочва за всяка заявка нещо.vmrejata.info DNS сървъра vmrejata.info. DNS сървъра vmrejata.info има информацията нужна да даде отговор на (всичко което администратора поиска).vmrejata.info. Администратора при vmrejata.info е въвел тези записи в DNS сървъра си, които се съхраняват като зонов файл. Администратора управлява зоната и по-точно зоновия файл на vmrejata.info. Зоновия файл съдържа имена и IP адреси за тази част на пространството от домейн имена. Администратора поставя записите за vmrejata.info в зонов файл наречен vmrejata.info.dns.
DNS е услуга която може да се изпълнява на различни платформи и операсионни системи. Базата данни която всеки DNS сървър ползва се състои от няколко файла. Повечето DNS версии и изпълнения следват стандарт наречен Berkeley Internet Name Domain (BIND) изпълнение. BIND изпълнението описва какви файлове са нужни и каква информация трябва да включват записите в DNS базата.
Всеки DNS администратор управлява DNS база данни. Тези база данни са свързани в интернет, за да образуват мрежа от DNS база данни. Тогава DNS сървърите работят заедно за да осигурят конвертиране на име-към-IP-адрес и IP-адрес-към-име. Понеже всеки администратор управлява собствена база данни и всички база данни работят заедно, успешното DNS конвертиране е резултат на общ труд.

Поддържане на DNS сървър

DNS администратора настойва и управява DNS база данни. Софтуер за DNS сървър може да върви на няколко операционни системи. В зависимост от избраната операционна система, метода за администриране се различава малко, но основната концепция е една и съща. Сървър върху които се изпълнява DNS услуга се нарича name server, има три типа name сървъри.

Основен нейм сървър (Primary Name Server)

Primary Name Server-a съдържа master DNS база данни (това е актуална DNS база данни съдържаща DNS записи, където администратора може да коригира записите). Администратора прави всички промени в тази master DNS база данни. Primary name сървъра съхранева копие за четене и писане на master DNS базата данни. За да добави или изтрие записи от DNS базата данни администратора влиза в Primary Name сървъра и променя master DNS базата данни.
Със само едно копие на DNS базата данни върху основния нейм сървър процеса на конвертиране на имена ще си върви чудесно, все пак администратора има опция да асистира на основния нейм сървър като настори secondary name server.

Secondary Name Server (Вторичен нейм сървър)

Вторичния нейм сървър съхранява копие на DNS базата данни. Този сървър осигурява конвертиране на името по същия начин по който го прави и основния сървър. Вторичния сървър помага на основния сървър, администраторите поставят вторичен DNS сървър по следните причини:
- Отказо устойчивост - Ако един от сървърите откаже или не е на разположение, другия сървър ще бъде на разположение да изпълнява заявките за конвертиране на имена.
- Балансиране на натоварването - Ако сървър бъде претоварен от заявки, втори сървър ще намали натоварването.
- Отдалечено конвертиране - Ако е нужно да се конвертират имена в IP адреси в отдаечено място, там може да въде инсталиран вторичен DNS сървър, за да може заявките от resolver-и да се изпълняват на място и да не се генерира допълнителен WAN трафик.

DNS Zone Transfer

Вторичния нейм сървър получава копие на основната DNS база данни от главния нейм сървър. Администратора не прави корекции в базата данни на вторичния нейм сървър, всички промени се правят само на основния нейм сървър. Вторичния сървър съхранява копие само за четене на DNS базата данни. Когато бъде направена промяна на основния нейм сървър, копие на базата (зонов файл) се изпраща на вторичния нейм сървър.
Трансфера на базата се нарича zone transfer. Zone transfer-а премества базата от основния DNS сървър на вторичния DNS сървър. Когато вторичен нейм сървър дойде на линия, той автоматично започва zone transfer. Администратора също може да настрои zone transfer от един вторичен нейм сървър към друг вторичен нейм сървър. Първия трансфер трябва да бъде от основния DNS сървър към вторичния, после вторичния препредава DNS базата данни.
Илюстрацията по-долу е пример за трансфер на DNS базата данни:



Кеш сървър (Caching-only Server)

Кеш сървъра не съдържа база данни. Когато сървър за кеш се появи на линия, той не знае нищо. Когато първата заявка за конвертиране бъде отправена към този сървър, кеш сървъра трябва да започне процеса на конвертиране от root сървъра и да премине по отделните нива. След като конвертира URL името, той вече има малко информация кеширана в паметта за следващата заявка. Кеш сървъра бързо учи и кешира най-често търсените имена. Кеш сървъра изисква малко за настройване и почти никаква поддръжка. Когато DNS сървър бъде първоначално инсталиран, той е по същество кеш сървър докато не му бъде добавена зоновата база данни.
Кеш сървърите са отличен избор за отдалечени офиси свързани с WAN връзки. Понеже няма зонов трансфер, когато кеш сървъра се появи на линия няма и първоначално натоварване на честотната лента.

Видове записи в DNS

DNS базата данни е колекция от записи. Има няколко типа записи които могат да бъдат включени в DNS базата данни. Някои от често срещаните записи са:

* Start Of Authority (SOA) запис
* A запис
* CNAME запис
* NS запис
* PTR запис
* MX запис

Start Of Authority (SOA) запис

DNS базата данни започва със запис наречен (SOA). Има само по един SOA запис във всяка зонова база данни. Този запис описва зоната в пространството от домейн имена, за които тази база данни е отговорна.

А запис

А записа е още наричан хост запис. Това е най-често срещания вид запис в DNS базата данни. А записа съдържа хост имена и IP адреси.

CNAME запис

Термина CNAME означава Canonical name (канонично име), доста интересно е наименуван. Този запис е просто кодово име за A запис. CNAME са по-рости алтернативни имена, записани в DNS базата данни. Тези записи предлагат различен начин за описване на хост записите, които вече са в базата данни.
Например нека кажем, че администратор иска хората да могат да получат конвертиране на site.vmrejata.info и www.vmrejata.info. И двете имат един и същ IP адрес. В DNS базата данни вече има A запис за www.vmrejata.info, така че администратора просто поставя CNAME запис в базата за site който посочва www А записа.

NS запис

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

PTR запис

PTR записа служи за конвертиране на искане за IP адрес не за хост име. Ако пристигне искане което казва, "Ето IP адреса, какво е името на хоста?" PTR записа ще осигури отговор на този въпрос. Всеки път когато се въвежда А запис в базата данни би трябвало да се въвежда и PTR запис.
Някои приложения са написани така, че да искат хост име (приложението знае IP адреса, но иска хост името). Заявката която тези приложения изпращат към DNS сървъра се нарича reverse или inverse (обратна) заявка. DNS сървъра преглежда PTR записа и отговаря с хост името, което отговаря на подадения IP адрес. Тези PTR записи са в специална зона наречена IN-ADDR.ARPA зона. Когато пристигне обърната заявка DNS сървъра може да погледне в IN-ADDR.ARPA зоната за по-бърз отговор.

MX запис

MX записа се отнася за Mail eXchange запис. Този запис има IP адреса на сървъра където трябва да се достави e-mail съобщение. Например, когато e-mail е изпратен до administrator(at)vmrejata.info, DNS сървъра при vmrejata е запитан за e-mail сървъра при vmrejata.info, DNS сървъра поглежда в MX запис за vmrejata.info и връща IP адреса на e-mail сървъра където трябва да се изпрати писмото.

Други типове записи

Администраторите могат да ползват и други записи за техните DNS база данни. Пример за такива записи са WKS записи, които сочат към WellKnown Services (добре познати услуги) или RP запис, които индикира Responsible Person (отговорното лице) за базата данни. Най-използваните записи все пак са тези които разгледахме с тази глава.

[netman]

Първоначално написано от protoberans от [url="http://www.vmrejata.info/tcpip.html"

http://www.vmrejata.info/tcpip.html[/url]]Глава 13 Dynamic DNS (DDNS)


През последните години Dynamic DNS стана стандартен метод за обновяване записите в DNS базите данни. Както има смисъл от използването на DHCP така има смисъл от използването на Dynamic DNS. В глава 7 научихте как действа DHCP, в тази гава ще научите за техника, която разширява DNS ползвайки DHCP.

Какво е Dynamic DNS

DHCP сървъра се ползва за автоматично назначаване на IP адреси. Това означава, че администратора няма нужда да обикаля всеки компютър и да въвежда IP адреса, подмрежовата маска, основния шлюз и другите опции. Вместо това всеки път когато бъде включен DHCP клиент в мрежата той броудкаства запитване в мрежата и получава своя IP адрес. Това освобождава администратора от извършването на една и съща работа по въвеждането на всички IP адреси.
В контраст на това научихте, че DNS се обновява ръчно. Това означава, че администратора трябва да влезе в DNS сървъра, за да направи промени по DNS базата данни. За да ъпдейтне DNS администратора трябва да добави хост име и IP адреса на това хост име, за да може след това то да бъде превеждано в зоната на DNS сървъра. Администратора ъпдейтва DNS базата като добавя A запис, който е хост към IP адрес запис и PTR запис който е IP адрес към хост име. Сега DNS сървъра може да предложи и двата типа конвертиране име-към-IP и IP-към-име.
Dynamic DNS позволява на DHCP сървърите и на HCP клиентите да изпращат ъпдейти на DNS сървъра. Тези ъпдейти в DNS базата данни се правят без намесата на администратора и потребителите не е нуйно да знаят ако някой IP адрес се променя или премества. Когато потребителите се нуждаят от конвертиране на хост име към IP адрес, DNS ще предложи текуща и вярна информация.
Когато DNS е бил проектиран, се очаквали промени в DNS базата данни но не много често. Записите в DNS базата данни се отнасяли за хостове чийто IP адреси са статични. Проектантите на DNS не са могли да предвидят невероятния ръст на интернет. Много администратижни задачи станали автоматизирани, но DNS останал резултат на ръчен труд. DHCP се превърнал в стандарт за автоматично задаване на IP адреси и DNS имал нуждата да се разшири и да получи облаги от автоматичното назначаване на IP адреси. Без Dynamic DNS, DHCP сървъра задава динамични IP адреси на хостовете, но DNS сървъра неможе да предложи конвертиране на техните имена в IP адреси докато администратора не ъпдейтне DNS азата данни. В миналото е нямало по-лесен начин за свършване на тази работа, сега използвайки Dynamic DNS, когато DHCP сървъра даде IP адрес, той също ъпдейтва DNS с новата информация.

Dynamic DNS е дискутиран в RFC 2136, а сигурността на Dynamic DNS e дискутирана в RFC 2137.

Dynamic DNS ползва автоматизацията на DHCP, за да автоматизира ъпдейтите в DNS базата данни. DHCP сървъра играе ключова роля в Dynamic DNS. Двете части информация за хоста от които DHCP се нуждае, за да обнови информацията в DNS са IP адреса на хоста и fully qualified domain name (FQDN). Тъй като DHCP сървъра току що е назначил име на хоста, то той знае IP адреса. За да намери FQDN, DHCP сървъра поглежда в пакета DHCP искане. Помнете, че всеки пъп когато DHCP клиент се появи на линия той броудкаства пакет, за да намери и да наеме IP адрес от DHCP сървър. DHCP сървъра знае името на хоста като гледа в теси пакети, но домейн името е една от опциите която DHCP сървъра назначава. Тъй като DHCP сървъра назначава домейна, той вече знае домейна на клиента. DHCP сървъра поставя тази информация заедно и получава FQDN.
Например, ако машина с име protoberans и DHCP сървър във vmrejata.info домейна назначи IP адрес на хоста protoberans, DHCP получава FQDN за този хост protoberans.vmrejata.info. Сега DHCP сървъра може да регистрира тази информация в DNS сървъра.
След като DHCP сървъра приключи с отдаването на IP адрес на клиента се изпраща DNS ъпдейт запис до DNS сървъра. Dynamic DNS може да бъде настроен по няколко различни начина. Помнете че има два типа записи, които да се ъпдейтват, A записът и PTR записът. Опциите за Dynamic DNS включват следното:

* DHCP сървъра изпраща PTR запис, а клиента изпраща A запис.
* DHCP сървъра изпраща и двата записа A и PTR.

Когато периода за наем на IP адреса изтече, DHCP сървъра ще изпрати друга заявка за ъпдейт към DNS сървъра и ще му каже да премахне А и PTR записите.

Конфигуриране на Windows Server 2000 и 2003 за динамично ъпдейтване

При Windows Server 2000 и 2003 първоначалните настройки са DHCP сървъра да изпраща заявка за обновяване на PRT записа и Windows 2000/XP клиента да изпраща заявка за ъпдейт на A записа. Ако администратора не жеае клиента да върши допълнителна работа по ъпдейта на DNS базата данни или просто желае DHCP сървъра да върши цялата работа, той може да модифицира първоначалните настройки.
За да модифицирате първоначалните настройки в Windows Server 2000/2003 щракнете с десния бутон върху DHCP записа в DHCP Manager и изберете Properties.


Натиснете таба DNS; това ще ви покаже настройки за ползване на Dynamic DNS. Първата опция - Automatically Update DHCP Client Information in DNS, трябва да бъде маркирана за да бъде Dynamic DNS включен и да бъдат активни останалите опции, които са:

* Automatically Update DHCP Client Information in DNS
* Update DNS Only If DHCP Client Requests
* Always Update DNS
* Discard Forward (Name-to-Address) Lookups When Lease Expires
* Enable Updates for DNS Clients That Do Not Support Dynamic Update

Update DNS Only If DHCP Client Requests

Тази опция е включена по подразбиране. По време на преговорите за наемане на IP адрес клиента ще изпрати заявка да обнови собствения си A запис и DHCP сървъра трябва да обнови PTR записа, следователно DHCP сървъра е помолен да ъпдейтне DNS базата данни. Избирайки опцията Update DNS Only If DHCP Client Requests:

* DHCP сървъра изпраща молба за ъпдейт на PTR записа.
* Клинта изпраща молба за ъпдейт на А записа.

Always Update DNS

Ако тази опция е избрана DHCP изпраща молба за ъпдейт и на двата записа A и PTR. Администратора може да избере тази опция когато DHCP клиента е в отдаечена мрежа и локалния DHCP сървър е по удобно да изпрати ъпдейта. Избирайки опцията Always Update DNS:

* DHCP сървъра изпраща заявка за ъпдейт на PTR и A записите.
* DHCP клиента не прави нищо.

Discard Forward (Name-to-Address) Lookups When Lease Expires

Тази опция е включена по подразбиране и е добра идея администратора да я остави включена. Тя оказва на DHCP сървъра да бъде отговорен за премахване на DNS записите, когато наема изтече. Когато тази опция е включена дори DHCP клиента да не е на линия когато срока на наема изтече, DHCP сървъра ще поиска и двата записа A и PTR да бъдат премахнати от DNS базата данни.

Enable Updates for DNS Clients That Do Not Support Dynamic Update

Преди Dynamic DNS, DHCP клиентите не са преговаряли за ъпдейт на DNS. Понеже има останали DHCP клиенти не написани да ползват Dynamic DNS, включването на тази опция ще накара DHCP сървъра да ъпдейтне DNS записите за всеки клиент, който не предложи да го направи. Тази опция трябва да бъде включена.

Statically-Assigned IP Addresses and Dynamic Update

Всеки път когато Windows 2000/XP клиент, който има статично зададен IP адрес влезе в мрежата, клиента ще регистирира и двата записа A и PTR. Ако администратор промени IP адреса киента ще изпрати молба за ъпдейт на A и PTR записите.

Конфигуриране на клиент за Dynamic DNS

Windows 2000/XP клиентите са настоени да ъпдейтват DNS по подразбиране. За да модифицирате тези настройки щракнете с десния бутон върху My Network Places и изберете Properties. След това от прозореца Network and Dial-up connections изберете конекцията, която искате да модифицирате щракнете с десния бутон върху нея и избетере Properties.



После маркирайте TCP/IP в Loca Area Connection и натиснете бутона Properties. От страницата TCP/IP Properties натиснете бутона Advanced... В страницата Advanced TCP/IP Settings изберете DNS.



От този екран изберете Register this connection's address in DNS и/или Use this connection's DNS suffix in DNS registration.
- Ако Register this connection's address in DNS е избрана тогава Dynamic DNS е включен на този клиент и клиента ще изпрати молба за ъпдейт на А записа в DNS базата данни ползвайки FQDN и IP адреса. Ако тази опция не е избрана клиента няма да изпрати молба за ъпдейт.
- Ако опцията Use this connection's DNS suffix in DNS registration е избрана, клиента ще изпрати на DNS сървъра първата дума от името на компютъра (като protoberans) и DNS suffix-а написан в полето "DNS suffix for this connection" (като например vmrejata.info) за тази конекция. Тази опция е полезна ако DNS суфикса се различава от домейн името.

Друга опция налична при Windows Server 2000/2003 е приемане на молби за динамично обновяване на записите само от компютри, които имат акаунт в активната директория (Active Directory). Веднъж въведени A и PTR записите могат да бъдат променяни само от компютъра изпратил оригиналната молба за вписване на тези записи. Опцията за сигурен ъпдейт ще отхвърли всякакви некриптирани ъпдейти изпратени от DHCP сървър или клиент. Тази опция предпазва зоната и записите в нея да бъдат модифицирани от неоторизирани компютри и предлага възможност за определяне на потренителите и групите, които са оторизирани да модифицират зони и записи. За да конфигурирате тази опция отворете properties прозореца за DNS сървъра и в таба General изберете за Alow Dynamic Updates полето Ony secure updates.

Повечето DNS сървъри днес поддържат Dynamic DNS, някои приложения разчитан на Dynamic DNS. Например Active Directory може да ползва само DNS сървър, който поддържа DDNS. Active Directory динамично регистрира услуги (SRV записи) и после Active Directory клиентите запитват DNS за SRV записите, за да намерят IP адреса на търсената услуга. Домейн контролера е пример за услуга чийто IP адрес ще търсят клиентите. По време на инсталацията на Active Directory, инсталационната програма търси и проверява дали DNS сървъра поддържа DDNS. Ако DNS сървъра не поддържа DDNS инсталационната програма предлага да инсталира и използва DNS на Mictosoft.

Dynamic DNS в Интернет

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

Ползи от Dynamic DNS

Ползи от Dynamic DNS има както за администраторите, така и за потребителите. Администраторите няма нужда да правят постоянни и податливи на грешки ъпдейти в техните DNS база данни. Потребителите получават конвертиране и информацията е по-прясна и точна от това което е възможно със старите ръчно ъпдейтвани DNS база данни. Веднъж конфигурирани Dynamic DNS транзакциите се извършват прозрачно (Потребителя незнае нищо за тях, потребителя не трябва да знае нещо за тях, потребителя не трябва да прави нищо). Колкото и често IP адреса на хоста да се променя, името на хоста ще бъде налично в DNS базата данни. Потребителите в мрежата ще получават конвертиране за този хост, дори да е получил нов IP адрес преди минути различен от IP адреса който е имал преди 2 часа.

[netman]

Първоначално написано от protoberans от [url="http://www.vmrejata.info/tcpip.html"

http://www.vmrejata.info/tcpip.html[/url]]Глава 14 Windows Internet Naming Service (WINS)

WINS е локална база данни от NetBIOS имена и IP адреси. WINS услугата предага конвертиране от WINS базата данни за клиентите, когато е нужно конвертиране на NetBIOS име към IP адрес.

NetBIOS приложения

Много мрежи в наши дни са съставени от работни станции, които ползват различни версии на операционните системи Windows. Има няколко приложения написани да ползват NetBIOS имена на компютрите вместо хост имена. Например потребител в мрежата може да отвори приложение наречено Network Neighborhood и да види имената на останалите работни станции и сървъри. Network Neighborhood показва NetBIOS имената на останалите хостове.
Когато Microsoft хост бъде включен и започне да изгражда TCP/IP стека си се включват няколко NetBIOS услуги. NetBIOS услугите предлагат услуга на локалния компютър или на останалите компютри в мрежата. Някои от NetBIOS услугите, които хост може да предлага включват workstation service и server service.
Workstation service - NetBIOS услуга, която извършва дейности на работната станция като например използване на локалната операционна система.
Server service - NetBIOS услуга която извърша сървърни дейности, като споделени файлове напримен.
Тези услуги са като приложения стартирани на хоста, хоста автоматично стартира тези услуги и ги предлага на останалите хостове. NetBIOS името и услугата които се предлагат трябва да са уникални за мрежата; никой друг хост немойе да предлага същото NetBIOS име и услуга.

Процеса на конвертиране на NetBIOS имена без WINS

NetBIOS името на компютъта трябва да бъде конвертирано в IP адрес, за да може TCP/IP да комуникира с хоста. Ако хоста неуспее да конвертира NetBIOS името в IP адрес, няма да има комуникация. Конвертирането на NetBIOS имена е разработено отдавна, без използване на WINS. Microsoft TCP/IP клиентите, могат да извършват конвертиране на NetBIOS имена без WINS. Все пак WINS предлага няколкго подобрения за които ще научите в тази глава.

Регистриране на имената

Преди да дойде реда на NetBIOS конвертирането, NetBIOS хостовете трябва да преминат през процес на регистриране на техните NetBIOS имена. Процеса на конвертиране на NetBIOS имена започва когато TCP/IP хост изпълняващ NetBIOS услуги бъде стартиран; хоста броудкаства пакет за регистрация на NetBIOS име, който включва NetBIOS името му и услугата която предлага. Ако друг хост в мрежата получи броудкаста и има същото име, той ще изпрати negative acknowlidgement (отрицателно потвърждение). Регистриращия се хост слуша за отрицателни потвърждения и ако не получи такива, то той смята че има уникално име. Ако хоста получи отрицателно потвърждение, на потребителя ще бъде показано съобщение за грешка съобщаващо, че NetBIOS името е вече във употреба.
Когато всички хостове идват на линия и броудкастват своето NetBIOS име и услуги, тогава нема да има дублиране. Хоста може да предлага няколко NetBIOS услуги и ще броудкастне всяка. Ако втори хост в мрежата иска същото NetBIOS име, той няма да може да стартира никакви NetBIOS услуги, които вече съществуват в мрежата. Когато хост бъде изключен или излезе от мрежата NetBIOS името става свободно, защото тогава може друг хост да дойде на линия и да броудкастне това име и оригиналния носител на това име няма да може да изпрати отрицателен отговор.

Конвертиране на име

Научихте как става регистрацията на NetBIOS имената, сега идва ред на тяхното конвертиране. Когато хост в мрежата иска да комуникира с друг хост в мрежата, като ползва NetBIOS приложение, то иницииращия хост ще ползва метода за конвертиране на NetBIOS имена както е описан с глава 11.
Първото място където ще погледне за конверторане на NetBIOS име е кеша за NetBIOS имена, може името наскоро да е конвертирано или да е записано във файла LMHOSTS като предварително зареждащо се в кеша за NetBIOS имена. Ако NetBIOS името не е в кеша и хоста не е конфигуриран да ползва WINS то той ще генерира броудкаст запитване за NetBIOS името. Пакета запитване за NetBIOS име съдържа търсеното NetBIOS име и IP адреса на търсещия го хост. Този пакет бива изпратен в мрежата с молба притежателя на това име да отговори с IP адреса си. Всички хостове преглеждат сеге си когато получат такъв пакет. Когато притежателя на името види, че търсеното име съвпада с неговото, се изпраща отговор на запитването за име до източника на запитването. Отговора включва IP адреса и NetBIOS името, сега когато хоста търсещ конвертиране знае IP адреса, TCP/IP ще започне комуникационния процес.
Този процес на конвертиране на NetBIOS имена е ефективен и работи добре в малки мрежи. С разрастване на мрежата обаче този метод става неприемлив, когато мрежата се разраства става очевидно че броудкаста за конвертиране на NetBIOS име става неефективен и консумира голяма част от честотната лента, което намалява ефективността на мрежата.

Конвертиране на NetBIOS име със WINS

За да се намали неефективността на използването на броудкаст за конвертиране на NetBIOS имена, е създаден сървър за NetBIOS имена. Сървъра за NetBIOS имена съдържа динамична база данни със NetBIOS имена и IP адреси. WINS е услуга която действа като сървър за NetBIOS имена. WINS услугата може да бъде инсталирана на Windows NT сървър.
IP адреса на WINS трябва да бъде конфигуриран за всеки хост, който ще ползва WINS сървъра. Понеже администратора може да не ползва WINS сървър, затива и IP адреса на WINS сървър e допълнителен параметър в TCP/IP конфигурацията. Администратора може да въведе ръчно IP адреса на WINS сървъра на всеки хост или ако в мрежата има DHCP сървър, то IP адреса на WINS сървъра може да се въведе като допълнителен параметър даван с назначаването на автоматичен IP адрес.

Регистриране на имената

Процеса на регистрация на NetBIOS имената се променя за клиентите конфигурирани да използват WINS. Сега когато хоста се появи в мрежата вместо да броудкаства пакет за регистрация на NetBIOS мето си, той изпраща този пакет директно на WINS сървъра. Пакета включва NetBIOS името, IP адреса и NetBIOS услугата която хоста регистрира. WINS сървъра поглежда в базата си данни, за да види дали това NetBIOS име е вече регистрирано. Ако няма други записи с това NetBIOS име, то WINS сървъра изпраща положително потвърждение към клиента.
Ако WINS сървъра види, че друг хост вече е регистрирал това NetBIOS име, тогава WINS сървъра изпраща challenge. Challenge пакета се изпраща до IP адреса на хоста регистрирал това име. Този пакет пита, "Хей, там ли си все още?" Ако хоста отговори, че е все още там, тогава WINS сървъра изпраща отрицателно потвърждение към хоста искащ регистрация на името. Този хост ще изведе съобщение за грешка, че съществува дублиране на името. Ако на challenge пакета не бъде даден отговор, тогава WINS сървъра приема, че първоначалния хост го няма вече. WINS сървъра ъпдейтва WINS базата данни и изпраща положително потвърждение до хоста искащ регистрацията.
Ако хост изпрати пакет за регистрация на NetBIOS име до WINS сървър и WINS сървъра не изпрати отговор, тогава хоста ще изпрати пакета още три пъти преди да се откаже. Ако хоста не получи отговор от WINS сървъра след три опита, тогава хоста броудкаства пакет за регистрация на NetBIOS името и слуша за отрицателно потвърждение. Когато WINS сървъра изглежда, че не работи клиента се връща към метода за регистриране на име без WINS сървър.

Конвертиране на име

Когато се използва WINS конвертирането на NetBIOS име е прост процес, който започва с изпращане на запитване за името до WINS сървъра. Вместо да броудкаства запитване за името и да смущава цялата мрежа, просто се изпраща запитване директно до WINS сървъра. WINS сървъра преглежда WINS базата си и изпраща положителен или отрицателен отговор.
Ако търсеното NetBIOS име го има в WINS азата данни, тогава NetBIOS името заедно с IP адреса се изпращат до източника на запитването. Това е положителен отговор на запитването за име. Сега хоста има IP адреса на получателя и TCP/IP ще започне комуникация с този хост.
Ако NetBIOS името не е в WINS базата данни, тогава сървъра изпраща отговор до източника на запитването и казва, че NetBIOS името не е регистрирано. Това е отрицателен отговор на запитването за име. Когато изпращача на запитването получи отрицателен отговор, този хост ще продължи със следващата стъпка в процеса за конвертиране на NetBIOS име, която е броудкаст за конвертиране на име.

В мрежата WINS услугата консумира ресурси на сървъра, на който е инсталирана. Броя на WINS клиентите и броя на NetBIOS приложенията определят натоварването на сървъра. Преценява се, че един WINS сървър може да обслужва 10000 клиента. Нужен е само един WINS сървър, но е препоръчително използването на втори за отказоустойчивост. Във всеки случай администратора трябва внимателно да наблюдава консумираните от процеса на конвертиране на имена ресурси на сървъра. WINS сървърите могат да бъдат конфигурирани да споделят база данни в големи мрежи.
Понеже WINS клиентите изпращат запитванията за регистрация на NetBIOS име и за конвертиране на NetBIOS име директно на WINS сървъра, един WINS сървър може да обслужва няколко подмрежи. Помнете броудкаст пакетите не преминават през рутерите и се разпространяват само в подмрежата в която се намира и изпратилия ги хост.
Когато WINS клиент бъде изключен правилно, той изпраща съобщение за освобождаване на NetBIOS името до WINS сървъра. Това казва на WINS сървъра, че NetBIOS името вече не е в употреба. Сега ако друг хост поиска да регистрира това име, то WINS сървъра ще знае, че то е свободно.

[netman]

Първоначално написано от protoberans от [url="http://www.vmrejata.info/tcpip.html"

http://www.vmrejata.info/tcpip.html[/url]]Глава 15 IP Version 6


В тази книга разгледахте TCP/IP адресите използвани с версия 4 на Internet Protocol (IPv4). Заради големия разтеж на Интернет и други фактори за които ще научите в тази глава, IPv4 е в процес на заместване от IP версия 6 (IPv6).
Повечето принципи за които научихте се отнасят за IPv6, някои са заменени и са добавени нови. Полезно при работата с IPv6 е да имате солидни познания по IPv4.

Нуждата от нова версия на TCP/IP

IPv4 е разработен в началото на 70-те години, той е доказа своята стабилност и е широко приет протокол, в следствие на големия разтеж на интернет IPv4 не е вече жизнеспособен. IPv6 започва да замества IPv4 като интернет стандарт. IPv6 е наричан още Internet Protocol Next Generation (IPng) IP следващо поколение.
IPng не е просто ъпгрейд на IPv4, той е щателно ревизиран протокол. Много от особенностите си приличат и основните методи на IPv4 са си същите. IP Адресите обаче са различни, а хедърите са по-леки и специализирани. IPv6 предлага повече опции, включително по-голем контрол на потока и по-висока сигурност.
От началото на 1998 е създадена тестова мрежа за IPv6 в интернет. Мрежата е наречена 6BONE и се е развила до повече от 400 сайта и свързва мрежи в повече от 40 държави. На базата на 6BONE мрежата се предвижда да протече преминаването към IPv6. Процеса на преминаване към новия протокол се очаква да отнеме 10 години. Веднъж въведен IPv6 се очаква да бъде стандарт за десетилетия напред.

IPv6 адресирането

IPv4 изпитва недостиг на мрежови адреси и маршрутните таблици са препълнени, от началото на 90-те е очевидно, че нещо трябва да се направи. Резултат на общи усилия и тестване е IPv6. Проектиращите го инженери са фокусирали подобрениета в областта на адресирането, ефективността и разширената сигурност.
Новия протокол предлага много повече IP адреси от IPv4, тези нови IP адреси ще се записват нов начин на записване в шестнадесеттичен вид.

IPv4 и IPv6 адресите

При IPv4 има 32 бита във всеки адрес, това означава че съществуват приблизително 4 милиарда уникални адреса. Този брой адрси би бил достатъчен за първоначалното предназначение на ARPAnet, но след превръщането на ARPAnet в Интернет и огромния брой хостове свързани към тази мрежа, IPv4 адресите са на изчерпване.
IPv6 използва 128 битови адреси, адреси с доста по-голям размер от този на IPv4 и това означава един умопомрачителен брой адреси:
IPv4 адреси (232):
4,294,967,296
IPv6 адреси (2128):
340,282,366,920,938,463,463,374,607,431,768,211,456
Огромен брой уникални IP адреси (как подяволите се произнася това число?).
Ако повърхността на земята е 511,263,971,197,990 квадратни метра, тогава за всеки квадратен мерът имаме 665,570,793,348,866,943,898,599 уникални IP адреси.

Защо са ни толкова много адреси? Дали проектантите не са се поувлякли малко? Друг план е предлагал 64 битови адреси, но проектантите сметнали, че това може да ограничи разтежа на Интернет в бъдеще. Помислете за бъдещето, какви устройства биха имали нужда от IP адрес? Възможно ли е всичко в дома ви да бъде свързано към интернет? домакински уреди, осветление, клетъчни телефони, лаптопи, вашата кола? Е ако поживеем достатъчно дълго ще разберем, но каквото и да стане имаме адресната схема която ще предложи достатъчен брой адреси.

Новите шестнадесеттични IPv6 адреси

До тук разглеждахте IPv4 адресите, които представляват 32 битов адреси и изглеждат така:
192.168.1.1
IPv6 адресите са 128 битови адреси и се записват в шестнадесеттичен вид. Шестнадесеттичната бройна система ползва същите сифри от 0 до 9 като десетичната и след това A, B, C, D, E и F за да представи 10, 11, 12, 13, 14 и 15. Десетичното 16 в шестнадесеттичн вид е 10. Следващия адрес е пример за IPv6 адрес:
EFDC:BA62:7654:3201:EFDC:BA72:7654:3210
Това е пример за пълен IPv6 адрес където всичките 32 шестнадесеттични цифри имат стойност. Един IPv6 адрес със много 0-ли може да бъде с дължина 8 шестнадесеттични цифри. Понеже IPv6 адресите са 128 бита дълги, трябва да бъде въведен нов стандарт на записване. Ако се ползва IPv4 стила на адресите, 128 битовия адрес ще би представлявал до 48 десетични цифри. Вместо това се използват шестнадесеттични цифри, за да представят двуичните адреси. Всяка секция от шестнадесеттични цифти представя 16 бита от адреса. За разделяне на 32-те шестнадесеттични цифри се използват 7 двоеточия. Този адрес се определя като 39 знаков адрес (32+7). Някои адреси ще имат доста 0-ли в адреса, например:
1080:0000:0000:0000:0008:0800:200C:417A
За да направи записването по-лесно, незначителните водещи 0-ли могат да бъдат премахнати. Така че горния адрес може да се запише като:
1080:0:0:0:8:800:200C:417A
Дори този по-гратък адрес изглежда прекалено дълъг, за щастие можем да го скъсим още малко. Понеже адреса има няколко последователни 0-ли, можем да ги премахнем и просто да въведем двуеточията заедно. Горния адрес може да бъде записан така, използвайки метод на записване с две двуеточия:
1080::8:800:200C:417A

Начин на записване с две двуеточия

Когато видите адрес записан с две двуеточия, няма да стане веднага ясно колко и кои 0-ли липсват. Отварянето на адрес записан във вид с две двуеточия, представлява двустъпков процес за хората. Първо въдете точния брой Х-сове разделени от двуеточие, и заместете Х-совете със стойностите от адреса, които са в отляво на двете двуеточия, започвайки от ляво на дясно. Например:
1080:x:x:x:x:x:x:x
После започнете от най-дясната страна на адреса и заместете Х-совете със стойностите от дясно на ляво. Например:
1080:x:x:x:x:x:x:417A
1080:x:x:x:x:x:200C:417A
1080:x:x:x:x:800:200C:417A
1080:x:x:x:8:800:200C:417A
Сега когато сте въвели всички дадени стойности заместете останалите Х-сове с нули.
1080:0:0:0:8:800:200C:417A

Важно правило при метода на записване с две двуеточия е, че те могат да се ползват само веднъж в адреса.

IPv4 адрес може да бъде използван в IPv6 адресната схема. Шестнадесеттичния еквивалент на IPv4 адреса се записва в последните 32 бита на IPv6 адреса. Например IPv4 адреса:
192.168.2.100
в IPv6 адрес е:
::C0A8:0264
(което е 0:0:0:0:0:0:C0A8:0264).

Конвертирането на десетичните числа в шестнадесеттични се извършва лесно с калкулатор.

 Да опитаме да конвертираме IPv4 адрес в IPv6 адрес

	За да конвертирате IPv4 адрес към IPv6 адрес, първо конвертирате всяка част от десетичния адрес в шестнадесетична стойност. Понеже всяка шестнадесетична стойност трябва да се представя от два знака, добавяте 0 към всяка стойност която има само една цифра. После поставяте първия и втория октет заедно за да формирате шестнадесетична стойност от четири знака. После поставяте двуеточие и правите същото за третия и четвърти октет.

	Като пример опитайте да конвертиране 10.153.92.151 към IPv6 адрес.

	Решението е:

	   1. Използвайки калкулатор десетичното 10 в шестнадесетично е:
		  10 - А
	   2. Конвертирайте десетичното 153 в шестнадесетично:
		  153 = 99
	   3. Конвертирайте десетичното 92 в шестнадесетично:
		  92 = 5C
	   4. Конвертирайте десетичното 151 в шестнадесетично:
		  151 = 97
	   5. Всяка от тези шестнадесетични стойности трябва да бъде представена от два знака. Добавете 0 към всяка шестнадесетична стойност, която има само една цифра (A става 0A).
	   6. Поставете шестнадесетичните цифри заедно: 0A99:5C97.

	Сега опитайте този пример: Конвертирайте 192.168.15.73 в IPv6 адрес. Решението е както следва:

	   1. 192 = C0
	   2. 168 = A8
	   3. 15 = F
	   4. 73 = 49
	   5. F става 0F
	   6. Поставете всички шестнадесетични цифри заедно и получавате: C0A8:0F49.

Специални IPv6 адреси

* Неуточнен адрес

Адреса 0:0:0:0:0:0:0:0 се нарича неуточнен адрес. Той не трябва да се дава на хост, всъщност той представлява липса на адрес. Неуточнения адрес се ползва например когато IPv6 хост изпраща пакет търсейки адрес. Частта за източник на пакета ще съдържа неуточнения адрес. Това в подобно на хост изпращащ DHCP пакет, опитвайки да получи адрес.

* Адрес за обратна връзка - Loopback

Адреса за обратна връзка при IPv6 е 0:0:0:0:0:0:0:1 Хостовете използват този адрес, за да изпратят пакет до себе си. Той неможе да бъде задеден за никой хост. Този адрес е като IPv4 адреса 127.0.0.1 Администратора използва този адрес за помощ при разрешаване на проблеми със TCP/IP, администратора може да пингва адреса за обратна връзка, за да провери дали TCP/IP работи правилно на мрежовата карта.

Подобрения на IPv6

Освен огромния брой адреси, които IPv6 предлага има и редица други подобрения в IPv6, ето по важните от тях:

* Повишена сигурност
* Нов тип адресиране на пакети multicast и anycast адресиране.
* Нови IPv6 RFC документи за протоколите в пакета включително DHCP, DNS, ICMP, IP, TCP и UDP. С усъвършенстване на IPv6 хедърите, тези TCP/IP протоколи са подобрени. Някои излишни IPv4 полета в хедъра са елиминирани или са направени опционални полета. Количеството ресурси консумирано от всеки хост и рутер за обработката на пакет е намалено, което увеличава количеството на свободната честотна лента. Въпреки, че IPv6 адресите са 4 пъти по-големи от IPv4 адресите, IPv6 хедъра е само 2 пъти по-голям. Това означава, че пакетите са по "елегантни" без много добавъчна информация, която да ги забави.

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

IPv6 описва правила за три типа адресиране:

Unicast - ОТ хост до друг хост адресиране
Anycast - От хост до най-близките хостове. Този тип адрес се използва за изпращане на пакет до група хостове, но само най-близкия хост обработва пакета. Идеята е че хоста получил пакета може да предаде пакета на другите хостове в групата. Този тип адресиране не съществува в IPv4.
Multicast - От един хост до много хостове. Този тип адресиране е сходен на мултикаст адресирането при IPv4.

Един IPv6 пакет съдържа опции, които са част от хедъра преглеждан само от получателя, това увеличава общата скорост на мрежата.

[netman]

Първоначално написано от Administratot от [url="http://www.vmrejata.info/networks/43-...rams.html"

http://www.vmrejata.info/networks/43-...rams.html[/url]]Използване на помощни програми за TCP/IP


Макар че могат да се различават до известна степен по име и функционалност, повечето реализации на TCP/IP включват комплект от помощни програми, които могат да бъдат използвани за събиране на конфигурационна информация, тестване на връзката и отстраняване на проблеми в мрежата.
В следващите секции ще разгледаме няколко категории TCP/IP помощни програми: такива, които тестват връзката, такива, използвани за конфигурация, и такива, осигуряващи информация, която може да бъде полезна за отстраняване на проблеми в мрежите.
Помощни програми за тестване на връзката

Първата стъпка при отстраняването на проблеми, свързани с изгубване на връзка, е да определите дали тя наистина е изгубена. По-неопитните потребители на мрежи бързо решават, че нямат връзка към сървъра, ако не виждат името на сървъра в Network Neighborhood в Windows. Често това е просто проблем на преминаването в дървовидната структура от ресурси; сървърът не се регистрира сам в главния браузър (master browser) (компютърът, който следи мрежовите ресурси, за да ги визуализира в списъка за браузване [browse list]). Но ако се опитате да осъществите достъп до сървъра чрез въвеждане на неговия път, спазвайки конвенцията за универсално именуване (UNC), ще откриете, че връзката е налице.
TCP/IP инструментите, които ви позволяват да тествате връзката до друга машина и да определяте пътя, който изминава пакетът, за да достигне до местоназначението, са следните:

* ping и pathping
* Помощни програми за трасиране

ping и pathping

ping с съкращение на packet internetwork grooper. Тази команда е проста помощна програма, която изпраща съобщение, наречено Echo Request, използвайки протокола Internet Control Message Protocol (ICMP), до зададен компютър местоназначение. Компютърът местоназначение отговаря с изпращане на ICMP ехо.
Първата стъпка при проверка за предполагаем проблем на връзката е ping-ването на хоста. Ако искате да проверите вашата връзка към Интернет, трябва да ping-вате надежден хост в Интернет, например www.google.bg. Ако получите отговор, ще знаете, че физическата връзка между двата компютъра е незасегната и работи.

Ето пример на заявка и отговор на ping.

C:\>ping www.google.bg

Pinging www.l.google.com [209.85.135.103] with 32 bytes of data:

Reply from 209.85.135.103: bytes=32 time=82ms TTL=243
Reply from 209.85.135.103: bytes=32 time=83ms TTL=243
Reply from 209.85.135.103: bytes=32 time=81ms TTL=243
Reply from 209.85.135.103: bytes=32 time=84ms TTL=243

Ping statistics for 209.85.135.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 81ms, Maximum = 84ms, Average = 82ms

Командата ping може да бъде подадена с използване или на IP адрес, или на името на компютъра местоназначение. За тестване на връзката използвайте IP адреса. Ако успеете да ping-вате с IP адрес, но не получите отговор, когато ping-вате същия компютър по име, това означава, че има проблем с вашия сървър или конфигурацията за преобразуване на имена. Такъв проблем може да възникне, когато вашият компютър не използва DHCP и няма адрес на DNS сървър, въведен в свойствата на TCP/IP. От друга страна, когато вашият компютър е DHCP клиент, DHCP сървърът може да зададе адреса на DNS сървъра.

Терминът ping time се отнася до количеството време, което изминава между изпращането на заявка за ехо (Echo Request) и приемането на ехо отговор (Echo Replay). Късото време на ping-ване показва бърза връзка.

Командата ping може да бъде използвана също за тестване дали TCP/IP стекът на компютъра е инсталиран правилно и функционира. За да извършите теста, изпълнете ping до адреса за обратна връзка 127.0.0.1. Ако получите отговор, това означава, че стекът работи.
Версията на ping от командния ред е включена в TCP/IP стековете на всички операционни системи Windows, както и с различните издания на UNIX и Linux.
Програмата pathping е включена в Windows 2000, XP, 2003, Vista, но не и в Windows 9х или NT. Тя комбинира възможностите на ping с тези на tracert и осигурява допъл¬нителна информация, която иначе не се визуализира от тези програми. С pathping можете да откриете кои маршрутизатори предизвикват проблеми по мрежата и да измерите колко пакета се губят при конкретен маршрутизатор.
Помощни програми за трасиране

Помощните програми за трасиране се използват за откриване на маршрута на движение на даден пакет за достигане на неговото местоназначение. Помощни програми за трасиране в различни операционни системи:

Операционна система *************** Команда за трасиране
Windows 9x, NT, 2000, 2003, XP, Vista ** Въведете tracert от командния ред
Linux/Unix ************************* Въведете traceroute от командния ред

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

Пример за ползване на tracert:

C:\>tracert www.dir.bg

Tracing route to dir.bg [194.145.63.12]
over a maximum of 30 hops:

1 1 ms <1 ms <1 ms 192.168.1.1
2 38 ms 26 ms 29 ms 212-39-87-245.btc-net.bg [212.39.87.245]
3 37 ms 44 ms 40 ms 101-91-39-212.btc-net.bg [212.39.91.101]
4 37 ms 35 ms 39 ms 90-91-39-212.btc-net.bg [212.39.91.90]
5 44 ms 35 ms 40 ms 50-66.btc-net.bg [212.39.66.50]
6 37 ms 35 ms 38 ms dir.bg [194.145.63.12]

Trace complete.
Помощни програми за конфигуриране

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

Ето списък на командите, използвани от различни операционни системи:

Операционна система ******** Команда за визуализиране на конфигурацията
Windows 9x ***************** winipcfg
NT, 2000, 2003, XP, Vista ****** ipconfig
Linux/Unix ****************** ifconfig

Макар че форматът и точната информация могат да се различават до известна степен, всяка помощна програма визуализира основна информация за конфигурацията, като използвания IP адрес, мрежовата маска (подмрежовата маска) и шлюз, а също допълнителна информация, като DNS сървъри, МАС (физически) адрес и др.

Командата ipconfig се използва в Windows NT, Windows 2000, Windows 2003, Windows XP, Windows Vista за визуализиране на IP адреса, подмрежовата маска и подразбиращия се шлюз, за които е конфигуриран мрежовият адаптер. За да видите по-детайлна информация, използвате ключа /all. Примерa по долу показва резултатите от използването на ipconfig /all на Windows XP машина.

C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : tihomir
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes

Ethernet adapter Local Area Connection 3:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek RTL8139 Family PCI Fast Ethernet NIC #2
Physical Address. . . . . . . . . : 00-11-5B-FE-0B-09
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.1.181
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 212.39.90.42
212.39.90.43

Ако компютърът е конфигуриран като DHCP клиент, с ipconfig могат да бъдат използвани два допълнителни ключа. Първият е /renew. Той предизвиква под¬новяване на арендата за зададения IP адрес. Вторият е ключът /release, който предизвиква освобождаване на IP адреса, така че DHCP сървърът да може да го назначава отново.

ifconfig на Linux/UNIX
Командата ifconfig можете да използвате на компютър с UNIX/Linux, за да прегледате информацията за конфигурацията. Конфигурацията може да бъде променена с тази програма и с помощта на аргументи на командата. За разлика от командите на Windows, командата ifconfig в UNIX и
Linux е чувствителна към разликата между главни и малки букви. Ако въведете IFCONFIG с главни букви, командата няма да бъде разпозната.

winipefg на Windows 9x
Операционните системи Windows 95 и Windows 98 реализират помощната програма за конфигурация с графичен интерфейс. Въвеждането на winipefg от командния ред визуализира графичен екран, winipefg може да бъде използван с ключа /all за получаване на по-детайлна информация.
Други TCP/IP помощни програми

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

*
Netstat и Nbtstat - Те визуализират TCP/IP и NetBIOS статистическа информация.
*
ARP (или „агр" в Linux и UNIX) - Използва се за визуализация и управление на кеша на протокола Address Resolution Protocol (ARP).
*
ROUTE (или ..route" в Linux и UNIX) - Използва се за преглеждане и промяна на елементите, записани в маршрутните таблици.