Допустим есть сервер, на linux, который к клиентским серверам (их пару десятков)подключается периодически по порту 1433, и забирает оттуда из sql определённые данные. Но то что на этих серверах порт 1433 смотрит наружу, не устраивает. В качестве решения было предложено поднять на сервере OpenVPN, на клиентских само собой - клиенты OpenVPN, и подключаться по локальным адресам. Но вот загвоздка - у этих удалённых серверов локальные IP могут совпадать. Повлиять на это мы никак не можем. Можно ли как-то смаршрутизировать пакеты, чтобы не возникло путаницы с адресами? Или это в принципе невозможно, и нужно искать другой путь?
Про то что на удалённых серверах можно добавить в белый список сервер на линуксе, я тоже думал, но пока хотят именно VPN
Но вот загвоздка - у этих удалённых серверов локальные IP могут совпадать. Повлиять на это мы никак не можем.
Можете повлиять. Ваш OpenVPN-сервер выдаст им разные адреса (серые) на tun-интерфейсы. Вот и обращайтесь к серверам по этим разным адресам. Какие там у них адреса на lan-интерфейсах вам должно быть безразлично, если только не требуется доступ в локальную сеть за этими серверами.
hint000 я так понимаю, что есть несколько разных подсетей, куда идет коннект по OpenVPN, а вот сервера в тех локалках могут иметь совпадающие частные адреса типа 192.168.1.2 или чего-то в этом роде, и становится непонятно, в какой tun-интерфейс отправлять пакет до такого айпи. При этом наехать и переделать адресацию ни в одной из этих сетей нельзя.
Максим Гришин, нарисовал схему с двумя клиентами с совпадающими адресами. Я говорю о том, что просто не нужно стучаться по этим адресам. Сервера доступны по тем адресам, которые назначаются при соединении OpenVPN. На моей схеме это 10.3.3.44 и 10.3.3.55. Они разные и их достаточно для доступа к этим хостам. Не к локальным сетям за этими хостами, а только к хостам.
Я так понимаю схему:
- Есть один сервер, который должен консолидировать какие-то данные
- Есть несколько SQL-серверов, находящихся в разных LAN'ах
- Есть несколько VPN-серверов, к которым можно подключаться, получая доступы до SQL-серверов
- Адресация удаленных LAN не находится под контролем ОПа, как следствие, разные логически сервера могут иметь одинаковые частные IP-адреса.
Тогда правильнее всего будет сделать так:
- Создать несколько разных подключений OpenVPN от консолидатора в сети SQL-серверов;
- Поднимать их по одному за раз, обходя проблему разных IP-адресов целевых серверов;
- Пока поднято одно соединение, обрабатывать консолидатором данные с тех серверов, которые расположены за ним, для этого организовать какую-нибудь структуру данных;
- После завершения обработки опускать соединение и переходить к следующему по порядку.
My_Second_Nickname, так, а если какой-то из серверов не соединился по VPN? И ещё, клиентом VPN будет выступать сам sql-сервер? Если да, там проще, реально настроить авторизацию по сертификатам/пользователям и каждому выдать один IP-адрес, но нужно, чтобы SQL на VPN-клиентах слушал 0.0.0.0, иначе на VPNский адрес не получится соединиться, чтобы забрать данные. Если нет, будет задница.
Максим Гришин, что значит не соединится? Это будет обязательная процедура, на автозапуске. Клиентом VPN будет выступать машина, на которой крутится MSSQL сервер. Там винда, обычно Server 2008 r2, либо 2012. Поставить OpenVPN, закинуть конфиги с сертификатами в нужное место - с этим даже те у кого лапки справятся. Вопрос, нужны ли все эти сложности
да вот я реально смотрю на всю это котовасию, и думаю что проще по белым спискам сделать. Те, у кого есть какой-никакой NAT или хотябы файрволл - настроят белые списки. У кого этого нет... ну тут уж явно надо думать не о том что 1433 наружу торчит.
Сложный
