Как настроить шлюз по умолчанию в openvpn

Настройка VPN-сервера с функцией интернет-шлюза (анонимный вебсерфинг)

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

В качестве VPN-сервера будет использоваться виртуальный сервер на Debian с OpenVPN. Стоимость виртуального сервера в нынешнее время крайне невысока. Даже домашние пользователи могут позволить себе поднять VPN-сервер за 4 евро в месяц и вкусить все прелести анонимного вебсерфинга или создать частную защищенную сеть over internet.

Базовая настройка OpenVPN приведена здесь. Отличаться будут только файлы конфигурации сервера и клиента.

port 1194
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push «redirect-gateway def1 bypass-dhcp»
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0
cipher AES-256-GCM
;compress lz4-v2 #v.2.4
;push «compress lz4-v2»
;comp-lzo
;max-clients 2
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
verb 3
explicit-exit-notify 1

Включаем форвардинг.
Настраиваем IPTABLES. В файл /etc/rc.local добавить:

iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m state —state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Примечание: в новых версиях Debian отсутствует файл rc.local. Чтобы не париться с его добавлением и настройкой служб, можно выполнить вышеприведенные команды IPTABLES, сохранить их:

iptables-save > /etc/iptables/rules.conf

и добавить в конец файла /etc/network/interfaces

pre-up iptables-restore

Настройка VPN-сервера с функцией интернет-шлюза (анонимный вебсерфинг) : Один комментарий

А где мы берем вот это?
Исходные данные: ISO-образ Acronis Backup Boot. Программы от Acronis весьма не дешевы

OpenVPN-сеть

OpenVPN -сеть создается для множественных клиентских подключений к ИКС. Добавить ее можно в меню Сеть > Провайдеры и сети. Для этого выполните следующие действия:

1. Создайте сертификаты для OpenVPN. Добавьте сертификат CA, а затем создайте в нем конечный сертификат, используя шаблон «VPN-сервер».
2. Нажмите кнопку «Добавить» и выберите «Сети > OpenVPN-сеть».
3. На вкладке «Основные настройки» введите название сети.
4. Укажите диапазон адресов в виде IP-адрес/префикс либо адрес:маска. Адреса из данного диапазона будут выдаваться пользователям, которые подключаются через OpenVPN.
5. При необходимости измените протокол. По умолчанию установлен протокол UDP.
6. Укажите порт сервера.
7. При необходимости можно включить проверку логина и пароля клиента, установив соответствующий флаг.
8. Если проверка логина и пароля клиента включена, то можно также включить использование двухфакторной аутентификации.
9. Если требуется, установите флаги:
   • «Разрешить трафик между клиентами» — предоставляет возможность взаимодействия (прохождения трафика) между OpenVPN-клиентами. Например, Клиент 1, подключенный к OpenVPN-сети, будет иметь доступ к хосту Клиента 2, подключенного к этой же OpenVPN-сети;
   • «Передать клиенту маршрут по умолчанию» — направляет весь трафик с устройства клиента через OpenVPN-сеть ИКС.
10. На вкладке можно выбрать сети, маршруты до которых будут передаваться клиентам, а также указать DNS-серверы, которые будут передаваться клиентам.
11. При необходимости установите флаги:
    • «Разрешить управление ИКС через веб» — позволяет подключаться к веб-интерфейсу ИКС из данной сети;
    • «Разрешить управление ИКС через SSH » — позволяет подключаться по SSH из данной сети.
12. На вкладке «Шифрование и сертификаты» выберите алгоритм шифрования и алгоритм хеширования.
13. При необходимости установите флаги :
    • «Включить сжатие LZO »;
    • «Включить TLS Auth».

Введите link- MTU (в байтах). Это объем передаваемых данных, при превышении которого информация будет разбиваться на небольшие блоки перед отправкой по сети. По умолчанию установлено значение 1500 байт.

Укажите корневой сертификат и сертификат сервера. При создании корневого сертификата и конечного сертификата сервера необходимо указать следующие параметры:

• Алгоритм: SHA 256
• Тип шифрования: RSA

Нажмите «Добавить» — новая сеть появится в списке.

Для более детальных настроек OpenVPN-сети откройте специальный модуль в меню Сеть > VPN либо нажмите кнопку «Настройки авторизации». Чтобы скачать сертификаты на компьютер, нажмите «Выгрузить сертификаты» и выберите, для какой версии OpenVPN-клиента выгрузить сертификаты (2.4* либо 2.5*). Внимание! Чтобы увеличить скорость при использовании версии 2.5.* и установленном драйвере wintun, рекомендуется вручную добавить в конфигурационный файл клиента опцию windows-driver wintun . Если вы подключаетесь по OpenVPN не к провайдеру по умолчанию, подключение будет возможно только при выборе Протокола TCP.

В модуле «VPN» укажите, какие пользователи могут подключаться к ИКС по OpenVPN.

Индивидуальный модуль OpenVPN-сети

Для перехода в индивидуальный модуль OpenVPN-сети нажмите на нее, а затем — на кнопку «Подробнее. ».

В данном модуле можно посмотреть состояние сети и журнал.

Состояние

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

Журнал

На данной вкладке отображается сводка всех системных сообщений модуля с указанием даты и времени.

Журнал является стандартным элементом веб-интерфейса ИКС.

Настройка openvpn

Привет! Есть сервер pfsense, установлен в качестве шлюза.
WAN — внешний IP
LAN 192.168.1.0/24
И сеть для VPN 192.168.50.1
Настроен openvpn. При подключении клиент получает IP адрес 192.168.50.6 и всё, ни шлюза, ни DNS.
Почему ip с 6го, а не со 2? Почему маршруты в клиенте 192.168.50.5, а не 50.1? В Где прописать нужные настройки? В интернете видел «push route 192.168.1.1 255.255.255.0» но это же не маршрут, это сеть. Она и так непосредственно подключена к pfsense. Вообщем я запутался.
А еще лучше как настроить его так, что бы клиенты openvpn получали IP с DHCP внутреннего сервера (192.168.1.0/24)?

pigbrother
отредактировано

Настроен openvpn. Все же, очевидно, не настроен.
Ответы на ваши вопросы — в подробнейших мануалах:
напрмер:
https://forum.pfsense.org/index.php/topic,59081.0.html
https://doc.pfsense.org/index.php/OpenVPN_Site-to-Site_PKI_%28SSL%29
https://forum.pfsense.org/index.php?topic=99694.0 еще лучше как настроить его так, что бы клиенты openvpn получали IP с DHCP внутреннего сервера (192.168.1.0/24)
С этим, вероятно, сложнее.

Amigo83
отредактировано

Спасибо конечно за ссылки, я их видел. В них в основном site to site vpn. А у меня клиент сервер. Я не могу понять логику работы этой приблуды. Например push route, iroute для меня загадки. Так же как и вопросы из первого поста, и логика выдачи DHCP сервером pfsense сетевых настроек. Также я не понимаю значения вкладок, client и client specific override. В которых тоже нужно вписывать подсели туннелей и route push.

timon12
отредактировано

https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server
http://shop.nativepc.ru/content/75-pfsense-2-cookbook-4
http://www.packetwatch.net/documents/guides/2012050801.php

Так же как и вопросы из первого поста, и логика выдачи DHCP сервером pfsense сетевых настроек.

https://forum.pfsense.org/index.php?topic=46984.0
https://www.reddit.com/r/PFSENSE/comments/3hql33/configuring_openvpn_bridge_with_local_dhcp/
http://bertdotself.com/configuring-an-openvpn-multisite-vpn-bridge-using-public-key-infrastructure-pki/ Только вот зачем DHCP из внутренней сети для мобильных клиентов?

Amigo83
отредактировано

Для получения доступа ко внутренним ресурсам, так обычно работает vpn…
А кто нибудь таки может сказать, почему IP выдается с 6-го адреса, DHCP на 5-ом, шлюз на 1ом и не работает, и что сделать что бы шлюз хотя бы выдавался?
По ссылкам этого нет.

timon12
отредактировано

Для получения доступа ко внутренним ресурсам, так обычно работает vpn…

Для этого не обязательно настраиват DHCP для openvpn, делать из openvpn новый интерфейс и объеденять с внутренней сетью, и плюс при таких настройках вы не сможете изолировать мобильных клиентов друг от друга (и такое обычно настраивают при доступе через vpn)
Кагбэ дело за вами, как настраивать)))))

Amigo83
отредактировано

А зачем их изолировать? Сотрудники работают удаленно, все что им нужно это доступ во внутреннюю корпоративную сеть. Сейчас подключаются через cisco, ее настроить было на порядок проще.. Настроено всё по мануалам… Почему шлюза нет?

timon12
отредактировано
Настройки в студию!
И какой было смысл слезать с Cisco, если там на порядок легче настройки?
pigbrother
отредактировано

На все ваши вопросы есть ответы в приведенных ссылках. Например: почему IP выдается с 6-го адреса Потому что для совместимости со старыми клиентами Windows используется топология виртуальной сети net30. Хотите адресацию 1-2-3-4 — используйте топологию subnet. Делается это одной строкой\галкой в настройках, и это описано в приведенных ссылках.

werter
отредактировано

Настройки в студию!
И какой было смысл слезать с Cisco, если там на порядок легче настройки?

Шта ?? Вы это только не говорите никому.
timon12
отредактировано
Так это не мои слова)))))) @Amigo83:

А зачем их изолировать? Сотрудники работают удаленно, все что им нужно это доступ во внутреннюю корпоративную сеть. Сейчас подключаются через cisco, ее настроить было на порядок проще.. Настроено всё по мануалам… Почему шлюза нет?

werter
отредактировано
Аааа, прошу пардону )
pigbrother
отредактировано
Присоединюсь.
Более наглядной\прозрачной настройки OpenVPN чем в pfSense придумать сложно.
werter
отредактировано

А кто нибудь таки может сказать, почему IP выдается с 6-го адреса, DHCP на 5-ом, шлюз на 1ом и не работает, и что сделать что бы шлюз хотя бы выдавался?

Сдается мне , что человек , к-ый не знает об адресации /30 (тип net30) openvpn врядли может бросаться фразами типа :

Сейчас подключаются через cisco, ее настроить было на порядок проще..

Amigo83
отредактировано

Что такое подсеть /30 я в курсе, с масками знаком. А вот что такое net30 не знает даже гугл. https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=net30

pigbrother
отредактировано

_Сдается мне , что человек , к-ый не знает об адресации /30 (тип net30) openvpn врядли может бросаться фразами типа : Quote Сейчас подключаются через cisco, ее настроить было на порядок проще.._
Ну почему же. Если в интернете найти похожую конфигурацию и copy\paste в свою — это вполне возможно. Сам так делал :). С pfSense такое проделать несколько сложнее — все в GUI и настройки надо переносить вдумчиво. Что такое подсеть /30 я в курсе, с масками знаком. А вот что такое net30 не знает даже гугл. Знает. Кстати — в первой приведенной мною ссылке на инструкцию от rubic: В режиме PKI по умолчанию используется топология net30. Создана она для обхода ограничения TAP-Win32 драйвера Microsoft в режиме эмуляции TUN интерфейса….
. Там же: Если вы не собираетесь подключать Windows клиентов к OpenVPN серверу на pfSense, то можно использовать новую топологию subnet. В ней, если в настройках сервера в Tunnel Network стоит 10.0.8.0/24, то сервер получает адрес 10.0.8.1, а клиенты последовательно адреса 10.0.8.2, 10.0.8.3, …, 10.0.8.254. Одним словом, subnet.

timon12
отредактировано

2 Amigo83
А вы гуглу вопрос перефразируйте, может он вас не понял))))
https://community.openvpn.net/openvpn/wiki/Topology

Amigo83
отредактировано

Если вы не собираетесь подключать Windows клиентов к OpenVPN серверу на pfSense, то можно использовать новую топологию subnet. В ней, если в настройках сервера в Tunnel Network стоит 10.0.8.0/24, то сервер получает адрес 10.0.8.1, а клиенты последовательно адреса 10.0.8.2, 10.0.8.3, …, 10.0.8.254. Одним словом, subnet

Как раз таки windows клиентов я и собираюсь подключать. А чем плоха subnet? Я не провайдер, мне не нужна изоляция сетей. В такой конфигурации таблица маршрутизации правильная, пингуется и шлюз, 192.168.50.1 и lan интерфейс pfsense 192.168.1.150, вот только трафик не идёт на другие адреса 192.168.1.0/24

timon12
отредактировано

Настройки в студию!

Amigo83
отредактировано

dev ovpns1
verb 1
dev-type tun
tun-ipv6
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher AES-256-CBC
auth SHA1
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 217.67..
tls-server
server 192.168.50.0 255.255.255.0
client-config-dir /var/etc/openvpn-csc
username-as-common-name
auth-user-pass-verify «/usr/local/sbin/ovpn_auth_verify user ‘Local Database’ false server1» via-env
tls-verify «/usr/local/sbin/ovpn_auth_verify tls ‘VPN+Server+Cert’ 1 »
lport 1194
management /var/etc/openvpn/server1.sock unix
max-clients 20
push «route 192.168.1.0 255.255.255.0»
push «dhcp-option DOMAIN it.local»
push «dhcp-option DNS 192.168.1.241»
client-to-client
ca /var/etc/openvpn/server1.ca
cert /var/etc/openvpn/server1.cert
key /var/etc/openvpn/server1.key
dh /etc/dh-parameters.1024
tls-auth /var/etc/openvpn/server1.tls-auth 0
comp-lzo adaptive
passtos
persist-remote-ip
float
topology subnet
push “route 192.168.1.0 255.255.255.0” В фаерволе скорее всего проблема..

werter
отредактировано
Зачем два push «route 192.168.1.0 255.255.255.0» ?
Amigo83
отредактировано

Для тестов 8) Это я уберу На фаеволе, в разделе openvpn трафик разрешен any to any, не пойму почему не ходит между 192.168.50.0/24 и 192.168.1.0/24 А где можно посмотреть лог фаервола?

timon12
отредактировано
Status-> System logs->Firewall
Amigo83
отредактировано

Если смотреть на LAN интерфейсе tcpdump, то я вижу запросы, но нет ответов(( 192.168.60.2 — IP клиента openvpn [2.2.6-RELEASE][admin@pfSense.localdomain]/var/log: tcpdump -i igb0 -n host 192.168.60.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 65535 bytes
capability mode sandbox enabled
14:49:36.521499 IP 192.168.60.2 > 192.168.1.241: ICMP echo request, id 1, seq 700, length 40
14:49:41.473601 IP 192.168.60.2 > 192.168.1.241: ICMP echo request, id 1, seq 701, length 40
14:49:46.274560 IP 192.168.60.2 > 192.168.1.241: ICMP echo request, id 1, seq 702, length 40
14:49:51.274557 IP 192.168.60.2 > 192.168.1.241: ICMP echo request, id 1, seq 703, length 40
14:52:56.212559 IP 192.168.60.2.53784 > 192.168.1.241.53: 1+ PTR? 241.1.168.192.in-addr.arpa. (44)
14:52:58.213252 IP 192.168.60.2.53785 > 192.168.1.241.53: 2+ A? itbs01. (26)
14:53:00.212521 IP 192.168.60.2.53786 > 192.168.1.241.53: 3+ AAAA? itbs01. (26)

Amigo83
отредактировано

Вообщем разобрался я… Все гениальное просто, как всегда.
В данный момент разбираюсь с наследством предыдущего администратора.
Не работало по той причине, что есть два шлюза, cisco и pfsense.
Так во по дефолту стоит шлюз cisco.. Надо было поменять шлюз на pfsense.

Два шлюза в Интернет и OpenVPN

На странице описывается как с помощью 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=$

Для того чтобы избежать случайного внутреннего противоречия в настройках, стоит использовать эти адреса и при настройке интерфейсов. Например, для 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

Такая схема маршрутизации не будет правильно работать с 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/$.conf log() < echo "$@" | logger -t $0 -p daemon.info >current_uplink_gateway() < uplink_addresses=`grep ^remote $| sed s/remote// | tr -d ' \t' | tr '\n' '|';echo default ` ip route show | grep -v tun | egrep "^($uplink_addresses)" | awk '' | tail -1 > read_gateways() < [ -f $] && source $ [ -f $ ] || echo file $ missing | logger -t $0 -p daemon.error [ -z "$GW" ] && GW=`current_uplink_gateway` > delete_uplink_gateway() < [ -z "$GW" ] && return for remote in $(grep ^remote $| sed s/remote// | tr -d ' \t') do ip route delete $remote via "$" done > change_uplink_gateway() < [ -z "$GW" ] && return NEWGW=$1 uplink_addresses=`grep ^remote $| sed s/remote// | tr -d ' \t' | tr '\n' '|';echo default ` for remote in `ip route show | grep -v tun | egrep "^($uplink_addresses)" | awk ''` do ip route change $remote via "$" done > openvpn_uplink_pid() < # uplink_addresses=`grep ^remote $| 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.$ > ping_remote_site() < for remote in $(grep ^remote $| 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=$> while true do read_gateways if [ "$" = "$" ] then if ping_remote_site -I $ then set_default_route $ else log "Gateway $GW1 ($IP1) is not usable. Trying $GW2 ($IP2)" if ping_remote_site -I $ then set_default_route $ else log "Uplink can't be reach by any path. Waiting" fi fi else if ping_remote_site -I $ then set_default_route $ else log "Gateway $GW2 ($IP2) is not usable. Trying $GW1 ($IP1)" if ping_remote_site -I $ then set_default_route $ else log "Uplink can't be reach by any path. Waiting" fi fi fi sleep $ 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 выполняется дальнейшая проброска внутрь сети.

[править] Дополнительная информация

• Default gateway
• Linux Advanced Routing & Traffic Control HOWTO — перевод руководства по iproute2 и управлению трафиком в Линукс

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

• OpenVPN
• Два шлюза в Интернет и OpenVPN
• OpenVPN в Windows
• OpenVPN Bridge ­— передача тегированного трафика через VPN
• OpenVPN Proxy ARP