Información confidencial de Google

Redes virtuales

En este módulo, analizaremos las redes virtuales.

Google Cloud usa una red definida por software y desarrollada en una infraestructura
global de fibra óptica. Esta infraestructura hace que Google Cloud tenga una de las
redes más grandes y rápidas del mundo. Si considera los recursos como servicios
(en lugar de hardware), podrá comprender las opciones disponibles y cómo
funcionan.
 Información confidencial de Google

Temario

01 Nube privada virtual (VPC)

02 Proyectos, redes y subredes

03 Direcciones IP

04 Rutas y reglas de firewall

05 Precios
Lab: Redes de VPC

06 Diseños comunes de redes

Lab: Implemente el Acceso privado 
a Google y Cloud NAT

Comenzaremos el módulo con una presentación de la nube privada virtual, o VPC,

que es la funcionalidad de herramientas de redes administradas de Google para sus
recursos de Cloud Platform. Luego, desglosaremos las redes en sus componentes
fundamentales: proyectos, redes, subredes, direcciones IP, rutas y reglas de firewall,
y analizaremos los precios de red.

A continuación, exploraremos la estructura de red de Google Cloud a través de un lab

en el que crearemos redes de muchas variedades diferentes y analizaremos las
relaciones entre ellas.

Después de eso, observaremos diseños de redes comunes.

 Información confidencial de Google

Finlandia

Países Bajos
Varsovia
Londres
Montreal Bélgica Fráncfort
Toronto París
Oregón Iowa* Zúrich Milán
Salt Lake City Madrid
Virginia del N. Seúl
Las Vegas Tokio
Los Ángeles Carolina del S.
Osaka
Delhi
Doha Taiwán
Hong Kong
Bombay

Singapur

Yakarta

Google Cloud São Paulo

Santiago
Sídney

Regiones, puntos de Melbourne

presencia y redes
Punto de
* Excepción: Región con 4 zonas. Región actual Región futura
presencia Red
con 3 zonas con 3 zonas
perimetral

Este mapa representa a Google Cloud. En el nivel general, Google Cloud está
compuesto por regiones (íconos azules), puntos de presencia o PoP (puntos azules),
una red privada global (líneas azules) y servicios.

Una región es una ubicación geográfica específica donde puede ejecutar sus
recursos. En este mapa, se muestran varias regiones que operan en la actualidad y
aquellas que lo harán en el futuro. Las regiones marcadas con íconos azules tienen
tres zonas. La única excepción es Iowa, cuya región us-central1 tiene cuatro zonas:
us-central1-a, us-central1-b, us-central1-c y us-central1-f. Para obtener información
actualizada sobre las regiones y zonas, consulte la página de documentación.

Los PoP son lugares en los que la red de Google se conecta al resto de Internet.
Google Cloud puede acercar su tráfico al de sus pares porque opera una amplia red
global de puntos de interconexión. Esto permite reducir los costos y proporcionar una
mejor experiencia a los usuarios.

La red conecta regiones y PoP, y se compone de una red global de cables de fibra
óptica con varias inversiones en cables submarinos.

Para obtener más información sobre la infraestructura de red de Google, consulte

este sitio.
 Información confidencial de Google

Nube privada virtual

(VPC)

01
Para comenzar, hablemos sobre la red de Google Cloud y, específicamente, sobre la
nube privada virtual (VPC).
 Información confidencial de Google

Objetos de VPC

Nube privada
● Proyectos ● Direcciones IP virtual
○ Interna, externa, rango
● Redes
○ Predeterminada, modo automático, ● Máquinas virtuales (VMs)
modo personalizado
● Rutas
● Subredes
● Reglas de firewall
● Regiones

● Zonas

Con Google Cloud, puede aprovisionar sus recursos del servicio, conectarlos a otros
y aislarlos en una nube privada virtual. También puede definir políticas detalladas de
red en Google Cloud, y entre Google Cloud y otros entornos locales o nubes
públicas. En términos simples, VPC es un conjunto integral de objetos de red
administrados por Google que analizaremos en detalle en este módulo.

Primero, veamos una descripción general de los objetos:

● Los proyectos abarcarán todos los servicios que use, incluidas las redes.
● Existen tres tipos de redes: predeterminadas, de modo automático y de modo
personalizado.
● Las subredes le permiten dividir o segregar su entorno.
● Las regiones y las zonas representan los centros de datos de Google y
proporcionan alta disponibilidad y protección continua de los datos.
● VPC ofrece direcciones IP para uso interno y externo, además de selecciones
detalladas de rangos de direcciones IP.
En cuanto a las máquinas virtuales, en este módulo nos enfocaremos en
configurar instancias de VM desde la perspectiva de las redes.
● También analizaremos las rutas y las reglas de firewall.
 Información confidencial de Google

Proyectos, redes

02
y subredes

En primer lugar, hablemos sobre los proyectos, las redes y las subredes para analizar
los objetos de VPC.
 Información confidencial de Google

Proyectos y redes
Características de Características
los proyectos: de las redes:

● Asocian objetos y servicios ● No tienen rangos de

con facturación. direcciones IP.
● Contienen redes (hasta 5) ● Son globales y abarcan todas
que se pueden compartir las regiones disponibles.
o intercambiar. ● Contienen subredes.
● Están disponibles como
predeterminadas, automáticas
o personalizadas.

Los proyectos son el elemento organizador clave de los recursos de infraestructura

en Google Cloud. Los proyectos asocian los objetos y servicios con la facturación. Lo
que los hace únicos es que, en realidad, pueden contener redes completas. La cuota
predeterminada para cada proyecto es de 5 redes, pero puede solicitar fácilmente un
aumento con Cloud Console. Estas redes se pueden compartir con otros proyectos o
pueden intercambiar tráfico con redes de otros proyectos. Analizaremos ambas
opciones en el curso Architecting with Google Compute Engine.

Las redes no tienen rangos de IP, ya que son solo una construcción de todos los
servicios y las direcciones IP individuales en ella. Las redes de Google Cloud son
globales, es decir, abarcan todas las regiones disponibles en el mundo que
mostramos antes. Por lo tanto, puede tener una red que literalmente exista en todo el
mundo a la vez: Asia, Europa, América, etcétera.
En una red, puede segregar sus recursos con subredes regionales.

Mencionamos hace un momento que existen distintos tipos de redes:

predeterminadas, automáticas y personalizadas. Analicémoslas en profundidad.
 Información confidencial de Google

3 tipos de redes de VPC

Predeterminado Modo automático Modo personalizado

● Todos los proyectos ● Red predeterminada ● No se crean subredes

● Una subred por región ● Una subred por región predeterminadas

● Reglas de firewall ● Asignación de IP regional ● Control total de los

predeterminadas rangos de IP
● Subred /20 fija por región
● Asignación de IP regional
● Expandible hasta /16
● Expandible a rangos
de IP que especifique

Todos los proyectos cuentan con una red de VPC predeterminada, que tiene
subredes y reglas de firewall predefinidas. Específicamente, se asigna una subred a
cada región con bloques CIDR no superpuestos y reglas de firewall que permiten
tráfico de entrada de ICMP, RDP y SSH desde cualquier lugar, además de tráfico de
entrada desde la red predeterminada para todos los protocolos y puertos.

En las redes de modo automático, se crea automáticamente una subred de cada

región dentro de ella. En realidad, las redes predeterminadas son redes de modo
automático. Estas subredes que se crearon automáticamente usan un conjunto de
rangos de IP predefinidos con una máscara /20 que se puede expandir a /16. Todas
estas subredes se ajustan al bloque CIDR [Link]/9. Por lo tanto, a medida que
están disponibles las nuevas regiones de Google Cloud, se agregan
automáticamente las subredes nuevas en esas regiones a las redes de modo
automático con un rango de IP de ese bloque.

Las redes en modo personalizado no crean subredes automáticamente. Este tipo de

red le proporciona control total sobre sus subredes y rangos de IP. Usted decide qué
subredes crear, en las regiones que elija, con el rango de IP que especifique. Estos
rangos de IP no se pueden superponer entre las subredes de una misma red.

Ahora bien, puede convertir redes de modo automático a redes en modo

personalizado para aprovechar el control que estas ofrecen. Sin embargo, la
conversión funciona en un solo sentido, es decir, las redes en modo personalizado no
se pueden transformar en redes de modo automático. Por lo tanto, revise con
detenimiento las consideraciones sobre las redes de modo automático a fin de decidir
qué tipo de red se ajusta a sus necesidades.
 Información confidencial de Google

Sistemas de aislamiento de redes

Internet

Proyecto

Red nº 1 Red nº 2 Red nº 3 Red nº 4 Red nº 5 Regiones

● A y B se pueden comunicar a través de IP internas, pese a que se encuentran en diferentes regiones.

● C y D se deben comunicar a través de IP externas, pese a que se encuentran en la misma región.

En esta diapositiva, tenemos un ejemplo de un proyecto que contiene 5 redes. Todas

ellas abarcan varias regiones del mundo, como puede ver en el lado derecho.

Cada red contiene máquinas virtuales independientes: A, B, C y D. Como las VMs A y

B están en la misma red, la nº 1, pueden comunicarse mediante direcciones IP
internas, pese a que están en regiones distintas. En términos simples, sus máquinas
virtuales aprovechan la red global de fibra de Google, incluso si se encuentran en
distintas partes del mundo. En cuanto al protocolo de configuración de red, las
máquinas virtuales se muestran como si estuvieran en un mismo bastidor.

Sin embargo, las VMs C y D no están en la misma red. Por lo tanto, de forma
predeterminada, deben comunicarse mediante direcciones IP externas, a pesar de
que están en la misma región. El tráfico entre las VMs C y D no pasa por la Internet
pública, sino que usa los routers perimetrales de Google. Esto tiene distintas
consecuencias en la facturación y seguridad que exploraremos más adelante.
 Información confidencial de Google

La VPC de Google es global

Local Red de
Cloud VPC
VPN
Puerta
de enlace

VM VM
Compute Engine Compute Engine

Subred Subred

Dado que las instancias de VM en una red de VPC se pueden comunicar de forma
privada a escala global, una sola VPN puede conectar de forma segura su red local
con la de Google Cloud, como se muestra en este diagrama. Aunque las dos
instancias de VM están en regiones distintas (us-west1 y us-east1), aprovechan la
red privada de Google para comunicarse entre ellas y con una red local mediante una
puerta de enlace de VPN.

Esto permite reducir los costos y la complejidad de la administración de las redes.

 Información confidencial de Google

Las subredes atraviesan zonas

Red 1 ● Las VMs pueden estar en una

misma subred, pero en zonas
Región 1
diferentes.
● Se puede aplicar la misma
subred-1 Zona A Zona B
regla de firewall a ambas VMs.

Mencionamos que las subredes funcionan a escala regional. Como una región
contiene varias zonas, las subredes pueden atravesarlas.

En esta diapositiva, se ve una región, la región 1, con dos zonas: A y B. Las subredes
pueden extenderse entre estas zonas en la misma región, como la subred-1. La
subred es solo un rango de direcciones IP, y usted podrá usar cualquier dirección IP
dentro del rango. Tenga en cuenta que las dos primeras direcciones del rango, .0
y .1, se reservan para las puertas de enlace de la red y la subred, respectivamente.
Por lo tanto, las primeras direcciones disponibles son .2 y .3, que se asignan a las
instancias de VM. Las otras direcciones reservadas en cada subred son la penúltima
dirección en el rango y la última, que está reservada como la dirección de
“transmisión”. En resumen, cada subred tiene cuatro direcciones IP reservadas en su
rango de IP principal.

A pesar de que las dos máquinas virtuales de este ejemplo se encuentran en zonas
distintas, pueden comunicarse entre ellas con la misma dirección IP de la subred.
Esto significa que se puede aplicar la misma regla de firewall a ambas VMs, aunque
estén en zonas distintas.
 Información confidencial de Google

Expanda las subredes sin volver a crear instancias

● No se puede superponer con otras subredes.

Proyecto
● El rango de IP debe ser un bloque CIDR válido.
● Los nuevos rangos de IP de subred deben Red

estar dentro de rangos de IP válidos.

● Se puede expandir, pero no reducir.
Región A Región B Región C
● El modo automático se puede expandir
de /20 a /16. Subred Subred Subred Subred

● Evite las subredes grandes.

VM VM VM VM

En cuanto a las direcciones IP de una subred, puede usar las VPCs de Google Cloud
para aumentar el espacio de dirección IP de cualquier subred sin cierres ni tiempo de
inactividad de las cargas de trabajo. En este diagrama, se muestra una red con
subredes que tienen distintas máscaras, lo que permite que haya más instancias en
algunas subredes que en otras. Esto le ofrece opciones de flexibilidad y crecimiento
para satisfacer sus necesidades, pero también debe tener en cuenta los siguientes
factores:

● La subred nueva no debe superponerse con otras de la misma red de VPC en

ninguna región.
● Cada rango de IP para todas las subredes en una red de VPC debe ser un
bloque CIDR válido.
● Además, los nuevos rangos de direcciones IP de subredes son direcciones IP
internas regionales y deben estar dentro de rangos de IP válidos.
○ Los rangos de subredes no pueden coincidir con un rango restringido,
ni ser más estrechos ni más amplios que uno de estos rangos.
○ Los rangos de subredes no pueden abarcar un rango de RFC válido y
un rango de direcciones IP públicas de uso privado.
○ Los rangos de subredes no pueden abarcar varios rangos de RFC.
● El rango de red nuevo debe ser más grande que el original, es decir, el valor
de la longitud del prefijo debe ser un número más pequeño. En otras
 ● palabras, no puede deshacer una expansión.
● Las subredes de modo automático comienzan con un rango de IP /20. Se
pueden expandir hasta un rango de IP máximo de /16. Como alternativa,
puede convertir la subred de modo automático en una de modo personalizado
a fin de aumentar aún más el rango de IP.
● Además, evite crear subredes grandes. Las subredes demasiado grandes
tienen más posibilidades de generar colisiones del rango de CIDR cuando se
usan interfaces de varias redes y el intercambio de tráfico entre redes de
VPC, o cuando se configura una VPN o cualquier otra conexión a una red
local. Por lo tanto, no debe escalar su subred más de lo que realmente
necesita.

Para ver una demostración de cómo expandir una subred personalizada en

Google Cloud, consulte este video.
 Información confidencial de Google

03 Direcciones IP

Ahora que explicamos las redes de Google Cloud de forma general, analicemos en
detalle las direcciones IP.
 Información confidencial de Google

Las VMs deben tener direcciones IP internas

y externas
Internet Direcciones
IP externas
de la nube

IP interna IP externa
● DHCP la asigna desde el rango de ● Se asigna desde un grupo (efímera).
subred a las VMs.
● Está reservada (es estática).
● La asignación de tiempo de DHCP
se renueva cada 24 horas. ● Puede proporcionar sus propias
direcciones IP (BYOIP).
● El nombre y la IP de la VM se registra
mediante DNS con permisos de red. ● La VM no conoce la IP externa;
está asignada a la IP interna.

En Google Cloud, cada máquina virtual puede tener dos direcciones IP asignadas.
Una de ellas es interna y se asigna internamente con DHCP.

Todas las VMs que se inicien y todos los servicios que dependan de una máquina
virtual recibirán una dirección IP interna. Algunos ejemplos de estos servicios son
App Engine y Google Kubernetes Engine, que analizaremos en otros cursos.

Cuando crea una VM en Google Cloud, se registra su nombre simbólico en un

servicio de DNS interno que lo traduce a la dirección IP interna. El DNS está
orientado a la red, por lo que puede traducir las URLs web y los nombres de las VMs
de hosts de la misma red, pero no puede traducir los de las VMs de otras redes.

La otra dirección IP es la externa, pero es opcional. Puede asignar una dirección IP

externa si su dispositivo o máquina son externos. La dirección IP externa se puede
asignar desde un grupo, lo que la hará efímera. Otra opción es asignarla a una
dirección IP externa reservada, lo que la convertirá en estática. Si reserva una
dirección IP externa estática y no la asigna a un recurso, como una instancia de VM o
una regla de reenvío, se le cobrará una tarifa más alta que por las otras direcciones
IP externas estáticas y efímeras que estén en uso.

Para obtener más información sobre este tema, consulte la página de

documentación. Puede usar sus propios prefijos de direcciones IP enrutables de
forma pública como direcciones IP externas de Google Cloud y anunciarlos en
Internet. A fin de ser apto, debe ser propietario de un bloque de /24 o superior.

Si desea ver una explicación rápida sobre las direcciones IP internas y externas en
Google Cloud, consulte esta demostración.
 Información confidencial de Google

Las IP externas están asignadas a IP internas

Nombre Zona Tipo de máquina Recomendación Usada por IP interna IP externa Conexión

instancia-1 1 CPU virtual, 3.75 GB

$ sudo /sbin/ifconfig
eth0
Link encap:Ethernet HWaddr [Link]
inet addr:[Link] Bcast:[Link] Mask:[Link]
UP BROADCAST RUNNING MULTICAST MTU:1460 Metric:1
RX packets:397 errors:0 dropped:0 overruns:0 frame:0
TX packets:279 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:66429 (64.8 KiB) TX bytes:41662 (40.6 KiB)
lo
Link encap:Local Loopback
inet addr:[Link] Mask:[Link]
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Sin importar si usa una dirección IP efímera o estática, el SO de la VM no la

conocerá. La dirección IP externa se asigna a la dirección interna de la VM con
transparencia por medio de la VPC. Con el fin de demostrarlo, ejecutaremos ifconfig
en una VM de Google Cloud, que solo muestra una dirección IP interna.

Con el fin de analizar esto en más detalle, veamos la resolución de DNS para
direcciones internas y externas.
 Información confidencial de Google

Resolución de DNS para direcciones internas

Cada instancia tiene un nombre de host que se puede resolver

en una dirección IP interna:
● El nombre del host es igual al nombre de la instancia.
● FQDN es [hostname].[zone].c.[project-id].internal
Ejemplo: [Link]

La resolución de nombres se controla con una resolución de

DNS interna:
● Se entrega como parte de Compute Engine ([Link]).
● DHCP lo configuró para el uso en la instancia.
● Entrega respuestas para direcciones internas y externas.

Comencemos por las direcciones internas.

Cada instancia tiene un nombre de host que se puede resolver en una dirección IP
interna. El nombre del host es igual al nombre de la instancia. También hay un
nombre de dominio interno completamente calificado (o FQDN) para una instancia
que usa el formato que se muestra en la diapositiva.

Si borra una instancia y vuelve a crearla, es posible que cambie la dirección IP

interna. Esto puede interrumpir las conexiones de otros recursos de Compute Engine,
que deberán tener la dirección IP nueva para conectarse nuevamente. Sin embargo,
el nombre del DNS siempre dirige a una instancia específica, sin importar cuál sea la
dirección IP interna.

Cada instancia tiene un servidor de metadatos que también actúa como agente de
resolución de DNS para esa instancia. El servidor de metadatos controla todas las
consultas de DNS de los recursos de la red local y enruta todas las demás consultas
a los servidores DNS públicos de Google para obtener una resolución de nombre
pública. Anteriormente, mencionamos que las instancias no conocen las direcciones
IP externas que se les asignan. En cambio, la red almacena una tabla de consulta
que combina las direcciones IP externas con las internas de las instancias relevantes.
Para obtener más información, incluida la manera de configurar su propio agente de
resolución en instancias, consulte la página de documentación.
 Información confidencial de Google

Resolución de DNS para direcciones internas

● Las instancias con direcciones IP externas pueden permitir

conexiones desde hosts fuera del proyecto.
○ Los usuarios se conectan directamente con direcciones
IP externas.
○ Los administradores también pueden publicar registros
DNS públicos que se dirigen a la instancia.
■ Los registros DNS públicos no se publican automáticamente.

● Los registros DNS para direcciones externas se pueden publicar

con servidores DNS existentes (fuera de Google Cloud).

● Las zonas del DNS se pueden alojar en Cloud DNS.

Ahora analicemos las direcciones externas.

Las instancias con direcciones IP externas pueden permitir conexiones desde hosts
fuera del proyecto. Los usuarios también pueden hacerlo de forma directa con la
dirección IP externa. Los registros DNS públicos que dirigen a las instancias no se
publican automáticamente. Sin embargo, los administradores pueden publicarlos con
los servidores DNS existentes.

Los servidores de nombres de dominios se pueden alojar en Google Cloud con

Cloud DNS. Este es un servicio administrado que definitivamente vale la pena
considerar, así que lo analizaremos en profundidad.
 Información confidencial de Google

Aloje zonas del DNS con Cloud DNS

Cloud DNS
● Servicio DNS de Google

● Convierte los nombres de dominio

en direcciones IP

● Latencia baja

● Alta disponibilidad (ANS de 100% de

tiempo de actividad)

● Crea y actualiza millones de registros DNS

● IU, línea de comandos o API

Cloud DNS es un servicio de sistema de nombres de dominio (DNS) autorizado,

escalable, confiable y administrado que se ejecuta en la misma infraestructura que
Google. Cloud DNS transforma las solicitudes de los nombres de dominios, como
[Link], en direcciones IP.

Cloud DNS usa la red global de Google de los servidores de nombres de Anycast
para entregar sus zonas del DNS desde ubicaciones redundantes en todo el mundo,
lo que permite ofrecer una latencia más baja y alta disponibilidad a sus usuarios. La
alta disponibilidad es muy importante porque, si no puede buscar el nombre de un
dominio, es posible que no tenga conexión a Internet. Por eso, Google Cloud ofrece
un Acuerdo de Nivel de Servicio (ANS) con 100% de tiempo de actividad para
dominios configurados en Cloud DNS. Si desea obtener más información sobre el
ANS, consulte la página de documentación.

Con Cloud DNS, puede crear y actualizar millones de registros DNS sin preocuparse
de administrar sus propios servidores DNS ni software. En lugar de ello, puede usar
una interfaz de usuario simple, una interfaz de línea de comandos o una API. Para
obtener más información sobre Cloud DNS, consulte esta página de documentación.
 Información confidencial de Google

Asigne un rango de direcciones IP como alias de una

interfaz de red de VM que usa rangos de alias de IP

IP primaria
de
VM [Link]

VM Subred:
Rango de CIDR primario [Link]/16
Contenedor Rango de CIDR secundario [Link]/20

Rango de alias de IP
de VM: [Link]/24

Otra función de las redes de Google Cloud son los rangos de alias de IP.

Estos le permiten asignar un rango de direcciones IP internas como un alias a una

interfaz de red de una máquina virtual. Esto es útil si tiene varios servicios
ejecutándose en una VM y desea asignar una dirección IP a cada uno.

En términos sencillos, puede configurar varias direcciones IP que representen los

contenedores o las aplicaciones que se alojan en una VM, sin necesidad de definir
una interfaz de red por separado. Solo debe obtener el rango de alias de IP de los
rangos CIDR principales o secundarios de la subred local. En este diagrama, se
proporciona una ilustración básica de los rangos de CIDR principales y secundarios,
y de los rangos de alias de IP de la VM.

Para obtener más información sobre los rangos de alias de IP, consulte la página de
documentación.
 Información confidencial de Google

Rutas y reglas

04
de firewall

Hasta ahora, aprendió sobre los proyectos, las redes, las subredes y las direcciones
IP. Usemos esa información para comprender de qué manera Google Cloud enruta el
tráfico.
 Información confidencial de Google

Una ruta es una asignación de

un rango de IP a un destino
Rutas de Cloud
Cada red tiene los siguientes elementos:
● Rutas que permiten a las instancias de una red enviarse
tráfico directamente entre ellas

● Una ruta predeterminada que dirige los paquetes a destinos

que están fuera de la red

Las reglas de firewall también deben autorizar los paquetes.

De forma predeterminada, cada red tiene rutas que permiten a las instancias de una
red enviarse el tráfico directamente entre ellas, incluso entre subredes. Además, cada
red tiene una ruta predeterminada que dirige los paquetes a destinos fuera de ella. A
pesar de que las rutas satisfacen la mayor parte de sus necesidades comunes de
enrutamiento, también puede crear rutas especiales que anulen a las otras.

El solo hecho de crear una ruta no garantiza que sus paquetes se recibirán en el
siguiente salto que indique. Las reglas de firewall también deben autorizar los
paquetes.

La red predeterminada tiene reglas de firewall preconfiguradas que permiten que

todas las instancias de la red se comuniquen entre ellas. Las redes creadas de forma
manual no tienen esas reglas, por lo que usted debe crearlas, tal como lo verá en el
primer lab.
 Información confidencial de Google

Las rutas asignan tráfico a redes de destino

Tabla de
enrutamiento de VM
● Se aplican al tráfico que sale de una VM.
[Link]/24 [Link]/24
● Desvían tráfico a la ruta más específica. [Link]/20
[Link]/20
● Se crean cuando se crea una subred. [Link]/0

● Habilitan VMs en la misma red para

comunicarse. [Link]/20
● El destino está en notación CIDR.
Internet
● El tráfico solo se entrega si también
coincide con una regla de firewall.

[Link]/20 [Link]/0

Las rutas hacen coincidir los paquetes según su dirección IP de destino. Sin
embargo, no se permitirá el tráfico que no coincida con una regla de firewall
específica.

Las rutas se crean cuando se crean las redes, lo que permite la entrada de tráfico
desde “cualquier lugar”. También se crean rutas cuando se crean subredes. Esto
permite que las VMs de una misma red se comuniquen entre ellas.

En esta diapositiva, se muestra una tabla de enrutamiento simplificada, pero

veámosla con más detalle.
 Información confidencial de Google

Tablas de enrutamiento de instancias

[Link]/16 -> default-route-78…

[Link]./0 -> default-route-6807… vpngateway

[Link]/16 -> default-route-78…

[Link]./0 -> default-route-6807…
Internet [Link]/16 -> vpngateway

vm2

[Link]/16 -> default-route-78…

vm1 [Link]./0 -> default-route-6807…
[Link]/16 -> vpngateway

Todas las rutas de la colección Rutas pueden aplicarse a una o más instancias. Las
rutas se aplican a una instancia si coinciden la red y las etiquetas de la instancia. Si
la red coincide y no se especificaron etiquetas de instancias, se aplica la ruta a todas
las instancias de la red. Luego, Compute Engine usa la colección Rutas a fin de crear
tablas de enrutamiento de solo lectura para cada instancia.

En este diagrama, se muestra un router virtual con alta escalabilidad en el centro de

cada red. Cada instancia de máquina virtual de la red está conectada directamente
con el router. Además, todos los paquetes que salen de una instancia de máquina
virtual se administran en esta capa antes de enviarlos al siguiente salto. Para elegir el
siguiente salto de un paquete, el router de la red virtual consulta la tabla de
enrutamiento de esa instancia.
 Información confidencial de Google

Las reglas de firewall protegen sus instancias

de VM de las conexiones no autorizadas
Reglas de
● Las redes de VPC funcionan como un firewall distribuido.
firewall de
Cloud
● Las reglas de firewall se aplican a toda la red.

● Las conexiones se permiten o rechazan a nivel de cada instancia.

● Las reglas de firewall son reglas con estado.

● Existen reglas implícitas para denegar todas las entradas y permitir

todas las salidas.

Las reglas de firewall de Google Cloud protegen sus instancias de máquinas virtuales
de las conexiones no autorizadas entrantes y salientes, conocidas como de entrada y
salida, respectivamente. En términos sencillos, cada red de VPC funciona como un
firewall distribuido.

Aunque las reglas de firewall se aplican a toda la red, las conexiones se permiten o
rechazan a nivel de cada instancia. Puede pensar que el firewall existe no solo entre
sus instancias y otras redes, sino también entre instancias individuales dentro de la
misma red.

Las reglas de firewall de Google Cloud tienen estado. Esto significa que, si se
permite una conexión entre un origen y un objetivo o entre un objetivo y un destino,
se permitirá todo el tráfico posterior en cualquier dirección. Es decir, las reglas de
firewall permiten la comunicación bidireccional una vez que se establece una sesión.

Además, si por algún motivo se borran todas las reglas de firewall de una red, aún
hay una regla de entrada implícita llamada “Rechazar todo” y otra de salida llamada
“Permitir todo” en la red.
 Información confidencial de Google

Una regla de firewall se compone de…

Parámetro Detalles

Las conexiones de entrada se comparan solo con las reglas de ingress.

direction
Las conexiones de salida se comparan solo con las reglas de egress.

Para la dirección ingress, sources se puede especificar como parte de la regla con direcciones IP, etiquetas de origen
source o o una cuenta de servicio de origen.
destination
Para la dirección egress, destinations se puede especificar como parte de una regla con uno o más rangos de
direcciones IP.

protocol Cualquier regla se puede restringir para que se aplique solo a protocolos o solo a combinaciones específicas de protocolos
y port y puertos.

action Permite o rechaza los paquetes que coincidan con la instrucción, el protocolo, el puerto y el origen o el destino de la regla.

priority Establece el orden en que se evalúan las reglas; se aplica la primera regla que coincide.

Rule
assignment Todas las reglas se asignan a todas las instancias, pero puede asignar algunas de ellas solo a ciertas instancias.

Puede indicar la configuración que desea para su firewall como un conjunto de

reglas. Desde una perspectiva conceptual, una regla de firewall se compone de los
siguientes parámetros:

● La instrucción (direction) de la regla. Las conexiones de entrada se

comparan solo con las reglas de entrada (ingress), mientras que las
conexiones de salida se comparan con las reglas de salida (egress).
● El origen (source) de la conexión de los paquetes de entrada o el destino
(destination) de la conexión de los paquetes de salida.
● El protocolo (protocol) y el puerto (port) de la conexión, en los que se
pueden restringir las reglas para que se apliquen solo a protocolos
específicos o solo a combinaciones específicas de protocolos y puertos.
● La acción (action) de las reglas, que es permitir o rechazar los paquetes que
coincidan con la instrucción, el protocolo, el puerto y el origen o el destino de
la regla.
● La prioridad (priority) de las reglas, que se encarga del orden en que estas
se evalúan. Se aplica la primera regla coincidente.
● La asignación de la regla (rule assignment). De forma predeterminada, todas
las reglas se asignan a todas las instancias, pero puede asignar algunas de
ellas solo a ciertas instancias.
Para obtener más información sobre los componentes de las reglas de firewall,
consulte la página de documentación.

Analicemos algunos casos de uso del firewall de Google Cloud para salidas y
entradas.
 Información confidencial de Google

Caso de uso del firewall de Google Cloud: salida

Hosts externos Condiciones:

VM ● Rangos CIDR de destino
● Protocolos
● Puertos

Acción:
Firewalls (salida) Firewalls (salida)
● allow: autoriza la conexión
VM VM
de salida coincidente
● deny: bloquea la conexión
Red virtual de Red virtual de
Google Cloud Google Cloud de salida coincidente

Las reglas de firewall de salida controlan las conexiones salientes desde la red de
Google Cloud. Las reglas allow de salida permiten las conexiones salientes que
coinciden con las direcciones IP, el protocolo y los puertos específicos. Las reglas
deny de salida evitan que las instancias inicien conexiones que coincidan con
combinaciones de rangos de IP, puertos o protocolos no permitidos.

En el caso de las reglas de firewall de salida, los destinos a los que se aplica la regla
podrían indicarse con los rangos de IP de CIDR. Específicamente, puede usar rangos
de destino para protegerse contra las conexiones no deseadas que inicie una
instancia de VM hacia un host externo, tal como se muestra a la izquierda. También
puede usar los rangos de destino para evitar las conexiones no deseadas desde
instancias de VM internas a un rango de CIDR específico de Google Cloud. Esto se
demuestra en el centro, en el que una VM de una subred específica intenta
conectarse de forma inapropiada a otra de la misma red.
 Información confidencial de Google

Caso de uso del firewall de Google Cloud: entrada

Hosts externos Condiciones:

VM ● Rangos de CIDR de origen
● Protocolos
● Puertos

Acción:
Firewalls (entrada) Firewalls (entrada)
● allow: autoriza la conexión
VM VM
de entrada coincidente
● deny: bloquea la conexión
Red virtual de Red virtual de
Google Cloud Google Cloud de entrada coincidente

Las reglas de firewall de entrada lo protegen contra las conexiones entrantes a la

instancia desde cualquier origen. Las reglas allow de entrada permiten que se
conecten direcciones IP, puertos y protocolos específicos. El firewall evita que las
instancias reciban conexiones en puertos o protocolos no permitidos. Se pueden
restringir las reglas para que se apliquen solo a algunos orígenes.
Los rangos de CIDR de origen pueden usarse para proteger una instancia de las
conexiones no deseadas que provengan de redes externas o de rangos de IP de
Google Cloud.

En este diagrama, se muestra una VM que recibe una conexión desde una dirección
externa y otra que recibe una conexión de otra VM desde la misma red. A fin de
controlar las conexiones de entrada desde una instancia de VM, cree condiciones
para las conexiones entrantes con rangos de CIDR de origen, protocolos o puertos.
 Información confidencial de Google

Precios

05
Antes de poner en práctica lo que aprendió, hablemos sobre los precios de red. Es
importante que comprenda las circunstancias en las que se le factura por la red de
Google Cloud.
 Información confidencial de Google

Precios de red (sujetos a cambios)

Tipo de tráfico Precio

Entrada Sin cargo

Salida a la misma zona (dirección IP interna) Sin cargo

Salida a productos de Google (YouTube, Maps, Drive) Sin cargo

Salida a un servicio distinto de Google Cloud (dentro de la misma región; Sin cargo

con excepciones)

Salida entre zonas de la misma región (por GB) $0.01

Salida a la misma zona (dirección IP externa, por GB) $0.01

Salida entre regiones dentro de Canadá y [Link]. (por GB) $0.01

Salida entre regiones, sin incluir el tráfico entre regiones de [Link]. Depende de la región

Esta tabla forma parte de la documentación de Compute Engine y, en ella, se indican

los precios de cada tipo de tráfico.

En primer lugar, no se cobra por la entrada o el tráfico que llega a la red de

Google Cloud, a menos que exista un recurso, como un balanceador de cargas, que
esté procesando el tráfico de entrada. Se cobran las respuestas a solicitudes, ya que
cuentan como tráfico de salida.

En el resto de la tabla, se muestra la salida o el tráfico que sale de una máquina

virtual. El tráfico de salida a la misma zona no se cobra, siempre que esa salida sea
por medio de la dirección IP interna de una instancia. Tampoco se cobran el tráfico de
salida a productos de Google, como YouTube, Maps o Drive, ni el tráfico a un servicio
distinto de Google Cloud dentro de la misma región.

Sin embargo, sí se cobra la salida entre zonas de la misma región y la salida dentro
de una zona si el tráfico ocurre por medio de una dirección IP externa de una
instancia y la salida entre regiones.

En cuanto a la diferencia en el tráfico de salida a la misma zona, Compute Engine no

puede determinar la zona de una máquina virtual a través de la dirección IP externa.
Por lo tanto, este tráfico se considera de salida entre zonas de la misma región.
Además, existen algunas excepciones y los precios siempre pueden cambiar, por lo
que recomendamos consultar la página de documentación.
 Información confidencial de Google

Precios de dirección IP externa (us-central1)

(Sujetos a cambios)

Tipo Precio/hora (USD)

Dirección IP estática (asignada, pero sin usar) $0.010

Direcciones IP estáticas y efímeras utilizadas en instancias de VM estándar $0.004

Direcciones IP estáticas y efímeras en uso en instancias de VM interrumpibles $0.002

Direcciones IP estáticas y efímeras vinculadas a reglas de reenvío Sin cargo

Ahora bien, se le cobra por direcciones IP externas estáticas y efímeras. En esta

tabla, se muestran los precios de dirección IP externa para us-central1 cuando se
grabó esta presentación.

Como seguramente notó, si reserva una dirección IP externa estática y no la asigna a

un recurso, como una instancia de VM o una regla de reenvío, se le cobrará una
tarifa más alta que por las otras direcciones IP externas estáticas y efímeras que
estén en uso. Además, las direcciones IP externas en VMs interrumpibles tiene un
precio inferior al de las instancias de VM estándar.

Recuerde que los precios siempre pueden cambiar, por lo que recomendamos
consultar la página de documentación.
 Información confidencial de Google

Estime los costos con la calculadora de precios

de Google Cloud

Moneda estimada

USD: dólar estadounidense

Ajustar plazo estimado

Compute  Red de 1 día 1 semana 1 mes 1 trimestre 1 año 3 años

Engine la nube

100 GB de
n1-standard-1
salida/mensual
us-central1
América y EMEA

Recomendamos usar la calculadora de precios de Google Cloud para estimar el

costo de un conjunto de recursos porque cada servicio tiene su propio modelo de
precios. La calculadora de precios es una herramienta basada en la Web que puede
usar para especificar el consumo esperado de ciertos servicios y recursos para
obtener un costo estimado.

Por ejemplo, puede especificar un tipo de instancia en particular en una región

específica y 100 GB de tráfico de salida mensual a América y EMEA. Luego, la
calculadora de precios le mostrará el costo total estimado. Puede ajustar la moneda y
el período necesario para satisfacer sus necesidades y, cuando termine, puede
enviar la estimación por correo electrónico o guardarla en una URL específica con el
fin de consultarla en el futuro.

Para utilizar la calculadora de precios ahora mismo, consulte la página de

documentación.
 Información confidencial de Google

Introducción al lab
Redes de VPC

Apliquemos en un lab algunas de las funciones de red que acabamos de analizar.

 Información confidencial de Google

Objetivos del lab

01 Explorar la red de VPC predeterminada

02 Crear una red de modo automático con reglas

de firewall

Convertir una red de modo automático en una

03 red de modo personalizado

Crear redes de VPC de modo personalizado

04 con reglas de firewall

05 Crear instancias de VM mediante Compute Engine

Explorar la conectividad de las instancias

06 de VM entre las redes de VPC

En este lab, creará una red de VPC de modo automático con reglas de firewall y dos
instancias de VM. Luego, convertirá la red de modo automático en una red de modo
personalizado y creará otras redes de este tipo, como se muestra en el diagrama de
red. También explorará la conectividad entre las redes.
 Información confidencial de Google

VPC Network:mynetwork Puerta de enlace de Internet

Cloud Virtual Network

Región: us-central1 Región: europe-west1

VMs VMs
Subred: Subred:
Compute Engine Compute Engine
(Modo automático) (Modo automático)

VPC Network:management Puerta de enlace de Internet

Cloud Virtual Network

Región: us-central1

VMs
Subred:
Compute Engine
(Personalizada)

VPC Network:privatenet Puerta de enlace de Internet

Cloud Virtual Network

Región: us-central1 Región: europe-west1

VMs
Subred: Subred:

Compute Engine
(Personalizada) (Personalizada)
 Información confidencial de Google

Diseños comunes

06
de redes

Usemos lo que aprendimos hasta ahora y analicemos diseños de red comunes.

“Común” es un término bastante relativo. Aunque podríamos pasar todo el día

hablando de los diseños de red, elegimos un conjunto que se relaciona mejor con
este módulo.
 Información confidencial de Google

Disponibilidad aumentada con varias zonas

Proyecto
Red
Región: us-west1
zona: us-west-1a zona: us-west-1b

Para comenzar, veamos la disponibilidad.

Si su aplicación necesita más disponibilidad, puede colocar dos máquinas virtuales

en múltiples zonas (pero dentro de la misma subred), como se muestra en esta
diapositiva. Con una sola subred, puede crear una regla de firewall para la subred
[Link]/16.

Por lo tanto, si asigna las VMs en una sola subred para separar zonas, obtendrá
disponibilidad mejorada sin la complejidad de seguridad adicional. Un grupo de
instancias administrado regional contiene instancias de múltiples zonas en la misma
región, que ofrece mayor disponibilidad.
 Información confidencial de Google

Globalización con varias regiones

Proyecto
Red

región: us-east1 región: us-west1

zona: us-east-1a zona: us-west-1b

A continuación, analicemos la globalización.

En el diseño anterior, colocamos recursos en zonas diferentes dentro de una sola

región, lo que ofrece aislamiento de muchos tipos de fallas de infraestructura,
hardware y software. Ubicar recursos en diferentes regiones como se muestra en
esta diapositiva proporciona un mayor grado de independencia ante fallas. Esto le
permite diseñar sistemas sólidos mediante la distribución de recursos en diferentes
dominios con fallas.

Cuando usa un balanceador de cargas global, como el balanceador de cargas de

HTTP, puede enrutar el tráfico a la región más cercana al usuario. Esto puede
generar mejor latencia para los usuarios y costos más bajos de tráfico de red en su
proyecto.

Exploraremos ambos grupos de instancias administrados y el balanceador de cargas

más adelante en el curso.
 Información confidencial de Google

Cloud NAT proporciona acceso a Internet para

instancias privadas
Red: my-private-network

Instancias
de aplicación

Subred IPv4: [Link]/16

Actualizar
servidor

Cloud NAT
Instancias
de aplicación

Subred IPv4: [Link]/16

Acceso no
autorizado
región us-west1

Privada Pública

Como práctica recomendada de seguridad general, sugerimos que, cuando sea

posible, use solo direcciones IP internas asignadas a sus instancias de VM.

Cloud NAT es el servicio de traducción de direcciones de red de Google. Le permite

aprovisionar sus instancias de aplicaciones sin direcciones IP públicas y, al mismo
tiempo, les permite acceder a Internet de forma eficaz y controlada. Esto significa que
sus instancias privadas pueden acceder a Internet para obtener actualizaciones,
parches, administración de configuración y más.

En este diagrama, Cloud NAT permite que dos instancias privadas accedan a un
servidor de actualización en Internet, que se denomina NAT de salida. Sin embargo,
Cloud NAT no implementa NAT de salida. En otras palabras, los hosts fuera de su red
de VPC no pueden acceder directamente a las instancias privadas detrás de la
puerta de enlace de Cloud NAT. Esto ayuda a mantener sus redes de VPC aisladas y
seguras.
 Información confidencial de Google

Acceso privado a los servicios y las API de Google

Servicios y API de Google
Internet
Direcciones IP públicas
Tráfico a los servicios y las API de Google

Tráfico a Internet

Proyecto

Red de VPC Puerta de enlace

de Internet

Enrutamiento
de VPC

Región: us-west1 Región: us-east1

VM A1 VM A2 VM B1 VM B2

e IP pública e IP pública

subred-a: Acceso privado a Google activado subred-b: Acceso privado a Google desactivado

Del mismo modo, debe habilitar el Acceso privado a Google a fin de permitir que solo
instancias de VM que tienen direcciones IP internas lleguen a direcciones IP externas
de los servicios y las API de Google. Por ejemplo, si su instancia de VM necesita
acceder a un bucket de Cloud Storage, debe habilitar el Acceso privado a Google.

Debe habilitar el Acceso privado a Google en cada subred. Como puede ver en este
diagrama, el Acceso privado a Google está habilitado en la subred-a e inhabilitado en
la subred-b. Esto permite que la VM A1 acceda a los servicios y las API de Google,
aunque no tenga una dirección IP externa.

El Acceso privado a Google no influye en las instancias que tienen direcciones IP

externas. Por eso, las VMs A2 y B2 pueden acceder a los servicios y las
API de Google. La única VM que no puede acceder a esos servicios y API es la VM
B1. Esta no tiene una dirección IP pública y es una subred en la que está inhabilitado
el Acceso privado a Google.
 Información confidencial de Google

Introducción al lab
Implemente el
Acceso privado a Google y Cloud NAT

Apliquemos en un lab dos de los diseños de red comunes que acabamos de analizar.
 Información confidencial de Google

Objetivos del lab

Configurar una instancia de VM que no

01 tenga una dirección IP externa

Conectarse a una instancia de VM mediante

02 un túnel Identity-Aware Proxy (IAP)

03 Habilitar el Acceso privado a Google
en una subred

04 Configurar una puerta de enlace de Cloud NAT

Verificar el acceso a las direcciones IP públicas

05 de los servicios y las API de Google y otras
conexiones a Internet

En este lab, implementará el Acceso privado a Google y Cloud NAT en una instancia
de VM que no tenga una dirección IP externa. Luego, verificará el acceso a las
direcciones IP públicas de los servicios y las API de Google, y otras conexiones a
Internet.

Con Cloud IAP, puede habilitar el acceso adaptado al contexto de las VMs a través
de SSH y RDP sin hosts de bastión. Para obtener más información sobre este tema,
consulte la página de documentación.
 Información confidencial de Google

Cuestionario
 Información confidencial de Google

Pregunta nº 1
Pregunta

¿Cuál es la cantidad mínima de direcciones IP que necesita una instancia de VM en Google Cloud?

A. Una: solo una dirección IP interna
B. Dos: una dirección IP interna y otra externa
C. Tres: una dirección IP interna, una externa y una de alias
 Información confidencial de Google

Pregunta nº 1
Respuesta

¿Cuál es la cantidad mínima de direcciones IP que necesita una instancia de VM en

Google Cloud?
A. Una: solo una dirección IP interna
B. Dos: una dirección IP interna y otra externa
C. Tres: una dirección IP interna, una externa y una de alias

Explicación:
En Google Cloud, cada máquina virtual debe tener una dirección IP interna. La
dirección IP externa es opcional; por lo tanto, una instancia de VM solo necesita una
sola dirección IP.
 Información confidencial de Google

Pregunta nº 2
Pregunta

¿Cuáles son los tres tipos de redes que se ofrecen en Google Cloud?

A. Zonal, regional y global
B. Red de 1 gigabit, red de 10 gigabits y red de 100 gigabits
C. Red predeterminada, red de modo automático y red de modo personalizado
D. Red IPv4 de unidifusión, red IPv4 de multidifusión, red IPv6
 Información confidencial de Google

Pregunta nº 2
Respuesta

¿Cuáles son los tres tipos de redes que se ofrecen en Google Cloud?

A. Zonal, regional y global
B. Red de 1 gigabit, red de 10 gigabits y red de 100 gigabits
C. Red predeterminada, red de modo automático y red de modo personalizado
D. Red IPv4 de unidifusión, red IPv4 de multidifusión, red IPv6

Explicación:
Los tres tipos de red que ofrece Google Cloud son: predeterminada, automática y
personalizada.

Cada proyecto comienza con una red predeterminada. La red automática usa los
mismos rangos de IP de subred que la predeterminada, pero con otro nombre de red.
Una red personalizada le permite especificar los rangos de IP de las subredes.
 Información confidencial de Google

Pregunta nº 3
Pregunta

¿Cuál es la ventaja de aplicar reglas de firewall según la etiqueta y no según la dirección?

A. Las etiquetas ayudan a las organizaciones a hacer un seguimiento de la facturación
del firewall.
B. Las etiquetas del tráfico de red permiten realizar análisis de redes.
C. Las etiquetas de las reglas de firewall controlan qué direcciones IP efímeras recibirán
las VMs.
D. Cuando se crea una VM con una etiqueta afín, se aplican las reglas de firewall,
independientemente de la dirección IP a la que se asigne.
 Información confidencial de Google

Pregunta nº 3
Respuesta

¿Cuál es la ventaja de aplicar reglas de firewall según la etiqueta y no según la dirección?

A. Las etiquetas ayudan a las organizaciones a hacer un seguimiento de la facturación
del firewall.
B. Las etiquetas del tráfico de red permiten realizar análisis de redes.
C. Las etiquetas de las reglas de firewall controlan qué direcciones IP efímeras recibirán
las VMs.
D. Cuando se crea una VM con una etiqueta afín, se aplican las reglas de firewall,
independientemente de la dirección IP a la que se asigne.

Explicación:
Cuando se crea una VM, la dirección IP externa efímera se asigna de entre los
valores de un grupo. No hay forma de predecir la dirección que se asignará, por lo
que no es posible escribir una regla que coincida con la dirección IP de la VM antes
de que se asigne. Las etiquetas permiten una asignación simbólica que no depende
del orden de las direcciones IP. Eso hace que las reglas de firewall sean más
simples, más generales y más fáciles de mantener.
 Información confidencial de Google

Repaso: Redes virtuales

En este módulo, presentamos una descripción general de las nubes privadas

virtuales de Google. Vimos los distintos componentes de las VPC, como los
proyectos, las redes, las direcciones IP, las rutas y las reglas de firewall.

También entregamos una descripción general breve de la forma en que las opciones
de diseño de la red pueden afectar la facturación. Luego, aplicamos los diferentes
conceptos en un lab minucioso.

A continuación, observamos diseños de red comunes y pudimos implementar el

Acceso privado a Google y Cloud NAT en un lab.

Ahora que tiene una perspectiva sólida de la forma en que Google Cloud implementó
las redes, aprenderemos de otros servicios. Hablemos sobre Compute Engine, que
ofrece máquinas virtuales escalables y de alto rendimiento.