Proxy arp что это
Протокол прокси-ARP
Параметры загрузки
Содержание
Введение
Предварительные условия
Требования
Данный документ требует понимания принципов работы ARP и Ethernet.
Используемые компоненты
Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:
ПО Cisco IOS ® версии 12.2 (10b)
Маршрутизаторы серии Cisco 2500
Сведения, содержащиеся в данном документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в данном документе, обладают ненастроенной (заданной по умолчанию) конфигурацией. При работе в действующей сети перед применением команды необходимо изучить все возможные последствия ее выполнения.
Условные обозначения
Дополнительные сведения об условных обозначениях в документах см. в статье Условные обозначения, используемые в технической документации Cisco.
Как работает протокол прокси-ARP?
Ниже приведен пример работы прокси-ARP:
Схема сети
Хосту A (172.16.10.100) подсети A необходимо отправить пакеты хосту D (172.16.20.200) подсети B. Как показано на рисунке выше, у хоста A есть маска подсети a /16. Это значит, что узел А предполагает, что он непосредственно подключен ко всем адресам 172.16.0.0 в сети. Когда хосту А необходимо связаться с устройством, которое предположительно подключено напрямую, он посылает на это устройство ARP-запрос. Таким образом, если хосту A требуется отправить пакет на хост D, который считается подключенным напрямую, хост A отправляет хосту D ARP-запрос.
Для получения доступа к хосту D (172.16.20.200) хосту A нужен MAC-адрес хоста D.
Поэтому хост А передает ARP-запрос в широковещательном режиме на подсеть А, как показано ниже:
Хост A (172.16.10.100) в вышеуказанном запросе ARP запрашивает отправку хостом D (172.16.20.200) своего MAC-адреса. Затем указанный выше пакет запроса ARP инкапсулируется в кадре Ethernet с MAC-адресом хоста A в качестве адреса источника и широковещательной рассылкой (FFFF.FFFF.FFFF) в качестве адреса назначения. Из-за широковещательной рассылки ARP-запрос достигает всех узлов в подсети A, включая интерфейс e0 маршрутизатора, кроме хоста D. Эта рассылка не достигает хоста D, так как маршрутизаторы по умолчанию ее не отправляют.
Поскольку маршрутизатору известно, что целевой адрес (172.16.20.200) находится в другой подсети и достигает хост D, он посылает в ответ собственный MAC-адрес хосту A.
IP адрес отправителя
Выше указан ответ прокси-ARP, который маршрутизатор посылает к хосту A. Ответный пакет прокси-ARP инкапсулируется в кадр Ethernet с MAC-адресом маршрутизатора в качестве адреса источника и с MAC-адресом хоста А в качестве адреса назначения. ARP-ответы являются одноадресными и посылаются узлу, инициировавшему запрос.
При получении ответа ARP хост A обновляет таблицу ARP, как показано ниже:
Теперь хост А будет пересылать все пакеты, которые должны достигнуть 172.16.20.200 (хост D), на MAC-адрес 00-00-0c-94-36-ab (маршрутизатор). Так как маршрутизатору известен путь достижения хоста D, он отправляет пакет этому хосту. ARP-кэш на хостах подсети A загружен MAC-адресом маршрутизатора для всех хостов подсети B. Поэтому все пакеты, предназначенные для подсети B, отправляются маршрутизатору. Маршрутизатор пересылает эти пакеты хостам в подсеть B.
Кэш ARP хоста A представлен ниже:
Примечание. Несколько IP-адресов сопоставляются с одним MAC-адресом (MAC-адресом маршрутизатора), что указывает на использование протокола прокси-ARP.
Интерфейс маршрутизатора Cisco должен быть настроен на прием и отправку прокси-ARP. Этот режим включен по умолчанию. Прокси-ARP отключается командой конфигурирования интерфейса no ip proxy-arp на уровне отдельного интерфейса, как показано ниже:
Чтобы включить прокси-ARP на интерфейсе используйте команду конфигурирования интерфейса ip proxy-arp.
Примечание. Если хост B (172.16.10.200/24) в подсети A пытается отправить пакеты на хост D (172.16.20.200) подсети B, он обращается к таблице IP-маршрутизации и использует соответствующий адрес для маршрутизации. Хост B (172.16.10.200/24) не запускает прокси-ARP для IP-адреса 172.16.20.200 хоста D, так как он принадлежит другой подсети, отличающейся от подсети, настроенной на хосте B интерфейса ethernet 172.16.20.200/24.
Преимущества прокси-ARP
Основное преимущество использования прокси-ARP состоит в том, что этот протокол можно установить на один маршрутизатор в сети без изменения таблиц маршрутизации на остальных маршрутизаторах в той же сети.
Прокси-ARP используется в сети, где IP-хосты не настроены в шлюзе по умолчанию или не обладают интеллектуальными функциями маршрутизации.
Недостатки прокси-ARP
Это увеличивает объем ARP-трафика в вашем сегменте сети.
Хостам необходимы большие ARP-таблицы для обработки сопоставления IP-адресов и MAC-адресов.
Система безопасности может быть нарушена. Один компьютер может выдавать себя за другой для перехвата пакетов. Это называется «спуфингом».
Это не относится к сетям, которые не используют ARP для разрешения адресов.
Это не касается всех сетевых топологий (например, нескольких маршрутизаторов, соединяющих две физические сети).
Для получения более подробных сведений о настройке прокси-ARP см. раздел Включение прокси-ARP документа Настройка IP–адресов.
ARP: Нюансы работы оборудования Cisco и интересные случаи. Часть 2
Привет, Habr! В предыдущей части статьи мы рассмотрели особенности работы ARP на маршрутизаторах Cisco, связанные с правилами NAT и с функцией Proxy ARP. В данном посте попробую разобрать отличия в работе ARP между маршрутизаторами Cisco и межсетевыми экранами Cisco ASA. В заключении статьи поделюсь несколькими интересными случаями из практики, связанными с работой ARP.
NAT и Proxy ARP на межсетевых экранах Cisco ASA
Рассмотрим примеры на основании следующей простейшей топологии:
Настройки интерфейсов Cisco ASA:
Настройки правила NAT и списка доступа на интерфейсе outside:
Как видно из представленных настроек мы публикуем порт tcp 3389 (RDP) под адресом 198.18.99.2, который не принадлежит IP-подсети интерфейса Cisco ASA.
Проверяем опцию sysopt noproxyarp:
Видно, что опция не выставлена (noproxyarp не включён). Попробуем открыть tcp-порт 3389 адреса 198.18.99.2 и одновременно посмотрим сниффер:
Успех: Cisco ASA отвечает на ARP-запрос и порт открывается.
Попробуем выставить опцию sysopt noproxyarp outside. Очищаем arc-cache на компьютере, подключенном к outside-интерфейсу, и пробуем открыть порт снова:
ASA более не отвечает на ARP-запросы к целевому IP-адресу. При этом, не имеет значения, находится ли целевой IP-адрес в IP-подсети интерфейса ASA. При выставленной опции sysopt noproxyarp ASA будет отвечать на ARP-запросы, адресованные исключительно IP-адресу интерфейса.
Не стоит сравнивать настройку ip proxy-arp интерфейса маршрутизатора с настройкой опции sysopt noproxyarp Cisco ASA. Опция Cisco ASA не включает проксирование любых ARP-запросов через межсетевой экран. Эта опция отвечает исключительно за обслуживание внутренних глобальных IP-адресов правил NAT и статических записей в ARP-таблице ASA, настроенных с ключевым словом alias.
В некоторых случаях функционал ARP-ответов необходимо отключать для конкретных правил NAT. Для этого служит ключевое слово no-proxy-arp в настройках NAT. Наиболее распространённый пример – настройка NAT-исключений при использовании VPN на Cisco ASA. Предположим, локальная сеть за Cisco ASA – 192.168.20.0/24, локальная сеть на удалённой стороне Site-to-Site VPN – 192.168.30.0/24. NAT-исключение для данного VPN можно настроить следующим образом:
Представленная конфигурация указывает для Cisco ASA, что IP-подсеть local-LAN 192.168.20.0/24 целиком опубликована на каждом интерфейсе Cisco ASA (any,any в правиле NAT) под внутренними глобальными адресами той же IP-подсети local-LAN. Следовательно, при данной конфигурации Cisco ASA будет отвечать на любой ARP-запрос к целевому IP-адресу из IP-подсети 192.168.20.0/24, поступившему на любой интерфейс, включая inside интерфейс.
Представим ситуацию, хост с адресом 192.168.20.5 хочет обратиться к хосту из той же IP-подсети с адресом 192.168.20.6. Формируется ARP-запрос на целевой адрес 192.168.20.6. ARP-запрос рассылается широковещательно и достигает как целевой хост, так и inside интерфейс Cisco ASA. Настроенное правило NAT заставляет Cisco ASA ответить своим MAC-адресом на ARP-запрос. Если ARP-ответ от Cisco ASA поступит раньше ответа от целевого хоста, весь трафик, направленный к целевому хосту, пойдёт на Cisco ASA, где будет благополучно отброшен.
В представленном примере Cisco ASA будет работать как «black hole» для локальной IP-подсети, стремясь «засасывать» на себя весь трафик. При этом, элемент policy NAT (настройка NAT после ключевых слов destinations static) ситуацию не спасает. Если сравнивать с маршрутизатором, данная настройка на Cisco ASA по эффекту схожа с совместной настройкой ip proxy-arp и ip local-proxy-arp на интерфейсе маршрутизатора. Чтобы избежать описанного эффекта, в правиле NAT на Cisco ASA необходимо добавить ключевое слово no-proxy-arp:
Примечание: описанный эффект можно избежать, указывая в настройках правила NAT точные интерфейсы, вместо ключевых слов any. Например, nat (inside,outside) …
Случай №1. Secondary IP-адрес у провайдера
Подключали к провайдеру межсетевой экран Cisco ASA. Подключение прошло успешно и все сервисы работали корректно. Однако через некоторое время связь пропадала. Детальный анализ показывал, что если инициировать исходящее соединение, то оно работает стабильно (трафик ходит в обе стороны). Проблема появляется только со входящими соединениями из сети Интернет (например, удалённое подключение к маршрутизатору). При этом прослеживается прямая зависимость входящих соединений от исходящих: если есть исходящие соединения, то и входящие соединения начинают корректно работать. Однако, по прошествии некоторого времени подключиться удалённо или «пропинговать» устройство из Интернета снова не удаётся.
Так как с физическим и канальным уровнем предположительно всё в порядке, мы стали проверять работу ARP. Запустили debug arp на ASA и попробовали очистить arp-cache. По debug-сообщениям увидели, что ASA корректно отправляет ARP-запрос и без проблем получает ARP-ответ от провайдера. В данном примере IP нашей ASA 80.X.X.4, её MAC-адрес a0ec.****.****, IP-шлюза провайдера 80.X.X.1, MAC-шлюза провайдера aa43.****.****:
Однако, через какое-то время заметили сообщение в debug arp на ASA:
Судя по данному сообщению ASA получает ARP-запрос с верным Sender MAC Address aa43.****.**** но неверным Sender IP Address – 195.Y.Y.1. Данный некорректный ARP-запрос ASA отбрасывает и не отправляет ARP-ответ.
Таким образом, когда существует исходящий трафик, ASA отправляет ARP-запрос (при необходимости, когда соответствующая запись в ARP-таблице ASA требуется обновления) в сторону провайдера и получает ARP-ответ. Благодаря ARP-запросу от ASA оборудование провайдера также получает запись об ASA в своей ARP-таблице. Однако, когда исходящий трафик от ASA отсутствует продолжительное время и ASA не отправляет ARP-запрос, на оборудовании провайдера в ARP-таблице запись об ASA истекает. Оборудование провайдера пробует обновить запись, отправляя ARP-запрос, но ответ не получает. Отсюда и появляются «плавающие» проблемы со связью.
Осталось понять, почему оборудование провайдера отправляет ARP-запрос с неверным Sender IP Address. Позже провайдер проверил данную ситуацию со своей стороны и даже показал дамп ARP-трафика, который подтверждал debug-сообщения ASA:
Оказалось, что на интерфейсе провайдера адрес 195.Y.Y.1 был настроен как основной, а IP-адрес 80.X.X.4, который являлся для нас шлюзом по умолчанию, был настроен как secondary. Эта настройка полностью объясняла ситуацию. В данном случае проблема была решена добавлением статической ARP-записи на оборудовании провайдера.
Абсолютно аналогичная ситуация у нас возникала на другой площадке, когда мы использовали для подключения к провайдеру маршрутизатор Cisco. На оборудовании провайдера наш шлюз был также настроен как seconday IP-адрес. В этом случае, чтобы ускорить процесс решения проблемы, мы добавили на маршрутизаторе secondary IP-адрес из той же подсети, что и основной IP-адрес на интерфейсе провайдера. После этого наш маршрутизатор стал успешно отвечать на ARP-запросы со стороны провайдера, так как на нашем интерфейсе появился IP-адрес из той же подсети, что и адрес в ARP-запросе.
Случай №2. ARP-несовместимость
Перед нами была поставлена задача в одном из офисов заменить маршрутизатор Cisco ISR на межсетевой экран Cisco ASA. Межсетевой экран ASA предварительно был настроен и отправлен в точку установки. После подключения к провайдеру Cisco ASA оказался недоступным для удалённого подключения. На первый взгляд на устройстве всё работало корректно. Межсетевой экран ASA корректно определял MAC адрес маршрутизатора провайдера с помощью стандартной процедуры ARP-запрос/ARP-ответ. Пакеты уходили с внешнего интерфейса устройства в Интернет. При этом в обратную сторону на ASA ничего не приходило. Этот факт фиксировался встроенными средствами перехвата пакетов (packet capture).
После обращения к провайдеру было установлено, что пакеты от ASA успешно доставлялись на оборудование провайдера, также провайдер видел ответные пакеты, приходящие с вышестоящего оборудования. После того как был обратно подключен маршрутизатор, трафик снова начал ходить корректно в обе стороны. Это означало, что проблема где-то на стыке между провайдером и межсетевым экраном ASA. После повторного обращения к провайдеру с детальным описанием проблемы было определено, что оборудование провайдера не видит MAC адрес межсетевого экрана ASA. Собранный демо-стенд доказал корректность работы ASA (роль провайдера играл маршрутизатор Cisco). По какой-то причине устройство провайдера не заносило запись об ASA в ARP-таблицу после получения ARP-ответа от ASA. Самое интересное, что ARP-запрос, поступающий от Cisco ASA не отбрасывался. Оборудование провайдера корректно отвечало на ARP-запрос от ASA, но также, не заносило запись ASA в ARP-таблицу.
В итоге провайдеру было предложено сделать статическую привязку в таблице ARP. Данный случай показал несовместимость по ARP оборудования провайдера с межсетевым экраном Cisco ASA. К сожалению, провайдер не озвучил производителя своего оборудования.
Случай №3. Gratuitous ARP
И опять подключаем к провайдеру Cisco ASA. В этот раз вместо сервера MS TMG. Особенность данного случая в том, что MS TMG был подключен к устройству провайдера через L2-коммутатор. Предполагалось подключение ASA также через L2-коммутатор:
Итак, отключаем MS TMG и вместо него в тот же порт L2-коммутатора подключаем Cisco ASA. Видим стандартную ситуацию: с внешнего порт Cisco ASA трафик уходит, но ответные пакеты отсутствуют. После обращения к провайдеру выясняется, что оборудование провайдера по-прежнему видит MAC-адрес сервера MS TMG за IP-адресом, перешедшим на Cisco ASA.
Дальнейшее разбирательство показало, что межсетевой экран Cisco ASA не шлёт Gratuitous ARP сообщение при переходе интерфейса из состояния DOWN в состояние UP. А так как оборудование провайдера подключено через L2-коммутатор, при смене устройства на нашей стороне канал до провайдера не падает, и интерфейс маршрутизатора провайдера всегда остаётся во включенном состоянии. Единственный способ своевременно оповестить провайдера о том, что на нашей стороне изменилось устройство и MAC-адрес, – Gratuitous ARP. В противном случае, придётся ждать таймаута ARP-записи у провайдера, а это как, как правило, 4 часа.
В данном случае мы сделали на интерфейсе Cisco ASA команды no ip address, ip address x.x.x.x y.y.y.y. После этого ASA всё же отправила Gratuitous ARP, и всё взлетело.
В данной статье, состоящей из двух частей, я постарался рассмотреть тонкости работы ARP на оборудовании Cisco в случаях использования трансляции сетевых адресов (NAT), а также функционал Proxy ARP. Разобрал отличия в работе ARP между маршрутизаторами Сisco и межсетевыми экранами Cisco ASA. В заключении статьи я рассмотрел проблемы, возникающие при подключении к Интернет-провайдеру, обусловленные работой ARP.
Описанные случаи показывают, на сколько важно помнить о необходимости проверки ARP в процессе решения и устранения сетевых проблем. Надеюсь, материал данной статьи станет полезным для более глубокого понимания работы ARP.
Жду комментарии. Может быть кто-то сможет рассказать собственные интересные случаи, связанные с работой ARP.
Proxy arp что это
версия 2.0, 27 августа 2000 года
Это все будет работать только в том случае, если все машины соединены при помощи Ethernet-совместимых устройств (т.е. не будет работать с SLIP/PPP/CSLIP и т.п..)
Создание этого документа и моего способа использования Прокси-ARP, было бы невозможно без помощи:
Мини-HOWTO «Прокси-ARP» (Al Longyear)
Мини-HOWTO «Несколько Ethernet-сетей» (Don Becker)
Исходный текст программы arp (8) и man-страница (Fred N. van Kempen и Bernd Eckenfels)
Конфигурация подсетей, при которых необходимо использование Прокси-ARP, достаточно специфична.
У меня была радио-Ethernet-ISA-8бит-карта. Мне было необходимо подключить ее к нескольким машинам одновременно. Я мог использовать ее на Linux-машине (правда мне для этого пришлось писать драйвер, но это тема для отдельного разговора). В общем, от меня требовалось установить вторую карту в Linux-машину, и некоторым образом объединить две подсети.
В обычном случае я должен был сделать следующее:
Использовать IP-мост (см. Мини-HOWTO: Мосты), чтобы передавать пакеты между интерфейсами. К сожалению, у радио-Ethernet-карт нет режима «promisc» (они не могут перехватывать весь трафик сети 1). Это связано с маленькой скоростью передачи (2Мбит/сек), а также с тем, что нам совсем не надо обрабатывать весь трафик сети 1. Более того, мосты достаточно хорошо загружают систему!
На самом деле Прокси-ARP необходим только для передачи пакетов из сети 1 в сеть 0. Обратно пакеты идут при помощи стандартной IP-маршрутизации.
В данном случае у сети 1 была 8-битная маска (255.255.255.0). Для сети 0 я использовал 4-битную маску (255.255.255.240), тем самым получив возможность иметь в ней 14 адресов (2 ^ 4 = 16, минус 0-ой и 15-ый). Заметьте что эта подсеть может иметь любое количество бит, которое должно быть меньше количества бит главной сети (т.е. 2, 3, 4, 5, 6 или 7 бит в моем случае)
Машине A выделены два IP-адреса, один в адресном пространстве сети 0 для настоящего Ethernet-интерфейса (eth0), а второй в пространстве сети 1 (не сети 0) для интерфейса радио-карты (eth1).
Вот здесь и начинается волшебство. Код arp в ядре Linux в машине A, будучи правильно настроен (Прокси-ARP для подсетей), определяет, что ARP-запрос идет из интерфейса сети 1 (eth1), а соответствующий IP-адрес находится в сети 0. В этом случае машина A в ответе на запрос укажет свой собственный Ethernet-адрес.
Машина C сделает запись в своем ARP-кэше, в котором укажет, что IP-адресу машины B соответствует Ethernet-адрес машины A (в данном случае, адрес радио-Ethernet карты). После этого машина C сможет послать пакет машине B на этот Ethernet-адрес, и его получит машина A.
Получив такой пакет, машина A определит, что его получатель не она, а машина B. Код IP-маршрутизации ядра Linux машины A попытается передать пакет машине B в соответствии со своей таблицей маршрутизации (в которой указано, какому интерфейсу, какая сеть соответствует). Однако, IP-адрес машины B соответствует одновременно и сети 0, и сети 1.
Вот здесь происходит вторая часть волшебства. Маска подсети на интерфейсе 0 имеет в двоичном представлении больше единиц (то есть, более конкретизирована), чем маска подсети интерфейса 1. Вследствие этого, код маршрутизации сопоставит этот пакет с интерфейсом eth0, игнорируя соответствие адреса в пакете сети 1 (из которой, собственно, этот пакет и пришел).
Аналогично (и даже немного проще) происходит с пакетами любых машин обеих сетей, предназначенными для машины A.
Очевидно, что, если другая машина (D) в сети 0 пошлет ARP-запрос относительно физического адреса машины B, машина A получит этот запрос с сети 0 и не пошлет в ответ прокси-адрес интерфейса eth1, определив, что запрос идет из сети 0.
Маленькое дополнение: заметьте, что физические (Ethernet) адреса, полученные машинами A, B, C (и D), помещаются в ARP-кэш, и последующие пакеты не вызовут повторной процедуры ARP-запрос-ответ. ARP-кэш обычно удаляет записи с адресами после 5 минут их бездействия.
Я настроил работу Прокси-ARP с подсетями в ядре Linux версии 2.0.30, но мне сказали, что все это работало еще в пору ядер 1.2.x.
NETMASK=255.255.255.240 # это для 4-битной сети NETWORK=x.y.z.64 # наш номер сети (замените x.y.z на настоящие цифры вашей сети) BROADCAST=x.y.z.79 # широковещательный адрес (в моем случае)
Затем добавляем настройку второй Ethernet-карты (после загрузки всех необходимых модулей с драйвером):
/sbin/ifconfig eth1 (name on net 1) broadcast (x.y.z.255) netmask 255.255.255.0
Теперь добавляем запись в таблицу маршрутизации:
Вам также, возможно, понадобится сменить адрес шлюза, используемого по умолчанию.
Теперь настало время добавить строку, включающую Прокси-ARP:
Если нам повезет, после загрузки все машины подсети 0 появятся в сети 1. Вы можете проверить на машине A настройку Прокси-ARP, используя следующую команду: (имена и адреса изменены)
Вы также можете проверить правильность таблицу маршрутизации. Ниже приведена моя таблица (имена и адреса снова изменены):
Заметьте, что первая запись является подмножеством второй, но таблица маршрутизации отсортирована в порядке приоритета, поэтому строка eth0 будет обрабатываться до строки eth1.
Существуют и другие способы работы с этими подсетями, кроме Прокси-ARP. О некоторых из них я уже упомянул выше (мосты и маршрутизация):
IP-Маскарадинг (см. мини-HOWTO «IP-Маскарадинг»). При его использовании, сеть 0 будет скрыта за машиной A от остальной части Интернет. При попытке машин сети 0 связаться с остальным миром через машину A, адреса отправителей и номера портов в пакетах будут заменены на машине A так, как будто она сама связывается с внешним миром. Это достаточно красивое решение, но машины сети 1 не смогут связаться с машинами сети 0, потому что для сети 1 сеть 0 не существует. Это, конечно, увеличивает защищенность сети 0, но при этом теряется возможность работы машин сети 1 с машинами сети 0.
Использовать Прокси-ARP без подсетей. Теоретически это возможно, просто вам придется в ARP-кэше указать все машины подсети 0 по отдельности, вместо указания ссылки на всю сеть.
Наверно, здесь можно воспользоваться и IP-алиасингом, но я об этом не думал.
Еще один пример применения Прокси-ARP в подсетях можно найти здесь же, в Австралийском Национальном Университете. Эта та самая конфигурация, для которой Andrew Tridgell и написал работу с подсетями в Прокси-ARP. Однако, Andrew говорит, что, на самом деле в мире существует еще несколько подобных конфигураций (подробностей у меня нет).
Это была лаборатория, в которой студентов обучают, как настраивать TCP/IP в машинах, включая и настройку шлюза. Там имеется сеть класса C, и Andrew была нужна «подсеть» для безопасности, контроля трафика и образовательных целей, упомянутых выше. Он сделал это при помощи стандартного Прокси-ARP, а затем до него дошло, что иметь одну запись в ARP-кэше значительно проще, чем иметь по одной записи для каждой машины.. И вот. появился Прокси-ARP для подсетей!
Copyright 1997 by Bob Edwards >
Voice: (+61) 2 6249 4090
Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions. All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs. If you have questions, please contact the Linux HOWTO coordinator, at > via email.
Авторские права на русский перевод этого текста принадлежат © 2000 SWSoft Pte Ltd. Все права зарезервированы.
Этот документ является частью проекта Linux HOWTO.
Авторские права на документы Linux HOWTO принадлежат их авторам, если явно не указано иное. Документы Linux HOWTO, а также их переводы, могут быть воспроизведены и распространены полностью или частично на любом носителе физическом или электронном, при условии сохранения этой заметки об авторских правах на всех копиях. Коммерческое распространение разрешается и поощряется; но так или иначе автор текста и автор перевода желали бы знать о таких дистрибутивах.
Все переводы и производные работы, выполненные по документам Linux HOWTO должны сопровождаться этой заметкой об авторских правах. Это делается в целях предотвращения случаев наложения дополнительных ограничений на распространение документов HOWTO. Исключения могут составить случаи получения специального разрешения у координатора Linux HOWTO с которым можно связаться по адресу приведенному ниже.