Ipsysctl tutorial 1.0.4

Ipsysctl tutorial 1.0.4

Ipsysctl tutorial 1.0.4

Автор: Oskar Andreasson

     blueflux@koffein.net
      Copyright (C) 2002 Oskar Andreasson
    

Перевод: Андрей Киселев

     kis_an@mail.ru
    

Последнюю версию документа можно получить по адресу: http://ipsysctl-tutorial.frozentux.net/ .

Допускается копирование, распространение и/или модификация данного документа или его части, в соответствии с соглашениями, принятыми в GNU Free Documentation License, версии 1.1. Неизменяемыми разделами являются раздел "Введение" и все подразделы этого раздела, а так же разделы, начинающиеся словами "Original Author: Oskar Andreasson", Копия GNU Free Documentation License включена в данный документ и находится в секции "GNU Free Documentation License".

Все сценарии в данном руководстве подпадают под действие GNU General Public License. Они являются свободно распространяемыми и могут копироваться, распространяться и/или модифицироваться в соответствии с условиями GNU General Public License версии 2, опубликованной Free Software Foundation.

Сценарии распространяются в надежде на то, что они будут полезны вам, но БЕЗ КАКИХ ЛИБО ГАРАНТИЙ. За дополнительной информацией обращайтесь к тексту GNU General Public License.

С данным документом должна распространяться копия GNU General Public License, в секции "GNU General Public License"; в случае ее отсутствия вы можете сообщить по адресу Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA



Посвящения

Этот документ посвящается всем, кто помог мне в работе над ошибками в ранних версиях этого руководства и тем, кто продолжает помогать. И каждому, кто пользуется свободными продуктами, выходящими под Свободными Лицензиями.

Кроме того, я хочу посвятить этот документ моей семье, за то, что она проявляла понимание, когда я этого не заслуживал, за то, что выколачивала дурь из моей головы, когда я этого заслуживал и просто за то, что все члены семьи обладают хорошим чувством юмора.

Содержание
Предисловие
1. Зачем написано это руководство
2. Кому адресовано это руководство
3. Как читать это руководство
4. Типографские соглашения
5. Благодарности
1. Введение
1.1. Виртуальные файловые системы
1.2. Файловая система /proc
1.3. Краткое описание файловой системы /proc
2. Как произвести запись в переменные
2.1. С помощью sysctl
2.2. С помощью файловой системы /proc
3. Переменные IPv4
3.1. Переменные IP
3.1.1. ip_autoconfig
3.1.2. ip_default_ttl
3.1.3. ip_dynaddr
3.1.4. ip_forward
3.1.5. ip_local_port_range
3.1.6. ip_no_pmtu_disc
3.1.7. ip_nonlocal_bind
3.1.8. ipfrag_high_thresh
3.1.9. ipfrag_low_thresh
3.1.10. ipfrag_time
3.2. Inet peer storage
3.2.1. inet_peer_gc_maxtime
3.2.2. inet_peer_gc_mintime
3.2.3. inet_peer_maxttl
3.2.4. inet_peer_minttl
3.2.5. inet_peer_threshold
3.3. Переменные TCP
3.3.1. tcp_abort_on_overflow
3.3.2. tcp_adv_win_scale
3.3.3. tcp_app_win
3.3.4. tcp_dsack
3.3.5. tcp_ecn
3.3.6. tcp_fack
3.3.7. tcp_fin_timeout
3.3.8. tcp_keepalive_intvl
3.3.9. tcp_keepalive_probes
3.3.10. tcp_keepalive_time
3.3.11. tcp_max_orphans
3.3.12. tcp_max_syn_backlog
3.3.13. tcp_max_tw_buckets
3.3.14. tcp_mem
3.3.15. tcp_orphan_retries
3.3.16. tcp_reordering
3.3.17. tcp_retrans_collapse
3.3.18. tcp_retries1
3.3.19. tcp_retries2
3.3.20. tcp_rfc1337
3.3.21. tcp_rmem
3.3.22. tcp_sack
3.3.23. tcp_stdurg
3.3.24. tcp_syn_retries
3.3.25. tcp_synack_retries
3.3.26. tcp_syncookies
3.3.27. tcp_timestamps
3.3.28. tcp_tw_recycle
3.3.29. tcp_window_scaling
3.3.30. tcp_wmem
3.4. Переменные ICMP
3.4.1. icmp_echo_ignore_all
3.4.2. icmp_echo_ignore_broadcasts
3.4.3. icmp_ignore_bogus_error_responses
3.4.4. icmp_ratelimit
3.4.5. icmp_ratemask
3.4.6. igmp_max_memberships
3.5. Переменные в каталоге conf/
3.5.1. Различия между conf/DEV/, conf/all/ и conf/default/
3.5.2. accept_redirects
3.5.3. accept_source_route
3.5.4. arp_filter
3.5.5. bootp_relay
3.5.6. forwarding
3.5.7. log_martians
3.5.8. mc_forwarding
3.5.9. proxy_arp
3.5.10. rp_filter
3.5.11. secure_redirects
3.5.12. send_redirects
3.5.13. shared_media
3.6. Neigh reference
3.7. Переменные Netfilter
3.7.1. ip_ct_generic_timeout
3.7.2. ip_ct_icmp_timeout
3.7.3. ip_ct_tcp_be_liberal
3.7.4. ip_ct_tcp_log_invalid_scale
3.7.5. ip_ct_tcp_log_out_of_window
3.7.6. ip_ct_tcp_timeout_close
3.7.7. ip_ct_tcp_timeout_close_wait
3.7.8. ip_ct_tcp_timeout_established
3.7.9. ip_ct_tcp_timeout_fin_wait
3.7.10. ip_ct_tcp_timeout_last_ack
3.7.11. ip_ct_tcp_timeout_listen
3.7.12. ip_ct_tcp_timeout_none
3.7.13. ip_ct_tcp_timeout_syn_recv
3.7.14. ip_ct_tcp_timeout_syn_sent
3.7.15. ip_ct_tcp_timeout_time_wait
3.7.16. ip_ct_udp_timeout
3.7.17. ip_ct_udp_timeout_stream
3.8. Route-переменные
3.8.1. error_burst
3.8.2. error_cost
3.8.3. flush
3.8.4. gc_elasticity
3.8.5. gc_interval
3.8.6. gc_min_interval
3.8.7. gc_thresh
3.8.8. gc_timeout
3.8.9. max_delay
3.8.10. max_size
3.8.11. min_adv_mss
3.8.12. min_delay
3.8.13. min_pmtu
3.8.14. mtu_expires
3.8.15. redirect_load
3.8.16. redirect_number
3.8.17. redirect_silence
A. Единицы измерения
A.1. "Тики"
B. Ссылки
C. Хронология
D. GNU Free Documentation License
0. PREAMBLE
1. APPLICABILITY AND DEFINITIONS
2. VERBATIM COPYING
3. COPYING IN QUANTITY
4. MODIFICATIONS
5. COMBINING DOCUMENTS
6. COLLECTIONS OF DOCUMENTS
7. AGGREGATION WITH INDEPENDENT WORKS
8. TRANSLATION
9. TERMINATION
10. FUTURE REVISIONS OF THIS LICENSE
How to use this License for your documents
E. GNU General Public License
0. Preamble
1. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
2. How to Apply These Terms to Your New Programs

Предисловие

1. Зачем написано это руководство

Я приступил к работе над этим документом в надежде на то, что он поможет вам понять настройки IP (от англ. Internet Protocol -- Межсетевой Протокол, прим. перев), предоставляемые ядром Linux 2.4. Этим руководством я надеюсь дать необходимые знания, которые помогут вам изменять настройки ядра "на лету". Часть настроек может быть использована для увеличения производительности, а так же для повышения уровня безопасности. В этом документе не будут обсуждаться все возможности, которые заключает в себе механизм управления системой -- sysctl, здесь мы сосредоточим все свое внимание на управлении сетевой подсистемой. Надеюсь, что этот документ заполнит собою недостаток документации по данной теме. На самом деле едва ли существует достаточно хорошая документация, которая детально описывала бы всю структуру ipsysctl, исключение составляет лишь файл ip-sysctl.txt, входящий в комплект документации, сопровождающей исходные тексты ядра, но она очень и очень кратко поясняет возможные настройки, которые могли бы быть использованы.

Я полагаю, что может существовать литература, которая содержит описание отдельных настроек, однако вам едва ли удастся найти подробное и связное их описания. Если вы нашли этот документ достаточно полезным или просто интересным -- не стесняйтесь, передавайте, помогайте в изучении, переводите на другие языки, вобщем все, что вы сочтете необходимым. Единственная просьба -- присылайте свои замечания, чтобы в документе не было ошибок или неточностей из-за изменений в ядре и пр. Если вам встретится новая команда sysctl, которая не упоминается здесь -- сообщите мне и я постараюсь добавить ее описание как можно быстрее.


2. Кому адресовано это руководство

Этот документ предназначен для всех, кто стремится расширить свои познания как операционной системы Linux в целом, так и TCP/IP в частности. Для понимания этого документа вы должны обладать хорошими знаниями о TCP/IP, вы должны знать -- что такое заголовок пакета и из каких частей он состоит. Вам так же понадобится понимание принципов маршрутизации и основы построения сетей на базе TCP/IP.

Этот документ не предназначен для новичков в Linux, но едва ли это будет серьезным ограничением, если вы испытываете определенные потребности в изучении приводимого здесь материала. Одно лишь замечание -- перед внесением изменений в настройки убедитесь на 100% в том, что достаточно четко представляете себе, что именно вы делаете, поскольку некоторые изменения могут привести к весьма неожиданным результатам.

Этот документ рекомендуется всем, кто интересуется компьютерами и компьютерными сетями. Здесь вы найдете основые сведения о различных переменных, доступных через интерфейс ipsysctl, это поможет вам продвинуться вперед в понимании того, для чего предназначена каждая из них.


3. Как читать это руководство

Этот документ может читаться в любом, удобном для вас порядке. Если вас интересуют лишь отдельные разделы -- читайте их. Если ранее вы никогда не сталкивались с sysctl -- прочитайте первую главу, а затем можете перейти к изучению интересующих вас разделов. Если вас обуревает желание прочитать документ от начала до конца -- читайте так. Если вы предпочитаете читать, начиная с конца -- читайте так. Если вам нравится читать в зашифрованном виде -- я не вижу причин, чтобы не делать этого!

Все, что я хочу сказать -- читайте те разделы, которые представляют для вас интерес. Если что-то для вас окажется непонятным -- прочитайте соответствующие разделы или в этом документе или где либо еще. Я не буду указывать вам -- как читать этот документ, ибо каждый из вас уже имеет некоторые познания и сам сможет решить -- что ему необходимо.


4. Типографские соглашения

В данном документе используются следующие соглашения по выделению информации различного рода:

  • Команды, вводимые пользователем, и вывод, получаемый в результате работы команд, отображаются моноширинным шрифтом, кроме того, ввод пользователя отображается жирным шрифтом:

    [blueflux@work1 neigh]$ ls
    default  eth0  lo
    [blueflux@work1 neigh]$
       
    
  • Все команды и имена программ отображаются жирным шрифтом .

  • Все упоминания об аппаратном обеспечении, а так же о внутренних механизмах ядра или абстрактных понятиях системы (например: петлевой (loopback) интерфейс), отображаются курсивом.

  • Вывод на экран выделяется таким образом.

  • Имена файлов и пути к файлам отображаются таким образом: /usr/local/bin/iptables.


5. Благодарности

Это руководство базируется на описании, содержащемся в /usr/src/linux/Documentation/networking/ip-sysctl.txt. Прежде чем продолжить, я хотел бы поблагодарить людей, которые нашли время для его написания. Все, кто будет читать оба этих документа с легкостью обнаружат, что оба они имеют одинаковую структуру.

Я хотел бы выразить свою признательность всем разработчикам, учавствовавшим в работе над реализацией стека протоколов TCP/IP, которая заняла значительное время. Я надеюсь, что смогу внести свой вклад в сообщество Linux этим руководством, облегчая труд тех, кому оно необходимо.

Я так же хотел бы поблагодарить Fabrice Marie за неоценимую помощь со стандартизацией и за подсказки, когда у меня что-то не получалось. Огромное спасибо всем участникам из списка рассылки netfilter mailing list за помощь при разрешении некоторых вопросов. Огромное спасибо всем участникам проекта linuxsecurity за их терпение, проявленное при выслушивании моих напыщеных речей, а затем и оправданий за срыв сроков публикации.

Хочу выразить огромную благодарность каждому, кто оказал мне посильную помощь.


Глава 1. Введение

Файловая система /proc -- это виртуальная файловая система, которой не существует в действительности, иначе как в "голове" ядра. Файловая системв /proc -- это особенность ядра Linux. Она может присутствовать и в других операционных системах, но с иной функциональностью и другим предназначением.


1.1. Виртуальные файловые системы

Под термином "Виртуальные файловые системы" подразумеваются такие файловые системы, которые не имеют образа на жестком диске, в отличие от обычных файловых систем. Ничто из того, что вы делаете в виртуальной файловой системе не приводит к изменению содержимого на магнитных носителях -- только в оперативной памяти. Виртуальные файловые системы создаются ядром "на лету", в процессе загрузки и изменяются только тогда, когда вы входите в них или выполняете какие либо операции в их пределах.

Note

Виртуальная файловая система может иметь различные предназначения. Она может использоваться как простой RAM-диск, куда могут помещаться файлы на временное хранение. На бездисковых станциях Amiga она используется при копировании файлов с дискеты на дискету. Сначала файл(ы) копируется в память, затем в дисковод вставляется другая дискета и файл(ы) копируется на нее. Однако, эти файлы пропадут как только компьютер будет выключен или перезагружен.


1.2. Файловая система /proc

Виртуальная файловая система /proc содержит большое количество информации, собранной из ядра во время исполнения и модифицируется всякий раз, когда вы пытаетесь просмотреть ее. Вся информация отображается как обычная файловая система -- вы можете просматривать файлы, путешествовать по дереву каталогов и т.п., то есть все то, что вы можете делать и в обычной файловой системе. Однако, большинство файлов в файловой системе /proc доступны только для чтения, т.е. не могут быть изменены. Эти файлы предназначены лишь для того, чтобы предоставить необходимую вам информацию.

Одним из каталогов, доступных на чтение-запись, является каталог /proc/sys. Все переменные ("файлы"), расположенные в этом каталоге и его подкаталогах доступны как для чтения, так и для записи.

В этом документе рассматривается Internet Protocol версии 4 (IPv4). Соответсвующий ему раздел находится в каталоге /proc/sys/net/ipv4. Здесь находятся все настройки стека IPv4, включая TCP, UDP, ICMP и ARP.


1.3. Краткое описание файловой системы /proc

Файловая система /proc содержит несколько основных каталогов и файлов, которые я опишу прежде чем перейти к рассмотрению стека ipv4.

Прежде всего следует упомянуть о том, что эта файловая система содержит огромное количество нумерованных каталогов. Каждый из этих нумерованных каталогов имеет непосредственное отношение к тому или иному активному процессу в системе. Когда запускается новый процесс -- для него создается новый каталог и все данные, касающиеся этого процесса помещаются в данный каталог, сюда помещается командная строка, которой был запущен процесс, ссылка на "текущий рабочий каталог" (cwd), переменные окружения, ссылка на исполняемый файл и т.п..

Кроме того, здесь находится довольно много других файлов и каталогов. Ниже приводится полный список:

[blueflux@work1 ]$ ls -l /proc
total 0
....
-r--r--r--    1 root     root            0 Sep 19 18:09 apm
dr-xr-xr-x    4 root     root            0 Sep 19 10:52 bus
-r--r--r--    1 root     root            0 Sep 19 18:09 cmdline
-r--r--r--    1 root     root            0 Sep 19 18:09 cpuinfo
-r--r--r--    1 root     root            0 Sep 19 18:09 devices
-r--r--r--    1 root     root            0 Sep 19 18:09 dma
dr-xr-xr-x    4 root     root            0 Sep 19 18:09 driver
-r--r--r--    1 root     root            0 Sep 19 18:09 execdomains
-r--r--r--    1 root     root            0 Sep 19 18:09 fb
-r--r--r--    1 root     root            0 Sep 19 18:09 filesystems
dr-xr-xr-x    2 root     root            0 Sep 19 18:09 fs
dr-xr-xr-x    4 root     root            0 Sep 19 18:09 ide
-r--r--r--    1 root     root            0 Sep 19 18:09 interrupts
-r--r--r--    1 root     root            0 Sep 19 18:09 iomem
-r--r--r--    1 root     root            0 Sep 19 18:09 ioports
dr-xr-xr-x   18 root     root            0 Sep 19 18:09 irq
-r--------    1 root     root     268374016 Sep 19 18:09 kcore
-r--------    1 root     root            0 Sep 19 10:52 kmsg
-r--r--r--    1 root     root            0 Sep 19 18:09 ksyms
-r--r--r--    1 root     root            0 Sep 19 18:09 loadavg
-r--r--r--    1 root     root            0 Sep 19 18:09 locks
-r--r--r--    1 root     root            0 Sep 19 18:09 mdstat
-r--r--r--    1 root     root            0 Sep 19 18:09 meminfo
-r--r--r--    1 root     root            0 Sep 19 18:09 misc
-r--r--r--    1 root     root            0 Sep 19 18:09 modules
lrwxrwxrwx    1 root     root           11 Sep 19 18:09 mounts -> self/mounts
-rw-r--r--    1 root     root          208 Sep 19 11:02 mtrr
dr-xr-xr-x    3 root     root            0 Sep 19 18:09 net
dr-xr-xr-x    2 root     root            0 Sep 19 18:09 nv
-r--r--r--    1 root     root            0 Sep 19 18:09 partitions
-r--r--r--    1 root     root            0 Sep 19 18:09 pci
dr-xr-xr-x    3 root     root            0 Sep 19 18:09 scsi
lrwxrwxrwx    1 root     root           64 Sep 19 12:01 self -> 2864
-rw-r--r--    1 root     root            0 Sep 19 18:09 slabinfo
-r--r--r--    1 root     root            0 Sep 19 18:09 stat
-r--r--r--    1 root     root            0 Sep 19 18:09 swaps
dr-xr-xr-x   10 root     root            0 Sep 19 14:39 sys
dr-xr-xr-x    2 root     root            0 Sep 19 18:09 sysvipc
dr-xr-xr-x    4 root     root            0 Sep 19 18:09 tty
-r--r--r--    1 root     root            0 Sep 19 18:09 uptime
-r--r--r--    1 root     root            0 Sep 19 18:09 version
[blueflux@work1 proc]$
 

Большая часть информации находится в формате, удобном для восприятия. Однако есть файлы, к которым не следует "прикасаться", например: kcore. Этот файл хранит отладочную информацию ядра. Если попробовать просмотреть его от начала до конца (хотя бы с помощью команды cat), то это может привести к зависанию и краху системы. В некоторых случаях, попытка скопировать kcore в обычный файл может привести к заполнению всего свободного пространства, имеющегося на заданном разделе жесткого диска. Это еще раз напоминает нам о том, что нужно быть очень и очень осторожными. В большинстве своем содержимое файловой системы /proc безопасно для просмотра, исключение составляют лишь некоторые файлы. Вот краткое описание некоторых переменных (файлов), находящихся в корне файловой системы /proc, содержащих важную информацию:

  • cmdline - Командная строка, переданная ядру во время загрузки.

  • cpuinfo - Информация о Центральном Процессорном Устройстве (CPU), известные баги, флаги и пр.

  • dma - Информация о доступных каналах DMA и драйверах, использующих их.

  • filesystems - Краткая информация о файловых системах, поддерживаемых ядром.

  • interrupts - Краткий список всех IRQ, данные о количестве прерываний, поступивших по каждому из них и драйверы, обслуживающие эти IRQ.

  • iomem - Карта памяти.

  • ioports - Карта портов ввода-вывода.

  • kcore - Полный дамп памяти. Не пытайтесь копировать это файл, это может подвесить вашу систему. Используется в целях отладки.

  • kmsg - Сообщения, переданные ядром, не может и не должен читаться пользователями, поскольку содержит жизненно важную информацию. В основном используется в отладочных целях.

  • ksyms - Таблица символов ядра, которая используется, в основном, для отладки.

  • loadavg - Содержит величину средней нагрузки за последние 1, 5 и 15 минут.

  • meminfo - Информация об использовании памяти.

  • modules - Информация о всех загруженных модулях ядра.

  • mounts - Ссылка на другой файл в файловой системе /proc, который содержит информацию обо всех смонтированных файловых системах.

  • partitions - Информация обо всех разделах на всех устройствах в системе.

  • pci - Информация обо всех PCI устройствах в системе, включая AGP и встроенные устройства, подключенные к шине PCI.

  • swaps - Информация о всех смонтированных swap-разделах.

  • uptime - uptime системы -- время в секундах, прошедшее с момента последней перезагрузки.

  • version - Версия ядра, включая дату сборки и версию компилятора.

Список основных каталогов:

  • bus - Информация обо всех аппаратных шинах, таких как USB, PCI и ISA.

  • ide - Информация обо всех шинах IDE в системе и IDE-устройствах.

  • net - Некоторая базовая информация и статистика сетевой подсистемы.

  • scsi - Информация о SCSI шинах в системе и SCSI-устройствах.

  • sys - Набор переменных, которые могут быть изменены. Сюда входит раздел /proc/sys/net/ipv4, который будет обсуждаться ниже.

Как видите -- в файловой системе /proc имеются, буквально, сотни файлов, содержащих важную информацию. Мы не рассмотрели и половины от их общего количества. Как я уже упоминал -- мы будем расматривать только раздел настроек и переменных ipv4, доступных через интерфейс sysctl.


Глава 2. Как произвести запись в переменные

Информация в переменные ipsysctl может заноситься двумя способами, которые обусловливают два совершенно различных метода. Первый из них -- с помощью команды sysctl, которая имеется в большинстве современных дистрибутивов. Второй способ -- посредством файловой системы /proc, которая должна иметься в любом дистрибутиве Linux, в котором ядро собрано с поддержкой этой файловой системы.

Управляться с командой sysctl немного сложнее, чем с файловой системой /proc. Как уже упоминалось ранее, при работе с командой sysctl вам нужно немножко больше, чем просто ядро. Однако sysctl предлагает лучший вариант внесения большого количества изменений. В этом случае все необходимые настройки могут быть записаны в конфигурационный файл и затем внесены в систему единственным вызовом команды sysctl. Другими словами, sysctl предлагает более гибкий способ настройки системы.

Файловая система /proc предоставляет более простой способ изменения настроек. Поэкспериментировав с настройками и выяснив их необходимый объем, мы можем записать эти настройки в файл sysctl.conf и затем воспроизводить их командой sysctl в момент загрузки системы. Конечно, можно написать сценарий на языке командной оболочки, который будет выполнять необходимые настройки через интерфейс файловой системы /proc, но такой сценарий уступает в читабельности конфигурационному файлу, передаваемому sysctl. Поэтому, если вы планируете выполнять достаточно большой объем настроек ipsysctl, то лучше будет обратиться к помощи команды sysctl.


2.1. С помощью sysctl

Программа sysctl может использоваться для изменения единичной переменной или большого набора переменных (с помощью конфигурационного файла) из командной строки. Но прежде всего, с помощью этой команды можно получить список всех возможных переменных:

sysctl -a

Эта команда выведет список всех переменных, в котором имена переменных отделены символом "=" от их значений. Для вывода списка переменных можно использовать ключи -a и -A. Ключ -a приводит к выводу списка переменных, отделенных от их значений символом "=", а ключ -A -- выводит список в табличной форме (как описывается в man sysctl), но на сегодняшний день эта особенность (имеется ввиду -- вывод в табличной форме) еще не реализована, надеюсь в будущем этот недостаток будет исправлен.

Как вы можете заметить, значительная часть переменных не имеет отношения к ipsysctl. Также, наверняка от вас не ускользнула и нотация переменных (стиль записи). В ipsysctl разделитель"/" заменен на символ "." (точка). Однако sysctl корректно воспримет и разделитель "/", так что с этой стороны проблем возникать не должно. Если вам нужно просмотреть отдельную переменную, то указать это можно следующим образом:

sysctl net.ipv4.tcp_sack

Для записи значения в переменную следует воспользоваться ключом -w, за которым следуют имя переменной и новое значение, отделенной от имени знаком "=", т.е. примерно так:

sysctl -w net.ipv4.tcp_sack=0

Эта команда запишет в переменную tcp_sack value значение 0 и выведет ее на экран в качестве подтверждения. Вобщем ничего особенного. Для того, чтобы внести изменения, находящиеся в конфигурационном файле (который мы обсуждали выше), следует воспользоваться ключом -p, примерно так:

sysctl -p

Эта команда внесет все изменения, которые содержатся в файле /etc/sysctl.conf. Если возникнет потребность в использовании другого имени файла, то нужно указать этот файл в командной строке:

sysctl -p /etc/testsysctl.conf

Этой командой все необходимые настройки будут взяты не из файла по-умолчанию /etc/sysctl.conf, а из указанного в командной строке -- /etc/testsysctl.conf. Формат конфигурационного файла sysctl.conf очень прост. Прежде всего -- строки, начинающиеся символом ";" или "#", являются комментариями. Все командные строки начинаются с пути к переменной, включая имя самой переменной, далее следуют символ "=" и значение, которое должно быть записано в переменную. Путь к переменной указывается относительно /proc/sys. Ниже приводится пример файла sysctl.conf:

# Это комментарий
net.ipv4.ip_forward = 0
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 0
 

В этом файле в переменную net.ipv4.ip_forward записывается 0, т.е. отключается форвардинг (передача транзитных пакетов) между сетевыми интерфейсами. Если вам необходимо разделять единственное подключение к Internet между несколькими компьютерами, то в эту переменную нужно записать 1. Затем в переменную net.ipv4.conf.all.rp_filter записывается 1, включая тем самым, политику фильтрации маршрутов. Эта переменная сообщает ядру о необходимости фильтрации пакетов по их исходящему адресу.

И наконец, посредством записи значения 0 в переменную kernel.sysrq (которая собственно не имеет никакого отношения к сетевой подсистеме), отключается комбинация клавиш sysrq, которая используется при крахе системы. Эта строка добавлена лишь с цель продемонстрировать, что можно изменять и другие переменные, не являющиеся частью ipsysctl.


2.2. С помощью файловой системы /proc

Интерфейс файловой системы /proc предоставляет простой доступ к переменным ipsysctl, однако, он более подходит для экспериментов с настройками, либо когда команда sysctl отсутствует в системе. Очень удобно пользоваться файловой системой /proc в отдельных случаях, когда переменная не должна включаться до определенного момента во время загрузки. Например, было бы просто замечательно, если бы переменная ip_forward включалась уже после того, как будет запущен брандмауэр.

Все что вам необходимо, чтобы пользоваться таким методом чтения-записи переменных -- это команды cat и echo. Очень трудно поверить в то, что у вас нет какой либо из них. Практически невозможно установить систему так, чтобы в ней не было этих команд.

Прежде всего, вам нужно запомнить, что все переменные, которые могут быть использованы или изменены, находятся в каталоге /proc/sys/. Все переменные, которые описываются в данном руководстве, находятся в каталоге /proc/sys/net/ipv4. В общем, для начала вам следует набирать команду

cd /proc/sys/net/ipv4

Чтобы просмотреть список доступных переменных, следует выполнить команду

ls

Проще говоря -- вы все это уже должны знать! Если это не так, то вы взялись читать не то руководство! Чтобы посмотреть значение конкретной переменной, выполните команду cat ip_forward. На мониторе это будет выглядеть примерно так:

[blueflux@work1 ipv4]$ cat ip_forward
0
[blueflux@work1 ipv4]$
  

Как вы можете убедиться, значения переменных могут быть прочитаны любым, кто имеет доступ к системе. Это может показаться вам проблемой с точки зрения безопасности, поскольку любой, имеющий доступ к системе сможет выяснить все настройки системы.

Caution

К сожалению невозможно ограничить права доступа к файловой системе /proc. Дело в том, что все права на доступ жестко "зашиты" в нее, а потому "вручную" они не изменяются. Если вы очень, ОЧЕНЬ захотите изменить права доступа, то вы сможете сделать это внеся изменения в исходный текст программ, которые находятся в каталоге linux/fs/proc.

Для записи значения в переменную воспользуйтесь командой echo. Обычно, команда echo используется для вывода на экран, но мы можем перенаправить вывод и в файл. Для случая bash это может выглядеть примерно так:

[root@work1 ipv4]# echo "1" > ip_forward
[root@work1 ipv4]#
  

Как вы уже наверняка заметили, на сей раз мы находимся в каталоге, где лежит файл (переменная) ip_forward, поэтому не был указан полный путь к переменной. Операции записи доступны только если у вас есть права суперпользователя root. Под простым пользователем попытка записи в переменную будет выглядеть примерно так:

[blueflux@work1 ipv4]$ echo "1" > ip_forward
bash: ip_forward: Permission denied
[blueflux@work1 ipv4]$
  

Обратите внимание на то, что все команды из примеров запускаются в соответствующем каталоге. По этой причине не указывается полный путь к переменным.


Глава 3. Переменные IPv4

В этой главе будут рассмотрены все переменные IPv4, которые доступны через интерфейс sysctl или /proc. Здесь вы найдете описание каждой переменной, за что она отвечает, значение по-умолчанию и, если это возможно, набор допустимых значений. Мы не будем углубляться в дискуссию -- почему та или иная переменная должна быть изменена, если на это не будет особых причин. Структура этой главы отражает структуру каталога ipv4


3.1. Переменные IP

Это список всех переменных, доступных в ядре 2.4.x, которые отвечают за настройку IP. Это довольно большой список. Вам наверняка потребуется изменить некоторые из них под свои условия, а другие такого изменения не требуют. Большинство из переменных имеют достаточно приемлемые значения по-умолчанию, однако, некоторые действительно требуют дополнительной подстройки.


3.1.2. ip_default_ttl

Устанавливает значение по-умолчанию для величины Time To Live исходящих пакетов. Это число определяет продолжительность "жизни" пакета в Internet. Каждый раз, когда пакет попадает на очередной роутер, брандмауэр и т.п., величина TTL пакета уменьшается на 1.

Значение по-умолчанию -- 64. Это достаточно приемлемое значение. Очень трудно представить себе ситуацию, когда это число оказалось бы недостаточным. Переменная принимает целое число без знака в диапазоне от 0 до 255 включительно, однако, значение 255 слишком велико, а если поставить 0 -- то вы вообще лишитесь выхода в сеть. Число 64 достаточно хорошее, если вы не пытаетесь установить соединение с компьютером, отстоящим от вас на значительном растоянии, измеряемом в "переходах" (hops). Тогда этой вличины TTL может и не хватить. Однако, я в своей практике еще не встречался с компьютерами, отстоящими от меня более чем на 30 "переходов" (hops) и я не думаю, что вам придется увеличивать значение этой переменной.

Увеличение TTL пакета до 255 может иметь свои негативные последствия. Если представить себе, что где-то произошел сбой в 2-х маршрутизаторах и пакет "зациклился" между ними, тогда пакет начнет "бегать" туда-сюда между маршрутизаторами, поглощая пропускную способность канала, до тех пор, пока TTL пакета не истечет. Как правило, величину TTL не устанавливают больше 100.


3.1.3. ip_dynaddr

Переменная используется для разрешения некоторых проблем, связанных с динамической адресацией. Позволяет демону diald одновременно устанавливать соединение и изменять исходящий адрес в пакетах (и сокетах для локальных процессов). Эта возможность была реализованв для поддержки TCP по коммутируемым соединениям и соединениям с маскарадингом (masqueradig). Эта опция позволяет "маскарадить" исходящий адрес пакета при изменении динамического IP-адреса.

В переменную можно записать одно из 3-х значений: 0, 1 или 2.

  • 0 -- опция выключена, это значение по-умолчанию.

  • 1 -- опция включена.

  • Любое другое значение, отличающееся от 0 и 1 подразумевает включение этой опции в "многословном" (verbose) режиме, что приводит к записи в системный журнал отладочных сообщений.

Что происходит, если изменяется адрес исходящего интерфейса при включенной опции ip_dynaddr:

  • Исходящий адрес пакета и сокета изменяется ПРИ ПОВТОРНОЙ ПЕРЕДАЧЕ, когда он находится в состоянии SYN_SENT. Это касается локальных процессов.

  • Для транзитных пакетов -- исходящий адрес пакета изменяется на выходе, когда внутренний хост выполняет ПОВТОРНУЮ ПЕРЕДАЧУ, пока не будет принят внешний пакет.

Эта опция особенно полезна для случаев автодозвона, когда в момент установления связи исходящий адрес еще не известен. Любой запрос на соединение заставляет diald "поднять" исходящий интерфейс, после чего пакеты отправляются через него. Это означает, что нет необходимости сначала выдавать запрос который "поднимет" исходящий интерфейс, а затем выдавать "реальный" запрос на соединение, вместо этого мы просто устанавливаем соединение.


3.1.4. ip_forward

Включает/отключает функцию форвардинга (передачу транзитных пакетов между сетевыми интерфейсами), которая позволяет компьютеру выступать в роли брандмауэра или маршрутизатора. Эта переменная очень важна для Network Address Translation (Трансляция Сетевых Адресов), брандмауэров, маршрутизаторов и всего того, что должно передавать пакеты между сетями.

Это булева переменная. Или, другими словами, она может принимать два значения -- 0 или 1. Значение по-умолчанию -- 0, "запрещено". То есть 0 означает запрет форвардинга, а 1 -- разрешает его.

Замечу, что это очень специфичная переменная, поскольку изменение ее влечет за собой установку всех настроек в значения по-умолчанию (я, у себя в системе на ядре 2.4.20, не заметил этой особенности. прим. перев.). Полный список этих значений вы найдете в RFC1122 для хостов и RFC1812 для роутеров.


3.1.5. ip_local_port_range

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

Значения по-умолчанию зависят от имеющегося объема ОЗУ. Если установлено более чем 128 Мб, то нижняя граница будет 32768, а верхняя -- 61000. При меньшем объеме ОЗУ нижняя граница будет 1024 а верхняя -- 4999 или даже меньше.

Этот диапазон определяет количество активных соединений, которые могут быть запущены одновременно, с другой системой, которая не поддерживает TCP-расширение timestamp.

Диапазона 1024-4999 вполне достаточно для установки до 2000 соединений в секунду с системами, не поддерживающими timestamp. Проще говоря, этого вполне достаточно для большинства применений.


3.1.6. ip_no_pmtu_disc

Переменная ip_no_pmtu_disc запрещает поиск PMTU (от англ. Path Maximum Transfer Unit -- Максимальный Размер Пакета для выбранного Пути). Для большинства случаев лучше установить в эту переменную значение FALSE, или 0 (т.е. система будет пытаться определить максимальный размер пакета, при котором не потребуется выполнять их фрагментацию, для передачи на заданный хост). Но иногда, в отдельных случаях, такое поведение системы может приводить к "срывам" соединений. Если у вас возникают такие проблемы, то вам следует попробовать отключить эту опцию (т.е. записать в переменную число 1) и установить нужное значение MTU.

Хочу обратить ваше внимание на то, что MTU и PMTU -- это не одно и то же! MTU -- (от англ. Maximum Transfer Unit -- максимальный размер пакета) определяет максимальный размер пакета для наших сетевых интерфейсов, но не для сетевых интерфейсов на другом конце. PMTU -- опция, которая заставляет систему вычислять максимальный размер пакета, при котором не потребуется фрагментация пакетов, для маршрута к заданному хосту, включая все промежуточные переходы.

Значение по-умолчанию -- FALSE (0), т.е. функция определения разрешена. Если записать число 1 в эту переменную, то функция определения PMTU будет запрещена. Переменная ip_no_pmtu_disc может принимать значение 0 или 1.


3.1.7. ip_nonlocal_bind

Установка этой переменной позволяет отдельным локальным процессам выступать от имени внешнего (чужого) IP адреса. Это может оказаться полезным в некоторых случаях, когда необходимо "прослушивать" внешние (чужие) IP адреса, например -- сниффинг чужого траффика. Однако, эта опция может оказывать отрицательное влияние на работоспособность отдельных приложений.

Эта переменная может иметь два значения -- 0 или 1. Если установлено значение 0, то опция отключена, 1 -- включена. Значение по-умолчанию -- 0.


3.1.8. ipfrag_high_thresh

Переменная задает максимальный объем памяти, выделяемый под очередь фрагментированных пакетов. Когда длина очереди достигает этого порога, то обработчик фрагментов будет отвергать все фрагментированные пакеты до тех пор, пока длина очереди не уменьшится до значения переменной ipfrag_low_thresh. Это означает, что все отвергнутые фрагментированные пакеты должны быть повторно переданы узлом-отправителем.

Пакеты фрагментируются в том случае, если их размер слишком велик, чтобы быть переданными по данному каналу. Узел-отправитель, в этом случае, "режет" пакеты на более мелкие части и затем передает их одну за другой. На узле-получателе эти фрагменты опять собираются в полноценный пакет. Примечательно, что идея фрагментации пакетов, сама по себе, вещь замечательная, но, к сожалению, может быть использована в весьма неблаговидных целях.

Переменная содержит целое число в диапазоне 0 .. 2147483647 и означает верхний порог длины очереди фрагментов в байтах. Значение по-умолчанию -- 262144 байт, или 256 Кб. Этого количества, как правило, вполне достаточно даже для самых крайних случаев.


3.1.9. ipfrag_low_thresh

Эта переменная очень тесно связана с переменной ipfrag_high_thresh. Она устанавливает нижний порог, при достижении которого опять разрешается прием фрагментов в очередь. Обработчик фрагментов имеет свою очередь, в которой находятся фрагментированные пакеты, ожидающие сборки. Когда длина очереди достигает верхнего порога (ipfrag_high_thresh), то прием фрагментов в очередь приостанавливается до тех пор, пока длина очереди не уменьшится до величины ipfrag_low_thresh. Это предохраняет систему от "затопления" фрагментированными пакетами и, тем самым, является, в своем роде, защитой от некоторых видов DoS-атак.

Переменная содержит целое число в диапазоне 0 .. 2147483647 и означает нижний порог длины очереди фрагментов в байтах, по достижении которого, фрагментированные пакеты снова будут приниматься в очередь. Значение по-умолчанию -- 196608 байт, или 192 Кб. Это число обязательно должно быть меньше, чем ipfrag_high_thresh.


3.1.10. ipfrag_time

Эта переменная определяет максимальное время "хранения" фрагментов в секундах. Это относится только к тем фрагментам, которые пока невозможно собрать, поскольку собранные пакеты к этому сроку скорее всего уже будут переданы дальше (на следующий уровень или в сеть).

Переменная принимает целое значение и определяет предельное время хранения фрагментов в секундах. Если записать туда число 5, то это будет означать 5 секунд.


3.2. Inet peer storage

Под термином "inet peer storage" понимается "хранилище" информации, имеющей отношение к определенными узлами сети. Однако, сюда помещаются только те данные, которые предполагают длительное хранение и данные, не связанные с маршрутизацией. Это означает, что она содержит информацию только о поле ID следующего исходящего пакета. В этом разделе есть несколько переменных, которые управляют поведением хранения этой информации, главным образом, переменные управляют периодичностью "сборки мусора" и сроком хранения данных.


3.2.1. inet_peer_gc_maxtime

Переменная inet_peer_gc_maxtime определяет частоту "сборки мусора" при незначительном объеме данных. Эта переменная имеет то же предназначение, что и inet_peer_gc_mintime, только выбор, какой переменной пользоваться, производится в зависимости от величины нагрузки на систему. Значение переменной измеряется в так называемых "тиках" (jiffies), понятие "тика" подробно объясняется в приложении A.

Переменная принимает целое число, измеряемое в "тиках". Значение по-умолчанию -- 120 "тиков", чего вполне достаточно для большинства серверов и рабочих станций.


3.2.2. inet_peer_gc_mintime

Переменная inet_peer_gc_mintime устанавливает минимальное время между проходами "сборщика мусора" при значительном объеме данных, хранящихся в "inet peer storage". Когда система находится под тяжелыми нагрузками и появляется множество факторов, ограничивающих размер пула памяти, то частота "сборки мусора" определяется этой переменной. Значение переменной измеряется в так называемых "тиках" (jiffies), понятие "тика" подробно объясняется в приложении A.

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


3.2.3. inet_peer_maxttl

Это максимальное время хранения записей. При незначительных нагрузках на систему неиспользуемые записи будут удаляться через данный промежуток времени.

Значение переменной измеряется в так называемых "тиках" (jiffies), понятие "тика" подробно объясняется в приложении A.


3.2.4. inet_peer_minttl

Переменная определяет минимальное время хранения данных в "inet peer storage". Это время должно быть достаточно большим, чтобы перекрыть время сборки фрагментов на противоположной стороне. Минимальное время хранения является гарантией того, что размер пула будет меньше чем величина inet_peer_threshold.

Значение переменной измеряется в так называемых "тиках" (jiffies), понятие "тика" подробно объясняется в приложении A.


3.2.5. inet_peer_threshold

Эта переменная хранит приблизительный размер памяти для "inet peer storage". Когда размер пула достигает этой величины, то "сборщик мусора" переводится в более агрессивный режим работы -- с периодом прохода inet_peer_gc_mintime. Кроме того, этот порог влияет на срок хранения записей. Чем выше этот порог, тем больше срок хранения.

Эта переменная принимает целое число, значание по-умолчанию -- 65664 байт.


3.3. Переменные TCP

Здесь будут кратко рассмотрены переменные, ответственные за настройку TCP. Обычно эти параметры не требуют дополнительной настройки, поскольку имеют вполне разумные установки по-умолчанию и, скорее всего, вам едва ли придется менять здесь что-либо, так утверждают вполне авторитетные разработчики! Здесь в основном приводятся описания из их уст, для тех, кому это интересно.


3.3.1. tcp_abort_on_overflow

Эта переменная заставляет ядро отвергать новые соединения, если их поступает такое количество, что система не в состоянии справиться с таким потоком. Что это означает? Допустим, что на систему обрушивается шквал запросов на соединение, тогда они могут быть просто отвергнуты, если переменная будет включена, поскольку система не в состоянии обработать их все. Если переменная не установлена, то система будет пытаться обслужить все запросы.

Переменная может иметь два значение -- 0(выключено) или 1(включено). Значение по-умолчанию -- 0. Включение этой опции следует расценивать как крайнюю меру. Перед этим необходимо попытаться поднять производительность сервисов.


3.3.2. tcp_adv_win_scale

Эта переменная влияет на вычисление объема памяти в буфере сокета, выделяемой под размер TCP-окна и под буфер приложения. Если величина tcp_adv_win_scale отрицательная, то для вычисления размера используется следующее выражение:

Где bytes -- это размер окна в байтах. Если величина tcp_adv_win_scale положительная, то для определения размера используется следующее выражение:

Переменная принимает целое значение. Значение по-умолчанию -- 2, т.е. под буфер приложения отводится 1/4 часть объема, определяемого переменной tcp_rmem.


3.3.3. tcp_app_win

Эта переменная определяет количество байт, резервируемых под TCP-окно в приемном буфере сокета. Выражение, согласно которому делается расчет, выглядит следующим образом:

Как видно из выражения -- чем больше значение переменной, тем меньше будет размер буфера окна. Исключение составляет значение 0. В этом случае резервирование не производится. Значение по-умолчанию -- 31. Не изменяйте эту переменную, если вы не уверены в том, что делаете.


3.3.4. tcp_dsack

Эта опция необходима для выполнения передачи дублирующих SACK-пакетов (от англ. Selective ACKnowledgement -- Выборочное Подтверждение Приема, прим. перев.). Техника выборочного подтверждения кратко описана в разделе, посвященном переменной tcp_sack. Детальное описание можно найти в RFC 2883. Здесь подробно описываются действия по обработке ситуаций, когда получен дубликат пакета, пришедшего ранее, или когда пакеты поступают не в той очередности. D-SACK -- это расширение стандарта SACK и используется для уведомления хоста-отправителя о том, что пакет был получен дважды (т.е. продублирован). Эту информацию хост-отправитель может использовать для корректировки сетевых настроек и т.п.. Эта опция гарантирует 100%-ную обратную совместимость с устаревшими реализациями TCP, если в них техника SACK не реализована каким-либо нестандартным образом. Но это чрезвычайно редкий случай, а посему -- у вас едва ли будут возникать проблемы с этим.

Переменная может иметь два состояния -- 1 (включено) и 0 (выключено). Значение по-умолчанию -- 1 (включено). И, само собой разумеется, установка этой переменной имеет смысл только если включена переменная tcp_sack, поскольку tcp_dsack очень тесно связана с ней. В большинстве случаев разумным будет оставить переменную включенной.


3.3.5. tcp_ecn

Переменная tcp_ecn отвечает за работу Explicit Congestion Notification (Явное Уведомление о Перегруженности) в TCP-соединениях. Используется для уведомления о возникновении "затора" на маршруте к заданному хосту или сети. Может использоваться для извещения хоста-отправителя о необходимости снизить скорость передачи пакетов через конкретный маршрутизатор или брандмауэр. Explicit Congestion Notification (ECN) детально описано в RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP. Дополнительную информацию о ECN вы найдете в RFC 2884 - Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks.

Коротко: этот документ подробно описывает как должно передаваться уведомление о перегруженности хосту-отправителю, который, в свою очередь, может выбрать другой маршрут или начать снижать скорость передачи до тех пор, пока к нему не перестанут поступать ECN-пакеты.

Caution

В Интернете еще встречаются маршрутизаторы и брандмауэры, которые не пропускают пакеты с установленным флагом ECN и, если вам не повезет, то вы можете столкнуться с ними. При возникновении проблем с прохождением ECN -- попробуйте отключить эту опцию. Если вам встретится подобный маршрутизатор, то можете попробовать вступить в контакт с администратором и предупредить его об имеющихся проблемах. Подробное описание проблемы и общий список аппаратуры, являющейся причиной этой неприятности, вы найдете в приложении Ссылки в пункте ECN-under-Linux Unofficial Vendor Support Page.

Переменная может иметь два состояния -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.3.6. tcp_fack

Переменная tcp_fack ответственна за систему Forward Acknowledgement (Упреждающее Подтверждение) в Linux. Forward Acknowledgement -- это специальный алгоритм, который работает поверх SACK, и предназначен для контроля "заторов".

Главная идея алгоритма FACK состоит в отслеживании наибольшего номера выборочно подтвержденной последовательности как признака того, что все предыдущие не подтвержденные (выборочно) сегменты были потеряны. Это позволяет оптимизировать восстановление потерь. Однако, этот алгоритм становится неработоспособным в случае неупорядоченного потока данных, тогда он (алгоритм) автоматически отключается для данного конкретного соединения.

Изначально алгоритм FACK был разработан Мэттью Матисом (Matthew Mathis) с соавторами. Документ, описывающий алгоритм, можно найти на http://www.psc.edu/~mathis/.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Эта опция используется только тогда, когда включена переменная tcp_sack.


3.3.7. tcp_fin_timeout

Переменная задает максимальное время пребывания сокета в состоянии FIN-WAIT-2. Используется в тех случаях, когда другая сторона по тем или иным причинам не закрыла соединение со своей стороны. Каждый сокет занимает в памяти порядка 1.5 Кб, что может привести к значительным утечкам памяти в некоторых случаях.

Переменная принимает целое число. Значение по-умолчанию -- 60 секунд. В ядрах серии 2.2 это значение было равно 180 секундам, но было уменьшено, поскольку иногда возникали проблемы, связанные с нехваткой памяти, на web-серверах, которые, как правило, обслуживают огромное количество подключений.

За дополнительной информацией -- обращайтесь к описанию переменных tcp_max_orphans и tcp_orphan_retries.


3.3.8. tcp_keepalive_intvl

Переменная определяет интервал проверки "жизнеспособность" сокета. Это значение учитывается при подсчете времени, которое должно пройти перед тем как соединение будет разорвано.

Переменная принимает целое число. Значение по-умолчанию -- 75 секунд. Это достаточно высокое значение, чтобы рассматривать его как нормальное. Значения переменных tcp_keepalive_probes и tcp_keepalive_intvl могут использоваться для определения времени, через которое соединение будет разорвано.

Со значениями по-умолчанию (9 попыток с интервалом 75 секунд) это займет примерно 11 минут. Попытки определения "жизнеспособности", в свою очередь, начнутся через 2 часа после того, как через данное соединение проследовал последний пакет.


3.3.9. tcp_keepalive_probes

Переменная определяет количество попыток проверки "жизнеспособности" прежде, чем будет принято решении о разрыве соединения.

Переменная принимает целое число, которое не следует устанавливать больше 50-ти. Значение по-умолчанию -- 9. Это означает, что будет выполнено 9 попыток проверки соединения, чтобы убедиться в том, что соединение разорвано.


3.3.10. tcp_keepalive_time

Переменная определяет как часто следует проверять соединение, если оно давно не используется. Значение переменной имеет смысл только для тех сокетов, которые были созданы с флагом SO_KEEPALIVE.

Переменная принимает целое число секунд. Значение по-умолчанию -- 7200 секунд, или 2 часа. Не уменьшайте это число без необходимости, поскольку это может привести к увеличению излишнего трафика.


3.3.11. tcp_max_orphans

Переменная задает максимальное число "осиротевших" (не связанных ни с одним процессом) сокетов. Если это число будет превышено, то такие соединения разрываются, а в системный журнал пишется предупреждение.

Это ограничение существует исключительно ради предотвращения простейших разновидностей DoS-атак. Вообще вы не должны полагаться на эту переменную! Не рекомендуется уменьшать это число. Сетевая среда может потребовать увеличение этого порога, однако, такое увеличение может привести к необходимости увеличения объема ОЗУ в системе. Прежде чем поднимать этот предел -- попробуйте перенастроить сетевые сервисы на более агрессивное поведение по отношению к "осиротевшим" сокетам.

Переменная принимает целое число. Значение по-умолчанию -- 8192, однако оно очень сильно зависит от объема памяти в системе. Каждый "осиротевший" сокет "съедает" примерно 64 Кб памяти, которая не может быть сброшена в своп (swap).

Note

При возникновении проблем, связанных с этим ограничением -- в системный журнал будет записано сообщение, подобное этому:

TCP: too many of orphaned sockets

Это может служить поводом к тому, чтобы пересмотреть значения переменных tcp_fin_timeout или tcp_orphans_retries.


3.3.12. tcp_max_syn_backlog

Переменная определяет максимальное время хранения SYN-запросов в памяти до момента получения третьего, завершающего установление соединения, пакета. Эта опция работает только тогда, когда включена переменная tcp_syncookies. Если сервер испытывает серьезные нагрузки, то можно попробовать немного увеличить этот параметр.

Переменная принимает целое число. Значение по-умолчанию зависит от количества памяти, имеющейся в системе. Если объем памяти менее 128 Мб, то значение по-умолчанию равно 128, если больше, то значение по-умолчанию равно 1024.

Caution

Если вы увеличиваете эту переменную до величины более чем 1024, то было бы неплохо изменить величину TCP_SYNQ_HSIZE и пересобрать ядро. TCP_SYNQ_HSIZE находится в файле linux/include/tcp.h. Эта величина рассчитывается по формуле:

TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog


3.3.13. tcp_max_tw_buckets

Максимальное число сокетов, находящихся в состоянии TIME-WAIT одновременно. При превышении этого порога -- "лишний" сокет разрушается и пишется сообщение в системный журнал. Цель этой переменной -- предотвращение простейших разновидностей DoS-атак.

Переменная принимает целое число. Значение по-умолчанию -- 180000. На первый взгляд может показаться, что это очень много, но на самом деле это не так. Если у вас начинают возникать ошибки, связанные с этим параметром, то попробуйте увеличить его.

Caution

Вам не следует уменьшать значение этой переменной. Вместо этого, если начали поступать сообщения в системный журнал, ее следует увеличить, однако, это может потребовать наращивания памяти в системе.


3.3.14. tcp_mem

В этой переменной задаются 3 значения, определяющие объем памяти, который может быть использован стеком TCP. Значения измеряются в страницах памяти. Размер одной страницы зависит от аппаратуры и конфигурации ядра. Для архитектуры i386 размер одной страницы составляет 4Кб, или 4096 байт. Некоторые, более новые аппаратные реализации, имеют размер страницы равный 16, 32 или даже 64 Кб. Все три значения по-умолчанию рассчитываются во время загрузки.

Первое число задает нижний порог. Ниже этого порога, стек TCP вообще никак не беспокоится об управлении памятью, используемой различными TCP сокетами.

Когда объем используемой памяти достигает второго предела (числа), то TCP начинает более энергично "расталкивать" память, стремясь освободить ее как можно быстрее. Этот процесс продолжается до тех пор, пока объем использумой памяти не достигнет нижнего предела.

И последнее число -- максимальный объем памяти, который может использоваться для нужд TCP. Если используемый объем памяти достигнет этого порога, то TCP просто начинает "терять"пакеты и соединения до тех пор, пока объем используемой памяти не уменьшится.

Tip

Эта переменная может позволить несколько увеличить пропускную способность на "толстых" каналах, если должным образом настроить переменные tcp_mem, tcp_rmem и tcp_wmem. Впрочем, переменная tcp_rmem не требует особо пристального внимания, поскольку серия ядер 2.4 имеет достаточно хорошие настройки этой переменний, а вот на другие две следует взглянуть поближе. Дополнительную информацию об этом вы найдете в руководстве TCP Tuning Guide.


3.3.15. tcp_orphan_retries

Количество попыток закрыть соединение перед тем как оно будет разорвано принудительно. Если вы администрируете http-сервер, который испытывает большие нагрузки, то стоит подумать об уменьшении этого значения.

Переменная принимает целое число. Значение по-умолчанию -- 7, что соответствует, примерно, от 50 секунд до 16 минут, в зависимости от внличины Retransmission Timeout (RTO -- Таймаут для Повторной Передачи. прим. перев.). Детальное описание RTO вы найдете в разделе "3.7. Data Communication" RFC 793 - Transmission Control Protocol.

Кроме того, посмотрите описание переменной tcp_max_orphans.


3.3.16. tcp_reordering

Максимальное количество пакетов, пришедших в потоке не по-порядку, прежде чем будет сделано предположение о том, что пакет был потерян где-то на маршруте. Когда делается такое предположение, то стек TCP переходит обратно в режим "slow start" (медленный старт), поскольку пакет действительно мог быть утерян из-за перегруженности сети. Кроме того, стек TCP откажется от дальнейшего использования алгоритма FACK при обмене с этим хостом.

Переменная принимает целое число. Значение по-умолчанию -- 3. Это достаточно хорошее значение и не следует его изменять. Если этот параметр уменьшить, то это может значительно ухудшить работу сетевой подсистемы особенно, если пакеты часто переупорядочиваются.


3.3.17. tcp_retrans_collapse

Включает/выключает эмуляцию ошибки протокола TCP, делая возможным сетевое взаимодействие с некоторыми устройствами, в которых реализация стека TCP имеет эту ошибку. Без ее эмуляции было бы невозможным работать с отдельными моделями принтеров. Ошибка заключается в отправке полноразмерных пакетов при повторной передаче.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Эмуляция ошибки никак не повредит взаимодействию с другими узлами сети, но при этом позволит общаться с устройствами, имеющими ошибку в реализации стека TCP. Вообще эта опция совершенно безопасна, однако, если в журнал пишутся непонятные сообщения -- можете попробовать отключить ее.


3.3.18. tcp_retries1

Максимальное количество попыток повторной передачи пакетов по установленному соединению прежде, чем сообщение об ошибке будет передано сетевому уровню, в результате чего может быть выбран другой маршрут для отправки последующих пакетов. Минимальное значение этого параметра определяется в RFC ???? и равно 3. Это число является значением по-умолчанию, что соответствует интервалу времени от 3 секунд до 8 минут, в зависимости от величины Retransmission timeout (RTO). Детальное описание RTO вы найдете в разделе "3.7. Data Communication" RFC 793 - Transmission Control Protocol.

Переменная принимает целое число. Значение по-умолчанию -- 3. Стандарты определяют диапазон изменения этого параметра от 3 до 100.


3.3.19. tcp_retries2

Максимальное количество попыток повторной передачи пакетов, до того как соединение будет считаться разорванным. Это ограничение определено в RFC 1122 и равно 100, но обычно его уменьшают.

Переменная принимает целое число. Значение по-умолчанию -- 15, что соответствует примерно 13-30 минутам в зависимости от величины Retransmission timeout (RTO). При желании можете попробовать уменьшить этот параметр.


3.3.20. tcp_rfc1337

Переменная tcp_rfc1337 является реализацией решения проблемы, описываемой в RFC 1337 - TIME-WAIT Assassination Hazards in TCP. Проблема связана с "устаревшими" дубликатами пакетов, которые могут вносить помехи во вновь устанавливаемые соединения и порождать три различные проблемы. Первая -- "устаревший" дубликат пакета с данными может быть ошибочно воспринят в новом соединении, что приведет к передаче неверных данных. Вторая -- соединение может быть десинхронизировано и "уйти" в ACK-цикл из-за "устаревших" дубликатов, которые порождают новые соединения (здесь автор имеет ввиду "устаревшие" дубликаты SYN-пакетов, прим. перев.). И третья, и последняя проблема -- "устаревшие" дубликаты могут "проникнуть" в недавно созданное соединение и ошибочно уничтожить его.

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

Окончательное решение состоит в том, что RST-пакеты должны просто игнорироваться, пока сокет находится в состоянии TIME_WAIT. Вместе с установкой параметра Maximum Segment Life (MSL -- максимальное время жизни сегмента) равным 2 мин. такой подход решает все три проблемы, описанные в RFC 1337.


3.3.21. tcp_rmem

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

Первое число -- минимальный размер приемного буфера, который выделяется для каждого сокета. Этот размер буфера выделяется всегда, даже при очень высоких нагрузках на систему. Значение по-умолчанию -- 4096 байт, или 4 Кб. В предыдущих версиях ядра Linux это значение было 8192 байт. Это достаточно большой размер и не следует увеличивать его, иначе, при "взрывных" нагрузках на сеть, вы можете столкнуть с очень серьезными проблемами.

Второе число -- размер приемного буфера по-умолчанию, который выделяется для каждого сокета. Это значение перекрывает значение переменной /proc/sys/net/core/rmem_default, которая используется другими протоколами. Значение по-умолчанию -- 87380 байт, или 85 Кб. Совместно с переменными tcp_adv_win_scale и tcp_app_win эта переменная используется при расчете размера TCP-окна. Это значение используется при незначительных нагрузках. Как и в случае с первым значением -- не следует без особой нужды изменять этот параметр.

Tip

Эта переменная может дать некоторый прирост производительности на "толстых" каналах, если достаточно корректно используется вместе с переменными tcp_mem и tcp_wmem. tcp_rmem не требует вмешательства извне, поскольку ядра серии 2.4 достаточно хорошо настраивают ее автоматически, а вот на tcp_mem и tcp_wmem можно взглянуть попристальнее. Дополнительную информацию, по настройке переменных, вы найдете в TCP Tuning Guide.

Третье, и последнее, число -- максимально возможный размер приемного буфера, который может быть размещен для каждого сокета. Этот параметр перекрывается переменной /proc/sys/net/core/rmem_max, если значение в ipv4 оказывается больше. Перед изменением этого параметра -- вам следует сначала взглянуть на значение /proc/sys/net/core/rmem_max. Значение по-умолчанию -- удвоенное значение второго параметра, т.е. -- 87380 * 2 bytes, или 174760 байт (170 Кб). Как правило этот параметр не нуждается в корректировке.


3.3.22. tcp_sack

Разрешает Selective Acknowledgements (SACK -- Выборочное Подтверждение), детальное описание вы найдете в RFC 2883 - An Extension to Selective Acknowledgement (SACK) Option for TCP и RFC 2883 - An Extension to Selective Acknowledgement (SACK) Option for TCP.

Если эта переменная включена (установлена 1), то в TCP-заголовке будет устанавливаться SACK-флаг при передаче SYN-пакета, сообщая тем самым удаленному хосту, что наша система в состоянии обрабатывать SACK, на что удаленный хост может ответить ACK-пакетом с установленным флагом SACK. Этот режим выборочно подтверждает каждый сегмент в TCP-окне. Это особенно полезно на неустойчивых соединениях, поскольку позволяет производить повторную передачу лишь отдельных, не подтвержденных фрагментов, а не всего TCP-окна, как это диктуется более старыми стандартами. Если какой либо сегмент TCP-окна был "утерян", то приемная сторона не пришлет на него SACK-подтверждение о приеме. Отправитель, поняв это, повторит передачу "потерявшихся" сегментов. Избыточные данные сохраняются в TCP-заголовке, 40 байт на сегмент. Подтверждение каждого сегмента -- это два 32-битных беззнаковых целых числа, таким образом в заголовке может разместиться подтверждение 4-х сегментов. Однако, как правило, совместно с опцией SACK используется опция timestamp, которая занимает 10 байт и поэтому в одном пакете может быть подтверждено не более 3 сегментов.

Рекомендуется включать эту опцию, если вы имеете неустойчивые соединения. Однако, если вы соединены 1.5-метровым кабелем с другой машиной, то в таком случае, для достижения наивысшей скорости обмена, следует эту опцию отключить. Обычно эта опция не нужна, но лучше ее включить. Она обеспечивает 100% обратную совместимость, т.е. вы не должны испытывать никаких проблем при соединении с хостами, которые эту опцию не поддерживают.

В переменную могут быть записаны два числа -- 0 (выключено) и 1 (включено). Значение по-умолчанию --1 (включено).


3.3.23. tcp_stdurg

Разрешает/запрещает соответствие стандарту RFC 1122. Поведение по-умолчанию соответствует стандарту использования флага URG -- BSD 4.2, описанному в RFC 793. Если эта переменная включена, то возможны сбои при работе с отдельными узлами Интернета, точнее -- с узлами, которые придерживаются стандарта BSD 4.2. За дополнительной информацией обращайтесь к RFC 1122 - Requirements for Internet Hosts -- Communication Layers секция "4.2.2.4 Urgent Pointer: RFC 793 Section 3.1 explanation", где имеется ссылка на RFC 793 - Transmission Control Protocol.

Переменная принимает два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.3.24. tcp_syn_retries

Количество попыток передачи SYN-пакета при установлении нового соединения.

Переменная принимает целое число, которое не должно устанавливаться больше чем 255, поскольку каждая повторная попытка отнимает значительное время. На каждую попытку отводится примерно 30-40 секунд. Значение по-умолчанию -- 5, что соответствует, примерно, 180 секундам.


3.3.25. tcp_synack_retries

Количество попыток передачи SYN,ACK-пакета в ответ на SYN-запрос. Другими словами -- максимальное число попыток установить пассивное TCP-соединение, инициированное другим хостом.

Переменная принимает целое число, которое не должно устанавливаться больше чем 255 по тем же причинам, что и в случае с переменной tcp_syn_retries. Значение по-умолчанию -- 5.


3.3.26. tcp_syncookies

Разрешает/запрещает передачу так называемых syncookies вызывающему хосту в случае переполнения очереди SYN-пакетов для заданного сокета. Когда в систему поступает слишком много запросов на соединение, то очередь может переполниться и тогда запускается передача syncookies в ответ на каждый SYN-запрос.

Эта переменная используется для предотвращения syn-flood атак. Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).

Эта функция будет работать только в том случае, если ядро собрано с опцией CONFIG_SYN_COOKIES. (прим. перев.)

Caution

В прошлом было много дискуссий по поводу проблем и недостатков, связанных с syncookies. Лично я рассматриваю эту возможность как достаточно удобную и безопасную. Однако, в некоторых случаях, использование этой опции может представлять некоторую угрозу, см. ниже.

Опция tcp_syncookies подразумевает, что на системах с высокой нагрузкой новые соединения будут устаналиваться без таких "фишек", как ECN и SACK. Если передача syncookies срабатывет при невысоких нагрузках, то вам следует подкорректировать параметр, задающий длину очереди.

Не следует использовать эту возможность на системах с высокой нагрузкой. Если в системный журнал поступают предупреждения о syn flood для вполне законных соединений, то можете попробовать подстроить переменные tcp_max_syn_backlog, tcp_synack_retries и tcp_abort_on_overflow.


3.3.27. tcp_timestamps

Разрешает/запрещает использование временных меток (timestamps), в соответствии с RFC 1323. Если коротко, то это расширение TCP используется для расчета Round Trip Measurement (определение времени возврата) лучшим способом, нежели метод Retransmission timeout (RTO). Эта опция должна сохранять обратную совместимость в большинстве случаев, так что лучше оставить ее включенной, особенно если вы работаете в высокоскоростной сети (например LAN или 10mb Интернет). В случае низкоскоростного оединения (скажем модемное) -- вы прекрасно обойдетесь и без этой опции, и будет даже лучше, если вы ее отключите.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено).

Более подробную информацию вы найдете в секции 4 документа RFC 1323 - TCP Extensions for High Performance.


3.3.28. tcp_tw_recycle

Разрешает/запрещает быструю утилизацию сокетов, находящихся в состоянии TIME-WAIT. Если вы не уверены в своих действиях, то вам лучше не трогать эту переменную.

Переменная принимает целое число (а не булевское -- из моего опыта и моего понимания исходных текстов ядра следует, что описание переменной в linux/Documentation/ip-sysctl.txt содержит ошибку, если я не ошибаюсь). Значение по-умолчанию -- 0.

Caution

Не изменяйте эту переменную, если вы не уверены в своих действиях или не получили совет от опытных экспертов по ядру.


3.3.29. tcp_window_scaling

Разрешает/запрещает масштабирование TCP-окна, как определено в RFC 1323. В этом документе описано как производится масштабирование TCP-окна при передаче по Large Fat Pipes (LFP -- "толстый" канал). При передаче TCP-пакетов по "толстым" каналам возникают существенные потери пропускной способности из-за того, что они не загружены полностью во время ожидания подтверждения о приеме предыдущего TCP-окна. Основная проблема состоит в том, что окно не может иметь размер больше, чем 2**16 байт (65 Кб). Разрешая масштабирование TCP-окна мы, тем самым, можем увеличить его размер и таким образом уменьшить потери пропускной способности.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено).

Дополнительную информацию по этой теме вы найдете в RFC 1323 - TCP Extensions for High Performance.


3.3.30. tcp_wmem

Переменная содержит три числа, которые используются при управлении размерами буферов передачи, выделяемых для каждого сокета. Каждое из значений используется при определенных условиях.

Первое значение -- минимальный размер буфера передачи для каждого сокета. Системой гарантируется выделение этого пространства при открытии сокета. Обычно это значение равно 4096 байт.

Второе значение -- размер передающего буфера по-умолчанию. При попытке увеличить размер буфера передачи больше этого ограничения, приложение может столкнуться с "нежеланием" системы выделения большего объема памяти при тяжелых нагрузках. Это может даже привести к потере пакетов при очень высоких нагрузках. Значение по-умолчанию -- 16384 байт, или 16 Кб. Будет неразумным попытаться увеличить это значение. Этот параметр перекрывается переменной /proc/sys/net/core/wmem_default, которая используется другими протоколами и, как правило, tcp_wmem должна быть меньше чем /proc/sys/net/core/wmem_default.

Третье значение -- максимальный размер буфера передачи для отдельного сокета. По-умолчанию -- 131072 байт, или 128 Кб. Это достаточно разумное значение и в большинстве случаев вам едва ли придется корректировать его. Однако, если вам придется его увеличивать -- помните о существовании переменной /proc/sys/net/core/wmem_max, которая должна быть всегда больше чем tcp_wmem.

Tip

Эта переменная может дать некоторый прирост производительности на "толстых" каналах, если достаточно корректно используется вместе с переменными tcp_mem и tcp_rmem. tcp_wmem дает наибольший прирост производительности из этих трех переменных. Замечу при этом, что вы практически не получите никакого выигрыша в сетях со скоростью передачи менее 1 Гб. Дополнительную информацию, по настройке переменных, вы найдете в TCP Tuning Guide.


3.4. Переменные ICMP

Эти переменные управляют поведением протокола ICMP. Они достаточно просты и их понимание не должно вызывать затруднений, которые могут возникнуть при изучении TCP-переменных. Главным образом они отвечают за реакцию ядра на различные типы ICMP-сообщений.


3.4.1. icmp_echo_ignore_all

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено). Если в переменную записана 1, то ядро просто игнорирует все ICMP Echo запросы и тогда никто не сможет ping-нуть вашу машину, чтобы проверить ее наличие в сети, что само по себе не есть хорошо. Однако, у каждого из нас может быть свое собственное мнение по поводу этой опции. С одной стороны -- окружающие лишены возможности проверить ваше присутствие в сети, с другой -- существует масса приложений, которые используют ICMP Echo запросы далеко не в благовидных целях. Вобщем все как всегда -- что-то плохо, а что-то хорошо.


3.4.2. icmp_echo_ignore_broadcasts

Эта переменная очень близка по смыслу к icmp_echo_ignore_all, только в данном случае будут игнорироваться ICMP сообщения, отправленные на широковещательный или групповой адрес. Вполне очевидно, почему полезно включить этот параметр -- защита от smurf атак.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.4.3. icmp_ignore_bogus_error_responses

Отдельные маршрутизаторы, вопреки стандартам, описанным в RFC 1122, отправляют фиктивные ответы в широковещательном диапазоне. Обычно эти ошибки заносятся в системный журнал. Если вы не желаете регистрировать их, то включите этот параметр и тем самым сбережете некоторый объем дискового пространства в своей системе.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.4.4. icmp_ratelimit

Максимальная частота генерации ICMP-пакетов с типом, указанным в icmp_ratemask (см. icmp_ratemask). Это значение задается в "тиках" и устанавливает временной интервал между ICMP-посылками. Таким образом, значение 0 означает отсутствие ограничений. Обычно 1 "тик" равен 0.01 секунды, так значение 1 в этой переменной ограничивает скорость передачи не более 100 посылок в секунду, а значение 100 -- не более 1 посылки в секунду.

Значение по-умолчанию -- 100, что означает не более 1 ICMP посылки за интервал в 100 "тиков".


3.4.5. icmp_ratemask

Маска ICMP типов, на которые накладывается ограничение по частоте генерации переменной icmp_ratelimit. Каждый из ICMP типов маскируется своим битом.

icmp_ratemask -- это битовая маска, где каждый ICMP тип представлен своим битом. Соответствие между символическим названием ICMP типа и его порядковым номером вы найдете в заголовочном файле netinet/ip_icmp.h (обычно это /usr/include/netinet/ip_icmp.h). За дополнительной информацией обращайтесь к RFC 792 - Internet Control Message Protocol. Математически маска определяется так:

где n принимает значения всех типов ICMP, которые должны быть ограничены.

Например: Ограничим передачу ICMP Destination Unreachable сообщений. В /usr/include/netinet/ip_icmp.h этому типу соответствует число 3. Подсчитаем значение 2**3, что равно 8. Теперь нужно прибавить это число к имеющейся битовой маске. Допустим, что маска уже равна числу 6160 (в двоичном виде 0001100000010000), тогда результирующая маска получится: 6160 + 8 = 6168 (в двоичном виде 0001100000011000).

Caution

Перед добавлением маски подобным образом убедитесь сначала, что нужный вам бит сброшен, иначе вы получите неверную маску! К примеру, если у вас маска является числом 256 и вы еще добавите число 256, то это приведет к размаскированию ICMP Echo Request и маскировке 9-го отсутствующего типа ICMP.

Значение по-умолчанию -- 6168 (в двоичном виде 0001100000011000), что подразумевает наложение ограничений на ICMP Destination Unreachable, ICMP Source Quench, ICMP Time Exceeded и ICMP Parameter Problem, где ICMP Destination Unreachable = 3, ICMP Source Quench = 4, ICMP Time Exceeded = 11 и ICMP Parameter Problem = 12. Таким образом, значение по-умолчанию соответствует выражению:

Note

Злоумышленник может "заставить" некоторый маршрутизатор или хост "затопить" жертву ICMP-посылками, передаваемыми в ответ на поддельный ICMP пакет с обратным адресом жертвы. Поэтому очень важно ограничить частоту генерации отдельных видов ICMP-сообщений.

Tip

На сайте http://www.frozentux.net вы сможете найти небольшую программу ratemask, которая может оказаться полезной при создании маски для переменной icmp_ratemasks или для дешифрации существующей маски.


3.4.6. igmp_max_memberships

Максимальное число групп на каждый сокет. Значение по-умолчанию -- 20 и может быть изменено по мере необходимости.

Fixme: NEED MORE DETAILS!!!


3.5. Переменные в каталоге conf/

Каталог /proc/sys/nrt/ipv4/conf содержит несколько подкаталогов, которые в свою очередь содержат ряд настроек, которые могут быть изменены. Если вы посмотрите на содержимое каталога conf/, то увидите, что здесь находятся подкаталоги с именами, соответствующими названиям существующих в системе сетевых интерфейсов, например: eth0, tr0 или lo. Кроме того, здесь же вы найдете каталоги all и default. Содержимое каталога conf/ выглядит примерно так:

root@firewall:/proc/sys/net/ipv4/conf# ls -l
total 0
dr-xr-xr-x    2 root     root            0 May  1 20:04 all/
dr-xr-xr-x    2 root     root            0 May  1 20:04 default/
dr-xr-xr-x    2 root     root            0 May  1 20:04 eth0/
dr-xr-xr-x    2 root     root            0 May  1 20:04 eth1/
dr-xr-xr-x    2 root     root            0 May  1 20:04 eth2/
dr-xr-xr-x    2 root     root            0 May  1 20:04 eth3/
dr-xr-xr-x    2 root     root            0 May  1 20:04 lo/
root@firewall:/proc/sys/net/ipv4/conf#
  

В данном случае, в системе имеется 4 различных сетевых интерфейса (eth0-3) и один локальный (lo) интерфейс. Практически в любой UNIX-подобной ОС присутствует интерфейс lo, поскольку он является составной частью сетевой подсистемы.


3.5.1. Различия между conf/DEV/, conf/all/ и conf/default/

Каталог /conf/DEV/, где под DEV следует понимать название того или иного устройства, содержит настройки для конкретного сетевого интерфейса. Настройки из каталога conf/all/ применяются ко ВСЕМ сетевым интерфейсам.

И наконец каталог conf/default/ содержит значения по-умолчанию. Они не влияют на настройки существующих интерфейсов, но используются для первоначальной настройки вновь устанавливаемых устройств.


3.5.2. accept_redirects

Переменная управляет приемом ICMP-сообщений о переадресации. Сообщения ICMP Redirect ... используются для уведомления маршрутизаторов или хостов о существовании лучшего маршрута движения пакетов к заданному хосту, который (маршрут) может быть быстрее или менее загружен.

Переменная может иметь два значения -- 0 (выключено -- сообщения о переадресации игнорируются) и 1 (включено -- сообщения о переадресации принимаются). Значение по-умолчанию -- 1 (включено), однако я посоветовал бы отключать эту опцию, поскольку она далеко небезопасна. В подавляющем большинстве случаев необходимость в переадресации отсутствует, поэтому лучше держать эту переменную выключенной, если конечно вы на 100% не уверены в обратном.


3.5.3. accept_source_route

Переменная разрешает/запрещает "маршрутизацию от источника". Маршрутизация от источника весьма небезопасна. Дополнительную информацию по этой темы вы сможете почерпнуть из ip-param.txt.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено).


3.5.4. arp_filter

Включает/выключает связывание IP-адреса с ARP-адресом. Если эта опция включена, то ответ будет передаваться через тот интерфейс, через который поступил запрос. В принципе, было бы не плохо, если бы ответы исходили через тот же интерфейс, через который был получен запрос, однако, в отдельных случаях, это может стать причиной ошибок.

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

Tip

Дополнительную информацию по данной тематике вы найдете в Guide to IP Layer Network Administration with Linux.


3.5.5. bootp_relay

Переменная разрешает/запрещает форвардинг пакетов с исходящими адресами 0.b.c.d. Демон BOOTP relay должен перенаправлять эти пакеты на корректный адрес.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).

Caution

Обработка переменной bootp_relay еще не реализована. Если вы желаете предложить свою реализацию -- милости просим! С этой целью можете вступить в контакт с командой разработчиков netdev mailinglist.


3.5.6. forwarding

Включает/отключает функцию форвардинга (передачу транзитных пакетов) между сетевыми интерфейсами. Переменные conf/DEV/forwarding могут использоваться для включения/выключения функции форвардинга для отдельных интерфейсов. Переменная может иметь два значения -- 0 (выключено) и 1 (включено). По-умолчанию все переменные conf/DEV/forwarding принимают значение равное ipv4/ip_forward так, если эту переменную включить, то и все переменные conf/DEV/forwarding будут включены, если ее выключить, то и переменные conf/DEV/forwarding окажутся выключены.


3.5.7. log_martians

Переменная включает/выключает функцию журналирования всех пакетов, которые содержат неправильные (невозможные) адреса (так называемые martians -- "марсианские" пакеты). Под невозможными адресами, в данном случае, следует понимать такие адреса, которые отсутствуют в таблице маршрутизации.

Caution

В некоторых ситуациях эта опция позволит получить дополнительную информацию, но вы должны понимать, что эта информация не так подробна как можно было бы подумать. Основными причинами, порождающими записи в системном журнале, могут быть: невозможность переадресации; плохая классификация; ограничения на широковещательные сообщения, или несоответствия в Forwarding Information Base (FIB).

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.5.8. mc_forwarding

Включает/выключает поддержку маршрутизации групповых рассылок для заданного интерфейса. Кроме того, чтобы иметь поддержку маршрутизации групповых рассылок, необходимо собрать ядро с включенной опцией CONFIG_MROUTE. Дополнительно в системе должен иметься демон, осуществляющий групповую маршрутизацию. Его вы можете получить с FTP-сайта AT&T Research.. Этот демон реализует протокол DVMRP (от англ. Distance Vector Multicast Routing Protocol -- протокол маршрутизации групповых рассылок типа "вектор-расстояние"). Еще один демон маршрутизации групповых рассылок доступен на сайте PIMd. Это реализация "разреженного" протокола PIM (от англ. Protocol Independent Multicast -- протокол маршрутизации групповых рассылок, независимый от используемого протокола маршрутизации), или PIM-SM. Там же вы найдете ссылки на другие реализации протоколов PIM-DM (Protocol Independent Multicast-Dense Mode -- протокол маршрутизации групповых рассылок, независимый от используемого протокола маршрутизации, "уплотненного" режима) и PIM-SM (Protocol Independant Multicast-Sparse Mode -- протокол маршрутизации групповых рассылок, независимый от используемого протокола маршрутизации, "разреженного" режима). Дополнительную информацию по групповой адресации вы найдете в Multicast HOWTO.

Групповая адресация используется в тех случаях, когда необходимо выполнить доставку информации сразу к нескольким пунктам назначения. Например, WEB-страничка передается отдельно каждому, кто ее запросил, а если несколько человек решили принять участие в видеоконференции? Есть два пути реализации доставки. Либо каждому участнику отдавать отдельный поток данных (тогда трафик будет таким огромным, что для него может просто не хватить пропускной способности канала), либо использовать групповую рассылку. В этом случае отправитель создает одну дейтаграмму с групповым адресом назначения, по мере продвижения через сеть дейтаграмма будет дублироваться только на "развилках" маршрутов от отправителя к получателям.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено). Обратите внимание -- нет никакой необходимости включать эту опцию, если вы желаете лишь получать групповые пакеты. Она необходима только если вы собираетесь перенаправлять групповой трафик через вашу систему.


3.5.9. proxy_arp

Включает/выключает проксирование arp-запросов для заданного интерфейса. ARP-прокси позволяет маршрутизатору отвечать на ARP запросы в одну сеть, в то время как запрашиваемый хост находится в другой сети. С помощью этого средства происходит "обман" отправителя, который отправил ARP запрос, после чего он думает, что маршрутизатор является хостом назначения, тогда как в действительности хост назначения находится "на другой стороне" маршрутизатора.

Маршрутизатор выступает в роли уполномоченного агента хоста назначения, перекладывая пакеты от другого хоста.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено). Дополнительную информацию вы найдете в Proxy-ARP mini HOWTO.


3.5.10. rp_filter

Включает/выключает reverse path filter ("проверка обратного адреса" -- хотя это слишком вольный перевод термина, но мне он кажется наиболее близким по смыслу. прим. перев.) для заданного интерфейса. Смысл этой переменной достаточно прост -- все что поступает к нам проходит проверку на соответствие исходящего адреса с нашей таблицей маршрутизации и такая проверка считается успешной, если принятый пакет предполагает передачу ответа через тот же самый интерфейс.

Caution

Если вы используете расширенную маршрутизацию тем или иным образом, то вам следует всерьез задуматься о выключении этой переменной, поскольку она может послужить причиной потери пакетов. Например, в случае, когда входящий трафик идет через один маршрутизатор, а исходящий -- через другой. Так, WEB-сервер, подключенный через один сетевой интерфейс к входному роутеру, а через другой -- к выходному (в случае, когда включен rp_filter), будет просто "терять" входящий трафик, поскольку обратный маршрут, в таблице маршрутизации, задан через другой интерфейс.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено). Однако в некоторых дистрибутивах по-умолчанию эта переменная включается в стартовых скриптах на этапе загрузки. Поэтому, если у вас эта переменная включена, а вам надо ее выключить -- просмотрите стартовые скрипты в каталоге rc.d.

Tip

Более детальную информацию об этой переменной вы найдете в RFC 1812 - Requirements for IP Version 4 Routers на страницах 46-49 (секция 4.2.2.11), странице 55 (секция 4.3.2.7) и странице 90 (секция 5.3.3.3). Если вы всерьез занимаетесь проблемами маршрутизации, то вам определенно придется изучить этот документ.


3.5.11. secure_redirects

Включает/выключает режим безопасной переадресации. Если переменная выключена, то будут приниматься любые сообщения ICMP Redirect ... от любого хоста из любого места. Если переменная включена, то сообщения о переадресации будут восприниматься только от тех шлюзов (gateways), которые имеются в списке шлюзов по-умолчанию. С помощью этой опции можно избежать большинства ложных переадресаций, которые могут быть использованы для перехвата трафика.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Обратите внимание -- действие этой переменной отменяется переменной shared_media, так что, если вы включаете secure_redirects, то необходимо включить и shared_media.


3.5.12. send_redirects

Включает/выключает выдачу ICMP Redirect ... другим хостам. Эта опция обязательно должна быть включена, если хост выступает в роли маршрутизатора любого рода. Как правило ICMP-сообщения о переадресации отправляются в том случае, когда необходимо сообщить хосту о том, что он должен вступить в контакт с другим сервером.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Если компьютер не выступает в роли маршрутизатора, то эту переменную можно отключить.


3.5.13. shared_media

Включает/выключает признак того, что физическая сеть является носителем нескольких логических подсетей, например, когда на одном физическом кабеле организовано несколько подсетей с различными сетевыми масками. Этот признак используется ядром при принятии решения о необходимости выдачи ICMP-сообщений о переадресации.

Переменная может иметь два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено). Эта переменная перекрывает действие переменной secure_redirects.


3.7. Переменные Netfilter

Все переменные, расположенные в /proc/sys/net/ipv4/netfilter/ связаны с функциональностью netfilter и iptables. Эти переменные пока еще не являются частью основного ядра, но предполагается, что они будут включены в него в ближайшем будущем. Если вы желаете иметь эти настройки у себя, то вам необходимо пропатчить ядро заплатой tcp-window-tracking, которая входит в состав пакета iptables patch-o-matic. Наложение заплат выполняется командой make patch-o-matic KERNEL_DIR=/usr/src/linux из каталога, куда предварительно должен быть развернут пакет patch-o-matic.

Раньше отдельные регулировки и настройки приходилось вносить прямо в исходные тексты, а затем пересобирать ядро. Теперь же, с указанными дополнениями, все становится намного проще, можно "на лету" управлять настройками сетевого фильтра (netfilter) и трассировщика соединений.

В этом разделе будут рассматриваться переменные, которые становятся доступны после пересборки ядра с добавленными дополнениями. Все значения переменных, которые управляют различными временными интервалами, измеряются в "тиках" (для архитектуры i386 -- 1 "тик" = 1/100 сек.).


3.7.1. ip_ct_generic_timeout

Переменная содержит время таймаута для тех случаев, когда трассировщик не в состоянии определить тип протокола, для которого имеется свое характерное время таймаута. Для любого потока, идущего через брандмауэр и для которого не может быть определен протокол, устанавливается значение таймаута из этой переменной.

Переменная принимает целое число. Значение по-умолчанию -- 600 секунд, или 10 минут. Если это значение в вашем случае окажется недостаточно большим -- попробуйте постепенно увеличивать его до тех пор, пока соединения не станут достаточно стабильными.


3.7.2. ip_ct_icmp_timeout

Переменная содержит время таймаута для ICMP-пакетов, т.е. для пар пакетов Echo request и Echo reply, Timestamp request и Timestamp reply, Information request и Information reply и наконец Address mask request и Address mask reply. Другими словами предполагается, что после получения ICMP-запроса, ICMP-ответ должен пройти в течение указанного времени.

Как правило, ICMP-отклики поступают достаточно быстро, в пределах нескольких секунд, поэтому величина таймаута для ICMP-трафика несколько ниже -- примерно 30 секунд. Этой величины вполне достаточно, если не говорить об очень неустойчивых соединениях.


3.7.3. ip_ct_tcp_be_liberal

Эта переменная отвечает за поведение трассировщика TCP-соединений по отношению к пакетам, пришедшим вне пределов TCP-окна. Если переменную выключить, то всем таким пакетам будет присваиваться признак INVALID. Если переменную включить -- то политика трассировщика станет более либеральной, исключение составляют лишь RST-пакеты, которым по-прежнему будет присваиваться признак INVALID, если они пришли за пределами TCP-окна. Наилучший вариант -- выключать эту опцию и включать ее только в особенных случаях.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 0 (выключено).


3.7.4. ip_ct_tcp_log_invalid_scale

Включает/выключает журналирование пакетов с ошибочным значением масштаба TCP-окна. Масштабирование окна -- это специфическая особенность, имеющаяся в современных реализациях TCP. Она детально описана в RFC 1323 - TCP Extensions for High Performance. Если масштаб окна был признан ошибочным, то такой пакет будет занесен в журнал.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Однако, если у вас возникают проблемы при взаимодействии с системами, имеющими очень древнюю реализацию TCP и, как следствие, заполнение системного журнала предупреждениями, то можете отключить эту опцию.


3.7.5. ip_ct_tcp_log_out_of_window

Включает/выключает журналирование пакетов, пришедших вне пределов TCP-окна. Обычно эта опция используется совместно с описанной выше переменной ip_ct_tcp_be_liberal. Все пакеты, пришедшие вне TCP-окна, в зависимости от значения переменной ip_ct_tcp_be_liberal, будут заноситься в системный журнал, если переменная ip_ct_tcp_log_out_of_window будет включена.

Переменная может принимать два значения -- 0 (выключено) и 1 (включено). Значение по-умолчанию -- 1 (включено). Однако, если в системный журнал поступает слишком много подобных предупреждений, а вы не в состоянии ликвидировать ошибки, порождающие эти сообщения, то можете отключить эту опцию.


3.7.6. ip_ct_tcp_timeout_close

Переменная содержит время таймаута для состояния CLOSE, как это определено в RFC 793 (подозреваю, что в данной ситуации автор имел ввиду не состояние CLOSE, а состояние CLOSING, поскольку состояние CLOSE в RFC 793 не определяется, прим. перев.). Когда клиент отправляет FIN-пакет серверу, затем получает FIN-пакет от сервера и отсылает подтверждение закрытия -- FIN/ACK-пакет, то соединение переводится в состояние CLOSE (см. прим. перев. выше). После прохождения заключительного FIN/ACK-пакета от сервера, соединение переводится в состояние TIME_WAIT. (Описываемая здесь ситуация называется "Одновременное закрытие соединения", т.е. когда закрытие соединения инициируется одновременно с обеих сторон. прим. перев)

Переменная принимает целое число. Значение по-умолчанию -- 1000 "тиков", или 10 секунд. Это достаточно большое значение, однако, если вы стали замечать, что соединения в этом состоянии обрываются по истечении таймаута, то вам следует попробовать увеличивать этот параметр до тех пор, пока эти проблемы не исчезнут.


3.7.7. ip_ct_tcp_timeout_close_wait

Переменная содержит время таймаута для состояния CLOSE-WAIT, которое так же определено в RFC 793. Соединение переводится в это состояние тогда, когда от клиента получен FIN-пакет и в ответ отправлен FIN/ACK-пакет. Это состояние длится до тех пор, пока клиенту не будет передан FIN-пакет со стороны сервера, после которого соединение перейдет в состояние LAST-ACK.

Значение по-умолчанию -- 43200 секунд, или 12 часов. Раньше, это значение составляло 60 секунд, но было пересмотрено из-за появления большого количества разрывов соединений по таймауту. Обычно этого времени вполне достаточно для выхода соединения из состояния CLOSE-WAIT, но если у вас возникают проблемы с переполнением таблицы трассировщика из-за большого количества соединений, находящихся в состоянии CLOSE-WAIT, то вам необходимо либо увеличить объем ОЗУ в системе, либо уменьшить этот параметр на несколько часов.


3.7.8. ip_ct_tcp_timeout_established

Переменная содержит время таймаута для соединений, находящихся в состоянии ESTABLISHED. Все соединения, которые благополучно миновали процедуру установления соединения, и по которым не было передано ни одного FIN-пакета, переходят в состояние ESTABLISHED. Другими словами -- это более или менее обычное состояние TCP-соединений.

Поскольку едва ли кто нибудь желает, чтобы установленное соединение было разорвано по таймауту, это время выбрано чрезвычайно большим -- 432000 секунд, или 5 суток.

Caution

Вам не следует уменьшать этот параметр, даже если у вас наблюдается слишком много активных соединений. Если у вас возникают проблемы из-за этого, то вам лучше пересмотреть код функции ip_conntrack_init в файле ip_conntrack_core.c, в которой жестко задаются ограничения на количество записей в таблице трассировщика. Такой жесткий подход является следствием того, что эта таблица не может быть выгружена в своп (swap-memory).


3.7.9. ip_ct_tcp_timeout_fin_wait

Переменная содержит время таймаута для состояний FIN-WAIT-1 и FIN-WAIT-2, описанных в RFC 793. Состояние FIN-WAIT-1 устанавливается после того как серверу будет передан FIN-пакет, а состояние FIN-WAIT-2 после получения FIN/ACK-пакета от сервера. Если от сервера FIN-пакет приходит раньше, чем FIN/ACK-пакет (ситуация "одновременного закрытия соединения" прим. перев.), то вместо состояния FIN-WAIT-2 устанавливается состояние CLOSING.

Значение по-умолчанию -- 120 секунд, или 2 минуты. Это значение достаточно для большинства случаев, но может быть несколько увеличено, если соединения разрываются по таймауту из-за задержек на брандмауэре. Естественно, если у вас возникают проблемы с переполнением таблицы трассировщика, то это значение можно попробовать уменьшить, но не настолько, чтобы не позволить выплнить полную процедуру закрытия соединения с обеих концов.


3.7.10. ip_ct_tcp_timeout_last_ack

Переменная содержит время таймаута для состояния LAST-ACK. Это состояние устанавливается после того, как сервер отправил FIN-пакет клиенту после получения FIN-пакета от клиента и передачи ему FIN/ACK-пакета. Это состояние устанавливается после CLOSE-WAIT состояния, когда ожидается прибытие заключительного FIN/ACK-пакета, после чего запись в таблице трассировщика уничтожается, и устанавливается состояние CLOSED.

Значение по-умолчанию -- 30 секунд. Этого времени более чем достаточно для того, чтобы получить заключительный FIN/ACK-пакет, однако, в отдельных случаях, его может и не хватить. В этой ситуации можете попробовать несколько увеличить это значение. Если у вас возникают проблемы с переполнением таблицы трассировщика, то это значение можно попробовать уменьшить, но не настолько, чтобы не оборвать процедуру закрытия соединения по таймауту.


3.7.11. ip_ct_tcp_timeout_listen

Переменная содержит время таймаута для состояния LISTEN. Состояние LISTEN -- это начальное состояние всех сокетов, согласно RFC 793, которые ожидают установления соединения. Трассировщик ничего не знает об этом состоянии, поскольку он не делает никаких предположений при отсутствии какого либо трафика. Тем не менее эта переменная была введена для сохранения соответствий с RFC 793, а возможно и по ряду других причин, имеющихся у основной команды разработчиков netfilter.

Значение по-умолчанию -- 120 секунд, или 2 минуты. Это значение может быть уменьшено до нуля, если вы сочтете это необходимым, однако это может повлечь за собой весьма странное поведение трассировщика. С другой стороны, поскольку эта переменная никогда не используется, то не имеет особого смысла менять значение по-умолчанию.


3.7.12. ip_ct_tcp_timeout_none

Эта переменная используется в течение чрезвычайно короткого периода времени и предшествует моменту, когда трассировщик определится с ответом на вопрос -- к какому состоянию отнести соединение. Например: брандмауэр никогда не "знает" наверняка в каком состоянии находится соединение, если он "увидел" его впервые. Когда через трассировщик проходит первый пакет, то соединению присваивается статус NONE. После этого трассировщик пытается определить -- к какому состоянию следует отнести этот пакет, в соответствии с RFC 793. В зависимости от комбинации TCP-флагов, пакет может быть отнесен к состоянию SYN-SENT, ESTABLISHED, TIME-WAIT или CLOSING.

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

Значение по-умолчанию -- 1800 секунд, или 30 минут.


3.7.13. ip_ct_tcp_timeout_syn_recv

Эта переменная определяет время таймаута для состояния SYN-RECEIVED (известному так же как SYN-RCVD или SYN-RECV), согласно RFC 793. Это состояние наступает вслед за состоянием LISTEN или SYN-SENT после того, как сервер принял пакет SYN и ответил на него SYN/ACK-пакетом. Это состояние предшествует состоянию ESTABLISHED, которое, в свою очередь, наступает после получения, завершающего процедуру установления соединения, ACK-пакета.

Значение по-умолчанию -- 60 секунд, или 1 минута. Это достаточно большое значение, однако, если вы постоянно сталкиваетесь с ситуацией истечения таймаута состояний SYN-RECV или SYN-SENT, то можете попробовать несколько увеличить это значение. И совершенно недопустимо уменьшение этой переменной, поскольку это сразу же повлечет за собой проблемы при попытке установления соединений.


3.7.14. ip_ct_tcp_timeout_syn_sent

Эта переменная определяет время таймаута для состояния SYN-SENT. Это состояние устанавливается после того, как клиент передаст SYN-пакет и перейдет в ожидание ответного SYN/ACK-пакета. Состояние SYN-SENT предшествует состоянию SYN-RCVD или ESTABLISHED, которое наступает после приема пакета SYN/ACK.

Значение по-умолчанию -- 120 секунд, или 2 минуты. Это достаточно большое значение, однако, если вы сталкиваетесь с проблемами, связанными с превышением таймаута состояния SYN-SENT, то можно попробовать увеличить этот параметр. И совершенно недопустимо уменьшение этой переменной, поскольку это сразу же повлечет за собой проблемы при попытке установления соединений.


3.7.15. ip_ct_tcp_timeout_time_wait

Эта переменная определяет время таймаута для состояния TIME-WAIT, согласно RFC 793. Это последнее из возможных состояний в TCP-соединениях. После закрытия соединения с обеих сторон, и сервер и клиент переходят в состояние TIME-WAIT для того, чтобы дать время на прохождение "опоздавших" пакетов. "Опоздавшие" пакеты могут появиться в результате нарушения порядка прохождения пакетов по сети, т.е. в конечную точку пакеты приходят не в том порядке в каком они были отправлены. По истечении этого таймаута запись в таблице трассировщика, соответствующая закрытому соединению, уничтожается и соединеиние переводится в состояние CLOSED. (Пусть вас не сбивает с толку фраза "соединеиние переводится в состояние CLOSED", на самом деле это несуществующее соединение, в системе полностью отсутствует информация о таких соединениях, проще говоря -- это псевдосостояние, обозначающее то, чего нет на самом деле! прим. перев.)

Значение по-умолчанию -- 120 секунд, или 2 минуты. Не рекомендуется изменять это значение. Однако, для коммутируемых линий, для линий с низкой пропускной способностью, где очень часто нарушается порядок прохождения пакетов, эта величина может оказатьсь слишком маленькой, что может привести к потере скачиваемой информации. В этом случае вам определенно потребуется увеличить время таймаута TIME-WAIT. Если у вас никогда не возникало подобного рода проблем, то можно немного уменьшить этот параметр, чтобы таблица трассировщика быстрее освобождалась от таких записей.


3.7.16. ip_ct_udp_timeout

Эта переменная определяет время таймаута прохождения нескольких начальных UDP-пакетов. Когда приходит первый UDP пакет, то он получает статус NEW, а как только через трассировщик пройдет обратный пакет -- UDP-соединению присваивается статус ESTABLISHED, но таймаут продолжает действовать. После того, как через соединение пройдет туда-обратно несколько UDP-пакетов, то для него, в таблице трассировщика, устанавливается флаг ASSURED (уверенное соединение прим. перев.) и таймаут перестает действовать.

Значение по-умолчанию -- 30 секунд. Если вы используете UDP протокол для передачи небольших блоков данных, следующих через длительные интервалы времени, то скорее всего вам придется увеличить это значение. И совершенно недопустимо уменьшение таймаута в случаях, когда довольно часто выполняется передача данных по протоколу UDP, порождающая "запоздалый" ответный трафик -- это может привести к заполнению таблицы трассировщика ненужными записями.


3.7.17. ip_ct_udp_timeout_stream

Эта переменная определяет время таймаута для UDP-потока, получившего признак ASSURED (см. выше). Этот признак обычно присваивается UDP-соединениям, через которые ведется довольно активный обмен, примерами могут служить разного рода потоковые сервисы или ICQ. Значение этой переменной всегда должно быть больше, чем ip_ct_udp_timeout, поскольку речь может идти о UDP-потоках, по которым передается большое количество данных, пусть даже и со значительными перерывами.

Значение по-умолчанию -- 180 секунд, или 3 минуты. Если у вас возникают проблемы, связанные с истечением этого таймаута -- попробуйте немного увеличить его. Не следует уменьшать этот таймаут, поскольку это может привести к обрыву обмена данными по таймауту. К сожалению, для протокола UDP не может быть определен полный набор состояний, поэтому трассировщик не имеет других видов таймаутов для UDP-потоков.


3.8. Route-переменные

Каталог route/ содержит, главным образом, переменные, связанные с маршрутизацией. Одни определяют максимальное количество генерируемых сообщений, другие -- управляют временными интервалами режима "сборки мусора" в кэше маршрутов.


3.8.1. error_burst

Переменная используется в паре с error_cost для ограничения количества генерируемых сообщений ICMP <Destination> Unreachable. Эта переменная несет в себе смысл верхнего предела "стоимости" передачи сообщений, в то время как error_cost обозначает "цену" одного сообщения. Когда error_burst "опустошается", то передача сообщений ICMP <Destination> Unreachable прекращается.

Note

Сообщения ICMP <Destination> Unreachable обычно отсылаются тогда, когда невозможно определить дальнейший маршрут движения пакета. Этому могут быть три причины:

  1. Невозможно выполнить передачу хосту.

  2. Не известен маршрут к заданному сегменту сети или хосту.

  3. Если данный маршрут запрещен набором правил маршрутизации.

В этих трех случаях сетевая подсистема генерирует сообщение ICMP <Destination> Unreachable, свое для каждого случая:

  1. ICMP Host Unreachable -- когда хост, находящийся в той же сети, что и наш роутер -- недоступен (т.е. не отвечает на ARP-запросы. прим. перев.).

  2. ICMP Network Unreachable -- когда в таблице маршрутизации роутера нет ни одного маршрута, по которому пакет мог бы быть отправлен дальше.

  3. ICMP Communication Administratively Prohibited By Filtering -- когда пакет не может быть переправлен из-за наличия правил маршрутизации явно запрещающих передачу.

Значение по-умолчанию -- 500. Учитывая значение по-умолчанию переменной error_cost (100) это соответствует 5-ти сообщениям ICMP Destination Unreachables в секунду.


3.8.2. error_cost

Более подробное описание см. выше error_burst. Основной смысл этой переменной -- "цена" одного сообщения ICMP Destination Unreachable.

Значение по-умолчанию -- 100, что подразумевает передачу не более 5-ти сообщений ICMP Destination Unreachable за 1 секунду (если расчет производить с учетом значения по-умолчанию переменной error_burst).


3.8.3. flush

Эта переменная очень проста в использовании. Она не содержит никаких реальных данных, поэтому попытка прочитать эту переменную не даст никаких результатов. Запись любой информации в эту переменную (само собой разумеется, запись может быть произведена только, если вы обладаете правами root) приведет к очистке кэша маршрутов. Просмотреть кэш маршрутов вы можете в /proc/net/rt_cache.


Приложение A. Единицы измерения

A.1. "Тики"

От переводчика: Приношу свои извинения за такой неудобоваримый термин, как "тик", но лучшего я просто не смог подобрать. Если вы сможете предложить нечто лучшее -- пишите, поправим! 8-))

"Тики" -- это отрезки времени, используемые ядром Linux. Это понятие базируется на константе HZ, определение которой вы найдете в /usr/include/asm/param.h. Величина этой константы различна для разных аппаратных платформ. Так например, для архитектуры i386 один "тик" равен 1/100 секунды, а для платформа Alpha -- 1/1024 секунды. Полный список соответствий аппаратных платформ и количество "тиков", укладывающихся в 1 секунду, приведен ниже.

Таблица A-1. Количество "тиков" в секунду для различных аппаратных платформ

Архитектура "Тики" в секунду Примечания
Alpha 1024 По-моему только AlphaServer 1200, 4000 и 4100 имеют 1024 "тика" в секунду, если определен символ CONFIG_ALPHA_RAWHIDE. Если CONFIG_ALPHA_RAWHIDE не определен, то в качестве константы HZ устанавливается число 1200. Если кто-нибудь сможет сказать что-то определенное по данному поводу -- пишите (автору данного руководства, прим. перев.)
ARM 100  
CRIS 100  
i386 100  
ia64 1024 Если определен символ CONFIG_IA64_HP_SIM, то тогда HZ = 32, поскольку это преполагает эмулирование архитектуры IA64, а любая эмуляция всегда довольно медлительна.
m68k 100  
MIPS 100 Лучше вам самим заглянуть в include/asm/param.h, поскольку это значение вычисляется довольно сложным образом и зависит от используемой аппаратуры.
MIPS64 100  
PA-RISC 100  
PPC 100  
PPC-64 100 Опять таки -- чтобы получить полное представление о том, как формируется это значение -- загляните в include/asm/param.h.
S390 100  
S390X 100  
SH 100  
Sparc 100  
Sparc64 100  

Приложение B. Ссылки

Здесь приводится список ссылок на ресурсы, которые я использовал в процессе работы над руководством. Часть ссылок я не включил в список преднамеренно, часть -- по забывчивости. Если вы можете предложить свои ссылки на информационные ресурсы -- напишите мне, тогда я смог бы добавить их в этот список.

  • RFC 791 - Internet Protocol - Документ, описывающий протокол IP. Этот документ является редакцией документа DoD Standard Internet Protocol, выполненной J. Postel.

  • RFC 792 - Internet Control Message Protocol - Полные сведения о протоколе ICMP. сли вы ищете какую-либо информацию об этом протоколе, то в первую очередь вам следует заглянуть сюда. Автор: J. Postel.

  • RFC 793 - Transmission Control Protocol - Основной документ, устанавливающий стандарт для протокола TCP, начиная с 1981 года. Сугубо техническое описание, но рекомендуется к прочтению всем, кто желает заняться углубленным изучением этого протокола. Изначально был разработан в Министерстве Обороны (США, прим. перев.). Автор: J. Postel.

  • RFC 959 - File Transfer Protocol - Документ, описывающий протокол FTP. Авторы: J. Postel и J. Reynolds.

  • RFC 1072 - TCP Extensions for Long-Delay Paths - В этом документе обсуждается решение проблем, связанных с маршрутами и потоками, имеющими чрезвычайно большое "время возврата" или идущих по очень "толстым" каналам и как можно выполнить повторное использование номеров TCP-последовательностей среди всего прочего. Этот RFC является устаревшей версией RFC 1323, но я привел его здесь, потому что он содержит большое количество ценной информации. Авторы: V. Jacobson и R. Braden.

  • RFC 1122 - Requirements for Internet Hosts -- Communication Layers - Здесь содержатся требования к узлам сети Internet. Издано в IETF, под редакцией R. Braden.

  • RFC 1123 - Requirements for Internet Hosts -- Application and Support - Требования к реализации Прикладного Уровня для всех узлов Internet. Под редакцией R. Braden.

  • RFC 1323 - TCP Extensions for High Performance - Следующая редакция RFC 1072, о котором упоминалось выше. Авторы: V. Jacobson, R. Braden и D. Borman.

  • RFC 1337 - TIME-WAIT Assassination Hazards in TCP - Обсуждается несколько возможных сценариев потери TCP-соединений и дается ряд решений этих проблем. Автор: R. Braden.

  • RFC 1812 - Requirements for IP Version 4 Routers - Обсуждаются требования, предъявляемые ко всем IPv4 маршрутизаторам. Вам необходимо прочитать этот докумен, если вы занимаетесь вопросами маршрутизации. Этот RFC базируется на устаревшем RFC 1716. Редакция F. Baker.

  • RFC 2018 - TCP Selective Acknowledgement Options - Обсуждается дополнение к TCP -- SACK, или Selective Acknowledgement (Выборочное Подтверждение). Авторы: M. Mathis, J. Mahdavi, S. Floyd и A. Romanow.

  • RFC 2883 - An Extension to Selective Acknowledgement (SACK) Option for TCP - Рассматриваются расширения дополнения SACK к TCP. Авторы: S. Floyd, J. Mahdavi, M. Mathis и M. Podolsky.

  • RFC 2884 - Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks - Оценка работы расширения ECN в IP-сетях. Это исключительно информационный RFC и не содержит никакой специфической информации по реализации ECN. Авторы: J. Hadi Salim и U. Ahmed.

  • RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP - Этот документ описывает, на техническом уровне -- как должно использоваться расширение ECN и ка оно может быть реализовано в протоколах TCP и IP. Авторы: K. Ramakrishnan, S. Floyd и D. Black.

  • Guide to IP Layer Network Administration with Linux - Огромное руководство, рассказывающее о том, как работает IP в Linux и как его администрировать. Обсуждается инструментарий и общая концепция IP. Особенно детально рассматриваются проблемы протокола ARP, который объясняется просто замечательно.

  • ECN-under-Linux Unofficial Vendor Support Page - Прекрасная страничка, содержащая информацию по проблемам ECN.

  • ECN: Executive Summary - Сообщение от Dax Kelson, направленное в список рассылки разработчиков ядра (Linux kernel mailing list), утверждающее, что 8% узлов Internet недоступны для клиентов, из-за несовместимости с расширением ECN. Это послание датировано 2000 годом (10 сентября 2000 г.), так что возможно, что положение, на сегодняшний день, изменилось.

  • TCP Tuning Guide - Обсуждаются различные варианты оптимизации TCP, с целью повышения производительности. Написано группой авторов из DIDC (Data Intensive Distributed Computing group) из Lawrence Berkeley Labs., лидер группы: Brian L. Tierney. Большинство из приводимых здесь рекомендаций, применимо лишь к гигабитным сетям.

  • services.txt - Пример файла /etc/services. Этот пример взят из дистрибутива Slackware 8.0.

  • protocols.txt - Пример файла /etc/protocols. Здесь содержатся символические имена сетевых сервисов и их номера. Этот пример взят из дистрибутива Slackware 8.0.

  • ip-sysctl.txt - Классическая документация по функциям ip-sysctl ядра Linux. Этот файл был взят из документации, сопровождавшей ядро 2.4.14.

  • ip_dynaddr.txt - Здесь содержится информация об опции ip_dynaddr, доступной через интерфейс sysctl. Этот файл был взят из документации, сопровождавшей ядро 2.4.14. Изначально был написан JuanJo Ciarlante.

  • ip-param.txt - Здесь содержится информация о полях IP-заголловка и содержатся ссылки на соответствующие RFC.

  • netdev mailinglist - Список рассылки для разработчиков сетевой подсистемы Linux.




Приложение C. Хронология

Version 1.0.4 (21 May 2003)
http://ipsysctl-tutorial.frozentux.net
By: Oskar Andreasson

Version 1.0.3 (26 Apr 2003)
http://ipsysctl-tutorial.frozentux.net
By: Oskar Andreasson
Contributors: Don Cohen, Martin A. Brown and Brian Tierney.

Version 1.0.2 (19 Dec 2002)
http://ipsysctl-tutorial.frozentux.net
By: Oskar Andreasson
Contributors: Alan Cox, Michael T. Babcock, Don Cohen and several others.

Version 1.0.1 (23 Oct 2002)
http://ipsysctl-tutorial.frozentux.net
By: Oskar Andreasson
Contributors: William Stearns, Don Gould, Mattias Webj?rn Eriksson and
Michael Bussmann.

Version 1.0.0 (8 Oct 2002)
http://ipsysctl-tutorial.frozentux.net
By: Oskar Andreasson
Contributors: Jozsef Kadlecsik, Nivedita Singhvi, JuanJo Ciarlanti and 
Alexey Kuznetsov
 


Приложение D. GNU Free Documentation License

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.


1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.


2. VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.


3. COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.


4. MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.


5. COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."


6. COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.


7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.


8. TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.


9. TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.


10. FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.


How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".

If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.


Приложение E. GNU General Public License

Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


0. Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

The precise terms and conditions for copying, distribution and modification follow.


1. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

    Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

  2. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

    You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

  3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

    1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

    2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

    These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

    Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

    In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

  4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

    1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    2. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

    The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

    If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

  5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

  6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

  7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

  8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

    If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

    It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

    This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

    If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

  9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

    Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

  10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

  11. NO WARRANTY

    BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS


2. How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found.

<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year>  <name of author>
    

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) year name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
  

<signature of Ty Coon>, 1 April 1989
Ty Coon, President of Vice
  

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.