База данных, которая работает до подключения VPN и отказывает после, редко бывает проблемой учётных данных. Облачные межсетевые экраны сопоставляют адреса источника, а полный туннель заменяет именно тот адрес, с которым они сопоставляли. Разница между тем, что, по вашему мнению, отправляет ноутбук, и тем, что получает сервер, и есть вся ошибка, и её можно измерить за один шаг.

Чем становится адрес источника

В полном туннеле каждый пакет выходит через VPN-шлюз, поэтому сервер видит исходящий адрес шлюза, а не ваше домашнее подключение. Если на пути стоит прямой прокси, приходит его адрес. Оба варианта — законные источники, и ни один из них не является адресом из вашего исходного правила.

Правила межсетевого экрана Azure SQL на уровне сервера и на уровне базы данных сопоставляют адрес клиента, который достигает логического сервера, а после полного туннеля это исходящий адрес. Группа безопасности AWS, разрешающая один адрес, ведёт себя так же. Пакет отбрасывается до аутентификации, поэтому возвращаемая ошибка выглядит как сбой сети, а не как проблема с правами. Именно поэтому люди начинают сбрасывать пароли.

Где решается список разрешённых

Читайте правило, соответствующее сбойному пути, а не то, которое вы помните как созданное. Отметьте его область, порт, протокол и то, оценивается ли оно до какой-либо проверки личности.

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

Три исправления, три уровня

Каждый вариант ниже исправляет поток по своей причине, а неверный выбор даёт соединение, которое работает до следующей смены шлюза.

RepairLayer it changesWhat it does not fix
Add the egress address to the ruleSource address matchingNothing about routing, and it breaks when the egress moves
Use a private endpointWhether the service is reached privatelyA client that still resolves the public name
Add a split-tunnel exceptionWhich flows bypass the tunnelAn expired credential or a wrong password

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

Почему управляемая платформа не может войти в туннель

Платформы приложений вроде Heroku, AppHarbor или CloudBees запускают ваш код в среде без устройства tun или tap и без прав создать его. Их модель входящего трафика — HTTP, а не произвольный слушающий сокет. Сборочный пакет, поставляющий двоичный файл VPN, всё равно не имеет куда поместить интерфейс. Работоспособные схемы — статический исходящий адрес, который база данных может разрешить, продукт частного подключения от платформы или прокси в DMZ, доступный по HTTPS.

Этот прокси — путь доступа с собственной аутентификацией и журналированием. Он не делает платформу участником вашего VPN, и такое описание порождает правила, которые никто не может проверить.

Проверьте со стороны сбойного клиента

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

Пересматривайте эти правила при каждом изменении туннеля. Заменённый шлюз или новый исходящий диапазон ломают путь без каких-либо изменений в конфигурации приложения.

Похожие статьи