У моєму випадку було необхідно з'єднати кілька віддалених філій зі своїми локальними мережами з центральним офісом, а також забезпечити роботу деяких співробітників з дому.
Схема мережі повинна виглядати приблизно так:
При цьому білий IP є тільки у центрального офісу. Як всіх проксі-серверів використовуються комп'ютери з ОС OpenSuSE Linux - через легкість настройки, всі дії займуть не більше півгодини (для серверів).
Для початку потрібно встановити пакети OpenVPN на всіх серверах, і на кожному клієнті, який безпосередньо буде з'єднаються з головним сервером.
Для початку підготуємо сертифікати для клієнтів і сервера:
скопіюємо скрипти easyrca в котрійсь із каталогів користувача,
заповнимо дані у файлі vars відповідними значеннями (довжинами ключів і терміном дії сертифікатів, назвою компанії, місцями і т.п.)
виконати source ./vars для установки наших змінних,
потім очистимо ключі, які можуть бути від попередніх установок: ./clean-all
і сформуємо кореневий сертифікат: ./build-ca
Тепер можна приступити до формування ключів:
для сервера: ./build-key-server <имя сервера/сертификата>
для клієнтів: ./build-key <имя клиента/сертификата>
в якості імені сертифіката сервера доцільно вказати «server», а для клієнта - назва підрозділу, до якого буде відноситься сертифікат (наприклад client_msk_timirjazevskaya, client_msk_marjina_rosha, client_spb_gorkovskaya і т.д.)
Потім сформуємо параметри шифрування протоколу Діффі-Хельмана: ./build-dh
Тепер в папці keys лежать всі необхідні файли, які необхідно покласти в папку / etc / openvpn по серверу і клієнтам наступним чином:
- ca.crt - кореневий сертифікат, на сервер і на кожного клієнта
- ca.key - ключ для підпису сертифікатів, залиште в папці з ключами і нікому не давайте :)
- dh1024.pem - параметри шифрування, на сервер
- server.crt - сертифікат сервера, на сервер
- server.key - закритий ключ сертифіката сервера, на сервер, ключ є секретним
- client _ *. crt - сертифікати клієнтів, на відповідні машини клієнтів
- client _ *. key - закритий ключ сертифікатів клієнтів, на відповідні машини клієнтів, ключі є секретними
тепер скопіюємо файл конфігурації сервера з папки з прикладами в папку з настройками openvpn:
cp /usr/share/doc/packages/openvpn/sample-config-files/server.conf / etc / openvpn /
в цьому файлі нас не влаштовують деякі параметри:
push "route 192.168.0.0 255.255.240.0" # маршрут у внутрішню мережу для клієнтів
client-config-dir ccd # папки з конфігураціями для клієнтів (для призначення статичних IP) (створити всередині / etc / openvpn)
client-to-client # маршрутизація між клієнтами
up "service SuSEfirewall2_setup restart" # перезапуск файрволла при старті сервісу
down "service SuSEfirewall2_setup restart" # і при зупинці. через те, що пристрої,
# Створювані openvpn віртуальні і існують тільки поки він запущений
route 192.168.1.0 255.255.255.0 10.8.0.2 # маршрут в мережу філії 1
route 192.168.2.0 255.255.255.0 10.8.0.3 # маршрут в мережу філії 2 (див. Схему)
# І маршрути в мережі інших філій.
тепер потрібно налаштувати фаєрвол на сервері і клієнтів для того, щоб він пропускав запити з vpn у внутрішні мережі (на клієнтах без внутрішніх мереж і не публікують ніяких ресурсів не обов'язково) (також передбачається, що файрволл вже налаштований як шлюз в інтернет для внутрішньої мережі) :
далі всі дії проводяться в гілці / network / Firewall / SuSEfirewall2 /
FW_DEV_INT додати через пробіл ім'я інтерфейсу openvpn (tap0) - додаємо його у внутрішню зону
FW_ALLOW_CLASS_ROUTING int - дозволяємо маршрутизацію між інтерфейсами внутрішньої внутрішньої зони
FW_REJECT_INT no - не відхиляється пакети з внутрішньої зони - не обов'язково
FW_FORWARD_ALLOW_BRIDGING yes - включити мережеві мости, навіть якщо немає жодного Інтерфом типу міст
все, тепер можна зберігати всі налаштування і запускати openvpn (на серверах і на клієнтах):
service openvpn start
має повернути done, в списку мережевих пристроїв повинно з'явиться пристрій tap0
ifconfig
tap0 Link encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Mask: 255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU 1500 Metric: 1
RX packets: 611222 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 539849 errors: 0 dropped: 0 overruns: 0 carrier: 0
collisions: 0 txqueuelen: 100
RX bytes: 108883515 (103.8 Mb) TX bytes: 141490615 (134.9 Mb) tap0 Link encap: Ethernet HWaddr 00: FF: A0: B4: 72: BF
inet addr: 10.8.0.1 Bcast: 10.8.0.255 Mask: 255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU 1500 Metric: 1
RX packets: 611222 errors: 0 dropped: 0 overruns: 0 frame: 0
TX packets: 539849 errors: 0 dropped: 0 overruns: 0 carrier: 0
collisions: 0 txqueuelen: 100
RX bytes: 108883515 (103.8 Mb) TX bytes: 141490615 (134.9 Mb)
в маршрутах автоматично прописатися потрібні:
ip route
192.168.2.0/24 via 10.8.0.3 dev tap0
192.168.1.0/24 via 10.8.0.2 dev tap0
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.1
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.100
Все, настройка закінчена, тепер при першій же можливості клієнти будуть підключаться до сервера і складати віртуальну локальну мережу як на схемі на початку статті, в якій можна безпечно публікувати сервери і ресурси. Інтернет при цьому буде працювати як і працював, така схема працює поверх вже встановлених VPN з'єднань, і т.д. Якщо на клієнтах, які безпосередньо підключаються до сервера використовується networkmanager - необхідний пакет networkmanager-openvpn, для windows настройка приблизно така ж.
навіщо вам знадобився кидок L2, тобто dev tap? Чим dev tun topology subnet не влаштував?
невірно вказана исключаемая маска, та й взагалі виключаються підмережі для vpn-клієнтів
У чому помилка, як, Ви вважаєте, має бути?
в поширених дистрибутивах в ходу iptables.
Тут кожен сам для себе вирішує. 19 людям, судячи з усього, було корисно, а мінуса від Вас я не бачу :)
proto tcp поустойчівее, хоча і менш економічний.
при підключенні через 3g по rdp поверх цього vpn - різниця видна на око, і вона не на користь варіанту з tcp. А надійність забезпечується тим, що той же самий tcp йде вже всередині тунелю.
Та й порт можна будь призначити.
з topology subnet те ж саме. Тільки непотрібних даних ганяється менше.
невірно вказана исключаемая маска, та й взагалі виключаються підмережі для vpn-клієнтів У чому помилка, як, Ви вважаєте, має бути?
Обмеження: внутрішня мережа клієнтів не повинна перетинатися з такими мережами:
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
UPD якраз при мережі клієнта 192.168.0.0/28 велика частина господарства буде працювати. Згідно з правилом вибору маршруту по більшій масці.
при підключенні через 3g по rdp поверх цього vpn - різниця видна на око, і вона не на користь варіанту з tcp
Постійно користуюся з планшета, різниці не бачу, все цілком комфортно. dev tun, topology subnet, proto tcp, tun-mtu 1024.
Плюс в тому, що при відвалі 3G, наприклад, в дорозі, реконнект відбувається через 10-12 секунд проти 20-30 з UDP. ping коштує 10
Можна ще написати про те, що 10.8.0.0 у провайдера всередині може використовуватися, і тоді теж (в певній ситуації) можливі косяки
От саме тут косяки малоймовірні, тому що клієнту ця мережа не потрібна. Та й маски різні. Провайдери вкрай рідко використовують / 24 на сірих сегментах, зазвичай маска менше.
Втім, якщо вважаєте за краще їздити додому до співробітників перенастроювати роутери - welcome. Але - в неробочий час і безкоштовно.
А що стосується iptables - ні в одному ніксовом howto Ви не знайдете вказівки використовувати додаткові оболонки. Все на iptables -A. Бо це універсальна команда, на відміну від.
А ось це, вибачте, прогавив.