Один IP адрес или DNS имя для узла и в локальной сети и по ту сторону OpenVPN туннеля

Question

[sixhundredsixtyfive]

Имеется узел, который обычно находится в локальной подсети (10.0.0.0/24), а иногда подключен через openvpn туннель (тогда он переносится в подсеть VPN 10.0.1.0/24).
Требуется организовать доступность узла по IP адресу из локальной подсети 10.0.0.0/24 или по DNS имени, в независимости от того как узел подключен, локально или по VPN. Думаю ситуация часто встречается но я не смог найти стабильного и быстро работающего готового решения.

VPN сервер установлен на устройстве под управлением openwrt c OpenVPN сервером и dnsmasq демоном который идет по умолчанию, как DHCP и DNS. dnsmasq не хотелось бы менять на какой либо другой DNS сервер, но варианты рассматриваются. По совместительству устройство занимается маршрутизацией.

Собственно вопрос я уже решил способом который ниже опишу. Но меня очень беспокоит сложность решения. Я убежден, что есть более простой и очевидный путь, прошу поделиться мыслями и покритиковать следующие решение.

Решил при помощи iptables путем переадресации всего трафика с IP A.A.A.A из локальной подсети 10.0.0.0/24 на IP B.B.B.B из VPN подсети 10.0.1.0/24 в момент подключения узла по vpn.
Для этого в openvpn.conf был добавлен параметр

script-security 2
learn-address /etc/openvpn/scripts/redirect.sh

который при подключении и отключении клиентов запускает скрипт redirect.sh.
Если подключается узел который был в локальной сети под IP A.A.A.A, и после подключения его IP в VPN подсети стал B.B.B.B, то скрипт делает так:

iptables -t nat -I PREROUTING  -d A.A.A.A -j DNAT --to-destination B.B.B.B # Собственно перенаправление
iptables -I FORWARD -d B.B.B.B -j ACCEPT
ifconfig br-lan:1 A.A.A.A netmask 255.255.255.0 up # Самое интересное! Что бы перенаправление работало для узлов из локальной подсети приходится поднимать виртуальный интерфейс на VPN сервере с IP A.A.A.A. Иначе узлы в локальной подсети не пользуются шлюзом и правила перенаправления для них не работают, и их ARP запросы к IP A.A.A.A обречены...

А при отключении узла от VPN и его переезде обратно в локальную подсеть под IP A.A.A.A скрипт redirect.sh делает вот так:

ifconfig br-lan:1 down # Удаляем интерфейс заглушку, чтобы узел снова смог получить свой A.A.A.A IP и не было конфликта
iptables -t nat -D PREROUTING  -d A.A.A.A -j DNAT --to-destination B.B.B.B # Удаляем перенаправление трафика
iptables -D FORWARD -d B.B.B.B -j ACCEPT

Таким образом узел всегда остается доступен под ip A.A.A.A. Это работает.

Внесем немного конкретики. Узел который перемещается из локальной подсети в VPN подсеть является мобильным устройством, которое подключено либо по WiFi либо по VPN. VPN сервер и маршрутизатор это роутер под управлением openwrt. Остальные узлы в сети работают под Windows, Linux, Android и т.д., то есть решение должно быть универсально и не затрагивать конфигурацию клиентов, все решает только маршрутизатор.

Прошу предложить свои решения. Например решение при помощи одного DNS имени на разные ip, поднятие DDNS сервера, какой нибудь умной маршрутизации и так далее. Приветствуется критика. В первую очередь с точки зрения безопасности и отказоустойчивости и нерациональности.

Answer 1

[lutskyy]

В bind-e для подобного случая используются views.
Т. е. для одной подсети зона отдается, к примеру, как internal, для другой - external.
Не уверен, конечно, что вам такой вариант подойдет.

Comments

[sixhundredsixtyfive]

В моем случае важно не из какой зоны запрос, важно в какой зоне находится цель запроса. Для этого Bind тоже подходит, он может работать как Dynamic DNS и есть пакеты для openwrt. Эта статья - первое с чем я ознакомился, когда начал искать решение http://habrahabr.ru/post/101380/ . Но тут требуется скрипт на клиенте, который бы обновлял данные зоны на сервере. Клиент работает под Android и не очень удобно было бы писать такой скрипт. Тут скорее подойдет скрипт обновления данных зоны, который бы запускался на сервере при подключении нужного клиента по VPN. На мой взгляд это решение красивее, не требует изменения правил файрвола и создания виртуальных интерфейсов. Попробую поставить и настроить Bind. Но опасаюсь длительного обновления кэша dns на клиентах. На начальном этапе я отложил Bind на потом, сейчас понятнее, как его применить. Размышления в слух, спасибо.

[lutskyy]

Для отдельных записей можно выставлять кастомный TTL, скажем, 1 минуту.

[lutskyy]

Для примера: #cat /etc/bind/named.conf acl "internal_networks" { 192.168.0.0/16; 172.16.0.0/12; }; ........ view "internal" { match-clients { !key external; internal_networks; }; recursion yes; zone "myzone.com.ua" { type master; file "pri/myzone.com.ua.internal.zone"; }; }; view "external" { match-clients { key external; }; allow-recursion { "none"; }; recursion no; zone "myzone.com.ua" { type master; file "pri/myzone.com.ua.zone"; }; }; Если у вас клиенты из разных подсетей обращаются к одному днс-у, то он для каждой подсети отдаст свою зону. Файлы зон могут быть идентичными, а могут отличаться (на одну запись). Суть сведется к тому, что клиент из конкретной подсети, получит предназначенные для него записи.

Answer 2

[alz]

Может Вам проще будет OpenVPN смостовать и в обоих случаях будет один и тот же ip

Comments

[sixhundredsixtyfive]

Спасибо, вот это действительно просто, я так и знал что горожу лишние костыли.

[sixhundredsixtyfive]

А с ходу скажите, есть ли способ чтобы OpenVPN выдавал определенному клиенту статический ip а остальным из пула?

[sixhundredsixtyfive]

А вот и не решено, у меня только tun а бриджить его нельзя к сожалению

Answer 3

[artjomtro]

Самый простой способ взять два микротика (cisco, juniper) и из точки А в точку Б кинуть IPSEC в режиме туннеля.
Правда можно и на OPENWRT вроде кинуть SSL так-же.
Одним словом Site-2-Site и забудешь о проблемах.

Либо 2 сетевуху по которой будешь бегать в ВПН, при этом маркировать трафик с какой сетевухи пришел на ту и отдать... ( на мой взгляд костыли.......)