En la entrada anterior, se exploró el servicio de Azure Storage. Uno de los otros servicios básicos para las aplicaciones en la nube es Redes de Azure. Azure tiene un montón de potentes funciones de red para asegurar y enrutar su tráfico a una escala verdaderamente global. Estas funciones están diseñadas para ayudarle a centrarse en cómo compilar y mantener sus aplicaciones, de modo que no tenga que preocuparse por detalles como direcciones IP y redirección de tablas. Si compila y ejecuta una tienda en línea para gestionar pedidos de pizza, debe transmitir los datos del cliente y procesar las transacciones de pago de forma segura.
En este capítulo se examinan las redes y subredes virtuales de Azure, y se analiza cómo crear interfaces de red virtuales. Para asegurar y controlar el flujo de tráfico, cree grupos y reglas de seguridad de red. Si la red es nueva para usted, o si hace tiempo que no tiene que trabajar con direcciones IP y tarjetas de red, puede que este capítulo le tome un poco más de tiempo. Tiene muchos ejercicios Pruébelo ahora. Sin embargo, vale la pena que se tome el tiempo para entender este capítulo, ya que el trabajo en red es clave para muchos de los servicios de Azure.
Componentes de las redes virtuales
Piense en cuántos cables hay detrás del escritorio de su equipo o en su centro de entretenimiento. Ahora, piense en todos los cables necesarios para conectar los equipos en un piso dado de un edificio de oficinas. ¿Y qué pasa con el edificio de oficinas en su totalidad? ¿Ha estado alguna vez en un centro de datos o ha visto fotos de uno? Intente imaginar lo grande que son los centros de datos de Azure. Ahora intente imaginar docenas de centros de datos Azure en todo el mundo. Las matemáticas no son mi punto fuerte, así que ni siquiera puedo calcular cuántos kilómetros y kilómetros de cables de red se utilizan para llevar todo el tráfico en Azure.
La conectividad de red es una parte crucial de la vida moderna. En Azure, la red es fundamental para la forma en que se comunica todo. Para todos los miles de dispositivos de red físicos y kilómetros de cables de red que conectan todo en un centro de datos de Azure, se trabaja con recursos de red virtuales. ¿Cómo? Redes definidas por software. Cuando crea una VM o una aplicación web, no es necesario que un técnico corra por el centro de datos de Azure para conectar cables físicamente ni asignar direcciones IP (¡aunque sería divertido de ver!). En lugar de ello, la plataforma Azure maneja lógicamente todos los recursos de red que definen todo su entorno de red. En la figura siguiente se muestran los componentes de red virtuales que compilará a medida que trabaje en este capítulo.
Algunos de los componentes de red se abstraen si utiliza recursos PaaS. Los componentes principales que utiliza para las VM son los siguientes:
– Redes y subredes virtuales (incluidas las agrupaciones de direcciones IP).
– Tarjetas de interfaz de red virtuales.
– Una o más direcciones IP públicas.
– Nombre DNS interno y nombres DNS públicos opcionales para resolución de nombres externos.
– Reglas y grupos de seguridad de red, que aseguran y controlan el flujo de tráfico de red como lo hace un firewall normal.
Redes y subredes virtuales
Cuando creó una VM en el capítulo 2, no tuvo que ajustar ningún parámetro de red. La plataforma Azure puede crear estos recursos automáticamente con nombres y ámbitos de dirección IP predeterminados. En esta sección, creará los recursos de red con antelación y veamos cómo funcionan para una VM.
Pruébelo ahora
La creación de redes suele ser más fácil de visualizar cuando se ve en acción. Utilizará Azure Portal para empezar, lo que acaba suponiendo bastantes pasos separados, pero verá la potencia de la CLI de Azure más adelante en el capítulo.
No se preocupe demasiado sobre cómo utilizar sus propios espacios de direcciones o nombres de DNS personalizados en este momento. Complete los siguientes pasos para crear la red y subred virtuales:
1 Abra Azure Portal y seleccione Crear un recurso en la esquina superior izquierda del panel.
2 Seleccione Redes en la lista de servicios de Marketplace y, a continuación, seleccione Red virtual.
3 Escriba un nombre para la red virtual, como vnetmol.
4 Si quiere jugar un poco más, cambie la dirección a 10.0.0.0/16.
Intervalos de direcciones IP
Las redes virtuales abarcan cierto intervalo de IP: un espacio de direcciones. Si alguna vez ha visto una dirección IP, puede haberse fijado en la máscara de subred que, a menudo, es algo como 255.255.255.0. Esta máscara de subred suele utilizarse en un formato corto que especifica el tamaño del intervalo, como por ejemplo /24.
Azure Portal toma un espacio de direcciones /24 predeterminado. Aquí aumentaremos el número de intervalos IP adicionales sin demasiado conocimiento de redes, así que aumente el espacio de dirección a /16. Este tipo de dirección IP no se proporciona directamente a una VM; en el siguiente paso, creará una subred que cubre una sección más pequeña de este espacio de dirección.
Si los espacios de direcciones de red son totalmente ajenos para usted, no se preocupe; en su mayoría, no lidiará con ellos a diario. La gobernanza adecuada de Azure puede funcionar de la misma manera que lo hace en su mundo de TI local: un grupo de personas puede administrar las redes virtuales de Azure y usted implementa sus aplicaciones en un espacio creado previamente.
5 Cree un grupo de recursos, como azuremolchapter5 y, luego, seleccione una región de Azure cerca de usted.
6 Proporcione un nombre de subred, como websubnet, y escriba el intervalo de direcciones de subred 10.0.1.0/24. Este intervalo de direcciones forma parte de la red virtual más amplia especificada anteriormente. Más tarde, agregará otra subred.
7 Examine algunas de las otras opciones, como la protección contra la denegación de servicio distribuida (DDoS), los puntos de conexión de servicio y Azure Firewall. Deje los valores predeterminados por ahora, pero espero que este ejemplo le dé algunas pistas sobre lo que es posible más allá de una red virtual básica.
8 Cuando esté listo, cree la red y subred virtuales.
Tarjetas de interfaz de red virtuales.
Ahora que creó una red y subred virtuales, necesita conectarse una VM. Al igual que lo hace con un equipo de escritorio normal, un equipo portátil o una tableta, se utiliza una tarjeta de interfaz de red (NIC) para conectarse a la red virtual. Y no, ¡no hay Wi-Fi gratuito! Pero hay tamaños de VM en Azure que actualmente proporcionan hasta ocho NIC con velocidades de hasta 32 GBps, Aunque se me dieran bien las matemáticas, podría decir que estas cifras suman un gran ancho de banda.
Se puede estar preguntando por qué es necesario crear cada uno de estos recursos con anticipación. Puede hacer todo esto en el momento de crear una VM. Es cierto… pero dé un paso atrás y piense en los recursos de red como recursos de larga duración.
Los recursos de red existen de forma separada de los recursos de la VM, y pueden persistir más allá del ciclo de duración de una VM determinada. Este concepto le permite crear los recursos de red fijos y crear, eliminar y crear nuevamente una VM que conserve los mismos recursos de red, como direcciones IP y nombres DNS. Piense en una VM de laboratorio o en un entorno de desarrollo y prueba. Puede reproducir exactamente el mismo entorno de forma rápida, ya que solo cambia la VM.
Pruébelo ahora
Para crear una NIC, complete los pasos siguientes:
1 En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda del panel.
2 Busque y seleccione Interfaz de red y, a continuación, seleccione Crear.
3 Proporcione un nombre para la interfaz de red, como webvnic; luego, seleccione la red y subred virtuales que creó en el ejercicio anterior.
4 Antes he hablado de los recursos de larga duración; ahora puede ver cómo funcionan. Cree una asignación de dirección IP estática que utilice la dirección 10.0.1.4.
CONSEJO ¿Por qué .4? ¿Qué pasa con las primeras tres direcciones en el espacio de direcciones? Azure reserva las primeras tres direcciones IP en cada intervalo para su propia administración y enrutamiento. La primera dirección que se puede utilizar en cada intervalo es .4.
5 No cree un grupo de seguridad de red por ahora; volverá a esto en unos minutos. Si es experto en IPv6, puede activar el cuadro de Dirección IP privada (IPv6) y escribir un nombre; de lo contrario, continúe con IPv4.
6 Seleccione el grupo de recursos existente del ejercicio anterior y, a continuación, elija crear la NIC en la misma región que la red virtual.
7 Cuando esté listo, cree la NIC.
Separación de funciones en Azure
No tiene que crear otros procesos dentro del mismo grupo de recursos que su red virtual. Vuelva a pensar en el concepto de gobernanza de Azure que se analizó anteriormente. Puede tener un grupo de ingenieros de red que administren todos los recursos de red virtual en Azure. Cuando se crean recursos para las aplicaciones, como las VM, los crea y administra en sus propios grupos de recursos.
En capítulos posteriores se analizan algunas de las funciones de seguridad y directiva en Azure que le permiten definir quién puede acceder y editar ciertos recursos. La idea es que si no sabe, o no quiere saber mucho sobre los recursos de la red, puede conectarse a lo que se le asignó y listo. Lo mismo se aplica a otros ingenieros o desarrolladores: es posible que puedan visualizar los recursos de su aplicación, pero no editarlos ni eliminarlos.
Este tipo de modelo de gobernanza en Azure es cómodo, pero tenga cuidado de evitar caer en la trampa de trabajar en silos. En las grandes empresas, puede ser inevitable que esté limitado por las líneas de departamentos. Sin embargo, una de las grandes ventajas de los proveedores de informática en la nube como Azure es acelerar el tiempo de implementación de las aplicaciones, ya que no hay que esperar el cableado y la configuración de los recursos de una red física. Planifique la creación y configuración de los recursos de red de Azure, y luego debería ser capaz de crear y administrar sus recursos de aplicación sin problemas.
Dirección IP pública y resolución DNS
Nadie puede acceder a sus recursos todavía, porque no hay direcciones IP públicas o nombres DNS asociados a ellos. Insisto, siga el principio de los recursos de larga duración para crear una dirección IP pública y un nombre DNS público y, a continuación, asignémoslos a su interfaz de red.
Pruébelo ahora
Complete los siguientes pasos para crear una dirección IP pública y una entrada DNS para su interfaz de red:
1 En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda del panel.
2 Busque y seleccione Dirección IP pública y, a continuación, seleccione Crear.
3 Cree una SKU básica y una dirección IPv4. Las SKU estándar y las direcciones IPv6 se utilizan con los equilibradores de carga (capítulo 8). No se preocupe demasiado por la diferencia en este momento.
4 Escriba un nombre, como web publica, que use una asignación dinámica.
Tipos de asignación de direcciones IP
Una asignación dinámica asigna una dirección IP pública cuando se inicia la VM. Cuando se detiene la VM, se desasigna la dirección IP pública. Hay un par de puntos importantes aquí:
– No tendrá una dirección IP pública hasta que la asigne a una VM y la inicie.
– La dirección IP pública puede cambiar si detiene, desasigna e inicia la VM.
Una asignación estática significa que tiene una dirección IP pública asignada sin una VM asociada, y esa dirección no cambiará. Esta asignación es útil cuando utiliza un certificado SSL asignado a una dirección IP, o un nombre DNS personalizado y un registro que dirige a la dirección IP.
Ahora mismo, está usando una sola VM. Para usos de producción, idealmente ejecutará su aplicación en varias VM con un equilibrador de carga delante de ellos. En esa situación, la dirección IP pública se asigna al equilibrador de carga y normalmente crea una asignación estática en ese punto.
5 Escriba un nombre DNS único. Este nombre forma el nombre de dominio completo (FQDN) para su recurso, que se basa en la región de Azure en la que se crea. Si, por ejemplo, crea un nombre de DNS llamado azuremol en la región Este de EE. UU., el FQDN pasa a ser azuremol.eastus.cloudapp.azure.com.
Entradas DNS
¿Qué pasa con un nombre DNS personalizado? El FQDN predeterminado no es exactamente fácil de usar. Utilice una dirección IP pública estática y, a continuación, cree un registro CNAME en su zona DNS registrada. Usted mantiene el control del registro DNS y puede crear tantas entradas como desee para sus aplicaciones.
Como ejemplo, en la zona DNS manning.com, puede crear un CNAME para azuremol que dirija a una dirección IP pública estática en Azure. Un usuario tendría que acceder a azuremol.manning.com para llegar a su aplicación. Esta dirección es mucho más fácil de usar que webmol.eastus.cloudapp.azure.com.
6 Seleccione el grupo de recursos existente del ejercicio anterior y, a continuación, elija crear la dirección IP pública en la misma región que la red virtual.
7 Cuando esté listo, cree la dirección IP pública.
8 Asocie la dirección IP pública y la etiqueta de nombre DNS con la interfaz de red que creó en la sección 5.1.2. Busque y seleccione Grupos de recursos en la barra de navegación del lado izquierdo de Azure Portal. Luego, elija el grupo de recursos en el que creó los recursos de red, como azuremolchapter5.
9 Seleccione la dirección IP pública de la lista de recursos y, a continuación, elija Asociar.
10 Elija asociar con una interfaz de red (pero fíjese con qué otra cosa puedes asociar la dirección IP pública); luego elija la interfaz de red que creó, como webvnic.
Después de unos segundos, la dirección IP pública se actualiza para mostrar que la dirección IP ya está asociada a su interfaz de red. Si seleccionó Dinámico como tipo de asignación, la dirección IP seguirá estando en blanco, como se muestra en la figura. Recuerde que una dirección IP pública se asigna cuando se enciende una VM asociada.
Creación de un grupo de seguridad de red
En Azure, un NSG aplica de manera lógica un conjunto de reglas a los recursos de red. Estas reglas definen qué tráfico puede ingresar y salir de su VM. Usted define los puertos, los protocolos y las direcciones IP que se permiten, y en qué dirección. Estos grupos de reglas se pueden aplicar a una sola interfaz de red o a toda una subred de red. Esta flexibilidad le permite controlar finamente cómo y cuándo se aplican las reglas para satisfacer las necesidades de seguridad de su aplicación.
La figura muestra el flujo lógico de un paquete de red entrante cuando pasa a través de un NSG. El mismo proceso se aplicaría a los paquetes salientes. El host Azure no distingue entre el tráfico de Internet y el tráfico de otros lugares dentro de su entorno Azure, como otra subred o red virtual. Las reglas de NSG entrantes se aplican cualquier paquete de red entrante y las reglas de NSG salientes se aplican a cualquier paquete de red saliente.
Esto es lo que pasa con cada paquete de red:
1 Se aplica la primera regla de NSG.
2 Si la regla no coincide con el paquete, se carga la siguiente regla hasta que no haya más reglas. A continuación, se aplica la regla predeterminada para eliminar el paquete.
3 Si una regla coincide, compruebe si la acción es denegar el paquete. Si es así, el paquete se elimina.
4 De lo contrario, si la regla es permitir el paquete, el paquete se pasa a la VM.
A continuación, creará una NGS para que estos conceptos empiecen a tener sentido.
Pruébelo ahora
Complete los siguientes pasos para crear un grupo de seguridad de red:
1 En Azure Portal, seleccione Crear un recurso en la esquina superior izquierda del panel.
2 Busque y seleccione el Grupo de seguridad de red y, a continuación, seleccione Crear.
3 Escriba un nombre, como webnsg, y elija usar el grupo de recursos existente.
¡Listo! La mayor parte de la configuración de un NSG viene cuando se crean las reglas de filtrado.
Asociación de un grupo de seguridad de red con una subred
El NSG no hace mucho para proteger sus VM si no tiene ninguna regla. También es necesario asociarlo con una subred, de la misma manera que anteriormente asoció la dirección IP pública con una interfaz de red. Primero asociará su NSG con una subred.
Pruébelo ahora
Complete los siguientes pasos para asociar su subred de red virtual al grupo de seguridad de red:
1 Busque y seleccione Grupos de recursos en la barra de navegación del lado izquierdo de Azure Portal. Luego, elija el grupo de recursos en el que creó los recursos de red, como azuremolchapter5.
2 Seleccione su NSG, como webnsg.
3 A la izquierda, en las opciones de Configuración, se encuentran las Interfaces de red y Subredes. Seleccione Subredes.
4 Seleccione el botón Asociar; seleccione la red virtual y la subred de red que creó con anterioridad y, a continuación, seleccione Aceptar para asociar su NSG con la subred.
La flexibilidad de los NSG significa que puede asociar varias subredes, a través de varias redes virtuales, con un solo NSG. La asignación es de uno a muchos, que permite definir reglas básicas de seguridad de red que se aplican a una amplia gama de recursos y aplicaciones.
Ahora puede ver su NSG y qué reglas predeterminadas se aplican.
5 En el lado izquierdo de su NSG, seleccione Reglas de seguridad entrantes.
No se enumeran reglas de seguridad, al menos ninguna que haya creado.
6 Seleccione Reglas predeterminadas para ver lo que la plataforma Azure crea automáticamente.
Se han creado automáticamente tres reglas predeterminadas, las cuales son importantes de entender:
– AllowVnetInBound: permite cualquier tráfico que sea interno a la red virtual. Si tiene varias subredes en su red virtual, el tráfico no se filtra de forma predeterminada y se permite.
– AllowAzureLoadBalancerInBound: permite que cualquier tráfico de un equilibrador de carga Azure llegue a su VM. Si coloca un equilibrador de carga entre las VM e Internet, esta regla asegura que el tráfico del equilibrador de carga pueda llegar a sus VM, así como para supervisar el latido.
– DenyAllInBound: la regla final que se aplica. Elimina cualquier paquete entrante que llegue hasta este punto. Si antes no hay ninguna regla Permitir previa, esta regla elimina todo el tráfico de forma predeterminada, lo que significa que simplemente debe permitir cualquier tráfico específico que desee; el resto se elimina.
La prioridad de una regla de NSG es importante. Si se aplica una regla Permitir o Denegar, no se aplicarán reglas adicionales. Las reglas se aplican en orden de prioridad numérica ascendente; una regla con una prioridad de 100 se aplica antes de una regla de prioridad 200, por ejemplo.
Al igual que lo conversado anteriormente sobre la gobernanza de los recursos de Azure, puede que ya se hayan creado estas reglas de NSG y se hayan aplicado a una subred determinada. Usted crea sus VM y ejecuta sus aplicaciones, mientras que otra persona administra los NSG.
Es importante entender cómo fluye el tráfico en caso de que algo salga mal. Hay un par de herramientas en Azure que pueden ayudarlo a determinar por qué el tráfico no puede llegar a su aplicación cuando cree que sí debería.
Creación de reglas de filtrado de grupo de seguridad de red
Ahora que tiene su NSG asociado a la subred de la red y hemos revisado las reglas predeterminadas, cree una regla de NSG básica que permita el tráfico HTTP.
Pruébelo ahora
Complete los siguientes pasos para crear sus propias reglas con el grupo de seguridad de red:
1 Para crear una regla de NSG desde la ventana anterior de Azure Portal, seleccione Agregar en la sección Reglas de seguridad entrantes.
2 Tiene dos opciones para crear reglas: Básica y Avanzada. Para crear rápidamente reglas precompiladas, seleccione Básico en la parte superior de la ventana.
3 Elija HTTP en el menú desplegable Servicio. Se proporcionan muchos servicios predeterminados, como SSH, RDP y MySQL. Cuando se selecciona un servicio, se aplica el rango de puertos apropiado, en este caso, el puerto 80. La acción por defecto en las reglas básicas permite el tráfico.
4 Se asigna un valor de prioridad a cada regla. Cuanto menor sea el número, mayor será la prioridad. Acepte la prioridad baja predeterminada, como por ejemplo 100.
5 Acepte el nombre predeterminado o escriba el que desee; luego, seleccione Aceptar.
Compilación de una aplicación web de ejemplo con tráfico seguro
Hasta ahora ha creado una red y una subred virtuales. Luego, creó una interfaz de red y asoció una dirección IP pública y una etiqueta de nombre DNS. Creó un NSG y lo aplicó a toda la subred, y creó una regla de NSG para permitir el tráfico HTTP. Le falta una cosa: la VM.
Creaciones de conexiones de red de acceso remoto
En producción, no debe abrir el acceso remoto, como SSH o RDP, a las VM que ejecutan sus aplicaciones. Normalmente, tiene una VM de servidor de salto independiente a la que se conecta desde Internet y luego accede a VM adicionales a través de la conexión interna. Hasta ahora, ha creado todos los recursos de red virtual en Azure Portal. Pasemos a la CLI de Azure para ver lo rápido que se pueden crear estos recursos desde la línea de comandos.
Pruébelo ahora
Creó el primer NSG se creó en Azure Portal. Complete los siguientes pasos para crear otro NSG con la CLI de Azure:
1 Seleccione el icono de Cloud Shell en la parte superior del panel de Azure Portal. Asegúrese de que se abra el Bash Shell, y no PowerShell.
2 Cree un NSG adicional en el grupo de recursos existente. Como en los capítulos anteriores, las barras inversas () en los ejemplos de comandos siguientes son para ayudar con los saltos de línea: no tiene que escribirlos si no lo desea. Escriba un nombre, como remotensg:
az network nsg create \
–resource-group azuremolchapter5 \
–name remotensg
3 Cree una regla NSG en el nuevo NSG que permite el puerto 22. Escriba el grupo de recursos y NSG que creó en el paso anterior, junto con un nombre, como allowssh:
az network nsg rule create \
–resource-group azuremolchapter5 \
–nsg-name remotensg \
–name allowssh \
–protocol tcp \
–priority 100 \
–destination-port-range 22 \
–access allow
4 Cree una subred de red para su máquina virtual remota. Proporcione un nombre de subred, como remotesubnet, junto con un prefijo de dirección dentro del intervalo de la red virtual, como 10.0.2.0/24. También se conectan a la subred los NSG que se crearon en el paso 3, como remotensg:
az network vnet subnet create \
–resource-group azuremolchapter5 \
–vnet-name vnetmol \
–name remotesubnet \
–address-prefix 10.0.2.0/24 \
–network-security-group remotensg
Apenas se necesitan tres comandos para crear una subred, una NSG y una regla. ¿Empieza a ver el poder de la CLI de Azure? Azure PowerShell es igual de poderoso, así que no sienta que debe crear todos los recursos en Azure Portal. A medida que avanza en el libro, utilizará la CLI de Azure en lugar del portal en la mayoría de los casos.
Creación de VM
Ahora que tenemos todos los componentes de red, está listo para crear dos VM. Una VM se crea en la subred que permite el tráfico HTTP para poder instalar un servidor web. La otra VM se crea en la subred que permite SSH para que tenga un servidor de salto y así asegurar aún más su entorno de aplicación y comenzar a replicar una implementación de producción. La siguiente figura le recuerda lo que está compilando.
Al crear una VM, puede proporcionar la interfaz de red virtual que creó antes. Si no especificó este recurso de red, la CLI de Azure crea una red, subred y NIC virtuales automáticamente usando los valores predeterminados integrados. Esa opción es genial para crear rápidamente una VM; pero le recomendamos seguir el principio de utilizar recursos de red de larga duración que otro equipo pueda administrar y en el que creará sus VM.
Pruébelo ahora
Complete los siguientes pasos para usar la CLI de Azure para crear su VM de servidor web y de servidor de salto:
1 Cree la primera VM para su servidor web y escriba un nombre, como webvm. Conecte la interfaz de red, como webvnic, e ingrese una imagen, como UbuntuLTS. Escriba un nombre de usuario, como azuremol. El paso final, –generate-ssh-keys, agrega a la VM las claves SSH que creó en la entrada anterior:
az vm create \
–resource-group azuremolchapter5 \
–name webvm \
–nics webvnic \
–image UbuntuLTS \
–size Standard_B1ms \
–admin-username azuremol \
–generate-ssh-keys
2 Cree la segunda VM para el servidor de salto. En este ejemplo se muestra cómo se puede utilizar una subred y NSG existentes, y permitir que la CLI de Azure cree la interfaz de red y realice las conexiones apropiadas. Usted crea una dirección IP pública, como «remotepublicip», como parte de este comando:
az vm create \
–resource-group azuremolchapter5 \
–name remotevm \
–vnet-name vnetmol \
–subnet remotesubnet \
–nsg remotensg \
–public-ip-address remotepublicip \
–image UbuntuLTS \
–size Standard_B1ms \
–admin-username azuremol \
–generate-ssh-keys
El resultado de ambos comandos muestra la dirección IP pública. Anote estas direcciones IP. En el siguiente ejercicio, si trata de SSH a su primera VM para el servidor web, falla. ¿Por qué? Usted puede SSH a la VM remota porque creó una regla de NSG para permitir solo el tráfico HTTP a la VM web.
Uso del agente SSH para conectarse a las VM
Permítame presentarle un acto de magia con SSH que le permite usar el servidor de salto correctamente y conectarse a la VM web sobre la red virtual Azure: se llama agente SSH. Este agente solo se aplica a las VM Linux, así que si trabaja de manera principal con las VM Windows y las conexiones de escritorio remoto, no se preocupe si SSH es totalmente nuevo. Si configura el servidor adecuadamente, puede crear conexiones RDP a las VM de Windows desde el servidor de salto con las credenciales remotas locales o con credenciales de dominio.
Un agente SSH puede almacenar sus claves SSH y reenviarlas cuando sea necesario. En el capítulo 2, cuando creó un par de claves públicas SSH, hablamos sobre las claves pública y privada. La clave privada es algo que se queda en su equipo. Solo la clave pública se copia en las VM remotas. Aunque la clave pública se agregó a ambas VM que creó, no puede simplemente SSH a su servidor de salto y, a continuación, SSH a la VM web. ¿Por qué? Porque ese servidor de salto no tiene una copia de su clave privada. Cuando intenta hacer la conexión SSH desde el servidor de salto, no tiene ninguna clave privada para emparejar con la clave pública de la VM web para autenticarse.
La clave privada es algo que se debe proteger, así que no debe tomar el camino fácil y copiar la clave privada del servidor de salto. Cualquier otro usuario que acceda al servidor de salto podría potencialmente obtener una copia de su clave privada y luego hacerse pasar por usted en cualquier lugar donde se utilice la clave. Aquí es donde el agente SSH entra en juego.
Si ejecuta el agente SSH en la sesión de Cloud Shell, puede agregar sus claves SSH a la sesión. Para establecer la conexión SSH al servidor de salto, especifique el uso de este agente para abrir su sesión. Esta técnica le permite transferir eficazmente su clave privada para usarla desde el servidor de salto, sin nunca tener que copiar la clave privada. Cuando aplica SSH desde el servidor de salto a la VM web, el agente SSH pasa su clave privada a través del servidor de salto y le permite autenticarlo.
Pruébelo ahora
Complete los siguientes pasos para utilizar SSH con la VM del servidor de salto:
1 En Cloud Shell, inicie el agente SSH de la siguiente manera:
eval $(ssh-agent)
2 Agregue la clave SSH que creó en el capítulo 2 al agente de la siguiente manera:
ssh-add
3 Aplique SSH a su VM de servidor de salto. Especifique el uso del agente SSH con el parámetro -A. Ingrese su propia dirección IP pública que obtuvo como resultado cuando creó la VM de servidor de salto:
ssh -A azuremol@
4 Esta es la primera vez que ha creado una conexión SSH a la VM de servidor de salto, así que acepte la notificación para conectarse con las claves SSH.
5 ¿Recuerda que creó una asignación de dirección IP privada estática para la VM web en la sección 5.1.2? Esta dirección estática hace que sea mucho más fácil aplicar SSH a ella. Aplique SSH a la VM web de la siguiente manera:
ssh 10.0.1.4
6 Acepte la notificación para continuar la conexión SSH. El agente SSH ha tunelizado su clave SSH privada a través del servidor de salto y le permite conectarse correctamente a la VM web. ¿Y ahora qué? Bueno, tiene un laboratorio para ver este trabajo.
Y bien amigos, por ahora dejamos este tema de las redes hasta aqui, ya que es un tema un poco mas extenso y algo complejo, para mañana mas…