<
  • Главная
Статьи

Два шлюзу в Інтернет і OpenVPN

  1. Матеріал з Xgu.ru ОС і ПЗ: Linux, OpenVPN Автор: Ігор Чубин Короткий URL: openvpn / gw На сторінці...
  2. [ правити ] Автоматична правка файлу / etc / network / gateways
  3. [ правити ] Маршрутизація з двома шлюзами
  4. [ правити ] Автоматична зміна маршруту за замовчуванням
  5. [ правити ] Скрипт change_default_route
  6. [ правити ] Додаткові питання
  7. [ правити ] Додаткова інформація

Матеріал з Xgu.ru

ОС і ПЗ: Linux, OpenVPN

Автор: Ігор Чубин
Короткий URL: openvpn / gw

На сторінці описується як за допомогою OpenVPN і двох незалежних інтернет-каналів низької надійності організувати надійне підключення віддаленої мережі (або системи) до центральної мережі.

Наведене рішення може бути корисно і без використання VPN - для вирішення завдання автоматичного вибору основного шлюзу.

Є два канали зв'язку з Інтернетом, через двох незалежних провайдерів. Один з каналів є основним, другий - резервним. Резервний канал потрібно використовувати тільки тоді, коли недоступний основний.

Потрібно зробити так, що б як тільки Інтернет стає недоступним через одне із з'єднань (не має значення через те що зник зв'язок з провайдером, або тому що проблеми у провайдера), автоматично змінювати маршрут за замовчуванням і використовувати інший канал.

Як тільки зв'язок через основний канал відновлюється, необхідно повертатися на його використання.

Розглянути ситуацію, коли комп'ютер входить в іншу мережу через OpenVPN:

  • OpenVPN повинен перестартовивать після зміни маршруту;
  • (Важливо!) Коли OpenVPN-з'єднання встановлено, маршрут за замовчуванням спрямований в приватну мережу через OpenVPN.

Якщо OpenVPN не використовується, нічого страшного - завдання тільки спрощується.

Схема включення шлюзу gw в Інтернет і локальну мережу (LAN), показана нижче.

+ ------- + | CENTRAL | | VPN | | HUB | + --- + --- + | _____._ ____ / \ ___ __ / \ / \ __ | \ \ Internet | | | \ _. \ ___ / \ ___ _ / \ _______ / GW1 GW2 * * || | IP1 || | IP2 [eth1] || | [Eth2] + ------- + | | | gw | | | + --- + --- + | [Eth0] | - LAN

  • CENTRAL VPN HUB - центральний VPN-концентратор, на який потрібно тримати VPN-канал;
  • GW1 - шлюз першого провайдера, на інтерфейсі з нашого боку встановлено IP-адреса IP1 (бажаний канал, відзначений подвійною лінією);
  • GW2 - шлюз другого провайдера, на інтерфейсі з нашого боку встановлено IP-адреса IP2.

На шлюзі gw працює VPN-клієнт, який через Інтернет повинен встановлювати тунель на центральний VPN-сервер (CENTRAL VPN HUB).

[ правити ] Файл / etc / network / gateways

Для простоти подальшого маніпулювання адресами інтерфейсів і шлюзів потрібно створити файл, в якому всі ці адреси і будуть вказані і модифікувати скрипти налаштування мережевих інтерфейсів так, щоб вони використовували цей файл.

  • IP1 - адреса першого інтерфейсу (eth1);
  • IP2 - адреса другого інтерфейсу (eth2);
  • GW1 - адреса шлюзу, доступного через перший інтерфейс;
  • GW2 - адреса шлюзу, доступного через другий інтерфейс;
  • DEFAULTGW - адреса пріоритетного (один з GW1 і GW2) шлюзу (якщо він працює, краще використовувати його).

Приклад файлу / etc / network / gateways

#### ISP 1 IP1 = 10.0.1.1 GW1 = 10.0.1.2 #### ISP2 IP2 = 10.0.4.1 GW2 = 10.0.4.4 ### Let ISP1 be default DEFAULTGW = $ {GW1}

Для того щоб уникнути випадкового внутрішнього протиріччя в настройках, варто використовувати ці адреси і при налаштуванні інтерфейсів. Наприклад, для Debian GNU / Linux, якщо настройка інтерфейсу виконується статично через файл / etc / network / interfaces:

iface eth1 inet manual up sh -c '. / Etc / network / gateways; ifconfig eth1 $ IP1 'iface eth2 inet manual up sh -c'. / Etc / network / gateways; ifconfig eth2 $ IP2 '

(Якщо при налаштуванні інтерфейсу потрібно вказувати і маску, слід додати відповідну змінну в файл / etc / network / gateways і використовувати її під час налаштування інтерфейсу).

[ правити ] Автоматична правка файлу / etc / network / gateways

IP-адреси мережевих інтерфейсів і шлюзів, зазначені в файлі / etc / network / gateways, можуть змінюватися, за умови, що вони призначаються динамічно при конфігуруванні інтерфейсу. В цьому випадку необхідно щоб файл відбивав зміни адрес.

Автоматична правка файлу / etc / network / gateways можливо за допомогою скрипта, який викликається при піднятті відповідного інтерфейсу.

Для Debian GNU / Linux це можна зробити або вказавши скрипт в директиві up в файлі / etc / network / interfaces або розмістивши у відповідному каталозі, наприклад /etc/ppp/ip-up.d/.

Приклад скрипта який викликається при піднятті інтерфейсу показаний нижче. Тут інтерфейс відповідає каналу 1, і тому він править змінні GW1 і IP1.

Приклад. Скрипт автоматичної правки файлу / etc / network / gateways, що викликається при підйомі інтерфейсу.

#! / Bin / sh case $ 1 in ppp200) / bin / ip rule add from $ 4 lookup 3 / bin / ip route add default via $ 5 table 3 / usr / bin / perl -i -p -e 's / GW1 =. * / GW1 = ' "$ 5" / / etc / network / gateways / usr / bin / perl -i -p -e' s / IP1 =. * / IP1 = ' "$ 4" / / etc / network / gateways ;; esac exit 0

[ правити ] Маршрутизація з двома шлюзами

Маршрутизатор має два інтерфейси, які дивляться в Інтернет через двох провайдерів (два інші незалежні шлюзу). При простий налаштуванні маршрут за замовчуванням може бути тільки один. Це означає, що весь трафік зі шлюзу (за винятком трафіку, адресованого в безпосередньо підключені мережі, і мережі, маршрут в які явно вказано) буде йти через це маршрут.

Нам необхідно зробити так, щоб шлюз відправляв пакети в інтернет, в залежності від того, який у них зворотну адресу:

  • трафік з інтерфейсу eth1 повинен йти через GW1;
  • трафік з інтерфейсу eth2 повинен йти через GW2.

Таким чином, відповіді повинні йти через той інтерфейс, на який вони прийшли. Вхідні підключення з нашого боку, якщо вони прив'язані до інтерфейсу, повинні йти через шлюз, який доступний через цей інтерфейс. Ті сполуки, які до інтерфейсу не прив'язані повинні йти через маршрут за замовчуванням.

Це завдання можна вирішити за допомогою policy routing, настройка якої в Linux можлива за допомогою iproute2.

Наприклад для шлюзів GW1 і GW2, які описуються в / etc / network / gateways:

. / Etc / network / gateways ip rule add from $ IP1 lookup 2 ip rule add from $ IP2 lookup 3 ip route add default via $ GW1 table 2 ip route add default via $ GW2 table 3 ip route add default via $ DEFAULTGW

/ Etc / network / gateways ip rule add from $ IP1 lookup 2 ip rule add from $ IP2 lookup 3 ip route add default via $ GW1 table 2 ip route add default via $ GW2 table 3 ip route add default via $ DEFAULTGW

Така схема маршрутизації ще не були правильно працювати з iptables DNAT. Іншими словами, якщо за допомогою iptables / netfilter прокидати звернення на якісь порти всередину мережі, принцип «відповіді йдуть по тому каналу, по якому приходять запити» працювати не буде. Один із способів вирішення проблеми описаний нижче, в розділі « Два шлюзу в Інтернет і NAT ».

[ правити ] Автоматична зміна маршруту за замовчуванням

Основний маршрут потрібно змінити, коли він перестає працювати. Як перевірити, що маршрут більше не працює?

Найпростіше - перевіряти доступність найближчого по цьому маршруту шлюзу, тобто шлюзу провайдера. Це спосіб поганий тим, що шлюз провайдера може бути доступний, але у самого провайдера можуть бути проблеми зі зв'язком.

Кращий спосіб - перевіряти доступність сервера, на який повинен бути встановлений тунель через той чи інший канал. Це можна зробити шляхом відправки ICMP-запитів з того чи іншого інтерфейсу.

Скрипт використовує другий спосіб. Кожні 30 секунд (CHECK_INTERVAL) виконується перевірка. Як тільки зв'язок через пріоритетний шлюз втрачається, а зв'язок через другий шлюз при цьому є, проводиться перехід на використання другого шлюзу в якості основного.

При відновленні зв'язку через пріоритетний шлюз, скрипт переводить систему на використання його в якості основного (default gateway).

При будь-якої зміни шлюзу (як з пріоритетного на резервний, так і навпаки) в syslog потрапляє повідомлення про те, що шлюз змінився, і вказується причина цієї зміни:

Sep 3 13:12:15 stab / usr / local / bin / change_default_route: Gateway 199.5.5.111 (199.5.5.112) is not usable. Trying 221.42.167.30 (221. 42.167.29) Sep 3 13:12:16 stab / usr / local / bin / change_default_route: Changing default route from 199.5.5.111 to 212.42.167.30

[ правити ] Скрипт change_default_route

Стан шлюзів контролює скрипт, change_default_route, що працює відповідно до вищеописаного алгоритму.

Змінні, які повинні бути задані в скрипті:

  • GW_CONF - ім'я файлу / etc / network / gateways (або інше, якщо він називається інакше)
  • OPENVPN_UPLINK - ім'я конфігурації OpenVPN;
  • CHECK_INTERVAL - періодичність перевірки доступності віддаленої точки через шлюзи, в секундах.

Ім'я конфігурації OPENVPN_UPLINK визначає ім'я конфігураційного файлу OpenVPN і процес openvpn, який повинен бути перезапущений після зміни маршруту. наприклад,

OPENVPN_UPLINK = kiev

відповідає конфігураційний файл

/etc/openvpn/kiev.conf

IP-адреса VPN-сервера, з яким повинен встановлюватися тунель, і на можливість зв'язку з яким постійно перевіряються шлюзи, визначається з цього конфігураційного файлу, з директиви remote.


Скрипт може бути розміщений, наприклад, тут:

/ Usr / local / sbin / change_default_route

Скрипт повинен викликатися автоматично при старті системи. Наприклад, в /etc/rc.local:

nohup / usr / local / sbin / change_default_route &

або в / etc / network / interfaces

iface ... .... up nohup / usr / local / sbin / change_default_route &

Скрипт / usr / local / sbin / change_default_route

#! / Bin / sh ############################################ ################ # # Set the variables berfore starting the script: GW_CONF = / etc / network / gateways OPENVPN_UPLINK = kiev CHECK_INTERVAL = 30 #seconds between gw check ##### ################################################## ###### OPENVPN_UPLINK_CONFIG = / etc / openvpn / $ {OPENVPN_UPLINK} .conf log () {echo "$ @" | logger -t $ 0 -p daemon.info} current_uplink_gateway () {uplink_addresses = `grep ^ remote $ {OPENVPN_UPLINK_CONFIG} | sed s / remote // | tr -d '\ t' | tr '\ n' '|'; echo default `ip route show | grep -v tun | egrep "^ ($ uplink_addresses)" | awk '{print $ 3}' | tail -1} read_gateways () {[-f $ {GW_CONF}] && source $ {GW_CONF} [-f $ {GW_CONF}] || echo file $ {GW_CONF} missing | logger -t $ 0 -p daemon.error [-z "$ GW"] && GW = `current_uplink_gateway`} delete_uplink_gateway () {[-z" $ GW "] && return for remote in $ (grep ^ remote $ {OPENVPN_UPLINK_CONFIG} | sed s / remote // | tr -d '\ t') do ip route delete $ remote via "$ {GW}" done} change_uplink_gateway () {[-z "$ GW"] && return NEWGW = $ 1 uplink_addresses = `grep ^ remote $ {OPENVPN_UPLINK_CONFIG} | sed s / remote // | tr -d '\ t' | tr '\ n' '|'; echo default `for remote in` ip route show | grep -v tun | egrep "^ ($ uplink_addresses)" | awk '{print $ 3}' `do ip route change $ remote via" $ {GW} "done} openvpn_uplink_pid () {# uplink_addresses =` grep ^ remote $ {OPENVPN_UPLINK_CONFIG} | sed s / remote // | tr -d '\ t' | tr '\ n' '|'; echo FINAL_ITEM `# netstat -np 2> / dev / null | grep openvpn | egrep $ uplink_addresses | perl -n -e 's @ /. * $ @@; m @ ([0-9] +) $ @; print $ 1. "\ n"; ' cat /var/run/openvpn.${OPENVPN_UPLINK}} ping_remote_site () {for remote in $ (grep ^ remote $ {OPENVPN_UPLINK_CONFIG} | sed s / remote // | tr -d '\ t') do ping -q - c 1 "$ @" $ remote> & / dev / null && return 0 done return 1} set_default_route () {NEWGW = $ 1 [ "$ GW" == "$ NEWGW"] && return 0 log "Changing default route from $ GW to $ NEWGW "# openvpn_uplink_pid =` openvpn_uplink_pid` /etc/init.d/openvpn stop $ OPENVPN_UPLINK route delete default gw "$ GW" delete_uplink_gateway route add default gw "$ NEWGW" /etc/init.d/openvpn start $ OPENVPN_UPLINK # Restarting openvpn to make him use new gw # [-z "$ openvpn_uplink_pid"] && /etc/init.d/openvpn restart || kill -1 $ openvpn_uplink_pid GW = $ {NEWGW}} while true do read_gateways if [ "$ {DEFAULTGW}" = "$ {GW1}"] then if ping_remote_site -I $ {IP1} then set_default_route $ {GW1} else log " Gateway $ GW1 ($ IP1) is not usable. Trying $ GW2 ($ IP2) "if ping_remote_site -I $ {IP2} then set_default_route $ {GW2} else log" Uplink can not be reach by any path. Waiting "fi fi else if ping_remote_site -I $ {IP2} then set_default_route $ {GW2} else log "Gateway $ GW2 ($ IP2) is not usable. Trying $ GW1 ($ IP1)" if ping_remote_site -I $ {IP1} then set_default_route $ {GW1 } else log "Uplink can not be reach by any path. Waiting" fi fi fi sleep $ {CHECK_INTERVAL} done exit 0

[ правити ] Додаткові питання

[ правити ] Два шлюзу в Інтернет і NAT

Вищеописаний спосіб маршрутизації в залежності від джерела (policy routing) не працюватиме для систем всередині мережі, доступних через NAT.

Іншими словами, якщо за допомогою iptables / netfilter прокидати звернення на якісь порти всередину мережі, принцип «відповіді йдуть по тому каналу, по якому приходять запити» працювати не буде.

Незалежно від того, через який інтерфейс прийшли запити, після того як вони отмаршрутізіровани всередину мережі і оброблені за допомогою трансляції адрес, відповіді будуть йти через маршрут за замовчуванням, що неправильно.

Один із способів вирішення проблеми описаний нижче.

Для вирішення проблем з трансляцією з'єднань всередину мережі, необхідно використовувати схему з проміжним шлюзом:

GW1 GW2 * * | | IP1 | | IP2 [eth1] | | [Eth2] + ------- + | | | gw | | | + ------- + 10.0.3.250 | 10.0.3.254 [eth0] | [Eth0: 1] | | 10.0.3.249 | 10.0.3.253 [eth1] | [Eth1: 1] + ------- + | | | pgw | | | + ------- + | 10.0.3.6 | [Eth0] |

В цьому випадку:

  • на шлюзі gw виконується проброска на один з внутрішніх адрес, в залежності від того, куди прийшов запит;
  • на шлюзі pgw виконується подальша проброска всередину мережі.

[ правити ] Додаткова інформація

[ правити ] Матеріали по OpenVPN на xgu.ru

Як перевірити, що маршрут більше не працює?


Новости
  • Виртуальный хостинг

    Виртуальный хостинг. Возможности сервера распределяются в равной мере между всеми... 
    Читать полностью

  • Редизайн сайта

    Редизайн сайта – это полное либо частичное обновление дизайна существующего сайта.... 
    Читать полностью

  • Консалтинг, услуги контент-менеджера

    Сопровождение любых интернет ресурсов;- Знание HTML и CSS- Поиск и обновление контента;-... 
    Читать полностью

  • Трафик из соцсетей

    Сравнительно дешевый способ по сравнению с поисковым и контекстным видами раскрутки... 
    Читать полностью

  • Поисковая оптимизация

    Поисковая оптимизация (англ. search engine optimization, SEO) — поднятие позиций сайта в результатах... 
    Читать полностью