Работаю в компании, которая до сих пор использует в своих филиалах MS SQL Server 2000. Уж не знаю, какие цели они преследуют этим, но это и не важно, так как система работает стабильно и цели и поставленные задачи выполняет.
Начнем по порядку. Прошу под хабракат.
Задачи цели решения
MS SQL Server 2000 выполняет роль сервера баз данных, сбора и хранения информации и обмена ею с Москвой и подчиненными нами представительствами, которые находятся от нашего филиала на расстоянии 100 и более км., сами же мы находимся от Москвы на расстоянии более 2500 км., это так для общей картины.
При появлении в нашем филиале, а так же в подчиненных представительствах нормального и стабильного доступа в Интернет, было решено завязывать с пересылкой файлов по почте для обмена данными. Для этого решено было подключить на то время два ADSL модема у меня и в представительстве через сервис DynDNS для обмена данными.
Сказано - сделано
Регистрируем на DynDNS.org две free учетки, получаем хост, прописываем в модемах в секции DDNS, настраиваем в модемах виртуальные серверы и проброс на порт 3389 (RDP), для более удобной работы. На этом, при подключение к удаленному хосту, через Linux rdesktop, получал подключенный диск своей Linux машины и спокойно обменивался файлами.
Файлы представляют собой базы данных Access, которые формируются на удаленном MS SQL Server 2000, и посредствам программ написанных Москвой, заливаются на мой MS SQL Server 2000.
После таких не хитрых манипуляций, работа пошла быстрее, но не устраивало одно, каждый день начинался с одного:
Утро, пришел на работу сформировал файл у себя, подключился, сформировал файл на удаленном сервере, перекинул свой файл на удаленный перекинул с удаленного файл на свой, залили спец программами на MS SQL Server"а. Утомило.
Было решено объединить два MS SQL Server"а по средствам DynDNS с пробросом портов в модемах TCP 1433-1434 и UDP 1433-1434.
Сказано сделано
Заходим в ADSL модем в секции виртуальные серверы, пробрасываем порты TCP UDP. Подключаемся спец.программами к удаленному серверу и обмениваемся данными:
MS SQL Server филиала <-> MS SQL Server представительства. Ура сказали бы все, так и я сказал, но на утро произошло самое страшное и непонятное. Интрига?
На следующее утро после того как было настроен автоматический обмен данными ночью между SQL серверами, получил два мертвых MS Windows 2003. Что значит мертвых:
мой MS Windows 2003 на котором стоял филиальский SQL сервер, отвалился от домена в сети, не давал по сети заходит на шару и после ребута не подключался к домену.
удаленный MS Windows 2003 на котором стоял SQL сервер представительства хоть и как то отвечал на подключения, но вел себя крайне неадекватно, то не даст подключиться по RDP, то падал IIS, который был просто необходим в представительстве.
Благо в филиале для таких случаев лежал backup своего MS Windows 2003, а базы SQL бекапились на SLES сервер. Работа филиальского сервера была восстановлена за небольшой промежуток времени. Удаленный же напомню 100 км. ходу, был проверен на вирусы, которых не было выявлено! После проверки сервера вручную, что в нем не так, было найдено то, что на сервере сменился владелец диска C: и остальных дисках на неопределенного. Ради интереса попробовал вернуть на всех дисках владельца, Администратор.
После нескольких часов изменения атрибутов, сервер стал работать нормально. Со спокойной душой проверил обмен и инфу в базах данных, все было на месте.
На следующее утро. Такая же картина!!! Ужас.
Решил испробовать метод восстановления владельца на филиальском сервера потому, как владелец был не определен. Восстановил у себя, Восстановил на удаленном все заработало. И тут встал вопрос из за чего это происходит. Ответ был найден на следующее утро, когда перед этим и у себя и удаленно убрал проброс портов SQL Server, напомню TCP UDP 1433-1434. Утром сервера работали без ошибок.
Баг? Взлом? Уязвимость? Что? Мучило меня долго, пока я перекидывал файлы между компами старым способом. И наконец в филиале появился оптоволоконный инет с белым IP. Ну теперь думаю все будет отлично. Хотя в представительстве так и оставался динамический IP с пробросом на 3389 (RDP).
Решение задачи объединения SQL серверов с использованием OpenSUSE, DynDNS
Задача осталась такая же, объединить два SQL сервера.
Сказано сделано
Сначала была простая цель, через OpenSUSE выполняющий роль Роутера прокинуть порт на SQL сервер сети в фаерволе пишем:
FW_FORWARD_MASQ="0/0,ip_sql_server,tcp,1433,1434, наш_белый_IP 0/0,ip_sql_server,udp,1433,1434, наш_белый_IP"
Открываем порты 1433-1434
Это значит, что трафик идущий на машину с белым ip по портам 1433 1434 перенаправляется на машину c SQL сервер внутренней сети.
С удаленного компьютера пробуем подключиться к SQL нашей сети подключение прошло успешно. Ура! Но остается одно, как моим SQL сервером подключиться к удаленному серверу. Принимаю решение все же пробросить порт SQL на ADSL модеме удаленного компа. И по средствам DynDNS подключиться от себя к нему. Пробрасываю, подключаюсь, обмениваюсь данными. Ну что ж, ждем утра.
Утро. Ндэ. На этот раз не так все плохо!
1. на моем сервере в корне диска C: лежат файлы:
xp5.exe
server.exe
hex.exe
и куча непонятных dll"ок
на сервере кто то был! :) Так же в job SQL server"а появились задачи типа a.exe server.exe и так далее и что интересно не определяться это все антивирусом.
2. такая же история на удаленном сервере. Но еще к тому же висит ADSL модем, не могу убрать проброс.
Простая чистка вручную удаление этих файлов, убиваем процессы, чистим SQL job.
Подключаюсь по telnet, сбрасываю модем полностью.
Reboot.
В общем, решение этой задачи лежало всегда на виду.
Кульминация
Поднимаем на OpenSUSE vpn server pptpd (не стал замарачиваться с openvpn) в фаерволе пишем:
FW_FORWARD="net_vpn,ip_server_sql_local ip_server_sql_local,net_vpn"
Удаленный сервер подключается к vpn серверу получает IP и в моей сети видит только sql сервер. Обмен проходит нормально и спокойное УТРО.
Вот собственно и все. Работает как часы.
Ссылки по теме
