Encaminhar todas as solicitações de TLD para outro servidor

Question

Então, uma emergência caiu no meu colo e, infelizmente, estou mal equipada para lidar com isso. Uma tecnologia de TI para a empresa de um cliente alterou o registro A para um domínio e saiu de férias. Ele é o único que tem acesso, e não há como mudar de volta até que ele reaparece da selva.

Ele deveria apontar apenas o registro www. A para um novo IP, apontando para o nosso servidor que hospeda mysite.com - no entanto, ele alterou o registro * A para IP novo - significa que todos os subdomínios agora estão efetivamente mortos ( mail. , exchange. , secure. , etc). Originalmente, o registro * A apontava para outro servidor que lidava com todas as solicitações de subdomínio separadamente.

Embora eu não possa acessar os controles de DNS, eu tenho acesso completo ao servidor DigitalOcean e ao painel de controle para onde o * A está apontando agora.

Existe algo que eu possa fazer do meu lado no servidor DigitalOcean, seja através do painel de controle do DNS (embora não pareça tão rápido) ou através do arquivo virtual.conf (veja abaixo) para encaminhar corretamente qualquer solicitações (ou seja, mail.mysite.com ) para o IP correto que deve, então, manipular a solicitação corretamente?

Para referência, o servidor está executando o nginx do CentOS 6.5 x64. O bloco do servidor que está atualmente manipulando a solicitação recebida é o seguinte:

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;
    }
}

Obrigado pela sua ajuda. Desculpas pelo TL; DR.

    

Answer 1

Para HTTP que pode funcionar, mas para HTTPS o servidor pode não ter os certificados corretos e para outros protocolos (como para email) o serviço HTTP não fará o trabalho.

Talvez ponha em pé o HAProxy no modo tcp, ouvindo nas portas em que as conexões entram e fazendo proxy para as portas corretas no servidor "real"? Isso pode não funcionar corretamente para alguns serviços, já que a origem aparente da conexão será a caixa HAProxy.

Uma abordagem melhor pode ser obter acesso ao DNS. Deve haver algum mecanismo que você possa usar para obter acesso à conta; não há mais ninguém na empresa do cliente configurado como contato com o provedor de DNS? Ou você pode simplesmente redefinir a senha de e-mail do cara e depois disparar um e-mail de redefinição de senha?

Editar :

Para que o HAProxy funcione para este caso, você vai querer instalar o HAProxy - isso requer que EPEL seja ativado , se já não é. Então yum install haproxy .

Edite /etc/haproxy/haproxy.cfg ; Não sei exatamente como é a configuração padrão, mas você deve limpar as seções listen primeiro, deixando as seções global e defaults .

Então, para cada porta de escuta que você precisa enviar para o outro servidor, você vai querer uma seção como essa (note que se você adicionar a porta 80, você precisará parar o serviço nginx primeiro):

listen port-443
    bind :443
    mode tcp
    balance roundrobin
    server realserver 192.0.2.1:443

(onde 192.0.2.1 é o IP do servidor que deve manipular a conexão).

    

Answer 2

Outra abordagem seria apenas chamar o provedor de serviços de DNS e explicar-lhes o que aconteceu. Eu acho que depois de alguma "prova" de que você é o dono do domínio / delegado ou algo assim, eles podem te dar acesso ou mudar para você ...