http://www.qbsd.ru/api.php?action=feedcontributions&feedformat=atom&user=Nordwind 2026-05-02T20:24:09Z Вклад участника MediaWiki 1.35.2 http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=251 2013-07-15T13:02:26Z

<p>Nordwind: /* Поиск сигнатур */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> ==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;Общий алгоритм&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на &lt;tt&gt;adler32 от Марка Адлера. &lt;tt&gt;Adler32&lt;/tt&gt; — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> <br /> == Поиск сигнатур ==<br /> <br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32-x битной сигнатуры, а значением — сумма двух её (16-ти битных) половин.<br /> <br /> Поиск сигнатур<br /> &lt;gallery&gt;<br /> Файл:search.gif |Поиск сигнатур<br /> &lt;/gallery&gt;<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле &#039;&#039;&#039;A&#039;&#039;&#039;, который есть в файле &#039;&#039;&#039;B&#039;&#039;&#039;. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков &#039;&#039;Alpha&#039;&#039; отсылает &#039;&#039;Beta&#039;&#039; данные из файла &#039;&#039;&#039;A&#039;&#039;&#039; между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в &#039;&#039;&#039;B&#039;&#039;&#039;. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле &#039;&#039;&#039;A&#039;&#039;&#039;, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> <br /> == Реконструкция файла ==<br /> <br /> Одна из простых частей алгоритма &lt;tt&gt;rsync&lt;/tt&gt; — реконструкция файла. После того, как компьютер &#039;&#039;Beta&#039;&#039; отсылает сигнатуры, &#039;&#039;Alpha&#039;&#039; присылает байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла &#039;&#039;&#039;B&#039;&#039;&#039; нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> <br /> == Конвейерная обработка ==<br /> <br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как &lt;tt&gt;ftp&lt;/tt&gt;, &lt;tt&gt;rcp&lt;/tt&gt; или &lt;tt&gt;rdist&lt;/tt&gt; обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web-сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> <br /> Схема конвейерной обработки<br /> &lt;gallery&gt;<br /> Файл:pipe.gif |Схема конвейерной обработки<br /> &lt;/gallery&gt;<br /> <br /> Процесс разбивается на 3 части — &lt;tt&gt;Generator&lt;/tt&gt;, &lt;tt&gt;Sender&lt;/tt&gt; и &lt;tt&gt;Receiver&lt;/tt&gt;. &lt;tt&gt;Generator&lt;/tt&gt; запускается на компьютере &#039;&#039;Beta&#039;&#039; и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. &lt;tt&gt;Sender&lt;/tt&gt;, запущенный на &#039;&#039;Alpha&#039;&#039; получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты &#039;&#039;Beta&#039;&#039;. &lt;tt&gt;Receiver&lt;/tt&gt;, запущенный на &#039;&#039;Beta&#039;&#039;, реконструирует файл, после чего он связывается с &lt;tt&gt;Generator&lt;/tt&gt;, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> <br /> == Заключение ==<br /> <br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> # [http://rsync.samba.org/tech_report/ Rsync technical report]. Andrew Tridgell и Paul Mackerras. 1998г.<br /> # [http://www.samba.org/~tridge/phd_thesis.pdf Efficient Algorithms for Sorting and Synchronization]. Andrew Tridgell. 2000г.<br /> # [http://www.gzip.org/zlib/zlib_tech.html Zlib Technical Details]. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=250 2013-07-10T15:39:03Z

<p>Nordwind: /* Быстрая сигнатура */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> ==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;Общий алгоритм&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на &lt;tt&gt;adler32 от Марка Адлера. &lt;tt&gt;Adler32&lt;/tt&gt; — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> <br /> == Поиск сигнатур ==<br /> <br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32-x битной сигнатуры, а значением — сумма двух её (16-ти битных) половин.<br /> <br /> Поиск сигнатур<br /> &lt;gallery&gt;<br /> Файл:Example.jpg|Описание1<br /> Файл:Example.jpg|Описание2<br /> &lt;/gallery&gt;<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле A, который есть в файле B. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков Alpha отсылает Beta данные из файла A между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в B. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле A, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> Реконструкция файла<br /> Одна из простых частей алгоритма rsync — реконструкция файла. После того, как компьютер Beta отсылает сигнатуры, Alpha присылает байты из файла A или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла B нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> Конвейерная обработка<br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как ftp, rcp или rdist обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> Схема конвейерной обработки<br /> Схема конвейерной обработки<br /> <br /> Процесс разбивается на 3 части — Generator, Sender и Receiver. Generator запускается на компьютере Beta и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к Alpha. Sender, запущенный на Alpha получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты Beta. Receiver, запущенный на Beta, реконструирует файл, после чего он связывается с Generator, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> Заключение<br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> Rsync technical report. Andrew Tridgell и Paul Mackerras. 1998г.<br /> Efficient Algorithms for Sorting and Synchronization. Andrew Tridgell. 2000г.<br /> Zlib Technical Details. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=249 2013-07-10T14:53:16Z

<p>Nordwind: /* Алгоритм */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> ==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;Общий алгоритм&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на adler32 от Марка Адлера. Adler32 — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> Поиск сигнатур<br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32 битной сигнатуры, а значением — сумма двух её (16 битных) половин.<br /> Поиск сигнатур<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле A, который есть в файле B. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков Alpha отсылает Beta данные из файла A между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в B. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле A, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> Реконструкция файла<br /> Одна из простых частей алгоритма rsync — реконструкция файла. После того, как компьютер Beta отсылает сигнатуры, Alpha присылает байты из файла A или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла B нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> Конвейерная обработка<br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как ftp, rcp или rdist обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> Схема конвейерной обработки<br /> Схема конвейерной обработки<br /> <br /> Процесс разбивается на 3 части — Generator, Sender и Receiver. Generator запускается на компьютере Beta и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к Alpha. Sender, запущенный на Alpha получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты Beta. Receiver, запущенный на Beta, реконструирует файл, после чего он связывается с Generator, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> Заключение<br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> Rsync technical report. Andrew Tridgell и Paul Mackerras. 1998г.<br /> Efficient Algorithms for Sorting and Synchronization. Andrew Tridgell. 2000г.<br /> Zlib Technical Details. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=248 2013-07-10T14:46:31Z

<p>Nordwind: </p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> ==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;Общий алгоритм&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на adler32 от Марка Адлера. Adler32 — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> Поиск сигнатур<br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32 битной сигнатуры, а значением — сумма двух её (16 битных) половин.<br /> Поиск сигнатур<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле A, который есть в файле B. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков Alpha отсылает Beta данные из файла A между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в B. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле A, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> Реконструкция файла<br /> Одна из простых частей алгоритма rsync — реконструкция файла. После того, как компьютер Beta отсылает сигнатуры, Alpha присылает байты из файла A или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла B нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> Конвейерная обработка<br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как ftp, rcp или rdist обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> Схема конвейерной обработки<br /> Схема конвейерной обработки<br /> <br /> Процесс разбивается на 3 части — Generator, Sender и Receiver. Generator запускается на компьютере Beta и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к Alpha. Sender, запущенный на Alpha получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты Beta. Receiver, запущенный на Beta, реконструирует файл, после чего он связывается с Generator, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> Заключение<br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> Rsync technical report. Andrew Tridgell и Paul Mackerras. 1998г.<br /> Efficient Algorithms for Sorting and Synchronization. Andrew Tridgell. 2000г.<br /> Zlib Technical Details. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=247 2013-07-10T14:44:54Z

<p>Nordwind: /* Для чего он нужен? */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> ==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;=== Общий алгоритм ===&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;=== Алгоритм &lt;tt&gt;rsync&lt;/tt&gt; ===&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на adler32 от Марка Адлера. Adler32 — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> Поиск сигнатур<br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32 битной сигнатуры, а значением — сумма двух её (16 битных) половин.<br /> Поиск сигнатур<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле A, который есть в файле B. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков Alpha отсылает Beta данные из файла A между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в B. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле A, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> Реконструкция файла<br /> Одна из простых частей алгоритма rsync — реконструкция файла. После того, как компьютер Beta отсылает сигнатуры, Alpha присылает байты из файла A или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла B нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> Конвейерная обработка<br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как ftp, rcp или rdist обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> Схема конвейерной обработки<br /> Схема конвейерной обработки<br /> <br /> Процесс разбивается на 3 части — Generator, Sender и Receiver. Generator запускается на компьютере Beta и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к Alpha. Sender, запущенный на Alpha получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты Beta. Receiver, запущенный на Beta, реконструирует файл, после чего он связывается с Generator, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> Заключение<br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> Rsync technical report. Andrew Tridgell и Paul Mackerras. 1998г.<br /> Efficient Algorithms for Sorting and Synchronization. Andrew Tridgell. 2000г.<br /> Zlib Technical Details. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_Rsync&diff=246 2013-07-10T14:42:46Z

<p>Nordwind: Новая страница: «==Для чего он нужен?== Современные средства и протоколы удалённого копирования файлов (на…»</p> <hr /> <div>==Для чего он нужен?==<br /> <br /> Современные средства и протоколы удалённого копирования файлов (например, http, ftp, rcp), каждый раз полностью пересылают данные, несмотря на возможно уже существующею старую версию этих данных. Хотя и возможно воссоздать только изменения, например, с помощью утилиты diff, если существует старая копия наряду с новой, и тем самым пересылать только изменения, но в практике это не всегда удобно и часто приводит к ошибкам.<br /> <br /> Задачи алгоритма &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> <br /> # Он должен работать с произвольными данными, не только с обычным текстом.<br /> # Размер передаваемых данных должен быть примерно равен размеру diff файла.<br /> # Он должен быстро работать с большими файлами.<br /> # Алгоритм не должен иметь какие-либо предварительные знания о статусе этих файлов, но должен эффективно находить их возможные сходства.<br /> # Использовать мало ресурсов. <br /> <br /> Представим, что у нас имеются файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;, и мы хотим обновить &#039;&#039;&#039;B&#039;&#039;&#039; таким образом, чтобы его содержимое было идентично содержимому файла &#039;&#039;&#039;A&#039;&#039;&#039;. Самый простой и очевидный способ — это скопировать &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Теперь представим, что эти файлы находятся на двух разных машинах, соединённых медленным каналом связи, например, с помощью &lt;tt&gt;dialup&lt;/tt&gt; модема. Если файл &#039;&#039;&#039;A&#039;&#039;&#039; большой, копирование &#039;&#039;&#039;A&#039;&#039;&#039; в &#039;&#039;&#039;B&#039;&#039;&#039; будет происходить очень медленно. Чтобы сделать это быстрее, мы можем сжать &#039;&#039;&#039;A&#039;&#039;&#039;, перед тем как пересылать его. Но обычный коэффициент сжатия колеблется от 2 до 4, что так же не подойдёт для нашей медленной связи.<br /> <br /> Предположим, что файлы &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; почти одинаковы (возможно, оба были получены из одного общего файла). Для увеличения производительности копирования мы можем воспользоваться преимуществом их сходства. Обычное решение этой проблемы заключается в том, чтобы пересылать только изменения между файлами &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039; и затем использовать их для реконструкции фала &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Но проблема в том, что для получения этих изменений необходимо иметь возможность чтения обоих файлов. Поэтому нам нужно иметь оба файла на одной из сторон нашего соединения. В противном случае, этот алгоритм использоваться не может. Для решения этой проблемы и был разработан алгоритм &lt;tt&gt;rsync&lt;/tt&gt;.<br /> <br /> == Алгоритм ==<br /> <br /> &#039;&#039;&#039;=== Общий алгоритм ===&#039;&#039;&#039;<br /> <br /> На двух разных компьютерах &#039;&#039;Alpha&#039;&#039; и &#039;&#039;Beta&#039;&#039;, соединённых медленным каналом связи (например, через модем), находятся два файла &#039;&#039;&#039;A&#039;&#039;&#039; и &#039;&#039;&#039;B&#039;&#039;&#039;.<br /> <br /> Структура алгоритма:<br /> <br /> # &#039;&#039;Beta&#039;&#039; отсылает некоторые данные &#039;&#039;&#039;S&#039;&#039;&#039; на компьютер &#039;&#039;Alpha&#039;&#039; <br /> # &#039;&#039;Alpha&#039;&#039; сравнивает эти данные с файлом &#039;&#039;&#039;A&#039;&#039;&#039; и отсылает некоторые данные &#039;&#039;&#039;D&#039;&#039;&#039; на компьютер &#039;&#039;Beta&#039;&#039; <br /> # &#039;&#039;Beta&#039;&#039; создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039; на основе файла &#039;&#039;&#039;B&#039;&#039;&#039;, данных &#039;&#039;&#039;S&#039;&#039;&#039; и &#039;&#039;&#039;D&#039;&#039;&#039; <br /> <br /> Главный вопрос в том, какую форму примут данные &#039;&#039;&#039;S&#039;&#039;&#039;, как компьютер &#039;&#039;Alpha&#039;&#039; будет использовать &#039;&#039;&#039;S&#039;&#039;&#039; для сопоставления с файлом &#039;&#039;&#039;A&#039;&#039;&#039;, и как &#039;&#039;Beta&#039;&#039; будет реконструировать &#039;&#039;A&#039;&#039;.<br /> <br /> &#039;&#039;&#039;=== Алгоритм &lt;tt&gt;rsync&lt;/tt&gt; ===&#039;&#039;&#039;<br /> <br /> Алгоритм &lt;tt&gt;rsync&lt;/tt&gt;:<br /> <br /> # &#039;&#039;Beta&#039;&#039; разбивает файл &#039;&#039;&#039;B&#039;&#039;&#039; на блоки длиной &#039;&#039;&#039;L&#039;&#039;&#039; (последний блок может быть меньше &#039;&#039;&#039;L&#039;&#039;&#039;байт) и вычисляет две сигнатуры &#039;&#039;&#039;Rb&#039;&#039;&#039; и &#039;&#039;&#039;Sb&#039;&#039;&#039; для каждого блока, после чего пересылает эти сигнатуры к &#039;&#039;Alpha&#039;&#039;. <br /> # &#039;&#039;Alpha&#039;&#039; вычисляет сигнатуры &#039;&#039;Ra&#039;&#039; для блоков длиной &#039;&#039;&#039;L&#039;&#039;&#039; для каждого байтового смещения. После чего сравнивает их с &#039;&#039;&#039;Rb&#039;&#039;&#039;. <br /> # Для блоков, чьи &#039;&#039;&#039;R&#039;&#039;&#039; сигнатуры совпали, &#039;&#039;Alpha&#039;&#039; вычисляет &#039;&#039;&#039;Sa&#039;&#039;&#039; и сравнивает с &#039;&#039;&#039;Sb&#039;&#039;&#039;. <br /> # Если &#039;&#039;&#039;S&#039;&#039;&#039; сигнатуры совпадают, &#039;&#039;Alpha&#039;&#039; отсылает уведомление с номером совпавшего блока, в противном случае &#039;&#039;Alpha&#039;&#039; пересылает один байт. <br /> # &#039;&#039;Beta&#039;&#039; получает номера совпавших блоков из &#039;&#039;&#039;B&#039;&#039;&#039; или одиночные байты из файла &#039;&#039;&#039;A&#039;&#039;&#039; и на основе этих данных создаёт копию файла &#039;&#039;&#039;A&#039;&#039;&#039;. <br /> <br /> Важно понимать, что ключом алгоритма является создание двух сигнатур — быстрой и стойкой. Быстрая (&#039;&#039;&#039;R&#039;&#039;&#039;) используется как фильтр (на компьютере &#039;&#039;Alpha&#039;&#039; она вычисляется для каждого байтового смещения!). Стойкая (&#039;&#039;S&#039;&#039;) используется для более точной проверки.<br /> [[File:rsync.gif|link=http://www.openbsd.pw/files/openbsd_ru/docs/images/rsync.gif|Алгоритм rsync]] <br /> Алгоритм rsync<br /> <br /> == Стойкая сигнатура ==<br /> <br /> Стойкая сигнатура может не быть быстрой, так как вычисляется только при совпадении простой, быстрой сигнатуры. Главным свойством стойкой сигнатуры должна быть минимальная вероятность отказа, иначе говоря, наличие одной и той же сигнатуры для двух разных блоков.<br /> <br /> Существует множество алгоритмов с такими свойствами, возможно, наиболее известный — это алгоритм хеширования &#039;&#039;Message Digest&#039;&#039;. Он часто используется в криптографических программах.<br /> <br /> == Быстрая сигнатура ==<br /> <br /> Быстрая сигнатура очень важна для эффективности алгоритма &lt;tt&gt;rsync&lt;/tt&gt;. Она работает как фильтр, предотвращая вычисление стойкой сигнатуры. Основная задача быстрой сигнатуры — это максимально быстрое её вычисление для каждого байтового смещения в файле.<br /> <br /> Первоначально для создания быстрой сигнатуры в &lt;tt&gt;rsync&lt;/tt&gt; было опробовано простое склеивание первых и последних 4 байт блока. Хотя такой алгоритм, в принципе, работал, но был выявлен его серьёзный недостаток. Для определённых типов данных, например, для &lt;tt&gt;tar&lt;/tt&gt; файла, он слишком часто создавал одинаковые сигнатуры для разных частей файла, что приводило к многократному вычислению стойкой сигнатуры и, как следствие, падению производительности всего алгоритма.<br /> <br /> Это привело к необходимости выбора нового алгоритма для вычисления быстрой сигнатуры, значение которого зависело бы от всех байт блока, но при этом вычисление оставалось таким же простым и быстрым. Им стал алгоритм, похожий на adler32 от Марка Адлера. Adler32 — алгоритм расчёта контрольных сумм, похожий на довольно распространённый алгоритм CRC32, но при этом более быстрый.<br /> Поиск сигнатур<br /> Для эффективности поиска используется хеширование быстрой сигнатуры и трехуровневый поиск. Ключом хеш-функции является значение 32 битной сигнатуры, а значением — сумма двух её (16 битных) половин.<br /> Поиск сигнатур<br /> Поиск сигнатур<br /> <br /> На первом уровне формируется хеш-таблица размером в 2^16 элементов. Ключом хеш-функции является быстрая 32 битная сигнатура. Для каждой пары быстрой и стойкой сигнатуры, полученной от Beta, вычисляется 16 битный хеш 32 битной сигнатуры, после чего все это сортируется согласно 16 битному хешу. Каждый элемент хеш-таблицы указывает на первый элемент сортированных сигнатур, хеш значения которых совпадают, либо хранит в себе NULL, если сигнатур с таким хешом нет. Номер элемента хеш-таблицы соответствует значению хеш-функции, а именно сумме двух половин быстрой 32 битной сигнатуры.<br /> <br /> Затем для каждого байтового смещения вычисляется быстрая 32 битная сигнатура и 16 битное хеш-значение. Если элемент хеш-таблицы для этого хеш-значения не равен NULL, алгоритм поиска переходит на следующий уровень.<br /> <br /> На втором уровне происходит линейный поиск по сортированному списку сигнатур, начиная с элемента, указанного в хеш-таблице. Мы ищем быструю 32 битную сигнатуру, чьё значение совпадает с необходимым нам значением. Поиск прекращается при первом же несовпадении 16 битной сигнатуры. Если мы нашли такую 32 битную сигнатуру, алгоритм переходит на следующий уровень.<br /> <br /> На третьем уровне происходит вычисление стойкой сигнатуры для текущего смещения в файле и сравнение его со значением стойкой сигнатуры в сортированном списке. При совпадении предполагается, что мы нашли блок в файле A, который есть в файле B. Фактически, блоки могут быть различны, но вероятность этого очень мала.<br /> <br /> При совпадении блоков Alpha отсылает Beta данные из файла A между текущим смещением и предыдущим совпадением, а также индекс совпавшего блока, который есть в B. Эти данные отсылаются сразу же при нахождении совпадения.<br /> <br /> Если совпадения найдено не было для текущего смещения в файле A, вычисляется быстрая сигнатура для следующего байтового смещения и процедура поиска повторяется. При совпадении смещение увеличивается на размер совпавшего блока, и поиск продолжается.<br /> Реконструкция файла<br /> Одна из простых частей алгоритма rsync — реконструкция файла. После того, как компьютер Beta отсылает сигнатуры, Alpha присылает байты из файла A или сообщения, которые содержат номера совпавших блоков.<br /> <br /> Для реконструкции файла B нам необходимо последовательно вписывать полученные байты в файл и при получении сообщения о совпавшем блоке вписывать целый блок из старого файла. Реконструкция не производится непосредственно в старом файле, так как нам необходим произвольный доступ к старым данным. Для реконструкции создаётся временный файл, который затем переименовывается.<br /> Конвейерная обработка<br /> Важным фактором быстродействия является задержка между пересылаемыми файлами. Обычно используемые протоколы передачи данных, такие как ftp, rcp или rdist обрабатывают каждый файл как отдельную операцию, тем самым ожидая подтверждения о доставке текущего файла, перед тем как обрабатывать следующий.<br /> <br /> При использовании большого количества маленьких файлов (например, обычное зеркалирование Web сайта) для пересылки через Internet, это время ожидания может сыграть роковую роль. Чтобы избежать этого, мы можем пересылать, не ожидая подтверждения. Этот метод также известен, как конвейерная обработка.<br /> Схема конвейерной обработки<br /> Схема конвейерной обработки<br /> <br /> Процесс разбивается на 3 части — Generator, Sender и Receiver. Generator запускается на компьютере Beta и генерирует сигнатуры для всех файлов, которые необходимо переслать, и отсылает эти сигнатуры к Alpha. Sender, запущенный на Alpha получает сигнатуры и отсылает сообщения о совпавших блоках или целые байты Beta. Receiver, запущенный на Beta, реконструирует файл, после чего он связывается с Generator, чтобы сообщить об успешной передачи файла, либо передать ему, что определённый файл необходимо обработать заново.<br /> Заключение<br /> Алгоритм rsync предоставляет эффективное решение проблемы удалённого обновления файлов. Метод двух сигнатур, используемый в алгоритме, позволяет эффективно находить совпадения на любом смещении файла. Алгоритм гарантирует точность передачи, подтверждая подлинность блока стойкой сигнатурой.<br /> Используемая литература<br /> <br /> Rsync technical report. Andrew Tridgell и Paul Mackerras. 1998г.<br /> Efficient Algorithms for Sorting and Synchronization. Andrew Tridgell. 2000г.<br /> Zlib Technical Details. Jean-loup Gailly и Mark Adler.</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenSSH_%D0%BC%D0%B8%D0%BD%D0%B8-%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE&diff=245 2013-06-14T17:07:05Z

<p>Nordwind: </p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Генерируем пару ключей (секретный и публичный):<br /> <br /> &lt;pre&gt;<br /> % ssh-keygen -t rsa<br /> Generating public/private rsa key pair.<br /> Enter file in which to save the key (/home/andrushock/.ssh/id_rsa):<br /> Enter passphrase (empty for no passphrase):<br /> Enter same passphrase again:<br /> Your identification has been saved in /home/andrushock/.ssh/id_rsa.<br /> Your public key has been saved in /home/andrushock/.ssh/id_rsa.pub.<br /> The key fingerprint is:<br /> 25:95:5b: a6:d7:26:b6:f5:f9:a7:49:d4:a8:2a:0d:7d andrushock@midian<br /> &lt;/pre&gt;<br /> <br /> Проверяем корректность прав доступа к директории &lt;span style=&quot;color:green;&quot;&gt;.ssh&lt;/span&gt; и RSA-ключам:<br /> <br /> &lt;pre&gt;<br /> % ls -la .ssh | egrep -v &#039;total|\.\.&#039;<br /> drwx------ 2 andrushock wsrc 512 Oct 19 20:42 ./<br /> -rw------- 1 andrushock wsrc 1743 Jun 11 03:35 id_rsa<br /> -rw-r--r-- 1 andrushock wsrc 413 Jun 11 03:35 id_rsa.pub<br /> &lt;/pre&gt;<br /> <br /> Добавляем публичный ключ в список авторизованных ключей на удаленной системе:<br /> <br /> % ssh user@host «cat &gt;&gt; .ssh/authorized_keys» &lt; .ssh/id_rsa.pub<br /> <br /> В случае, если подкаталог &lt;span style=&quot;color:green;&quot;&gt;.ssh&lt;/span&gt; и файл &lt;span style=&quot;color:green;&quot;&gt;.ssh/authorized_keys&lt;/span&gt; на удаленной системе не существуют:<br /> <br /> % ssh user@host «mkdir -m 700 .ssh; umask 077; cat &gt; .ssh/authorized_keys» &lt; .ssh/id_rsa.pub<br /> <br /> Для сохранения парольных фраз к приватным ключам запускаем [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent&amp;apropos=0&amp;sektion=1&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ssh-agent(1)]:<br /> <br /> &lt;pre&gt;<br /> % eval `/usr/bin/ssh-agent`<br /> Agent pid 3855<br /> &lt;/pre&gt;<br /> <br /> С помощью [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add&amp;apropos=0&amp;sektion=1&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ssh-add(1)] добавляем в память агента парольную фразу от нашего ключа:<br /> <br /> &lt;pre&gt;<br /> % ssh-add<br /> Enter passphrase for /home/andrushock/.ssh/id_rsa:<br /> Identity added: /home/andrushock/.ssh/id_rsa (/home/andrushock/.ssh/id_rsa)<br /> &lt;/pre&gt;<br /> <br /> Для проверки просматриваем отпечаток секретного ключа:<br /> <br /> &lt;pre&gt;<br /> % ssh-add -l<br /> 2048 25:95:5b: a6:d7:26:b6:f5:f9:a7:49:d4:a8:2a:0d:7d /home/andrushock/.ssh/id_rsa (RSA)<br /> &lt;/pre&gt;<br /> <br /> Выполняем вход на удаленный сервер без ввода пароля и парольной фразы:<br /> <br /> &lt;pre&gt;<br /> % ssh user@host<br /> OpenBSD 3.7-current (GENERIC) #1: Mon Aug 1 00:37:53 MSD 2005<br /> <br /> Welcome to OpenBSD: The proactively secure Unix-like operating system.<br /> <br /> $<br /> &lt;/pre&gt;<br /> <br /> Пример использования функций оболочки для упрощения беспарольной аутентификации:<br /> <br /> % vi .profile<br /> <br /> &lt;source lang=&quot;bash&quot;&gt;<br /> ssh_agent_start() {<br /> id1=$HOME/.ssh/identity<br /> id2=$HOME/.ssh/id_dsa<br /> id3=$HOME/.ssh/id_rsa<br /> if [ ! «$SSH_AGENT_PID» ] &amp;&amp; [ -f $id1 -o -f $id2 -o -f $id3 ]; then<br /> eval `/usr/bin/ssh-agent -s`<br /> /usr/bin/ssh-add &lt; /dev/null<br /> export SSH_AGENT_SHELL=$$<br /> fi<br /> }<br /> <br /> ssh_agent_stop() {<br /> if [ «$SSH_AGENT_PID» -a &quot;$SSH_AGENT_SHELL&quot;x = &quot;$$&quot;x ]; then<br /> /usr/bin/ssh-add -D &lt; /dev/null<br /> eval `/usr/bin/ssh-agent -sk`<br /> fi<br /> }<br /> <br /> ssh_agent_start<br /> trap ssh_agent_stop 0 1<br /> &lt;/source&gt;<br /> <br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9F%D1%80%D0%B8%D0%B2%D1%8F%D0%B7%D0%BA%D0%B0_IP_%D0%BA_MAC_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_bridge(4)_%D0%B8_pf(4)&diff=244 2013-06-14T17:06:23Z

<p>Nordwind: </p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство &quot;шаг за шагом&quot; ==<br /> <br /> Пример предоставления клиентам доступа к ресурсам сети с привязкой IP к MAC с помощью &lt;tt&gt;bridge&lt;/tt&gt; и &lt;tt&gt;pf&lt;/tt&gt;. В данном случае для создания моста достаточно одного внутреннего сетевого интерфейса &lt;tt&gt;ral0&lt;/tt&gt;.<br /> <br /> &lt;pre&gt;<br /> Сервер. IP: 192.168.2.1<br /> Клиент 1. Hostname: evol, IP: 192.168.2.2, MAC: 00:0f:ea:91:43:f6<br /> Клиент 2. Hostname: aurora, IP: 192.168.2.3, MAC: 00:80:c8:2c:47:a1 <br /> &lt;/pre&gt;<br /> <br /> Включаем перенаправление IPv4-пакетов между сетевыми интерфейсами:<br /> <br /> # sysctl -w net.inet.ip.forwarding=1<br /> <br /> Добавляем соответствующую запись в &lt;span style=&quot;color:green;&quot;&gt;/etc/sysctl.conf&lt;/span&gt;:<br /> <br /> # vi /etc/sysctl.conf<br /> net.inet.ip.forwarding=1<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridgename.bridge0&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridgename.bridge0<br /> add ral0<br /> blocknonip ral0<br /> link0<br /> -discover ral0<br /> -learn ral0<br /> flushall<br /> static ral0 00:0f: ea:91:43:f6<br /> static ral0 00:80:c8:2c:47:a1<br /> up<br /> rulefile /etc/bridge.conf<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridge.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridge.conf<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> &lt;/pre&gt;<br /> <br /> Создаем и поднимаем псевдоустройство &lt;tt&gt;bridge&lt;/tt&gt;:<br /> <br /> # ifconfig bridge0 create<br /> # sh /etc/netstart bridge0<br /> <br /> Для проверки смотрим информацию о бридже:<br /> <br /> &lt;pre&gt;<br /> # brconfig bridge0<br /> bridge0: flags=1041&lt;UP,RUNNING,LINK0&gt;<br /> Configuration:<br /> priority 32768 hellotime 2 fwddelay 15 maxage 20<br /> Interfaces:<br /> ral0 flags=4&lt;BLOCKNONIP&gt;<br /> port 2 ifpriority 128 ifcost 55<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> Addresses (max cache: 100, timeout: 240):<br /> 00:80:c8:2c:47:a1 ral0 1 flags=1&lt;STATIC&gt;<br /> 00:0f: ea:91:43:f6 ral0 1 flags=1&lt;STATIC&gt;<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/pf.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/pf.conf<br /> ext_if = «vr0»<br /> int_if = «ral0»<br /> <br /> evol = «192.168.2.2»<br /> aurora = «192.168.2.3»<br /> <br /> nat on $ext_if inet from { $evol, $aurora } to any -&gt; ($ext_if)<br /> <br /> block in quick on $int_if from ! $evol to any tagged evol<br /> block in quick on $int_if from ! $aurora to any tagged aurora<br /> <br /> block return<br /> <br /> pass quick on { lo, $int_if } inet all<br /> pass quick on $ext_if inet all keep state<br /> &lt;/pre&gt;<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> Дополнительную информацию можно получить, прочитав статью «[[Настройка Ethernet Bridge]]», а также из справочных man-страниц: [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html bridge(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=pf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)], [http://www.openbsd.org/cgi-bin/man.cgi?query=netstart&amp;sektion=8&amp;apropos=0&amp;manpath=OpenBSD+Current&amp;arch=i386 netstart(8)].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=243 2013-06-14T17:05:36Z

<p>Nordwind: /* Устаревшее */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Использование сетевой файловой системы NFS]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Настройка PPPoE-сервера]]<br /> * [[Настройка PPPoE-клиента с помощью pppoe(8)]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> * [[Настройка Ethernet Bridge]]<br /> * [[Привязка IP к MAC с помощью bridge(4) и pf(4)]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_Ethernet_Bridge&diff=242 2013-06-14T17:04:27Z

<p>Nordwind: </p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> Использование Ethernet Bridge позволяет объединить несколько сегментов Ethernet в один логический сегмент. При этом допустимо использование правил фильтрации &lt;tt&gt;pf&lt;/tt&gt;, что позволяет превратить OpenBSD в прозрачный IP фильтр.<br /> <br /> Чтобы настроить OpenBSD в качестве Ethernet Bridge, нужно выполнить следующие шаги:<br /> <br /> * Сконфигурировать ядро OpenBSD, включив в него псевдоустройство &lt;tt&gt;&quot;bridge&quot;&lt;/tt&gt;. Файл конфигурации ядра должен содержать строку &lt;tt&gt;&#039;&#039;&#039;&quot;pseudo-device bridge&quot;&#039;&#039;&#039;&lt;/tt&gt;.<br /> * Создать файл конфигурации &lt;span style=&quot;color:green;&quot;&gt;/etc/bridgename.bridge0&lt;/span&gt;, содержащий команды конфигурации Bridge, например:<br /> <br /> &lt;pre&gt;<br /> add rl0<br /> add fxp0<br /> up<br /> &lt;/pre&gt;<br /> <br /> В данном случае мы объявляем интерфейсы &lt;tt&gt;fxp0&lt;/tt&gt; и &lt;tt&gt;rl0&lt;/tt&gt; одним логическим Ethernet сегментом. Подробнее о командах конфигурирования Bridge можно прочитать в [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)]. При использовании нескольких логических сегментов следует создать файл конфигурации для каждого псевдоустройства bridge.<br /> <br /> * Создать файлы конфигурации сетевых интерфейсов:<br /> <br /> &lt;span style=&quot;color:green;&quot;&gt;/etc/hostname.fxp0&lt;/span&gt;:<br /> <br /> inet 194.226.170.3 255.255.255.0 NONE<br /> <br /> &lt;span style=&quot;color:green;&quot;&gt;/etc/hostname.rl0&lt;/span&gt;:<br /> <br /> up<br /> <br /> Подробнее о файлах конфигурации сетевых интерфейсов можно прочитать в [http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if&amp;sektion=5&amp;arch=i386&amp;apropos=0&amp;manpath=OpenBSD+Current hostname.if(5)]<br /> <br /> Обратите внимание, что в данном случае IP адрес присваивается только одному интерфейсу. Допускается также создание Bridge, не имеющего своего IP адреса.<br /> <br /> * Перезагрузить машину. <br /> <br /> Ethernet Bridge также позволяет с помощью протокола &lt;tt&gt;Ethernet-over-IP&lt;/tt&gt; объединить в один логический сегмент сети, физически находящиеся далеко друг от друга. Рассмотрим следующий пример:<br /> <br /> : Хост &#039;&#039;&#039;A&#039;&#039;&#039;, адрес 81.1.212.10, внутренний интерфейс &#039;&#039;&#039;em0&#039;&#039;&#039;<br /> : Хост &#039;&#039;&#039;B&#039;&#039;&#039;, адрес 81.1.226.48, внутренний интерфейс &#039;&#039;&#039;rl0&#039;&#039;&#039;<br /> <br /> Чтобы объединить сегменты интерфейса &lt;tt&gt;&#039;&#039;&#039;em0&#039;&#039;&#039;&lt;/tt&gt; хоста &#039;&#039;&#039;A&#039;&#039;&#039; и &lt;tt&gt;&#039;&#039;&#039;rl0&#039;&#039;&#039;&lt;/tt&gt; хоста &#039;&#039;&#039;B&#039;&#039;&#039; в один логический Ethernet сегмент, нужно подать следующие команды:<br /> <br /> Для хоста &#039;&#039;&#039;A&#039;&#039;&#039;:<br /> <br /> # sysctl -w net.inet.etherip.allow=1<br /> # ifconfig gif0 tunnel 81.1.212.10 81.1.226.48<br /> # ifconfig bridge0 create<br /> # brconfig bridge0 add em0 add gif0 up<br /> <br /> Для хоста &#039;&#039;&#039;B&#039;&#039;&#039;:<br /> <br /> # sysctl -w net.inet.etherip.allow=1<br /> # ifconfig gif0 tunnel 81.1.226.48 81.1.212.10<br /> # ifconfig bridge0 create<br /> # brconfig bridge0 add rl0 add gif0 up<br /> <br /> Замечания<br /> <br /> * При использовании OpenBSD Packet Filter пакет, проходящий через Bridge, попадает под проверку PF два раза: при входе на одном интерфейсе и при выходе на другом. Чтобы производить &lt;tt&gt;keep-state&lt;/tt&gt; фильтрацию, нам необходимо разрешить все входящие и исходящие пакеты на одном интерфейсе, а на другом производить фильтрацию. Пример правил:<br /> <br /> # фильтрация производится на rl0, поэтому пропускаем все пакеты на rl1<br /> pass quick on rl1<br /> <br /> # по умолчанию мы блокируем все пакеты и пропускаем только<br /> # icmp запросы с получившимися keep-state ответами в обе стороны.<br /> block on rl0<br /> pass on rl0 inet proto icmp icmp-type echoreq code 0 keep state<br /> <br /> * При использовании &lt;tt&gt;pf&lt;/tt&gt; для фильтрации пакетов, проходящих через Bridge, действуют только правила для входящих пакетов.<br /> * Если во время работы Bridge производится перенос какого-нибудь компьютера (или другого устройства, имеющего свой Ethernet адрес) с одного Ethernet сегмента на другой, следует выполнить команду<br /> <br /> # brconfig bridge0 flush<br /> <br /> (где &lt;tt&gt;bridge0&lt;/tt&gt; - псевдоинтерфейс Bridge, к которому относится Ethernet сегмент, где раньше находился компьютер). <br /> <br /> Смотрите также по данной теме пошаговое [[Привязка IP к MAC с помощью bridge(4) и pf(4)|руководство]], в котором рассматривается привязка IP к MAC с помощью &lt;tt&gt;bridge&lt;/tt&gt; и &lt;tt&gt;pf&lt;/tt&gt;. <br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_Ethernet_Bridge&diff=241 2013-06-14T16:54:24Z

<p>Nordwind: Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] Использование Ethernet Bridge позволяет об…»</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> Использование Ethernet Bridge позволяет объединить несколько сегментов Ethernet в один логический сегмент. При этом допустимо использование правил фильтрации &lt;tt&gt;pf&lt;/tt&gt;, что позволяет превратить OpenBSD в прозрачный IP фильтр.<br /> <br /> Чтобы настроить OpenBSD в качестве Ethernet Bridge, нужно выполнить следующие шаги:<br /> <br /> # Сконфигурировать ядро OpenBSD, включив в него псевдоустройство &lt;tt&gt;&quot;bridge&quot;&lt;/tt&gt;. Файл конфигурации ядра должен содержать строку &lt;tt&gt;&#039;&#039;&#039;&quot;pseudo-device bridge&quot;&#039;&#039;&#039;&lt;/tt&gt;.<br /> # Создать файл конфигурации &lt;span style=&quot;color:green;&quot;&gt;/etc/bridgename.bridge0&lt;/span&gt;, содержащий команды конфигурации Bridge, например:<br /> <br /> add rl0<br /> add fxp0<br /> up<br /> <br /> В данном случае мы объявляем интерфейсы &lt;tt&gt;fxp0&lt;/tt&gt; и &lt;tt&gt;rl0&lt;/tt&gt; одним логическим Ethernet сегментом. Подробнее о командах конфигурирования Bridge можно прочитать в [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)]. При использовании нескольких логических сегментов следует создать файл конфигурации для каждого псевдоустройства bridge.<br /> <br /> # Создать файлы конфигурации сетевых интерфейсов:<br /> <br /> &lt;span style=&quot;color:green;&quot;&gt;/etc/hostname.fxp0&lt;/span&gt;:<br /> <br /> inet 194.226.170.3 255.255.255.0 NONE<br /> <br /> &lt;span style=&quot;color:green;&quot;&gt;/etc/hostname.rl0&lt;/span&gt;:<br /> <br /> up<br /> <br /> * Подробнее о файлах конфигурации сетевых интерфейсов можно прочитать в [http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if&amp;sektion=5&amp;arch=i386&amp;apropos=0&amp;manpath=OpenBSD+Current hostname.if(5)]<br /> <br /> * Обратите внимание, что в данном случае IP адрес присваивается только одному интерфейсу. Допускается также создание Bridge, не имеющего своего IP адреса.<br /> <br /> # Перезагрузить машину. <br /> <br /> Ethernet Bridge также позволяет с помощью протокола &lt;tt&gt;Ethernet-over-IP&lt;/tt&gt; объединить в один логический сегмент сети, физически находящиеся далеко друг от друга. Рассмотрим следующий пример:<br /> <br /> * Хост &#039;&#039;&#039;A&#039;&#039;&#039;, адрес 81.1.212.10, внутренний интерфейс &#039;&#039;&#039;em0&#039;&#039;&#039;<br /> * Хост &#039;&#039;&#039;B&#039;&#039;&#039;, адрес 81.1.226.48, внутренний интерфейс &#039;&#039;&#039;rl0&#039;&#039;&#039;<br /> <br /> Чтобы объединить сегменты интерфейса &lt;tt&gt;&#039;&#039;&#039;em0&#039;&#039;&#039;&lt;/tt&gt; хоста &#039;&#039;&#039;A&#039;&#039;&#039; и &lt;tt&gt;&#039;&#039;&#039;rl0&#039;&#039;&#039;&lt;/tt&gt; хоста &#039;&#039;&#039;B&#039;&#039;&#039; в один логический Ethernet сегмент, нужно подать следующие команды:<br /> <br /> Для хоста &#039;&#039;&#039;A&#039;&#039;&#039;:<br /> <br /> # sysctl -w net.inet.etherip.allow=1<br /> # ifconfig gif0 tunnel 81.1.212.10 81.1.226.48<br /> # ifconfig bridge0 create<br /> # brconfig bridge0 add em0 add gif0 up<br /> <br /> Для хоста &#039;&#039;&#039;B&#039;&#039;&#039;:<br /> <br /> # sysctl -w net.inet.etherip.allow=1<br /> # ifconfig gif0 tunnel 81.1.226.48 81.1.212.10<br /> # ifconfig bridge0 create<br /> # brconfig bridge0 add rl0 add gif0 up<br /> <br /> Замечания<br /> <br /> * При использовании OpenBSD Packet Filter пакет, проходящий через Bridge, попадает под проверку PF два раза: при входе на одном интерфейсе и при выходе на другом. Чтобы производить &lt;tt&gt;keep-state&lt;/tt&gt; фильтрацию, нам необходимо разрешить все входящие и исходящие пакеты на одном интерфейсе, а на другом производить фильтрацию. Пример правил:<br /> <br /> # фильтрация производится на rl0, поэтому пропускаем все пакеты на rl1<br /> pass quick on rl1<br /> <br /> # по умолчанию мы блокируем все пакеты и пропускаем только<br /> # icmp запросы с получившимися keep-state ответами в обе стороны.<br /> block on rl0<br /> pass on rl0 inet proto icmp icmp-type echoreq code 0 keep state<br /> <br /> * При использовании &lt;tt&gt;pf&lt;/tt&gt; для фильтрации пакетов, проходящих через Bridge, действуют только правила для входящих пакетов.<br /> * Если во время работы Bridge производится перенос какого-нибудь компьютера (или другого устройства, имеющего свой Ethernet адрес) с одного Ethernet сегмента на другой, следует выполнить команду<br /> <br /> # brconfig bridge0 flush<br /> <br /> (где &lt;tt&gt;bridge0&lt;/tt&gt; - псевдоинтерфейс Bridge, к которому относится Ethernet сегмент, где раньше находился компьютер). <br /> <br /> Смотрите также по данной теме пошаговое [[Привязка IP к MAC с помощью bridge(4) и pf(4)|руководство]], в котором рассматривается привязка IP к MAC с помощью &lt;tt&gt;bridge&lt;/tt&gt; и &lt;tt&gt;pf&lt;/tt&gt;. <br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=240 2013-06-14T16:16:48Z

<p>Nordwind: /* Устаревшее */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Использование сетевой файловой системы NFS]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Настройка PPPoE-сервера]]<br /> * [[Настройка PPPoE-клиента с помощью pppoe(8)]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> * [[Привязка IP к MAC с помощью bridge(4) и pf(4)]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9F%D1%80%D0%B8%D0%B2%D1%8F%D0%B7%D0%BA%D0%B0_IP_%D0%BA_MAC_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_bridge(4)_%D0%B8_pf(4)&diff=239 2013-06-14T16:14:07Z

<p>Nordwind: /* Мини-руководство &quot;шаг за шагом&quot; */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство &quot;шаг за шагом&quot; ==<br /> <br /> Пример предоставления клиентам доступа к ресурсам сети с привязкой IP к MAC с помощью &lt;tt&gt;bridge&lt;/tt&gt; и &lt;tt&gt;pf&lt;/tt&gt;. В данном случае для создания моста достаточно одного внутреннего сетевого интерфейса &lt;tt&gt;ral0&lt;/tt&gt;.<br /> <br /> &lt;pre&gt;<br /> Сервер. IP: 192.168.2.1<br /> Клиент 1. Hostname: evol, IP: 192.168.2.2, MAC: 00:0f:ea:91:43:f6<br /> Клиент 2. Hostname: aurora, IP: 192.168.2.3, MAC: 00:80:c8:2c:47:a1 <br /> &lt;/pre&gt;<br /> <br /> Включаем перенаправление IPv4-пакетов между сетевыми интерфейсами:<br /> <br /> # sysctl -w net.inet.ip.forwarding=1<br /> <br /> Добавляем соответствующую запись в &lt;span style=&quot;color:green;&quot;&gt;/etc/sysctl.conf&lt;/span&gt;:<br /> <br /> # vi /etc/sysctl.conf<br /> net.inet.ip.forwarding=1<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridgename.bridge0&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridgename.bridge0<br /> add ral0<br /> blocknonip ral0<br /> link0<br /> -discover ral0<br /> -learn ral0<br /> flushall<br /> static ral0 00:0f: ea:91:43:f6<br /> static ral0 00:80:c8:2c:47:a1<br /> up<br /> rulefile /etc/bridge.conf<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridge.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridge.conf<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> &lt;/pre&gt;<br /> <br /> Создаем и поднимаем псевдоустройство &lt;tt&gt;bridge&lt;/tt&gt;:<br /> <br /> # ifconfig bridge0 create<br /> # sh /etc/netstart bridge0<br /> <br /> Для проверки смотрим информацию о бридже:<br /> <br /> &lt;pre&gt;<br /> # brconfig bridge0<br /> bridge0: flags=1041&lt;UP,RUNNING,LINK0&gt;<br /> Configuration:<br /> priority 32768 hellotime 2 fwddelay 15 maxage 20<br /> Interfaces:<br /> ral0 flags=4&lt;BLOCKNONIP&gt;<br /> port 2 ifpriority 128 ifcost 55<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> Addresses (max cache: 100, timeout: 240):<br /> 00:80:c8:2c:47:a1 ral0 1 flags=1&lt;STATIC&gt;<br /> 00:0f: ea:91:43:f6 ral0 1 flags=1&lt;STATIC&gt;<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/pf.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/pf.conf<br /> ext_if = «vr0»<br /> int_if = «ral0»<br /> <br /> evol = «192.168.2.2»<br /> aurora = «192.168.2.3»<br /> <br /> nat on $ext_if inet from { $evol, $aurora } to any -&gt; ($ext_if)<br /> <br /> block in quick on $int_if from ! $evol to any tagged evol<br /> block in quick on $int_if from ! $aurora to any tagged aurora<br /> <br /> block return<br /> <br /> pass quick on { lo, $int_if } inet all<br /> pass quick on $ext_if inet all keep state<br /> &lt;/pre&gt;<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> Дополнительную информацию можно получить, прочитав статью «Настройка Ethernet Bridge», а также из справочных man-страниц: [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html bridge(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=pf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)], [http://www.openbsd.org/cgi-bin/man.cgi?query=netstart&amp;sektion=8&amp;apropos=0&amp;manpath=OpenBSD+Current&amp;arch=i386 netstart(8)].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9F%D1%80%D0%B8%D0%B2%D1%8F%D0%B7%D0%BA%D0%B0_IP_%D0%BA_MAC_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_bridge(4)_%D0%B8_pf(4)&diff=238 2013-06-14T16:13:05Z

<p>Nordwind: Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство &quot;шаг за шагом&quot; == П…»</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство &quot;шаг за шагом&quot; ==<br /> <br /> Пример предоставления клиентам доступа к ресурсам сети с привязкой IP к MAC с помощью &lt;tt&gt;bridge&lt;/tt&gt; и &lt;tt&gt;pf&lt;/tt&gt;. В данном случае для создания моста достаточно одного внутреннего сетевого интерфейса &lt;tt&gt;ral0&lt;/tt&gt;.<br /> <br /> &lt;pre&gt;<br /> Сервер. IP: 192.168.2.1<br /> Клиент 1. Hostname: evol, IP: 192.168.2.2, MAC: 00:0f:ea:91:43:f6<br /> Клиент 2. Hostname: aurora, IP: 192.168.2.3, MAC: 00:80:c8:2c:47:a1 <br /> &lt;/pre&gt;<br /> <br /> Включаем перенаправление IPv4-пакетов между сетевыми интерфейсами:<br /> <br /> # sysctl -w net.inet.ip.forwarding=1<br /> <br /> Добавляем соответствующую запись в &lt;span style=&quot;color:green;&quot;&gt;/etc/sysctl.conf&lt;/span&gt;:<br /> <br /> # vi /etc/sysctl.conf<br /> net.inet.ip.forwarding=1<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridgename.bridge0&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridgename.bridge0<br /> add ral0<br /> blocknonip ral0<br /> link0<br /> -discover ral0<br /> -learn ral0<br /> flushall<br /> static ral0 00:0f: ea:91:43:f6<br /> static ral0 00:80:c8:2c:47:a1<br /> up<br /> rulefile /etc/bridge.conf<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/bridge.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/bridge.conf<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> &lt;/pre&gt;<br /> <br /> Создаем и поднимаем псевдоустройство &lt;tt&gt;bridge&lt;/tt&gt;:<br /> <br /> # ifconfig bridge0 create<br /> # sh /etc/netstart bridge0<br /> <br /> Для проверки смотрим информацию о бридже:<br /> <br /> &lt;pre&gt;<br /> # brconfig bridge0<br /> bridge0: flags=1041&lt;UP,RUNNING,LINK0&gt;<br /> Configuration:<br /> priority 32768 hellotime 2 fwddelay 15 maxage 20<br /> Interfaces:<br /> ral0 flags=4&lt;BLOCKNONIP&gt;<br /> port 2 ifpriority 128 ifcost 55<br /> pass in on ral0 src 00:0f: ea:91:43:f6 tag evol<br /> pass in on ral0 src 00:80:c8:2c:47:a1 tag aurora<br /> block in on ral0<br /> Addresses (max cache: 100, timeout: 240):<br /> 00:80:c8:2c:47:a1 ral0 1 flags=1&lt;STATIC&gt;<br /> 00:0f: ea:91:43:f6 ral0 1 flags=1&lt;STATIC&gt;<br /> &lt;/pre&gt;<br /> <br /> Редактируем &lt;span style=&quot;color:green;&quot;&gt;/etc/pf.conf&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/pf.conf<br /> ext_if = «vr0»<br /> int_if = «ral0»<br /> <br /> evol = «192.168.2.2»<br /> aurora = «192.168.2.3»<br /> <br /> nat on $ext_if inet from { $evol, $aurora } to any -&gt; ($ext_if)<br /> <br /> block in quick on $int_if from ! $evol to any tagged evol<br /> block in quick on $int_if from ! $aurora to any tagged aurora<br /> <br /> block return<br /> <br /> pass quick on { lo, $int_if } inet all<br /> pass quick on $ext_if inet all keep state<br /> &lt;/pre&gt;<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> Дополнительную информацию можно получить, прочитав статью «Настройка Ethernet Bridge», а также из справочных man-страниц: [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html bridge(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=pf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf(4)], [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)], [http://www.openbsd.org/cgi-bin/man.cgi?query=netstart&amp;sektion=8&amp;apropos=0&amp;manpath=OpenBSD+Current&amp;arch=i386 netstart(8)].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_pppoe(8)&diff=237 2013-06-14T14:23:51Z

<p>Nordwind: </p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример настройки PPPoE-клиента. Предположим, что &lt;tt&gt;vr0&lt;/tt&gt; - это сетевой интерфейс, на котором будет работать клиент, выданы логин &lt;tt&gt;&quot;test&quot;&lt;/tt&gt; и пароль &lt;tt&gt;&quot;qwe123&quot;&lt;/tt&gt;.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на «&lt;big&gt;&#039;&#039;&#039;:&#039;&#039;&#039;&lt;/big&gt;», вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set authname test<br /> set authkey qwe123<br /> add! default HISADDR<br /> &lt;/pre&gt;<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.conf<br /> <br /> Устанавливаем соединение:<br /> <br /> # ppp -ddial pppoe<br /> <br /> Если тестирование прошло успешно, можно настроить автоматическое поднятие PPPoE-соединения при старте системы:<br /> <br /> # vi /etc/hostname.tun0<br /> !/usr/sbin/ppp -ddial pppoe<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=236 2013-06-14T14:20:47Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Использование сетевой файловой системы NFS]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Настройка PPPoE-сервера]]<br /> * [[Настройка PPPoE-клиента с помощью pppoe(8)]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_pppoe(8)&diff=235 2013-06-14T14:19:31Z

<p>Nordwind: </p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]&lt;br /&gt;<br /> <br /> Пример настройки PPPoE-клиента. Предположим, что &lt;tt&gt;vr0&lt;/tt&gt; - это сетевой интерфейс, на котором будет работать клиент, выданы логин &lt;tt&gt;&quot;test&quot;&lt;/tt&gt; и пароль &lt;tt&gt;&quot;qwe123&quot;&lt;/tt&gt;.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на «&lt;big&gt;&#039;&#039;&#039;:&#039;&#039;&#039;&lt;/big&gt;», вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set authname test<br /> set authkey qwe123<br /> add! default HISADDR<br /> &lt;/pre&gt;<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.conf<br /> <br /> Устанавливаем соединение:<br /> <br /> # ppp -ddial pppoe<br /> <br /> Если тестирование прошло успешно, можно настроить автоматическое поднятие PPPoE-соединения при старте системы:<br /> <br /> # vi /etc/hostname.tun0<br /> !/usr/sbin/ppp -ddial pppoe<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_pppoe(8)&diff=234 2013-06-14T14:18:40Z

<p>Nordwind: Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] Пример настройки PPPoE-клиента. Предпол…»</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> Пример настройки PPPoE-клиента. Предположим, что &lt;tt&gt;vr0&lt;/tt&gt; - это сетевой интерфейс, на котором будет работать клиент, выданы логин &lt;tt&gt;&quot;test&quot;&lt;/tt&gt; и пароль &lt;tt&gt;&quot;qwe123&quot;&lt;/tt&gt;.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на «&lt;big&gt;&#039;&#039;&#039;:&#039;&#039;&#039;&lt;/big&gt;», вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set authname test<br /> set authkey qwe123<br /> add! default HISADDR<br /> &lt;/pre&gt;<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.conf<br /> <br /> Устанавливаем соединение:<br /> <br /> # ppp -ddial pppoe<br /> <br /> Если тестирование прошло успешно, можно настроить автоматическое поднятие PPPoE-соединения при старте системы:<br /> <br /> # vi /etc/hostname.tun0<br /> !/usr/sbin/ppp -ddial pppoe<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=233 2013-06-14T13:56:42Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Использование сетевой файловой системы NFS]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Настройка PPPoE-сервера]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0&diff=232 2013-06-14T13:54:30Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример создания PPPoE-сервера. Предположим, &lt;tt&gt;vr0&lt;/tt&gt; — это сетевой интерфейс, на котором будет работать сервер.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на «&#039;&#039;&#039;&lt;big&gt;:&lt;/big&gt;&#039;&#039;&#039;», вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe1:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set ifaddr 192.168.1.1 192.168.1.32-192.168.1.63 255.255.255.255<br /> enable chap<br /> &lt;/pre&gt;<br /> <br /> Создание или изменение учетных записей пользователей производится за счет редактирования файла &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.secret&lt;/span&gt;. Если IP-адрес должен быть динамическим, тогда вместо поля &lt;tt&gt;ip_address&lt;/tt&gt; нужно поставить знак звездочки («&#039;&#039;&#039;&lt;big&gt;*&lt;/big&gt;&#039;&#039;&#039;»). Поле &lt;tt&gt;label&lt;/tt&gt; является необязательным. Например:<br /> <br /> # vi /etc/ppp/ppp.secret<br /> # user password ip_address label<br /> user1 secret123 192.168.1.40 sidorov<br /> user2 123qwe *<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.{conf, secret}<br /> <br /> Запуск:<br /> <br /> # pppoe -p pppoe1 -i vr0 -s &amp;<br /> <br /> Если тестирование прошло успешно, можно настроить автоматический запуск при старте системы:<br /> <br /> # vi /etc/rc.local<br /> /usr/sbin/pppoe -p pppoe1 -i vr0 -s &amp; &gt;/dev/null 2&gt;&amp;1<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0&diff=231 2013-06-14T13:50:04Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример создания PPPoE-сервера. Предположим, &lt;tt&gt;vr0&lt;/tt&gt; — это сетевой интерфейс, на котором будет работать сервер.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на &#039;&#039;&#039;:&#039;&#039;&#039;, вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe1:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set ifaddr 192.168.1.1 192.168.1.32-192.168.1.63 255.255.255.255<br /> enable chap<br /> &lt;/pre&gt;<br /> <br /> Создание или изменение учетных записей пользователей производится за счет редактирования файла &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.secret&lt;/span&gt;. Если IP-адрес должен быть динамическим, тогда вместо поля &lt;tt&gt;ip_address&lt;/tt&gt; нужно поставить знак звездочки (&#039;&#039;&#039;*&#039;&#039;&#039;). Поле &lt;tt&gt;label&lt;/tt&gt; является необязательным. Например:<br /> <br /> # vi /etc/ppp/ppp.secret<br /> # user password ip_address label<br /> user1 secret123 192.168.1.40 sidorov<br /> user2 123qwe *<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.{conf, secret}<br /> <br /> Запуск:<br /> <br /> # pppoe -p pppoe1 -i vr0 -s &amp;<br /> <br /> Если тестирование прошло успешно, можно настроить автоматический запуск при старте системы:<br /> <br /> # vi /etc/rc.local<br /> /usr/sbin/pppoe -p pppoe1 -i vr0 -s &amp; &gt;/dev/null 2&gt;&amp;1<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0&diff=230 2013-06-14T13:46:41Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример создания PPPoE-сервера. Предположим, &lt;tt&gt;vr0&lt;/tt&gt; — это сетевой интерфейс, на котором будет работать сервер.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на &lt;nowiki&gt;``:&#039;&#039;&lt;/nowiki&gt;, вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe1:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set ifaddr 192.168.1.1 192.168.1.32-192.168.1.63 255.255.255.255<br /> enable chap<br /> &lt;/pre&gt;<br /> <br /> Создание или изменение учетных записей пользователей производится за счет редактирования файла &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.secret&lt;/span&gt;. Если IP-адрес должен быть динамическим, тогда вместо поля &lt;tt&gt;ip_address&lt;/tt&gt; нужно поставить знак звездочки (&lt;nowiki&gt;``*&#039;&#039;&lt;/nowiki&gt;). Поле &lt;tt&gt;label&lt;/tt&gt; является необязательным. Например:<br /> <br /> # vi /etc/ppp/ppp.secret<br /> # user password ip_address label<br /> user1 secret123 192.168.1.40 sidorov<br /> user2 123qwe *<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.{conf, secret}<br /> <br /> Запуск:<br /> <br /> # pppoe -p pppoe1 -i vr0 -s &amp;<br /> <br /> Если тестирование прошло успешно, можно настроить автоматический запуск при старте системы:<br /> <br /> # vi /etc/rc.local<br /> /usr/sbin/pppoe -p pppoe1 -i vr0 -s &amp; &gt;/dev/null 2&gt;&amp;1<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_PPPoE-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0&diff=229 2013-06-14T13:40:33Z

<p>Nordwind: Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == …»</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример создания PPPoE-сервера. Предположим, &lt;tt&gt;vr0&lt;/tt&gt; — это сетевой интерфейс, на котором будет работать сервер.<br /> <br /> Перейдем к настройке PPP. Обратите внимание, что в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.conf&lt;/span&gt; cтроки, оканчивающиеся на ``:&#039;&#039;, вводятся без отступа в начале строки. Остальные строки должны быть введены с отступом, как показано в примере.<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ppp/ppp.conf<br /> default:<br /> Set log Phase Chat LCP IPCP CCP tun command<br /> Disable ipv6cp<br /> <br /> pppoe1:<br /> set device &quot;!/usr/sbin/pppoe -i vr0&quot;<br /> set mtu max 1492<br /> set mru max 1492<br /> set speed sync<br /> disable acfcomp protocomp<br /> deny acfcomp<br /> set ifaddr 192.168.1.1 192.168.1.32-192.168.1.63 255.255.255.255<br /> enable chap<br /> &lt;/pre&gt;<br /> <br /> Создание или изменение учетных записей пользователей производится за счет редактирования файла &lt;span style=&quot;color:green;&quot;&gt;/etc/ppp/ppp.secret&lt;/span&gt;. Если IP-адрес должен быть динамическим, тогда вместо поля &lt;tt&gt;ip_address&lt;/tt&gt; нужно поставить знак звездочки (``*&#039;&#039;). Поле &lt;tt&gt;label&lt;/tt&gt; является необязательным. Например:<br /> <br /> # vi /etc/ppp/ppp.secret<br /> # user password ip_address label<br /> user1 secret123 192.168.1.40 sidorov<br /> user2 123qwe *<br /> <br /> Выставляем корректные права доступа:<br /> <br /> # chmod 600 /etc/ppp/ppp.{conf, secret}<br /> <br /> Запуск:<br /> <br /> # pppoe -p pppoe1 -i vr0 -s &amp;<br /> <br /> Если тестирование прошло успешно, можно настроить автоматический запуск при старте системы:<br /> <br /> # vi /etc/rc.local<br /> /usr/sbin/pppoe -p pppoe1 -i vr0 -s &amp; &gt;/dev/null 2&gt;&amp;1<br /> <br /> Статья основана на материалах, предоставленных Гнединым Алексеем aka Goblin.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=228 2013-06-14T13:32:02Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Использование сетевой файловой системы NFS]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_NFS&diff=227 2013-06-14T13:31:02Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> В файле [http://www.openbsd.org/cgi-bin/man.cgi?query=exports&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html exports(5)] перечисляем каталоги, которые должны быть предоставлены для общего доступа через NFS, а также задаем права доступа к ним:<br /> <br /> # vi /etc/exports<br /> /export -alldirs -ro -network=192.168.2.0 -mask=255.255.255.0<br /> /usr/src /usr/ports -maproot=root 192.168.2.3<br /> <br /> Последовательно загружаем [http://www.openbsd.org/cgi-bin/man.cgi?query=portmap&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html portmap(8)], [http://www.openbsd.org/cgi-bin/man.cgi?query=nfsd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html nfsd(8)], [http://www.openbsd.org/cgi-bin/man.cgi?query=mountd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html mountd(8)]:<br /> <br /> # portmap<br /> # nfsd -tun 4<br /> # touch /var/db/mountdtab<br /> # mountd<br /> <br /> Для того чтобы &lt;tt&gt;mountd&lt;/tt&gt; смог перечитать &lt;span style=&quot;color:green;&quot;&gt;/etc/exports&lt;/span&gt;, следует отправить ему сигнал &#039;&#039;&#039;SIGHUP&#039;&#039;&#039;:<br /> <br /> # kill -HUP `head −1 /var/run/mountd.pid`<br /> <br /> Проверить корректность работы RPC-служб можно с помощью следующей команды:<br /> <br /> &lt;pre&gt;<br /> % rpcinfo -p 192.168.2.1<br /> program vers proto port<br /> 100000 2 tcp 111 portmapper<br /> 100000 2 udp 111 portmapper<br /> 100003 2 udp 2049 nfs<br /> 100003 3 udp 2049 nfs<br /> 100003 2 tcp 2049 nfs<br /> 100003 3 tcp 2049 nfs<br /> 100005 1 udp 772 mountd<br /> 100005 3 udp 772 mountd<br /> 100005 1 tcp 804 mountd<br /> 100005 3 tcp 804 mountd<br /> &lt;/pre&gt;<br /> <br /> Вот таким образом можно получить список экспортируемых общих ресурсов:<br /> <br /> % showmount -e<br /> Exports list on localhost:<br /> /export 192.168.2.0<br /> /usr/src 192.168.2.3<br /> /usr/ports 192.168.2.3<br /> <br /> В [http://www.openbsd.org/cgi-bin/man.cgi?query=rc.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html rc.conf(8)] прописываем автозапуск служб NFS:<br /> <br /> # vi /etc/rc.conf<br /> nfs_server=YES<br /> portmap=YES<br /> nfsd_flags=&quot;-tun 4&quot;<br /> <br /> Конфигурирование клиента NFS заключается в выполнении следующих шагов. В первую очередь изменяем значение переменной [http://www.openbsd.org/cgi-bin/man.cgi?query=sysctl&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sysctl(8)]:<br /> <br /> # sysctl -w vfs.nfs.iothreads=4<br /> <br /> Добавляем соответствующую запись в [http://www.openbsd.org/cgi-bin/man.cgi?query=sysctl.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sysctl.conf(5)]:<br /> <br /> # vi /etc/sysctl.conf<br /> vfs.nfs.iothreads=4<br /> <br /> Задаем опции монтирования общих ресурсов NFS в [http://www.openbsd.org/cgi-bin/man.cgi?query=fstab&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html fstab(5)]:<br /> <br /> # vi /etc/fstab<br /> 192.168.2.1:/export /mnt nfs ro, nodev, nosuid, tcp, soft, intr 0 0<br /> 192.168.2.1:/usr/src /usr/src nfs rw, noauto, nodev, nosuid, soft, intr 0 0<br /> 192.168.2.1:/usr/ports /usr/ports nfs rw, noauto, nodev, nosuid, soft, intr 0 0<br /> <br /> Пример монтирования удаленной файловой системы:<br /> <br /> # mount /usr/ports<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D1%84%D0%B0%D0%B9%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B_NFS&diff=226 2013-06-14T13:27:20Z

<p>Nordwind: Новая страница: «: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == …»</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> В файле [exports(5)http://www.openbsd.org/cgi-bin/man.cgi?query=exports&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html] перечисляем каталоги, которые должны быть предоставлены для общего доступа через NFS, а также задаем права доступа к ним:<br /> <br /> # vi /etc/exports<br /> /export -alldirs -ro -network=192.168.2.0 -mask=255.255.255.0<br /> /usr/src /usr/ports -maproot=root 192.168.2.3<br /> <br /> Последовательно загружаем [portmap(8) http://www.openbsd.org/cgi-bin/man.cgi?query=portmap&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html], [nfsd(8) http://www.openbsd.org/cgi-bin/man.cgi?query=nfsd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html], [mountd(8) http://www.openbsd.org/cgi-bin/man.cgi?query=mountd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html]:<br /> <br /> # portmap<br /> # nfsd -tun 4<br /> # touch /var/db/mountdtab<br /> # mountd<br /> <br /> Для того чтобы &lt;tt&gt;mountd&lt;/tt&gt; смог перечитать &lt;span style=&quot;color:green;&quot;&gt;/etc/exports&lt;/span&gt;, следует отправить ему сигнал &#039;&#039;&#039;SIGHUP&#039;&#039;&#039;:<br /> <br /> # kill -HUP `head −1 /var/run/mountd.pid`<br /> <br /> Проверить корректность работы RPC-служб можно с помощью следующей команды:<br /> <br /> &lt;pre&gt;<br /> % rpcinfo -p 192.168.2.1<br /> program vers proto port<br /> 100000 2 tcp 111 portmapper<br /> 100000 2 udp 111 portmapper<br /> 100003 2 udp 2049 nfs<br /> 100003 3 udp 2049 nfs<br /> 100003 2 tcp 2049 nfs<br /> 100003 3 tcp 2049 nfs<br /> 100005 1 udp 772 mountd<br /> 100005 3 udp 772 mountd<br /> 100005 1 tcp 804 mountd<br /> 100005 3 tcp 804 mountd<br /> &lt;/pre&gt;<br /> <br /> Вот таким образом можно получить список экспортируемых общих ресурсов:<br /> <br /> % showmount -e<br /> Exports list on localhost:<br /> /export 192.168.2.0<br /> /usr/src 192.168.2.3<br /> /usr/ports 192.168.2.3<br /> <br /> В [rc.conf(8) http://www.openbsd.org/cgi-bin/man.cgi?query=rc.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html] прописываем автозапуск служб NFS:<br /> <br /> # vi /etc/rc.conf<br /> nfs_server=YES<br /> portmap=YES<br /> nfsd_flags=&quot;-tun 4&quot;<br /> <br /> Конфигурирование клиента NFS заключается в выполнении следующих шагов. В первую очередь изменяем значение переменной [sysctl(8) http://www.openbsd.org/cgi-bin/man.cgi?query=sysctl&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html]:<br /> <br /> # sysctl -w vfs.nfs.iothreads=4<br /> <br /> Добавляем соответствующую запись в [sysctl.conf(5) http://www.openbsd.org/cgi-bin/man.cgi?query=sysctl.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html]:<br /> <br /> # vi /etc/sysctl.conf<br /> vfs.nfs.iothreads=4<br /> <br /> Задаем опции монтирования общих ресурсов NFS в [fstab(5) http://www.openbsd.org/cgi-bin/man.cgi?query=fstab&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html]:<br /> <br /> # vi /etc/fstab<br /> 192.168.2.1:/export /mnt nfs ro, nodev, nosuid, tcp, soft, intr 0 0<br /> 192.168.2.1:/usr/src /usr/src nfs rw, noauto, nodev, nosuid, soft, intr 0 0<br /> 192.168.2.1:/usr/ports /usr/ports nfs rw, noauto, nodev, nosuid, soft, intr 0 0<br /> <br /> Пример монтирования удаленной файловой системы:<br /> <br /> # mount /usr/ports<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=209 2013-06-05T14:55:12Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[VPN на базе SSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=VPN_%D0%BD%D0%B0_%D0%B1%D0%B0%D0%B7%D0%B5_SSH&diff=208 2013-06-05T14:53:13Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Для примера возьмем два сервера: &lt;tt&gt;srv1&lt;/tt&gt; с IP-адресами 212.34.XX.YY и 192.168.2.1 подключен к сегменту внутренней сети 192.168.2.0/24, а &lt;tt&gt;srv2&lt;/tt&gt; с 213.167.XX.YY и 192.168.1.1 шефствует над подопечными из 192.168.1.0/24. Настроим VPN-туннель средствами OpenSSH, в котором будут использоваться адреса 10.0.0.1 и 10.0.0.2. Для наглядности сценарий можно представить следующим образом:<br /> <br /> &lt;pre&gt;<br /> (10.0.0.1) 212.34.XX.YY 213.167.XX.YY (10.0.0.2)<br /> 192.168.2.0/24 — srv1 — [ internet ] — srv2 — 192.168.1.0/24<br /> 192.168.2.1 192.168.1.1<br /> &lt;/pre&gt;<br /> <br /> Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на &lt;tt&gt;srv1&lt;/tt&gt; и правим главный конфигурационный файл [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]:<br /> <br /> &lt;pre&gt;<br /> srv1# vi /etc/ssh/sshd_config<br /> <br /> # Разрешаем туннелирование layer-3<br /> # <br /> PermitTunnel point-to-point<br /> <br /> # VPN на базе OpenSSH требует привилегий суперпользователя,<br /> # поэтому аутентификацию под учетной записью root разрешаем<br /> # только с доверенных хостов<br /> # <br /> PermitRootLogin no<br /> Match Host 213.167.XX.YY,192.168.2.*,127.0.0.1<br /> PermitRootLogin yes<br /> &lt;/pre&gt;<br /> <br /> По окончании настроек не забываем отправить демону сигнал SIGHUP, чтобы он смог перечитать свой конфиг:<br /> <br /> srv1# kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах [http://www.openbsd.org/cgi-bin/man.cgi?query=tun&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html tun(4)] (на &lt;tt&gt;tun0&lt;/tt&gt; у меня висит OpenVPN, &lt;tt&gt;tun1&lt;/tt&gt; — для OpenSSH):<br /> <br /> srv1# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> Загружаем правила из конфига:<br /> <br /> srv1# pfctl -f /etc/pf.conf<br /> <br /> Создаем интерфейс &lt;tt&gt;tun1&lt;/tt&gt; и назначаем ему IP-адрес:<br /> <br /> srv1# ifconfig tun1 create<br /> srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252<br /> <br /> При помощи команды [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)] проверяем его состояние:<br /> <br /> &lt;pre&gt;<br /> srv1% ifconfig tun1<br /> tun1: flags=51&lt;UP,POINTOPOINT,RUNNING&gt; mtu 1500<br /> groups: tun<br /> inet 10.0.0.1 --&gt; 10.0.0.2 netmask 255.255.255.252<br /> &lt;/pre&gt;<br /> <br /> Не забываем добавить в таблицу маршрутизации удаленную подсеть:<br /> <br /> srv1# route add 192.168.1.0/24 10.0.0.2<br /> <br /> Второй сервер выступает в роли SSH-клиента, поэтому процедура конфигурирования здесь чуть проще:<br /> <br /> srv2# echo &#039;Tunnel point-to-point&#039; &gt;&gt; /etc/ssh/ssh_config<br /> <br /> Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем &lt;tt&gt;tun1&lt;/tt&gt;, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:<br /> <br /> &lt;pre&gt;<br /> srv2# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> srv2# pfctl -f /etc/pf.conf<br /> srv2# ifconfig tun1 create<br /> srv2# ifconfig tun1 10.0.0.2 10.0.0.1 netmask 255.255.255.252<br /> srv2# route add 192.168.2.0/24 10.0.0.1<br /> &lt;/pre&gt;<br /> <br /> И, наконец, самый ответственный момент: устанавливаем защищенное соединение между двумя сетями:<br /> <br /> srv2# ssh -f -w 1:1 212.34.XX.YY true<br /> <br /> Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить &lt;span style=&quot;color:green;&quot;&gt;/dev/null&lt;/span&gt; на стандартный входной поток [http://www.openbsd.org/cgi-bin/man.cgi?query=stdin&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html stdin(4))]. Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:<br /> <br /> &lt;pre&gt;<br /> srv2% ping 192.168.2.101<br /> PING 192.168.2.101 (192.168.2.101): 56 data bytes<br /> 64 bytes from 192.168.2.101: icmp_seq=0 ttl=127 time=2.508 ms<br /> &lt;/pre&gt;<br /> <br /> Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства &lt;tt&gt;tun1&lt;/tt&gt;:<br /> <br /> srv2# echo &#039;10.0.0.2 10.0.0.1 netmask 255.255.255.252&#039; &gt; /etc/hostname.tun1<br /> <br /> Занести необходимые статические маршруты и запуск «&#039;&#039;&#039;ssh -f -w&#039;&#039;&#039;» в один из сценариев начальной загрузки (&lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив &lt;tt&gt;PermitTunnel&lt;/tt&gt; и &lt;tt&gt;Tunnel&lt;/tt&gt; следует использовать &lt;tt&gt;ethernet&lt;/tt&gt;, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство &lt;tt&gt;tunX&lt;/tt&gt; (см. [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&amp;sektion=4&amp;apropos=0&amp;manpath=OpenBSD+Current&amp;arch=i386 bridge(4)]).<br /> <br /> Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).<br /> <br /> Данное пошаговое руководство основано на статье «Волшебные криптотуннели», опубликованной в июльском номере журнала [http://www.xakep.ru/magazine/xa/115/132/1.asp «Хакер»] за 2008 год. Авторы оригинальной статьи: Андрей Матвеев и Сергей Яремчук.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=VPN_%D0%BD%D0%B0_%D0%B1%D0%B0%D0%B7%D0%B5_SSH&diff=207 2013-06-05T14:49:55Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Для примера возьмем два сервера: &lt;tt&gt;srv1&lt;/tt&gt; с IP-адресами 212.34.XX.YY и 192.168.2.1 подключен к сегменту внутренней сети 192.168.2.0/24, а &lt;tt&gt;srv2&lt;/tt&gt; с 213.167.XX.YY и 192.168.1.1 шефствует над подопечными из 192.168.1.0/24. Настроим VPN-туннель средствами OpenSSH, в котором будут использоваться адреса 10.0.0.1 и 10.0.0.2. Для наглядности сценарий можно представить следующим образом:<br /> <br /> &lt;pre&gt;<br /> (10.0.0.1) 212.34.XX.YY 213.167.XX.YY (10.0.0.2)<br /> 192.168.2.0/24 — srv1 — [ internet ] — srv2 — 192.168.1.0/24<br /> 192.168.2.1 192.168.1.1<br /> &lt;/pre&gt;<br /> <br /> Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на &lt;tt&gt;srv1&lt;/tt&gt; и правим главный конфигурационный файл [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]:<br /> <br /> &lt;pre&gt;<br /> srv1# vi /etc/ssh/sshd_config<br /> <br /> # Разрешаем туннелирование layer-3<br /> # <br /> PermitTunnel point-to-point<br /> <br /> # VPN на базе OpenSSH требует привилегий суперпользователя,<br /> # поэтому аутентификацию под учетной записью root разрешаем<br /> # только с доверенных хостов<br /> # <br /> PermitRootLogin no<br /> Match Host 213.167.XX.YY,192.168.2.*,127.0.0.1<br /> PermitRootLogin yes<br /> &lt;/pre&gt;<br /> <br /> По окончании настроек не забываем отправить демону сигнал SIGHUP, чтобы он смог перечитать свой конфиг:<br /> <br /> srv1# kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах [http://www.openbsd.org/cgi-bin/man.cgi?query=tun&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html tun(4)] (на &lt;tt&gt;tun0&lt;/tt&gt; у меня висит OpenVPN, &lt;tt&gt;tun1&lt;/tt&gt; — для OpenSSH):<br /> <br /> srv1# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> Загружаем правила из конфига:<br /> <br /> srv1# pfctl -f /etc/pf.conf<br /> <br /> Создаем интерфейс &lt;tt&gt;tun1&lt;/tt&gt; и назначаем ему IP-адрес:<br /> <br /> srv1# ifconfig tun1 create<br /> srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252<br /> <br /> При помощи команды [http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html ifconfig(8)] проверяем его состояние:<br /> <br /> &lt;pre&gt;<br /> srv1% ifconfig tun1<br /> tun1: flags=51&lt;UP,POINTOPOINT,RUNNING&gt; mtu 1500<br /> groups: tun<br /> inet 10.0.0.1 --&gt; 10.0.0.2 netmask 255.255.255.252<br /> &lt;/pre&gt;<br /> <br /> Не забываем добавить в таблицу маршрутизации удаленную подсеть:<br /> <br /> srv1# route add 192.168.1.0/24 10.0.0.2<br /> <br /> Второй сервер выступает в роли SSH-клиента, поэтому процедура конфигурирования здесь чуть проще:<br /> <br /> srv2# echo &#039;Tunnel point-to-point&#039; &gt;&gt; /etc/ssh/ssh_config<br /> <br /> Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем &lt;tt&gt;tun1&lt;/tt&gt;, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:<br /> <br /> &lt;pre&gt;<br /> srv2# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> srv2# pfctl -f /etc/pf.conf<br /> srv2# ifconfig tun1 create<br /> srv2# ifconfig tun1 10.0.0.2 10.0.0.1 netmask 255.255.255.252<br /> srv2# route add 192.168.2.0/24 10.0.0.1<br /> &lt;/pre&gt;<br /> <br /> И, наконец, самый ответственный момент: устанавливаем защищенное соединение между двумя сетями:<br /> <br /> srv2# ssh -f -w 1:1 212.34.XX.YY true<br /> <br /> Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить &lt;span style=&quot;color:green;&quot;&gt;/dev/null&lt;/span&gt; на стандартный входной поток [http://www.openbsd.org/cgi-bin/man.cgi?query=stdin&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html stdin(4))]. Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:<br /> <br /> &lt;pre&gt;<br /> srv2% ping 192.168.2.101<br /> PING 192.168.2.101 (192.168.2.101): 56 data bytes<br /> 64 bytes from 192.168.2.101: icmp_seq=0 ttl=127 time=2.508 ms<br /> &lt;/pre&gt;<br /> <br /> Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства &lt;tt&gt;tun1&lt;/tt&gt;:<br /> <br /> srv2# echo &#039;10.0.0.2 10.0.0.1 netmask 255.255.255.252&#039; &gt; /etc/hostname.tun1<br /> <br /> Занести необходимые статические маршруты и запуск «ssh -f -w» в один из сценариев начальной загрузки (&lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив &lt;tt&gt;PermitTunnel&lt;/tt&gt; и &lt;tt&gt;Tunnel&lt;/tt&gt; следует использовать &lt;tt&gt;ethernet&lt;/tt&gt;, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство &lt;tt&gt;tunX&lt;/tt&gt; (см. [http://www.openbsd.org/cgi-bin/man.cgi?query=bridge&amp;sektion=4&amp;apropos=0&amp;manpath=OpenBSD+Current&amp;arch=i386 bridge(4)]).<br /> <br /> Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).<br /> <br /> Данное пошаговое руководство основано на статье «Волшебные криптотуннели», опубликованной в июльском номере журнала [http://www.xakep.ru/magazine/xa/115/132/1.asp «Хакер»] за 2008 год. Авторы оригинальной статьи: Андрей Матвеев и Сергей Яремчук.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=VPN_%D0%BD%D0%B0_%D0%B1%D0%B0%D0%B7%D0%B5_SSH&diff=206 2013-06-05T14:39:23Z

<p>Nordwind: Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == Д…»</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Для примера возьмем два сервера: &lt;tt&gt;srv1&lt;/tt&gt; с IP-адресами 212.34.XX.YY и 192.168.2.1 подключен к сегменту внутренней сети 192.168.2.0/24, а &lt;tt&gt;srv2&lt;/tt&gt; с 213.167.XX.YY и 192.168.1.1 шефствует над подопечными из 192.168.1.0/24. Настроим VPN-туннель средствами OpenSSH, в котором будут использоваться адреса 10.0.0.1 и 10.0.0.2. Для наглядности сценарий можно представить следующим образом:<br /> <br /> &lt;pre&gt;<br /> (10.0.0.1) 212.34.XX.YY 213.167.XX.YY (10.0.0.2)<br /> 192.168.2.0/24 — srv1 — [ internet ] — srv2 — 192.168.1.0/24<br /> 192.168.2.1 192.168.1.1<br /> &lt;/pre&gt;<br /> <br /> Ключевые элементы сетевой конфигурации рассмотрены, теперь приступаем к настройкам. Логинимся на &lt;tt&gt;srv1&lt;/tt&gt; и правим главный конфигурационный файл sshd(8):<br /> <br /> &lt;pre&gt;<br /> srv1# vi /etc/ssh/sshd_config<br /> <br /> # Разрешаем туннелирование layer-3<br /> # <br /> PermitTunnel point-to-point<br /> <br /> # VPN на базе OpenSSH требует привилегий суперпользователя,<br /> # поэтому аутентификацию под учетной записью root разрешаем<br /> # только с доверенных хостов<br /> # <br /> PermitRootLogin no<br /> Match Host 213.167.XX.YY,192.168.2.*,127.0.0.1<br /> PermitRootLogin yes<br /> &lt;/pre&gt;<br /> <br /> По окончании настроек не забываем отправить демону сигнал SIGHUP, чтобы он смог перечитать свой конфиг:<br /> <br /> srv1# kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Далее разрешаем прохождение пакетов на используемых туннельных псевдоустройствах tun(4) (на tun0 у меня висит OpenVPN, tun1 — для OpenSSH):<br /> <br /> srv1# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> Загружаем правила из конфига:<br /> <br /> srv1# pfctl -f /etc/pf.conf<br /> <br /> Создаем интерфейс tun1 и назначаем ему IP-адрес:<br /> <br /> srv1# ifconfig tun1 create<br /> srv1# ifconfig tun1 10.0.0.1 10.0.0.2 netmask 255.255.255.252<br /> <br /> При помощи команды ifconfig(8) проверяем его состояние:<br /> <br /> &lt;pre&gt;<br /> srv1% ifconfig tun1<br /> tun1: flags=51&lt;UP,POINTOPOINT,RUNNING&gt; mtu 1500<br /> groups: tun<br /> inet 10.0.0.1 --&gt; 10.0.0.2 netmask 255.255.255.252<br /> &lt;/pre&gt;<br /> <br /> Не забываем добавить в таблицу маршрутизации удаленную подсеть:<br /> <br /> srv1# route add 192.168.1.0/24 10.0.0.2<br /> <br /> Второй сервер выступает в роли SSH-клиента, поэтому процедура конфигурирования здесь чуть проще:<br /> <br /> srv2# echo &#039;Tunnel point-to-point&#039; &gt;&gt; /etc/ssh/ssh_config<br /> <br /> Остальные настройки и действия практически идентичны описанным выше: правим и активируем рулесеты файервола, поднимаем tun1, присваиваем ему сетевой адрес (обратите внимание, порядок следования IP-адресов изменен) и добавляем статический маршрут:<br /> <br /> &lt;pre&gt;<br /> srv2# vi /etc/pf.conf<br /> pass quick on { tun0, tun1 } inet all<br /> <br /> srv2# pfctl -f /etc/pf.conf<br /> srv2# ifconfig tun1 create<br /> srv2# ifconfig tun1 10.0.0.2 10.0.0.1 netmask 255.255.255.252<br /> srv2# route add 192.168.2.0/24 10.0.0.1<br /> &lt;/pre&gt;<br /> <br /> И, наконец, самый ответственный момент: устанавливаем защищенное соединение между двумя сетями:<br /> <br /> srv2# ssh -f -w 1:1 212.34.XX.YY true<br /> <br /> Чтобы снизить накладные расходы, к списку аргументов имеет смысл добавить ключи «-o Compression=yes -x -a -n» (сжимать передаваемые данные, отключить пересылку пакетов X11, запретить аутентификацию с помощью агента и направить /dev/null на стандартный входной поток stdin(4)). Теперь проверим доступность удаленного узла, находящегося «за первым сервером»:<br /> <br /> &lt;pre&gt;<br /> srv2% ping 192.168.2.101<br /> PING 192.168.2.101 (192.168.2.101): 56 data bytes<br /> 64 bytes from 192.168.2.101: icmp_seq=0 ttl=127 time=2.508 ms<br /> &lt;/pre&gt;<br /> <br /> Если все ОК, можно дальше развивать предложенную схему, упрощая или, наоборот, усложняя настройки. Например, применить беспарольную аутентификацию на базе ключей, создать конфигурационный файл для автоматического создания псевдоустройства tun1:<br /> <br /> srv2# echo &#039;10.0.0.2 10.0.0.1 netmask 255.255.255.252&#039; &gt; /etc/hostname.tun1<br /> <br /> Занести необходимые статические маршруты и запуск «ssh -f -w» в один из сценариев начальной загрузки (/etc/rc.local) или в отдельный скрипт, чтобы все выполнялось одной командой, без дополнительных телодвижений. Чтобы использовать OpenSSH на уровне OSI 2, в качестве значения директив PermitTunnel и Tunnel следует использовать ethernet, а затем объединить в мост внешний сетевой интерфейс и псевдоустройство tunX (см. bridge(4)).<br /> <br /> Стоит отметить, с помощью OpenSSH возможно построение не только Site-to-Site VPN (межсайтовое подключение, в котором два маршрутизатора создают туннель в интернете), но и Client-to-Site (VPN-подключение удаленного доступа для проводных и беспроводных клиентов).<br /> <br /> Данное пошаговое руководство основано на статье «Волшебные криптотуннели», опубликованной в июльском номере журнала [http://www.xakep.ru/magazine/xa/115/132/1.asp «Хакер»] за 2008 год. Авторы оригинальной статьи: Андрей Матвеев и Сергей Яремчук.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=205 2013-06-05T14:12:02Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[OpenSSL: 101 прием работы]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenSSL:_101_%D0%BF%D1%80%D0%B8%D0%B5%D0%BC_%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%8B&diff=204 2013-06-05T14:09:34Z

<p>Nordwind: Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == П…»</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> Пример шифрования файла симметричным алгоритмом &lt;tt&gt;des3&lt;/tt&gt; с помощью &lt;tt&gt;openssl enc&lt;/tt&gt;:<br /> <br /> &lt;pre&gt;<br /> % openssl enc -des3 -e -in plain.txt -out enc.txt<br /> enter des-ede3-cbc encryption password:<br /> Verifying — enter des-ede3-cbc encryption password:<br /> &lt;/pre&gt;<br /> <br /> Расшифровать файл можно, заменив ключ &#039;-e&#039; ключом &#039;-d&#039;:<br /> <br /> &lt;pre&gt;<br /> % openssl enc -des3 -d -in enc.txt -out plain.txt<br /> enter des-ede3-cbc decryption password:<br /> &lt;/pre&gt;<br /> <br /> Для того, чтобы собеседник мог передать нам файл в зашифрованном виде, а мы бы смогли его расшифровать, стоит воспользоваться ассиметричной криптографией, сгенерировав пару RSA-ключей (публичный и приватный):<br /> <br /> &lt;pre&gt;<br /> % openssl genrsa -out rsaprivatekey.pem -des3 2048<br /> Generating RSA private key, 2048 bit long modulus<br /> ……………..+++<br /> …………….+++<br /> e is 65537 (0x10001)<br /> Enter pass phrase for rsaprivatekey.pem:<br /> Verifying — Enter pass phrase for rsaprivatekey.pem:<br /> &lt;/pre&gt;<br /> <br /> Выставляем корректные права доступа:<br /> <br /> % chmod 600 rsaprivatekey.pem<br /> <br /> Получить соответствующий закрытому публичный ключ можно с помощью openssl rsa:<br /> <br /> &lt;pre&gt;<br /> % openssl rsa -in rsaprivatekey.pem -pubout -out rsapublickey.pem<br /> Enter pass phrase for rsaprivatekey.pem:<br /> writing RSA key<br /> &lt;/pre&gt;<br /> <br /> Публичный ключ мы передаем собеседнику. Он шифрует файл на нем, используя &lt;tt&gt;openssl rsautl&lt;/tt&gt;:<br /> <br /> % openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in plain.txt -out cipher.txt<br /> <br /> Мы получаем файл, расшифровываем его, используя свой секретный ключ:<br /> <br /> % openssl rsault -decrypt -inkey rsaprivatekey.pem -in cipher.txt -out plain.txt<br /> <br /> Кроме шифрования, можно также подписывать файлы, предоставляя гарантии, что данный файл послан лично нами, и давая возможность проверить его аутентичность:<br /> <br /> % openssl dgst -sha1 -sign rsaprivatekey.pem -out sign.txt myfile.tar.gz<br /> <br /> Все, что нужно получателю файла — это проверить подпись, используя наш публичный ключ:<br /> <br /> % openssl dgst -sha1 -verify rsapublickey.pem -signature sign.txt myfile.tar.gz<br /> Verified OK.<br /> <br /> Вычислить контрольную сумму файла можно с помощью &lt;tt&gt;openssl dgst&lt;/tt&gt;:<br /> <br /> % openssl dgst -md5 myfile.tar.gz<br /> MD5(myfile.tar.gz) =65b36f8d54b8bab0a787cbd4a8dd8aef<br /> <br /> Чтобы быстро сгенерировать пароль, WEP или IPsec-ключи, можно воспользоваться &lt;tt&gt;openssl rand&lt;/tt&gt;:<br /> <br /> % openssl rand -base64 45<br /> 0JZmfHQL3WI7PTUYcq1w8yQ8wFE3mB7Wd7vdAYd2A6x0cTHmVYqI/Su3o5qh<br /> <br /> Если нужно найти соответствие пароля его md5-шифру, можно использовать &lt;tt&gt;openssl passwd&lt;/tt&gt;:<br /> <br /> % openssl passwd −1 mypassword<br /> $1$OsmexMtO$0CtV.Lb6nhGOSGKM8jKNO.<br /> <br /> Пример подписи почтового сообщения своим сертификатом:<br /> <br /> % openssl smime -sign -signer server.crt -inkey server.key \<br /> -in message.txt -text | mail mailbox@domain.ru<br /> <br /> А теперь еще зашифруем:<br /> <br /> &lt;pre&gt;<br /> % openssl smime -encrypt -in message.txt -signer server.crt \<br /> -inkey server.key -text | openssl smime -encrypt \<br /> -des3 myserver.crt -out mail.msg | mail mailbox@domain.ru<br /> &lt;/pre&gt;<br /> <br /> Чтобы протестировать работу сетевого сервиса, который работает через SSL, выполним:<br /> <br /> % openssl s_client -connect myserver:443<br /> <br /> Статья основана на материалах, предоставленных Антоном Карповым [http://www.toxahost.ru/ www.toxahost.ru].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=203 2013-06-05T14:01:20Z

<p>Nordwind: /* Устаревшее */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Зеркалирование данных с помощью ccd]]<br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%97%D0%B5%D1%80%D0%BA%D0%B0%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_ccd&diff=202 2013-06-05T13:58:21Z

<p>Nordwind: /* Мини-руководство «шаг за шагом» */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> OpenBSD установлена на sd0. Требуется подключить sd1 и производить автоматическое копирование данных с sd0. Для этих целей будем использовать ccd(4). На разделы ccd(4) следует перенести &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;, &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;. Перенести корневую файловую систему нельзя, поскольку ядро не поддерживает загрузку с этого типа устройств. Рекомендуется остановить запущенные процессы и при наличии локального доступа к машине выполнять все операции в однопользовательском режиме.<br /> <br /> Текущая система:<br /> <br /> &lt;pre&gt;<br /> # df -h<br /> Filesystem Size Used Avail Capacity Mounted on<br /> /dev/sd0a 490M 27.6M 438M 6 % /<br /> /dev/sd0d 38.4G 4.0M 36.5G 0 % /home<br /> /dev/sd0e 982M 6.0K 933M 0 % /tmp<br /> /dev/sd0f 17.5G 821M 15.9G 5 % /usr<br /> /dev/sd0g 9.6G 7.1M 9.1G 0 % /var<br /> &lt;/pre&gt;<br /> <br /> Уже сейчас можно составить конфиг для создания устройств ccd(4) при загрузке системы:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ccd.conf<br /> ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> ccd1 16 CCDF_MIRROR /dev/sd0g /dev/sd1g<br /> ccd2 16 CCDF_MIRROR /dev/sd0f /dev/sd1f<br /> &lt;/pre&gt;<br /> <br /> Предварительно делаем бэкап &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; в &lt;span style=&quot;color:green;&quot;&gt;/usr/dump&lt;/span&gt;, иначе данные на дисках будут утеряны:<br /> <br /> &lt;pre&gt;<br /> # mkdir /usr/dump<br /> # dump -a -f /usr/dump/var.dump /var<br /> # dump -a -f /usr/dump/home.dump /home<br /> # umount -f /var<br /> # umount -f /home<br /> &lt;/pre&gt;<br /> <br /> После размонтирования необходимо внести соответствующие изменения в &lt;span style=&quot;color:green;&quot;&gt;/etc/fstab&lt;/span&gt; (старые записи больше не понадобятся):<br /> <br /> &lt;pre&gt;<br /> # vi /etc/fstab<br /> /dev/sd0a / ffs rw 1 1<br /> /dev/ccd1e /home ffs rw, nodev, nosuid 1 2<br /> /dev/sd0e /tmp ffs rw, nodev, nosuid 1 2<br /> /dev/ccd2e /usr ffs rw, nodev 1 2<br /> /dev/ccd0e /var ffs rw, nodev, nosuid 1 2<br /> &lt;/pre&gt;<br /> <br /> Создаем два устройства ccd(4) (для &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt;):<br /> <br /> # ccdconfig ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> # ccdconfig ccd1 16 CCDF_MIRROR /dev/sd0g /dev/sd1g<br /> <br /> Для каждого из созданных устройств меняем тип раздела «с» на &lt;tt&gt;unused&lt;/tt&gt; и создаем одну большую партицию «e» с типом 4.2BSD на весь диск:<br /> <br /> &lt;pre&gt;<br /> # disklabel -E ccd0<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> &lt;/pre&gt;<br /> <br /> И для ccd1:<br /> <br /> &lt;pre&gt;<br /> # disklabel -E ccd1<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> &lt;/pre&gt;<br /> <br /> Создаем файловые системы:<br /> <br /> # newfs ccd0e<br /> # newfs ccd1e<br /> <br /> Снова монтируем /&lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;, но уже как устройства ccd(4). Восстанавливаем данные из резервной копии:<br /> <br /> &lt;pre&gt;<br /> # mount /var<br /> # cd /var &amp;&amp; restore -r -f /usr/dump/var.dump<br /> # mount /home<br /> # cd /home &amp;&amp; restore -r -f /usr/dump/home.dump<br /> &lt;/pre&gt;<br /> <br /> Подготавливаем бэкап &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;:<br /> <br /> # mkdir /home/dump<br /> # dump -a -f /home/dump/usr.dump /usr<br /> <br /> Перегружаемся в &lt;tt&gt;single user mode&lt;/tt&gt; (удаленно размонтировать &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt; нельзя). Делаем с ccd2 то же самое, что делали ранее с ccd0 и ccd1:<br /> <br /> &lt;pre&gt;<br /> # ccdconfig ccd2 16 CCDF_MIRROR /dev/sd0f /dev/sd1f<br /> # disklabel -E ccd2<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> <br /> # newfs ccd2e<br /> # mount /usr<br /> &lt;/pre&gt;<br /> <br /> Создаем ccd0 и монтируем &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;:<br /> <br /> # ccdconfig ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> # mount /home<br /> <br /> Возвращаем данные на &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;:<br /> <br /> # cd /usr &amp;&amp; restore -r -f /home/dump/usr.dump<br /> <br /> Перезагружаемся:<br /> <br /> # reboot<br /> <br /> В итоге получаем:<br /> <br /> &lt;pre&gt;<br /> # df -h<br /> Filesystem Size Used Avail Capacity Mounted on<br /> /dev/sd0a 490M 27.6M 438M 6 % /<br /> /dev/ccd1e 38.4G 4.0M 36.5G 0 % /home<br /> /dev/sd0e 982M 6.0K 933M 0 % /tmp<br /> /dev/ccd2e 17.5G 815M 15.9G 5 % /usr<br /> /dev/ccd0e 9.6G 7.1M 9.1G 0 % /var<br /> &lt;/pre&gt;<br /> <br /> Статья основана на материалах, предоставленных Антоном Карповым [http://www.toxahost.ru/ www.toxahost.ru].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%97%D0%B5%D1%80%D0%BA%D0%B0%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85_%D1%81_%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%D1%8C%D1%8E_ccd&diff=201 2013-06-05T13:56:09Z

<p>Nordwind: Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] == Мини-руководство «шаг за шагом» == Ope…»</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Мини-руководство «шаг за шагом» ==<br /> <br /> OpenBSD установлена на sd0. Требуется подключить sd1 и производить автоматическое копирование данных с sd0. Для этих целей будем использовать ccd(4). На разделы ccd(4) следует перенести &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;, &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;. Перенести корневую файловую систему нельзя, поскольку ядро не поддерживает загрузку с этого типа устройств. Рекомендуется остановить запущенные процессы и при наличии локального доступа к машине выполнять все операции в однопользовательском режиме.<br /> <br /> Текущая система:<br /> <br /> &lt;pre&gt;<br /> # df -h<br /> Filesystem Size Used Avail Capacity Mounted on<br /> /dev/sd0a 490M 27.6M 438M 6 % /<br /> /dev/sd0d 38.4G 4.0M 36.5G 0 % /home<br /> /dev/sd0e 982M 6.0K 933M 0 % /tmp<br /> /dev/sd0f 17.5G 821M 15.9G 5 % /usr<br /> /dev/sd0g 9.6G 7.1M 9.1G 0 % /var<br /> &lt;/pre&gt;<br /> <br /> Уже сейчас можно составить конфиг для создания устройств ccd(4) при загрузке системы:<br /> <br /> &lt;pre&gt;<br /> # vi /etc/ccd.conf<br /> ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> ccd1 16 CCDF_MIRROR /dev/sd0g /dev/sd1g<br /> ccd2 16 CCDF_MIRROR /dev/sd0f /dev/sd1f<br /> &lt;/pre&gt;<br /> <br /> Предварительно делаем бэкап &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; в &lt;span style=&quot;color:green;&quot;&gt;/usr/dump&lt;/span&gt;, иначе данные на дисках будут утеряны:<br /> <br /> &lt;pre&gt;<br /> # mkdir /usr/dump<br /> # dump -a -f /usr/dump/var.dump /var<br /> # dump -a -f /usr/dump/home.dump /home<br /> # umount -f /var<br /> # umount -f /home<br /> &lt;/pre&gt;<br /> <br /> После размонтирования необходимо внести соответствующие изменения в &lt;span style=&quot;color:green;&quot;&gt;/etc/fstab&lt;/span&gt; (старые записи больше не понадобятся):<br /> <br /> &lt;pre&gt;<br /> # vi /etc/fstab<br /> /dev/sd0a / ffs rw 1 1<br /> /dev/ccd1e /home ffs rw, nodev, nosuid 1 2<br /> /dev/sd0e /tmp ffs rw, nodev, nosuid 1 2<br /> /dev/ccd2e /usr ffs rw, nodev 1 2<br /> /dev/ccd0e /var ffs rw, nodev, nosuid 1 2<br /> &lt;/pre&gt;<br /> <br /> Создаем два устройства ccd(4) (для &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt;):<br /> <br /> # ccdconfig ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> # ccdconfig ccd1 16 CCDF_MIRROR /dev/sd0g /dev/sd1g<br /> <br /> Для каждого из созданных устройств меняем тип раздела «с» на &lt;tt&gt;unused&lt;/tt&gt; и создаем одну большую партицию «e» с типом 4.2BSD на весь диск:<br /> <br /> &lt;pre&gt;<br /> # disklabel -E ccd0<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> &lt;/pre&gt;<br /> <br /> И для ccd1:<br /> <br /> &lt;pre&gt;<br /> # disklabel -E ccd1<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> &lt;/pre&gt;<br /> <br /> Создаем файловые системы:<br /> <br /> # newfs ccd0e<br /> # newfs ccd1e<br /> <br /> Снова монтируем /&lt;span style=&quot;color:green;&quot;&gt;/var&lt;/span&gt; и &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;, но уже как устройства ccd(4). Восстанавливаем данные из резервной копии:<br /> <br /> &lt;pre&gt;<br /> # mount /var<br /> # cd /var &amp;&amp; restore -r -f /usr/dump/var.dump<br /> # mount /home<br /> # cd /home &amp;&amp; restore -r -f /usr/dump/home.dump<br /> &lt;/pre&gt;<br /> <br /> Подготавливаем бэкап /&lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;:<br /> <br /> # mkdir /home/dump<br /> # dump -a -f /home/dump/usr.dump /usr<br /> <br /> Перегружаемся в &lt;tt&gt;single user mode&lt;/tt&gt; (удаленно размонтировать /&lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt; нельзя). Делаем с ccd2 то же самое, что делали ранее с ccd0 и ccd1:<br /> <br /> &lt;pre&gt;<br /> # ccdconfig ccd2 16 CCDF_MIRROR /dev/sd0f /dev/sd1f<br /> # disklabel -E ccd2<br /> &gt; m c<br /> &gt; [4.2BSD] unused<br /> &gt; a e<br /> <br /> # newfs ccd2e<br /> # mount /usr<br /> &lt;/pre&gt;<br /> <br /> Создаем ccd0 и монтируем &lt;span style=&quot;color:green;&quot;&gt;/home&lt;/span&gt;:<br /> <br /> # ccdconfig ccd0 16 CCDF_MIRROR /dev/sd0d /dev/sd1d<br /> # mount /home<br /> <br /> Возвращаем данные на &lt;span style=&quot;color:green;&quot;&gt;/usr&lt;/span&gt;:<br /> <br /> # cd /usr &amp;&amp; restore -r -f /home/dump/usr.dump<br /> <br /> Перезагружаемся:<br /> <br /> # reboot<br /> <br /> В итоге получаем:<br /> <br /> &lt;pre&gt;<br /> # df -h<br /> Filesystem Size Used Avail Capacity Mounted on<br /> /dev/sd0a 490M 27.6M 438M 6 % /<br /> /dev/ccd1e 38.4G 4.0M 36.5G 0 % /home<br /> /dev/sd0e 982M 6.0K 933M 0 % /tmp<br /> /dev/ccd2e 17.5G 815M 15.9G 5 % /usr<br /> /dev/ccd0e 9.6G 7.1M 9.1G 0 % /var<br /> &lt;/pre<br /> <br /> Статья основана на материалах, предоставленных Антоном Карповым [http://www.toxahost.ru/ www.toxahost.ru].<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=200 2013-06-05T12:14:36Z

<p>Nordwind: /* Инсталляция на стороне клиента */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу &lt;tt&gt;_openvpn&lt;/tt&gt; и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах &lt;tt&gt;openssl&lt;/tt&gt; можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый &lt;tt&gt;shared secret&lt;/tt&gt;):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс &lt;tt&gt;tun0&lt;/tt&gt;:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт &lt;tt&gt;1194/udp&lt;/tt&gt;:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы [http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe OpenVPN GUI] и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=199 2013-06-05T12:09:52Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[Деликатное проникновение в частную сеть]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=198 2013-06-05T12:06:55Z

<p>Nordwind: /* Щепетильное конфигурирование */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу &lt;tt&gt;_openvpn&lt;/tt&gt; и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах &lt;tt&gt;openssl&lt;/tt&gt; можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый &lt;tt&gt;shared secret&lt;/tt&gt;):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс &lt;tt&gt;tun0&lt;/tt&gt;:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт &lt;tt&gt;1194/udp&lt;/tt&gt;:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=197 2013-06-05T12:04:43Z

<p>Nordwind: /* Золотые ключики и подарочные сертификаты */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу &lt;tt&gt;_openvpn&lt;/tt&gt; и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах &lt;tt&gt;openssl&lt;/tt&gt; можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый &lt;tt&gt;shared secret&lt;/tt&gt;):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=196 2013-06-05T12:03:00Z

<p>Nordwind: </p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу &lt;tt&gt;_openvpn&lt;/tt&gt; и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=195 2013-06-05T12:02:09Z

<p>Nordwind: /* Серверная инсталляция */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу &lt;tt&gt;_openvpn&lt;/tt&gt; и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=194 2013-06-05T12:01:04Z

<p>Nordwind: /* Серверная инсталляция */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов &lt;tt&gt;lzo&lt;/tt&gt;:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу _openvpn и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=193 2013-06-05T11:59:26Z

<p>Nordwind: </p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов lzo:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу _openvpn и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%94%D0%B5%D0%BB%D0%B8%D0%BA%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%BD%D0%B8%D0%BA%D0%BD%D0%BE%D0%B2%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B2_%D1%87%D0%B0%D1%81%D1%82%D0%BD%D1%83%D1%8E_%D1%81%D0%B5%D1%82%D1%8C&diff=192 2013-06-05T11:57:27Z

<p>Nordwind: Новая страница: «:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru] &lt;br /&gt; Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp о…»</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> <br /> Статья [http://www.xakep.ru/magazine/xa/110/156/1.asp опубликована] в февральском номере журнала Хакер за 2008 год. Автор оригинального текста: Andrey Matveev (andrey at openbsd dot ru). <br /> <br /> == Введение ==<br /> <br /> Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.<br /> <br /> <br /> == Поем дифирамбы OpenVPN ==<br /> <br /> OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS. С его помощью можно поднять надежный, достаточно быстрый и в то же время защищенный от прослушивания и вмешательства злоумышленников криптотуннель поверх общедоступной сети, такой, как Интернет. В двух словах схему работы этого приложения можно описать следующим образом: любой сетевой трафик, посылаемый или принимаемый для сетевого адаптера, инкапсулируется в зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где данные расшифровываются и попадают в удаленную сеть.<br /> К числу основных преимуществ применения OpenVPN стоит отнести:<br /> <br /> * высокая переносимость между платформами – пакет работает на Windows 2000/XP/2003/Vista, Linux, Free/Net/OpenBSD, Mac OS X и Solaris;<br /> * поддержка режимов маршрутизации (routed) и моста (bridged), другими словами, нам под силу туннелировать как IP-пакеты, так и Ethernet-фреймы;<br /> * для транспорта можно использовать UDP/TCP;<br /> * клиентские хосты могут иметь статические и динамические IP-адреса;<br /> * туннели можно создавать поверх NAT;<br /> * работа через межсетевые экраны, в которых реализован контроль состояния соединений (достигается за счет отправки через определенные промежутки времени echo-запросов);<br /> * ассиметричное шифрование с использованием статических ключей и SSL/TLS сертификатов;<br /> * встроенные меры безопасности для предотвращения DoS-атак и повторного проигрывания злоумышленником последовательности записанных пакетов;<br /> * адаптивная компрессия передаваемых данных;<br /> * способность &quot;проталкивать&quot; маршруты для клиента;<br /> * использование всех механизмов шифрования, встроенных в библиотеку OpenSSL;<br /> * работа в chroot-окружении;<br /> * поддержка мультипоточной библиотеки pthread (положительно влияет на быстродействие при динамическом обмене SSL/TLS ключами). <br /> <br /> Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).<br /> <br /> <br /> == Увертюра к основному действию ==<br /> <br /> Предположим, одним прекрасным солнечным утром твое высокое начальство впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой стоит задача поднять VPN-сервер для служащих, которым требуется работать с корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные, командировочные сотрудники или просто фрилансеры).<br /> Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1) под управлением… хотя это не так важно, настройки в поддерживаемых операционках будут отличаться минимально. В моем случае на сервере заказчика была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного (192.168.2.0/24). После рекогносцировки на местности переходим к установке OpenVPN.<br /> <br /> <br /> == Серверная инсталляция ==<br /> <br /> OpenVPN без труда можно найти в любом репозитарии или дереве портов:<br /> <br /> # cd /usr/ports/net/openvpn<br /> # make install clean<br /> <br /> В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов lzo:<br /> <br /> # ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \<br /> --with-lzoheaders=/usr/local/include<br /> # make<br /> # make install<br /> <br /> Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:<br /> <br /> # /usr/local/sbin/openvpn --show-digests<br /> # /usr/local/sbin/openvpn --show-ciphers<br /> <br /> Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot’ной среде — среде с измененным корневым каталогом. Первый шаг для этого — добавить в систему группу _openvpn и одноименного пользователя:<br /> <br /> # groupadd -g 500 _openvpn<br /> # useradd -u 500 -g 500 -c &#039;OpenVPN Server&#039; -s /sbin/nologin \<br /> -d /var/openvpn -m _openvpn<br /> <br /> Проверяем правильность выполнения двух последних команд:<br /> <br /> # grep 500 /etc/passwd<br /> _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin<br /> <br /> == Золотые ключики и подарочные сертификаты ==<br /> <br /> Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас тратить время на теоретическую часть и перейдем непосредственно к процедуре генерирования надлежащих сертификатов.<br /> Создаем директорию, где будут лежать конфигурационные файлы, скрипты и сертификаты:<br /> <br /> # mkdir -p /etc/openvpn/keys<br /> <br /> Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.<br /> <br /> # cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn<br /> <br /> Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:<br /> <br /> # cd /etc/openvpn/easy-rsa<br /> # . ./vars<br /> <br /> Инициализируем директорию /etc/openvpn/easy-rsa/keys:<br /> <br /> # ./clean-all<br /> <br /> Создаем корневой и серверный сертификаты:<br /> <br /> # ./build-ca<br /> # ./build-key-server server<br /> <br /> Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:<br /> <br /> # ./build-dh<br /> <br /> Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):<br /> <br /> # /usr/local/sbin/openvpn --genkey --secret keys/ta.key<br /> <br /> Перемещаем все созданные файлы в подкаталог &lt;span style=&quot;color:green;&quot;&gt;keys&lt;/span&gt; и выставляем для них корректные права доступа:<br /> <br /> # cd keys/<br /> # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys<br /> # chown -R root:wheel /etc/openvpn<br /> # chmod 700 /etc/openvpn/keys<br /> # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt}<br /> # chmod 600 /etc/openvpn/keys/{server.key,ta.key}<br /> <br /> Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:<br /> <br /> # ./build-key client1<br /> # mkdir -p /home/vpn/client1<br /> # mv client1.crt client1.key /home/vpn/client1<br /> # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1<br /> <br /> Теперь подкаталог &lt;span style=&quot;color:green;&quot;&gt;client1&lt;/span&gt; следует перенести на винч или флешку «географически изолированного» сотрудника.<br /> <br /> == Щепетильное конфигурирование ==<br /> <br /> Конфигурация сервера OpenVPN хранится в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/openvpn/server.conf&lt;/span&gt;. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся «не срезать углы» — за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в &lt;span style=&quot;color:green;&quot;&gt;server.conf&lt;/span&gt; желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.<br /> <br /> # vi /etc/openvpn/server.conf<br /> ; Работаем в режиме демона<br /> daemon openvpn<br /> ; Указываем местоположение файла с уникальным идентификатором процесса сервера<br /> ; OpenVPN<br /> writepid /var/openvpn/pid<br /> ; Определяем файл, содержащий список текущих клиентских соединений<br /> status /var/openvpn/status 10<br /> ; Внешний IP-адрес нашего сервера<br /> local 213.167.XX.YY<br /> ; Используемый порт<br /> port 1194<br /> ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный<br /> ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию<br /> ; встроенной функции подтверждения доставки пакетов, производительность UDP<br /> ; значительно выше. А во-вторых, при использовании UDP общая надежность не<br /> ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку<br /> ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять<br /> ; только в тех случаях, когда UDP не работает, например, если брандмауэр<br /> ; блокирует весь UDP-трафик.<br /> proto udp<br /> ; Выбираем тип виртуального устройства туннеля (tun, tap или null)<br /> dev tun0<br /> ; Включаем компрессию передаваемых данных<br /> comp-lzo<br /> ; Указываем абсолютные пути к созданным сертификатам и ключам<br /> ca /etc/openvpn/keys/ca.crt<br /> cert /etc/openvpn/keys/server.crt<br /> key /etc/openvpn/keys/server.key<br /> dh /etc/openvpn/keys/dh1024.pem<br /> ; Значение 0 следует использовать на сервере, 1 - на клиенте<br /> tls-auth /etc/openvpn/keys/ta.key 0<br /> ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом<br /> ; случае широковещательный трафик отсутствует, соответственно, не будут работать<br /> ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но<br /> ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых<br /> ; дисков/созданием ярлыков на расшаренные ресурсы<br /> server 192.168.3.0 255.255.255.0<br /> ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли<br /> ; получить доступ к ресурсам проводной и беспроводной сети<br /> push &quot;route 192.168.1.0 255.255.255.0&quot;<br /> push &quot;route 192.168.2.0 255.255.255.0&quot;<br /> ; Не позволяем соединению разорваться при простое<br /> keepalive 10 120<br /> ; Алгоритмы, используемые для аутентификации и шифрования пакетов<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Максимальное число одновременно подключенных VPN-пользователей<br /> max-clients 10<br /> ; Задаем файл журналирования событий и уровень детализации журнала, отображаем<br /> ; не более 20 экземпляров одного сообщения (остальные отбрасываем)<br /> log-append /var/log/openvpn.log<br /> verb 3<br /> mute 20<br /> ; Пользователь и группа, с правами которых работает демон<br /> user _openvpn<br /> group _openvpn<br /> ; Эти опции предотвращают доступ к некоторым ресурсам (например,<br /> ; tun-устройству) при перезапуске демона (рекомендуется применять только при<br /> ; снижении привилегий)<br /> persist-key<br /> persist-tun<br /> ; Сажаем демона в chroot-окружение<br /> chroot /var/empty<br /> <br /> Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:<br /> <br /> # cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn<br /> <br /> Поднимаем виртуальный интерфейс tun0:<br /> <br /> # echo &quot;up&quot; &gt; /etc/hostname.tun0<br /> # sh /etc/netstart tun0<br /> <br /> Запускаем сервер OpenVPN командой:<br /> <br /> # /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> <br /> Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt;, например, так:<br /> <br /> # vi /etc/rc.local<br /> if [ -x /usr/local/sbin/openvpn ]; then<br /> echo -n &#039; openvpn&#039;; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf<br /> fi<br /> <br /> Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:<br /> <br /> # tail /var/log/openvpn.log<br /> Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62<br /> Sun Dec 2 15:31:37 2007 Initialization Sequence Completed<br /> <br /> Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой &lt;tt&gt;ifconfig&lt;/tt&gt;:<br /> <br /> # ifconfig tun0<br /> tun0: flags=8051&lt;UP,POINTOPOINT,RUNNING,MULTICAST&gt; mtu 1500<br /> groups: tun<br /> inet 192.168.3.1 --&gt; 192.168.3.2 netmask 0xffffffff<br /> <br /> Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:<br /> <br /> # vi /etc/pf.conf<br /> pass quick on { lo tun0 $int_if } inet<br /> pass in on $ext_if inet proto udp from any to $ext_if port 1194 \<br /> keep state<br /> <br /> Перезагружаем набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> == Инсталляция на стороне клиента ==<br /> <br /> Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла &lt;span style=&quot;color:green;&quot;&gt;client*.ovpn&lt;/span&gt;.<br /> <br /> C:\Program Files\OpenVPN\config\mycompany_client1.ovpn<br /> ; Работаем в режиме клиента<br /> client<br /> dev tun<br /> ; Указываем IP-адрес и порт VPN-сервера<br /> remote 213.167.XX.YY 1194<br /> proto udp<br /> resolv-retry infinite<br /> nobind<br /> pull<br /> comp-lzo<br /> persist-key<br /> persist-tun<br /> verb 3<br /> ; Я предпочитаю хранить crt и key файлы на флешке<br /> ca &quot;f:\\vpn\\mycompany\\ca.crt&quot;<br /> cert &quot;f:\\vpn\\mycompany\\client1.crt&quot;<br /> key &quot;f:\\vpn\\mycompany\\client1.key&quot;<br /> tls-auth &quot;f:\\vpn\\mycompany\\ta.key&quot; 1<br /> ns-cert-type server<br /> ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере<br /> auth SHA1<br /> cipher AES-256-CBC<br /> ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера<br /> ; route-method exe<br /> ; route-delay 2<br /> <br /> Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг &lt;tt&gt;mycompany_client1&lt;/tt&gt; и нажать Connect.<br /> <br /> <br /> == Аутентификационный шлюз на базе pf и authpf ==<br /> <br /> В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и корпоративной сети. Схема работы такой конструкции довольно проста: пользователь логинится по ssh, и, в зависимости от введенных данных (имя и пароль), на сервере вступают в силу персональные правила файервола, в данном случае разрешающие прохождение UDP-пакетов к порту 1194.<br /> Но прежде, чем производить настройку &lt;tt&gt;authpf&lt;/tt&gt;, необходимо переопределить некоторые дефолтные значения переменных демона [http://www.openbsd.org/cgi-bin/man.cgi?query=sshd&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html sshd(8)]. Так мы усложним потенциальному злоумышленнику успешное проведение атаки с целью перехвата и подмены ssh-сессии.<br /> <br /> # vi /etc/ssh/sshd_config<br /> # Работаем с использованием протоколов IPv4 и ssh2<br /> AddressFamily inet<br /> Protocol 2<br /> # Ожидаем подключения по всем доступным сетевым интерфейсам<br /> ListenAddress 0.0.0.0<br /> # Запрещаем регистрацию root&#039;а и применение пустых паролей<br /> PermitRootLogin no<br /> PermitEmptyPasswords no<br /> # За счет использования протокола ssh2 и этих двух опций усложняем проведение<br /> # атак типа ARP- и IP-spoofing<br /> ClientAliveInterval 15<br /> ClientAliveCountMax 3<br /> # Отключаем DNS-резолвинг<br /> UseDNS no<br /> # Определяем списки контроля доступом<br /> AllowGroups wheel users authpf<br /> <br /> Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:<br /> <br /> # kill -HUP `sed q /var/run/sshd.pid`<br /> <br /> Authpf представляет собой псевдооболочку, которая назначается пользователю системы в качестве &lt;tt&gt;login shell&lt;/tt&gt; (примечание: запись «&lt;span style=&quot;color:green;&quot;&gt;/usr/sbin/authpf&lt;/span&gt;» в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/shells&lt;/span&gt; добавлять не следует). При авторизации пользователя по ssh к текущим правилам фильтра пакетов с помощью так называемых якорей &lt;tt&gt;(anchors)&lt;/tt&gt; будут присоединены правила, указанные в файле &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/authpf.rules&lt;/span&gt;, либо в &lt;span style=&quot;color:green;&quot;&gt;/etc/authpf/users/$USER&lt;/span&gt;. В добавляемых правилах допускается использование зарезервированных макросов &lt;tt&gt;$user_id&lt;/tt&gt; и &lt;tt&gt;$user_ip&lt;/tt&gt;, за счет которых будет происходить автоматическая подстановка имени и IP-адреса подключившегося пользователя (значения макросов считываются из переменных окружения ssh автоматически).<br /> В конец файла &lt;span style=&quot;color:green;&quot;&gt;[http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html login.conf(5)]&lt;/span&gt; заносим сведения о новом классе &lt;tt&gt;authpf&lt;/tt&gt;, пользователи которого в качестве стандартного шелла будут получать authpf:<br /> <br /> # vi /etc/login.conf<br /> authpf:\<br /> :shell=/usr/sbin/authpf:\<br /> :tc=default:<br /> <br /> С помощью штатной утилиты [http://www.openbsd.org/cgi-bin/man.cgi?query=cap_mkdb&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html cap_mkdb(1)] обновляем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/login.conf.db&lt;/span&gt;:<br /> <br /> # cap_mkdb /etc/login.conf<br /> <br /> Мы не будем переопределять умолчальные значения директив &lt;tt&gt;anchor&lt;/tt&gt; и &lt;tt&gt;table&lt;/tt&gt;, поэтому файл &lt;span style=&quot;color:green;&quot;&gt;authpf.conf&lt;/span&gt; оставляем пустым:<br /> <br /> # echo -n &gt; /etc/authpf/authpf.conf<br /> <br /> Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):<br /> <br /> # vi /etc/authpf/authpf.message<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:<br /> <br /> # useradd -m -c &#039;authpf vpn user&#039; -g authpf -L authpf \<br /> -s /usr/sbin/authpf client1<br /> # passwd client1<br /> <br /> Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:<br /> <br /> # mkdir -p /etc/authpf/users/client1<br /> <br /> # vi /etc/authpf/users/client1/authpf.rules<br /> pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \<br /> port 1194 keep state<br /> <br /> Теперь для подключения механизма якорей добавим следующие записи в [http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&amp;apropos=0&amp;sektion=0&amp;manpath=OpenBSD+Current&amp;arch=i386&amp;format=html pf.conf(5)]:<br /> <br /> # vi /etc/pf.conf<br /> nat-anchor &quot;authpf/*&quot;<br /> rdr-anchor &quot;authpf/*&quot;<br /> binat-anchor &quot;authpf/*&quot;<br /> ...<br /> pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state<br /> ...<br /> anchor &quot;authpf/*&quot;<br /> <br /> И перезагрузим набор рулесетов файервола:<br /> <br /> # pfctl -f /etc/pf.conf<br /> <br /> На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.<br /> <br /> # f:\vpn\putty&gt; plink.exe -pw mypassword client1@213.167.XX.YY<br /> Hello client1. You are authenticated from host &quot;77.41.XX.YY&quot;<br /> This service is for authorised VPN-clients only. Please play nice.<br /> <br /> А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.<br /> <br /> == Эндшпиль ==<br /> <br /> Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_sendmail&diff=186 2013-06-03T12:32:43Z

<p>Nordwind: /* Как заставить sendmail использовать /etc/hosts */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> <br /> == Настройка TLS и SSL ==<br /> <br /> Начиная с версии 8.11, sendmail поддерживает защиту ESMTP соединения с помощью расширения STARTTLS (RFC 2487). Для настройки TLS прежде всего нужно создать SSL сертификат и секретный DSA-ключ для шифрования:<br /> <br /> &lt;pre&gt;<br /> # mkdir -m 700 /etc/mail/certs<br /> # openssl dsaparam 1024 -out dsa1024.pem<br /> # openssl req -x509 -nodes -days 365 -newkey dsa: dsa1024.pem \<br /> -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem<br /> # rm -f dsa1024.pem<br /> &lt;/pre&gt;<br /> <br /> Если у вас уже есть ключ шифрования, то для создания сертификата следует подать команду:<br /> <br /> &lt;pre&gt;<br /> # openssl req -x509 -new -days 365 -key /etc/mail/certs/mykey.pem \<br /> -out /etc/mail/certs/mycert.pem<br /> &lt;/pre&gt;<br /> <br /> Параметр &#039;&#039;-days&#039;&#039; позволяет указать количество дней, в течение которых сертификат будет действительным. Чтобы проверить созданный сертификат, можно воспользоваться следующей командой:<br /> <br /> # openssl x509 -in /etc/mail/certs/mycert.pem -text<br /> <br /> Если вы не планируете использовать TLS для авторизации (не путать с [[#Настройка SMTP авторизации|SMTP авторизацией]]) или используете сертификат, подписанный самим собой, следует создать symlink:<br /> <br /> # ln -s /etc/mail/certs/mycert.pem /etc/mail/certs/CAcert.pem<br /> <br /> В противном случае следует поместить сертификат авторизации в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/certs/CAcert.pem&lt;/span&gt; Не забудьте установить права, запрещающие чтение/запись файлов сертификатов и ключей простым пользователям:<br /> <br /> # chmod 600 /etc/mail/certs/*<br /> <br /> Теперь следует настроить sendmail. В .mc файле конфигурации нужно добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> define(`CERT_DIR&#039;, `MAIL_SETTINGS_DIR`&#039;certs&#039;)dnl<br /> define(`confCACERT_PATH&#039;, `CERT_DIR&#039;)dnl<br /> define(`confCACERT&#039;, `CERT_DIR/CAcert.pem&#039;)dnl<br /> define(`confSERVER_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confSERVER_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> define(`confCLIENT_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confCLIENT_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> После добавления вышеуказанных строк в файл конфигурации следует пересобрать его с помощью m4 (см. файл &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;) и рестартовать уже запущенный sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настроек TLS можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH PLAIN<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-STARTTLS». Смотрите также по данной теме <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=starttls&amp;sektion=8 starttls(8)], <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=ssl&amp;sektion=8 ssl(8)], <br /> [http://www.sendmail.org/~ca/email/starttls.html http://www.sendmail.org/~ca/email/starttls.html], &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;.<br /> <br /> Для того чтобы научить sendmail работать по SSL (без использования STARTTLS), нужно создать и добавить в .mc файл сертификат и ключ для шифрования, как описано выше, а также добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> DAEMON_OPTIONS(`Name=MTA&#039;)dnl<br /> DAEMON_OPTIONS(`Port=465, Name=MTA-SSL, M=s&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки можно воспользоваться командой openssl:<br /> <br /> &lt;pre&gt;<br /> # openssl s_client -connect localhost:465<br /> CONNECTED(00000004)<br /> <br /> […]<br /> <br /> ---<br /> SSL handshake has read 1409 bytes and written 288 bytes<br /> ---<br /> New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA<br /> Server public key is 1024 bit<br /> SSL-Session:<br /> Protocol : TLSv1<br /> Cipher : DHE-DSS-AES256-SHA<br /> Session-ID:<br /> 28CAD859854BC30F61B0013DF835E69CDB0037D82FD741F9C7A56DD1E25B655<br /> Session-ID-ctx:<br /> Master-Key:<br /> F5BA53F5C0659E3E12D1057FE8D4AEA8177A868169B35949793ABECED7870A29FF4B3AFB9D479EA86618185D5192B837<br /> Key-Arg : None<br /> Start Time: 1119252698<br /> Timeout : 300 (sec)<br /> Verify return code: 18 (self signed certificate)<br /> ---<br /> 220 cvs.openbsd.ru ESMTP Sendmail 8.12.11/8.12.11; Mon, 20 Jun 2005 11:37:06 +0400 (MSD)<br /> &lt;/pre&gt;<br /> <br /> == Настройка SMTP авторизации ==<br /> <br /> Для настройки авторизации следует пересобрать sendmail с поддержкой SASL. Для этого следует установить пакет &#039;&#039;cyrus-sasl2&#039;&#039; или порт &#039;&#039;security/cyrus-sasl2&#039;&#039;. Для включения поддержки SASL нам потребуется перекомпилировать sendmail следующим образом:<br /> <br /> &lt;pre&gt;<br /> # echo WANT_SMTPAUTH=yes &gt;&gt; /etc/mk.conf<br /> # cd /usr/src/gnu/usr.sbin/sendmail<br /> # make cleandir<br /> # make obj<br /> # make depend<br /> # make<br /> # make install<br /> &lt;/pre&gt;<br /> <br /> Также можно воспользоваться набором site.tar.gz и пересобрать sendmail, установив настройку SENDMAIL_SASL=Yes в mk.conf.<br /> <br /> Далее следует создать файл конфигурации SASL для sendmail ( &lt;span style=&quot;color:green;&quot;&gt;/usr/local/lib/sasl2/Sendmail.conf&lt;/span&gt;):<br /> <br /> pwcheck_method: saslauthd<br /> <br /> Добавляем в &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt; строки для запуска saslauthd:<br /> <br /> &lt;pre&gt;<br /> if [ -x /usr/local/sbin/saslauthd ]; then<br /> echo -n &#039; saslauthd&#039;; /usr/local/sbin/saslauthd -a getpwent<br /> fi<br /> &lt;/pre&gt;<br /> <br /> Теперь остается только включить поддержку авторизации в .mc файле конфигурации sendmail:<br /> <br /> &lt;pre&gt;<br /> dnl<br /> dnl Эту опцию следует включить, чтобы запретить авторизацию с помощью<br /> dnl механизмов PLAIN и LOGIN по незащищенному соединению<br /> dnl (без использования TLS).<br /> dnl<br /> define(`confAUTH_OPTIONS&#039;, `p&#039;)dnl<br /> dnl<br /> dnl Список допустимых механизмов авторизации. Для всех механизмов,<br /> dnl кроме PLAIN и LOGIN, невозможна авторизация по системному файлу<br /> dnl паролей. Для них следует использовать sasldb или другие способы<br /> dnl авторизации (см. документацию sasl2).<br /> dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> dnl<br /> dnl Список механизмов, авторизация по которым разрешает использовать<br /> dnl сервер для пересылки почты (relaying).<br /> dnl<br /> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настройки авторизации можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH DIGEST-MD5 CRAM-MD5<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-AUTH». В случае если в файле конфигурации запрещено использование PLAIN авторизации по незащищенному соединению, вместо команды telnet следует использовать команду openssl:<br /> <br /> # openssl s_client -starttls smtp -connect localhost: smtp<br /> <br /> Смотрите также &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;, [[#Настройка TLS и SSL|Настройка TLS и SSL]].<br /> <br /> == Настройка sendmail как SMTP клиента с авторизацией ==<br /> <br /> В случае, когда sendmail выступает в роли клиента, демон saslauthd не требуется. В файл конфигурации необходимо внести следующие изменения:<br /> <br /> &lt;pre&gt;<br /> define(`SMART_HOST&#039;, `smtp: smtp.domain.ru&#039;)dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> FEATURE(`authinfo&#039;, `hash /etc/mail/authinfo&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Указываем SMTP-сервер, имя и пароль пользователя, а также метод аутентификации в отдельном файле &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/authinfo&lt;/span&gt;:<br /> <br /> AuthInfo: smtp.domain.ru «U:username@domain.ru» «P:mypassword» «M:CRAM-MD5»<br /> <br /> Создаем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/authinfo.db&lt;/span&gt;:<br /> <br /> # makemap hash /etc/mail/authinfo &lt; /etc/mail/authinfo<br /> <br /> == Как заставить sendmail использовать /etc/hosts ==<br /> <br /> По умолчанию sendmail использует в первую очередь DNS. Чтобы заставить его сначала смотреть &lt;span style=&quot;color:green;&quot;&gt;/etc/hosts&lt;/span&gt;, нужно создать файл &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/service.switch&lt;/span&gt; и прописать в нем следующую строку:<br /> <br /> hosts files dns<br /> <br /> После этого достаточно перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> == Хранение писем в Maildir ==<br /> <br /> По умолчанию sendmail использует mail.local в качестве локального агента доставки почты. При этом почта доставляется в формате стандартного BSD mailbox. Чтобы доставлять почту в Maildir, нам потребуется установить альтернативный агент доставки mail.buhal, который можно скачать [http://pdp-11.org.ru/~form/openbsd/files/sys/mail.buhal-1.0.tar.gz отсюда].<br /> <br /> Сначала нужно собрать и установить mail.buhal:<br /> <br /> # make depend &amp;&amp; make &amp;&amp; make install<br /> <br /> Далее следует указать mail.buhal в файле конфигурации sendmail в качестве локального агента доставки:<br /> <br /> &lt;pre&gt;<br /> define(`LOCAL_MAILER_PATH&#039;, `/usr/libexec/mail.buhal&#039;)dnl<br /> MODIFY_MAILER_FLAGS(`LOCAL&#039;, `-m&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> В портах OpenBSD, в категории mail, есть программы &#039;&#039;procmail&#039;&#039; и &#039;&#039;maildrop&#039;&#039;, которые также поддерживают формат Maildir и дополнительные расширения данного формата.<br /> <br /> == Использование procmail в качестве LDA ==<br /> <br /> После установки procmail из портов или пакетов, необходимо создать глобальный конфигурационный файл. Пример конфигурации:<br /> <br /> &lt;pre&gt;<br /> # Секция общих настроек.<br /> # <br /> DROPPRIVS=yes<br /> COMSAT=no<br /> VERBOSE=off<br /> SHELL=/bin/sh<br /> PATH=/bin:/usr/bin:/usr/local/bin<br /> LOCKFILE=$HOME/.lockmail<br /> LOGFILE=$HOME/procmail.log<br /> <br /> # Складываем почту в формате Maildir.<br /> # <br /> MAILDIR=$HOME/Maildir/<br /> DEFAULT=$MAILDIR<br /> <br /> # Входящую корреспонденцию можно резервировать в файлы формата mbox.<br /> # <br /> #: 0 c<br /> # /var/mail/$LOGNAME<br /> <br /> # Либо передавать в хранилище на другом хосте.<br /> # <br /> #: 0 c<br /> # ! mail@mx2.domain.ru<br /> &lt;/pre&gt;<br /> <br /> Далее необходимо изменить локальный агент доставки (LDA) с mail.local на procmail:<br /> <br /> &lt;pre&gt;<br /> FEATURE(local_procmail)dnl<br /> MAILER(local)dnl<br /> MAILER(smtp)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_sendmail&diff=185 2013-06-03T12:31:20Z

<p>Nordwind: /* Настройка sendmail как SMTP клиента с авторизацией */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> <br /> == Настройка TLS и SSL ==<br /> <br /> Начиная с версии 8.11, sendmail поддерживает защиту ESMTP соединения с помощью расширения STARTTLS (RFC 2487). Для настройки TLS прежде всего нужно создать SSL сертификат и секретный DSA-ключ для шифрования:<br /> <br /> &lt;pre&gt;<br /> # mkdir -m 700 /etc/mail/certs<br /> # openssl dsaparam 1024 -out dsa1024.pem<br /> # openssl req -x509 -nodes -days 365 -newkey dsa: dsa1024.pem \<br /> -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem<br /> # rm -f dsa1024.pem<br /> &lt;/pre&gt;<br /> <br /> Если у вас уже есть ключ шифрования, то для создания сертификата следует подать команду:<br /> <br /> &lt;pre&gt;<br /> # openssl req -x509 -new -days 365 -key /etc/mail/certs/mykey.pem \<br /> -out /etc/mail/certs/mycert.pem<br /> &lt;/pre&gt;<br /> <br /> Параметр &#039;&#039;-days&#039;&#039; позволяет указать количество дней, в течение которых сертификат будет действительным. Чтобы проверить созданный сертификат, можно воспользоваться следующей командой:<br /> <br /> # openssl x509 -in /etc/mail/certs/mycert.pem -text<br /> <br /> Если вы не планируете использовать TLS для авторизации (не путать с [[#Настройка SMTP авторизации|SMTP авторизацией]]) или используете сертификат, подписанный самим собой, следует создать symlink:<br /> <br /> # ln -s /etc/mail/certs/mycert.pem /etc/mail/certs/CAcert.pem<br /> <br /> В противном случае следует поместить сертификат авторизации в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/certs/CAcert.pem&lt;/span&gt; Не забудьте установить права, запрещающие чтение/запись файлов сертификатов и ключей простым пользователям:<br /> <br /> # chmod 600 /etc/mail/certs/*<br /> <br /> Теперь следует настроить sendmail. В .mc файле конфигурации нужно добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> define(`CERT_DIR&#039;, `MAIL_SETTINGS_DIR`&#039;certs&#039;)dnl<br /> define(`confCACERT_PATH&#039;, `CERT_DIR&#039;)dnl<br /> define(`confCACERT&#039;, `CERT_DIR/CAcert.pem&#039;)dnl<br /> define(`confSERVER_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confSERVER_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> define(`confCLIENT_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confCLIENT_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> После добавления вышеуказанных строк в файл конфигурации следует пересобрать его с помощью m4 (см. файл &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;) и рестартовать уже запущенный sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настроек TLS можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH PLAIN<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-STARTTLS». Смотрите также по данной теме <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=starttls&amp;sektion=8 starttls(8)], <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=ssl&amp;sektion=8 ssl(8)], <br /> [http://www.sendmail.org/~ca/email/starttls.html http://www.sendmail.org/~ca/email/starttls.html], &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;.<br /> <br /> Для того чтобы научить sendmail работать по SSL (без использования STARTTLS), нужно создать и добавить в .mc файл сертификат и ключ для шифрования, как описано выше, а также добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> DAEMON_OPTIONS(`Name=MTA&#039;)dnl<br /> DAEMON_OPTIONS(`Port=465, Name=MTA-SSL, M=s&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки можно воспользоваться командой openssl:<br /> <br /> &lt;pre&gt;<br /> # openssl s_client -connect localhost:465<br /> CONNECTED(00000004)<br /> <br /> […]<br /> <br /> ---<br /> SSL handshake has read 1409 bytes and written 288 bytes<br /> ---<br /> New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA<br /> Server public key is 1024 bit<br /> SSL-Session:<br /> Protocol : TLSv1<br /> Cipher : DHE-DSS-AES256-SHA<br /> Session-ID:<br /> 28CAD859854BC30F61B0013DF835E69CDB0037D82FD741F9C7A56DD1E25B655<br /> Session-ID-ctx:<br /> Master-Key:<br /> F5BA53F5C0659E3E12D1057FE8D4AEA8177A868169B35949793ABECED7870A29FF4B3AFB9D479EA86618185D5192B837<br /> Key-Arg : None<br /> Start Time: 1119252698<br /> Timeout : 300 (sec)<br /> Verify return code: 18 (self signed certificate)<br /> ---<br /> 220 cvs.openbsd.ru ESMTP Sendmail 8.12.11/8.12.11; Mon, 20 Jun 2005 11:37:06 +0400 (MSD)<br /> &lt;/pre&gt;<br /> <br /> == Настройка SMTP авторизации ==<br /> <br /> Для настройки авторизации следует пересобрать sendmail с поддержкой SASL. Для этого следует установить пакет &#039;&#039;cyrus-sasl2&#039;&#039; или порт &#039;&#039;security/cyrus-sasl2&#039;&#039;. Для включения поддержки SASL нам потребуется перекомпилировать sendmail следующим образом:<br /> <br /> &lt;pre&gt;<br /> # echo WANT_SMTPAUTH=yes &gt;&gt; /etc/mk.conf<br /> # cd /usr/src/gnu/usr.sbin/sendmail<br /> # make cleandir<br /> # make obj<br /> # make depend<br /> # make<br /> # make install<br /> &lt;/pre&gt;<br /> <br /> Также можно воспользоваться набором site.tar.gz и пересобрать sendmail, установив настройку SENDMAIL_SASL=Yes в mk.conf.<br /> <br /> Далее следует создать файл конфигурации SASL для sendmail ( &lt;span style=&quot;color:green;&quot;&gt;/usr/local/lib/sasl2/Sendmail.conf&lt;/span&gt;):<br /> <br /> pwcheck_method: saslauthd<br /> <br /> Добавляем в &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt; строки для запуска saslauthd:<br /> <br /> &lt;pre&gt;<br /> if [ -x /usr/local/sbin/saslauthd ]; then<br /> echo -n &#039; saslauthd&#039;; /usr/local/sbin/saslauthd -a getpwent<br /> fi<br /> &lt;/pre&gt;<br /> <br /> Теперь остается только включить поддержку авторизации в .mc файле конфигурации sendmail:<br /> <br /> &lt;pre&gt;<br /> dnl<br /> dnl Эту опцию следует включить, чтобы запретить авторизацию с помощью<br /> dnl механизмов PLAIN и LOGIN по незащищенному соединению<br /> dnl (без использования TLS).<br /> dnl<br /> define(`confAUTH_OPTIONS&#039;, `p&#039;)dnl<br /> dnl<br /> dnl Список допустимых механизмов авторизации. Для всех механизмов,<br /> dnl кроме PLAIN и LOGIN, невозможна авторизация по системному файлу<br /> dnl паролей. Для них следует использовать sasldb или другие способы<br /> dnl авторизации (см. документацию sasl2).<br /> dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> dnl<br /> dnl Список механизмов, авторизация по которым разрешает использовать<br /> dnl сервер для пересылки почты (relaying).<br /> dnl<br /> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настройки авторизации можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH DIGEST-MD5 CRAM-MD5<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-AUTH». В случае если в файле конфигурации запрещено использование PLAIN авторизации по незащищенному соединению, вместо команды telnet следует использовать команду openssl:<br /> <br /> # openssl s_client -starttls smtp -connect localhost: smtp<br /> <br /> Смотрите также &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;, [[#Настройка TLS и SSL|Настройка TLS и SSL]].<br /> <br /> == Настройка sendmail как SMTP клиента с авторизацией ==<br /> <br /> В случае, когда sendmail выступает в роли клиента, демон saslauthd не требуется. В файл конфигурации необходимо внести следующие изменения:<br /> <br /> &lt;pre&gt;<br /> define(`SMART_HOST&#039;, `smtp: smtp.domain.ru&#039;)dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> FEATURE(`authinfo&#039;, `hash /etc/mail/authinfo&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Указываем SMTP-сервер, имя и пароль пользователя, а также метод аутентификации в отдельном файле &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/authinfo&lt;/span&gt;:<br /> <br /> AuthInfo: smtp.domain.ru «U:username@domain.ru» «P:mypassword» «M:CRAM-MD5»<br /> <br /> Создаем хэшированную базу данных &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/authinfo.db&lt;/span&gt;:<br /> <br /> # makemap hash /etc/mail/authinfo &lt; /etc/mail/authinfo<br /> <br /> == Как заставить sendmail использовать /etc/hosts ==<br /> <br /> По умолчанию sendmail использует в первую очередь DNS. Чтобы заставить его сначала смотреть &lt;tt&gt;/etc/hosts&lt;/tt&gt;, нужно создать файл &lt;tt&gt;/etc/mail/service.switch&lt;/tt&gt; и прописать в нем следующую строку:<br /> <br /> hosts files dns<br /> <br /> После этого достаточно перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> <br /> == Хранение писем в Maildir ==<br /> <br /> По умолчанию sendmail использует mail.local в качестве локального агента доставки почты. При этом почта доставляется в формате стандартного BSD mailbox. Чтобы доставлять почту в Maildir, нам потребуется установить альтернативный агент доставки mail.buhal, который можно скачать [http://pdp-11.org.ru/~form/openbsd/files/sys/mail.buhal-1.0.tar.gz отсюда].<br /> <br /> Сначала нужно собрать и установить mail.buhal:<br /> <br /> # make depend &amp;&amp; make &amp;&amp; make install<br /> <br /> Далее следует указать mail.buhal в файле конфигурации sendmail в качестве локального агента доставки:<br /> <br /> &lt;pre&gt;<br /> define(`LOCAL_MAILER_PATH&#039;, `/usr/libexec/mail.buhal&#039;)dnl<br /> MODIFY_MAILER_FLAGS(`LOCAL&#039;, `-m&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> В портах OpenBSD, в категории mail, есть программы &#039;&#039;procmail&#039;&#039; и &#039;&#039;maildrop&#039;&#039;, которые также поддерживают формат Maildir и дополнительные расширения данного формата.<br /> <br /> == Использование procmail в качестве LDA ==<br /> <br /> После установки procmail из портов или пакетов, необходимо создать глобальный конфигурационный файл. Пример конфигурации:<br /> <br /> &lt;pre&gt;<br /> # Секция общих настроек.<br /> # <br /> DROPPRIVS=yes<br /> COMSAT=no<br /> VERBOSE=off<br /> SHELL=/bin/sh<br /> PATH=/bin:/usr/bin:/usr/local/bin<br /> LOCKFILE=$HOME/.lockmail<br /> LOGFILE=$HOME/procmail.log<br /> <br /> # Складываем почту в формате Maildir.<br /> # <br /> MAILDIR=$HOME/Maildir/<br /> DEFAULT=$MAILDIR<br /> <br /> # Входящую корреспонденцию можно резервировать в файлы формата mbox.<br /> # <br /> #: 0 c<br /> # /var/mail/$LOGNAME<br /> <br /> # Либо передавать в хранилище на другом хосте.<br /> # <br /> #: 0 c<br /> # ! mail@mx2.domain.ru<br /> &lt;/pre&gt;<br /> <br /> Далее необходимо изменить локальный агент доставки (LDA) с mail.local на procmail:<br /> <br /> &lt;pre&gt;<br /> FEATURE(local_procmail)dnl<br /> MAILER(local)dnl<br /> MAILER(smtp)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_sendmail&diff=184 2013-06-03T12:29:45Z

<p>Nordwind: /* Настройка SMTP авторизации */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> <br /> == Настройка TLS и SSL ==<br /> <br /> Начиная с версии 8.11, sendmail поддерживает защиту ESMTP соединения с помощью расширения STARTTLS (RFC 2487). Для настройки TLS прежде всего нужно создать SSL сертификат и секретный DSA-ключ для шифрования:<br /> <br /> &lt;pre&gt;<br /> # mkdir -m 700 /etc/mail/certs<br /> # openssl dsaparam 1024 -out dsa1024.pem<br /> # openssl req -x509 -nodes -days 365 -newkey dsa: dsa1024.pem \<br /> -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem<br /> # rm -f dsa1024.pem<br /> &lt;/pre&gt;<br /> <br /> Если у вас уже есть ключ шифрования, то для создания сертификата следует подать команду:<br /> <br /> &lt;pre&gt;<br /> # openssl req -x509 -new -days 365 -key /etc/mail/certs/mykey.pem \<br /> -out /etc/mail/certs/mycert.pem<br /> &lt;/pre&gt;<br /> <br /> Параметр &#039;&#039;-days&#039;&#039; позволяет указать количество дней, в течение которых сертификат будет действительным. Чтобы проверить созданный сертификат, можно воспользоваться следующей командой:<br /> <br /> # openssl x509 -in /etc/mail/certs/mycert.pem -text<br /> <br /> Если вы не планируете использовать TLS для авторизации (не путать с [[#Настройка SMTP авторизации|SMTP авторизацией]]) или используете сертификат, подписанный самим собой, следует создать symlink:<br /> <br /> # ln -s /etc/mail/certs/mycert.pem /etc/mail/certs/CAcert.pem<br /> <br /> В противном случае следует поместить сертификат авторизации в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/certs/CAcert.pem&lt;/span&gt; Не забудьте установить права, запрещающие чтение/запись файлов сертификатов и ключей простым пользователям:<br /> <br /> # chmod 600 /etc/mail/certs/*<br /> <br /> Теперь следует настроить sendmail. В .mc файле конфигурации нужно добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> define(`CERT_DIR&#039;, `MAIL_SETTINGS_DIR`&#039;certs&#039;)dnl<br /> define(`confCACERT_PATH&#039;, `CERT_DIR&#039;)dnl<br /> define(`confCACERT&#039;, `CERT_DIR/CAcert.pem&#039;)dnl<br /> define(`confSERVER_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confSERVER_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> define(`confCLIENT_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confCLIENT_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> После добавления вышеуказанных строк в файл конфигурации следует пересобрать его с помощью m4 (см. файл &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;) и рестартовать уже запущенный sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настроек TLS можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH PLAIN<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-STARTTLS». Смотрите также по данной теме <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=starttls&amp;sektion=8 starttls(8)], <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=ssl&amp;sektion=8 ssl(8)], <br /> [http://www.sendmail.org/~ca/email/starttls.html http://www.sendmail.org/~ca/email/starttls.html], &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;.<br /> <br /> Для того чтобы научить sendmail работать по SSL (без использования STARTTLS), нужно создать и добавить в .mc файл сертификат и ключ для шифрования, как описано выше, а также добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> DAEMON_OPTIONS(`Name=MTA&#039;)dnl<br /> DAEMON_OPTIONS(`Port=465, Name=MTA-SSL, M=s&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки можно воспользоваться командой openssl:<br /> <br /> &lt;pre&gt;<br /> # openssl s_client -connect localhost:465<br /> CONNECTED(00000004)<br /> <br /> […]<br /> <br /> ---<br /> SSL handshake has read 1409 bytes and written 288 bytes<br /> ---<br /> New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA<br /> Server public key is 1024 bit<br /> SSL-Session:<br /> Protocol : TLSv1<br /> Cipher : DHE-DSS-AES256-SHA<br /> Session-ID:<br /> 28CAD859854BC30F61B0013DF835E69CDB0037D82FD741F9C7A56DD1E25B655<br /> Session-ID-ctx:<br /> Master-Key:<br /> F5BA53F5C0659E3E12D1057FE8D4AEA8177A868169B35949793ABECED7870A29FF4B3AFB9D479EA86618185D5192B837<br /> Key-Arg : None<br /> Start Time: 1119252698<br /> Timeout : 300 (sec)<br /> Verify return code: 18 (self signed certificate)<br /> ---<br /> 220 cvs.openbsd.ru ESMTP Sendmail 8.12.11/8.12.11; Mon, 20 Jun 2005 11:37:06 +0400 (MSD)<br /> &lt;/pre&gt;<br /> <br /> == Настройка SMTP авторизации ==<br /> <br /> Для настройки авторизации следует пересобрать sendmail с поддержкой SASL. Для этого следует установить пакет &#039;&#039;cyrus-sasl2&#039;&#039; или порт &#039;&#039;security/cyrus-sasl2&#039;&#039;. Для включения поддержки SASL нам потребуется перекомпилировать sendmail следующим образом:<br /> <br /> &lt;pre&gt;<br /> # echo WANT_SMTPAUTH=yes &gt;&gt; /etc/mk.conf<br /> # cd /usr/src/gnu/usr.sbin/sendmail<br /> # make cleandir<br /> # make obj<br /> # make depend<br /> # make<br /> # make install<br /> &lt;/pre&gt;<br /> <br /> Также можно воспользоваться набором site.tar.gz и пересобрать sendmail, установив настройку SENDMAIL_SASL=Yes в mk.conf.<br /> <br /> Далее следует создать файл конфигурации SASL для sendmail ( &lt;span style=&quot;color:green;&quot;&gt;/usr/local/lib/sasl2/Sendmail.conf&lt;/span&gt;):<br /> <br /> pwcheck_method: saslauthd<br /> <br /> Добавляем в &lt;span style=&quot;color:green;&quot;&gt;/etc/rc.local&lt;/span&gt; строки для запуска saslauthd:<br /> <br /> &lt;pre&gt;<br /> if [ -x /usr/local/sbin/saslauthd ]; then<br /> echo -n &#039; saslauthd&#039;; /usr/local/sbin/saslauthd -a getpwent<br /> fi<br /> &lt;/pre&gt;<br /> <br /> Теперь остается только включить поддержку авторизации в .mc файле конфигурации sendmail:<br /> <br /> &lt;pre&gt;<br /> dnl<br /> dnl Эту опцию следует включить, чтобы запретить авторизацию с помощью<br /> dnl механизмов PLAIN и LOGIN по незащищенному соединению<br /> dnl (без использования TLS).<br /> dnl<br /> define(`confAUTH_OPTIONS&#039;, `p&#039;)dnl<br /> dnl<br /> dnl Список допустимых механизмов авторизации. Для всех механизмов,<br /> dnl кроме PLAIN и LOGIN, невозможна авторизация по системному файлу<br /> dnl паролей. Для них следует использовать sasldb или другие способы<br /> dnl авторизации (см. документацию sasl2).<br /> dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> dnl<br /> dnl Список механизмов, авторизация по которым разрешает использовать<br /> dnl сервер для пересылки почты (relaying).<br /> dnl<br /> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настройки авторизации можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH DIGEST-MD5 CRAM-MD5<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-AUTH». В случае если в файле конфигурации запрещено использование PLAIN авторизации по незащищенному соединению, вместо команды telnet следует использовать команду openssl:<br /> <br /> # openssl s_client -starttls smtp -connect localhost: smtp<br /> <br /> Смотрите также &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;, [[#Настройка TLS и SSL|Настройка TLS и SSL]].<br /> <br /> == Настройка sendmail как SMTP клиента с авторизацией ==<br /> <br /> В случае, когда sendmail выступает в роли клиента, демон saslauthd не требуется. В файл конфигурации необходимо внести следующие изменения:<br /> <br /> &lt;pre&gt;<br /> define(`SMART_HOST&#039;, `smtp: smtp.domain.ru&#039;)dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> FEATURE(`authinfo&#039;, `hash /etc/mail/authinfo&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Указываем SMTP-сервер, имя и пароль пользователя, а также метод аутентификации в отдельном файле &lt;tt&gt;/etc/mail/authinfo&lt;/tt&gt;:<br /> <br /> AuthInfo: smtp.domain.ru «U:username@domain.ru» «P:mypassword» «M:CRAM-MD5»<br /> <br /> Создаем хэшированную базу данных /etc/mail/authinfo.db:<br /> <br /> # makemap hash /etc/mail/authinfo &lt; /etc/mail/authinfo<br /> <br /> <br /> == Как заставить sendmail использовать /etc/hosts ==<br /> <br /> По умолчанию sendmail использует в первую очередь DNS. Чтобы заставить его сначала смотреть &lt;tt&gt;/etc/hosts&lt;/tt&gt;, нужно создать файл &lt;tt&gt;/etc/mail/service.switch&lt;/tt&gt; и прописать в нем следующую строку:<br /> <br /> hosts files dns<br /> <br /> После этого достаточно перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> <br /> == Хранение писем в Maildir ==<br /> <br /> По умолчанию sendmail использует mail.local в качестве локального агента доставки почты. При этом почта доставляется в формате стандартного BSD mailbox. Чтобы доставлять почту в Maildir, нам потребуется установить альтернативный агент доставки mail.buhal, который можно скачать [http://pdp-11.org.ru/~form/openbsd/files/sys/mail.buhal-1.0.tar.gz отсюда].<br /> <br /> Сначала нужно собрать и установить mail.buhal:<br /> <br /> # make depend &amp;&amp; make &amp;&amp; make install<br /> <br /> Далее следует указать mail.buhal в файле конфигурации sendmail в качестве локального агента доставки:<br /> <br /> &lt;pre&gt;<br /> define(`LOCAL_MAILER_PATH&#039;, `/usr/libexec/mail.buhal&#039;)dnl<br /> MODIFY_MAILER_FLAGS(`LOCAL&#039;, `-m&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> В портах OpenBSD, в категории mail, есть программы &#039;&#039;procmail&#039;&#039; и &#039;&#039;maildrop&#039;&#039;, которые также поддерживают формат Maildir и дополнительные расширения данного формата.<br /> <br /> == Использование procmail в качестве LDA ==<br /> <br /> После установки procmail из портов или пакетов, необходимо создать глобальный конфигурационный файл. Пример конфигурации:<br /> <br /> &lt;pre&gt;<br /> # Секция общих настроек.<br /> # <br /> DROPPRIVS=yes<br /> COMSAT=no<br /> VERBOSE=off<br /> SHELL=/bin/sh<br /> PATH=/bin:/usr/bin:/usr/local/bin<br /> LOCKFILE=$HOME/.lockmail<br /> LOGFILE=$HOME/procmail.log<br /> <br /> # Складываем почту в формате Maildir.<br /> # <br /> MAILDIR=$HOME/Maildir/<br /> DEFAULT=$MAILDIR<br /> <br /> # Входящую корреспонденцию можно резервировать в файлы формата mbox.<br /> # <br /> #: 0 c<br /> # /var/mail/$LOGNAME<br /> <br /> # Либо передавать в хранилище на другом хосте.<br /> # <br /> #: 0 c<br /> # ! mail@mx2.domain.ru<br /> &lt;/pre&gt;<br /> <br /> Далее необходимо изменить локальный агент доставки (LDA) с mail.local на procmail:<br /> <br /> &lt;pre&gt;<br /> FEATURE(local_procmail)dnl<br /> MAILER(local)dnl<br /> MAILER(smtp)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_sendmail&diff=183 2013-06-03T12:26:45Z

<p>Nordwind: /* Настройка TLS и SSL */</p> <hr /> <div>:Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> &lt;br /&gt;<br /> <br /> == Настройка TLS и SSL ==<br /> <br /> Начиная с версии 8.11, sendmail поддерживает защиту ESMTP соединения с помощью расширения STARTTLS (RFC 2487). Для настройки TLS прежде всего нужно создать SSL сертификат и секретный DSA-ключ для шифрования:<br /> <br /> &lt;pre&gt;<br /> # mkdir -m 700 /etc/mail/certs<br /> # openssl dsaparam 1024 -out dsa1024.pem<br /> # openssl req -x509 -nodes -days 365 -newkey dsa: dsa1024.pem \<br /> -out /etc/mail/certs/mycert.pem -keyout /etc/mail/certs/mykey.pem<br /> # rm -f dsa1024.pem<br /> &lt;/pre&gt;<br /> <br /> Если у вас уже есть ключ шифрования, то для создания сертификата следует подать команду:<br /> <br /> &lt;pre&gt;<br /> # openssl req -x509 -new -days 365 -key /etc/mail/certs/mykey.pem \<br /> -out /etc/mail/certs/mycert.pem<br /> &lt;/pre&gt;<br /> <br /> Параметр &#039;&#039;-days&#039;&#039; позволяет указать количество дней, в течение которых сертификат будет действительным. Чтобы проверить созданный сертификат, можно воспользоваться следующей командой:<br /> <br /> # openssl x509 -in /etc/mail/certs/mycert.pem -text<br /> <br /> Если вы не планируете использовать TLS для авторизации (не путать с [[#Настройка SMTP авторизации|SMTP авторизацией]]) или используете сертификат, подписанный самим собой, следует создать symlink:<br /> <br /> # ln -s /etc/mail/certs/mycert.pem /etc/mail/certs/CAcert.pem<br /> <br /> В противном случае следует поместить сертификат авторизации в файл &lt;span style=&quot;color:green;&quot;&gt;/etc/mail/certs/CAcert.pem&lt;/span&gt; Не забудьте установить права, запрещающие чтение/запись файлов сертификатов и ключей простым пользователям:<br /> <br /> # chmod 600 /etc/mail/certs/*<br /> <br /> Теперь следует настроить sendmail. В .mc файле конфигурации нужно добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> define(`CERT_DIR&#039;, `MAIL_SETTINGS_DIR`&#039;certs&#039;)dnl<br /> define(`confCACERT_PATH&#039;, `CERT_DIR&#039;)dnl<br /> define(`confCACERT&#039;, `CERT_DIR/CAcert.pem&#039;)dnl<br /> define(`confSERVER_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confSERVER_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> define(`confCLIENT_CERT&#039;, `CERT_DIR/mycert.pem&#039;)dnl<br /> define(`confCLIENT_KEY&#039;, `CERT_DIR/mykey.pem&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> После добавления вышеуказанных строк в файл конфигурации следует пересобрать его с помощью m4 (см. файл &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;) и рестартовать уже запущенный sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настроек TLS можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH PLAIN<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-STARTTLS». Смотрите также по данной теме <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=starttls&amp;sektion=8 starttls(8)], <br /> [http://www.openbsd.pw/files/www.openbsd.org/cgi-bin/man.cgi@query=ssl&amp;sektion=8 ssl(8)], <br /> [http://www.sendmail.org/~ca/email/starttls.html http://www.sendmail.org/~ca/email/starttls.html], &lt;span style=&quot;color:green;&quot;&gt;/usr/share/sendmail/README&lt;/span&gt;.<br /> <br /> Для того чтобы научить sendmail работать по SSL (без использования STARTTLS), нужно создать и добавить в .mc файл сертификат и ключ для шифрования, как описано выше, а также добавить следующие строки:<br /> <br /> &lt;pre&gt;<br /> DAEMON_OPTIONS(`Name=MTA&#039;)dnl<br /> DAEMON_OPTIONS(`Port=465, Name=MTA-SSL, M=s&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки можно воспользоваться командой openssl:<br /> <br /> &lt;pre&gt;<br /> # openssl s_client -connect localhost:465<br /> CONNECTED(00000004)<br /> <br /> […]<br /> <br /> ---<br /> SSL handshake has read 1409 bytes and written 288 bytes<br /> ---<br /> New, TLSv1/SSLv3, Cipher is DHE-DSS-AES256-SHA<br /> Server public key is 1024 bit<br /> SSL-Session:<br /> Protocol : TLSv1<br /> Cipher : DHE-DSS-AES256-SHA<br /> Session-ID:<br /> 28CAD859854BC30F61B0013DF835E69CDB0037D82FD741F9C7A56DD1E25B655<br /> Session-ID-ctx:<br /> Master-Key:<br /> F5BA53F5C0659E3E12D1057FE8D4AEA8177A868169B35949793ABECED7870A29FF4B3AFB9D479EA86618185D5192B837<br /> Key-Arg : None<br /> Start Time: 1119252698<br /> Timeout : 300 (sec)<br /> Verify return code: 18 (self signed certificate)<br /> ---<br /> 220 cvs.openbsd.ru ESMTP Sendmail 8.12.11/8.12.11; Mon, 20 Jun 2005 11:37:06 +0400 (MSD)<br /> &lt;/pre&gt;<br /> <br /> == Настройка SMTP авторизации ==<br /> <br /> Для настройки авторизации следует пересобрать sendmail с поддержкой SASL. Для этого следует установить пакет &#039;&#039;cyrus-sasl2&#039;&#039; или порт &#039;&#039;security/cyrus-sasl2&#039;&#039;. Для включения поддержки SASL нам потребуется перекомпилировать sendmail следующим образом:<br /> <br /> &lt;pre&gt;<br /> # echo WANT_SMTPAUTH=yes &gt;&gt; /etc/mk.conf<br /> # cd /usr/src/gnu/usr.sbin/sendmail<br /> # make cleandir<br /> # make obj<br /> # make depend<br /> # make<br /> # make install<br /> &lt;/pre&gt;<br /> <br /> Также можно воспользоваться набором site.tar.gz и пересобрать sendmail, установив настройку SENDMAIL_SASL=Yes в mk.conf.<br /> <br /> Далее следует создать файл конфигурации SASL для sendmail (&lt;tt&gt;/usr/local/lib/sasl2/Sendmail.conf&lt;/tt&gt;):<br /> <br /> pwcheck_method: saslauthd<br /> <br /> Добавляем в &lt;tt&gt;/etc/rc.local&lt;/tt&gt; строки для запуска saslauthd:<br /> <br /> &lt;pre&gt;<br /> if [ -x /usr/local/sbin/saslauthd ]; then<br /> echo -n &#039; saslauthd&#039;; /usr/local/sbin/saslauthd -a getpwent<br /> fi<br /> &lt;/pre&gt;<br /> <br /> Теперь остается только включить поддержку авторизации в .mc файле конфигурации sendmail:<br /> <br /> &lt;pre&gt;<br /> dnl<br /> dnl Эту опцию следует включить, чтобы запретить авторизацию с помощью<br /> dnl механизмов PLAIN и LOGIN по незащищенному соединению<br /> dnl (без использования TLS).<br /> dnl<br /> define(`confAUTH_OPTIONS&#039;, `p&#039;)dnl<br /> dnl<br /> dnl Список допустимых механизмов авторизации. Для всех механизмов,<br /> dnl кроме PLAIN и LOGIN, невозможна авторизация по системному файлу<br /> dnl паролей. Для них следует использовать sasldb или другие способы<br /> dnl авторизации (см. документацию sasl2).<br /> dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> dnl<br /> dnl Список механизмов, авторизация по которым разрешает использовать<br /> dnl сервер для пересылки почты (relaying).<br /> dnl<br /> TRUST_AUTH_MECH(`DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Не забудьте перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> Для проверки настройки авторизации можно воспользоваться командой telnet:<br /> <br /> &lt;pre&gt;<br /> # telnet localhost smtp<br /> Trying 127.0.0.1…<br /> Connected to localhost.<br /> Escape character is &#039;^]&#039;.<br /> 220 form.home.lan ESMTP Sendmail 8.13.1/8.13.1; Wed, 17 Nov 2004 13:42:08 +0600<br /> (NOVT)<br /> EHLO localhost<br /> 250-form.home.lan Hello root@localhost.home.lan [127.0.0.1], pleased to meet you<br /> 250-ENHANCEDSTATUSCODES<br /> 250-PIPELINING<br /> 250-8BITMIME<br /> 250-SIZE<br /> 250-DSN<br /> 250-ETRN<br /> 250-AUTH DIGEST-MD5 CRAM-MD5<br /> 250-STARTTLS<br /> 250-DELIVERBY<br /> 250 HELP<br /> &lt;/pre&gt;<br /> <br /> При правильной настройке в ответе сервера на команду «EHLO» должна присутствовать строка «250-AUTH». В случае если в файле конфигурации запрещено использование PLAIN авторизации по незащищенному соединению, вместо команды telnet следует использовать команду openssl:<br /> <br /> # openssl s_client -starttls smtp -connect localhost: smtp<br /> <br /> Смотрите также &lt;tt&gt;/usr/share/sendmail/README&lt;/tt&gt;, [[#Настройка TLS и SSL|Настройка TLS и SSL]].<br /> <br /> <br /> == Настройка sendmail как SMTP клиента с авторизацией ==<br /> <br /> В случае, когда sendmail выступает в роли клиента, демон saslauthd не требуется. В файл конфигурации необходимо внести следующие изменения:<br /> <br /> &lt;pre&gt;<br /> define(`SMART_HOST&#039;, `smtp: smtp.domain.ru&#039;)dnl<br /> define(`confAUTH_MECHANISMS&#039;, `DIGEST-MD5 CRAM-MD5 PLAIN LOGIN&#039;)dnl<br /> FEATURE(`authinfo&#039;, `hash /etc/mail/authinfo&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Указываем SMTP-сервер, имя и пароль пользователя, а также метод аутентификации в отдельном файле &lt;tt&gt;/etc/mail/authinfo&lt;/tt&gt;:<br /> <br /> AuthInfo: smtp.domain.ru «U:username@domain.ru» «P:mypassword» «M:CRAM-MD5»<br /> <br /> Создаем хэшированную базу данных /etc/mail/authinfo.db:<br /> <br /> # makemap hash /etc/mail/authinfo &lt; /etc/mail/authinfo<br /> <br /> <br /> == Как заставить sendmail использовать /etc/hosts ==<br /> <br /> По умолчанию sendmail использует в первую очередь DNS. Чтобы заставить его сначала смотреть &lt;tt&gt;/etc/hosts&lt;/tt&gt;, нужно создать файл &lt;tt&gt;/etc/mail/service.switch&lt;/tt&gt; и прописать в нем следующую строку:<br /> <br /> hosts files dns<br /> <br /> После этого достаточно перезапустить sendmail:<br /> <br /> # kill -HUP `head −1 /var/run/sendmail.pid`<br /> <br /> <br /> == Хранение писем в Maildir ==<br /> <br /> По умолчанию sendmail использует mail.local в качестве локального агента доставки почты. При этом почта доставляется в формате стандартного BSD mailbox. Чтобы доставлять почту в Maildir, нам потребуется установить альтернативный агент доставки mail.buhal, который можно скачать [http://pdp-11.org.ru/~form/openbsd/files/sys/mail.buhal-1.0.tar.gz отсюда].<br /> <br /> Сначала нужно собрать и установить mail.buhal:<br /> <br /> # make depend &amp;&amp; make &amp;&amp; make install<br /> <br /> Далее следует указать mail.buhal в файле конфигурации sendmail в качестве локального агента доставки:<br /> <br /> &lt;pre&gt;<br /> define(`LOCAL_MAILER_PATH&#039;, `/usr/libexec/mail.buhal&#039;)dnl<br /> MODIFY_MAILER_FLAGS(`LOCAL&#039;, `-m&#039;)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> В портах OpenBSD, в категории mail, есть программы &#039;&#039;procmail&#039;&#039; и &#039;&#039;maildrop&#039;&#039;, которые также поддерживают формат Maildir и дополнительные расширения данного формата.<br /> <br /> == Использование procmail в качестве LDA ==<br /> <br /> После установки procmail из портов или пакетов, необходимо создать глобальный конфигурационный файл. Пример конфигурации:<br /> <br /> &lt;pre&gt;<br /> # Секция общих настроек.<br /> # <br /> DROPPRIVS=yes<br /> COMSAT=no<br /> VERBOSE=off<br /> SHELL=/bin/sh<br /> PATH=/bin:/usr/bin:/usr/local/bin<br /> LOCKFILE=$HOME/.lockmail<br /> LOGFILE=$HOME/procmail.log<br /> <br /> # Складываем почту в формате Maildir.<br /> # <br /> MAILDIR=$HOME/Maildir/<br /> DEFAULT=$MAILDIR<br /> <br /> # Входящую корреспонденцию можно резервировать в файлы формата mbox.<br /> # <br /> #: 0 c<br /> # /var/mail/$LOGNAME<br /> <br /> # Либо передавать в хранилище на другом хосте.<br /> # <br /> #: 0 c<br /> # ! mail@mx2.domain.ru<br /> &lt;/pre&gt;<br /> <br /> Далее необходимо изменить локальный агент доставки (LDA) с mail.local на procmail:<br /> <br /> &lt;pre&gt;<br /> FEATURE(local_procmail)dnl<br /> MAILER(local)dnl<br /> MAILER(smtp)dnl<br /> &lt;/pre&gt;<br /> <br /> Теперь достаточно перекомпилировать файл конфигурации и перезапустить sendmail.<br /> <br /> [[Категория:Howto]]</div>

Nordwind http://www.qbsd.ru/index.php?title=OpenBSD-Wiki:%D0%A2%D0%B5%D0%BA%D1%83%D1%89%D0%B8%D0%B5_%D1%81%D0%BE%D0%B1%D1%8B%D1%82%D0%B8%D1%8F&diff=182 2013-06-02T10:12:50Z

<p>Nordwind: /* Актуальное */</p> <hr /> <div>== Актуальное ==<br /> Собрано всё, что применимо к текущему релизу.<br /> <br /> * [[Введение в OpenBSD]]<br /> * [[Аппаратное обеспечение и вопросы]]<br /> * [[IPsec между OpenBSD и Linux Ubuntu]]<br /> * [[OpenSSH мини-руководство]]<br /> * [[OpenSSH: настройки, секреты, трюки и советы]]<br /> * [[RSA/DSA аутентификация в OpenSSH]]<br /> * [[Использование файла mk.conf]]<br /> * [[Написание OpenBSD Loadable Kernel Modules (LKM)]]<br /> * [[Настройка sendmail]]<br /> * [[Новое IPSec howto]]<br /> * [[Русификация OpenBSD 5.x]]<br /> * [[Русификация OpenBSD]]<br /> * [[Русификация консоли OpenBSD]]<br /> * [[Создание загрузочной флешки]]<br /> * [[Перечень Интернет ресурсов о OpenBSD]]<br /> * [[Описание переменных sysctl]]<br /> * [[Сборник советов с OpenBSD101.com]]<br /> <br /> === Переводы ===<br /> * [[C2k10-marco]]<br /> * [[C2k10-guenther]]<br /> * [[C2k10-ajacoutot]]<br /> * [[C2k10-henning]]<br /> * [[C2k10-tedu]]<br /> <br /> == Устаревшее ==<br /> Данная информация сохранена для архивных версий.<br /> <br /> * [[Использование Bluetooth в OpenBSD]]<br /> * [[Настройка GPRS]]<br /> <br /> == Прочее ==<br /> <br /> * [[Резервная копия Wiki]]</div>

Nordwind http://www.qbsd.ru/index.php?title=RSA/DSA_%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D1%8F_%D0%B2_OpenSSH&diff=181 2013-06-02T10:10:04Z

<p>Nordwind: /* Что это такое? */</p> <hr /> <div>: Данная статья 100 % копипаст с [http://www.openbsd.ru www.openbsd.ru]<br /> <br /> == Что это такое? ==<br /> <br /> OpenSSH — замена стандартных уязвимых протоколов, таких как &lt;tt&gt;telnet&lt;/tt&gt; или &lt;tt&gt;rsh&lt;/tt&gt;. OpenSSH использует шифрованный канал для передачи данных. В нем могут быть задействованы алгоритмы аутентификации RSA или DSA.<br /> <br /> Эти протоколы основаны на базе специально созданной паре ключей, а именно публичном и приватном ключах. Это асимметричные алгоритмы шифрования, то есть мы можем зашифровать информацию одним ключом, а расшифровать другим, в отличие, например от DES, где используется один и тот же ключ для шифрования и расшифровки информации.<br /> <br /> Первым делом следует сгенеровать пару ключей. Опцией -t мы задаём тип ключа. Доступны следующие типы ключей: &#039;&#039;&#039;rsa&#039;&#039;&#039;, &#039;&#039;&#039;dsa&#039;&#039;&#039; для протокола SSH 2 и &#039;&#039;&#039;rsa1&#039;&#039;&#039; для SSH 1.<br /> <br /> &lt;pre&gt;<br /> $ ssh-keygen -t dsa<br /> Generating public/private dsa key pair.<br /> Enter file in which to save the key (/home/dfa/.ssh/id_dsa):<br /> Enter passphrase (empty for no passphrase):<br /> Enter same passphrase again:<br /> Your identification has been saved in /home/dfa/.ssh/id_dsa.<br /> Your public key has been saved in /home/dfa/.ssh/id_dsa.pub.<br /> The key fingerprint is:<br /> 27:33:40:91:0f:81:df:0a:87:f5:58:60:bb:28:c8:ad dfa@zinc<br /> &lt;/pre&gt;<br /> <br /> Далее, если необходимо, указываем место, куда сохранить ключ, по умолчанию предлагается &lt;span style=&quot;color:green;&quot;&gt;/home/$USER/.ssh/id_dsa&lt;/span&gt;. Если ввести пароль, наш приватный ключ будет зашифрован, и для того чтобы позднее воспользоваться этим ключом, нам необходимо будет вводить данный пароль. Публичный ключ имеет суффикс &#039;&#039;&#039;.pub&#039;&#039;&#039;.<br /> <br /> При использовании беспарольной аутентификации любой, кто имеет доступ к приватному ключу, может беспрепятственно проникнуть на удалённую машину, для которой этот ключ используется.<br /> <br /> Публичный ключ не представляет угрозу для безопасности, мы можем пересылать его по &lt;tt&gt;email&lt;/tt&gt; или по &lt;tt&gt;ftp&lt;/tt&gt;.<br /> <br /> Далее рассмотрим способ аутентификации, при котором приватный ключ будет зашифрован паролем, и нам не нужно будет каждый раз вводить его при соединении, за нас это будет делать [[#Парольная аутентификация с использованием ssh-agent|&lt;tt&gt;ssh-agent&lt;/tt&gt;]], занимающийся кэшированием дешифрованных личных ключей.<br /> <br /> == Беспарольная аутентификация ==<br /> <br /> После успешной генерации ключей необходимо скопировать публичный ключ на удалённую машину в файл &lt;span style=&quot;color:green;&quot;&gt;~/.ssh/authorized_keys&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> $ scp ~/.ssh/id_dsa.pub cvs.openbsd.ru:~/.ssh/authorized_keys<br /> dfa@cvs.openbsd.ru password:<br /> id_dsa.pub 100 % |***************************| 598 00:00<br /> &lt;/pre&gt;<br /> <br /> Пример файла конфигурации клиента &lt;span style=&quot;color:green;&quot;&gt;~/.ssh/config&lt;/span&gt;:<br /> <br /> &lt;pre&gt;<br /> Host cvs.openbsd.ru<br /> IdentityFile ~/.ssh/id_dsa<br /> RSAAuthentication yes<br /> <br /> Host anoncvs.ca.openbsd.org<br /> Compression no<br /> <br /> Host *<br /> Cipher blowfish<br /> Compression yes<br /> EscapeChar ~<br /> Port 22<br /> Protocol 2,1<br /> User dfa<br /> &lt;/pre&gt;<br /> <br /> Пробуем присоединиться к удалённой машине &lt;tt&gt;cvs.openbsd.ru&lt;/tt&gt;<br /> <br /> &lt;pre&gt;<br /> $ ssh cvs.openbsd.ru<br /> OpenBSD 3.0-current (RUOBSD) #19: Sat Dec 1 11:57:43 NOVT 2001<br /> <br /> Welcome to OpenBSD: The proactively secure Unix-like operating system.<br /> <br /> $<br /> &lt;/pre&gt;<br /> <br /> == Парольная аутентификация с использованием &lt;tt&gt;ssh-agent&lt;/tt&gt; ==<br /> <br /> &lt;tt&gt;ssh-agent&lt;/tt&gt; — специальная программа-демон, которая разработана для протоколов аутентификации RSA/DSA и применяется для хранения парольной фразы приватного ключа. Используя эту программу, вы можете соединяться с удалённой машиной, не набирая пароль, и при этом ваши приватные ключи остаются защищёнными. Клиент &lt;tt&gt;ssh&lt;/tt&gt; поддерживает &lt;tt&gt;ssh-agent&lt;/tt&gt; и может взаимодействовать с ней.<br /> <br /> Ключи и их пароли добавляются к &lt;tt&gt;ssh-agent&lt;/tt&gt; только один раз, используя &lt;tt&gt;ssh-add&lt;/tt&gt;, и далее &lt;tt&gt;ssh&lt;/tt&gt; будет обращаться к &lt;tt&gt;ssh-agent&lt;/tt&gt; для определения парольной фразы для данного приватного ключа.<br /> <br /> При запуске &lt;tt&gt;ssh-agent&lt;/tt&gt;, в зависимости от вашего $SHELL, выводит команды для установки переменных окружения:<br /> <br /> &lt;pre&gt;<br /> $ ssh-agent<br /> SSH_AUTH_SOCK=/tmp/ssh-jyw17290/agent.17290; export SSH_AUTH_SOCK;<br /> SSH_AGENT_PID=8809; export SSH_AGENT_PID;<br /> echo Agent pid 8809;<br /> $<br /> &lt;/pre&gt;<br /> <br /> &lt;tt&gt;ssh-agent&lt;/tt&gt; открывает сокет для взаимодействия с &lt;tt&gt;ssh&lt;/tt&gt; и сообщает об этом через переменную окружения $SSH_AUTH_SOCK, а также сообщает свой уникальный идентификатор процесса, который установлен в переменной окружения $SSH_AGENT_PID и выводится командой &lt;tt&gt;echo&lt;/tt&gt;.<br /> <br /> Правильный запуск &lt;tt&gt;ssh-agent&lt;/tt&gt;, используя встроенную в оболочку команду eval, выполняется следующим образом:<br /> <br /> &lt;pre&gt;<br /> $ eval `ssh-agent`<br /> Agent pid 17522<br /> $<br /> &lt;/pre&gt;<br /> <br /> Или можно задать программу, использующую ssh, как аргумент ssh-agent. В данном случае — это командный интерпретатор ksh:<br /> <br /> &lt;pre&gt;<br /> $ ssh-agent /bin/ksh<br /> $ env | grep SSH<br /> SSH_AUTH_SOCK=/tmp/ssh-SAe17087/agent.17087<br /> SSH_AGENT_PID=20652<br /> $<br /> &lt;/pre&gt;<br /> <br /> Теперь, используя ssh-add, необходимо добавить ключ и парольную фразу к нему:<br /> <br /> &lt;pre&gt;<br /> $ ssh-add ~/.ssh/id_dsa<br /> Enter passphrase for /home/dfa/.ssh/id_dsa:<br /> Identity added: /home/dfa/.ssh/id_dsa (/home/user/.ssh/id_dsa)<br /> $<br /> &lt;/pre&gt;<br /> <br /> Пробуем присоединиться к удалённой машине &lt;tt&gt;cvs.openbsd.ru&lt;/tt&gt;<br /> <br /> &lt;pre&gt;<br /> $ ssh cvs.openbsd.ru<br /> OpenBSD 3.0-current (RUOBSD) #19: Sat Dec 1 11:57:43 NOVT 2001<br /> <br /> Welcome to OpenBSD: The proactively secure Unix-like operating system.<br /> <br /> $<br /> &lt;/pre&gt;<br /> <br /> [[Категория:Howto]]</div>

Nordwind