Переадресация всех запросов 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 и объяснить им, что произошло. Я думаю, после некоторого "доказательства", что вы являетесь владельцем домена / делегата или чего-то еще, они могут предоставить вам доступ или изменить его для вас...

Источник
Другие вопросы по тегам