Estratégias do servidor físico executando vários convidados, mas com um único IPv4 externo

Question

Meu hoster está - compreensivelmente - reduzindo os endereços IPv4 oferecidos com novos servidores para que, da próxima vez que eu localizar minhas coisas em um novo servidor, eu tenha um grande número de endereços IPv6, mas apenas um único endereço IPv4.

Para os serviços dos quais executo apenas uma instância (como SMTP), isso não deve ser um problema. Vou simplesmente passar o NAT através (usando iptables/6 ). No entanto, para outros serviços - e estou particularmente preocupado com HTTP / S aqui - vejo a questão de como passar tráfego de entrada para a máquina de convidado correta e, obviamente, obter os dados de saída em turnê para o cliente novamente.

Minha principal questão aqui é a segurança. Eu acho que poderia (ab) usar um dos proxies habituais ou um servidor web (nginx, lighttpd) que também pode servir como um proxy. No entanto, nesse caso, os sistemas convidados vêem isso como uma "solicitação local" e determinados mecanismos de controle de acesso podem falhar. Além disso, o HTTPS é um grande problema aqui devido ao tráfego criptografado, embora eu possa fazer com que o sistema host implemente as partes HTTPS completamente e o proxy de / para sistemas convidados não criptografados (usei esse método em uma única máquina em que uma instância lighttpd serviu como o front-end para um back-end do Apache2 manipulando um conjunto específico de URIs).

Como posso oferecer o mesmo serviço (HTTP / S aqui) para o mundo externo, mesmo que a manipulação de domínios individuais seja realizada por convidados individuais? Ou melhor, o que é considerado melhor prática nos dias de hoje?

[internet] <--> [IPv4:host] <-+-> [guest:foo.org]
                              |
                              |-> [guest:bar.org]
                              |
                              |-> [guest:baz.org]

... ou posso, talvez, desconsiderar todos esses problemas dando apenas AAAA registros para esses domínios e permitindo que o lado do cliente cuide de tudo?

    

Answer 1

Não consigo ver esse final de maneira diferente de "na próxima vez que eu localizar minhas coisas em um novo servidor, ele estará em um novo host com mais IPs". A menos que você esteja planejando de 3 a 5 anos ou que seus usuários sejam verdadeiros amigos, isso provavelmente acabará em lágrimas.

O IPv6 ainda não é mainstream, sem IPv4 você simplesmente não terá visitantes. Basta ter registros AAAA para um servidor razoavelmente ocioso. A experiência anedótica é que em 3-5 anos todos terão de trocar seu roteador sem fio barato pelo menos uma vez, talvez até que as pessoas comprem novos roteadores baratos suportarão o mesmo sem precisar do OpenWRT.

Do lado da segurança, o X-Forwarded-For: foi projetado para permitir que os servidores saibam qual IP conectado ao proxy reverso, então você precisará reescrever o código dos sites para ver o cabeçalho em vez da própria conexão.

O SNI foi desenvolvido para lidar com hosts virtuais SSL e praticamente todos os servidores atuais o suportam, portanto, O proxy do Apache ou Nginx deve cobrir você lá. Se algum dos convidados precisar de certificados SSL do lado do cliente, não sei como essas informações de certificado são transmitidas de um proxy (tenho certeza de que elas são enviadas em um cabeçalho). O problema real aqui é que, no Windows XP, o IE não suporta SNI e obterá o certificado do host virtual padrão com qualquer nome de host que eles tenham inserido, esperamos que seus usuários atualizem o Windows ou alternem para o Firefox.