Переадресация всех запросов TLD на другой сервер
Итак, у меня на коленях возникла чрезвычайная ситуация, и, к сожалению, я плохо подготовлен, чтобы справиться с ней. ИТ-специалист компании-клиента изменил рекорд A для домена, а затем ушел в отпуск. Он единственный, у кого есть доступ, и нет способа изменить его обратно, пока он не появится из джунглей.
Он должен был указать только www.
Запись на новый IP, указывающий на наш сервер, на котором размещается mysite.com
- Однако он изменил *
Запись на новый IP - это означает, что все субдомены теперь фактически мертвы (mail.
, exchange.
, secure.
, так далее). Первоначально *
Запись указывала на другой сервер, который обрабатывал все запросы поддоменов отдельно.
Хотя я не могу получить доступ к элементам управления DNS, у меня есть полный доступ к серверу и панели управления DigitalOcean, где *
Запись сейчас указывает.
Могу ли я что-нибудь сделать с моего конца на сервере DigitalOcean, либо через панель управления DNS (хотя на первый взгляд это не так), либо через virtual.conf
файл (см. ниже) для правильной пересылки любых запросов (т.е. mail.mysite.com
) к правильному IP, который затем должен правильно обработать запрос?
Для справки, сервер CentOS 6.5 x64 работает под управлением nginx. Блок сервера, который в настоящее время обрабатывает входящий запрос, выглядит следующим образом:
server {
listen 80;
server_name mysite.com www.mysite.com;
root /var/www/html/mysite.com/;
error_page 403 404 500 502 503 504 = /server_error.php;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
Спасибо за вашу помощь. Извиняюсь за TL;DR.
2 ответа
Для HTTP, который может работать, но для HTTPS сервер может не иметь правильных сертификатов, а для других протоколов (например, для электронной почты) служба HTTP не будет выполнять эту работу.
Может быть, установить HAProxy в режиме tcp, прослушивая порты, через которые входят соединения, и проксируя правильные порты на "реальном" сервере? Это может работать не совсем правильно для некоторых сервисов, так как очевидным источником соединения будет окно HAProxy.
Лучшим подходом может быть получение доступа к DNS. Должен быть какой-то механизм, который вы можете использовать для получения доступа к учетной записи; никто в компании клиента не настроен как контакт с провайдером DNS? Или вы можете просто сбросить пароль электронной почты парня, а затем запустить электронную почту для сброса пароля?
Редактировать:
Чтобы заставить HAProxy работать в этом случае, вам нужно установить HAProxy - для этого необходимо включить EPEL, если это еще не сделано. затем yum install haproxy
,
редактировать /etc/haproxy/haproxy.cfg
; не уверен, как именно выглядит конфигурация по умолчанию, но вы захотите очистить любую listen
разделы в первую очередь, оставляя global
а также defaults
разделы.
Затем для каждого прослушивающего порта, который нужно отправить на другой сервер, вам понадобится такой раздел (обратите внимание, что если вы добавите порт 80, вам сначала нужно будет остановить службу nginx):
listen port-443
bind :443
mode tcp
balance roundrobin
server realserver 192.0.2.1:443
(где 192.0.2.1
IP-адрес сервера, который должен обрабатывать соединение).
Другой подход заключается в том, чтобы просто позвонить поставщику услуг DNS и объяснить им, что произошло. Я думаю, после некоторого "доказательства", что вы являетесь владельцем домена / делегата или чего-то еще, они могут предоставить вам доступ или изменить его для вас...