30 сентября 2011 в 19:47

VPN на 50+ филиалов на коленке

image
Появилась потребность сделать VPN для аутсорсинговой компании — организовать связь с сетями компаний клиентов таким образом, чтобы админы заказчика и собственной сети видели каждый хост клиента за NATом и не было возможно обратное. Аппаратные решения в принципе не рассматривались ввиду стоимости, да и все проприетарные программные решения отсеялись по этой же причине. Остался только свободный софт. Благо свободных решений более чем достаточно

Поскольку начинал я знакомство со свободными системами с FreeBSD — выбор пал на нее. Сразу прошу хабралюдей не разводить холивар на тему BSD vs Linux – основной причиной выбора были более глубокие знания этой системы (до сих пор не могу осилить Linux настолько, чтобы быть уверенным в результатах своей работе с ним). Собственно, ВПН решено было организовать на основе OpenVPN — опять же, раньше приходилось иметь с ней дело, и недостатков я не обнаружил. И снова попрошу без холивара на тему PPTP – если есть приверженцы такого решения – лучше напишите свою статью.

Так же заказчиком было озвучено требование простоты управления. Чтобы в случае чего работники заказчика смогли подправить конфиги по бумажке под конкретные нужды.
Ну и требовался полный мониторинг трафика, проходящий между сетями и доступ через авторизацию в AD (у заказчика на основном шлюзе стоит Kerio Winroute Firewall)
Итак, подведя черту под требованиями, получили следующее:
— Минимальная стоимость оборудования
— Легкость в управлении
— Скорость развертывания
— Управление доступом
Подробности решения – под катом
Задача легкого управления, естественно, свелась к выбору дистрибутива с удобным веб-интерфейсом. Выбор пал на pfSense:

1. Минимальные требования к железу — работает на PII/128RAM;
2. Стабильная, безглючная веб-мордочка — разберется даже эникейщик, поверхностно знакомый с сетевыми технологиями;
3. Установка за 10 минут — сохранение всех настроек в одном XML-файле;
4. Кроме того в качестве бонусов большое количество софта, которое управляется так же из веб интерфейса и весь набор ПО для FreeBSD, если уж что-то специфичное понадобится.

Что нами собственно было сделано по шагам:
1. Поставлена в виртуалку (на XEN) чистая FreeBSD 8.2, которой отдали одно ядро и 256 памяти
2. Установлена OpenVPN (просто #pkg_add -r openvpn20)
3. Сочинен конфиг OpenVPN следующего содержания:

port 1194 #на какой порт стучаться клиентам
proto udp #наш выбор UDP
dev tap # выбрано было из соображений адресации — не хотелось видеть кучу туннелей

#keys
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key
dh /usr/local/etc/openvpn/keys/dh1024.pem

#server`s IP
server 10.17.0.0 255.255.0.0 #собственно, IP сервера
push «route 10.17.0.0 255.255.0.0» # маршрут клиентам для нашего VPN
push «route-gateway 10.17.0.1» Почему-то без него не работало, хотя должно
client-config-dir ccd #директория в которой лежат конфиги клиентов
client-to-client #разрешаем клиентов видеть друг друга
route 10.17.0.0 255.255.0.0 #маршрут для нашего VPN
#authentification
tls-server #заставим TLS
tls-auth keys/ta.key 0
tls-timeout 120
auth MD5 #заставим MD5
cipher BF-CBC #заставим шифровать
keepalive 10 120
comp-lzo #сжимаем трафик
max-clients 4000 #взято с потолка
user nobody #в целях паранойи и философии системы
group nobody
persist-key

#logging
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

Расписывать полностью конфигурирование, я думаю, не стоит — специфичных статей достаточно.

4. Собственно, добавил все это в автозагрузку:

server# more /etc/rc.conf

defaultrouter=«192.168.0.247»
gateway_enable=«YES»
hostname=«server.nerv.local»
ifconfig_re0=«inet 192.168.0.244 netmask 255.255.255.0»
keymap=«ru.koi8-r»
sshd_enable=«YES»
openvpn_enable=«YES»
openvpn_if=«tap»
openvpn_configfile="/usr/local/etc/openvpn/server"
openvpn_dir="/usr/local/etc/openvpn"
startroute_enable=«YES»

Раздача IP клиентам ведется из файлов директории ccd — это видно из конфига на этом вся настройка сервера закончена — опять же не буду описывать генерацию ключей — все это очень правильно и подробно расписано, например, здесь: www.lissyara.su/articles/freebsd/security/openvpn

В файле клиента в директории ccd пишется только одна строка:
ifconfig-push 10.17.0.131 255.255.0.0 # отдаем клиенту конкретный адрес с маской
Все операции по поднятию боевого сервера на железе заказчика уложились в 20 минут, не считая создания ключиков.

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

==========настройка OpenVPN клиента на pfSense======
1. меню System > Cert Manager > вкладка CA
добавляем новый CA
1. в поле Descriptive name вписываем произвольный идентификатор;
2. в списке Method выбираем «Import an existing Certificate Autority»
3. в поле Certificate data вписываем содержимое сертефиката ca.crt
сохраняем
2. меню System > Cert Manager > вкладка Certificates
добавляем новый сертификат клиента
1. в списке Method выбираем «Import an existing Certificate»
2. в поле Descriptive name вписываем произвольный идентификатор;
3. в поле Certificate data вписываем содержимое сертефиката name_client.crt
4. в поле Private key data вписываем содержимое файла name_client.key
сохраняем
3. меню VPN > OpenVPN > вкладка Client
добавляем новое подключение
1. в списке Server Mode выбираем Peer to Peer (SSL/TLS)
2. протокол UDP
3. Device mode — TAP
4. Interface — WAN
5. local port — оставляем пустым
6. server host or address вписываем ip-адрес сервера
7. server port 1194
8. proxy не заполняем
9. в разделе TLS Authentication снимаем галочку (Automatically generate a shared TLS authentication key)
10.в открывшемся поле вписываем содержимое ta.key
11.Peer Certificate Authority выбираем то, что ввели в п. 1.1
12.в списке Client Certificate выбираем тот, что ввели в п. 2.2
13.в списке Encryption algorithm выбираем BF-CBC(128 bit)
14.в поле Compression ставим галочку (Compress tunnel packets using the LZO algorithm)
15 в поле Advanced вписываем
auth MD5
ns-cert-type server
persist-key
verb 3
сохраняем. Если все сделали правильно, то через 15-45 секунд подключение станет активным
4. Выбираем пункт меню Interfaces -> (assign)
1. Добавляем новый интерфейс кнопкой "+"
2. Выбираем в выпадающем списке интерфейс ovpnc1, нажимаем кнопку «Save»
3. Выбираем пункт меню Interfaces -> OPT1, ставим галочку «Enable interface», нажимаем «Save», нажимаем кнопку «apply change»
4. В Строке description вводим VPN, в списке Type выбираем «Static», в появившемся поле «Static IP configuration» вводим адрес ВПН-клиента и выбираем маску 16 (шлюз вводить не надо!!!)
5. Если есть галочки в разделе Private networks — снимаем их и нажимаем кнопку «Save»
5. Выбираем пункт меню Firewall -> NAT
1. выбираем вкладку Outbound
2. Ставим переключатель mode в режим manual (правое положение) и нажимаем save
3. В списке NAT добавляем новую опцию нажатием кнопки "+"
4. В поле Interface выбираем OpenVPN (не VPN!!!)
5. в поле Source вводим адрес локальной сети (это, как правило, 192.168.x.0/24) и выбираем маску
6. В поле Destination вводим сеть 10.17.0.0 и маску 16
7. В поле Translation ставим галочку Static port
8. нажимаем кнопку SAVE
======================================

Естественно, pfSense должен быть настроен как основной шлюз на стороне клиента заказчика.

И, наконец, последний шаг — настройка доступа из сети заказчика в сети клиентов: на шлюзе заказчика был поднят клиент OpenVPN (использовали OpenVPN-GUI) и прописаны статические маршруты до сетей через IP-адреса сети 10.17.0.0/16

Вот собственно и все, что понадобилось. Единственно требование для простоты настройки этой схемы — сети всех клиентов должны быть разные. Для заказчика это условие оказалось несложным – там, где сети совпадали, все было перенастроено без проблем и полностью удаленно через эту же сеть VPN.
@Lamaster
карма
6,0
рейтинг 0,1
Похожие публикации
Самое читаемое Администрирование

Комментарии (21)

  • +6
    Почитайте про динамическую маршрутизацию и, в частности, ospf.
    В таких масштабах сэкономит вам и время, и нервы.
    • 0
      как конкретно здесь поможет dynamic routing (ospf)?
      на BRAS прописан статик в 10.17.0.0/16
      в филиалах — дефолт в тунель
      в ядре — статик в 10.17.0.0/16 на BRAS
  • +1
    На самом деле — OpenVPN мультиплатформенна и настраивается и на фре и на *nix и на Win. и никаких танцев с бубном.
    под никсы (убунту в частности) вся установка сводится к:
    apt get-install openvpn
    закачке конфига и ключей в директорию /etc/openvpn/
    Под винду решение вообще простейшее. Там и клиент и сервер в одной программе (хочешь раздавай, хочешь конектись сам).
    • 0
      Под freebsd установка сводится к portinstall openvpn (или /usr/ports/secuiry/openvpn && make install clean, или же еще проще pkg_add -r openvpn20), тут же идет речь о PC-роутере с вэьмордой.

      > Под винду решение вообще простейшее. Там и клиент и сервер в одной программе (хочешь раздавай, хочешь конектись сам).

      А под *nix нет?

      > под никсы (убунту в частности)

      С каких пор FreeBSD перестал быть Unix like?
  • 0
    Под все ваши требования и даже больше, подпадает Mikrotik RB750
    • –1
      попадать попадает но проигрывает по производительности, как и остальные решения OVPN
  • 0
    При 50+ филиалов уже стоит посмотреть в сторону железного решения.
    Плюсов и минусов железного решения много. Может оно будет немного дороже в процессе внедрения, но уж точно окажется дешевле в ослуживании по сравнению с использованным PII/128RAM.
    Короче — тема холиварная. Все зависит от ТЗ.
  • +2
    Недостатки OpenVPN — производительность. В сети на 2к онлайн пользователей с торрентами машина загибалась очень быстро (машина была не самая слабая). При замене на PPTP нагрузка на машине редко поднималась выше 5% при тех же условиях.
    • 0
      50+ это точно << 2000, я думаю. Ну и хотелось таки tap и без туннелей.
  • +1
    auth MD5 #заставим MD5

    Зачем это? Для авторизации по сертификату этого не нужно.
    • 0
      проверю обязательно, спасибо
  • +4
    Для пранойи создайте отдельного юзера. Использование nobody — это древняя ошибка многих дистрибутивов. Юзер должен быть отдельным, чтобы в случае его компрометации не вытекала автоматическая компрометация другого демона, работающего под тем же uid.
    • +2
      в данном случае в системе только OpenVPN, поэтому можно следовать древней философии
  • +1
    По поводу OpenVPN. Немного разочаровался в производительности, требует в разы больше ресурсов чем нативный IPSEC с одинаковым шифрованием. Плюсы, конечно, это очень простая настройка и работа из-за NAT.
  • 0
    А как оно будет с 256 мб памяти работать с 50+ филиалами?
    • 0
      высокий трафик не предполагался. Главной задачей было добраться до каждого клиента за все возможные NAT`ы. А если когда оно понадобится, то виртуалке отдать поболее памяти — непроблема
  • +3
    это результат вывода команды man по теме?
  • +1
    ru.wikipedia.org/wiki/Аутентификация — перечитывать до просветления.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Наличие прочего функционала окончательно определило выбор. M0n0wall все таки очень обрезан. А, как я упомянул в статье, pfSense — это полноценная BSD. А поскольку машинки у клиентов ставились как основной шлюз, хотелось оставить возможность маневра.
  • 0
    Я бы mikrotik взял.

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