SQL мешает пробиваться через VPN

Привет, ребята. Я только что заменил все Sonicwall в моих 3 местах на UDM Pro. Настроил все правила файрвола (или так мне казалось), но удалённые пользователи не могут получить доступ к нашему серверу SQL Practice CS (это CPA фирма) удалённо.

Наша структура выглядит следующим образом:

Место 1 — главный офис с физическим сервером SQL, пользователи могут подключаться без проблем.

Место 2 — настройка с Site Magic для связи с Site 1 и Site 3. Пользователи не могут подключиться к серверу SQL, получая следующую ошибку: “Успешно установлено соединение с сервером, но во время процесса входа произошла ошибка (поставщик: SSL Provider, ошибка: 0 - Истёк тайм-аут семафора” (прилагается изображение ошибки).

Место 3 — доступ к SQL осуществляется через RDP на терминальном сервере, так как в этом месте всего два пользователя.

Я не помню, чтобы что-то подобное было в старом Sonicwall, и при этом у нас не было такой ошибки.

Любые подсказки были бы очень полезны. Я обратился в поддержку Thompson Reauters, и они ничем помочь не смогли, кроме совета открыть TCP порт 1433 и UDP порт 1434 в файрволе Windows (что я вроде бы сделал).


ИГРАЛ В ИЗМЕНЕНИЕ

Я выяснил, в чем проблема. Похоже, мне нужно было добавить IP сервера в список разрешённых в Security Detection Allow List. Как только я добавил IP, я смог войти.

Спасибо всем, кто дал советы — это было очень полезно. Эта сообщество круто.

Здравствуйте! Спасибо за ваш пост на r/Ubiquiti!

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

Пожалуйста, прочтите и поймите правила в боковой панели, так как посты и комментарии, нарушающие их, будут удалены. Все посты, не связанные с темой, публикуйте в еженедельной ветке «Off topic».

Если заметите распространение дезинформации или других недопустимых действий — сообщите об этом!

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

Я выяснил, в чем причина. Похоже, мне нужно было добавить IP сервера в список разрешенных в Security Detection Allow List. Как только я добавил IP, я смог войти.

Спасибо всем за советы, они были очень полезны. Это сообщество потрясающее.

Если здесь не получишь хорошего ответа, задавайте вопрос в subreddit r/sqlserver. Это точно проблема сети, и хотя я специалист по SQL Server, я не очень разбираюсь в сетевых вопросах, но там есть другие, кто может помочь.

Я забываю, что можно пинговать сервер и подключаться по RDP с сайта 2 и сайта 3 (и я могу подключаться по RDP из дома, и пинговать его).

Проверка SSL-инспекции с помощью IPS/IDS?

О, боже. Practice CS. Самое ужасное программное обеспечение, которое только есть. Ну, ultratax — еще хуже. У меня до сих пор ночные кошмары о ultratax.

SSL должен использовать порт 443, возможно, стоит проверить именно его.

Большое спасибо, я в отчаянии. Как я уже говорил, я ничего не увидел в Sonicwall, что помогло бы понять, почему что-то блокирует трафик, и я почти уверен, что проблема в месте 1, так как я подключён к этой сети через VPN и она блокирует меня (я использую L2TP). Я еще не пробовал OpenVPN или WireGuard, но сомневаюсь, что это что-то изменит.

Я ничего не вижу. Самое первое, что я проверил.

Я руководлю IT с ноября прошлого года, и Practice CS у нас работает без проблем (надеюсь), и это впервые, когда у меня возникла такая проблема, но, похоже, всё работает сейчас, потому что я добавил IP сервера в белый список.

SQL обычно использует TCP 1433. Первое, что стоит проверить — это ACL.

Надеюсь, там не используют ultratax.

Нет, у нас только Practice, QuickBooks, Lacerte и несколько других программ.