Tutorial: Crie seu Reverse Proxy para ocultar o IP do servidor com Vesta (Deprecated)

  • Autor Autor Carlos Frias
  • Data de início Data de início
Este tópico foi traduzido automaticamente do espanhol. Ver original
Status

🔒 Este tópico está fechado para novas respostas.

⏰ Apenas o criador do tópico pode solicitar a reabertura de seus próprios tópicos, mas apenas dentro dos 60 dias anteriores à última atualização.

O que foi alcançado com isso? Desaparecer tudo o que não vamos usar ou o que não foi instalado com esta modalidade no VestaCP, além disso cabe ressaltar que não devemos
Não, pelo menos 4G de RAM é o que eu recomendo, 2 cores de processador e, acima de tudo, a rede. Se você consome mais de 200mbps de rede, precisa buscar um provedor de servidores que te forneça mais de 200mbps de rede. O que mais se consome é a rede, acima de tudo.
Excelente, basicamente se precisa ter uma rede melhor que a do VPS principal onde está o site, certo?.
Isso é ouro, já salvei em um PDF 🙂.
 
Excelente, basicamente se precisa ter uma rede melhor que a do VPS principal onde está o site, certo?.
Isso é ouro, já salvei em um PDF 🙂.
Sim, o VPS é quem deve ter uma boa rede ou um dedicado que seja usado como proxy.
 
Sim, o VPS é quem deve ter uma boa rede ou um dedicado que seja usado como proxy.

Ah, olha só, minha pergunta anterior era nesse sentido, pensando que nossa hospedagem original era a que ditava o poder da rede, mas é o contrário. Então, pelo que entendi, a hospedagem original pode ser pequena, já que só gerencia os dados do nosso site, e o proxy é que deve ter boa rede, memória, etc., para poder mover as solicitações. Ou seja, a hospedagem original de $5 ou $10, e o proxy, um de $20, é assim?
 
Bom tutorial, isso também serve como balanceamento de tráfego ou estou me confundindo?
 
Ah, olha só, minha pergunta anterior era nesse sentido, pensando que nossa hospedagem original era a que ditava o poder da rede, mas é o contrário. Então, pelo que entendi, a hospedagem original pode ser pequena, já que só gerencia os dados do nosso site, e o proxy é que deve ter boa rede, memória, etc., para poder mover as solicitações. Ou seja, a hospedagem original de $5 ou $10, e o proxy, um de $20, é assim?

Correto, mas também tem um truque: para economizar rede na hospedagem de destino final, deve-se configurar o Nginx para fazer Cache.

Verei se mais adiante faço um tutorial para adicionar a parte de "CDN", que é muito efetiva, deixa o site bem veloz.

Bom tutorial, isso também serve como balanceamento de tráfego ou estou me confundindo?

Correto, esse tema rende outro tutorial, já que requer outras configurações e regras no Nginx (mais adiante veremos).

É possível fazer muitas coisas 🙂
 
@Carlos Frias Alguma hospedagem offshore e pacotes específicos recomendados para a questão de DMCA que permitam essa configuração que você menciona? 🙂
 
Muito obrigado pela informação, excelente contribuição. Abraços
 
@Carlos Frias Alguma hospedagem offshore e pacotes específicos recomendados para a questão de DMCA que permitam essa configuração que você menciona? 🙂

Primeiro, deve ser feito em um VPS; por enquanto, continuo recomendando a Veesp de olhos fechados.

Depois verei se começo a variar um pouco ou se publico uma lista de servidores que considero pessoalmente sérios, já que as empresas que conheço que pelo menos aceitam hospedar esse tipo de conteúdo e ignoram as denúncias são escassas.
 
Primeiro, deve ser feito em um VPS; por enquanto, continuo recomendando a Veesp de olhos fechados.

Depois verei se começo a variar um pouco ou se publico uma lista de servidores que considero pessoalmente sérios, já que as empresas que conheço que pelo menos aceitam hospedar esse tipo de conteúdo e ignoram as denúncias são escassas.
olá, tenho uma dúvida, é difícil fazer um proxy privado que um plugin de WordPress para redes sociais me pede?
 
olá, tenho uma dúvida, é difícil fazer um proxy privado que um plugin de WordPress para redes sociais me pede?

Depende, se quiser, me envie essa informação por mensagem privada.
 
Olá @Carlos Frias, excelente contribuição !!!

Uma dúvida, se tenho um plano na Banahosting com 2 domínios hospedados, crio o reverse proxy na VEESP etc., então no painel do Vesta devo adicionar os 2 domínios ou tudo o que estiver apontando para o host dos EUA passará automaticamente pelo proxy?
 
Olá @Carlos Frias, excelente contribuição !!!

Uma dúvida, se tenho um plano na Banahosting com 2 domínios hospedados, crio o reverse proxy na VEESP etc., então no painel do Vesta devo adicionar os 2 domínios ou tudo o que estiver apontando para o host dos EUA passará automaticamente pelo proxy?

Você deve adicionar os domínios que quer passar pelo IP Russo para que as denúncias não cheguem à Banahosting, é correto.
 
Olá, tudo bem, betas?, hoje vou mostrar como realizar o seguinte.

Ver o anexo 307812

Para o público, um IP da Rússia (um VPS russo, por exemplo, em veesp.com) e, apenas para nosso conhecimento, um servidor nos Estados Unidos.

Em que isso beneficia vocês? Para quem tem sites de séries, filmes, anime, pornô ou pelo simples fato de evitar que a concorrência saiba onde o site está realmente hospedado (para saber com que fins) e ter que, por qualquer motivo, migrar seus dados de tempos em tempos. Serve muito para portais que recebem ataques e depois você se vê obrigado a migrar os dados de forma recorrente, pois com isso você apenas monta um proxy e muda o IP, sem nunca mais tocar nos dados (e se você é pirata com um site do tipo warez... as reclamações não chegam ao destino final, apenas à empresa offshore, que as ignora) Impressionante, não?

Obviamente, não faltará quem diga que sempre há formas de conseguir o IP, mas este método por si só já dificulta para uma população muito grande (ainda assim, não vi esses casos, apenas pessoas falando que é possível) sem mais delongas, vamos ao que interessa.

1)
Vou e compro meu servidor (deve ser feito em um servidor que esteja em branco)

Ver o anexo 307828

2) Colocamos um hostname (nome da máquina) e preenchemos os dados (Atenção, selecionamos CentOS 7 x64 como distribuição de Linux)

Ver o anexo 307832

3) Depois de fazer o pedido e pagar, nos entregarão o VPS em cerca de 5-10 minutos

Ver o anexo 307834
Ver o anexo 307835

4) Agora, com os dados que recebemos por e-mail, entramos no VPS via SSH e iniciamos uma instalação do VestaCP

Normalmente a porta SSH na Veesp por padrão é a 22, mas em outras empresas isso pode variar, a menos que você a altere da sua maneira.

yum upgrade -y; yum install -y wget curl curl-devel nano perl perl-core epel-release; curl -O http://vestacp.com/pub/vst-install.sh; bash vst-install.sh --nginx yes --apache yes --phpfpm no --named yes --remi yes --vsftpd no --proftpd no --iptables no --fail2ban no --quota no --exim no --dovecot no --spamassassin no --clamav no --softaculous no --mysql no --postgresql no --hostname server.hostname.tld --email tucorreo@gmail.com --password Cambiame01@#$

Levará pelo menos 10 minutos (ou menos) para instalar o VestaCP e não passará de 20 minutos em provedores com conexão à internet lenta.

Atenção com o hostname, e-mail e senha colocados na linha de comando, além de levar em conta que a senha root do VPS é diferente da do admin.

Ver o anexo 307841

(É possível que demore um pouco)

Ver o anexo 307842

Vamos colocar "y" seguido de enter e finalmente esperamos que todo esse processo automatizado termine...

Ver o anexo 307843

5) Uma vez instalado, teremos 50% do trabalho realizado. O próximo passo será mover os modelos (templates) que o VestaCP traz por padrão e carregar apenas o código com o qual vamos trabalhar. O Vesta servirá apenas como um painel de controle para adicionar e excluir domínios, ativar SSL com Let's Encrypt ou instalar um próprio, sem ter que ficar modificando código pelo console nem escalar para algo maior.

Se você tem conhecimento para fazer isso sem um painel de controle, então vá em frente, mas isso foi feito para quem não quer lutar com isso 😀 (ou para facilitar a existência das pessoas xD). No meu caso, eu tenho a experiência e quero facilitar as coisas para todos vocês.

Ver o anexo 307845

mv /usr/local/vesta/data/templates/web/nginx/ /usr/local/vesta/data/templates/web/nginx.old;mkdir /usr/local/vesta/data/templates/web/nginx/;cd /usr/local/vesta/data/templates/web/nginx/; rm -rf /etc/nginx/conf.d/1* /etc/nginx/conf.d/2* /etc/nginx/conf.d/3* /etc/nginx/conf.d/4* /etc/nginx/conf.d/5* /etc/nginx/conf.d/6* /etc/nginx/conf.d/7* /etc/nginx/conf.d/8* /etc/nginx/conf.d/9* /etc/nginx/conf.d/0*; mv /usr/local/vesta/data/packages /usr/local/vesta/data/packages.old; mkdir /usr/local/vesta/data/packages; wget https://raw.githubusercontent.com/carlosfriascf/vesta7/master/default.pkg -O /usr/local/vesta/data/packages/default.pkg;

6) Vamos colar o seguinte código (e modificar o que diz IPDESTINOFINALAQUI pela IP do servidor que temos nos Estados Unidos, por exemplo)

- Criamos o modelo default.stpl, podemos criá-lo da seguinte forma nano /usr/local/vesta/data/templates/web/nginx/default.stpl;

e depois inserimos o seguinte... (nota: colocar o IP do servidor ou hospedagem em IPDESTINOFINALAQUI como destino/para)

server { listen *:%proxy_ssl_port% ssl; server_name %domain_idn% %alias_idn%; ssl_certificate %ssl_pem%; ssl_certificate_key %ssl_key%; error_log /var/log/httpd/domains/%domain%.error.log error; location / { proxy_pass https://IPDESTINOFINALAQUI:443; location ~* ^.+\.(%proxy_extentions%)$ { root %sdocroot%; access_log /var/log/httpd/domains/%domain%.log combined; access_log /var/log/httpd/domains/%domain%.bytes bytes; expires max; try_files $uri @fallback; } } location @fallback { proxy_pass https://IPDESTINOFINALAQUI:443; } include %home%/%user%/conf/web/snginx.%domain%.conf*; }

- Fazemos o mesmo com default.tpl, podemos criá-lo da seguinte forma nano /usr/local/vesta/data/templates/web/nginx/default.tpl;

server { listen *:%proxy_port%; server_name %domain_idn% %alias_idn%; error_log /var/log/httpd/domains/%domain%.error.log error; location / { proxy_pass http://IPDESTINOFINALAQUI:80; location ~* ^.+\.(%proxy_extentions%)$ { root %docroot%; access_log /var/log/httpd/domains/%domain%.log combined; access_log /var/log/httpd/domains/%domain%.bytes bytes; expires max; try_files $uri @fallback; } } location @fallback { proxy_pass http://IPDESTINOFINALAQUI:80; } include %home%/%user%/conf/web/nginx.%domain%.conf*; }

- Lembre-se de salvar as alterações, no nano as alterações são salvas com CTRL + O (depois enter) e para sair CTRL + X...

Ver o anexo 307854

7) Feito isso, concluímos o trabalho pesado... Tudo o que precisamos fazer agora é colocar o IP do nosso Proxy Reverso na lista branca (se o IP que estamos colocando é de uma hospedagem compartilhada, devemos pedir à hospedagem que o faça para evitar banimentos de IP por desconhecimento da sua plataforma de segurança)

Já precisei enviar tickets para a Banahosting para fazer exclusões, por exemplo, no Bitninja, que costuma expulsar muito os IPs dos nossos Proxies.

(atenção, isso no caso de estar hospedado em uma hospedagem compartilhada, pois se envia um ticket)

db103d2e01584c7312f2836fd1a8e175.png


8) Uma vez que o IP esteja na lista branca em nosso firewall ou que a empresa de hospedagem nos confirme que fez a exclusão, passamos a excluir o domínio de teste que o VestaCP gerou no momento da instalação e finalmente criamos o que vamos passar pelo Proxy.

- Entramos no VestaCP, que é IPDOPROXY:8083 com https, ignoramos o Certificado SSL inseguro e clicamos em Log In.

0ddc9b6890bd407eb5191d46c3e3e47a.png


- Vamos até "Web" para ver a lista de domínios existentes...

ecb56b95a67de9a3b5ae663075737111.png


- Excluímos isso e adicionamos o nosso clicando no botão verde (+) para adicionar o nosso.

49a9101645bad90b751fac6738bcddf0.png


eb47cdf8c1264910d02fd1dd4e717520.png


08a9bb336a8fd03824beaadfc906e02c.png


- Colocamos nosso domínio, adicionamos 😀

908f05e09b6a13c2d8629437ba8483e1.png


- E pronto, esta é a mensagem que nos confirmará o bom trabalho que realizamos 😀

1fbc445e0bb0f1a8c2bf0a19d88eafc3.png


9) Finalmente... Vamos ao Cloudflare ou ao nosso Gerenciador de DNS, depois mudamos o IP do servidor nos Estados Unidos pelo do Proxy.

- Modifica-se o @ (o registro A do domain.tld e o www no caso de ser um Record A e não um CNAME)

fb85df281cc56f9b8bd802f6c123c4ce.png


10) Concluímos ativando o Certificado SSL e verificando os resultados...

e50cf1790900c264093584434e825c3a.png


d58540ee0949a09b556fbd70562eaa56.png


RESULTADO:

e734fce432e96e4775a80a5ac3849fa1.png


22c68b71c879bbbc512f531128d5dd5c.png


Qualquer dúvida, correção, preocupação, pergunta, contribuição ou sugestão é bem-vinda... Não é incômodo algum, então você pode me escrever por mensagem privada ou comentar no tópico e eu responderei com muito prazer, sem problema algum. Fico no aguardo de qualquer novidade, nos vemos no próximo tutorial 😉 também clicando no link da minha assinatura, você poderá validar parte dos serviços que eu ofereço.
O tutorial está excelente, só que tem um detalhe: segui o tutorial exatamente como está, e tudo ok, mas faço ping pelo CMD para web.com e continua aparecendo o "IP dos Estados Unidos". Mas coloco o IP russo DO PROXY apenas no navegador e ele carrega a página padrão do "plesk, ou seja, servidor ESTADOS UNIDOS", ou seja, está redirecionado. Alguma forma de saber se o proxy realmente está funcionando?.
 
Obrigado pelo acolhimento que deram ao guia, hoje venho trazer uma atualização para corrigir as opções que aparecem "a mais" no nosso painel de controle que estamos usando apenas para fins de Proxy Reverso (e talvez até DNS), a seguir, deve-se rodar o seguinte.

mv /usr/local/vesta/data/packages /usr/local/vesta/data/packages.old; mkdir /usr/local/vesta/data/packages; wget https://raw.githubusercontent.com/carlosfriascf/vesta7/master/default.pkg -O /usr/local/vesta/data/packages/default.pkg;

Antes:

Ver o anexo 308613

Depois:

Ver o anexo 308614

O que foi alcançado com isso? Desaparecer tudo o que não vamos usar ou o que não foi instalado com esta modalidade no VestaCP, além disso, cabe ressaltar que não devemos nos preocupar com questões de segurança, já que este servidor NÃO HOSPEDA O SITE, apenas o carrega mediante Proxy.

Da mesma forma, se você quiser mudar a porta de acesso ao VestaCP (IPDOSERVIDOR:8083) pode rodar o seguinte a seguir.

sed -i 's/8083;/NUEVOPUERTO;/g' /usr/local/vesta/nginx/conf/nginx.conf; killall -9 vesta; service vesta restart;

(Atenção, onde diz NOVAPORTA vai a sua nova porta) e se por algum erro o serviço do VestaCP não subir, inverta o comando.

sed -i 's/PUERTOERRONEO;/NUEVOPUERTO;/g' /usr/local/vesta/nginx/conf/nginx.conf; killall -9 vesta; service vesta restart;

Por enquanto, fico no aguardo de qualquer dúvida para responder. Passo a atualizar o tutorial com o patch.

Abraços,
O primeiro comando não está funcionando, por alguma razão ao rodá-lo as opções continuam aparecendo.
 
Obrigado, bom tutorial, vou ler com atenção!
 
O tutorial está ótimo, só que tem um detalhe e é que segui exatamente o tutorial, e tudo ok, mas faço ping pelo CMD para web.com e continua aparecendo o "IP dos Estados Unidos". Mas coloco o IP russo DO PROXY apenas no navegador e ele carrega a página padrão do "plesk, ou seja, servidor ESTADOS UNIDOS", ou seja, está redirecionado.
Alguma forma de saber se o proxy realmente está funcionando?.
Conseguiu solucionar isso? Acho que primeiro você tinha que limpar o cache de DNS do seu PC, depois fazer o ping
 
O tutorial está ótimo, só que tem um detalhe e é que segui exatamente o tutorial, e tudo ok, mas faço ping pelo CMD para web.com e continua aparecendo o "IP dos Estados Unidos". Mas coloco o IP russo DO PROXY apenas no navegador e ele carrega a página padrão do "plesk, ou seja, servidor ESTADOS UNIDOS", ou seja, está redirecionado.
Alguma forma de saber se o proxy realmente está funcionando?.

Pelo menos com uma CDN como a Cloudflare funciona dessa forma, ao fazer ping ele mostra os IPs da Cloudflare, mas lá está configurado para apontar para o servidor da veesp, esse IP intermediário não seria visível com o ping.

Por enquanto, funciona bem para mim entre o vesta na veesp e um plesk nos EUA.
 
Status

🔒 Este tópico está fechado para novas respostas.

⏰ Apenas o criador do tópico pode solicitar a reabertura de seus próprios tópicos, mas apenas dentro dos 60 dias anteriores à última atualização.

Voltar
Topo