Мне нужно подключиться с веб-сервера Debian GNU / Linux к базе данных SQL Server, которая размещена на машине Windows в локальной сети организации.
Лицо, отвечающее за сервер базы данных, и лицо, отвечающее за брандмауэр, оба заявили, что они настроили все, чтобы я мог подключиться: входящее соединение разрешено на сервере базы данных, входящее соединение разрешено и перенаправление портов включено (1433 TCP и 1434 UDP) на межсетевом экране. Они разрешили IP-адрес веб-сервера, но я все еще не могу подключиться к базе данных. Я даже не могу инициировать TCP-соединение с портом 1433 ни с помощью telnet, ни с помощью nc. Я запустил nmap на брандмауэре, но он не сообщает об открытых портах. Для тестирования человек, управляющий машиной базы данных, попросил человека, управляющего брандмауэром, разрешить его собственный IP-адрес, и он может нормально подключиться. Я также попросил хостинговую компанию веб-серверов проверить исходящее соединение с этими портами, и они явно разрешили это.
Правильно ли я думаю, что прежде чем искать проблему с FreeTDS, я должен иметь возможность установить необработанное TCP-соединение с портом 1433?
Возможно ли, что SQL Server делает что-то необычное со своей сетевой реализацией и что мои тесты с использованием telnet, nmap или nc в данном случае не актуальны?
Возможно ли, что Nmap не сообщает о портах как об открытых, когда они действительно открыты?
Telnet всегда был для меня канарейкой в угольной шахте в отношении подключения. Вы правы в том, что у вас должна быть возможность подключиться к порту через Telnet. Оттуда вы мало что можете сделать, но это скажет вам, по крайней мере, все ли движущиеся части на месте, чтобы вы могли общаться через этот порт. Удачи!
Если кто-то может подключиться с помощью собственных инструментов SQL Server через порт 1433 (вам нужен только UDP 1434, если вы используете именованный экземпляр), а вы не можете с сервера Linux, это брандмауэр. Я все время использую telnet для проверки возможности подключения.