Наразі виникла необхідність “прозорого” для віддалених співробітників підключення до локальної мережі малого підприємства. Зі слів замовника: “ХАЧУ(sic!), щоби було так, щоб, е-е-е, ну щоб поїхати у відрядження, а тако нажати на кнопочку і вже підключитися до мережі“.
Ну, як відомо, бажання замовника — то є закон. Беремося за роботу!
Розвідка боєм
Локальна мережа цих товаришів колись була кимось налаштована, та наразі контакт з власне адміністраторами було втрачено — мережею займався технік, який знав дещо з того, що його навчили адміни. Щож — будемо виходити з того, що є. Між Інтернет та локалкою контори стоїть маршрутизатор, до якого є (обмежений) адмін-доступ, всі сервіси в локальній мережі чітко обмежені використанням з їхньої підмережі. Міняти налаштування, щоби додати окрему мережу для ВПН клієнтів не виявлялося за можливе: бо геморно та й роботи багато.
Що ж будуємо?
Було прийнято рішення щось на зразок інжекції ВПН клієнтів в існуючу локальну мережу. Щоправда, я особисто не дуже схвалюю такі рішення внаслідок збільшення точок взаємоз’єднання глобальної та локальної мереж, проте іншого виходу не було.
В мережі було виявлено майже безхозний сервер з, в принципі, непоганою апаратною конфігурацією. В якості операційної системи стоїть Fedora 12. Один з моїх улюблених дистрибутивів (до розвитку якого докладаю зусиль по мірі можливого — до чого і Вас закликаю) та зараз не про це — якось іншим разом.
В якості ВПН сервера було обрано OpenVPN.
Чому його:
- Є можливість роботи по TCP та UDP протоколах.
- Окрім цього, не потрібно інших протоколів на зразок GRE, що сильно затруднює фільтрацію (фактично можна прикинути трафік під будь-який інший шифрований) та пріоритезацію тунельного трафіку зі сторони деяких провайдерів (таке зустрічається).
- І, саме головне, дає можливість встановлення TAP (L2 OSI) інтерфейсів.
З іншої сторони, можна було би використовувати і IP-маршрутизований (L3 OSI) тип інтерфейсу, проте у замовника використовуються деякі програми, які некоректно працюють через NAT.
Використовуємо протокол UDP, оскільки за думкою деяких авторитетних джерел : Why TCP Over TCP Is A Bad Idea, з чим я особисто згодний. Більш того, для простих користувачів, використання цього протоколу виглядає в безрозривному перепідключенні при поганому Інтернет-з’єднанні.
Go-go-go!!!
Зміна параметрів мережі
Для успішної реалізації нашої задумки нам слід ув’язати два L2 інтерфейси в брідж.
Наразі маємо:
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:00:D3:00:68:0B inet addr:192.168.0.250 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:475981 errors:0 dropped:0 overruns:0 frame:0 TX packets:1043500 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:31818293 (30.3 MiB) TX bytes:1433394318 (1.3 GiB)
cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=none IPADDR=192.168.1.250 NETMASK=255.255.255.0 ONBOOT=yes USERCTL=no IPV6INIT=no PEERDNS=no NOZEROCONF=yes
Переналаштування мережевих інтерфейсів:
1. Виключаємо на інтерфейсі eth0 ІР та включаємо його в брідж.
cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=none IPADDR="" NETMASK="" BRIDGE=br0 ONBOOT=yes USERCTL=no IPV6INIT=no PEERDNS=no NOZEROCONF=yes
Ось цим: BRIDGE=br0 , прив’язується фізичний (чи віртуальний) пристрій (тут: DEVICE=eth0) до відповідного бріджа.
2. Створюємо брідж інтерфейс br0 , на якому і налаштовуємо ІР .
cat /etc/sysconfig/network-scripts/ifcfg-br0
TYPE=Bridge DEVICE=br0 ONBOOT=yes BOOTPROTO=static IPADDR=192.168.1.250 NETMASK=255.255.255.0 ONBOOT=yes USERCTL=no IPV6INIT=no PEERDNS=no NOZEROCONF=yes
Не забуваємо, що ifcfg-скрипти прискіпливо ставляться до регістру параметрів в конфігах, тому пишемо обов’язково “Bridge“, а не “bridge” чи “BRIDGE”.
3. Перезапускаємо мережу, не забувши виключити непотрібний нам NetworkManager.
/sbin/chkconfig network on
/sbin/chkconfig NetworkManager off
/sbin/service network restart
Звісно, ці операції дозволено виконувати лише з-під привілейованого облікового запису, тому не забуваємо ставати перед цим root (sudo -s чи su , кому як більше до вподоби)
Установка та налаштування OpenVPN
1. Встановлюємо OpenVPN природним для RedHat-based дистрибутивів.
yum install openvpn
2. Налаштовуємо ОпенВПН
cat /etc/openvpn/tap0.сonf
# порт на якому працює сервер port 443 # протокол - TCP / UDP proto udp # тип (обов'язковий) та номер (можна опускати) пристрою dev tap0 persist-key # не передьоргувати TUN\TAP # пристрій при отриманні сигналу # SIGUSR1 или ping-restart persist-tun #після підняття інтерфейсу виконати up /etc/openvpn/test.sh #статус пишем сюди status /var/log/openvpn/tun0-status.log #лог ДОПИСУЄМО! в файл log-append /var/log/openvpn/tun0-openvpn.log #рівень балакучості демона # продакт -- не більше 3-х # запуск -- можна 6 # при проблемах -- 9 verb 6
3. Скрипт, який ув’язує TAP інтерфейс OpenVPN’а і фізичну мережеву картку
cat /etc/openvpn/test.sh
#!/bin/bash /sbin/ifconfig $1 promisc up /usr/sbin/brctl addif br0 $1
Скрипт написаний чисто для демонстрації можливостей ОперВПН, його, звісно, можна значно розширити функціоналом, чи написати універсальний на декілька тунелів. Наразі потреби в цьому не було.
Не забудьте поміняти налаштування фаєрволу у відповідності до Ваших потреб.
Так як фаєрволу на цьому сервері не стояло, і місцевий тіпа-адмін ставити не захотів категорично, що ж це буде на його сумлінні. Кажуть, у них в офісі всі дуже дисципліновані і бяк не роблять, на прон не дивляться, вірусів не хапають. Повіримо їм на слово 🙂
Happy end!
P.S. Не люблю я TAP інтерфейси OpenVPN, бо не бачу поки-що ефективного механізму контролю за поведінкою ВПН-клієнтів. Тому все-таки рекомендую використовувати маршрутні IP-інтерфейси (3-го рівня по моделі ОСІ).
P.S.S. Якщо когось зацікавив матеріал, та є якісь незрозумілі/недостатньо висвітлені моменти — прошу в коментарі.