2 votos

AWS VPC: Internet Gateway vs NAT

Este y este y este son muy relacionado con mi pregunta. Aunque parece haber respondido a un buen montón de las dudas de la gente, todavía estoy luchando para entender si esta configuración es específica de AWS o en general de la red. Si es el segundo, entonces la necesidad de volver a visitar mis fundamentos. Sospecho que ya, y de ahí la pregunta.

Mi comprensión

Si una red privada está conectado a Internet, luego de sus ejércitos necesitan tener IPs públicas a ser identificada de forma única en Internet. Todo el tráfico de internet, de entrada o de salida, que pasa con esta dirección IP Pública. Un host de la red cuando se conecta a Internet se pone una IP Pública. Un paquete procedente de este host decir www.google.com tendrá el host privado de dirección en el paquete, que finalmente se sustituye por su dirección IP pública por el dispositivo NAT (que está instalado en el router/Puerta de enlace predeterminada), que es como se ilustra aquí. De esta manera la mayoría de la Internet (excepto IPV6) se ejecuta.

Ahora, en AWS

  • cuando se crea una Subred Pública y habilitar auto-asignar IPs Públicas, que son esencialmente informar a la Puerta de enlace de Internet para cambiar la dirección privada de la instancia de EC2 con la dirección IP pública de la instancia de EC2 en la solicitud de los paquetes que provienen de esta instancia de EC2, mientras que el enrutamiento de sus solicitudes en el internet y vice-versa sobre el modo en. Es mi entendimiento de la derecha?
  • cuando se crea una Subred Privada (por no adjuntar a la Puerta de enlace de Internet), se mantiene privada. Entonces, nosotros conscientemente asegúrese de que podemos mantener el auto-asignar IP Pública de discapacidad. Cuando lanzamos instancias de EC2 dentro de esta subred privada, nosotros, no, por lo tanto, llegar a ver, las IPs públicas en la consola de EC2. Esto también significa que los casos que en esta subred no son visibles en internet. Ahora, si puedo conectar este subred privada a un dispositivo NAT (que, por supuesto, está en la subred pública) (por favor, no me confundan con lo de la Pasarela de NAT no mejor, en este momento), entonces, yo soy en esencia, dejando el dispositivo NAT para averiguar IP pública a asignar a un host específico X de la subred privada que ha solicitado para comunicarse con el internet como una IP pública es necesaria para comunicarse con Internet.

    Ahora,

    • Esto no es algo que un/Router(Internet) de la Puerta de enlace ya y también en AWS y en general de la red? No es la asignación de IPs públicas a los hosts en una red y mantener la sustitución de la dirección IP privada con la dirección IP pública en los paquetes (que se originan en un host de red) en su camino de salida a Internet es algo que se lleva a cabo por un router?
    • Dicen que el dispositivo NAT cifras de la IP 1.2.3.4 a ser asignado a este host de la subred privada. Si, "de alguna manera", esta IP se conoce en Internet, entonces este host en la subred privada debería ser accesible desde Internet, demasiado, a menos que el dispositivo NAT tira algún truco (ver pregunta de seguimiento). Es mi entendimiento de la derecha? Ahora, AWS dice que el dispositivo NAT no permitir la comunicación entrante. Es que como contra el hecho de que, incluso si la dirección IP 1.2.3.4 (que el dispositivo NAT asigna al host de esta subred privada) se la conoce, las conexiones de entrada se fuerza restringido? O, ¿el dispositivo NAT simplemente utilizar su propia dirección IP en nombre de los hosts de la red privada (que no es lo que un dispositivo NAT idealmente debe hacer; un dispositivo NAT lleva a la asignación de direcciones IP Privadas y la reemplaza con la dirección IP Pública en paquetes)?
    • También, AWS le permite activar auto-asignar IPs Públicas en una subred privada. Y puedo confirmar que puedo ver en las instancias de EC2 en la subred privada con una IP Pública. Así, ahora tienes una Subred Privada (como no están conectados a la Puerta de enlace de Internet en las tablas de enrutamiento) con las instancias de tener una IP Pública (como se ha habilitado el auto-asignar IPs Públicas en una subred privada). Cómo se supone que eso debe interpretarse?

0voto

MLu Puntos 439

Creo que entienden la función de puerta de enlace NAT y que conduce a todas las otras confusiones.

  • NAT no al azar asignar direcciones a los internos / privada de los ejércitos.

  • Dispositivo NAT usualmente tiene dos interfaces - interior con una IP privada, por ejemplo, 10.0.0.1. Y externos con una IP pública, por ejemplo, 1.2.3.4.

  • Los Hosts de la red interna que tiene por ejemplo algunos 10.0.0.x dirección (y no público) enviar todo el tráfico de salida a la pasarela de NAT y que la puerta de enlace NAT reemplaza la dirección IP de origen del paquete (por ejemplo, 10.0.0.123) con su propia IP pública (es decir, 1.2.3.4). A continuación, se envía el paquete hacia el destino en internet, por ejemplo, a Google.

  • Los paquetes TCP no sólo de origen y de destino direcciones , pero también de origen y de destino de los puertos. El puerto de origen también puede ser reemplazado por la pasarela de NAT para evitar colisiones cuando varios hosts de intentar comunicarse con la misma puertos de origen.

NAT Explicó:

Un host interno 10.0.0.123 quiere descargar algo de google.com en 216.58.203.110 a través de HTTPS, es decir, el puerto 443.

  1. Se envía un paquete con origen 10.0.0.123:12345 (dirección : random puerto local) y de destino 216.58.203.110:443 (dirección : puerto https) para la puerta de enlace NAT, porque esa es su mejor salto siguiente para todas las direcciones no 10.0.0.x.

  2. La puerta de enlace NAT reemplaza la fuente de la 10.0.0.123:12345 a su propia IP pública y algunas de puerto aleatorio 1.2.3.4:54321.

  3. Registra que una conexión de 10.0.0.123:12345 a 216.58.203.110:443 ha sido traducido a 1.2.3.4:54321 en su conexión tabla de seguimiento.

  4. Cuando un retorno paquete de google llega a la Puerta de enlace NAT con un destino 1.2.3.4:54321, la puerta de enlace busca de un registro (dirección:puerto) y considera que se debería traducir de nuevo a 10.0.0.123:12345 y enviarlo al host en el puerto.

Si, al mismo tiempo, otro host de la red local (por ejemplo, 10.0.0.99) de los intentos de descargar algo de Google esto es lo que sucede:

  1. La puerta de enlace NAT traduce la dirección IP de origen de nuevo a su propia IP pública 1.2.3.4 , pero el puerto de origen será algo más que antes, por ejemplo 56789.

  2. Ahora que Google ve dos conexiones de nuestra puerta de enlace NAT

    • 1.2.3.4:54321 - 216.58.203.110:443 (donde la puerta de enlace NAT sabe que la fuente original es, de hecho, 10.0.0.123:12345)
    • 1.2.3.4:56789 - 216.58.203.110:443 (NAT GW sabe que la fuente original es 10.0.0.99:12345).

Ambas conexiones parecen venir de la puerta de enlace NAT, pero en realidad fueron iniciados a partir de diferentes hosts de la red interna. Sólo la puerta de enlace NAT sabe la asignación.

Que en pocas palabras.


Ahora un par de notas:

  • Usted no puede iniciar conexiones desde el exterior a un host detrás de NAT. Sólo puedes enviar las respuestas a los paquetes que inició desde el interior.

    Eso es porque la correspondencia entre los internos IP:port y puerta de enlace NAT IP:port se realiza cuando el host interno envía el primer paquete.

    Si usted quería SSH a 10.0.0.123:22 desde fuera cómo lo harías? No se pudo enviar el paquete SSH a la puerta de enlace NAT IP 1.2.3.4 pero qué puerto? A ver, no hay ninguna correlación, de modo que no es posible iniciar una conexión desde el exterior.

  • Los Routers en el otro lado no cambie las direcciones ip o puertos (como opuesto a NAT puertas de enlace). Pasan los paquetes a través de prácticamente sin cambios.

  • En la AWS contexto Router es IGW = Puerta de enlace de Internet. NAT puede ser Puerta de enlace NAT o a Instancia de NAT, ellos hacen lo mismo.

Espero que lo explica :)

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: