Поддельное соединение с базой данных должно быть локальным, а не удаленным

Я пытаюсь подключить одну из наших клиентских программ "как есть" к удаленной базе данных, а не к локальной, они думают, что запрограммировали ее для такой работы, но по какой-то причине происходит сбой программы при попытке подключиться к удаленной базе данных. база данных. У меня нет исходного кода, поэтому я не могу копать намного глубже, и компания не предоставляет никаких обновлений или пользовательских модификаций. Я могу успешно подключиться к базе данных через SqlDbx и HeidiSQL, поэтому я знаю, что сервер настроен правильно.

Вот почему мне нужно найти способ подделать удаленное соединение через порт 1433, чтобы оно выглядело как соединение локальной базы данных с программой. Я думал о редактировании файла hosts, но он, скорее всего, приведет к сбою других программ, если я свяжу localhost с другим IP-адресом, чем 127.0.0.1.

Есть идеи?

ОБНОВИТЬ:

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

  • Это одинаковые версии всех программ
  • TCP/IP работает вместо именованных каналов на локальном хосте и работает с sqlviewers, такими как sqldbx и heidisql
  • Аутентификация работает с sqlviewers
  • Конфигурация - это только поля, необходимые для строки подключения к базе данных.

Осталось только увидеть, что внутри кода есть что-то ограничивающее, и я не могу это контролировать.

3 ответа

Решение

По сути, вы пытаетесь обойти то, что кажется чужой плохой реализацией. Это кажется мне разумным, а иногда и необходимостью. Если эта программа действительно "падает" при попытке подключиться к одной базе данных, но не к другой, в отличие от, о, вы знаете, отображения сообщения об ошибке, это довольно слабо.

У меня есть резервное решение для этого в Linux ("redir") ... но не в Windows; Тем не менее, я нашел это в машине Google:

http://www.vakuumverpackt.de/tcptunnel/

Я только что протестировал его с версией "Cygwin" - не требует установки, у него есть исполняемый файл и DLL, и он "просто работает" на моем ноутбуке с Windows 7. Аккуратный маленький бонус, у него есть --log-to-stdout вариант, который в сочетании с > в файл, записывает байты, извлеченные из потока (может быть интересно чтение). У меня не было под рукой SQL Server, но я проверил его с некоторыми другими службами TCP, и он, кажется, работает должным образом - он прослушивает локальный сокет, а при подключении устанавливает соединение с назначенным сокетом на удаленная машина, и связывает концы труб вместе. Слушая 1433, он "должен" сделать свое дело.

Во всяком случае, это входит в мой инструментарий.

Хотя вы, безусловно, могли бы использовать такие методы, как переадресация порта SSH, чтобы сделать сокет TCP для удаленного прослушивания похожим на локальный, он, вероятно, не поможет.

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

Может быть множество причин, почему программное обеспечение работает нормально при подключении к локальной базе данных, но становится проблематичным с удаленной базой данных, включая, но не ограничиваясь

  • проблемы с версией
  • использование разных протоколов (именованные каналы или TCP/IP)
  • проблемы аутентификации (встроенная аутентификация может работать локально, но не работает для удаленных систем)
  • проблемы с конфигурацией

Вы должны направить свои усилия на диагностику проблемы, а не на сомнительные попытки обхода.

Другие ответы, похоже, предполагают, что вам следует исправить приложение - на самом деле это не всегда возможно, поэтому вот небольшое исправление с помощью пластыря / скрепки / жевательной резинки.

Я не пробовал это с MSSQL, но для MySQL мне удалось настроить TCP-прокси через Nginx. Настройка будет заключаться в развертывании Nginx на том же компьютере, что и ваше приложение, с такой конфигурацией, как в этом ответе SO ; надеюсь, вам поможет, просто изменив порты на 1433:

      stream {
  upstream db {
    server mssql.example.com:1433;
  }

  server {
    listen 1433;
    proxy_pass db;
  }
}

РЕДАКТИРОВАТЬ: Если используется именованные экземпляры и используется служба браузера SQL (которая использует UDP), вы также можете добавить конфигурацию для проксирования UDP: https://dev.to/jordonr/reverse-proxy-ms-sql-with-nginx-3e90

      stream {
    upstream dbtcp {
        server db1:1433;
    }

    upstream dbudp {
        server db1:1434;
    }

    server {
        listen 1433;
        proxy_pass dbtcp;
        proxy_connect_timeout 1s; # detect failure quickly
    }

    server {
        listen 1434 udp;
        proxy_pass dbudp;
        proxy_connect_timeout 1s; # detect failure quickly
    }
}
Другие вопросы по тегам