Estrategias server físico que ejecuta varios invitados, pero con un solo IPv4 externo

Mi host es – comprensiblemente – networkinguciendo las direcciones IPv4 ofrecidas con nuevos serveres, de modo que la próxima vez que vuelva a ubicar mis cosas en un nuevo server tendré un gran número de direcciones IPv6, pero solo una dirección IPv4.

Para los services de los que ejecutar sólo una instancia (como SMTP) esto no debería ser un problema. Voy a NAT simplemente el material a través (con iptables/6 ). Sin embargo, para otros services – y estoy especialmente preocupado por HTTP / S aquí – veo el problema de cómo pasar el tráfico entrante a la máquina invitada correcta y, obviamente, get los datos salientes en tour al cliente de nuevo.

Mi principal problema aquí es la security. Creo que podría (ab) utilizar uno de los proxies habituales o un server web (nginx, lighttpd) que también puede servir como un proxy. Sin embargo, en este caso, los sistemas invitados ven esto como una "request local" y ciertos mecanismos de control de acceso pueden fallar. Además, HTTPS es un gran problema aquí debido al tráfico encriptado, aunque podría tener el sistema host implementar las partes HTTPS por completo y proxy de / a los sistemas invitados sin cifrar (han estado utilizando ese método en una sola máquina donde una instancia lighttpd sirvió como el frontend a un backend Apache2 que maneja un set particular de URIs).

¿Cómo puedo ofrecer el mismo service (HTTP / S aquí) al mundo exterior aunque el event handling dominios individuales sea realizado por invitados individuales? ¿O más bien lo que se considera la mejor práctica en estos días?

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

… o puedo quizás despreciar todos estos problemas sólo dando AAAA loggings a esos dominios y dejar que el lado del cliente manejar todo?

One Solution collect form web for “Estrategias server físico que ejecuta varios invitados, pero con un solo IPv4 externo”

No puedo ver este final de ninguna manera aparte de "la próxima vez que vuelva a ubicar mis cosas a un nuevo server que será en un nuevo host con más IPs". A less que usted esté planeando 3-5 años hacia fuera o sus usuarios son chums verdaderos, esto terminará probablemente en rasgones.

IPv6 todavía no es stream, sin IPv4 usted apenas no va a tener ningún visitante. Sólo tener loggings AAAA hará que un server bastante inactivo. Experiencia anecdótica es que en 3-5 años todo el mundo tendrá junked su enrutador inalámbrico barato al less una vez, tal vez por el momento la gente compra nuevos los routers baratos lo apoyará sin necesidad de OpenWRT.

En el lado de la security, X-Forwarded-For: fue diseñado para permitir que los serveres conozcan qué IP está conectado al proxy inverso, por lo que tendrá que volver a escribir el código de los sitios para que vea el encabezado en lugar de la connection misma.

SNI fue desarrollado para hacer frente a los serveres virtuales SSL y prácticamente todos los serveres actuales lo soportan, por lo que la creación de un proxy inverso de Apache o Nginx debería cubrirlo allí. Si alguno de los invitados necesitaba certificates SSL del lado del cliente, no sé cómo se transmite la información del certificate desde un proxy (estoy seguro de que se envía en un encabezado). El problema real aquí es que en Windows XP, IE no soporta SNI y obtendrá el certificate de host virtual por defecto con cualquier nombre de host que introdujeron, esperamos que sus usuarios actualizarán Windows o cambiarán a Firefox.

  • Construcción de SAN barata
  • ¿Debo instalar los transceptores SFP + en parejas?
  • Servidor SSH, enviado al cliente
  • ¿Por qué mtr es mucho más rápido que traceroute?
  • Solución de problemas de una networking "lenta"
  • Autoridad de server DNS
  • Conectividad inestable en el server Ubuntu 14.04 con dos adaptadores de networking
  • Estado actual de Tinc 1.1?
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.