Денис Фатеев unix:2009

Createtorrent − создание .torrent-файлов

Fri, 27 Aug 2010 08:42:00 +0000

Утилита для создания .torrent-файлов из командной строки. Поддерживает включение в раздачу как одиночного файла, так и набора файлов (находящихся в одной директории). Нет ограничения на размер отдельного файла в наборе.

Мной она используется в связке с ruTorrent (плагин create) в качестве внешней программы создания .torrent-файлов. Готового пакета под RedHat для нее я не нашел, поэтому собрал свой. Вдруг кому-нибудь еще пригодится.

Как всегда, скачать пакеты можно здесь.

network, linux, centos

Read or add comments to this article

Организация VPN-сети (часть первая)

Mon, 22 Nov 2010 08:05:00 +0000

Этой статьей я открываю цикл кратких заметок по созданию распределенных VPN-сетей республиканского масштаба для нужд среднего предприятия. Не ищите здесь руководство по VPN-технологиям – его здесь нет, для этого есть специализированные пособия, доступные в электронной и печатной форме. Я лишь попытаюсь дать представление на практическом примере, что это за «зверь» такой – VPN, и указать на особенности построения подобной инфраструктуры в наших условиях, попутно обобщив свой опыт на этом поприще. Все, сказанное мной, не претендует на истину в последней инстанции, и отражает лишь мою собственную точку зрения.

Зачем это нужно?

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

И как это сделать?

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

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

На этом этапе требуется сесть и тщательно продумать, какие филиалы вашей организации войдут в сеть. Если их больше двух-трех, можно для наглядности даже нарисовать схему с табличкой, в которой указать адреса и контакты каждого филиала. Если требуется организовать распределенную сеть в пределах одного города, обычно есть выбор из нескольких вариантов подключений у различных провайдеров. В моем случае, требовалось объединить несколько сетей, расположенных в различных городах области; здесь, как говорится, без вариантов – приходится обращаться к компании-монополисту Казахтелеком, единственному глобальному поставщику данного вида связи на всей территории РК. Далее в статье я буду рассматривать подключение именно через «Казахтелеком», как наиболее универсальный способ, адаптировать рекомендации под конкретного провайдера не составит особого труда.

Организация VPN-сети (часть вторая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть вторая)

Mon, 22 Nov 2010 08:11:00 +0000

Итак, определились с провайдером и четко представляем, из каких структурных элементов, то бишь, филиалов, будет состоять наша сеть. С провайдером согласованы технологии, на основе которых будут предоставляться услуги. В случае «Казахтелекома», это обычно xDSL – ADSL, SHDSL. Вообще, предполагается, что вы обладаете базовыми знаниями в маршрутизации IP-сетей и представлениями о технологиях, которые будут использоваться провайдером; а если нет – то сейчас самое время почитать об этом.

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

L2 – в этом случае ваша VPN-сеть будет представлять собой подобие большого географически разнесенного свитча;
L3 – привычная для нас инфраструктура сетевого уровня на базе протокола IPv4, в которой действует роутинг и прочие «вкусные» вещи. Советую ознакомиться с "Рекомендациями по составлению адресного плана", это документ, который дается всем клиентам услуги IP VPN L3 «Казахтелекома». Заявка составляется по такому шаблону.

В подавляющем большинстве случаев, вариант с L3 является предпочтительным. Используйте L2 в том случае, если точно знаете, зачем вам это нужно¹⁾. Далее аспекты построения VPN-сетей на базе топологии L2 рассматриваться не будут.

К адресному плану для VPN-сети особых условий не предъявляется ²⁾, формально можно использовать любое адресное пространство, но на практике лучше выбрать рекомендованный диапазон, например 10.0.0.0/24 или 172.16.0.0/24. Для каждой точки подключения (филиала) назначается блок из 4-х IP-адресов (подсети вида 10.0.0.0/30, 10.0.0.4/30, 10.0.0.8/30 и т.п.) из выбранного вами общего диапазона. Также, если не планируете использовать NAT или собственную VPN- инфраструктуру поверх «казахтелекомовского» канала, в заявке необходимо указать IP-адресацию, используемую в ваших сетях филиалов. В ином случае, в поле «Подсети клиента» указываете полный диапазон IP-адресов вашей сети (вида 10.0.0.0/24).

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

В каждый филиал вашей компании, входящий в VPN-сеть, необходимо будет поставить маршрутизатор. Выбор платформы для маршрутизатора остается за вами; это может быть аппаратный роутер (Cisco, Juniper, ZyXEL, D-Link и т.д.) или программный – обычный PC с архитектурой х86 или ARM, с установленными ОС Linux или BSD³⁾. Он будет обеспечивать взаимодействие сети филиала с VPN-сетью, и посредством неё, с сетями других филиалов. В случае использования топологии L3, непосредственно на него назначаются IP-адреса, указанные в заявке⁴⁾. Получится примерно такая схема:

№ п/п	Адрес подключения	Телеф.	Пр.сп., Кбит/с	Техн.	P2P IP-адрес	Подсети клиента	Точка агрегации
1	г. Костанай, ул.Тарана, 114	540000	512	SHDSL	10.0.0.0/30	10.0.0.0/24	10.0.0.0/30
2	г. Костанай, ул. Сьянова, 69	510000	256	ADSL	10.0.0.4/30	10.0.0.0/24	10.0.0.0/30
3	г. Рудный, ул. Ленина, 47	43000	128	ADSL	10.0.0.8/30	10.0.0.0/24	10.0.0.0/30
4	г. Лисаковск, 6 мкрн, 23	37000	128	ADSL	10.0.0.12/30	10.0.0.0/24	10.0.0.0/30

Если сеть областного масштаба, с заполненной заявкой идете в ОДТ "Казахтелеком" (Областную дирекцию телекоммуникаций АО «Казахтелеком»), здесь можете заранее ознакомиться с расценками на услуги областного IP VPN. В Костанае Центр продаж ОДТ находится по адресу: пр. Аль-Фараби, 71 (здание переговорного пункта, соседнее крыльцо).

В том случае, если ваша сеть выходит за пределы области или страны - вам придется работать с ДКП "Казахтелеком" (Дирекция корпоративных продаж АО «Казахтелеком»). Центр расширенного сервиса ДКП в Костанае находится по адресу: ул. Тарана, 56 (здание дирекции «Казахтелеком»).

Там, на месте, получаете типовой договор на предоставление услуг IP VPN; если условия и расценки устраивают – заключаете договор с менеджером ОДТ или ДКП, в зависимости от ваших условий.

Организация VPN-сети (часть первая)

Организация VPN-сети (часть третья)

linux, vpn, network

¹⁾ тем более, на территории Костанайской области существует ограничение по количеству хостов: не более 64 уникальных хостов в L2 VPN-сети; это связано с особенностями используемого оборудования Alcatel на DSLAM

²⁾ есть информация, что MPLS ДКП Казахтелекома работает с использованием VRRP

³⁾ у меня стоят PC с ОС Linux, в основном, на базе CentOS

⁴⁾ для топологии L2 IP-адресация точек подключения смысла не имеет

Read or add comments to this article

Организация VPN-сети (часть третья)

Mon, 22 Nov 2010 08:40:00 +0000

Готовим машину

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

Я буду рассматривать настройку маршрутизаторов на базе ОС Linux CentOS, не составит особого труда адаптировать эти рекомендации для любой ОС семейства Linux/BSD. Ну а если вы обладатель «железного» роутера – обратитесь к документации на ваше устройство, нижеприведенные рекомендации к вам не относятся.

Требования к аппаратной части маршрутизаторов достаточно скромны: системного блока с процессором Intel Celeron/Pentium II 450-500МГц и 160-192Мб ОЗУ будет вполне достаточно для поддержки 10-20 подключений. В крайнем случае, если у вас 5-10 подключений, можно обойтись Intel Celeron 333 со 128Мб оперативной памяти на борту.

На каждый маршрутизатор нужно будет поставить две сетевые карты – для соединения с WAN (с VPN-сетью) и LAN (локальная сеть филиала). Поскольку зачастую заказывают VPN-канал не шире 1-2Мбит/с, то производительность сетевых карт не играет здесь особой роли. Подойдут и распространённые у нас RealTek и VIA всех видов, а также встроенные в материнскую плату карточки. Лучшим выбором, из доступного у нас, будет что-то вроде Intel PRO/1000 PT/GT, худшим – продукция TP-Link. Всё остальное лежит в широком диапазоне между этими двумя крайностями. Кстати, если будете использовать встроенные сетевые карточки RealTek, загляните сюда.

Скорее всего, на собранной вами машине не будет поддержки аппаратного RAID. Максимум, что можно встретить на бюджетной машине среднего класса, это «Fake-RAID», реализуемый средствами BIOS и ненадёжный даже в сравнении с программными RAID-решениями. Поэтому, чтобы хоть как-то обезопаситься от сбоев, купите пару одинаковых жёстких дисков IDE или SATA, в зависимости от вашей материнской платы, и в процессе установки системы настройте «зеркалом» (RAID1) разделы на дисках с помощью «Linux Software RAID». Официальная документация с картинками находится здесь.

Все остальные компоненты некритичны и могут быть любыми. Монитор и клавиатура нужны только на этапе установке ОС. После того, как маршрутизатор будет настроен, они более не понадобятся – им можно будет управлять удаленно.

xDSL-оборудование

Согласно условиям контракта, «Казахтелеком» предоставляет своим клиентам ADSL/SHDSL-модемы, обычно, марки Billion, в аренду на всё время пользования услугой IP VPN. Так что, дополнительно ничего покупать не требуется.

Организация VPN-сети (часть вторая)

Организация VPN-сети (часть четвертая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть четвертая)

Mon, 22 Nov 2010 08:38:00 +0000

К этому времени, «Казахтелеком» или иной провайдер, предоставляющий вам услугу IP VPN, должен завершить выполнение вашей заявки на подключение. Если у вас подключение по xDSL, вам необходимо уточнить у техподдержки параметры инкапсуляции и значения VPI/VCI. В разных областях Казахстана они могут варьироваться по усмотрению местного оператора связи. В Костанае по области используется 0/34, а в Павлодаре – 0/35.

Процедура настройки модемов в филиалах абсолютно аналогична; максимум, могут отличаться лишь вышеуказанные параметры. Включите ваш модем и зайдите на него через веб-интерфейс (как это сделать, написано в документации к модему). Переключите модем в режим моста («bridge mode»), смените пароль администратора и убедитесь, что прочие настройки соответствуют полученным от провайдера. Все прочие настройки (PPTP и IPSec VPN, NAT, сервера NTP и прочее) для нас несущественны, оставьте их как есть.

На телефонную линию ставите сплиттер (идёт в поставке с модемом), подключаете модем к соответствующему порту сплиттера. После перезагрузки на модеме должна загореться лампочка «DSL». Это означает, что сделанные настройки верны и линия исправна; модем подключился к DSLAM провайдера.

Организация VPN-сети (часть третья)

Организация VPN-сети (часть пятая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть пятая)

Fri, 27 Aug 2010 08:42:00 +0000

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

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

Отключаем службы

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

Чтобы не повторяться, краткое описание имеющихся служб в RHEL/Fedora можно найти здесь. Руководство по управлению службами и уровнем запуска («runlevel») доступно здесь. Конфигурирование служб проще всего произвести через псевдографический интерфейс (утилита «setup»).

Настраиваем сетевые параметры

На нашем маршрутизаторе стоят две сетевые карты (см. ранее). Назначаем IP-адреса сетевым интерфейсам. Например, интерфейс «eth0» может быть использован для соединения с сетью провайдера, а «eth1» будет «смотреть» в локальную сеть филиала.

Снова смотрим на общую схему филиалов (приведена ранее во второй части данных заметок):

Взглянем на отдельный сегмент VPN-сети, на примере головного филиала (WAN-сеть 10.0.0.0/30, локальная сеть 192.168.0.0/24):

Конфигурация сетевых интерфейсов маршрутизатора будет такой:

Файл /etc/sysconfig/network:

NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=gateway1.yourcompany.com
GATEWAY=10.0.0.1

Файл /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
BOOTPROTO=static
BROADCAST=10.0.0.3
HWADDR=00:XX:XX:XX:XX:XX
IPADDR=10.0.0.2
NETMASK=255.255.255.252
NETWORK=10.0.0.0
GATEWAY=10.0.0.1
ONBOOT=yes

Файл /etc/sysconfig/network-scripts/ifcfg-eth1:

DEVICE=eth1
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=00:XX:XX:XX:XX:XX
IPADDR=192.168.0.1
NETMASK=255.255.255.0
NETWORK=192.168.0.0
GATEWAY=192.168.0.1
ONBOOT=yes

Настраиваем файервол

Задаем максимально ограничивающие правила файервола.

Файл /etc/sysconfig/iptables:

# -- NAT table --
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
 
# -- FILTER table --
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j REJECT --reject-with tcp-reset
-A INPUT -p tcp ! --syn -m state --state NEW -j DROP
-A INPUT -i eth1 -m state --state NEW -p udp -d 192.168.0.255 -j DROP
-A INPUT -m state --state NEW -p udp -d 255.255.255.255 -j DROP
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
#
-A INPUT -j LOG --log-prefix "IPTABLES-IN Default Drop: " --log-level 7
#
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
#
-A FORWARD -j LOG --log-prefix "IPTABLES-FWD Default Drop: " --log-level 7
COMMIT

Активируем новые правила:

[root@gateway1 ~]# /etc/init.d/iptables restart

Проверяем результат

Перезапускаем службу сети …

[root@gateway1 ~]# /etc/init.d/network restart

… и включаем поддержку роутинга на маршрутизаторе:

[root@gateway1 ~]# echo "1" > /proc/sys/net/ipv4/ip_forward

(неплохо было бы добавить эту строчку в файл /etc/rc.local, чтобы поддержка маршрутизации активировалась сразу при загрузке ОС).

Подключаем WAN-порт маршрутизатора к Ethernet-порту модема и с консоли проверяем доступность ближайшего шлюза провайдера:

[root@gateway1 ~]# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=6.74 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=4.85 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=5.02 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=3.72 ms

--- 10.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 3.727/5.087/6.746/1.081 ms
[root@gateway1 ~]#

Если «ping» к шлюзу успешен, ваш маршрутизатор подключен к сети IP VPN.

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

Организация VPN-сети (часть четвертая)

Организация VPN-сети (часть шестая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть шестая)

Fri, 27 Aug 2010 08:42:00 +0000

Теперь нам нужно обеспечить шифрование передаваемых данных и организовать контроль доступа к нашим ресурсам. Для этого разворачиваем собственную VPN-инфраструктуру поверх каналов Казахтелекома. Существует несколько реализаций технологии VPN, в нашем случае подойдет пакет OpenVPN, в котором реализован весь нужный нам функционал.

Структура подобной сети достаточно простая – один из узлов сети объявляется VPN-сервером; другие узлы, выступающие VPN-клиентами, могут подключаться к сети после аутентификации на VPN-сервере, при этом данные между клиентами и сервером передаются в зашифрованном виде. Результатом наших действий будет виртуальная сеть, построенная по такой схеме:

Устанавливаем VPN-сервер

В качестве VPN-сервера настраиваем один из маршрутизаторов нашей сети (используйте маршрутизатор головного филиала или того филиала, который географически находится ближе к вам). Сначала проверьте, присутствует ли пакет openvpn в репозиториях вашего дистрибутива:

[root@gateway1 ~]# yum search openvpn lzo
Loading "fastestmirror" plugin
Loading mirror speeds from cached hostfile
 * base: mirror.corbina.net
 * updates: mirror.corbina.net
 * addons: mirror.corbina.net
 * extras: centosr3.centos.org
openvpn.i386 : OpenVPN is a robust and highly flexible VPN daemon by James Yonan.
lzo-devel.i386 : Header files, libraries and development documentation for lzo
lzo.i386 : Portable lossless data compression library
[root@gateway1 ~]#

Если пакеты найдены, устанавливаем:

[root@gateway1 ~]# yum install openvpn lzo

в ином случае, готовые пакеты для RHEL5/CentOS можно скачать отсюда.

После установки конфигурируем службу в режиме сервера. Копируем пример конфигурационного файла /usr/share/doc/openvpn-2.0.9/sample-config-files/server.conf в каталог /etc/openvpn и редактируем в соответствии с нашими условиями.

Файл /etc/openvpn/server.conf:

############################################################
# OpenVPN 2.0 config file for multi-client server.         #
############################################################
 
# Which local IP address should OpenVPN
# listen on? (optional)
;local a.b.c.d
 
# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194
 
# TCP or UDP server?
;proto tcp
proto udp
 
# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun0
 
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one.  On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
;dev-node MyTap
 
# SSL/TLS root certificate (ca), certificate
# (cert), and private key (key).  Each client
# and the server must have their own cert and
# key file.  The server and all clients will
# use the same ca file.
#
# See the "easy-rsa" directory for a series
# of scripts for generating RSA certificates
# and private keys.  Remember to use
# a unique Common Name for the server
# and each of the client certificates.
#
# Any X509 key management system can be used.
# OpenVPN can also use a PKCS #12 formatted key file
# (see "pkcs12" directive in man page).
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
 
 
# Diffie hellman parameters.
# Generate your own with:
#   openssl dhparam -out dh1024.pem 1024
 
# Substitute 2048 for 1024 if you are using
# 2048 bit keys.
dh dh1024.pem
 
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
server 10.10.0.0 255.255.255.0
# -- server --: 
# 10.10.0.0/30 (main-filial)
#  host 10.10.0.1, gw 10.10.0.2, bcast 10.10.0.2
# -- clients --:
# 10.10.0.4/30 (filial2) 
#  host 10.10.0.5, gw 10.10.0.6, bcast 10.10.0.7
# 10.10.0.8/30 (filial3)
#  host 10.10.0.9, gw 10.10.0.10, bcast 10.10.0.11
# 10.10.0.12/30 (filial4)
#  host 10.10.0.13, gw 10.10.0.14, bcast 10.10.0.15
# .. etc..
 
# Maintain a record of client <-> virtual IP address
# associations in this file.  If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt
 
# Configure server mode for ethernet bridging.
# You must first use your OS's bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface.  Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0.  Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients.  Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
 
# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
 
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).
 
# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
client-config-dir ccd
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
#   iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN.  This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.
 
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
;client-config-dir ccd
;route 10.9.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
#   ifconfig-push 10.9.0.1 10.9.0.2
 
# Suppose that you want to enable different
# firewall access policies for different groups
# of clients.  There are two methods:
# (1) Run multiple OpenVPN daemons, one for each
#     group, and firewall the TUN/TAP interface
#     for each group/daemon appropriately.
# (2) (Advanced) Create a script to dynamically
#     modify the firewall in response to access
#     from different clients.  See man
#     page for more info on learn-address script.
;learn-address ./script
 
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# the TUN/TAP interface to the internet in
# order for this to work properly).
# CAVEAT: May break client's network config if
# client's local DHCP server packets get routed
# through the tunnel.  Solution: make sure
# client's local DHCP server is reachable via
# a more specific route than the default route
# of 0.0.0.0/0.0.0.0.
;push "redirect-gateway local def1"
push "redirect-gateway def1"
 
 
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses.  CAVEAT:
# http://openvpn.net/faq.html#dhcpcaveats
;push "dhcp-option DNS 10.8.0.1"
;push "dhcp-option WINS 10.8.0.1"
 
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
;client-to-client
 
# Uncomment this directive if multiple clients
# might connect with the same certificate/key
# files or common names.  This is recommended
# only for testing purposes.  For production use,
# each client should have its own certificate/key
# pair.
#
# IF YOU HAVE NOT GENERATED INDIVIDUAL
# CERTIFICATE/KEY PAIRS FOR EACH CLIENT,
# EACH HAVING ITS OWN UNIQUE "COMMON NAME",
# UNCOMMENT THIS LINE OUT.
;duplicate-cn
 
# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120
 
# For extra security beyond that provided
# by SSL/TLS, create an "HMAC firewall"
# to help block DoS attacks and UDP port flooding.
#
# Generate with:
#   openvpn --genkey --secret ta.key
#
# The server and each client must have
# a copy of this key.
# The second parameter should be '0'
# on the server and '1' on the clients.
;tls-auth ta.key 0 # This file is secret
 
# Select a cryptographic cipher.
# This config item must be copied to
# the client config file as well.
;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
 
# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
comp-lzo
 
# The maximum number of concurrently connected
# clients we want to allow.
;max-clients 100
 
# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on
# non-Windows systems.
user nobody
group nobody
 
# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
persist-key
persist-tun
 
# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status /var/log/openvpn-status.log
 
# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it.  Use one
# or the other (but not both).
;log         openvpn.log
log-append  /var/log/openvpn.log
 
# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3
 
# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

Создаем PKI-инфраструктуру на сервере. Копируем каталог /usr/share/doc/openvpn-2.0.9/easy-rsa в /etc/openvpn, редактируем файл настроек vars.

Файл /etc/openvpn/easy-rsa/vars:

 -------- < начало пропущено > --------
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY=KZ
export KEY_PROVINCE=Kostanay
export KEY_CITY=Kostanay
export KEY_ORG="YourCompany LLC"
export KEY_EMAIL="denis@fateyev.com"

Активизируем изменения (обратите внимание на пробел в '. ./vars'):

[root@gateway1 easy-rsa]# . ./vars
[root@gateway1 easy-rsa]# ./clean-all

Создаем корневой сертификат:

[root@gateway1 easy-rsa]# ./build-ca

Generating a 1024 bit RSA private key
………………………++++++
…………………….++++++
writing new private key to ‘ca.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [KZ]:
State or Province Name (full name) [Kostanay]:
Locality Name (eg, city) [Kostanay]:
Organization Name (eg, company) [YourCompany LLC]:
Organizational Unit Name (eg, section) []:Tech Staff
Common Name (eg, your name or your server’s hostname) []:vpn.yourcompany.com
Email Address [denis@fateyev.com]:

Создаем сертификат сервера:

[root@gateway1 easy-rsa]# ./build-key-server server

Generating a 1024 bit RSA private key
………………………………….++++++
…………………….++++++
writing new private key to ‘server.key’
—–
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [KZ]:
State or Province Name (full name) [Kostanay]:
Locality Name (eg, city) [Kostanay]:
Organization Name (eg, company) [YourCompany LLC]:
Organizational Unit Name (eg, section) []:Tech Staff
Common Name (eg, your name or your server’s hostname) []:vpn.yourcompany.com
Email Address [denis@fateyev.com]:

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:<enter your password here>
An optional company name []:
Using configuration from /etc/openvpn/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject’s Distinguished Name is as follows
countryName :PRINTABLE:’KZ’
stateOrProvinceName :PRINTABLE:’Kostanay’
localityName :PRINTABLE:’Kostanay’
organizationName :PRINTABLE:’YourCompany LLC’
organizationalUnitName:PRINTABLE:’Tech Staff’
commonName :PRINTABLE:’vpn.yourcompany.com’
emailAddress :IA5STRING:’denis@fateyev.com’
Certificate is to be certified until Jun 02 11:52:31 2019 GMT (3650 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

С помощью алгоритма Diffie-Hellman генерируем секретный ключ:

[root@gateway1 easy-rsa]# ./build-dh
Generating DH parameters, 1024 bit long safe prime, generator 2
This is going to take a long time

Копируем файлы ca.crt, dh1024.pem, server.key, server.crt из папки keys/ в /etc/openvpn:

[root@gateway1 easy-rsa]# cp keys/ca.crt keys/dh1024.pem \
  keys/server.key keys/server.crt /etc/openvpn/

Разрешаем подключения к OpenVPN-серверу (добавляем запись в конфигурационный файл /etc/sysconfig/iptables в секцию *filter):

-A INPUT -m state --state NEW -p udp --dport 1194 -j ACCEPT

Перезапускаем iptables:

[root@gateway1 ~]# /etc/init.d/iptables restart

Создаем log-файлы для OpenVPN и назначаем права доступа:

[root@gateway1 ~]# touch /var/log/openvpn.log && \
  chown nobody:nobody /var/log/openvpn.log
[root@gateway1 ~]# touch /var/log/openvpn-status.log && \
  chown nobody:nobody /var/log/openvpn-status.log

Служба openvpn должна запускаться при загрузке системы. Устанавливаем уровень запуска и перезапускаем службы:

[root@gateway1 ~]# chkconfig openvpn on
[root@gateway1 ~]# /etc/init.d/network restart
[root@gateway1 ~]# /etc/init.d/openvpn restart

Если при перезапуске openvpn присутствуют ошибки, проверьте log-файлы OpenVPN для получения дополнительной информации о неполадке. На этом настройка серверной части OpenVPN завершена.

Организация VPN-сети (часть пятая)

Организация VPN-сети (часть седьмая)

linux, vpn, network

Read or add comments to this article

Организация VPN-сети (часть седьмая)

Fri, 27 Aug 2010 08:42:00 +0000

Устанавливаем VPN-клиентов

Маршрутизаторы прочих филиалов будут выступать клиентами по отношению к VPN-серверу. Переходим к настройке клиентского роутера, устанавливаем пакеты openvpn, lzo аналогично тому, как описано ранее для сервера.

После установки пакетов конфигурируем службу в режиме клиента. Для этого копируем пример конфигурационного файла /usr/share/doc/openvpn-2.0.9/sample-config-files/client.conf в каталог /etc/openvpn и редактируем в соответствии с нашими условиями.

Файл /etc/openvpn/client.conf:

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
##############################################
 
# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client
 
# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun0
 
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap
 
# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp
 
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 10.0.0.2 1194
;remote my-server-2 1194
 
# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random
 
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
 
# Most clients don't need to bind to
# a specific local port number.
nobind
 
# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody
 
# Try to preserve some state across restarts.
persist-key
persist-tun
 
# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
 
# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings
 
# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca.crt
cert filial2.crt
key filial2.key
 
# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server
 
# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1
 
# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x
 
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
 
# Set log file verbosity.
verb 3
log-append /var/log/openvpn.log
 
# Silence repeating messages
;mute 20

Служба openvpn должна запускаться при загрузке системы. Устанавливаем уровень запуска службы:

[root@gateway2 ~]# chkconfig openvpn on

Возвращаемся на наш сервер OpenVPN (центральный маршрутизатор) и создаем ключ и сертификат для клиента-маршрутизатора филиала filial2:

[root@gateway1 ~]# cd /etc/openvpn/easy-rsa
[root@gateway1 easy-rsa]# . ./vars
[root@gateway1 easy-rsa]# ./build-key filial2

Ответив на ряд типовых вопросов (аналогично созданию ключа и сертификата для сервера), ответьте утвердительно на запрос о подписи нового сертификата. В конечном итоге, в каталоге /etc/openvpn/easy-rsa/keys добавятся два файла: filial2.key и filial2.crt. Работоспособность созданного сертификата можно проверить командой:

[root@gateway1 keys]# openssl verify -CAfile ca.crt filial2.crt

Устанавливаем параметры IP-протокола для клиента: переходим в подкаталог ccd каталога /etc/openvpn ¹⁾, внутри каталога создаем файл filial2 (имя, указанное как «commonName» при создании клиентского сертификата). В нем прописываем клиентский IP-адрес и шлюз, которые будут назначены клиенту filial2 при подключении ²⁾).

Файл /etc/openvpn/ccd/filial2:

ifconfig-push 10.10.0.5 10.10.0.6

В заключение, перезапускаем сервер openvpn на основном маршрутизаторе:

[root@gateway1 keys]# /etc/init.d/openvpn restart

Переходим снова к клиентскому маршрутизатору. Корневой сертификат сервера (ca.crt) и пару ключ-сертификат клиента (filial2.key, filial2.crt) нужно скопировать в папку /etc/openvpn клиентского маршрутизатора. Перезапускаем службу openvpn на клиентском маршрутизаторе:

[root@gateway2 ~]# /etc/init.d/openvpn restart

После перезапуска должно установиться VPN-подключение между основным и клиентским роутером, связь можно проверить «ping»-ами по IP-адресам VPN-сети. В случае проблем, смотрите логи openvpn (/var/log/openvpn.log).

Остальные маршрутизаторы-клиенты VPN-сети настраиваются аналогично.

Организация VPN-сети (часть шестая)

Организация VPN-сети (часть восьмая)

linux, vpn, network

¹⁾ Создаем этот каталог, если не существует

²⁾ Если пропустить этот шаг, будет динамически назначаться адрес из диапазона 10.10.0.0/24. Чтобы не ошибиться в параметрах, руководствуйтесь схемой из предыдущего раздела. В комментариях конфигурационного файла openvpn (см. server.conf там же) содержится развернутое описание параметров адресации

Read or add comments to this article

Использование openssh-server-jail

Fri, 27 Aug 2010 08:42:00 +0000

Основным отличием данной сборки от стандартного пакета openssh является возможность «запирать» подключающихся по SSH/SFTP пользователей в определенной директории (причем, для каждого пользователя она может быть своя).

Параметры chroot-окружения пользователей задаются в отдельном конфигурационном файле '/usr/openssh-jail/etc/sshjail.conf'. Во всем остальном настройка службы повторяет стандартный openssh (производится через '/usr/openssh-jail/etc/sshd_config').

Практический пример использования:

Если вы еще не установили пакет openssh-server-jail, сейчас самое время это сделать. После завершения процедуры установки отредактируйте основной конфигурационный файл службы '/usr/openssh-jail/etc/sshd_config': задайте номер tcp-порта для службы и запретите неиспользуемые вами методы аутентификации.

Допустим, системного пользователя 'user1' нужно ограничить его домашним каталогом ('/home/user1'). Используем скрипт «makejail», который идет в поставке с пакетом:

[root@ts ~]# /usr/openssh-jail/sbin/makejail user1 /home/user1

Можно написать еще проще (если отсутствует второй параметр, скрипт использует каталог '/home/USERNAME'):

[root@ts ~]# /usr/openssh-jail/sbin/makejail user1

После создания окружения, добавляем в файл '/usr/openssh-jail/etc/sshjail.conf' строки:

chroot=/home/user1
users=user1

Последний шаг, перезапускаем службу sshd-jail.

Типичные вопросы, возникающие при работе с программой:

1) У пользователя в его окружении отсутствует программа XXX, как ее добавить?

Посмотрите, как это реализовано в скрипте «makejail»: при помощи «ldd» для каждой утилиты в списке выясняются зависимости (библиотеки), затем они копируются в пользовательское chroot-окружение с таким расчетом, чтобы утилита могла их найти при запуске. Вы можете сэмулировать работу скрипта (запустить «ldd» для Вашей утилиты и скопировать утилиту и ее зависимости в jail-каталог), или же отредактировать скрипт «makejail» (вручную добавить свою утилиту в список «APPS» и пересоздать пользовательский «jail»).

2) Можно ли задавать ограничения не для одиночного пользователя, а для целой группы?

Да, sshjail обладает подобным функционалом. Смотрите пример конфигурационного файла, идущего в поставке с программой. Но учтите, что вы не сможете использовать скрипт «makejail» (он может создавать окружение для одиночного пользователя, но не для группы).

3) Обязательно ли располагать «клетку» (jail) в домашнем каталоге пользователя?

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

4) Можно ли в последствии менять физическое расположение jail-а пользователя?

Конечно. Вы можете переместить ее в любое место, и это не повлияет на работоспособность программ внутри chroot-окружения пользователя (см. предыдущий вопрос). Только не забудьте прописать новый путь к «клетке» в /usr/openssh-jail/etc/sshjail.conf.

5) Мне нравится стандартная реализация chroot в openssh! Могу ли я использовать ее вместо sshjail?

Безусловно, да. Хотя я не вижу в этом смысла, ведь в этом случае теряются все преимущества sshjail. Невозможно использовать два метода организации «chroot» одновременно; при активации стандартных методов («ChrootDirectory» в sshd_config и т.п.) закомментируйте все строки в файле /usr/openssh-jail/etc/sshjail.conf, чтобы отключить функционал sshjail. По вопросам использования стандартных методов «chroot» обратитесь к официальной документации OpenSSH.

6) Для каких дистрибутивов/архитектур можно использовать данный пакет?

Пакет собран и протестирован под RHEL5 и CentOS, архитектуры i386 и x86_64. Вы также можете собрать пакеты из SRPM под свою архитектуру.

7) Могу ли я использовать данный пакет под Fedora 9/10/11 и т.д.?

Теоретически, да; поскольку ничего специфичного в пакете нет. Перед сборкой для Fedora я бы внес некоторые коррективы в spec-файл, в первую очередь это касается секции зависимостей для сборки. Возможно также требуется обновить pam (sshd-jail.pam) в соответствии с версией, используемой в Вашем дистрибутиве.

Для получения дополнительной информации, посетите сайт автора sshjail.

linux, centos

Read or add comments to this article

NTFS-3g для CentOS

Wed, 10 Jul 2013 15:54:00 +0000

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

Готовых пакетов для ntfs-3g я не нашел (видимо, плохо искал), поэтому пересобрал нужные пакеты из репозиториев Fedora.

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

После установки модулей перезагрузки не требуется, можно сразу проверять работоспособность установленных компонентов. Мы подключили жесткий диск с помощью переходника Sata2USB и под-mount-или разделы, указав тип файловой системы ntfs-3g.

Содержимое диска отображается нормально, имена файлов и папок в правильной кодировке. Чтение и запись на разделы идет без проблем.

linux, centos

Read or add comments to this article

RPM-пакеты openssh-server-jail

Fri, 27 Aug 2010 08:42:00 +0000

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

Основные отличия данной сборки от официальной версии:

Оставлены лишь компоненты сервера и необходимые для него утилиты;

В связи с этим, имя пакета изменено на openssh-server-jail. Клиентская часть пакета нам без надобности; примеры конфигурации, man-ы и документация openssh-5.2 также не включены в пакет.

Изменены пути к исполняемым и конфигурационным файлам пакета;

Пакет устанавливается в отдельный каталог и не влияет на компоненты openssh. Вкупе со сменой имени пакета, это позволяет «развести по углам» две версии программы и избежать коллизий с имеющими в системе пакетами на уровне RPM-менеджера. Вы можете одновременно использовать openssh и openssh-server-jail или только один из них, при этом изменение конфигурации или удаление одного из них не окажет влияния на другой.

Не требуется вносить изменения в конфигурацию системы;

Основная причина, почему я отказался от использования стандартных механизмов chroot-a в openssh – это необходимость правки пользовательских параметров в /etc/passwd (добавлять последовательность '/./' в путь к домашнему каталогу пользователя; для openssh это служит признаком того, что пользователя нужно «запереть» в каталоге). В дополнение к этому, владельцем домашнего каталога пользователя нужно делать пользователя 'root'. Все эти манипуляции вызывают проблемы с правами, если пользователь будет входить в систему локально; не говоря уж о том, что некоторые программы некорректно воспринимают путь вида '/home/user/./'. В случае же использования патча sshjail, параметры chroot хранятся не в системе, а в отдельном конфигурационном файле (sshjail.conf).

Изменен номер tcp-порта службы;

Во избежание конфликтов с потенциально работающим sshd, демон sshd-jail из пакета openssh-server-jail по умолчанию слушает tcp-порт 2200 (номер порта можно изменить в конфигурационном файле).

Автоматизация создания chroot-окружения;

Найденный в Сети скрипт для организации пользовательского chroot-окружения был мной подкорректировал в соответствии с нашими нуждами, и включен в пакет (после установки пакета, доступен как /usr/openssh-jail/sbin/makejail).

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

Как всегда, скачать пакеты можно здесь.

linux, centos

Read or add comments to this article