CrazyOne: на одном инстансе с одним IP поднимаете любой прокси сервер, например 3proxy / dante / etc (HTTP или SOCKS - зависит от того, какие запросы вы выполняете), выбор прокси определяется количеством параллельных запросов. На остальных перенаправьте запросы в прокси сервер. Если запросы, например, делаются через cURL, можно установить переменную среды окружения
http_proxy=http://login:password@IP:port
или передать настройки прокси в параметрах.
если через что-то другое - посмотрите в документации чего-то другого, как направлять запросы через прокси-сервер.
Решение годится если количество параллельных исходящих соединений не превышает несколько десятков тысяч.
Вы уточните хотя бы примерно категорию сайта, для чего пользователю нужен эккаунт (может быть он вообще лишний), какие пользовательские данные доступны с эккаунтом, с какой целью кто-то может ломать пользовательские эккаунты?
tramvay: если на один и тот же запрос прилетают разные ответы, значит скорей всего для corp.example.com неправильно указаны NS-записи либо у вас имеется две отдельные несинхронизованные между собой версии зоны на двух разных серверах. Убедитесь что в родительской зоне есть NS-записи, что они совпадают с записями в самой зоне corp.example.com, что одна из зон является основной а остальныые резервными, настроена синхронизация и они проходят, и что по всем IP указанным в NS-записях проходит nslookup.
nslookup -type=NS corp.example.com 172.16.0.251
и по всем NS-серверам
nslookup hostname.corp.example.ru IP_NS-сервера
чтобы проверить с каким из серверов проблемы.
tramvay: так а что странного? Это значит что hostname.corp.example.ru в зоне corp.example.ru отсутствует. У вас динамические регистрации в этой зоне разрешены? Необходимо либо разрешить динамические регистрации, чтобы клиенты сами регистрировались, либо прописать хосты в этой зоне.
Петр Иванов: нет, это не так. В данному случае будет использоваться маршрут с меньшей метрикой из тех, что соответствуют данному интерфейсу.
Вы бы просто взяли и попробовали.
В таблице маршрутов есть сведения об интерфейсах, в каждом записи есть интерфейс, через который он идет. В случае VPN маршруты должны быть для каждого VPN. Если адрес источника привязан к определенному интерфейсу, маршрут выбирается с учетом интерфейса.
Дмитрий: скорее всего вам так кажется, потому что за вас это сделала CMS. Возможно вы действительно используете скрипты которые шлют напрямую, без локальной очереди, но это значит, что вы приготовили все необходимое для выстрела в ногу. https://yandex.ru/support/mail/troubleshooting/sup... (см. ограничения в почте для домена)
там есть ограничения для отправки через почту для домена. Если при отправке с локальным MTA у вас будет подстилка в виде очереди и отложенной отправки, то без него, упершись в лимит, вы получите сфейлившиеся скрипты и потерянные письма.
Для того, чтобы письмо попало в pdd/biz требуется MTA (exim, postfix. sendmail, etc - он нужен чтобы получить письмо от веб-службы и доставить его по SMTP с авторизацией). Не обязательно при этом поднимать свой SMTP-сервер.
Попадание в блеклисты никак не связано с наличием или отсутствием spf/dkim/ptr, но настроить их придется для нормальной доставляемости писем. Их придется настроить и в случае использование pdd или biz.
Значит порт уже открыт в другом приложении, возможно оно запущено из-под другого пользователя. Возможно вы переключаетесь между двумя пользователями не закрыв приложение?
По netstat -nao можно найти PID процесса, который открыл этот порт, по tasklist /v - посмотреть от какого пользователя запущен процесс.
соответственно, если даже сервер, например, узнает что коннект разорван, когда попытается отправить данные клиенту и будет считать,Ю что соединение завершено - клиент может продолжать висеть и считать что коннект в порядке, пока сам что-то записать не попытается. Т.е. надо в любом случае делать кипэлайв на уровне приложения, если не хотите делать на уровне TCP.
