En este post vamos a ver como configurar una VPN IPSEC de acceso remoto en un firewall Fortigate, con este tipo de VPN usando el protocolo IPSec nos podemos conectar desde cualquier equipo con conexión a Internet hacia nuestra red interna, dónde todo el tráfico irá encriptado.

• Lo primero que vamos a realizar será, crear los usuarios locales que accederán a través de la VPN:

• Para una correcta administración, los usuarios que nos hemos creado anteriormente los vamos a anidar en un grupo:

• Una vez creados los usuarios y grupos, vamos a crearnos el túnel IPSec, para ello, accedemos a VPN > Túneles Ipsec > Crear nuevo > IPsec Tunnel:

• Sobre Configuración de VPN, le indicamos un nombre y seleccionamos Acceso remoto, Siguiente:

• Sobre Autenticación, le indicamos la interface de entrada, el método de autenticación por llave compartida y el grupo de usuario, este grupo lo eliminaremos de la configuración de las fases más tarde, ya que las políticas de acceso irán configuradas con grupos y no sería necesario, Siguiente:

• Sobre Política y Enrutamiento, vamos a configurar esta política, que más tarde vamos a eliminar, ya que iremos aplicando políticas más granulares y restrictivas, habilitamos el Split Tunnel, esto hará que los usuarios que se conecten a la VPN, tengan la salida a Internet por su propia conexión y no por la nuestra, Siguiente:

• Sobre Opciones de cliente, le indicamos que guarde la contraseña, y habilitamos el Keep Alive, Crear:

• Aquí nos indica todo lo que hemos configurado, damos a Mostrar la lista de túnel:

• Vemos el túnel IPsec que nos ha creado, damos a Editar:

• Convertimos a túnel personalizado:

• Para la parte de Red, configuramos estos parámetros:

• Para la parte de Autenticación, configuramos lo siguiente:

• Para la propuesta de la fase 1, configuramos estos parámetros:

• Para XAUTH, aquí es donde quitamos el grupo que configuramos al crear el túnel, y para el Grupo de Usuarios, le indicamos que los herede de las políticas:

• Para los Selectores de fase 2, configuramos estos parámetros, damos a OK:

• Aquí tenemos ya el túnel IPsec configurado de modo personalizado:

• Antes de seguir, vamos a explicar, estos dos objetos que se han creado al crear la VPN IPsec.
• Uno de ellos es, ipsecra_range, este objeto es para asignar las direcciones IPs de los equipos que se conecten a nuestra VPN PIsec de acceso remoto:

• El otro es, ipsecra_split, este objeto es un grupo de direcciones que actúa como una «lista blanca» de destinos, su función principal es decirle al cliente VPN (FortiClient) qué tráfico debe enviar obligatoriamente a través del túnel y cuál debe ignorar para que salga por su conexión local a Internet.
• Cuando habilitamos el Split Tunneling (Túnel Dividido), el comportamiento es el siguiente:
• Si el destino está en el objeto ipsecra_split, el FortiClient enruta ese tráfico por la VPN.
• Si el destino NO está ahí, el FortiClient lo envía por la puerta de enlace predeterminada del usuario (su internet doméstico).

• También podemos ver, que en la interface de red que le indicamos al túnel VPN IPsec, nos ha creado esta interface virtual:

• Para terminar de configurar la VPN IPsec de acceso remoto, debemos de crear las reglas o políticas para que los equipos que se conecten a través de la VPN, tengan acceso a las redes internas configuradas en nuestro firewall, voy a mostrar sólo una de ellas ya que para las demás sería exactamente igual, editamos la regla que se nos creó al crear el túnel IPsec:

• Con esto ya tendríamos configurada y operativa nuestra VPN IPsec de acceso remoto, ahora desde cualquier equipo con conexión a internet, le instalaremos el Forticlient y configuraremos los parámetros de la VPN IPsec para conectarnos desde cualquier lugar del mundo a las redes internas de nuestra infraestructura, dónde todo el tráfico irá encriptado mediante IPsec:

• Como podemos ver ya estamos conectados y nos está sirviendo una dirección IP del rango que habíamos configurado:

• Aquí vemos el túnel levantado:

• Desde el Monitor IPsec de nuestro Fortigate podemos ver los usuarios conectados a través de la VPN:

• Desde la opción VPN > VPN Location Map podemos ver desde que parte del mundo se están conectando los usuarios que hemos creado y configurado para nuestra VPN IPsec de acceso remoto:

Saludos y espero que os resulte de ayuda

En este post veremos cómo configurar VLANs en las redes de Proxmox VE 9.0

• Para empezar y ponernos en contexto, vamos a configurar las VLANs del mismo modo que lo hacemos en una infraestructura con VMware vSphere, es decir, en un virtual switch, configuramos un port group del tipo VMkernel para la interface de management asignándole una dirección IP y una etiqueta o ID de VLAN, y en ese mismo virtual switch vamos configurando nuevos port group del tipo máquina virtual para cada VLAN asignándole su etiqueta o ID de VLAN que corresponda, lo mismo haremos en Proxmox, eso sí, con sus particularidades, pero la idea sería la misma:

• Estas serían las VLANs que tenemos configuradas en nuestra infraestructura, concretamente en un router Mikrotik, VLAN_GESTION ID 99, VLAN_INGENIERIA ID 10, VLAN_CONTABILIDAD ID 20, VLAN_VENTAS ID 30:

• En nuestro servidor proxmox, tenemos configurado un bond o NIC Teaming con dos interfaces de red con la siguiente configuración:

auto bond0

iface bond0 inet manual

bond-slaves ens192 ens224

bond-miimon 100

bond-mode balance-rr

auto vmbr0

iface vmbr0 inet static

address 192.168.99.100/24

gateway 192.168.99.1

bridge-ports bond0

bridge-stp off

bridge-fd 0

• Ahora para configurar las VLANs, este sería el plateamiento:
• El nodo de Proxmox (management) con su IP en la VLAN 99.
• Las VMs/Contenedores LXCs que salgan por el mismo puerto trunk, cada uno en su propia VLAN (10, 20, 30).
• Esta sería la configuración:

auto bond0

iface bond0 inet manual

bond-slaves ens192 ens224

bond-miimon 100

bond-mode balance-rr

auto vmbr0

iface vmbr0 inet manual

bridge-ports bond0

bridge-stp off

bridge-fd 0

auto vmbr0.99

iface vmbr0.99 inet static

address 192.168.99.100/24

gateway 192.168.99.1

• Si accedemos a la interface gráfica, así nos quedaría:

• Con esto, ya tendríamos configurado el acceso a nuestro Proxmox desde la VLAN de GESTION, para la configuración de las VMs/Contenedores LXCs elegiremos el bridge vmbr0, en el campo VLAN Tag, colocaremos el número de VLAN (10, 20, 30), así Proxmox insertará el tag VLAN cuando el tráfico salga por vmbr0 → bond0 hacia el switch trunk:

• Este sería el resumen de todo lo que hemos configurado:
• El nodo Proxmox usa la VLAN 99 → vmbr0.99
• Una VM1 con IP en VLAN 10 → asignamos vmbr0 como interfaz y VLAN Tag = 10
• Una VM2 con IP en VLAN 20 → asignamos vmbr0 como interfaz y VLAN Tag = 20
• Una VM3 con IP en VLAN 30 → asignamos vmbr0 como interfaz y VLAN Tag = 30
• El switch físico, debe tener el puerto donde está Proxmox en modo trunk/tagged con VLANs 10, 20, 30 y 99 permitidas.
• La VLAN 99 es la que usará el propio Proxmox para management
• Proxmox se gestiona en la VLAN 99
• Las VMs/Contenedores LXCs pueden usar cualquier VLAN disponible en el trunk, solo con asignar el tag correspondiente en la GUI

Saludos y espero que os resulte de ayuda

En este post veremos cómo configurar un bond o NIC Teaming en Proxmox VE 9.0, un bond o NIC Teaming es agrupar las interfaces de red de nuestro servidor para crear alta disponibilidad y balanceo de carga a nivel de red en nuestro sistema operativo.

• Si accedemos a proxmoxlab11 > Sistema > Red, vemos que nuestro hypervisor tiene dos interfaces de red, llamadas ens192 y ens224, en la instalación de proxmox, cuando configuramos la interface de management, utilizamos la interface de red ens192 y nos creo la interface virtual vmbr0 del tipo Linux Bridge, esta interface virtual vmbr0 es la que tiene asignados los parámetros de TCP/IP:

• Ahora nos abrimos una Consola en nuestro Proxmox, realizamos un backup del fichero de configuración de red, ejecutando cp /etc/network/interfaces /etc/network/interfaces00.bck  y editamos el fichero original con nano /etc/network/interfaces para configurar nuestra red:

• Esta es la configuración que tenemos tras la instalación de proxmox:

• Para configurar el bond o NIC Teaming, vamos a añadir al fichero esta configuración, incluimos las dos interfaces de red y el tipo de balanceo de carga round robin (consiste en distribuir paquetes de datos de forma secuencial entre las interfaces de red de un grupo «bond», de manera que se aprovecha todo el ancho de banda y se proporciona tolerancia a fallos), si aplicamos esta configuración, en el switch físico dónde conectemos las interfaces de red deben de tener un trunk sin LACP:

auto bond0

iface bond0 inet manual

bond-slaves ens192 ens224

bond-miimon 100

bond-mode balance-rr

auto vmbr0

iface vmbr0 inet static

address 192.168.7.11/24

gateway 192.168.7.210

bridge-ports bond0

bridge-stp off

bridge-fd 0

• Con systemctl restart networking reiniciamos el servicio de red y con systemctl status networking vemos que el servicio está cargado y activado:

• Si accedemos a proxmoxlab11 > Sistema > Red, vemos que ya nos muestra el bond o NIC Teaming que hemos creado, y que la configuración de la interface virtual vmbr0 Linux Bridge ahora apunta al puerto bond0:

• Para laboratorios en modo nested y en configuraciones de dos switches redundantes, la configuración adecuada sería el bond, en modo active-backup:

auto bond0

iface bond0 inet manual

bond-slaves ens192 ens224

bond-miimon 100

bond-mode active-backup

bond-primary ens192

auto vmbr0

iface vmbr0 inet static

address 192.168.7.11/24

gateway 192.168.7.210

bridge-ports bond0

bridge-stp off

bridge-fd 0

• Si accedemos a proxmoxlab11 > Sistema > Red, vemos que ya nos muestra el bond o NIC Teaming que hemos creado en modo active-backup, y que la configuración de la interface virtual vmbr0 Linux Bridge ahora apunta al puerto bond0:

• Para laboratorios en modo nested, en configuraciones de switches físicos redundantes o en configuraciones de un solo switch físico, otra configuración adecuada sería el bond, en modo balance-alb:

auto bond0

iface bond0 inet manual

bond-slaves ens192 ens224

bond-miimon 100

bond-mode balance-alb

auto vmbr0

iface vmbr0 inet static

address 192.168.7.11/24

gateway 192.168.7.210

bridge-ports bond0

bridge-stp off

bridge-fd 0

• Si accedemos a proxmoxlab11 > Sistema > Red, vemos que ya nos muestra el bond o NIC Teaming que hemos creado en modo balance-alb, y que la configuración de la interface virtual vmbr0 Linux Bridge ahora apunta al puerto bond0:

• Para resumir, como podemos configurar un bond, vamos a poner de ejemplos distintos escenarios.
• Servidor Proxmox con dos interfaces de red y dos switches físicos distintos:
• Si los switches no están apilados (stack) o no soportan MLAG/VLT/VSF:
• No podemos usar 802.3ad (LACP) porque este requiere que ambos puertos estén en el mismo dominio lógico de switch, en este caso, lo correcto es usar un modo de balanceo que funcione sin coordinación entre switches, como balance-alb (Adaptive Load Balancing) que no requiere configuración en los switches y proporciona balanceo de carga en salida y también en entrada (mediante ARP negotiation), o balance-tlb (Transmit Load Balancing) que balancea solo la salida, pero es más sencillo.
• Si los switches están en stack/VSF/IRF (actúan como un único switch lógico), en este caso, sí podemos usar bond mode 802.3ad (LACP) y configurar un LAG estático o dinámico en los switches físicos, esto nos dará redundancia y balanceo real a nivel de capa 2.
• Servidor Proxmox con dos interfaces de red conectadas al mismo switch físico:
• Bond en modo 802.3ad (LACP), es la opción más correcta y recomendada cuando ambas interfaces van al mismo switch físico, el switch debe tener configurado un LAG (Link Aggregation Group) con LACP para esos dos puertos, nos aporta redundancia (si un enlace cae, sigue funcionando el otro) y balanceo real de carga a nivel de capa 2/3.
• Bond en modo balance-alb, funciona y no hay que configurar nada en el switch, es transparente, proporciona balanceo de carga y tolerancia a fallos, nos aporta simplicidad ya que no dependemos de configurar el switch, pero el balanceo es menos predecible y puede dar problemas en ciertos entornos (aunque normalmente funciona bien).

Saludos y espero que os sea de ayuda

En este post vamos a ver como configurar un servidor DHCP en Linux Ubuntu 24.04 LTS con Webmin.

• Con la herramienta gráfica webmin vamos a configurar el servicio DHCP para que haga lo siguiente:
• Vamos  a crear una declaración de subred DHCP para la subred 192.168.5.0 máscara 255.255.255.0:

• Vamos a definir dos rangos de direcciones IP para asignar a los clientes dinámicamente: rango 1 desde 192.168.5.20 hasta 192.168.5.40 y rango 2 desde 192.168.5.60 hasta 192.168.6.80:

• El servidor debe ser autoritativo en toda la subred:

• El tiempo de concesión máximo para los clientes de la subred será de cinco horas; y el de concesión por defecto de dos horas y media:

• Se establecerá mitologianordica.local como nombre del servidor:

• A los clientes se les asignará la máscara 255.255.255.0, la IP de la puerta de enlace 192.168.5.210, la dirección de broadcast 192.168.5.255, el nombre de dominio mitologianordica.local y las direcciones IP de los servidores de dominio, 8.8.8.8 y 8.8.4.4:

• Dentro de la subred se declarará un grupo llamado «dioses» y dentro del grupo se asignarán dos reservas para las máquinas, estas máquinas siempre tendrán asignadas las mismas IP’s:

• Dirección MAC 00:08:01:12:23:34, IP asignada 192.168.5.8 y nombre asignado a la máquina «mitologianordica.local«:

• Dirección MAC 00:08:01:34:45:56, IP asignada 192.168.5.9 y nombre asignado a la máquina equipo «mitologianordica.local«:

• Las dos máquinas dispondrán de un tiempo de concesión por defecto de media hora y lo asígnamos al grupo, y a la máquina loki se le asignará como servidor de tiempo NTP el servidor de IP 130.206.3.166 (hora.rediris.es) y como servidor DNS 8.8.8.8:

Saludos y espero que os resulte de ayuda

En este post vamos a ver como configurar un servidor DHCP en Linux Ubuntu 24.04 LTS.

• Tenemos dos máquinas virtuales, que llamaremos odin y frigg, deben tener instalado el sistema operativo Ubuntu 24.04 LTS, odin debe actuar como servidor DHCP por lo que debemos tener instalado el paquete isc-dhcp-server, y también vamos a instalar la herramienta webmin para realizar la configuración del servicio con esta herramienta, pero esto será en un próximo post, la máquina frigg será el cliente DHCP:

• Establecemos en odin, que será el servidor DHCP, una configuración manual o fija de los parámetros de red del adaptador de red mediante la herramienta gráfica Network Manager. Los valores que se van asignar son:
• IPv4: 192.168.5.1
• Máscara de subred: 255.255.255.0
• IP de la puerta de enlace: 192.168.5.210.
• Servidores DNS: 8.8.8.8 y 8.8.4.4

• Establecemos en frigg, que será el cliente DHCP, que tenga configuración automática de los parámetros de red:

• Vamos a establecer que el servidor DHCP es autoritativo:

• El tiempo de concesión por defecto es de cuatro horas y media:

• El tiempo de concesión máximo es de nueve horas:

• El nombre del dominio que se entregará a los clientes es mitologianordica.local:

• Las IPs de los servidores de dominio entregadas a los clientes serán los de Google: 8.8.8.8 y 8.8.4.4:

• La IP de la puerta de enlace entregada a los clientes será 192.168.5.210:

• Ahora vamos a editar el archivo de configuración dhcpd.conf, para que el servidor asigne dinámicamente direcciones IP en los rangos 192.168.5.20 – 192.168.5.40 y 192.168.5.60 – 192.168.5.80 en la subred a la que pertenece el servidor, para todos los clientes DHCP de esta subred establecemos que:
• El tiempo de concesión por defecto es de dos horas y media.
• El tiempo de concesión máximo es de cinco horas.
• La máscara para los clientes es 255.255.255.0.
• La dirección de broadcast entregada a los clientes es 192.168.5.255.

• Editamos el archivo de configuración dhcpd.conf, necesarias para que se realice la declaración de un grupo en el que todos los clientes del grupo tendrán un tiempo de concesión por defecto de una hora, en el grupo se harán dos reservas para:
• Dirección MAC 00:08:01:12:23:34, IP asignada 192.168.5.3 y nombre asignado al equipo «mitologianordica.local«.
• Dirección MAC 00:08:01:34:45:56, IP asignada 192.168.5.4 y nombre asignado al equipo «mitologianordica.local«.

• Una vez que hemos guardado todos los cambios realizados en el fichero /etc/dhcp/dhcpd.conf, hemos reiniciado el servicio con systemctl restart isc-dhcp-server y verificamos el estado con systemctl status isc-dhcp-server:

• Ahora, si accedemos a la máquina frigg, podemos ver, que el servidor odin, le está sirviendo los parámetros de red configurados, de manera automática:

Saludos y espero que os resulte de ayuda

En este post vamos a ver cómo desplegar y configurar dos firewalls OPNSense en modo clúster HA en Azure.

La topología que vamos a utilizar será esta:

• Lo primero que vamos a realizar es acceder a este link de dmauser, aquí vamos a encontrar un desarrollo para desplegar dos firewalls OPNSense sobre FreeBSD en modo cluster HA Activo-Activo:

• Se nos abrirá esta plantilla para el despliegue de OPNSense, sobre Deployment Scenarios le indicamos la suscripción, el grupo de recursos, la región y muy importante OPNSense Scenario que le indicamos Active-Active:

• Sobre Virtual Machine Settings le indicamos el nombre y tamaño de máquina, la URL para la descarga del script, la versión de OPNSense y la versión del agente de Azure:

• Para el despliegue y la configuración de la red virtual en Azure, vamos a seleccionar un espacio de direcciones en la red virtual, y le configuraremos las distintas subredes que va a utilizar el firewall y la que utilizaremos como la red local de Azure dónde se conectarán nuestras máquinas virtuales (ésta última la configuraremos a posteriori de la plantilla de despliegue):
• Red virtual: opnsenseha-vnet168.128.0/18
• Subred Externa: Untrusted-Subnet168.191.0/27
• Subred Interna: Trusted-Subnet168.191.32/27
• LAN Azure: SubnetLAN-192_168_128_0-24
• DMZ Azure: SubnetLAN-192_168_129_0-24

• Sobre Virtual Network Settings estas serían las configuraciones para nuestra infraestructura:

• Sobre Revisar y crear, nos muestra un resumen de todas las configuraciones realizadas, comenzamos a Crear todos los recursos de la plantilla OPNSense deployment:

• Como podemos ver, comienza el despliegue:

• Aquí vemos que ya ha terminado y se ha implementado correctamente, podemos ver, los distintos recursos que ha creado el despliegue de esta plantilla:

• Accedemos al grupo de recursos y vemos todos los recursos que se nos han creado, entre ellos, dos firewalls opnsense (primario y secundario), dos Load Balancer (Externo e Interno) y una IP pública:

• Ahora vamos a clicar sobre la máquina virtual opnsense-Primary:

• En la máquina virtual accedemos a Configuración de red y cómo podemos ver tenemos dos interfaces de red, una es la interface WAN de OPNSense que tiene asignada una IP privada del rango de la subred Untrusted, y la otra es la interface LAN que tiene asignada una IP privada del rango de la subred Trusted:

• Debemos de configurar las IPs privadas como estáticas, tanto la WAN cono la LAN:

• Para la máquina opnsense-Secondary hacemos lo mismo:

• Otro de los recursos que se han creado es el Load Balancer Interno:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP del rango de la subred Trusted:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Trusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada para equilibrar la carga entre los dos firewalls:

• Otro de los recursos que se han creado es el Load Balancer Externo:

• Sobre Configuración de IP de front-end, vemos que la IP asignada es una IP pública, que será la que nos dará la entrada y salida desde y hacia la WAN:

• Sobre Grupos de back-end, vemos que tenemos asignados los dos firewall opnsense en su interface Untrusted:

• Sobre Sondeos de estado, vemos que tenemos uno agregado para el protocolo TCP puerto 443:

• Sobre Reglas de equilibrio de carga, vemos que tenemos una regla configurada a modo de ejemplo para definir cómo se distribuye el tráfico entrante a todas las instancias del grupo de back-end, en este ejemplo sería una regla creada en el puerto 3389 para equilibrar la carga del tráfico RDP:

• Sobre Regla NAT de entrada, tenemos dos reglas configuradas para el acceso a los firewalls opnsense a través de su IP pública, al firewall primario se accede por el puerto 50443 y al firewall secundario por el puerto 50444, que como vemos está mapeado al puerto 443 de cada firewall:

• Sobre Reglas de salida, tenemos configurada una regla para la salida a la WAN de nuestra infraestructura, con esta regla todas las máquinas ubicadas detrás de los firewalls van a salir a Internet con la IP pública de nuestro load balancer externo:

• Para acceder a los firewalls accedemos a través de su IP pública, https://PublicIP:50443 para el primario y https://publicip:50444 para el secundario, las credenciales por defecto son root/opnsense:

• Lo primero que vamos a configurar en los firewall opnsense, va a ser la configuración de HA.
• Nos vamos primero al firewall primario y sobre System > High Availability > Settings configuramos el peer del firewall secundario:

• Ahora accedemos al firewall secundario y sobre System > High Availability > Settings configuramos el peer del firewall primario:

• Accedemos de nuevo al firewall primario y sobre System > High Availability > Status sincronizamos y reconfiguramos todo, una vez configurado este cambio, todo lo que hagamos y configuremos en el firewall opnsense primario se va a replicar en el firewall opnsense secundario:

• Veamos un ejemplo, hemos configurado los servidores NTP en el firewall primario:

• Sincronizamos todos los servicios:

• Una vez que se ha sincronizado todo, si accedemos al firewall secundario, vemos que la configuración de los servidores NTP se ha replicado correctamente:

• Como comentamos anteriormente, vamos a configurar la red local de Azure dónde se conectarán nuestras máquinas virtuales, LAN Azure: SubnetLAN-192_168_128_0-24 y DMZ Azure: SubnetDMZ-192_168_129_0-24:

• Lo siguiente que vamos a desplegar y configurar es una tabla de rutas UDR (User Definition Routes) en Azure.
• Accedemos al Marketplace, buscamos Route table y damos a crear:

• Sobre Básico le indicamos el grupo de recursos, la región, le damos un nombre y le indicamos que propague las rutas de puerta de enlace:

• Sobre Etiquetas podemos configurar las que nos interesen:

• Sobre Revisar y crear nos muestra un resumen sobre todo lo que le hemos configurado a la tabla de rutas:

• Aquí vemos que se ha implementado correctamente:

• Accedemos al recurso y sobre subredes vamos a asociar las subredes LAN y DMZ que configuramos anteriormente, estas subredes son dónde vamos a ubicar las máquinas virtuales de nuestra infraestructura en Azure:

• Como podemos ver, ya las tenemos asociadas:

• Ahora vamos a configurar las rutas, para ello, accedemos a Rutas > Agregar:

• La primera ruta que vamos a agregar, será la ruta por defecto:

• La siguiente ruta será para el acceso a la subred LAN dónde vamos a ubicar nuestras máquinas virtuales:

• La siguiente ruta será para el acceso a la subred DMZ dónde vamos a ubicar nuestras máquinas virtuales:

• Aquí vemos las rutas agregadas:

• Sobre Información general en la tabla de rutas, podemos ver, todo lo que se ha configurado:

• Una vez configurada la tabla de rutas, accedemos a nuestro OPNSense HA en Azure, y nos vamos a crear estas dos rutas estáticas, la primera es la ruta por defecto, para que todo lo que no se encuentre en la tabla de enrutamiento del OPNSense lo envíe por la interface WAN al gateway de la subred Untrusted, y la segunda ruta son para servicios internos de Azure, para que lo envíe por la interface LAN al gateway de la subred Trusted:

• Para todas las demás configuraciones de opnsense, podemos seguir los enlaces a estos post creados hace algún tiempo en el blog.

Saludos y espero que os sea de ayuda

En este post vamos a ver como montar un FrontalWeb con Apache (Reverse Proxy) sobre una máquina Ubuntu Server 24.04 LTS utilizando certificados de Let´s Encrypt, con esta implementación le vamos a dar un punto más de seguridad a nuestra infraestructura perimetral, ya que sólo vamos a exponer directamente a Internet un único servidor, sólo va a ser necesario abrir un puerto en nuestro Firewall, ya que a través del Frontalweb vamos a poder alcanzar a los demás servidores, los certificados digitales los vamos a instalar y administrar en un solo servidor, a través del Frontalweb que se va a encargar de cifrar todos los contenidos.

• Lo primero que vamos a realizar será la instalación de Apache, para ello ejecutamos el comando apt-get install apache2:

• Una vez finalizada la instalación, con el comando apache2ctl -v podemos ver la versión de apache que hemos instalado:

• Con el comando ufw app list podemos ver los perfiles de aplicación que se pueden usar para habilitar o deshabilitar el acceso a Apache a través del firewall de Ubuntu:

Apache → Este perfil solo abre el puerto 80 (tráfico web normal sin cifrar)

Apache Full → Abre tanto el puerto 80 (tráfico web normal sin cifrar) como el puerto 443 (tráfico cifrado TLS / SSL)

Apache Secure → Este perfil solo abre el puerto 443 (tráfico cifrado TLS / SSL)

• En nuestro caso vamos a permitir el acceso a los dos puertos (80 y 443), ufw allow ‘Apache Full’:

• Para verificar que el servidor Apache está funcionando, accedemos a la URL de nuestro servidor, http://frontalweb.ragasys.net:

• Con el comando systemctl status apache2 podemos ver el estado del servicio del servidor Apache, que como podemos ver está activo y ejecutándose:

• Una vez que hemos instalado nuestro servidor de apache, vamos a habilitar los siguientes módulos:
• a2enmod ssl
• a2enmod proxy
• a2enmod proxy_http
• a2enmod proxy_balancer
• a2enmod lbmethod_byrequests
• a2enmod headers
• a2enmod rewrite

• Con el comando systemctl restart apache2 reiniciamos el servicio:

• Nos vamos a crear nuestro primer VirtualHost, en la ruta /etc/apache2/sites-available, y ejecutando nano nextcloud.ragasys.eu.conf, este primer VirtualHost será un servidor de Nextcloud que tenemos en nuestra infraestructura, con este fichero, todo el tráfico http y https que llegue a la URL de dominio púbico indicada, se va a redirigir al servidor interno de nextcloud, siempre a través de conexión cifrada https:

<VirtualHost *:80>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

#RewriteEngine On
#RewriteCond %{HTTPS} off
#RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

#SSLEngine on
#SSLCertificateFile /etc/letsencrypt/live/nextcloud.ragasys.eu/fullchain.pem
#SSLCertificateKeyFile /etc/letsencrypt/live/netxcloud.ragasys.eu/privkey.pem

ProxyPreserveHost On
ProxyPass / http://nextcloud.ragasys.net/
ProxyPassReverse / http://nextcloud.ragasys.net/

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Nos creamos nuestro segundo VirtualHost, en la ruta /etc/apache2/sites-available, y ejecutando nano guacamole.ragasys.eu.conf:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

#RewriteEngine On
#RewriteCond %{HTTPS} off
#RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

#SSLEngine on
#SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
#SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem

ProxyPreserveHost On
ProxyPass /guacamole http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse /guacamole http://guacamole.ragasys.net:8080/guacamole/

ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Nos creamos también el directorio para los logs de los sites virtuales:

• Habilitamos los VirtualHost con el comando a2ensite nextcloud.ragasys.eu.conf y a2ensite guacamole.ragasys.eu.conf y como podemos ver ya tenemos habilitados los sites:

• Deshabilitamos el site por defecto a2dissite 000-default.conf:

• Ejecutamos systemctl restart apache2 y systemctl status apache2 para reiniciar y ver el estado del servicio:

• Ahora en nuestro Firewall, que en mi caso es un Fortigate, nos debemos de crear las reglas necesarias para publicar el puerto 443 apuntando al servidor FrontalWeb que va a ser el único que vamos a exponer en el perímetro, en este post de este mismo blog podemos ver como hacerlo, primero realizamos un NAT estático y luego nos creamos la regla de acceso a los puertos HTTP y HTTPS para el NAT estático creado:

• En nuestro DNS interno debemos de crearnos una zona de búsqueda directa, en mi caso, ragasys.eu, que es el dominio externo que hemos comprado a nuestro proveedor de DNS y que utilizaremos para publicar nuestros servicios, esto lo hacemos en nuestra infraestructura interna, para que los usuarios que accedan desde la red interna no salgan al exterior, en esta zona de búsqueda directa nos creamos estos registros Tipo A y CNAME: 

• En nuestro DNS externo, el que tengamos contratado con nuestro proveedor de DNS, debemos de hacer algo parecido, es decir, debemos de crearnos un subdominio del tipo www.ragasys.eu con un registro tipo A apuntando a nuestra IP púbica, y nos crearemos subdominios por cada servicio que queramos publicar con un registro del tipo CNAME apuntando a www.ragasys.eu:

• Ahora vamos a instalar cerbot, para ello, ejecutamos apt install certbot python3-certbot-apache:

• Obtenemos el certificado SSL de Let’s Encrypt para el primer site, para ello, ejecutamos certbot –apache -d nextcloud.ragasys.eu:

• Obtenemos el certificado SSL de Let’s Encrypt para el segundo site, para ello, ejecutamos certbot –apache -d guacamole.ragasys.eu:

• Si accedemos a la configuración de los sites virtuales, nos ha quedado así tras el despliegue de los certificados SSL de Let’s Encrypt:

• El fichero bien estructurado del primer site debe quedar así:

<VirtualHost *:80>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

RewriteEngine on
RewriteCond %{SERVER_NAME} =nextcloud.ragasys.eu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName nextcloud.ragasys.eu
ServerAlias nextcloud.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/nextcloud.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
ProxyPass / http://nextcloud.ragasys.net/
ProxyPassReverse / http://nextcloud.ragasys.net/

ErrorLog /var/log/apache2/nextcloud.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/nextcloud.ragasys.eu/ssl-access.log combined
</VirtualHost>

• El fichero bien estructurado del segundo site debe quedar así:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

RewriteEngine on
RewriteCond %{SERVER_NAME} =guacamole.ragasys.eu
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
ProxyPass /guacamole http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse /guacamole http://guacamole.ragasys.net:8080/guacamole/

ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• El fichero de este segundo host me ha estado dando problemas, y no conseguía acceder, se iba siempre a la página por defecto de apache.
• Para dejarlo fino y funcionando, se ha quedado así de manera definitiva:

<VirtualHost *:80>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

RewriteEngine on
RewriteRule /(.*) https://guacamole.ragasys.eu/guacamole [R,L]

ErrorLog /var/log/apache2/guacamole.ragasys.eu/error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName guacamole.ragasys.eu
ServerAlias guacamole.ragasys.eu

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/guacamole.ragasys.eu/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/guacamole.ragasys.eu/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

ProxyPreserveHost On
SSLProxyEngine On
RewriteEngine On

<Location />
ProxyPass http://guacamole.ragasys.net:8080/guacamole/ flushpackets=on
ProxyPassReverse http://guacamole.ragasys.net:8080/guacamole/
</Location>
ErrorLog /var/log/apache2/guacamole.ragasys.eu/ssl-error.log
CustomLog /var/log/apache2/guacamole.ragasys.eu/ssl-access.log combined
</VirtualHost>

• Certbot renueva los certificados automáticamente, pero podemos verificarlo con, certbot renew –dry-run:

• Aquí vemos que ya podemos acceder a nuestro servidor de Nextcloud desde el exterior, a través del FrontalWeb, con los certificados SSL de Let’s Encrypt: 

• Aquí vemos que ya podemos acceder a nuestro servidor de Apache Guacamole desde el exterior, a través del FrontalWeb, con los certificados SSL de Let’s Encrypt:

• Para comprobar el certificado podemos acceder a  https://www.ssllabs.com/ssltest/ y verificamos el certificado para nuestros dos sitios webs:

Saludos y espero que os sea de ayuda

En este post vamos a ver como crear reglas del firewall en nuestro vCenter para limitar y supervisar el acceso a la plataforma.

• Para todo el tráfico de red entrante en el firewall se pueden aplicar esta acciones:
• Aceptar, permite el paquete con la dirección correspondiente.
• Omitir, descarta el paquete con la dirección correspondiente.
• Rechazar, descarta el paquete con la dirección correspondiente mientras que no se puede acceder al destino de envío.
• Regresar, aplica reglas predeterminadas o específicas del puerto en un paquete con la dirección correspondiente.

• Para configurar reglas de firewall accedemos a la interface VAMI y accedemos a Firewall > AGREGAR:

• Vamos a crear una regla para permitir el acceso desde una determinada IP:

• Y otra regla para denegar todo lo demás:

• Aquí tenemos las dos reglas creadas:

• Ahora si accedemos por SSH a nuestro vCenter y hacemos un iptables -L veremos que ya tenemos estas dos reglas agregadas, me muestra el nombre asignado a esa IP ya que tengo configurado DNS en el vCenter y está resolviendo esa IP:

• Con estas dos reglas le estamos indicando al vCenter que sólo será accesible desde la IP 192.168.14.14, aquí ya configuramos las reglas que nos vengan bien, y vamos añadiendo las que nos vayan haciendo falta, luego con REORDENAR podemos ponerla en el orden que nos venga bien:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar SD-WAN (Software-Defined WAN) en firewalls fortigate.

SD-WAN es una interface virtual compuesta por 2 o más interfaces con acceso a Internet, el objetivo de SD-WAN es hacer un uso mucho más efectivo de nuestras conexiones hacia internet aplicando diferentes criterios de balanceo.

• Antes de empezar vamos a ver las interfaces de red que tenemos configuradas en nuestro firewall, para ello, accedemos a Network > Interfaces y vemos que ya tenemos configuradas la interface LAN y dos interfaces WAN para la salida a Internet, estas dos interfaces son las que vamos a configurar para la SD-WAN:

• Para empezar a configurar SD-WAN accedemos a Network > SD-WAN y la configuramos manualmente:

• Sobre SD-WAN Zones podemos ver que hay creada ya una interface virtual, podemos utilizar esta interface y añadirle los miembros y empezar a trabajar, pero en nuestro caso nos vamos a crear una nueva zona y le vamos a añadir como miembros nuestras dos interfaces WAN:

• Le indicamos un nombre y OK:

• Aquí vemos que ya la tenemos creada:

• Ahora vamos a añadir y configurar las interfaces miembros de esta nueva zona SD-WAN, para ello, accedemos a Create new > SD-WAN Member:

• Añadimos las dos interfaces WAN que tenemos en nuestro firewall, indicándole la zona, la puerta de enlace, el costo y la habilitamos:

• Vemos que ya tenemos la zona creada con nuestras dos interfaces WAN:

• Si accedemos de nuevo a Network > Interfaces podemos ver la interface virtual para la nueva zona SD-WAN y las interfaces que la componen (WAN1 y WAN2):

• El siguiente paso será crearnos la ruta estática por defecto para la salida a Internet por la SD-WAN, para ello, accedemos a Network > Static Routes > Create new y creamos la ruta por defecto para la SD-WAN:

• Aquí vemos que ya la tenemos creada:

• Para verificar que funciona, desde la CLI le hacemos un ping a google.com y vemos que ya recibimos respuesta:

• Empezamos a ver tráfico sobre la SD-WAN, de momento sólo hay tráfico por la WAN1 ya que no tenemos configuradas las performance SLAs, entonces no estamos aplicando ningún tipo de balanceo, simplemente la interface WAN2 entrará a funcionar si la WAN1 cae, ahora más adelante configuraremos las performance SLAs:

• Ahora vamos a crear una política en el firewall para darle acceso web a todos los usuarios de nuestra red interna LAN a través de la SD-WAN:

• Aquí tenemos la política creada:

• Ahora vamos a ver las Performance SLAs, accedemos a Network > SD-WAN > Performance SLAs y vemos que por defecto ya tenemos creadas algunas, con las Performance SLAs vamos a poder balancear por distintos criterios entre todas las interfaces miembros de la SD-WAN, estas performances SLAs que nos ha creado por defecto no tienen asignadas ninguna interface:

• En nuestro caso nos vamos a crear estas dos performances SLAs y las vamos a asociar a las dos interfaces WAN1 y WAN2 de nuestra SD-WAN:

• Como podemos ver, aquí las tenemos ya creadas y configuradas:

• Ahora si accedemos a nuestra zona SD-WAN, ya podemos ver que estamos realizando balanceo de carga, vemos que ya tenemos tráfico en ambas interfaces, no como antes, que todo estaba saliendo por la WAN1 y si fallaba ésta, entonces entraba en funcionamiento la WAN2:

• Realmente el balanceo de carga se realiza a través de las reglas de SD-WAN, y por defecto, ya trae una regla implícita, que realiza un balanceo del 50% en cada interface, nosotros nos podemos ir creando reglas más específicas y configurar balanceos por ejemplo a sitios webs más específicos a través de estas reglas, esta sería la regla implícita por defecto:

• Para Source IP, el tráfico se divide a partes iguales entre los miembros, y las sesiones que comienzan en la misma dirección de origen utilizan la misma ruta:

• Para Sessions, el tráfico se distribuye en función del número de sesiones que se conectan a través del miembro:

• Para Spillover, el miembro de mayor prioridad se utiliza hasta que el ancho de banda supera los umbrales de entrada y salida, el tráfico adicional se envía a través del siguiente miembro SD-WAN:

• Para Source-Destination IP, el tráfico se divide a partes iguales, las sesiones que empiezan en la misma dirección IP de origen y van a la misma dirección IP de destino utilizan la misma ruta:

• Para Volume, la carga de trabajo se distribuye en función del número de paquetes que pasan por el miembro:

• Y estos serían los algoritmos de balanceo de carga utilizados para la regla implícita por defecto, con origen en todos (all) y destinos en todos (all).
• Nosotros nos podemos crear reglas más específicas que se irán ubicando por encima de la regla implícita, teniendo así mayor prioridad, por ejemplo, nos vamos a crear una regla para el acceso a LinkedIn de los usuarios de nuestra LAN, para ello, accedemos a SD-WAN > SD-WAN Rule:

• Damos a Create new, dónde le asignamos un nombre, le indicamos el origen, que serán los equipos de nuestros usuarios, el destino que va a ser el servicio de internet LinkedIn-Web, le indicamos la estrategia del balanceo de carga a seguir, que será la que tenga mejor calidad con respecto al criterio de latencia utilizando uno de los performances SLAs que nos creamos anteriormente:

• Aquí tenemos la regla ya creada y operativa:

• A partir de aquí podemos ir ya configurando las reglas que nos vayan interesando y con los distintos balanceos de carga que nos vengan mejor.

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo crear y configurar una zona DNS secundaria en Azure mediante la zona DNS primaria.

• Como podemos ver, tenemos esta zona DNS primaria en Azure, en este link podéis ver cómo se crea y se configura:

• Ahora, vamos a crear una zona DNS secundaria y delegarla en la zona DNS primaria, para ello, nos vamos a Información general > + Zona secundaria:

• Sobre Datos básicos, le indicamos la suscripción, el grupo de recursos y el nombre del subdominio:

• Sobre Editor de zonas DNS, lo dejamos como está:

• Sobre Etiquetas, podemos configurar las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, Crear:

• Como podemos ver, se ha implementado correctamente:

• Si accedemos al grupo de recursos, podemos ver el recurso que hemos implementado:

• Una vez que hemos creado la zona DNS secundaria ragasysweb.com, comprobamos que la delegación se ha configurado correctamente, para ello debemos verificar, que los registros del servidor de nombres NS de la zona secundaria están en la zona primaria:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo instalar y configurar servidores DNS externos con bind9, estos servidores DNS externos serán los servidores públicos DNS de nuestra infraestructura, dónde vamos a publicar nuestros servicios en Internet, vamos a desplegar un servidor primario y otro secundario.

Que vamos a necesitar:

• Máquina Ubuntu Server 24.04 LTS con el Rol de DNS bind9, este será el DNS primario, ubicada en nuestro entorno on-premise
• Máquina Ubuntu Server 24.04 LTS con el Rol de DNS bind9, este será el DNS secundario, ubicada en nuestro entorno cloud de Azure
• Los dos servidores estarán en nuestra DMZ (on-premise y cloud)
• Proveedor ISP de DNS, dónde vamos a configurar nuestros propios Servidores DNS
• Un dominio DNS público contratado con un ISP, en nuestro caso, el dominio es ragasysweb.com
• En Firewall Fortigate, vamos a configurar un NAT Static y crear las reglas de acceso para la parte on-premise
• En Firewall OPNsense, vamos a configurar un NAT Static y crear las reglas de acceso para la parte cloud

Está será la infraestructura que vamos a desplegar:

• Como podemos ver, tenemos dos máquinas con Ubuntu Server 24.04 LTS, una para el DNS primario on-premise y otra para el DNS secundario en Azure:

• En las dos máquinas debemos de instalar bind9 ejecutando apt-get install bind9:

• Una vez que ya tenemos desplegado el rol de DNS en ambas máquinas, lo primero que vamos a realizar, es en nuestros firewalls fortigate on-premise y opensense en Azure, realizar las configuraciones necesarias para el acceso externo a nuestros servidores DNS públicos.
• Empezamos en el fortigate on-premise, dónde hemos creado este NAT estático, que lo que hace es mapear nuestra IP externa 192.168.1.210 con la IP interna dónde se ubica el servidor DNS, en este caso el servidor DNS primario, mapeando también el puerto TCP/UDP 53 externo con el puerto TCP/UDP 53 interno, que es el que utiliza el servicio DNS:

• Una vez creado el NAT estático, configuramos la siguiente política en nuestro fortigate, dónde le indicamos que desde cualquier origen externo y con destino al servicio DNS Externo de nuestra infraestructura, le vamos a permitir el acceso:

• Seguimos en el opnsense de Azure, dónde hemos creado este NAT estático, que lo que hace es mapear nuestra interface WAN externa con la IP interna dónde se ubica el servidor DNS, en este caso el servidor DNS secundario, mapeando también el puerto TCP/UDP 53 externo con el puerto TCP/UDP 53 interno, que es el que utiliza el servicio DNS:

• Una vez creado el NAT estático, configuramos la siguiente política en nuestro opnsense, dónde le indicamos que desde cualquier origen externo y con destino al servicio DNS Externo de nuestra infraestructura, le vamos a permitir el acceso:

• Una vez que ya tenemos desplegado bind9 en ambas máquinas y los accesos configurados en nuestros firewalls, vamos a trabajar sobre el servidor primario DNS01, y nos creamos una zona primaria de resolución directa «ragasysweb.com» cuyo archivo de zona se llamará «db.ragasysweb.com» y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «ragasysweb.com» {

type master;

file «/var/lib/bind/db.ragasysweb.com»;

};

• Ahora, nos vamos a crear una zona primaria de resolución inversa (esta parte de la resolución inversa, es solo a modo de ejemplo), para que resuelva direcciones IP pertenecientes a la dirección de red 80.31.203.0/24, el nombre del archivo de zona será db.80.31.203.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «203.31.80.in-addr.arpa» {

type master;

file «/var/lib/bind/db.80.31.203.rev»;

};

• Ahora, en nuestro servidor secundario DNS02, vamos a crear una zona secundaria de resolución directa «ragasysweb.com» cuyo archivo de zona se llamará «db.slave.ragasysweb.com» y se almacenará en «/var/lib/bind», en esta zona debemos de indicar cual es el servidor DNS primario:

nano /etc/bind/named.conf.local

zone «ragasysweb.com» {

type slave;

file «/var/lib/bind/db.slave.ragasysweb.com»;

masters { 80.31.203.9; };

};

• Nos creamos también, una zona secundaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 80.31.203.0/24, el nombre del archivo de zona será db.slave.80.31.203.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «203.31.80.in-addr.arpa» {

type slave;

file «/var/lib/bind/db.slave.80.31.203.rev «;

masters { 80.31.203.9; };

};

• Lo siguiente será configurar, la transferencia de zona en el servidor primario DNS01, para que las zonas primarias se transfieran a la zonas secundarias, para ello, volvemos editar, nano /etc/bind/named.conf.local y añadimos el servidor secundario al que tiene que transferir la zona, tanto para la zona directa como para la inversa, allow-transfer { 13.X.X.X; }; Mi ip pública de Azure:

• Una vez configuradas las zonas, vamos a acceder a nuestro proveedor ISP de DNS, y en nuestro dominio público (ragasysweb.com) vamos a configurar nuestros servidores DNS propios o personalizados con nuestras IPs públicas:

• Con esto ya tendríamos configuradas las zonas de resolución directa e inversa, en el servidor primario y en el secundario.
• Para continuar, vamos a crear los registros de las zonas, para indicar que DNS01 y DNS02 son servidores DNS en la zona «ragasysweb.com» y que el servidor autoritativo o con autoridad sobre la zona es DNS01.

• Zona primaria para la resolución directa:

nano /var/lib/bind/db.ragasysweb.com

$ttl                    604800

ragasysweb.com.     IN       SOA    ns1.ragasysweb.com.   it.ragasys.eu  (

2025012401                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

@                                   IN      NS       ns1.ragasysweb.com.

@                                   IN      NS       ns2.ragasysweb.com.

• Zona primaria para la resolución inversa:

nano /var/lib/bind/db.80.31.203.rev

$ttl                    604800

203.31.80.in-addr.arpa.    IN    SOA  ns1.ragasysweb.com.   it.ragasys.eu (

2025012401                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

203.31.80.in-addr.arpa.    IN    NS     ns1.ragasysweb.com.

203.31.80.in-addr.arpa.    IN    NS     ns2.ragasysweb.com.

• Para que las zonas primarias (directa e inversa) se transfieran sobre las secundarias, debemos de crear los registros tipo A y PTR para los dos servidores DNS:

• Hacemos un systemctl restart bind9 y un systemctl status bind9, a ambos servidores, y como podemos ver ya se están replicando las zonas correctamente, haciendo ls /var/lib/bind en el servidor secundario podemos ver como se han creado los ficheros para las zonas secundarias:

• NOTA: La configuración de zona para la resolución inversa, cuando estamos configurando DNS público, realmente no es así, la he mostrando aquí en este lab de esta manera, para que se viese también, a modo de ejemplo, como se replica una zona primaria de resolución inversa en un servidor secundario, para la configuración del PTR debe configurarse, solicitando al proveedor de Internet que ponga un nombre de host a la IP pública, es probable que si contratamos servidores cloud, tengamos una opción para poner el PTR a las IPs públicas.
• Para verificar que todo funciona correctamente, desde cualquier equipo con conexión a Internet le vamos a hacer un ping a uno de los registros DNS de nuestro servidor, y cómo podemos ver, nos responde correctamente:

Saludos y espero que os sea de ayuda

En este post vamos a ver como migrar una IP pública con SKU Basic a SKU Stantard en Microsoft Azure, a partir del 30 de septiembre de 2025, las direcciones IP públicas con SKU básicas se retirarán en Azure, las vamos a poder seguir utilizando hasta entonces; sin embargo, ya no vamos a poder crear nuevas después del 31 de marzo de 2025, para evitar posibles interrupciones del servicio, debemos actualizar a direcciones IP públicas con SKU estándar antes del 30 de septiembre de 2025, aquí vamos a ver cómo hacerlo.

• Aquí vemos que tenemos una IP pública con SKU basic, asignada a la interface de red de una máquina virtual:

• Para migrarla a SKU standard, lo primero que tenemos que hacer es desasociarla de la interface de red de la máquina virtual:

• Le indicamos que Sí:

• Una vez que la hemos desasociado de la interface de red de la máquina virtual, vamos a pinchar sobre el enlace que nos proporciona el portal de Azure, Actualizar a la SKU estándar: Microsoft recomienda una dirección IP pública de SKU estándar para las cargas de trabajo de producción:

• Lo confirmamos y le indicamos que Sí:

• Como podemos ver, ya tenemos nuestra IP pública migrada a SKU Standard:

• Para terminar, volvemos a asociarla a la interface de red de la máquina virtual:

• Seleccionamos la interface de red y aceptamos:

• Como podemos ver, ya la tenemos de nuevo asociada:

• Y ya saben a migrar se ha dicho.

Saludos y espero que os sea de ayuda

En este post, vamos a ver, cómo configurar servidores DNS internos con bind9, para ello, vamos a desplegar dos máquinas con Ubuntu Server 24.04 LTS, una será el servidor DNS primario y la otra el servidor DNS secundario.

• Esta máquina será nuestro servidor DNS primario, y tendrá esta configuración IP:

• Esta máquina será nuestro servidor DNS secundario, y tendrá esta configuración IP:

• En las dos máquinas debemos de instalar bind9 ejecutando apt-get install bind9:

• Lo primero que vamos a realizar sobre el servidor primario DNSBIND1, será crear una zona primaria de resolución directa «ragasys.net» cuyo archivo de zona se llamará «db.ragasys.net» y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «ragasys.net» {

type master;

file «/var/lib/bind/db.ragasys.net»;

};

• Ahora, nos vamos a crear una zona primaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 192.168.5.0/24, el nombre del archivo de zona será db.192.168.5.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «5.168.192.in-addr.arpa» {

type master;

file «/var/lib/bind/db.192.168.5.rev»;

};

• Ahora, en nuestro servidor secundario DNSBIND2, vamos a crear una zona secundaria de resolución directa «ragasys.net» cuyo archivo de zona se llamará «db.slave.ragasys.net» y se almacenará en «/var/lib/bind», en esta zona debemos de indicar cual es el servidor DNS primario:

nano /etc/bind/named.conf.local

zone «ragasys.net» {

type slave;

file «/var/lib/bind/db.slave.ragasys.net»;

masters { 192.168.5.21; };

};

• Nos creamos también, una zona secundaria de resolución inversa, para que resuelva direcciones IP pertenecientes a la dirección de red 192.168.5.0/24, el nombre del archivo de zona será db.slave.192.168.5.rev y se almacenará en «/var/lib/bind»:

nano /etc/bind/named.conf.local

zone «5.168.192.in-addr.arpa» {

type slave;

file «/var/lib/bind/db.slave.192.168.5.rev»;

masters { 192.168.5.21; };

};

• Lo siguiente será configurar, la transferencia de zona en el servidor primario DNSBIND1, para que las zonas primarias se transfieran a las zonas secundarias, para ello, volvemos editar, nano /etc/bind/named.conf.local y añadimos el servidor secundario al que tiene que transferir la zona, tanto para la zona directa como para la inversa, allow-transfer { 192.168.5.22; }; :

• Con esta ya tendríamos configuradas las zonas de resolución directa e inversa, en el servidor primario y en el secundario.
• Para continuar, vamos a crear los registros de las zonas, para indicar que DNSBIND1 y DNSBIND2 son servidores DNS en la zona «ragasys.net» y que el servidor autoritativo o con autoridad sobre la zona es DNSBIND1.

• Zona primaria para la resolución directa:

nano /var/lib/bind/db.ragasys.net

$ttl                    604800

ragasys.net.     IN       SOA    dnsbind1.ragasys.net.   it.ragasys.net  (

2024112800                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

@                                   IN      NS       dnsbind1.ragasys.net.

@                                   IN      NS       dnsbind2.ragasys.net.

• Zona primaria para la resolución inversa:

nano /var/lib/bind/db.192.168.5.rev

$ttl                    604800

5.168.192.in-addr.arpa.    IN    SOA  dnsbind1.ragasys.net.   it.ragasys.net  (

2024112800                 ; Serial

604800                          ; Refresh

86400                            ; Retry

2419200                       ; Expire

604800 )                       ; Negative Cache TTL

5.168.192.in-addr.arpa.    IN    NS     dnsbind1.ragasys.net.

5.168.192.in-addr.arpa.    IN    NS     dnsbind2.ragasys.net.

• Para que las zonas primarias (directa e inversa) se transfieran sobre las secundarias, debemos de crear los registros tipo A y PTR para los dos servidores DNS:

• Hacemos un systemctl restart bind9 y un systemctl status bind9, a ambos servidores, y como podemos ver ya se están replicando las zonas correctamente, haciendo ls /var/lib/bind en el servidor secundario podemos ver como se han creado los ficheros para las zonas secundarias:

• Ahora, vamos a configurar en el archivo de configuración de opciones globales de bind, /etc/bind/named.conf.options, para indicar que el servidor DNS va a usar como reenviadores los servidores DNS con estas direcciones IP, así tendremos resoluciones de nombres externos, realizamos esta configuración en el servidor primario y secundario:

nano /etc/bind/named.conf.options

options {

forwarders { 8.8.8.8; 8.8.4.4; 1.1.1.1; 9.9.9.9; };

};

• Comprobamos lo que llevamos hecho hasta ahora con nslookup, como podemos ver, nos resuelve bien:

• A partir de ahora, ya podemos empezar a crear, todo tipo de registros (A, CNAME, MX, PTR …) en nuestro servidor primario, y automáticamente se replicará en el secundario, como ejemplo hemos creado estos registros:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un web proxy transparente en un firewall Fortigate, un proxy transparente es una combinación de un proxy con NAT para que las conexiones se enruten dentro del proxy y el cliente no tenga que hacer ninguna configuración. En la mayoría de los casos en los que se emplea esta opción, el propio usuario desconoce que se esté utilizando un proxy.

• Para empezar, lo primero que vamos a realizar es habilitar en las características de nuestro firewall el Proxy Explícito, para ello accedemos a Sistema > Visibilidad de Característica > Funciones de seguridad y lo habilitamos:

• Lo siguiente que vamos a realizar será editar una de nuestras políticas de salida a Internet:

• En el Modo de inspección, lo configuraremos como Basado en Proxy, y aplicamos cambios:

• Una vez aplicado el cambio, vamos a editar la política por la CLI:

• Añadimos a la configuración set http-policy-redirect enable:

• Una vez introducido el comando, vemos que en la política ya nos aparece esta nueva opción:

• Habilitamos también en la regla, Inspección SSL > certificate-inspection:

• Ahora debemos acceder a Políticas y Objetos > Política de Proxy, como podemos ver, nos ha creado una política implícita de DENY, denegándonos el acceso a cualquier sitio web:

• Ahora desde cualquier equipo de nuestra LAN se le va a denegar el acceso hacia internet:

• Para habilitar la salida a Internet pasando por el web proxy, accedemos a Políticas y Objectos > Política de Proxy > Crear nuevo:

• Nos creamos esta regla como web transparente, dónde le indicamos a nuestra LAN, que le permitimos la conexión hacia Internet, a través del web proxy:

• Aquí la tenemos creada:

• Si accedemos a la misma web de antes, vemos que ya tenemos acceso:

• Ahora nos vamos a crear estos objetos de dirección, que son los que vamos a utilizar para denegar en las reglas las webs que nos interesen, Políticas y Objetos > Dirección > Crear nuevo > Dirección:

• Configuramos la categoría como Dirección de Proxy, le indicamos un Nombre, seleccionamos el patrón como Coincidencia de Expresión Regular de Host, y le ponemos el patrón que nos interese:

• Nos hemos creado estos objetos de dirección de proxy:

• Ahora nos vamos a crear esta regla para denegar la web o las webs que nos interesen, Políticas y Objectos > Política de Proxy > Crear nuevo:

• En esta regla denegamos a nuestra LAN el acceso a las webs indicadas:

• Como podemos ver, aquí la tenemos, y la ubicamos por encima de la regla de permitir todo el acceso a Internet:

• Ahora si intentamos acceder a cualquiera de estas webs nos va a indicar que no es posible, que tenemos el acceso denegado:

• Vemos que ya tenemos tráfico de denegación en nuestras reglas:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar un servidor DHCP Relay en un firewall Fortigate, este DHCP relay va a escuchar las peticiones DHCP que se producen en la red, y las va a encaminar hacia un servidor DHCP que se encuentra en otra red para que éste las atienda, el servidor DHCP dará una respuesta que enviará hacia el DHCP relay configurado en nuestro Fortigate, y éste la trasladará al cliente que hizo la petición.

• Para empezar, vamos a ver que tenemos configurado nuestro servidor DHCP con el ámbito de red que queremos asignar a nuestros equipos clientes, y estas serían las distintas configuraciones del ámbito:

• Ahora en nuestro firewall fortigate vamos a acceder a Red > Interfaces y editaremos la red dónde vamos a configurar nuestro servidor DHCP relay:

• Sobre la edición de la interface de red, vamos a habilitar el servidor DHCP y en Avanzado seleccionamos el modo Relay, tipo Regular y ponemos la IP del servidor DHCP dónde hemos configurado el ámbito para esta red, en este caso, he puesto dos servidores DHCP ya que en mi infraestructura tengo montado un failover cluster para este servicio con balaceo de carga 50%-50%:

• Como podemos ver, ya lo tenemos configurado:

• Ahora accedemos a una máquina cliente de nuestra infraestructura, y como podemos ver, ya se le está sirviendo el direccionamiento IP y las opciones del ámbito que hemos configurado, todo ello, a través del DHCP relay configurado en el fortigate:

• En nuestra consola del servidor DHCP, podemos ver la concesión de direcciones para esta red:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo bloquear conexiones VPN SSL desde ciertas IPs públicas en un firewall Fortigate.

• En muchas ocasiones podemos ver en los logs de nuestros firewalls fortigate, que están intentando acceder a nuestra conexión VPN SSL desde IPs sospechosas, en esta captura podemos ver intentos de sesión fallidos desde una IP y está intentando probar con distintos usuarios:

• Para bloquear a esta IP pública, lo primero que voy a realizar será crearme un grupo de direcciones llamado blacklistipp, dónde iré añadiendo todas las IPs públicas sospechosas:

• Antes he creado los objetos de cada dirección IP pública, aquí muestro un ejemplo:

• Así nos quedaría:

• Para bloquear las conexiones VPN SSL a estas IPs públicas, accedemos a la consola de nuestro firewall y nos vamos a la configuración de la VPN SSL, con el comando config vpn ssl setting, una vez dentro de la configuración ejecutamos, set source-address «blacklistipp» y set source-address-negate enable, con el comando show podemos ver que la configuración se ha aplicado:

• Ahora, cuando un usuario intente conectarse desde una IP pública de la lista, la VPN SSL será rechazada:

• Es posible ver, que una de estas IPs públicas de la lista bloqueada está intentando conectarse, pero nuestro FortiGate no responde, para ello, ejecutamos el comando diagnose sniffer packet any «host 80.94.95.175 and port 10443» 4:

• Como podemos ver, si ejecutamos el comando, get vpn ssl monitor, se permitirá la conexión desde las IPs que no estén en la lista y se establecerán las conexiones:

• Otra forma de limitar el acceso, es irse a la Configuración de SSL_VPN > Restringir Acceso y Limitar acceso a hosts específicos, dónde configuro la restricción para el grupo de IPs públicas bloqueadas, aquí el problema es que la conexión no se rechaza en una primera instancia, es decir, nos va a dejar introducir las credenciales y una vez introducidas bloquea la conexión, con el método visto anteriormente por consola, la conexión se rechaza desde primera hora:

• Sobre este post realizado por mi compañero Héctor Herrero del blog Bujarra, podemos aplicar las listas dinámicas que nos está indicando sobre la configuración de la VPN, quedando de esta manera:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar una VPN site to site entre dos redes virtuales de Azure.

Las redes virtuales pueden estar en distintas regiones y provenir de distintas suscripciones. Al conectar redes virtuales provenientes de distintas suscripciones, no es necesario que las suscripciones estén asociadas con el mismo inquilino. Este tipo de configuración crea una conexión entre dos puertas de enlace de red virtual.

Configurar una conexión de red virtual a red virtual es una forma sencilla de conectar redes virtuales. Cuando conecta una red virtual a otra mediante el tipo de conexión entre redes virtuales (VNet2VNet) es parecida a la creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de conectividad usan una puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y funcionan de la misma forma en lo relativo a la comunicación. Sin embargo, la manera en que se configura la puerta de enlace de red local es distinta.

Cuando se crea una conexión de red virtual a red virtual, el espacio de direcciones de la puerta de enlace de red local se crea y rellena automáticamente. Si actualiza el espacio de direcciones de una de las redes virtuales, la otra enruta automáticamente al espacio de direcciones actualizado. Por lo general, es más rápido y sencillo crear una conexión de red virtual a red virtual que una conexión de sitio a sitio. Sin embargo, la puerta de enlace de red local no está visible en esta configuración.

Fuente: Microsoft Learn vpns2svnettovnet

Esta será la topología utilizada en esta configuración:

• Antes de empezar, vamos a explicar la configuración que va a tener nuestra infraestructura.
• Para VNet1:

• Configuración de la red virtual.
• Name: vnet1
• Espacio de direcciones:10.1.0.0/16
• Suscripción: Seleccionamos nuestra suscripción
• Grupo de recursos: vpnvnet1-rg
• Ubicación: Oeste de Europa
• Subred
• Name: lan1vnet1
• Intervalo de direcciones:10.1.1.0/24

• Configuración de puerta de enlace de red virtual.
• Name: vnet1gw
• Grupo de recursos: Oeste de Europa
• Generación: Generación 2
• Tipo de puerta de enlace: VPN
• Tipo de VPN: Basada en rutas
• SKU: VpnGw2
• Generación: generación 2
• Red virtual: vnet1
• Intervalo de direcciones de subred de puerta de enlace:10.1.255.0/27
• Dirección IP pública: Crear nuevo
• Nombre de dirección IP pública: vnet1gwpip
• Habilitar el modo activo/activo: deshabilitado
• Configurar BGP: deshabilitado

• Conexiones.
• Tipo de conexión: Seleccionamos de red virtual a red virtual
• Establecer conectividad bidireccional: Seleccionar este valor
• Nombre de la primera conexión: vnet1-to-vnet2
• Nombre de la segunda conexión: vnet2-to-vnet1
• Región: Oeste de Europa
• Configuración:
• Primera puerta de enlace de red virtual: Seleccionamos vnet1gw
• Segunda puerta de enlace de red virtual: Seleccionamos vnet2gw
• Clave compartida (PSK): En este campo, escribimos una clave compartida para la conexión, dicha clave podemos generarla o crearla manualmente, en una conexión de sitio a sitio, la clave que usa es la misma del dispositivo local y de la conexión de puerta de enlace de red virtual, aquí el concepto es similar, salvo en que en lugar de conectarse a un dispositivo VPN, la conexión se establece con otra puerta de enlace de red virtual.
• Protocolo IKE: IKEv2

• Para VNet2:

• Configuración de la red virtual.
• Name: vnet2
• Espacio de direcciones:10.2.0.0/16
• Suscripción: Seleccionamos nuestra suscripción
• Grupo de recursos: vpnvnet2-rg
• Ubicación: Oeste de Europa
• Subred
• Name: lan1vnet2
• Intervalo de direcciones:10.2.1.0/24

• Configuración de puerta de enlace de red virtual.
• Name: vnet2gw
• Grupo de recursos: Oeste de Europa
• Generación: Generación 2
• Tipo de puerta de enlace: VPN
• Tipo de VPN: Basada en rutas
• SKU: VpnGw2
• Generación: generación 2
• Red virtual: vnet2
• Intervalo de direcciones de subred de puerta de enlace:10.2.255.0/27
• Dirección IP pública: Crear nuevo
• Nombre de dirección IP pública: vnet2gwpip
• Habilitar el modo activo/activo: deshabilitado
• Configurar BGP: deshabilitado

• Conexiones.
• Tipo de conexión: Seleccionamos de red virtual a red virtual
• Establecer conectividad bidireccional: Seleccionar este valor
• Nombre de la primera conexión: vnet1-to-vnet2
• Nombre de la segunda conexión: vnet2-to-vnet1
• Región: Oeste de Europa
• Configuración:
• Primera puerta de enlace de red virtual: Seleccionamos vnet1gw
• Segunda puerta de enlace de red virtual: Seleccionamos vnet2gw
• Clave compartida (PSK): En este campo, escribimos una clave compartida para la conexión, dicha clave podemos generarla o crearla manualmente, en una conexión de sitio a sitio, la clave que usa es la misma del dispositivo local y de la conexión de puerta de enlace de red virtual, aquí el concepto es similar, salvo en que en lugar de conectarse a un dispositivo VPN, la conexión se establece con otra puerta de enlace de red virtual.
• Protocolo IKE: IKEv2

• Empezaremos creando la red virtual vnet1, para ello, accedemos a Redes virtuales > Crear:

• Sobre Datos básicos, le indicamos, el grupo de recursos, el nombre y la región:

• Sobre Seguridad, no vamos a configurar nada, lo dejamos por defecto:

• Sobre Direcciones IP, configuramos el espacio de direcciones, y nos creamos las subredes para lan, dónde irán ubicadas las máquinas virtuales, y para la puerta de enlace de red virtual:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, si todo está bien, damos a Crear:

• Vemos que comienza a crearse:

• Aquí vemos que ya se ha completado, accedemos al nuevo recurso de vnet creado:

• Para la red virtual vnet2, seguimos los mismos pasos, cambiando el espacio de direcciones y el rango de las subredes:

• Una vez creadas las redes virtuales, vamos a crear la puerta de enlace de red virtual para la vnet1, para ello, accedemos a Puerta de enlace de red virtual > Crear:

• Sobre Datos básicos, vamos a introducir los valores descritos anteriormente:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado y que la validación ha sido superada, si todo está bien, damos a Crear:

• Una puerta de enlace puede tardar hasta 45 minutos en crearse e implementarse completamente, aquí podemos ver que la implementación se ha completado correctamente:

• Si nos vamos a Puertas de enlace de red virtual, podemos ver que ya la tenemos creada:

• La puerta de enlace de red virtual para la vnet2, se crea exactamente igual que para la vnet1, dónde también, vamos a introducir los valores descritos anteriormente:

• Si nos vamos a Puertas de enlace de red virtual, podemos ver que ya la tenemos creada:

• Una vez que ya tenemos, las dos puertas de enlace de red virtual creadas y configuradas, vamos a crear y configurar las conexiones entre estas dos puertas de enlace de red virtual, para ello, accedemos a Conexiones > Crear:

• Sobre Datos básicos, vamos a introducir los valores descritos anteriormente:

• Sobre Opciones, configuramos los parámetros descritos anteriormente:

• Sobre Etiquetas, podemos añadir las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado y que la validación ha sido superada, si todo está bien, damos a Crear:

• Como podemos ver, las conexiones se han creado correctamente:

• Si accedemos a Conexiones, podemos ver, que ya las tenemos creadas y conectadas:

• Ahora, para verificar que la VPN Site to Site entre VNets funciona correctamente, tenemos estas dos máquinas, una llamada litio en vnet1 y otra llamada sodio en vnet2, como podemos ver, ya tenemos comunicación entre ellas, a través de la VPN que hemos creado:

• Ahora vemos, que ya se está generando tráfico entre las dos conexiones:

Saludos y espero que os sea de ayuda

En este post (hoy cortito), vamos a ver, cómo configurar la interface de red de un equipo Windows a través de la consola cmd.

• Nos abrimos un terminal de cmd como administrador:

• Y ejecutamos el comando netsh interface ipv4 set address name=»LAN» source=static address=192.168.5.2 mask=255.255.255.0 gateway=192.168.5.210:

• Ahora para configurar el DNS primario ejecutamos, netsh interface ip add dnsservers «LAN» 8.8.8.8 index=1:

• Para terminar, configuramos el DNS secundario ejecutando, netsh interface ip add dnsservers «LAN» 8.8.4.4 index=2:

• Para verificar que todo se ha configurado correctamente, ejecutamos un ipconfig /all:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo configurar el tránsito de la puerta de enlace de VPN para el emparejamiento de red virtual, el emparejamiento de red virtual conecta perfectamente dos redes virtuales de Azure, combinando las dos redes virtuales en una sola, para favorecer la conectividad. El tránsito de puerta de enlace es una propiedad del emparejamiento que permite que una red virtual utilice la puerta de enlace de VPN en la red virtual emparejada para la conectividad entre redes locales o entre redes virtuales.

Esta será la topología utilizada en esta configuración:

• Antes de empezar, vamos a explicar cómo está configurada nuestra infraestructura.
• Para la parte On-premise, tenemos un firewall Fortigate, en el cuál, hay configurado una red dónde van ubicadas las máquinas de esta parte de la infraestructura y hay configurado un extremo de la VPN site to site entre la parte ON-premise y Azure, al final de estas explicaciones, os pondré un enlace a este mismo blog dónde se muestra como se configura esta VPN site to site.

• Esta es la VLAN que vamos a utilizar para la parte ON-premise:

• Aquí vemos la VPN site to site entre la parte On-premise y Azure levantada:

• Estas son las rutas estáticas hacia las redes virtuales de Azure:

• Para la parte Cloud en Azure, tenemos tres redes virtuales, una central, llamada hub-vnet, dónde se ubica la subred de puerta de enlace y dónde hemos configurado la puerta de enlace de red virtual que se encarga de la comunicación de la VPN site to site entre la parte On-premise y Azure, sobre esta vnet vamos a configurar el emparejamiento entre las vnets spoke1-vnet y spoke2-vnet y el tránsito de puerta de enlace que va a permitir comunicar estas dos vnets entre sí y va a permitir la comunicación también con la parte On-premise.
• Red virtual hub-vnet:

• Red virtual spoke1-vnet:

• Red virtual spoke2-vnet:

• Puerta de enlace de red virtual:

• Puerta de enlace de red local:

• Conexión:

• En este link os dejo como configurar una VPN site to site entre la parte On-premise y Azure.
• Una vez explicada toda la infraestructura, vamos a ver como configurar el emparejamiento entre redes virtuales y el tránsito de la puerta de enlace de VPN.
• Vamos a configurar el emparejamiento y el tránsito entre las redes virtuales hub-vnet y spoke1-vnet, para ello, accedemos a, red virtual hub-vnet > Emparejamientos > Agregar:

• Red virtual hub-vnet:
• Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo, HubToSpoke1
• Tráfico hacia la red virtual remota: Permitir
• Tráfico reenviado desde la red virtual remota: Permitir
• Puerta de enlace de red virtual: Usar la puerta de enlace de esta red virtual o el servidor de rutas
• Red virtual spoke1-vnet:
• Nombre del vínculo de emparejamiento: Asigne un nombre al vínculo, Spoke1ToHub
• Tráfico hacia la red virtual remota: Permitir
• Tráfico reenviado desde la red virtual remota: Permitir
• Puerta de enlace de red virtual: Usar la puerta de enlace de red virtual remota o el servidor de rutas

• Como podemos ver, aquí tenemos los emparejamientos y el tránsito de puerta de enlace habilitado:

• El emparejamiento y el tránsito entre las redes virtuales hub-vnet y spoke2-vnet, se configura exactamente igual que el anterior:

• Para verificar que las máquinas virtuales de las redes virtuales spoke1-vnet y spoke2-vnet, se comunican con las máquinas virtuales del entorno on-premise, vamos a lanzar varios pings entre ellas.
• Máquina en red virtual spoke1-vnet:

• Máquina en red virtual spoke2-vnet:

• Máquina en red on-premise:

Saludos y espero que os sea de ayuda

En este post vamos a ver cómo desplegar y configurar una puerta de enlace NAT en Azure, el servicio NAT Gateway proporciona conectividad de salida a Internet para máquinas virtuales en Azure, con esta configuración, las máquinas virtuales de nuestro entorno de Azure saldrán a Internet a través de la puerta de enlace NAT compartiendo una única dirección IP pública, sobre la red virtual que vamos a desplegar le vamos a configurar un host de Bastion, a través del cuál vamos a acceder a nuestras máquinas virtuales y verificar que el NAT Gateway funciona correctamente.

Esta será la topología utilizada en esta configuración:

• Antes de empezar, nos hemos creado, este grupo de recursos, dónde vamos a alojar todos los recursos de esta infraestructura:

• Lo primero que vamos a realizar, será desplegar la puerta de enlace NAT, para ello, accedemos a Puertas de enlace NAT > Crear:

• Sobre Datos básicos, le indicamos el grupo de recursos, nombre de la puerta de enlace NAT, la Región, no seleccionamos zona de disponibilidad y el tiempo de espera de inactividad TCP lo dejamos en 4 minutos:

• Sobre IP de salida, nos creamos una nueva dirección IP pública:

• Sobre Subred, de momento no configuramos nada, ya que la red virtual y sus subredes todavía no las hemos creado, lo vamos a realizar en un paso posterior y agregaremos las subredes que nos interesen a la puerta de enlace NAT:

• Sobre Etiquetas, podemos configurar las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, Crear:

• Como podemos ver, se ha implementado correctamente:

• Si accedemos al grupo de recursos, podemos ver los dos recursos que hemos implementado:

• Ahora vamos a crear la red virtual y el host de bastion, para ello, accedemos Redes virtuales > Crear:

• Sobre Datos básicos, le indicamos el grupo de recursos, nombre de la red virtual y la Región:

• Sobre Seguridad, habilitamos Bastion en la sección Azure Bastion. Azure Bastion usa el explorador para conectarse a las máquinas virtuales de la red virtual a través del shell seguro (SSH) o el protocolo de escritorio remoto (RDP) mediante sus direcciones IP privadas. Las máquinas virtuales no necesitan direcciones IP públicas, software cliente ni configuración especial, le indicamos el nombre de host y nos creamos una nueva dirección IP pública:

• Sobre Direcciones IP, editamos el espacio de direcciones que nos interese, como podemos ver, la subred de Azure Bastion ya se ha creado, editamos la subred default, dónde le indicamos un nombre, el intervalo de direcciones de subred, y que utilice la puerta de enlace NAT que nos creamos anteriormente:

• Sobre Etiquetas, podemos configurar las que nos interesen:

• Sobre Revisar y crear, nos muestra un resumen de todo lo configurado, Crear:

• Como podemos ver, se ha implementado correctamente:

• Si accedemos al grupo de recursos, podemos ver los tres recursos que hemos implementado:

• Ahora, si accedemos a la puerta de enlace NAT > Subredes, podemos ver, que la subred que creamos anteriormente ya está implementada en esta puerta de enlace NAT, tal y como le indicamos:

• Para verificar que todo lo que hemos desplegado y configurado funciona correctamente, vamos a crearnos una máquina virtual ubicada en la red virtual vnet-natgw y subred subnet-lan:

• Accedemos a esta máquina virtual, a través del host bastion que nos creamos anteriormente:

• Como podemos ver, ya estamos dentro de la máquina:

• Para verificar que estamos saliendo por la IP pública de la puerta de enlace NAT, vamos a abrirnos un PowerShell y ejecutaremos este comando, Invoke-RestMethod -Uri https://ipinfo.io y cómo podemos ver, estamos saliendo por la IP pública de nuestro NAT Gateway:

Saludos y espero que os sea de ayuda