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

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

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

Ако сте свързани директно през 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 -- извежда по-голям обем данни за посоченото устройство. Може да изпълните тази опция повече от веднъж, за да увеличите количеството информация, извеждана на екрана.

-f, -family followed by a protocol family identifier such as: inet, inet6 or link. -- Указва да се използва точно определена фамилия протоколи, inet ползва стандартен IPv4 (т.е. текущия internet стандарт), inet6 ползва IPv6 (експериментален), и link (физическа връзка). Ако не укажете опцията, се прави опит да бъде разпознат, а ако няма достатъчно информация, ще се ползва този по подразбиране.

-o, -oneline Показва изхода от всеки запис на устройство на един ред.

-r, -resolve Използва системния резолвер (т.е.; DNS), за да отпечата имената до IP номерата.

OBJECT е обекта/устройството, което се управлява или за което се извежда информация. Текущо разпознаваните устройства в сегашната версия са:

• link -- Мрежово устройство; eth0 или ppp0.
• address -- IP (IP или IPv6) адреса на посоченото устройство.
• neigh -- ARP или NDISC запис в кеша.
• route -- Запис в рутиращата таблица
• rule -- Правило в routing policy database
• maddress -- Мултикаст адрес
• mroute -- multicast route запис в кеша
• tunnel -- Дали има или не тунел върху IP

Количеството на възможните опции за всеки обект зависи от типа на предприетите действия. Общото правило е, че са възможни add, delete, или да се покаже обекта(ите), но не всички обекти позволяват да бъдат използвани допълнителни команди. Командата help, разбира се, е достъпна за всички обекти и когато се използва ще отпечата списък с възможните синтактични конвенции за дадения обект.

Ако не подадете команда, ще бъде изпълнена командата по подразбиране. Обикновено командата по подразбиране е да се изведе списък на обектите, а ако няма обекти в списъка се извежда стандартния помощен екран.

ARGUMENTS е списъкът от агрументи, които могат да бъдат предадени на командата. Броят им зависи от командата и обекта, които се използват. Има два типа аргументи:

Flags - състоят се от ключова дума, следвана от стойност. За удобство всяка команда има някакви параметри по подрабиране. Например, параметъра dev> по подразбиране сочи ip link.

Грешки... благодарим ти Боже, за умните програмисти. Всички операции на ip командите са динамични. Ако синтаксиса е неправилен, командата няма да промени конфигурацията на системата. Както винаги, има едно изключение - командата ip link, която се използва, за да се променят частично параметрите на устройствата.

Трудно е да се даде списък на съобщенията за грешки (особено, на синтактичните грешки), но по правило, значенията им са ясни, в контекста на командата. Най-често срещаните грешки са: 1. Ядрото е компилирано без поддръжка на Netlink. Съобщението е: Cannot open netlink socket: Invalid value

2. Ядрото е компилирано без поддръжка на RTNETLINK. В този случай може да бъде изведено едно от следните съобщения, в зависимост от командата: Cannot talk to rtnetlink: Connection refused Cannot send dump request: Connection refused

3. Не е била избрана опцията CONFIG_IP_MULTIPLE_TABLES при конфигурирането на ядрото. В такъв случай всеки опит да бъде използвана командата dip rule ще се провали, т.е.:

jd@home $ ip rule list RTNETLINK error: Invalid argument dump terminated

Глава 10. Използване на добре познат (общодостъпен) PC хардуер

10.1. ISDN

Integrated Services Digital Network (ISDN) са серия от стандарти, определящи цифрови прекъсваеми мрежи за данни с общо предназначение. ISDN 'повикването' създава синхронна услуга за данни тип "точка-до-точка" да назначението. Обикновено ISDN се доставя по високоскоростна линия разделена на определен брой отделни канали. Има два различни типа канали - 'B канали', които всъщност пренасят потребителските данни и един-единствен канал, наречен 'D канал', който се използва за изпращане на контролна информация от ISDN централата за създаване на повиквания и други функции. Например в Австралия ISDN може да бъдат доставяни по 2 Mbps линия, която е разделена на 30 отделни 64 Kbps B-канала и един 64 Kbps D-канал. Всякакъв брой канали могат да бъдат използвани по всяко време и във всякаква комбинация. Например, може да установите 30 отделни връзки до 30 различни направления по 64 Kbps всяка, или пък 15 връзки до 15 различни направления по 128 Kbps всяка (използват се два канала на връзка), или пък по малък брой връзки, а останалите да са свободни. Каналът може да се използва както за входящи, така и за изходящи обаждания. Оригиналното намерение на ISDN беше да позволи на телекомуникационните компании да доставят универсална услуга за данни, която е възможно да доставя както телефонни (чрез цифровизация на гласа), така и услуги за данни да дома ви или до вашия бизнес без да са необходими специални конфигурационни промени.

Има няколко различни начина компютъра ви да се свърже към ISDN услуга. Единия начин е чрез използване на т.нар. 'Terminal Adaptor" устройство, което се включва в мрежовия накрайник, инсталиран ви от телекома и представляващ известен брой серийни интерфейси. Единия от тези интерфейси се ползва за въвеждане на команди по установяване на връзката и за конфигуриране, а другите всъщност се свързват към мрежовите устройства, пренасящи данните. Linux ще работи при такъв тип конфигурация без модификации, вие ще се отнасяте към порта на Терминалния Адаптор, както към серийно устройство. Другият начин е, при който в ядрото е вградена поддръжка на ISDN, и вие инсталирате ISDN карта в Linux-машината и тогава Linux софтуера ще се оправя с протоколите и сам ще прави повиквания.

Kernel Compile Options:

	ISDN subsystem  --->
		<*> ISDN support
		[ ] Support synchronous PPP
		[ ] Support audio via ISDN
		< > ICN 2B and 4B support
		< > PCBIT-D support
		< > Teles/NICCY1016PC/Creatix support
	

Linux изпълнението на ISDN поддържа няколко различни типа вътрешни ISDN карти. Това са:

• ICN 2B and 4B

• Octal PCBIT-D

• Teles ISDN-cards and compatibles

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

Пълните подробности как да се настрои поддръжката на Linux ISDN са достъпни в директорията /usr/src/linux/Documentation/isdn/, FAQ, посветен на isdn4linux е достъпен на http://www.lrz-muenchen.de/~ui161ab/www/isdn/. (Кликнете на англииския флаг, за англииската версия).

Бележка относно PPP. Комплектът PPP протоколи ще работи както върху асинхронни, така и през синхронни серийни линии. Най-разпространеният PPP демон за Linux 'pppd' поддържа само асинхронен режим. Ако искате да ползвате PPP протоколи върху ISDN-услуги ще ви е необходима специално модифицирана версия. Подробности за това къде да я намерите има в посочената по-горе документация.

10.2. PLIP за Linux-2.0

Имената на PLIP-устройствата са 'plip0, 'plip1' и 'plip2'

Kernel Compile Options:

	Network device support  --->
	    <*> PLIP (parallel port) support
	

PLIP (Parallel Line IP), е подобен на SLIP по това, че се използва за създаване на мрежова връзка тип " точка-до-точка" между две машини, с изключение на това, че се използват паралелните портове на машината ви, вместо серийните (диаграма на окабеляването е включена в съответната секция по-късно в този документ). Понеже е възможно да се пренасят повече от един бит едновременно, с PLIP интерфейса са възможни и по-високи скорости от стандартното серийно устройство. Освен това, дори и най-простите от паралелните портове, портовете за принтери, могат да се ползват, вместо да е необходимо да закупувате сравнително скъпия 16550AFN UART чип за серийните си портове. PLIP натоварва доста процесора спрямо серийните връзки и със сигурност не е добър избор, ако можете да се сдобиете с някоя от евтините ethernet карти, но ако нямате друг избор - ще работи, и то добре. Може да очаквате трансфер със скорост около 20 Kbytes/s, когато линията работи добре.

PLIP драйверите за устройства се съревновават с драйвера за паралелния порт за това хардуерно устройство. Ако искате да ги ползвате едновременно, следва да ги компилирате като модули, за да можете да избирате кой порт ще ползвате за PLIP, и кой - за принтера, със съответния драйвер. Обърнете се към "Modules mini-HOWTO" за повече информация относно конфигуриранете на модули на ядрото.

Моля, отбележете си, че някои лаптопи използват чипсети, които не работят с PLIP, защото не позволяват някои комбинации от сигнали, на които се основава PLIP, но принтерите не използват.

PLIP интерфейса за Linux е съвместим със Crynwyr Packet Driver PLIP и това означава, че може да свържете Linux-машината си с DOS-машина, ползваща някакъв вид tcp/ip софтуер през PLIP.

В ядрата от серия 2.0.*, PLIP устройствата се съпоставят с i/o портовете и IRQ както следва:

	device	i/o	IRQ
	------	-----	---
	plip0	0x3bc	5
	plip1	0x378	7
	plip2	0x278	2
	

Ако вашите паралелни портове не съвпадат с някоя от горните комбинации, тогава променете IRQ на порта, като използвате командата ifconfig със параметъра 'irq' (но първо разрешете използването на IRQ за притерския си порт от ROM BIOS, ако той поддържа тази опция). Друг вариант е да укажете опциите "io=" и "irq=" на командния ред на insmod, ако използвате модули. Например:

	root# insmod plip.o io=0x288 irq=5

PLIP операциите се контролират от два периода (timeouts), чийто стойности по подразбиране са добре в повечето случаи. Вероятно ще има нужда да ги увеличите, особено при бавен компютър, в който случай таймерите, които трябва да се увеличат са тези на другия компютър. Съществува програма, наречена plipconfig, която позволява да променяте тези времена без да е необходима прекомпилация на ядрото. Тя включена в много дистрибуции на Linux.

За да настройте PLIP интерфейса, трябва да напишете следните команди (или ги добавете в инициализационните си скриптове):

	root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
	root# /sbin/route add remoteplip plip1

Тук, използвания порт е този на I/O адрес 0x378; localip и remoteip са имената или IP адресите, използвани по PLIP кабела. Лично аз ги държа в базата от данни /etc/hosts:

	# plip entries
	192.168.3.1   localplip
	192.168.3.2   remoteplip

Параметъра pointopoint има същото значение като този на SLIP, той указва адреса на машината в другия край на линията.

В почти всички отношения, можете да третирате PLIP интерфейст все едно е SLIP интерфейс, с тази разлика, че не са необходими нито dip, нито slattach, нито пък могат да се използват.

По-нататъчна информация за PLIP може да се намери в "PLIP mini-HOWTO".

10.2.1. PLIP за Linux-2.2

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

Kernel Compile Options:

General setup ---> [*] Parallel port support Network device support ---> <*> PLIP (parallel port) support

Новия код за PLIP се държи като стария (използват се същите команди - ifconfig и route както в предишната секция, но инициализацията на устройството е различна, поради усъвършенстваната поддръжка за паралелни портове.

"Първото" PLIP устройство винаги се нарича "plip0", където първо е това устройство, което първо бъде открито от системата, подобно на устройсвата Ethernet. Реално използваният паралелен порт е един от достъпните портове, както се вижда в /proc/parport. Например, ако имате само един паралелен порт, ще имате само една директория наречена /proc/parport/0.

Ако ядрото ви не засече кое IRQ ползва вашият порт, "insmod plip" ще се провали; в такъв случай просто напишете правилния номер в /proc/parport/0/irq и птново извикайте insmod.

Пълна информация за управлението на паралелни портове има във файла /Documentation/parport.txt, като част от изходния код на ядрото ви.

10.3. PPP

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

PPP-HOWTO все още е Linux Documentation Project document , но официалния му адрес е на

	Network device support  --->
	    [*] Network device support
	    <*> SLIP (serial line) support
	    [ ]  CSLIP compressed headers
	    [ ]  Keepalive and linefill
	    [ ]  Six bit SLIP encapsulation
	

	user% tar xvzf dip337o-uri.tgz
	user% cd dip-3.3.7o
	user% vi Makefile
	root# make install
	

#
# sample.dip	Dialup IP connection support program.
#
#		This file (should show) shows how to use the DIP
#       This file should work for Annex type dynamic servers, if you
#       use a static address server then use the sample.dip file that
#       comes as part of the dip337-uri.tgz package.
#
#
# Version:	@(#)sample.dip	1.40	07/20/93
#
# Author:	Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
#

main:
# Next, set up the other side's name and address.
# My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42)
get $remote xs4all.hacktic.nl
# Set netmask on sl0 to 255.255.255.0
netmask 255.255.255.0
# Set the desired serial port and speed.
port cua02
speed 38400

# Reset the modem and terminal line.
# This seems to cause trouble for some people!
reset

# Note! "Standard" pre-defined "errlevel" values:
#  0 - OK
#  1 - CONNECT
#  2 - ERROR
#
# You can change those grep'ping for "addchat()" in *.c...

# Prepare for dialing.
send ATQ0V1E1X4\r
wait OK 2
if $errlvl != 0 goto modem_trouble
dial 555-1234567
if $errlvl != 1 goto modem_trouble

# We are connected.  Login to the system.
login:
sleep 2
wait ogin: 20
if $errlvl != 0 goto login_trouble
send MYLOGIN\n
wait ord: 20
if $errlvl != 0 goto password_error
send MYPASSWD\n
loggedin:

# We are now logged in.
wait SOMEPROMPT 30
if $errlvl != 0 goto prompt_error

# Command the server into SLIP mode
send SLIP\n
wait SLIP 30
if $errlvl != 0 goto prompt_error

# Get and Set your IP address from the server.  
#   Here we assume that after commanding the SLIP server into SLIP
#   mode that it prints your IP address
get $locip remote 30
if $errlvl != 0 goto prompt_error

# Set up the SLIP operating parameters.
get $mtu 296
# Ensure "route add -net default xs4all.hacktic.nl" will be done
default

# Say hello and fire up!
done:
print CONNECTED $locip ---> $rmtip
mode CSLIP
goto exit

prompt_error:
print TIME-OUT waiting for sliplogin to fire up...
goto error

login_trouble:
print Trouble waiting for the Login: prompt...
goto error

password:error:
print Trouble waiting for the Password: prompt...
goto error

modem_trouble:
print Trouble occurred with the modem...
error:
print CONNECT FAILED to $remote
quit

exit:
exit

	#
	# Attach a leased line static SLIP connection
	#
	#  configure /dev/cua0 for 19.2kbps and cslip
	/sbin/slattach -p cslip -s 19200 /dev/cua0 &
	/sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up
	#
	# End static SLIP.
	

• /etc/passwd, за dialin потребителски акаунти.
• /etc/slip.hosts, да съдържа информацията, уникална за всеки dial-in потребител.
• /etc/slip.login, който управлява настройката и рутирането, които трябва да се изпълнят за всеки потребител.
• /etc/slip.tty, който се изисква, само ако конфигурирате сървъра си за динамично отпускане на адреси и съдържа таблица с адресите за отпускане.
• /etc/slip.logout, съдържащ почистващи команди, след като потребителя затвори и излезе.

10.4.10. Откъде да вземем sliplogin

Вие вече може да имате sliplogin инсталиран, като част от веашата дистрибуция, ако го няма, можете да го получите от: metalab.unc.edu. Архивът съдържа изходния код, изпълнима програма и man страницата.

За да могат само оторизирани потребители да стартират sliplogin, добавете запис, подобен на този във вашия файл /etc/group:

 ..
slip::13:radio,fred
 ..

Когато инсталирате пакета sliplogin, Makefile ще промени груповия идентификатор на sliplogin на slip, и това означава, че само членове от тази група ще могат да я изпълняват.

За да инсталирате двоичните файлове в директорията /sbin, и man страницата в секция 8, направете следното:

# cd /usr/src
# gzip -dc .../sliplogin-2.1.1.tar.gz | tar xvf -
# cd sliplogin-2.1.1
# <..edit the Makefile if you don't use shadow passwords..>
# make install

Ако искате да да ги прекомпилирате преди инсталацията, добавете make clean и make install. Ако желаете да ги инсталирате някъде другаде, ще трябва да редактирате Makefile install rule.

10.4.11 Конфигуриране на /etc/passwd за Slip хостове.

Обикновено ще създадете някои специални регистрации за Slip потребители във файла /etc/passwd. Конвенцията, следвана най-често е да използва hostname на извикващия хост с клавна буква 'S' като префикс. Така например, ако извикващия хост се казва radio, записът с /etc/passed ще изглежда така:

Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin

Няма значение как ще се казва акаунта, стига това да значи нещо за вас.

Забележка: Няма нужда от специална директория home за потребителя, тъй като те няма да ползват шел на тази машина, така че /tmp е добър избор. Обърнете внимание, че sliplogin се използва вместо нормалния логин шел.

10.4.12 Конфигуриране на /etc/slip.hosts

Във файла /etc/slip.hosts, sliplogin търси записи, съвпадащи с името на потребителя, за да получи съответния детайли за него. Това е файла, където определяте ip адреса и мрежовата маска, които ще се присвоятват на потребителите и ще бъда настройвани за употреба. Примерните записи за два хоста, един със статична конигурация (radio), и друг със динамична (albert) са:

#
Sradio   44.136.8.99   44.136.8.100  255.255.255.0  normal      -1
Salbert  44.136.8.99   DYNAMIC       255.255.255.0  compressed  60
#

Записите в /etc/slip.hosts са:

1. Логин име на потребителя.
2. IP адрес на сървърната машина, т.е. на тази машина.
3. IP адрес, присвояван на потребителя. Ако в това поле е записано DYNAMIC, IP адреса ще се избере на базата на информацията, съдържаща се във вашия файл /etc/slip.tty описан по-късно. Забележка: Трябва да използвате версия на sliplogin поне 1.3, за да работи тази опция.
4. Мрежовата маска на потребителската машина в десетичен запис - т.е. 255.255.255.0 за мрежа от клас C.
5. Режим на Slip, разрешаващ или забраняващ използването на компресия и други възможности. Възможните стойности тук са "normal" и "compressed".
6. Параметър за времето, който указва колко време може да бездейства линията (да няма приети дейтаграми), преди тя да бъде прекъсната. Отрицателна стойност ще изключи тази опция.
7. Допълнителни аргументи.

Забележка: Може да използвате името на хоста или IP адреса в десетичен запис за полета 2 и 3. Ако ползвате имена на хост, те трябва да са познати, т.е. вашата машина да е способна да открие техните IP адреси, в противен случай, скрипта няма да роботи. Може да изпробвате това, като се опитате да се telnet-нете към хоста, ако получите съобщение 'Trying nnn.nnn.nnn...', вашата машина намира ip адреса за този хост, иначе съобщението би било 'Unknown host'. Ако не го намира използвайте ip адрес или поправете настройката на резолвера на имена (Виж секцията Name Resolution).

Най-известните режими на slip са:

normal

за използване на нормален некомпресиан SLIP.

compressed

използва van Jacobsen header compression (cSLIP)

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

10.4.13. Настройване на файла /etc/slip.login.

След като sliplogin претърси /etc/slip.hosts и намери съвпадащ запис, ще се опита да изпълни файла /etc/slip.login за реалната конфигурация на SLIP интерфейса с ip адрес и мрежова маска.

Примерния /etc/slip.login файл, доставян с пакета sliplogin изглежда така:

#!/bin/sh -
#
#       @(#)slip.login  5.1 (Berkeley) 7/1/90
#
# generic login file for a SLIP line.  sliplogin invokes this with
# the parameters:
#     $1       $2       $3    $4, $5, $6 ...
#   SLIPunit ttyspeed   pid   the arguments from the slip.host entry
#
/sbin/ifconfig $1 $5 pointopoint $6 mtu 1500 -trailers up
/sbin/route add $6
arp -s $6 <hw_addr> pub
exit 0
#

Ще забележите, че този скрипт просто използва командите ifconfig и route, за да конфигурира SLIP устройствата с техния ip адрес, отдалечения ip адрес и мрежова маска, и да създаде път за отдалечения адрес през SLIP устройството. Същото, каквото бихте направили вие чрез командата slattach.

Забележете също използването на Proxy ARP, за да подсигури други хостове от същата ethernet мрежа като сървърната машина, ще знаят как да достигнат dial-in хостовете. Полето <hw_addr> следва да бъде харуерния адрес на ethernet картата на вашата машина. Ако тя не е в ethernet мрежа може да оставите това поле празно.

10.4.13. Настройване на файла /etc/slip.logout.

Когато връзката се разпадне, бихте искали серийното устройство да възстанови нормалното си състояние, за да могат потребителите да се включват коректно отново. Това се постига чрез използването на файла /etc/slip.logout. Неговия формат е доста прост и се извиква със същия аргумент както файла /etc/slip.login.

#!/bin/sh - # # slip.logout # /sbin/ifconfig $1 down arp -d $6 exit 0 #

Всичко, което той прави е да 'спре' интерфейса, което ще изтрие ръчно зададения път, създаден преди това. Също така, той използва командата arp, за да изтрие съществуващ proxy arp, и отново, командата arp не ви трябва в скрипта ако машината ви няма ethernet порт.

10.4.15. Конфигуриране на файла /etc/slip.tty.

Ako използвате динамочно разпределение на ip адресите (имате някои хостове, настроени с ключова дума DYNAMIC във файла /etc/slip.hosts), следва да конфигурирате файла /etc/slip.tty със списък кои адреси се присвояват на кои портове. Този файл е необходим само ако сървъра ви разпределя динамично адресите за потребителите.

Файлът представлява таблица със списък на tty устройствата, които ще поддържат dial-in SLIP връзките и ip адресите, които ще се присвояват на потребителите, свързжащи се към този порт.

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

# slip.tty    tty -> IP address mappings for dynamic SLIP
# format: /dev/tty?? xxx.xxx.xxx.xxx
#
/dev/ttyS0      192.168.0.100
/dev/ttyS1      192.168.0.101
#

Това, което казва тази таблица, е че на потребителите, свързали се с порт /dev/ttyS0, притежаващи поле с отдалечен адрес във файла /etc/slip.hosts, установено на DYNAMIC, ще бъде присвояван адрес 192.168.0.100.

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

10.4.16. Slip сървър с използване на dip.

Ще започна, казвайки че някои части от по-долната информация са от справочните страници на dip, където е документирано накратко как се ползва SLIP сървър. Знайте, че следното се основава на пакета dip337o-uri.tgz и е възможно да не е приложимо за други версии на dip.

Dip има оперативен режим за въвеждане, при който той автоматично намира запис за потребителя, който го е извикал и конфигурира серийната линия като SLIP според информацията, намерена във файла /etc/diphosts. Този оперативен режим се активира чрез извикване на dip като diplogin. Това следователно е начина, по който да използваме dip като SLIP сървър, като създадем специални акаунти, за които като логин-шел да се ползва diplogin.

Първото нещо, което трябва да направите е да създадете символна връзка както следва:

# ln -sf /usr/sbin/dip /usr/sbin/diplogin

След това трябва да добавите записи във вашите /etc/passwd и /etc/diphosts файлове. Записите, които ще направите имат следния вид:

За да настройте Linux като SLIP сървър с dip, трябва да създадете специални SLIP регистрации за потребители, за които dip ще се използва (в режим въвеждане) като логин-шел. Препоръчвана конвенция е всички SLIP акаунти да започват с главна буква 'S', т.е. 'Sfredm'.

Примерен/etc/passwd запис изглежда така:

Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin ^^ ^^ ^^ ^^ ^^ ^^ ^^ | | | | | | \__ diplogin as login shell | | | | | \_______ Home directory | | | | \____________ User Full Name | | | \_________________ User Group ID | | \_____________________ User ID | \_______________________________ Encrypted User Password \__________________________________________ Slip User Login Name

След като потребителя се регистрира, програмат login, ако намери и провери потребителската регистрация, ще изпълни командата diplogin. Dip когата е извикана като diplogin знае, че трябва автоматично да приеме, че се използва като логин-шел. Когато е стартирана като diplogin, първото нещо което прави тя е да извика функцията getuid(), за да получи потребителския идентификационен номер (userid) на този, който я е извикал. Тогава тя претърсва файла /etc/diphosts, за запис, съвпадащ с този userid или името на tty tty устройството, от което идва обаждането, и се конфигурира правилно. С разумни решения като: дали да се прибави запис за потребителя в diphosts, или да бъде изпълнене конфигурацията по подразбиране, можете да изградите сървъра си по начин, подобен на комбинирания подход на статично и динамично присвоявани адреси на потребителите.

Dip автоматично ще добави 'Proxy-ARP' запис, ако е извикан в режим 'въвеждане', така че не е необходимо да мислите за ръчно добавяне на подобни записи.

Конфигуриране на /etc/diphosts

Файлът /etc/diphosts се използва от dip, за предварително установени конфигурации за отдалечени хостове. Тези отдалечени хостове могат да бъдат потребители, набиращи вашата linux машина, или те могат да са машини, които вие набирате с вашата linux машина.

Главният формат за /etc/diphosts е както следва:

.. Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296 ..

Полетата са:

1. Login name: както е върнато от getpwuid(getuid()) или tty името.

2. Unused: съвместим с passwd

3. Remote Address: IP адресът на повикващия хост, цифров или по име

4. Local Address: IP адресът на тази машина, отново цифров или по име

5. Netmask: в точкуван десетичен запис

6. Comment field: сложете каквото искате тук.

7. Protocol: Slip, CSlip и т.н.

8. MTU: десетично число

Примерен /etc/diphosts запис за отдалечен SLIP потребител може да бъде:

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296

който установява SLIP връзка с отдалечен адрес 145.71.34.1 и MTU = 296, или:

Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006

който установява връзка с cSLIP-способности с отдалечен адрес 145.71.34.1 и MTU = 1006.

По тази причина, всички потребители, които ще имат статичен dial-up IP достъп следва да имат запис в /etc/diphosts. Ако искате потребителите, които се свързват на определен порт да имат динамично разпределени детайли, трябва да имате запис за tty устройството и да не конфигуриранте потребителски записи. Трябва да помните да конфигурирате поне един запис за всяко tty устройство, използвано от вашите dialup потребители, за да осигурите подходяща конфигурация за тях, независимо от кой модем се свързват.

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

10.4.18 SLIP сървър с използване на пакета dSLIP

Matt Dillon<dillon@appollo.west.oic.com> написа пакет, който поддържа не само dial-in, но и dial-up SLIP. Пакетът на Matt е комбинация от малки програми и скриптове, които управляват връзките ви. Ще е необходимо да имате инсталиран tcsh, тъй като поне един от скриптовете го изисква. Matt е приложил двоично копиие на праграмата expect, която също е необходима на един от скриптовете. Най-вероятно ще ви е необходим някакъв опит с expect, за да заработи пакета, но не се оставяйте това да ви разколебае.

Matt е написал добър набор от инсталационни инструкции в README файла, така че за вас няма да е проблем да ги повторите.

Можете да вземете пакета dSLIP от официалния му сайт:

/pub/linux/dillon_src/dSLIP203.tgz

или от:

/pub/Linux/system/Network/serial/dSLIP203.tgz

Прочетете README файла и създайте /etc/passwd и /etc/group преди да направите make install.

Chapter 11. Other Network Technologies

The following subsections are specific to particular network technologies. The information contained in these sections does not necessarily apply to any other type of network technology. The topics are sorted alphabetically.

Това е акроним от Address Resolution Protocol и това е начина по-който мрежова машина асоциира IP адрес с хардуерен адрес.

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

Това обикновено е част от софтуера от страната на потребителската система. Има и изключения, например, графичната система X11 на практика е сървър при потребиеля и клиента работи на отдалечената машина. Клиента е програма или крайна система, която получава услуги, доставяни от сървъра. В случай на равнопоставени системи (peer to peer) като slip или ppp, за клиент се приема този край, който е инициирал връзката, а отдалечения край, който е бил извикан - за сървър.

Дейтаграмата е самостоятелен пакет от данни и хедъри, съдържащи адреси, който е основна предавателна единица в IP мрежите. Може да чуете да ги наричат 'пакети'.

DLCI е Data Link Connection Identifier и се ползва за идентификация на уникална виртуална връзка 'точка-до-точка' през Frame Relay мрежа. DLCI обикновено се присвояват от мрежовия доставчик на Frame Relay.

Мрежова технология, която подхожда идеално за пренос на неравномерен и спорадичен трафик. Цената на мрежата се намалява, когато има много Frame Relay потребители споделящи един и същ мрежов капацитет, и се основава на желанието им да го ползват по различно време.

Това е номер, който еднозначно идентифицира хост във физическа мрежа на media access layer. Примери за това са Ethernet Addresses и AX.25 Addresses.

Това е акроним за Integrated Services Digital Network. ISDN доставя стандартизирани средства, чрез които телекомуникационните компании могат да доставят информация (глас или данни) до потребителите си. Технически ISDN е превключваема мрежа за данни.

Това е акроним за Internet Service Provider. Те са организации или фирми, даставящи мрежови връзки към Internet.

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

Максимален размер на сегмент (Maximum Segment Size - MSS) е най-голямото количество данни, което може да се предаде наведнъж. Ако желаете да предотвратите локална фрагментация MSS ще бъде равно на MTU-IP хедъра.

Maximum Transmission Unit (MTU) е параметър, които определя най-голямата дейтаграма, която може да бъде предадена от даден IP интерфейс, без да се разбива на по-малки части. MTU следва да бъде по-голяма от най-голямата дейтаграма, която желаете да се пренесе нефрагментирана. Забележете, че това предотвратява фрагментацията локално, някоя друга връзка може да има по-малка MTU и там дейтаграмата ще се фрагментира. Обичайните стойности са 1500 байта за ethernet интерфейс, или 576 байта за SLIP интерфейс.

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

Това обикновено е част от софтуера откъм отдалечения край на потребителя. Сървъра доставя някакви услуги на един или много клиенти. Примери за сървъри са ftp, Networked File System, или Domain Name Server. В случай на равнопоставени системи като slip или ppp за сървър се приема този край на връзката, който е бил извикан, а другия край се приема за клиент.

Window е най-голямото количество данни, което приемащия край може да приеме в даден момент.