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

Обмислете мрежата си:

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

Ако сте свързани директно през LAN с Internet, прочетете секцията "Ethernet and IP":

Ако се интересувате от евтини локални мрежи или dial-up връзки, прочетете следващата секция:

Тя описва PLIP, PPP, SLIP и ISDN, широкоразпространените технологии, използвани в персоналните работни станции.

Прочетете технологично специфичните секции, свързани с нуждите ви:

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

Свършете конфигурационната работа:

Опитайте се да конфигурирате мрежата си, и да си отбележите, ако имате някакви проблеми.

Погледнете за по-нататъчна помощ:

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

Забавлявайте се!

Мрежите са готини, насладете им се.

3.1. Conventions used in this document

No special convention is used here, but you must be warned about the way commands are shown. Following the classic Unix documentation, any command you should type to your shell is prefixed by a prompt. This howto shows "user%" as the prompt for commands that do not require superuser privileges, and "root#" as the prompt for commands that need to run as root. I chose to use "root#" instead of a plain "#" to prevent confusion with snapshots from shell scripts, where the hash mark is used to define comment lines.

When ``Kernel Compile Options'' are shown, they are represented in the format used by menuconfig. They should be understandable even if you, (like me), are not used to menuconfig. If you are in doubt about the options' nesting, running the program once can't do anything, but help.

Глава 4. Обща информация за мрежите под Linux.

4.1. Linux Networking Ресурси.

Има доста места, където може да намерите информация за мрежите под Linux.

Има и много консултанти. Списък с имената им може да се намери на http://www.linuxports.com/.

Алън Кокс, който поддържа кода на Linux kernel networking в момента, има уеб-страница, която съдържа бележки по текущата и по новите разработки в Linux Networking на адрес: http://www.uk.linux.org/.

Има нюзгрупа в Linux news hierarchy, посветена на мрежите и свързаните с тях неща: comp.os.linux.networking

Има и mailing list, за който можете да се абонирате и където може да задавате въпроси, свързани с мрежите под Linux. За да се абонирате, изпратете съобщение:

	To: majordomo@vger.rutgers.edu
	Subject: anything at all
	Message:
	subscribe linux-net

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

4.2. Откъде да вземете не-linux-специфична мрежова информация.

Ако търсите обща информация за tcp/ip мрежите, ви препоръчвам да погледнете следните документи:

tcp/ip introduction:

Този документ има текстова и postscript версии.

tcp/ip administration:

Този документ има текстова и postscript версии.

Ако търсите по-подробна информация относно tcp/ip мрежите, горещо ви препоръчвам:

"Internetworking with TCP/IP, Volume 1: principles, protocols and architecture, by Douglas E. Comer, ISBN 0-13-227836-7, Prentice Hall publications, Third Edition, 1995."

Ако искате да научите как да пишете мрежови приложения за Unix-съвместимо обкръжение, ви препоръчвам:

"Unix Network Programming, by W. Richard Stevens, ISBN 0-13-949876-1, Prentice Hall publications, 1990."

Може да опитате и comp.protocols.tcp-ip нюзгрупата.

Важен източник на техническа информация за Internet и групата от протоколи tcp/ip са RFC's. RFC е акроним на 'Request For Comment' и е стандартния начин за изпращане и документиране на стандартите за Internet протоколите.Има много хранилища за RFC.

Един възможен източник за RFC е Nexor RFC database.

Глава 5. Обща конфигурационна информация.

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

5.1. Какво ми е ноебходимо, за да започна ?

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

5.1.1 Текущия сорс-код на ядрото (незадължително).

Обърнете внимание:

Мнозинството от сегашните дистрибуции идват с прекомпилирани ядра, поддържащи мрежовите възможности, затова е възможно да не е необходимо да прекомпилирате ядрото. Ако използвате добре познат хардуер всичко ще бъде наред. Например: 3Com NIC, NE2000 NIC, или Intel NIC. Ето малко информация, ако все пак се налага да обновявате ядрото:

Възможно е ядрото, което използвате в момента да не поддържа мрежовите карти, които използвате и тогава вероятно ще имате нужда от сорс-кода на ядрото, за да го прекомпилирате с подходящите за вас опции.

За потребителите на основните дистрибуции като RedHat, Cladera, Debian, или SuSE това твърдение вече не е чиста истина. Докато използвате хардуер от преобладаващия на пазара тип, прекомпилация няма да е необходима, освен ако има някоя много специфична функция, която ви е необходима.

По всяко време можете да вземете последните сорс-кодове на ядрото от http://www.kernel.org/. Моля, използвайте някои от огледалните сървъри посочени там.

Обикновено сорс-кода на ядрото ще бъде разпакетиран в директорията /usr/src/linux.

Препоръчвам ви да използвате стандартния сорс-код (този с четна цифра във втория знак на версията - 2.2.x, 2.4.x) освен ако не е изрично посочено друго. Текущо разработвание ядра (тези с нечентен втори знак - 2.3.x, 2.5.x) могат да имат стурктурни или други промени, предизвикващи проблеми при работа с друг софтуер на вашата система. Не ги използвайте, освен ако не сте сигурни, че можете да разрешите такъв род проблеми.

5.1.2 IP адрес, обяснение.

Internet Protocol адресите се състоят от четири байта. Конвенцията, използвана за тяхното изписване се нарича 'точкуван десетичен запис'. По този начин всеки байт се превръща в десетична цифра (0-255), всяка водеща нула се изпуска, освен ако цифрата не е нула и всеки байт се разделя с '.'(точка). По конвенция всеки интерфейс на хост или рутер има IP адрес. При определени обстоятелства, е възможно един IP адрес да бъде използван за всички интерфейси на една машина, но обикновено всеки интерфейс си има собствен адрес.

Internet Protocol мрежите използват последователни поредици от IP адреси. Всеки адрес от една мрежа има общи цифри с другите адреси от нея. Частта, която е обща за адресите в тази мрежа се нарича 'мрежова част' на адреса. Останалите цифри се наричат 'хостова част'. Броят на битовете, споделяни от всички адреси в мрежата се нарича мрежова маска, чиято роля е да се определи коя част от адреса, към които се прилага тя, е т.нар. мрежова част и коя не е. Например:

	-----------------  ---------------
	Host Address       192.168.110.23
	Network Mask       255.255.255.0
	Network Portion    192.168.110.
	Host portion                  .23
	-----------------  ---------------
	Network Address    192.168.110.0
	Broadcast Address  192.168.110.255
	-----------------  ---------------
	

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

Broadcast адресът е специален адрес, когото всеки хост в мрежата прослушва, освен своя уникален адрес. Дейтаграмите, предназначени за всички хостова в мрежата, се изпращат на този адрес. Определен тип данни като рутираща информация и предупредителни съобщения се предават към broadcast адреса, така че всички хостове в мрежата да ги получат едновременно. Има два най-често използвани стандарта за това, кой да бъде broadcast адреса. Най-широкоприетия е за broadcast адрес да се използва възможно най-високия адрес в мрежата. В по-горния пример това е 192.168.110.255.По някаква причина други места използват конвенция, при която мрежовия адрес се използва като broadcast адрес. На практика няма голямо значение кой точно е broadcast адреса, стига всеки хост в мрежата да е конфигуриран със същия broadcast адрес.

В ранен етап от разработката на IP протокола по административни причини с някои произволни групи от адреси бяха образувани мрежи и тези мрежи бяха групирани в т.нар. класове. Тези класове осигуряват известен брой мрежи със стандартен размер, които могат да бъдат отпуснати. Отпусканите серии от адреси са:

	--------------------------------------------------------------------------------
	| Network| Netmask                             |  Network Addresses            |
	| Class   |                		       |                               | 
	--------------------------------------------------------------------------------
	|    A    | 255.0.0.0     			| 0.0.0.0    - 127.255.255.255 |
	|    B    | 255.255.0.0   			| 128.0.0.0  - 191.255.255.255 |
	|    C    | 255.255.255.0 			| 192.0.0.0  - 223.255.255.255 |
	|Multicast| 240.0.0.0     			| 224.0.0.0  - 239.255.255.255 |
	--------------------------------------------------------------------------------
	

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

Инсталиране на линукс машина в съществуваща IP мрежа.

Ако искате да инсталирате линукс машина като част от вече съществуваща IP мрежа е необходимо тези, които я администрират и да ги попитате за следната информация:

• IP адрес на хоста
• IP адрес на мрежата
• IP broadcast адрес
• IP мрежова маска
• адрес на рутера
• адрес на DNS сървъра

Изграждане на нова мрежа, която няма да е свързана с Internet:

Ако изграждате частна мрежа, за която смятате никога да не бъде свързвана към Internet може да използвате каквито адреси пожелаете. Обаче, поради пичини свързани със безопасността и устойчивостта на мрежата съществуват някои IP мрежови адреси, заделени специално за такива цели. Те са посочени в RFC1597 и са следните:

	-----------------------------------------------------------
	|         RESERVED PRIVATE NETWORK ALLOCATIONS            |
	-----------------------------------------------------------
	| Network | Netmask       | Network Addresses             |
	| Class   |               |                               |
	-----------------------------------------------------------
	|    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
	|    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
	|    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
	-----------------------------------------------------------

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

5.2. Къде да поставя конфигурационните команди ?

Има няколко различни подхода на зареждане на система с Linux. След като ядрото се зареди, то винаги изпълнява програма наречена 'init'. След това програмата 'init' чете конфигурационния файл наречен /etc/inittab и започва процеса на зареждане. Има няколко различни версии на init, но сега всички те са много близки до версията System V (Five) разработена от Miguel van Smoorenburg.

Независимо от факта, че програмата init винаги е една и съща, началното установяване и зареждането на системата се различава във всяка дистрибуция.

Файлът /etc/inittab обикновено съдържа записи подобни на този:

	si::sysinit:/etc/init.d/boot

Този ред определя името на шел-скрипт файла, който всъщност ще управлява последователността на зареждане на системата. Този файл е донякъде еквивалент на файла AUTOEXEC.BAT в MS-DOS.

Обикновено има други скриптове, извиквани от зареждащия скрипт и често мрежата се конфигурира от един от тях.

Следната таблица може да се използва като ръководства за вашата система:

---------------------------------------------------------------------------
Distrib. | Interface Config/Routing          | Server Initialization
---------------------------------------------------------------------------
Debian   | /etc/init.d/network               | /etc/rc2.d/*
---------------------------------------------------------------------------
Slackware| /etc/rc.d/rc.inet1                | /etc/rc.d/rc.inet2 
---------------------------------------------------------------------------
RedHat   | /etc/rc.d/init.d/network          | /etc/rc.d/rc3.d/*
---------------------------------------------------------------------------

Забележете, че Debian и Red Hat използват цяла директория, където съхраняват инициализационните скриптове ( а самата информация обикновено не се съдържа в тези файлове, Red Hat например съхранява кофигурационната си информация във файловете в директорията /etc/sysconfig, откъдето тя се взима от инициализационните скриптове). Ако искате да задълбаете в детайлите на процеса на зарждане, предлагам ви да проверите /etc/inittab, както и придружаващата информация на init. Linux Journal също ще публикува статия за системната инициализация, и този документ ще има връзка към нея, когато тя стане достъпна в уеб-пространството.

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

	-----------------------------------------
	Distrib   | Network configuration program
	-----------------------------------------
	RedHat    | /usr/bin/netcfg ; /usr/bin/netconf
	Slackware | /sbin/netconfig
	-----------------------------------------

5.3. Създаване на мрежови интерфейси.

В много Unix операционни системи мрежовите устройства се появяват в директорията /dev. Под Linux това не е така. При Linux мрежовите устройства се създават динамично от софтуера и не изискват файл за устройство, за да съществуват.

В мнозинството от случайте мрежовите устройства се създават автоматично от драйвера за устройството по време на инициализацията, когато бъде открит хардуера ви. Eternet драйвер на устройство, например, създава eth[0..n] интерфейси последователно, когато открие вашия ethernet хардуер. Първата намерена ethernet карта става eth0, втората eth1 и т.н.

В някои случаи обаче, особено slip и ppp, мрежовите устройства се създават в движение, от някоя потребителска програма. Също се прилагат последователни номера, но устройствата не се създават автоматично по време на зареждане. Причината е, че за разлика от ethernet устройствата, броят на активните slip или ppp устройства може да варира през времето, докато машината работи. Тези случаи ще бъдат разгледани по-подробно в секциите по-късно.

5.4 Конфигуриране на мрежов интерфейс. Ядра 2.0 и 2.2

След като имате всички необходими програми, както и мрежовия адрес и мрежовата информация можете да конфигурирате мрежовите си интерфейси.Когато говорим за конфигуриране на мрежов интерфейс става дума за процеса на присвояване на подходящ адрес на мрежовото устройство, както и установяване на подходящите стойности на други параметри на мрежовото устройство. Най-често използвана за тази цел команда е ifconfig (interface configure).

Обикновено ще използвате команда подобна на следната:

	root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

В този случай аз конфигурирам ethernet интерфейс 'eth0' с IP адрес '192.168.0.1' и мрежова маска '255.255.255.0'. Опцията 'up' в края на командата, указва на интерфейса, че трябва да се активира, но по подразбиране може да се пропусне. За да спрете (деактивирате) интерфейса, напишете "ifconfig eth0 down".

Когато конфигурира интерфейса, ядрото приема някои опции по подразбиране. Например, можете да укажете мрежов адрес и broadcast адрес за даден интерфейс, но ако не укажете, както в по-горния пример, ядрото ще предположи какви трябва да са те въз основа на мрежовата маска, а ако не установите маска, въз основа на мрежовия клас на използвания IP адрес. В моя пример ядрото ще приеме, че е мрежата е клас C и ще настрои мрежови адрес '192.168.0.0' и broadcast адрес '192.168.0.255' за този интерфейс.

Командата ifconfig има много други опции. Най-важните от тях са:

Тази опция активира интерфейса (по подразбиране).

Тази опция деактивира интерфейса.

Разрешава или забранява използването на adress resolution protocol за този интерфейс.

Опцията разрешава или забранява приемането на всички хардуерни мултикаст пакети. Хардуерния мултикаст позволява група от хостове да приемат пакети адресирани до специални направлвния. Това е важно, ако използвате приложения за видеоконференции, но обикновено не се използва.

Този параметър позволява да се установи MTU (Maximum Transfer Unit) на устройството.

Параметъра позволява да установите маскате на мрежата, на която устройството принадлежи.

Този параметър работи само за определен тип хардуер и ви позволява да посочите IRQ за хардуера на това устройство.

Позволява да разрешите приемането на дейтаграми, насочени към broadcast адреса, или да забраните приемането им.

[-]pointopoint [addr]

Задава адрес на машината в другия край на връзка точка-до-точка, такава като slip или ppp.

hw <type><addr>

Позволява да зададете хардуерния адрес на определен тип мрежови устойства. Не е много полезно за ethernet, но е полезно за мрежи от типа на AX.25.

Във версията на ядрото 2.2 има допълнителни опции, които не са посочени по-горе. Най-интересни сред тях са опциите за tunneling и IPV6. Параметрите на ifconfig за ядра с версия 2.2 са показани по-долу.

Името на интерфейса. Обикновено това е името на драйвера, следвано от номера на устройството, например eth0 за първия Ethernet интерфейс.

Този флаг активира интерфейса. Подразбира се, когато се зададе адрес на интерфейса.

Флага спира драйвера за този интерфейс.

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

Разрешава / забранява режима all-multicast. Когато е разрешен, всички multicast пакети в мрежата ще бъдат получавани от интерфейса.

Установява метриката на интерфейса.

Установява Maximum Transfer Unit (MTU) за интерфейса.

Установява отсрещния IP адрес при връзка точка-до-точка (като PPP). Опцията е излязла от употреба; вместо нея използвайте pointopoint.

Установява IP мрежова маска за интерфейса. Приема се по подразбиране за класове мрежи A, B или C (извлича се от IP адреса на интерфейса), но може да бъде установена с всяка стойност.

Добавя IPv6 адрес на интерфейс.

Премахва IPv6 адрес от интерфейс.

Създава ново SIT (IPv6-in-IPv4) устройство, тунел към зададено направление.

Установява прекъсването, използвано от устройството. Не всички устройства могат динамично да променят IRQ настройките си.

Установява начален входно-изходен (I/O) адрес за устройството.

Установява начален адрес на споделената памет, използвана от това устройство. Само няколко вида устройства се нуждаят от тази опция.

Установява физическия порт или вида на носителя, който се използва от устройството. Не всички устройства могат да променят тази настройка, а стойностите при тези които могат да варират. Типични стойности са 10base2(тънък Ethernet), 10baseT (10 Mbps Ethernet, усукана двойка), AUI (външен приемо-предавател) и т.н. Опцията auto на media type може да се използва, за да укаже на драйвера автоматично да открие типа на носителя. Не се поддържа от всички устройства.

Ако е зададен адрес като аргумент, установява broadcast адреса за това устройство. В противен случай, вдига (или изчиства) флага IFF_BROADCAST за устойството.

Този ключ включва режима точка-до-точка на интерфейса, което означава, че отваря директна връзка между две машини, която никой друг не може да слуша. Ако е зададен адрес в аргумента, установява адреса на протокола от другата страна на връзката, също като остарялата опция dstaddr. Иначе, установява или изчиства флага IFF_POITOPOINT на интерфейса.

Установява хардуерен адрес за това устройство, ако то поддържа тази опция. Опцията трябва да бъде последвана от името на хардуерния клас, както и от ASCII еквивалент на хардуерния адрес. Поддържаните хардуерни класове включват ether (Ethernet), ax25 (AMPR AX.25), ARCnet и netrom (AMPR NET/ROM).

Вдига multicast флага за това устройство. Обикновено не е необходимо, защото драйвера го установява коректно сам.

IP адреса, присвояван на устройството.

Commercial Organizations - търговски огранизации.

Educational Organizations - учебни организации.

Government Organizations - правителствени организации (на САЩ).

Military Organizations - военни организации (на САЩ).

Други организации.

Организации, чиято дейност е свързана с Internet.

Това са двубуквени кодове, представящи определена държава.

По исторически причини повечето от домейните от най-горно ниво, без принадлежащите на отделните държави, бяха използвани от организации в САЩ, макар те да имат собствен код - '.us'. Това вече не е така, защото домейни като .com и .org, често се използват и от фирми извън САЩ.

Всеки домейн от най-високо ниво има поддомейни. Домейните, завършващи с код на държава, често се разделят на поддомейни, базирани на com, gov, mil и org. Така например com.au и gov.au са търговски и държавни организации в Австралия; това не е общо правило, действителните правила се определят от управляващите власти на съответния домейн.

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

Най-лявата част от името винаги е уникалното име на хоста и се нарича 'hostname', частта на името, намираща се в дясно от името на хоста се нарича 'domainname', а пълното име се нарича 'Fully Qualified Domain Name' (FQDN).

Ако използвам името на хоста на Тери като пример, пълното име на домейна ще бъде 'perf.no.itg.telstra.com.au'. Това означава, че името на хоста е 'perf', а името на домейна е 'no.itg.telstra.com.au'. В този случай, домейна от най-високо ниво е двубуквения код на Австралия, поддомейна '.com' означава, че става дума за бизнес-организация, 'telstra' е името на фирмата, а останалата част се базира на вътрешната й структура - тази машина принадлежи на Information Technology Group, отдел Network Operations.

Обикновено имената са по-кратки, ISP-то ми например се нарича "systemy.it";, а моята организация с нестопанска цел се нарича "linux.it", без поддомейни като com или org, а хоста ми се нарича "morgana.linux.it"; и rubini@linux.it е валиден адрес на електронна поща. Забележете, че собственика на домейна има правата да регистрира имена на хостове и поддомейни; LUG групата, към която аз принадлежа използва домейна pluto.linux.it, благодарение на факта, че собсвеницита на linux.it се съгласиха да отворят поддомейн за LUG.

5.5.2. Каква информация ще ви е необходима.

Необходимо е да знаете на кой домейн принадлежи хоста ви. Софтуера за откриване на имена (name resolver) осигурява услугите по транслирането на името като отправя запитвания до 'Domain Name Server', така че вие трабва да знаете IP адреса на местен именен сървър (DNS), който да използвате.

Има три файла, които трябва да редактирате; ще ги обсъдя накратко.

5.5.3 /etc/resolv.conf

/etc/resolv.conf е главния конфигурационен файл, използван от резолвера на имена. Той има прост формат - текстов файл с една ключова дума на ред. Има три типично използвани ключови думи и те са:

Определя местното име на домейн.

Определя реда на търсене на алтернативни имена на домейни, за да намери името на търсения хост.

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

Един примерен /etc/resolv.conf би могъл да изглежда така:

	domain maths.wu.edu.au
	search maths.wu.edu.au wu.edu.au
	nameserver 192.168.10.1
	nameserver 192.168.12.1

В този пример се указва, че името на домейн, което ще се добавя към непълните имена (т.е. ако е зададено само име на хост без домейн) е maths.wu.edu.au и ако хоста не бъде намерен в този домейн, втория опит да бъде директно в домейна wu.edu.au. Дадени са и два именни сървъра, всеки от които може да бъде извикван от резолвера на имена, за да получи името.

5.5.4 /etc/host.conf

Във файла /etc/host.conf се кофигурират някои опции, които управляват поведението на резолвера на имена. Неговия формат е описан подробно в справочната страница на 'resolv+'. При почти всички обстоятелства, следния пример ще работи и при вас:

                          
	order hosts,bind                                          
	multi on  

Тази кофигурация казва на резолвера да провери файла /etc/hosts, преди да запита именния сървър и да върне всички валидни адреси за хоста, намерени във файла, а не само първия.

5.5.5. /etc/hosts

Файлът /etc/hosts е мястото, където слагате името и IP адреса на локалните хостове. Ако поставите хост в този файл не е необходимо да питате DNSа, за да ви каже какъв е IP адреса му. Неудобството на този подход е, че трябва обновявате файла всеки път, когато IP адреса на хоста бъде сменен. В добре управлявана система, имената на хостове, които се намират в този файл обикновено са - един запис за интерфейса loopback и един за името на хоста.

	# /etc/hosts
	127.0.0.1      localhost loopback
	192.168.0.1    this.host.name

На един ред може да поставите повече от едно име за хост, както е показано в първия запис от примера, който представлява стандартен запис на loopback интерфейса.

5.5.6 Използване на именен сървър

Ако искате да имате локален именен сървър, можете лесно да го направите. Моля обърнете се към DNS-HOWTO, както и към документите, включени във вашата версия на BIND (Berkeley Internet Name Domain).

5.6. Конфигуриране на loopback интерфейса.

'loopback' интерфейса е специален тип интерфейс, който позволява да се свързвате със себе си. Причините, поради които бихте искали да правите това са много, например, може да желаете да тествате някакъв мрежов софтуер без да си пречите с някой друг в мрежата. По конвенция IP адрес '127.0.0.1' е запазен изрично за loopback. Така, без занчение какъв вид машина ползвате, ако отворите telnet връзка към 127.0.0.1 винаги ще се свържете със собствената си машина (local host).

Конфигурирането на loopback интерфейс е просто и трябва да се прави винаги (затова тази задача обикновено се извършва от стандартните инициализационни скриптове).

	root# ifconfig lo 127.0.0.1
	root# route add -host 127.0.0.1 lo

За командата route, ще поговорим повече в следващата секция.

5.7. Рутиране.

Рутирането е обширна тема. Лесно е да се напишат голям обем текст за него. Някои от вас ще имат относителни прости изисквания за рутиране, а за други няма да е така. Аз ще покрия само основните неща относно рутирането. Ако се интересувате от по-детайлна информация, препоръчвам ви да погледнете отпратките в началото на документа.

Да започнем с дефиниция. Какво е IP рутиране ? Ето дефиницията, която използвам:

"IP рутирането е процес, при който хост с много мрежови връзки решава къде да достави дейтаграмите, които е получил."

Може би ще е полезно да илюстрирам това с един пример. Представете си един типичен офис-рутер, който има PPP връзка към Internet, известен брой ethernet сегменти, захранващи работните станции, както и друга PPP връзка към друг офис. Когато рутера получи дейтаграма по някоя от мрежовите си връзки, рутирането е механизмът, който той използва, за да определи към кой интерфейс да изпрати дейтаграмата. Обикновените хостове също имат нужда от рутиране, всички Internet хостове имат две мрежови устройства, едно за loopback, описано по-горе и друго, което бива използвано, за да комуникира с останалата част от мрежата, и което може да е ethernet, PPP или SLIP сериен интерфейс.

Окей, та как казваш работи рутирането ? Всеки хост има специален списък с правила за рутиране, наречен рутираща таблица. Тази таблица съдържа редове, които имат поне три полета - първото е адреса на назначението; второто е името на интерфейса, към който да бъде рутирана дейтаграмата; и третото е (незадължително) IP адреса на другат машина, която ще поеме дейтаграмата на следващия етап от пътуването й по мрежата. Под Linux можете да видите рутиращата таблица чрез следната команда:

	user% cat /proc/net/route

или чрез някоя от следните команди:

	user% /sbin/route -n
	user% netstat -r

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

За да се борави с тази таблица се използва специална команда. Тя взима аргументите от командния ред и ги конвертира в системни извиквания на ядрото, които изискват от него да прибавя, изтрива или променя записи от рутиращата таблица. Тази команда се нарича 'route'.

Прост пример. Представете си, че имате ethernet мрежа. Казано ви е, че тя е от клас C, с адрес 192.168.1.0. Даден ви е IP адрес - 192.168.1.10 за ваша употреба и ви е казано, че 192.168.1.1 е адресът на рутера, свързан с Internet.

Първата стъпка е да конфигурирате интерфейса си, както описахме по-рано. За целта, бихте използвали команда като:

	root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

Сега е необходимо да добавите запис в рутиращата таблица, който да указва на ядрото, че дейтаграмите за всички хостове с адрес, който съвпада с 192.168.1.* следва да бъдат изпращани през ethernet устройството. Бихте използвали подобна команда:

	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

Обърнете внимание на използвания аргумент '-net', указващ на рутиращата програма, че този запис определя мрежов път. Другата възможност е на това място да е аргумента '-host', указващ път до определен IP адрес.

Горния път ви позволява да установите връзка с всички хостове от вашия ethernet сегмент. А как да стане това с онези IP хостове, които не са част от вашия сегмент ?

Би било доста тежка работа да добавяте пътища до всяко възможно мрежово направление, затова се използва един особен трик, за да се опрости тази задача. Този трик се нарича "път по подразбиране"(default route). Пътят по подразбиране съответства на всеки възможен път, само че слабо, така че ако съществува друг запис, съответстващ на искания адрес, ще бъде използван той, вместо default route. Идеята на пътя по пдразбиране е да ви даде възможност да кажете "а всичко останало да отива натам". В примера, който уйдурдисах бихте използвали запис като:

	root# route add default gw 192.168.1.1 eth0

Аргументът 'gw' казва на командата route, че следващия аргумент е IP адрес или име на портал (gateway) или рутер, към който следва да се изпращат дейтаграмите, отговарящи на записа, за по-нататъчно рутиране.

Ето, пълната конфигурация ще изглежда така:

	root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# route add default gw 192.168.1.1 eth0

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

Да погледнем една малко по-сложна рутираща конфигурация. Нека си представим, че настройваме рутера, за който говорихме по-рано, този с PPP връзка към Internet и LAN сегменти към компютрите в офиса. Нека той има три ethernet сегмента и една PPP връзка. Рутиращата ни конфигурация би имала следния външен вид:

	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
	root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
	root# route add default ppp0

Всеки от офис-копютрите ще използва простата форма, представена по-горе, единствено мрежовите пътища на рутера трябва да се укажат поотделно, защото заради пътят по подразбиране, установен в офис-компютрите (и който работи чудесно за тях) на него ще му се наложи да разделя приеманите пакети и да ги предава в подходящата посока. Може би се чудите защо представения default route не е уточнен с 'gw'. Причината за това е проста, протоколите за серийна връзка като PPP и SLIP имат само два хоста в мрежата си; (по един във всеки край). Да се указва хоста от другия край на връзката като портал е безсмислено и излишно, тъй като няма друг избор, затова не е необходимо да се указва портал за този тип мрежови връзки. Друг тип мрежи като ethernet, arcnet или token ring изискават порталът да бъде указан, защото те поддържат голям брой хостове.

5.7.1. А какво прави програмата routed ?

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

Големия проблем на "ръчното" или "статично рутиране" което описахме, е че ако някои компютър блокира или някоя връзка пропадне във мрежата ви, единствения начин да пренасочите дейтаграмите по друг път, ако такъв съществува е ръчно да изпълните подходящите команди. Това, естествено е неудобно, бавно, непрактично и рисковано. Различни техники бяха разработени, за да се настройват автоматично рутиращите таблици в случай на пропадане на мрежови връзки, когато съшествува алтернативен път, всички те отговарят на термина 'динамични рутиращи протоколи'.

Може да сте чували за някои от най-известните динамични рутиращи протоколи. Вероятно най-известните от тях са RIP (Routing Information Protocol) и OSPF (Open Shortest Path First Protocol). Routing Information Protocol е най-често използван в корпоративни мрежи с малък до среден размер. OSPF е по-модерен и е способен да се справи с големи мрежви конфигурации, той е по-подходящ за обкръжения, където броят на възможните пътища през мрежата е голям. Въплъщенията на тези протоколи са: 'routed' - RIP и 'gated' - RIP, OSPF и други. Програмата 'routed' обикновено е включена във вашата Linux дистрибуция или в пакета 'NetKit' разгледан по-горе.

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

    192.168.1.0 /                         192.168.2.0 /
       255.255.255.0                         255.255.255.0
     -                                     -
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |ppp0   //    ppp0|     |   |
eth0 |---|  A  |------//---------|  B  |---| eth0
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |      \ ppp1             ppp1 /      |
     -       \                     /       -
              \                   /
               \                 /
                \               /
                 \             /
                  \           /
                   \         /
                    \       /
                     \     /
                  ppp0\   /ppp1
                     /-----\
                     |     |
                     |  C  |
                     |     |
                     \-----/
                        |eth0
                        |
                   |---------|
                   192.168.3.0 /
                      255.255.255.0

Имаме три рутера - A, B и C. Всеки от тях поддържа един ethernet сегмент от IP мрежа с клас C (мрежова маска 255.255.255.0). Всеки рутер също така има PPP-връзка до всеки от другите рутери. Мрежата образува триъгълник.

Ясно е, че рутиращата таблица на рутер A ще изглежда така:

	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
	root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
	

Това ще работи чудесно, докато връзката между рутерите A и B не се провали. Ако тя се провали, с рутиращия запис показан по-горе, хостовете от ethernet сегмента на A няма да могат да достигнат хостове от ethernet сегмента на B, защото дейтаграмите им ще бъдат изпращани през връзката ppp0 на рутер A, която е прекъсната. Те ще продължат да имат връзка с хостовете от ethernet сегмента на C, а хостовете от ethernet сегмента на C ще могат да комуникират с хостове от ethernet сегмента на B, защото връзката между B и C е непокътната.

Обаче, ако A има връзка с C, и C има връзка с B, тогава защо A не рутира дейтаграмите за B през C, и да остави C да ги предаде на B ? Динамичните рутиращи протоколи като RIP, са създадени да решават проблеми точно от този род. Ако на всеки от рутерите - A, B или C, е стартиран рутиращ демон, техните рутиращи таблици автоматично ще бъдат обновявани, за да отразят новото състояние на мрежата, когато някоя от връзките пропадне. Да се конфигурира такава мрежа е просто, ще има нужда от две неща за всеки рутер. В този случай за рутер A:

	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	root# /usr/sbin/routed

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

Това бе доста сбито обяснение на динамичното рутиране, и къде се използва то. Ако желаете повече информация, вижте предложените справки изброени в началото на документа.

Важните неща относно динамичното рутиране са:

1. За да заработи, трябва само да стартирате демона за динамични рутиращи протоколи (routed) на Linux-машина, имаща възможност да избира от няколко възможни пътя до определена посока. Пример за това е ако планирате да използвате IP Masquerading.
2. Динамично рутиращият процес автоматично ще променя рутиращата ви таблица, за да отговаря тя на промените в мрежата.
3. RIP е предназначен за мрежи с малък до среден размер.

5.8. Конфигуриране на вашите мрежови сървъри и услуги.

Мрежовите сървъри и услуги са програмите, позволяващи на отдалечен потребител да стане потребител на вашата Linux машина. Програмите-сървъри слушат определени мрежови портове. Мрежовите портове са начина да се адресира точно определена услуга на точно определен хост, и са начина по който сървъра различава входяща telnet-връзка от входяща ftp-връзка. Отдалеченния потребител установява мрежова връзка с вашата машина, а сървърната програма, или още мрежов демон, слушащ точно този порт приема връзката и я изпълнява. Има два режима, в които могат да бъдат мрежовите демони. И двата често се прилагат на практика. Те са:

Мрежовата програма-демон слуша определения мрежов порт и когато се появи входяща връзка, самия демон ушравлява мрежовата връзка, за да достави услугата.

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

Има два важни файла, които трябва да конфигурираме. Това са /etc/services, който присвоява имена на номерата на порт, и /etc/inetd.conf - конфигурационния файл на мрежовия демон inetd.

5.8.1. /etc/services

Файлът /etc/services е проста база от данни, която асоциира удбно за човек име към удобния за машината номер на порт. Формата му е доста прост. Това е текстов файл, в който един ред отговаря на един запис в базата данни. Всеки запис е съставен от три полета, разделени от произволно празно пространство (табулации или интервали). Полетата са:

name port/protocol aliases # comment

име порт/протокол псевдоними # коментар

Име на описваната услуга, състоящо се от една дума.

Това поле е разделено на две под-полета.

Цифра, определяща номера на порт, на които ще е достъпна посочената услуга. Повечето услуги имат присвоени номера на услуги. Те са описани в RFC-1340.

Това поле може да бъде установено на tcp или udp.

Важно е да се отбележи, че записът 18/tcp е коренно различен от 18/udp, и няма техническа причина някоя услуга да иска да ползва и двата протокола. Обикновено здравият разум преобладава и само ако определена услуга е достъпна и по tcp и по udp, тогава ще видите записи за двата протокола.

aliases

Други имена, под които може да е известна тази услуга.

Всеки текст, който се появява след знака '#' се игнорира и се третира като коментар.

5.8.1.1. Примерен файл /etc/services.

# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# Network services, Internet style
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
# are included, only the more common ones.

tcpmux		1/tcp				# TCP port service multiplexer
echo		7/tcp
echo		7/udp
discard		9/tcp		sink null
discard		9/udp		sink null
systat		11/tcp		users
daytime		13/tcp
daytime		13/udp
netstat		15/tcp
qotd		17/tcp		quote
msp		18/tcp				# message send protocol
msp		18/udp				# message send protocol
chargen		19/tcp		ttytst source
chargen		19/udp		ttytst source
ftp-data	20/tcp
ftp		21/tcp
ssh		22/tcp				# SSH Remote Login Protocol
ssh		22/udp				# SSH Remote Login Protocol
telnet		23/tcp
# 24 - private
smtp		25/tcp		mail
# 26 - unassigned
time		37/tcp		timserver
time		37/udp		timserver
rlp		39/udp		resource	# resource location
nameserver	42/tcp		name		# IEN 116
whois		43/tcp		nicname
re-mail-ck	50/tcp				# Remote Mail Checking Protocol
re-mail-ck	50/udp				# Remote Mail Checking Protocol
domain		53/tcp		nameserver	# name-domain server
domain		53/udp		nameserver
mtp		57/tcp				# deprecated
bootps		67/tcp				# BOOTP server
bootps		67/udp
bootpc		68/tcp				# BOOTP client
bootpc		68/udp
tftp		69/udp
gopher		70/tcp				# Internet Gopher
gopher		70/udp
rje		77/tcp		netrjs
finger		79/tcp
www		80/tcp		http		# WorldWideWeb HTTP
www		80/udp				# HyperText Transfer Protocol
link		87/tcp		ttylink
kerberos	88/tcp		kerberos5 krb5	# Kerberos v5
kerberos	88/udp		kerberos5 krb5	# Kerberos v5
supdup		95/tcp
# 100 - reserved
hostnames	101/tcp		hostname	# usually from sri-nic
iso-tsap	102/tcp		tsap		# part of ISODE.
csnet-ns	105/tcp		cso-ns		# also used by CSO name server
csnet-ns	105/udp		cso-ns
rtelnet		107/tcp				# Remote Telnet
rtelnet		107/udp
pop-2		109/tcp		postoffice	# POP version 2
pop-2		109/udp
pop-3		110/tcp				# POP version 3
pop-3		110/udp
sunrpc		111/tcp		portmapper	# RPC 4.0 portmapper TCP
sunrpc		111/udp		portmapper	# RPC 4.0 portmapper UDP
auth		113/tcp		authentication tap ident
sftp		115/tcp
uucp-path	117/tcp
nntp		119/tcp		readnews untp	# USENET News Transfer Protocol
ntp		123/tcp
ntp		123/udp				# Network Time Protocol
netbios-ns	137/tcp				# NETBIOS Name Service
netbios-ns	137/udp
netbios-dgm	138/tcp				# NETBIOS Datagram Service
netbios-dgm	138/udp
netbios-ssn	139/tcp				# NETBIOS session service
netbios-ssn	139/udp
imap2		143/tcp				# Interim Mail Access Proto v2
imap2		143/udp
snmp		161/udp				# Simple Net Mgmt Proto
snmp-trap	162/udp		snmptrap	# Traps for SNMP
cmip-man	163/tcp				# ISO mgmt over IP (CMOT)
cmip-man	163/udp
cmip-agent	164/tcp
cmip-agent	164/udp
xdmcp		177/tcp				# X Display Mgr. Control Proto
xdmcp		177/udp
nextstep	178/tcp		NeXTStep NextStep	# NeXTStep window
nextstep	178/udp		NeXTStep NextStep	# server
bgp		179/tcp				# Border Gateway Proto.
bgp		179/udp
prospero	191/tcp				# Cliff Neuman's Prospero
prospero	191/udp
irc		194/tcp				# Internet Relay Chat
irc		194/udp
smux		199/tcp				# SNMP Unix Multiplexer
smux		199/udp
at-rtmp		201/tcp				# AppleTalk routing
at-rtmp		201/udp
at-nbp		202/tcp				# AppleTalk name binding
at-nbp		202/udp
at-echo		204/tcp				# AppleTalk echo
at-echo		204/udp
at-zis		206/tcp				# AppleTalk zone information
at-zis		206/udp
z3950		210/tcp		wais		# NISO Z39.50 database
z3950		210/udp		wais
ipx		213/tcp				# IPX
ipx		213/udp
imap3		220/tcp				# Interactive Mail Access
imap3		220/udp				# Protocol v3
ulistserv	372/tcp				# UNIX Listserv
ulistserv	372/udp
#
# UNIX specific services
#
exec		512/tcp
biff		512/udp		comsat
login		513/tcp
who		513/udp		whod
shell		514/tcp		cmd		# no passwords used
syslog		514/udp
printer		515/tcp		spooler		# line printer spooler
talk		517/udp
ntalk		518/udp
route		520/udp		router routed	# RIP
timed		525/udp		timeserver
tempo		526/tcp		newdate
courier		530/tcp		rpc
conference	531/tcp		chat
netnews		532/tcp		readnews
netwall		533/udp				# -for emergency broadcasts
uucp		540/tcp		uucpd		# uucp daemon
remotefs	556/tcp		rfs_server rfs	# Brunhoff remote filesystem
klogin		543/tcp				# Kerberized `rlogin' (v5)
kshell		544/tcp		krcmd		# Kerberized `rsh' (v5)
kerberos-adm	749/tcp				# Kerberos `kadmin' (v5)
#
webster		765/tcp				# Network dictionary
webster		765/udp
#
# From ``Assigned Numbers'':
#
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations.  For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined.  This list specifies the port used by the server process as its
#> contact port.  While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convenience to the
#> community.
#
ingreslock	1524/tcp
ingreslock	1524/udp
prospero-np	1525/tcp		# Prospero non-privileged
prospero-np	1525/udp
rfe		5002/tcp		# Radio Free Ethernet
rfe		5002/udp		# Actually uses UDP only
bbs		7000/tcp		# BBS service
#
#
# Kerberos (Project Athena/MIT) services
# Note that these are for Kerberos v4 and are unofficial.  Sites running
# v4 should uncomment these and comment out the v5 entries above.
#
kerberos4	750/udp		kdc	# Kerberos (server) udp
kerberos4	750/tcp		kdc	# Kerberos (server) tcp
kerberos_master	751/udp			# Kerberos authentication
kerberos_master	751/tcp			# Kerberos authentication
passwd_server	752/udp			# Kerberos passwd server
krb_prop	754/tcp			# Kerberos slave propagation
krbupdate	760/tcp		kreg	# Kerberos registration
kpasswd		761/tcp		kpwd	# Kerberos "passwd"
kpop		1109/tcp		# Pop with Kerberos
knetd		2053/tcp		# Kerberos de-multiplexor
zephyr-srv	2102/udp		# Zephyr server
zephyr-clt	2103/udp		# Zephyr serv-hm connection
zephyr-hm	2104/udp		# Zephyr hostmanager
eklogin		2105/tcp		# Kerberos encrypted rlogin
#
# Unofficial but necessary (for NetBSD) services
#
supfilesrv	871/tcp			# SUP server
supfiledbg	1127/tcp		# SUP debugging
#
# Datagram Delivery Protocol services
#
rtmp		1/ddp			# Routing Table Maintenance Protocol
nbp		2/ddp			# Name Binding Protocol
echo		4/ddp			# AppleTalk Echo Protocol
zip		6/ddp			# Zone Information Protocol
#
# Debian GNU/Linux services
rmtcfg		1236/tcp		# Gracilis Packeten remote config server
xtel		1313/tcp		# french minitel
cfinger		2003/tcp		# GNU Finger
postgres	4321/tcp		# POSTGRES
mandelspawn	9359/udp	mandelbrot	# network mandelbrot

# Local services

В реалния свят, този файл нараства с добавянето на нови услуги. Ако се страхувате, че вашето копие е непълно, предлагам ви да си копирате нов /etc/services от някоя съвременна дистрибуция.

5.8.2 /etc/inetd.conf

Файлът /etc/inetd.conf е конфигурационния файл за демона inetd. Неговата функция е да казва на inetd какво да прави, когато получи заявка за връзка с определена услуга. За всяка услуга, която трябва да кажете на inetd кой мрежов демон да стартира и как (с какви опции).

Неговия формат също е доста прост. Той е текстов файл, всеки ред от който описва услуга, която искате да бъде доставяна. Всеки текст на реда след знака '#' се пренебрегва и се счита за коментар. Всеки ред съдържа седем полета, разделени със знаци за празно пространство (табулации или интервали). Общата подредба е следната:

  service  socket_type  proto  flags  user  server_path  server_args

service

е услугата, свързана с тази конфигурация както е описана във файла /etc/services.

socket_type

Това поле описва типа на сокета, към който ще бъде свързан този запис, позволените стойности са: stream, dgram, raw, rdm или seqpacket. Това е малко техническо отклонение, но на практика почти всички услуги, базирани на tcp, използват stream, а почти всички, базирани на udp, използват dgram. Само някои много специален тип сървърни демони използват някои от другите стойности.

proto

Валидния протокол за този запис. Той би трябвало да съвпада със съответния запис във файла /etc/services и типично е или tcp или udp. Сървърите, базирани на Sun RPC (Remote Procedure Call - отдалечено извикване на процедури) биха използвали rpc/tcp или rpc/udp.

flags

Реално има само две възможни стойности за това поле. Полето казва на inetd дали мрежовия демон освобождава сокета след като бъде стартирана и следоватлно inetd трябва да го стартира отново при следващата заявка за връзка, или inetd трябва да чака и да предполага, че всеки сървърен демон, който вече е стартиран ще се оправя с новите заявки за връзка. Отново това е доста делокатно докато заработи, но на практика за tcp сървърите този запис трябва да е nowait, а за повечето udp сървъри трябва да е wait. Има някои важни изключения на това правило, затова оставете на примерите да ви водят, ако не сте сигурни.

user

Това поле описва коя потребителска регистрация от /etc/passwd ще бъде установена като собственик на мрежовия демон, когато той бъде стартиран. Това е полезно, когато искате да се предпазите от рискове за сигурността. Може да укажете в записа потребителя да бъде nobody, така че при евентуален пробив в сигрността, възможните вреди да са минимални. Обикновено това поле е установено на root обаче, защото много от сървърите изискват привилегии на root, за да функционират правилно.

server_path

Това поле е пътят до действителната сървърна програма, за да се изпълни тя за този запис.

server_args

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

5.8.2.1. Примерен /etc/inetd.conf файл.

Подобно на файла /etc/services, модерните дистрибуции включват добър /etc/inetd.conf файл, с който да работите. Тук, за пълнота ще покажем един /etc/inetd.conf файл от дистрибуция на Debian.

# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet server configuration database
#
#
# Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
# Internal services
#
#echo		stream	tcp	nowait	root	internal
#echo		dgram	udp	wait	root	internal
discard		stream	tcp	nowait	root	internal
discard		dgram	udp	wait	root	internal
daytime		stream	tcp	nowait	root	internal
daytime		dgram	udp	wait	root	internal
#chargen	stream	tcp	nowait	root	internal
#chargen	dgram	udp	wait	root	internal
time		stream	tcp	nowait	root	internal
time		dgram	udp	wait	root	internal
#
# These are standard services.
#
telnet	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.telnetd
ftp	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.ftpd
#fsp	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.fspd
#
# Shell, login, exec and talk are BSD protocols.
#
shell	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rshd
login	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind
#exec	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rexecd
talk	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.talkd
ntalk	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.ntalkd
#
# Mail, news and uucp services.
#
smtp	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.smtpd  
#nntp	stream	tcp	nowait	news	/usr/sbin/tcpd	/usr/sbin/in.nntpd
#uucp	stream	tcp	nowait	uucp	/usr/sbin/tcpd	/usr/lib/uucp/uucico
#comsat	dgram	udp	wait	root	/usr/sbin/tcpd	/usr/sbin/in.comsat
#
# Pop et al
#
#pop-2	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.pop2d
#pop-3	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.pop3d
#
# `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
# current implementation of the `finger' daemon allows it to be run as `root'.)
#
#cfinger stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.cfingerd
#finger	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.fingerd
#netstat	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/netstat
#systat	stream	tcp	nowait	nobody	/usr/sbin/tcpd	/bin/ps -auwwx
#
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
#
#tftp	dgram	udp	wait	nobody	/usr/sbin/tcpd	/usr/sbin/in.tftpd
#tftp	dgram	udp	wait	nobody	/usr/sbin/tcpd	/usr/sbin/in.tftpd /boot
#bootps	dgram	udp	wait	root	/usr/sbin/bootpd	bootpd -i -t 120
#
# Kerberos authenticated services (these probably need to be corrected)
#
#klogin		stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind -k
#eklogin	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rlogind -k -x
#kshell		stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/in.rshd -k
#
# Services run ONLY on the Kerberos server (these probably need to be corrected)
#
#krbupdate	stream tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/registerd
#kpasswd	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/sbin/kpasswdd
#
# RPC based services
#
#mountd/1	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.mountd
#rstatd/1-3	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rstatd
#rusersd/2-3	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rusersd
#walld/1	dgram	rpc/udp	wait	root	/usr/sbin/tcpd	/usr/sbin/rpc.rwalld
#
# End of inetd.conf.
ident		stream	tcp	nowait	nobody	/usr/sbin/identd	identd -i

5.9. Други допълнителни, свързани с мрежата конфигурационни файлове.

Под Linux има още няколко допълнителни файла, свързани с мрежовата конфигурация, които могат да ви заинтересуват. Може никога да не ви се наложи да модифицирате тези файлове, но си струва да ги опишем, за да знаете какво съдържат и за какво служат те.

5.9.1. /etc/protocols

  protocolname  number  aliases

Файлът /etc/protocols, доставян с Debian е следният:

# /etc/protocols:
# $Id: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# Internet (IP) protocols
#
#	from: @(#)protocols	5.1 (Berkeley) 4/17/89
#
# Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

ip	0	IP		# internet protocol, pseudo protocol number
icmp	1	ICMP		# internet control message protocol
igmp	2	IGMP		# Internet Group Management
ggp	3	GGP		# gateway-gateway protocol
ipencap	4	IP-ENCAP	# IP encapsulated in IP (officially ``IP'')
st	5	ST		# ST datagram mode
tcp	6	TCP		# transmission control protocol
egp	8	EGP		# exterior gateway protocol
pup	12	PUP		# PARC universal packet protocol
udp	17	UDP		# user datagram protocol
hmp	20	HMP		# host monitoring protocol
xns-idp	22	XNS-IDP		# Xerox NS IDP
rdp	27	RDP		# "reliable datagram" protocol
iso-tp4	29	ISO-TP4		# ISO Transport Protocol class 4
xtp	36	XTP		# Xpress Tranfer Protocol
ddp	37	DDP		# Datagram Delivery Protocol
idpr-cmtp	39	IDPR-CMTP	# IDPR Control Message Transport
rspf	73	RSPF		# Radio Shortest Path First.
vmtp	81	VMTP		# Versatile Message Transport
ospf	89	OSPFIGP		# Open Shortest Path First IGP
ipip	94	IPIP		# Yet Another IP encapsulation
encap	98	ENCAP		# Yet Another IP encapsulation

5.9.2 /etc/networks

Файлът /etc/networks има функция, сходна с тази на файла /etc/hosts. Той осигурява проста база от данни на имена на мрежи срещу мрежови адреси. Форматът му се различава в това, че в него може да има само две полета на ред и те се кодират така:

  networkname networkaddress

Един пример би изглеждал така:

	loopnet    127.0.0.0
	localnet   192.168.0.0
	amprnet    44.0.0.0

Когато използвате команда като route, ако направлението е мрежа и за тази мрежа има запис в /etc/networks, тогава рутиращата команда ще изведе на екрана името на мрежата вместо нейния адрес.

5.10. Мрежова сигурност и контрол на достъпа.

Нека да зпочна тази секция с предупреждението, че защитата на вашата машина и мрежа срещу злонамерени атаки е сложно изкуство. Аз не се считам за голям експерт в тази област, така че механизмите които описвам биха помогнали, но ви препоръчвам ако сериозно сте се замислили относно сигурността, да направите някои собствени проучвания в по темата. В Internet има много хубави справочници, свързани с това, включително Security-HOWTO

Едно много важно практическо правило е: 'не стартирай сървъри, които нямаш намерение да използваш'. Много дистрибуции идват конфигурирани с услуги от всякакъв род, които се стартират автоматично. За да си осигурите едно минимално ниво на сигурност, редно е да прегледате вашия /etc/inetd.conf файл и да коментирате (сложете '#' в началото на всеки ред) всички записи за услуги, които не смятате да използвате. Добри кандидати са услуги като: shell, login, exec, uucp, ftp и информационни услуги като finger, netstat и sysstat.

Има вякакви видове механизми за сигурност и контрол на достъпа. Ще опиша само най-елементарните от тях.

5.10.1. f/etc/ftpusers

Файлът f/etc/ftpusers е прост механзиъм, който позволява да отказвате на определени потребители достъп до вашата машина по fftp. Файлът f/etc/ftpusers се прочита от ftp демона (ftpd) когато се пяви входяща ftp-връзка. Той представлява прост списък на тези потребители, на които е забранено да се логват. Той би могъл да изглежда така:

	# /etc/ftpusers - users not allowed to login via ftp
	root
	uucp
	bin
	mail

5.10.2. /etc/securetty

Файлът /etc/securetty ви позволява да укажете през кои tty устройства е разрепено на root да се логва. Той се прочита от програмата за вклюючване (обикновено /bin/login), и представлява списък от tty устройства, през които е разрешено включването на root, логването му през вскички останали е забранено:

	# /etc/securetty - tty's on which root is allowed to login
	tty1
	tty2
	tty3
	tty4

5.10.3. Механизъм за контрол на достъпа tcpd.

Програмата tcpd, която видяхте посочена в /etc/inetd.conf по-горе, осигурява запис в журналните файлове и механизми за контрол на достъпа за услугите, за които е настроена да защитава.

Когато бъде извикана от inetd, тя прочита два файла, съдържащи правила за достъп и съответно разрешава или забранява достъпа до защитавания сървър.

Тя ще претърси правилата, докато не открие съвпадение. Ако не бъде открито такова, се предполага, че трябва да се разреши достъп на всеки. Файловето, които претърсва последователно са: /etc/hosts.allow, /etc/hosts.deny. Ще опиша всеки от тях поред. За пълно описание на тези възможности прегледайте подходящите man страници (hosts_access (5) е добро начало).

5.10.3.1. /etc/hosts.allow

Файлът /etc/hosts.allow е конфигурационен файл на програмата /usr/bin/tcpd. Той съдържа правила, описващи на кои хостове е разрешен достъп до услуга на вашата машина.

Неговия формат е доста прост:

	# /etc/hosts.allow
	#
	# <service list>: <host list> [: command]

Това е разделен със запетая списък от имена на сървъри към които се прилага това правило. Примерни имена на сървъри са: ftpd, telnetd и fingerd.

	root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
	root# route add -net 192.168.0.0 netmask 255.255.255.0 eth0

        alias eth0 ne
        alias eth1 ne
        alias eth2 ne
	options ne io=0x220,0x240,0x300
   

        alias eth0 3c501
        alias eth1 3c501
        options eth0 -o 3c501-0 io=0x280 irq=5
        options eth1 -o 3c501-1 io=0x300 irq=7
	

7.2. Настройване на DHCP клиенти за потребители на LinuxConf

Под Linux като root стартирайте програмта linuxconf. Тази програма е включена във всички версии на Red Hat и работи както под X, така и в конзолен режим. Тя също така работи и за SuSE и Caldera.

Select Networking
----------------->Basic Host Information
----------------->Select Enable
----------------->Set Config Mode DHCP

7.3. Настройка на DHCP сървър под Linux

Ако вашата машина няма, вземете DHCPD. Get DHCPD

Внимание: УВЕРЕТЕ СЕ, ЧЕ СТЕ РАЗРЕШИЛИ MULTICAST В ЯДРОТО

Ако няма двоична дистрибуция за вашата версия на Linux, ще трябва да компилирате DHCPD.

Редактирайте вашия /etc/rc.d/rc.local, за да отразите добавянето на път към 255.255.255.255.

Цитат от DHCPd README:

За да работи коректно с придричиви DHCP клиенти (като Windows 95), трябва да е възможно изпращането на пакети с IP адрес на получателя 255.255.255.255. За нещастие Linux настоява да променя 255.255.255.255 в локалния подмрежов адрес (тук, това е 192.5.5.223). Това е нарушение на DHCP протокола, и докато някои DHCP клиенти не го забелязват, някои (всички Microsoft DHCP клиенти) го забелязват. Клиентите, имащи този проблем няма да виждат съобщенията DHCPOFFER от сървъра.

Напишете следното с права на root:

route add -host 255.255.255.255 dev eth0

Ако се появи съобшението:

255.255.255.255: Unknown host

опитйте като добавите следния запис във вашия /etc/hosts файл:

255.255.255.255 dhcp

след което опитайте:

route add -host dhcp dev eth0

7.3.1. Опции на DHCPD

Сега трябва да конфигурирате DHCPd. За да стане това трябва да създадете или редактирате /etc/dhcpd.conf. Има графичен интерфейс за конфигуриране на dhcpd под linuxconf. Това прави настройката и управлението на DHCPD изключително просто.

Ако искате да го настроите на ръка, следвайте по-долните инструкции. Предлагам ви да го настроите ръчно поне веднъж. Ще ви е от помощ в диагностиката, каквато GUI не може да ви предостави. За нещастие в Microsoft не вярват на това.

Най-лесния начин е да присвоите случаен IP адрес. По-долу е даден примерен конфигурационен файл, показващ този тип настройка.

# Sample /etc/dhcpd.conf
# (add your comments here)
default-lease-time 1200;
max-lease-time 9200;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1, 192.168.1.2;
option domain-name "mydomain.org";

subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
range 192.168.1.150 192.168.1.200;
}

Това позволява на DHCP сървъра да присвоява адреси в диапазона 192.168.1.10 - 192.168.1.100 или 192.168.1.150 - 192.168.1.200.

Заемането на IP адрес е с продължителност 1200 секунди, освен ако клиента не поиска по-дълъг период от време. Иначе максималния (разрешен) период на заемане, който сървъра ще позволи е 9200 секунди. Сървърът ще изпрати следните параметри на клиента:

Използвай като мрежова маска 255.255.255.0; използвай 192.168.1.255 като broadcast адрес; използвай 192.168.1.254 като свой портал по подразбиране; използвай 192.168.1.1 и 192.168.1.2 като свои DNS сървъри.

Ако посочите WINS сървър за WIndows клиентите си, ще е необходимо да включите следната опция във файла dhcpd.conf:

option netbios-name-server 192.168.1.1;

Може също така да присвоите определен IP адрес базиран на MAC адреса на клиента, напр.:

  host haagen {
     hardware ethernet 08:00:2b:4c:59:23;
     fixed-address 192.168.1.222;
}

Това ще установи 192.168.1.222 като IP адрес на клиент с MAC адрес 08:00:2b:4c:59:23.

7.3.2. Стартиране на сървъра

В повечето случаи инсталацията на DHCP не създава dhcpd.leases файл. Затова преди да стартирате сървъра трябва да напишете следното, за да създадете празен файл:

touch /var/state/dhcp/dhcpd.leases

За да стартирате DHCP сървъра, просто напишете (или включете в скрипт от процеса на зареждане)

/usr/sbin/dhcpd

Това ще стартира dhcpd на устройство eth0. Ако е необходимо да го стартирате на друго устройство, просто напишете на командния ред:

/usr/sbin/dhcpd eth1

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

/usr/sbin/dhcp -d -f

Заредете някой клиент и погледнете конзолата на сървъра. Там ще видите известен брой debugging съобщения.

Your done

7.4. EQL - балансьор на трафика през няколко линии.

Името на EQL устройството е 'eql'. При стандартния изходен код на ядрото може да имате само едно EQL устройство на машина. EQL осигурява начин да се използват множество линии от типа точка-до-точка - PPP, SLIP или PLIP, като една логическа връзка, носеща tcp/ip. Често е много по-евтино да се използват множество нискоскоростни линии, вместо една високоскоростна.

Kernel Compile Options:

	Network device support  --->
	    [*] Network device support
	    <*> EQL (serial line load balancing) support

За да се поддържа този механизъм, машината от другия край на линиите, също трябва да поддържа EQL. Linux, Livingstone Portmasters и новите dial-in сървъри поддъжат такива съвместими възможности.

За да кофигурирате EQL ще са ви необходими eql инструментите, които са достъпни от: matalab.unc.edu.

Настройката е доста праволинейна.Започате с конфигурирането на eql интерфейса. Той е като всеки друг мрежов интерфейс. Настройвате IP адреса и MTU, чрез командата ifconfig, така че ще се получи нещо такова:

	root# ifconfig eql 192.168.10.1 mtu 1006

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

И последно, трябва да асоциирате серийната връзка с EQL устройството, това се нарича 'поробване' (enslaving) и се прави с командата eql_enslave както е показано:

	root# eql_enslave eql sl0 28800
	root# eql_enslave eql ppp0 14400

Параметъра 'estimated speed', който подавате на eql_enslave, не прави нищо директно. Той се използва от EQL драйвера, за да определи какъв дял от дейтаграмите трябва да получава това устройство, така че вие можете финно да настройвате натоварването на линиите като променяте тази стойност.

За да отделите линия от EQL устройството, използвайте командата eql_emancipate както в показано:

	root# eql_emancipate eql sl0

Добавянето на пътища става, както бихте го направили за всяка друга връзка точка-до-точка, с изключение на това, че пътищата ви трябва да се отнасят към eql устройството, вместо към действителните серийни устройства. Обикновено бихте използвали:

	root# route add default eql

EQL драйвера бе разработен от Simon Janes, simon@ncm.com.

7.5.1. IP Accounting (за Linux-2.2)

Новия код за акаунтинг е достъпен чрез "IP Firewall Chains". За повече информация вижте the IP chains home page

Освен другите неща, сега ще са ви необходими ipchains вместо ipfwadm, за да конфигурирате филтрите си.

7.6. IP Aliasing (псевдоними).

Има някои приложения, при които конфигурирането на няколко IP адреса за едно мрежово устройство е полезно. Internet-доставчиците често използват тази възможност, за да доставят WWW, с настройки, кскто и ftp до клиентите си. Може да погледнете в "IP-Alias mini-HOWTO" за повече информация.

Kernel Compile Options:

	Networking options  --->
	    ....
	    [*] Network aliasing
	    ....
	    <*> IP: aliasing support
	

След компилирането и инсталиране на ядрото с поддръжка на IP_Alias; конфигурацията е много проста. Добавяте псевдонимите като виртуални мрежови устройства присъединени към реалното мрежово устройство. Конвенцията за именуване на тези устройства е: <devname>:<virtual dev num>, т.е. eth0:0, ppp0:10 и т.н. Отбележете, че виртуалното устройство може да бъде конфигурирано след като главното устройство бъде настроено.

Например, представете си, че имате ethernet мрежа, която поддържа две различни IP подмрежи едновременно и вие желаете машината ви да има директен достъп и до двете. Можете да използвате нещо като:

	root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
	root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

	root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
	root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
	

За да изтриете псевдоним просто добавете '-' към края на името му или просто:

	root# ifconfig eth0:0- 0

Всички пътища, асоциирани с това устройство ще се изтрият автоматично.

7.7. IP Firewall (за Linux-2.0)

Въпросите за IP Firewall и Firewalling са разгледани подробно в Firewall-HOWTO.

7.7.1 IP Firewall (за Linux-2.2)

Новия код за firewalling е достъпен чрез "IP Firewall Chains". За повече информация вижте the IP chanins home page

7.8. IPIP Капсулация

Защо бихте искали да обвивате IP дейтаграма в друга IP дейтаграма ? Това ще ви се стори доста странно нещо, ако не сте виждали приложението му преди. Добре, ето някои от местата, където се използва: Mobile-IP, IP-Multicast. Това, в което е най-широко използвана капсулацията, е и най-малко познато, Amateur Radio.

Kernel Compile Options:

	Networking options  --->
	    [*] TCP/IP networking
	    [*] IP: forwarding/gatewaying
	    ....
	    <*> IP: tunneling

IP tunnel устройствата се наричат 'tunl0', tunl1' и т.н.

"Но защо ?". Е, добре де, добре. Обикновеното правила за IP рутиране, нареждат, че IP мрежата съдържа мрежов адрес и мрежова маска. Това създава серии от съседни адреси, които могат да бъдат рутирани чрез единствен рутиращ запис. Това е доста удобно, но означава, че докато сте свързани с Internet, трябва да използвате IP-адреса на устройството, откъдето сте свързан. В повечето случаи, няма проблем, но ако сте мобилен 'гражданин на Мрежата', тогава може да не е възможно да се свързвате винаги от едно и също място. IP/IP капсулирането (IP tunneling) преодолява това ограничение, като позволява дейтаграмите, предназначени за вашия IP адрес, да бъдат обвити в други и препратени към друг IP адрес. Ако знаете, че ще работите от някоя друга IP мрежа за известно време, може да настройте машина от домашната ви мрежа да приема дейтаграми да вашия IP адрес и да ги препраща към адреса, който временно използвате в момента.

7.8.1. A tunneled network configuration.

 192.168.1/24                          192.168.2/24

     -                                     -
     |      ppp0 =            ppp0 =       |
     |  aaa.bbb.ccc.ddd  fff.ggg.hhh.iii   |
     |                                     |
     |   /-----\                 /-----\   |
     |   |     |       //        |     |   |
     |---|  A  |------//---------|  B  |---|
     |   |     |     //          |     |   |
     |   \-----/                 \-----/   |
     |                                     |
     -                                     -

Диаграмата показва друга възможна причина за IPIP капсулиране - виртуална частна мрежа (VPN, virtual private network). Примерът предполага, че имате две машини, всяка използваща проста dial-up интернет връзка. На всеки хост е отделен един IP адрес. Зад всяка от тези машини има някакви частни мрежи, конфигурирани със запазени IP адреси Да предположим, че искате всеки хост от мрежа A да може да комуникира с всеки хост от мрежа B, все едно че са свързани към Internet по нормалния начин. IPIP капсулирането позволява да се направи това. Обърнете внимание, че IPIP капсулацията не решава проблема как хостовете от мрежите A и B ще се свързват с останалата част от Internet, за тази цел трябва да използвате трикове като маскиране на IP (известно още като NAT или IP Masquerade). Капсулирането обикновено се изпълнява от машините работещи като рутери.

Linux рутера 'A' ще бъде конфигуриран със скрипт, подобен на следния:

	#!/bin/sh
	PATH=/sbin:/usr/sbin
	mask=255.255.255.0
	remotegw=fff.ggg.hhh.iii
	#
	# Ethernet configuration
	ifconfig eth0 192.168.1.1 netmask $mask up
	route add -net 192.168.1.0 netmask $mask eth0
	#
	# ppp0 configuration (start ppp link, set default route)
	pppd
	route add default ppp0
	#
	# Tunnel device configuration
	ifconfig tunl0 192.168.1.1 up
	route add -net 192.168.2.0 netmask $mask gw $remotegw tunl0
	

Linux рутер 'B' ще използва подобен скрипт:

	#!/bin/sh
	PATH=/sbin:/usr/sbin
	mask=255.255.255.0
	remotegw=aaa.bbb.ccc.ddd
	#
	# Ethernet configuration
	ifconfig eth0 192.168.2.1 netmask $mask up
	route add -net 192.168.2.0 netmask $mask eth0
	#
	# ppp0 configuration (start ppp link, set default route)
	pppd
	route add default ppp0
	#
	# Tunnel device configuration
	ifconfig tunl0 192.168.2.1 up
	route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0
	

Командата:

	route add -net 192.168.1.0 netmask $mask gw $remotegw tunl0

се чете като: 'Изпращай всички дейтаграми предназначени за 192.168.1.0/24 капсулирани (обвити) в дейтаграма с адрес на назначението aaa.bbb.ccc.ddd'.

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

7.8.2 A tunneled host configuration.

Не е необходимо да рутирате цяла мрежа през тунела. Може, например да рутирате само един IP адрес. В този случай можете да конфигурирате устройство tunl на отдалечената (remote) машина с найния 'домашен' IP адрес, и от края на 'A' да рутирате чрез път до хоста (Proxy Arp), вместо да ползвате път до цялата мрежа през тунелното устройство. Нека да преизчертаем и модифицираме конфигурацията по подходящ начин. Сега имаме само хост 'B', който ще искаме да действа и се държи сякаш е едновременно изцяло свързан към Internet и да е част от отдалечената мрежа, поддържана от хоста 'A':

 192.168.1/24

     -
     |      ppp0 =                ppp0 =
     |  aaa.bbb.ccc.ddd      fff.ggg.hhh.iii
     |
     |   /-----\                 /-----\
     |   |     |       //        |     |
     |---|  A  |------//---------|  B  |
     |   |     |     //          |     |
     |   \-----/                 \-----/
     |                      also: 192.168.1.12
     -

Linux рутера 'A' ще бъде конфигуриран с:

	#!/bin/sh
	PATH=/sbin:/usr/sbin
	mask=255.255.255.0
	remotegw=fff.ggg.hhh.iii
	#
	# Ethernet configuration
	ifconfig eth0 192.168.1.1 netmask $mask up
	route add -net 192.168.1.0 netmask $mask eth0
	#
	# ppp0 configuration (start ppp link, set default route)
	pppd
	route add default ppp0
	#
	# Tunnel device configuration
	ifconfig tunl0 192.168.1.1 up
	route add -host 192.168.1.12 gw $remotegw tunl0
	#
	# Proxy ARP for the remote host
	arp -s 192.168.1.12 xx:xx:xx:xx:xx:xx pub
	

Linux хоста 'B' ще бъде конфигуриран с:

	#!/bin/sh
	PATH=/sbin:/usr/sbin
	mask=255.255.255.0
	remotegw=aaa.bbb.ccc.ddd 
	#
	# ppp0 configuration (start ppp link, set default route)
	pppd
	route add default ppp0
	#
	# Tunnel device configuration
	ifconfig tunl0 192.168.1.12 up
	route add -net 192.168.1.0 netmask $mask gw $remotegwtunl0
	

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

7.9. IP Maquerade

Много хора имат прост dialup акаунт, за да се свързват с Internet. Почти във всички случаи на тях им се осигурява само един IP адрес от Internet доставчика им. Обикновено това е достатъчно, за да позволи на един хост да има пълен достъп до Мрежата. IP Masquerade е хитър трик, който ви дава възможността много машини да използват този единствен IP адрес и да изглеждат все едно те са машината с dial-up връзката; оттук и термина 'маскиране'. Има едно малко неудобство; функцията на маскиране почти винаги работи само в едната посока. Така, че маскираните хостове могат да търсят, но не могат да получават мрежови връзки от отдалечени хостове. Това означава, че някои мрежови услуги няма да роботят (такива като talk, а други като ftp трябва да са настроени да работят в пасивен (PASV) режим, за да ги има). За щастие по-известните мрежови услуги като telnet, WWW и irc работят чудесно.

Kernel Compile Options:

	Code maturity level options  --->
	    [*] Prompt for development and/or incomplete code/drivers
	Networking options  --->
	    [*] Network firewalls
	    ....
	    [*] TCP/IP networking
	    [*] IP: forwarding/gatewaying
	    ....
	    [*] IP: masquerading (EXPERIMENTAL)
	

Обикновено имате linux машина, поддържаща SLIP или PPP dial-up линия, също като домашния ви компютър у дома. Тя ще бъде конфигурирана с допълнителни мрежово устройство, вероятно ethernet, конфигурирано с един от запазените мрежови адреси. Маскираните хостове ще са част от тази втора мрежа. Като път по подразбиране (default route) на всеки от тях, ще бъде зададен IP адреса на ethernet-картата на linux машината.

Една типична конфигурация би могла да е нещо подобно на:

-                                   -
 \                                  | 192.168.1.0
  \                                 |   /255.255.255.0
   \                 ---------      |
    |                | Linux | .1.1 |
NET =================| masq  |------|
    |    PPP/slip    | router|      |  --------
   /                 ---------      |--| host |
  /                                 |  |      |
 /                                  |  --------
-                                   -

7.9.1 Маскиране с IPFWADM (Ядра 2.0.x)

Най-уместни за такава конфигурация са командите:

	# Network route for ethernet
	route add -net 192.168.1.0 netmask 255.255.255.0 eth0
	#
	# Default route to the rest of the internet.
	route add default ppp0
	#
	# Cause all hosts on the 192.168.1/24 network to be masqueraded.
	ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 
	

7.9.2 Маскиране с IPCHAINS

Това е подобно на използването на IPFWADM, но структурата на командите е променена:

        # Network route for ethernet
        route add -net 192.168.1.0 netmask 255.255.255.0 eth0
        #
        # Default route to the rest of the internet.
        route add default ppp0
        #
        # Cause all hosts on the 192.168.1/24 network to be masqueraded.
	ipchains -A forward -s 192.168.1.0/24 -j MASQ
        

Можете да научите повече относно възможностите на Linux за IP маскиране от IP Masquerade Resource Page. Също така, много подрабен документ относно маскирането е "IP-Masquerade mini-HOWTO" (в който има инструкции как се настройват други OS да ползват маскиращ сървър пос Linux).

7.10. Прозрачно IP Proxy

Прозрачното IP proxy е функция, позволяваща пренасочване на сървъри и услуги, предназначени за друга машина към услугите на тази машина. Обикновено това е полезно, когато имате за рутер linux машина, която също е и прокси-сървър.

Kernel Compile Options:

	Code maturity level options  --->
		[*] Prompt for development and/or incomplete code/drivers
	Networking options  --->
		[*] Network firewalls
		....
		[*] TCP/IP networking
		....
		[*] IP: firewalling
		....
		[*] IP: transparent proxy support (EXPERIMENTAL)
	

Настройката на прозрачното прокси се извършва чрез командата ipfwadm.

Следния пример може да ви свърши работа:

	root# ipfwadm -I -a accept -D 0/0 telnet -r 2323

Сега всеки опит за връзка към порт 23 (telnet) на всеки хост, ще бъде пренасочен към порт 2323 на този хост. Ако стартирате услугата на този порт, ще можете да препращате telnet връзки; да ги записвате (log) или каквото сметнете за необходимо.

По интересен пример е пренасочването на целия http трафик към локалния кеш. Все пак, протоколът, използван от прокси-сървърите е различен от обикновеното http: когато клиент се свърже към www.server.com:80 и поиска /path/page, тогава той бива свързван към локалния кеш proxy.local.domain:8080 и иска www.server.com/path/page.

За да се филтрират http-заявките през локалното прокси, трябва да приспособите протокола като вмъкнете малък сървър, наречен transproxy (може да го намерите в world wide web). Ако изберете да стартирате transproxy на порт 8081, ще използвате тази команда:

	root# ipfwadm -I -a accept -D 0/0 80 -r 8081

Тогава програмата transproxy, ще приема всички връзки предназначени за външни сървъри и ще ги подаде към локалния прокси-сървър след като поправи разликите в протоколите.

7.11 IPv6

Точно когато си помислихте, че започвате да разбирате IP мрежите правилата се промениха! IPv6 е съкратеното наименование на версия 6 на Internet Protocol. IPv6 бе разработен главно за да се преодолеят страховете в Internet-обществото, че скоро ще има недостиг на IP адреси за разпределение. IPv6 адресите са с дължина 16 байта (128 бита). В IPv6 са вградени и редица други промени, предимно опростявания, които ще направят IPv6-мрежите по-лесно управляеми от IPv4-мрежите.

Под Linux вече има работещ (но не напълно), IPv6 за ядрата от сериято 2.2.x.

7.13. Mobile IP

Термина "подвижност на IP" описва възможността даден хост да мести мрежовата си връзка към Internet от една точка на друга, без да променя IP адреса си или да губи връзката. Обикновено, когато хост промени мястото, откъдето се свързва, трябва да смени и IP адреса, който ползва. Подвижността на IP преодолява този проблем, чрез предоставяне на фиксиран IP адрес на подвижния хост и използване на IP-капсулиране (tunneling) с автоматично рутиране, за да може предназначените за него дейтаграми, да бъдат рутирани към реалния IP адрес, който той използва в момента.

Съществува проект, който да предостави пълен комплект инструменти за мобилност на IP под Linux. Текущото му състояние, както и самите инструменти могат да бъдат открити на: Linux Mobile IP Home Page.

7.14. Multicast

IP Multicast позволява IP дейтаграмите на произволен брой IP хостове от различни IP мрежи, да бъдат рутирани едновременно между тях. Този механизъм се използва, за да се доставя в Internet "broadcast" материал като аудио и видео предавания, както и други нови приложения.

Kernel Compile Options:

Networking options  --->
	[*] TCP/IP networking
	....
	[*] IP: multicasting

Необходими са редица инструменти и малко допълнителна мрежова настройка. Моля проверете Multicast-HOWTO за повече информация относно поддръжката на Multicast под Linux.

7.15. Traffic Shaper - Променяне на разрешената честотна лента.

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

Shaper бе въведен в Linux-2.1.15 и бе пренесен в Linux-2.0.36 (първата му поява е в 2.0.36-pre-path-2, разпространен от Alan Cox, авторът на устройството shaper, и човека, отговарящ за Linux-2.0).

Traffic shaper може да се компилира само като модул и се конфигурира чрез програмата shapecfg, с команди като следната:

	shapecfg attach shaper0 eth1
	shapecfg speed shaper0 64000

Shaper-устройството може да контролира честотната лента само на изходящ трафик, като пакетите се предават само през shaper-a и според рутиращите таблици; така функционалността на "рутиране според адреса на източника" може да помогне за ограничаване на цялостната честотна лента на определени хостове чрез използване на Linux рутер.

Linux-2.2 вече има поддръжка за такъв тип рутиране, ако ви е необходимо за Linux-2.0, моля проверете patch-a от Mike McLagan, на ftp.invlogic.com. Погледнете в Documentation/networking/shaper.txt за повече информация относно shaper.

Ако желаете да пробвате експериментален shaping за входящи пакети, опитайте rshaper-1.01 (или по-нов), от ftp://ftp.systemy.it/pub/develop.

Глава 8. Усъвършенствани мрежи с Kernel 2.2

Ядрата 2.2 имат известни усъвършенствания на рутиращите възможности. За съжаление почти е невъзможно да се намери информация за тези нови възможности, дори ако такава съществува.

Аз вложих известно време в това и смятам, че се справям малко с тях. Ще прибавя още неща когато имам време и когато разбера какво означават всички тези неща.

В ядра 2.0 и надолу Linux използваше стандартната команда route за да създава пътища в една-единствена рутираща таблица. Ако напишете netstat -rn на Linux промпта, можете да видите един пример.

В по-новите ядра (2.1 и по-големи) имате друга възможност. Тя се основава на правила и ви позволява да имате множество рутиращи таблици. Новите правила добавят голяма доза гъвкавост, при вземане на решения как да се борави с пакетите. Може да избирате пътища на базата не само на адреса на назначение, но и според адреса на източника, TOS, или устройството от което пристигат пакетите.

8.1. Основите

Показване на рутиращата таблица:

ip route

На моята машина тази команда извежда следния изход:

207.149.43.62 dev eth0  scope link
207.149.43.0/24 dev eth0  proto kernel  scope link  src 207.149.43.62
default via 207.149.43.1 dev eth0

Първият ред:

207.149.43.62 dev eth0 scope link е пътят за интерфейса

Вторият ред:

207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62 е пътят който казва а всичко останало отива към 207.149.43.0 трябва да излезе навън 207.149.43.62.

Третият ред:

default via 207.149.43.1 dev eth0 е пътят по подразбиране.

8.1.1 Използвайки тази информация

Вече минахме през основната рутираща таблица. Да видим сега как да я използваме. Първо прочетете the Policy routing text. Ако се объркате, не се притеснявайте -- това си е объркващ текст. Той ще ви даде някаква представа какво може да прави новият рутиращ код.

8.2. Добавяне на път с новите ip инструменти

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

ip route add 207.149.43.62 dev eth0  scope link
ip route add 207.149.43.0/24 dev eth0 proto kernel scope link src 207.149.43.62
ip route add 127.0.0.0/8 dev lo  scope link
ip route add default via 207.149.43.1 dev eth0

Както виждате изхода и входа са почти еднакви, с тази разлика, че е добавено ip route add в началото на реда.

Забележка: Осведомени сме, че документацията за Рутиране с 2.2 е извънредно оскъдна. Всъщност това ВСЕКИ го знае. Ако имате някакъв опит с него, моля свържете се с нас - poet@linuxports.com , ще сме ви благодарни за информацията, за бъдещи версии на този документ.

8.3. Използване на NAT с Kernel 2.2

Функцията IP Network Address Translation е доста добре стандартизираният по-голям брат на Linux IP Masquerade. Той е определен с подробности в RFC-1631 от най-близкия до вас RFC-архив. NAT осигурява възможности, които IP-Masquerade няма, и които го правят крайно по-подходящ за ползване в корпоративни firewall-рутиращи конструкции, и в много големи инсталации.

Алфа-версия на NAT за Linux 2.0.29 ядро бе разработена от Michael Hasenstein, Michael.Hasenstein@informatik.tu-chemnitz.de. Документацията и софтуера на Michael са достъпни на:

Linux IP Network Address Web Page

Подобреният TCP/IP стек на Linux-ядрата 2.2 имат вградена NAT-фунционалност. Заради тези възможности работата на Michael Hasenstein (Michael.Hasenstein@informatik.tu-chemnitz.de) е излязла от уптреба.

За да заработи, ви трябва ядро с разрешени CONFIG_IP_ADVANCED_ROUTER, CONFIG_IP_MULTIPLE_TABLES (aka policy routing) и CONFIG_IP_ROUTE_NAT (aka fast NAT). Така също, ако искате да използвате по-финни NAT правила, ще включите firewalling (CONFIG_IP_FIREWALL) и CONFIG_IP_ROUTE_FWMARK. За да работите реално с тези въможности на ядрото, ще ви е необходима програмата "ip" от Alexey Kuznyetsov от ftp://ftp.inr.ac.ru/ip-routing/.

NAT на входящи дейтаграми

За да се транслира адресът на входящите дейтаграми, се използва следната команда:

	   ip route add nat <ext-addr>[/<masklen>] via <int-addr>

Това ще накара за входящите пакети, предназначени за "ext-addr" (адресът, видим отвън,откъм internet) да бъде пренаписвано полето им 'адрес на предназначение' на "int-addr" (адресът във вашата вътрешна мрежа, зад вашия портал/firewall). По-нататък пакетът се рутира според локалната рутираща таблица. Може да транслирате както един-единствен адрес на хост, така и цели блокове от адреси. Примери:

  
  	ip route add nat 195.113.148.34 via 192.168.0.2
   	ip route add nat 195.113.148.32/27 via 192.168.0.0

Първата команда ще направи вътрешния адрес 192.168.0.2 достъпен като 195.113.148.34. Вторият пример показва съpоставяне на блок 192.168.0.0-31 като 195.113.148.32-63.

Глава 9. Справочник на IP командите на Kernel 2.2 (work in progress)

9.1. ip

Ако имате инсталирани инструментите iproute2, изпълнението на командата ip ще изведе на екрана основния й синтаксис.

[root@jd Net4]# ip
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
where  OBJECT := { link | addr | route | rule | neigh | tunnel |
                   maddr | mroute | monitor }
       OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |
                    -f[amily] { inet | inet6 | dnet | link } | -o[neline] }

Има още няколко опции:

-V, -Version -- извежда версията на използваната команда ip и приключва.

-s, -stats, -statistics -- извежда по-голям обем данни за посоченото устройство. Може да изпъл