Cuando trabajamos en entornos de redes globales distribuidas, uno de los aspectos fundamentales a tener en cuenta es la inspección de tráfico. Este punto cobra especial relevancia cuando, además de tener varios entornos, tenemos también conectividad con terceras partes y queremos tener un control efectivo del tráfico que entra y sale de nuestra red.
Uno de los principales servicios que proporciona AWS para inspeccionar tráfico en entornos de red complejos es AWS Network Firewall. En este segundo post de la serie sobre AWS Cloud WAN, vamos a ver cómo podemos aprovechar las características de este servicio para realizar inspección del tráfico con AWS Network Firewall.
Antes de entrar en materia, es necesario que nos familiaricemos con un nuevo componente que no hemos abordado en el post anterior: Network Function Groups.
Network Function Groups #
Los Network Function Groups (NFG) son un tipo de segmento especial. Al igual que los segmentos normales (Core Network Segments), un NFG consiste en un conjunto de attachments; sin embargo, estos attachments están especializados en funciones de networking o seguridad. Por lo tanto, un NFG se puede utilizar para funciones de inspección de tráfico, pero también para funciones de agregación de tráfico de salida, como VPCs de egress centralizado.
Veamos las diferencias clave entre un Core Network Segment y un Network Function Group.
| Core Network Segment | Network Function Group |
|---|---|
| Los segmentos son dominios de enrutamiento aislados. Los attachments se pueden asociar con control total sobre las rutas dentro del segmento y entre segmentos. | Los NFG tienen sus propias tablas de rutas. Estas tablas de rutas se propagan automáticamente (con redirecciones del siguiente salto) en función de la configuración del service insertion definido en la Core Network Policy. A pesar de tener total visibilidad de estas rutas, no se pueden añadir, eliminar o compartir de forma alguna. |
| Cuando asocias un attachment con un segmento de AWS Cloud WAN, los CIDR de la VPC y/o las rutas dinámicas se propagarán en la tabla de rutas del segmento correspondiente. | Cuando asocias un attachment con un NFG (Network Function Group), los CIDR de la VPC y/o las rutas dinámicas no se propagarán en la tabla de rutas del NFG. |
Service insertions #
Como hemos visto, los NFG nos permiten agrupar las funciones de red que necesitamos para realizar la inspección del tráfico (por ejemplo, VPCs), pero necesitamos una manera de indicar al resto de nuestra red global cómo redirigir el tráfico por estas funciones. Aquí es donde entran en juego las service insertions, que son ni más ni menos que segment actions aplicadas a los NFG.
Mediante service insertions podemos redirigir el tráfico dentro de un mismo segmento o entre segmentos para que pase, por ejemplo, por una VPC con un endpoint de AWS Network Firewall.
Hay dos modos principales de inspección:
-
Inspección de tráfico norte-sur, en la que el tráfico fluye desde nuestra red global hacia una VPC de egress para su inspección y salida hacia internet.
-
Inspección de tráfico este-oeste, en la que el tráfico fluye entre attachments de nuestra red global. En este caso, la inspección se puede realizar de dos maneras: bien entre attachments que están situados en segmentos distintos —por ejemplo, cuando el tráfico fluye del segmento de producción al segmento de desarrollo— o bien dentro del mismo segmento.
La configuración de las service insertions se realiza en la Core Network Policy, en el mismo bloque que configura las acciones de los segmentos segment-actions. Para ello, usaremos los parámetros action y mode.
Para el primer caso, tráfico norte-sur, el parámetro action tendrá el valor sent-to. Esta acción envía el tráfico hacia la VPC de inspección y de ahí hacia internet o el entorno on-premise, según el caso. En este caso, el tráfico no vuelve otra vez a AWS Cloud WAN.
Para el segundo caso, tráfico este-oeste, el parámetro action tendrá el valor sent-via. Esta acción envía el tráfico hacia la VPC de inspección y después lo reencamina a su destino, por ejemplo, otra VPC.
Cuando usamos la acción sent-via, podemos elegir cómo se reencaminará el tráfico antes de alcanzar su destino definitivo con el parámetro mode. Los valores pueden ser:
single-hop: El tráfico pasa por un único attachment de inspección, que puede estar en la región de origen o en la de destino. Por defecto, se usa el de la región de origen, aunque se puede configurar.dual-hop: El tráfico pasa por attachments de inspección tanto en la región de origen como en la de destino.
Para configuraciones más complejas, te recomiendo que consultes la referencia en Core network policy version parameters in AWS Cloud WAN.
Configuración de ejemplo #
Para ilustrar mejor cómo aplicar estas configuraciones, se proporciona una Core Network Policy de ejemplo.
{
"version": "2021.12",
"core-network-configuration": {
"asn-ranges": [
"64512-64555"
],
"edge-locations": [
{
"asn": 64512,
"location": "eu-west-1"
},
{
"asn": 64513,
"location": "us-east-1"
}
],
"vpn-ecmp-support": false
},
"segments": [
{
"isolate-attachments": false,
"name": "segmentA",
"require-attachment-acceptance": false
},
{
"isolate-attachments": false,
"name": "segmentB",
"require-attachment-acceptance": false
}
],
"network-function-groups": [
{
"name": "inspection",
"require-attachment-acceptance": false
}
],
"attachment-policies": [
{
"rule-number": 100,
"action": {
"association-method": "tag",
"tag-value-of-key": "segment"
},
"conditions": [
{
"key": "segment",
"type": "tag-exists"
}
]
},
{
"rule-number": 200,
"action": {
"add-to-network-function-group": "inspection"
},
"conditions": [
{
"key": "inspection",
"type": "tag-exists"
}
]
}
],
"segment-actions": [
{
"action": "send-via",
"mode": "dual-hop",
"segment": "segmentA",
"via": {
"network-function-groups": [
"inspection"
]
},
"when-sent-to": {
"segments": [
"segmentB"
]
}
}
]
}
En esta política se definen dos segmentos, segmentA y segmentB, y sus correspondientes attachment-policies.
La política también define un Network Function Group llamado inspection. Sobre este NFG también se define una regla en attachment-policies para asociar las VPCs de inspección cuando estas se añadan.
Por último, en el bloque segment-actions es donde se configura la Service Insertion. En este caso, como vamos a realizar inspección este-oeste, lo indicamos con el parámetro "action": "send-via". Además, vamos a hacer inspección tanto en la región de origen como en la de destino, por lo tanto lo reflejamos en la política con el parámetro "mode": "dual-hop".
Para indicar por dónde se encuentran los attachments encargados de la inspección, lo hacemos con el parámetro via, donde le indicamos el NFG que hemos definido previamente.
El parámetro when-sent-to nos sirve para indicar cuándo realizar la inspección en función del destino. En este caso, cuando se dirija el tráfico hacia segmentB. Si necesitáramos realizar la inspección para cualquier segmento de destino, podríamos simplemente indicarlo mediante un asterisco: "when-sent-to": {"segments": ["*"]}.
segmentA y el destino segmentB, como AWS Cloud WAN genera rutas para mantener la simetría del tráfico, también se realizará la inspección del tráfico cuando el origen sea segmentB y el destino segmentA.
Demo #
Como siempre, la mejor manera de consolidar estos conceptos es con una demo.
Aquí puedes acceder al código de la demo para desplegarla en tu propia cuenta:
Vamos con ello.
En esta demo vamos a ver cómo redirigir el tráfico este-oeste entre la Instancia A y la Instancia B para que pase por VPCs de inspección tanto en la región de origen como en la de destino. Estas VPCs de inspección tienen un AWS Network Firewall Endpoint. Al tratarse de una demo, la Network Firewall Policy correspondiente deja pasar todo el tráfico.
Veamos cómo se comporta:
-
El tráfico saliente de la Instancia A llega hasta la Core Network por
segmentA. Las rutas que se aplican asegmentAen la regióneu-west-1son las siguientes:CIDR Destination Route Type 192.168.1.0/25VPC A PROPAGATED 192.168.1.128/25Inspection A PROPAGATED Como el destino de la conexión es la Instancia B con IP
192.168.1.159, la ruta que aplica es192.168.1.128/25, que redirige el tráfico hacia la VPC Inspection A. -
Una vez que el tráfico alcanza la VPC Inspection A, es evaluado por Network Firewall y devuelto a la Core Network.
-
En este caso, el tráfico pasa por el Network Function Group que tiene las siguientes rutas en la región
eu-west-1:CIDR Destination Route Type 192.168.1.0/25VPC A PROPAGATED 192.168.1.128/25Inspection B PROPAGATED La ruta a aplicar sigue siendo
192.168.1.128/25, que en este caso redirige hacia Inspection B. -
Tras repetir la misma operación de inspección, esta vez en la región
us-east-1, el tráfico vuelve a pasar por el NFG. En esta ocasión, las rutas que tiene paraus-east-1son:CIDR Destination Route Type 192.168.1.0/25Inspection A PROPAGATED 192.168.1.128/25VPC B PROPAGATED Al aplicar la ruta
192.168.1.128/25, esta vez el tráfico se dirige a su destino final, VPC B, y por tanto alcanza la Instancia B.
Una vez visto cuál es el recorrido que seguirá el tráfico, vamos a desplegar la infraestructura y hacer la prueba empírica.
terraform init
terraform apply
Una vez desplegado, comprobamos que la Instancia B, que está en la región us-east-1 y asociada al segmento segmentB, puede ser alcanzada desde la Instancia A, ubicada en la región eu-west-1 y en el segmentA.
-
Conéctate a la instancia A a través de SSM Session Manager. Una vez allí, ejecuta un
pinga la instancia B.sh-5.2$ uname -a Linux ip-192-168-1-35.eu-west-1.compute.internal 6.1.134-152.225.amzn2023.aarch64 #1 SMP Wed May 7 09:10:22 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux sh-5.2$ ping 192.168.1.159 PING 192.168.1.159 (192.168.1.159) 56(84) bytes of data. 64 bytes from 192.168.1.159: icmp_seq=1 ttl=119 time=80.1 ms 64 bytes from 192.168.1.159: icmp_seq=2 ttl=119 time=71.0 ms 64 bytes from 192.168.1.159: icmp_seq=3 ttl=119 time=70.9 ms 64 bytes from 192.168.1.159: icmp_seq=4 ttl=119 time=70.9 ms 64 bytes from 192.168.1.159: icmp_seq=5 ttl=119 time=70.9 ms 64 bytes from 192.168.1.159: icmp_seq=6 ttl=119 time=70.9 ms 64 bytes from 192.168.1.159: icmp_seq=7 ttl=119 time=70.9 ms ^C --- 192.168.1.159 ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6007ms rtt min/avg/max/mdev = 70.910/72.247/80.133/3.219 msComo podemos ver, la instancia B es alcanzada desde la instancia A sin ningún problema. Adicionalmente, si lo deseas, puedes modificar la Firewall Policy para cortar el tráfico y comprobar que el tráfico pasa efectivamente por ella.
sh-5.2$ ping 192.168.1.35 PING 192.168.1.35 (192.168.1.35) 56(84) bytes of data. ^C --- 192.168.1.35 ping statistics --- 23 packets transmitted, 0 received, 100% packet loss, time 22892ms -
Ahora, conéctate a la instancia B mediante SSM Session Manager. Una vez dentro, ejecuta
pinghacia la instancia A.sh-5.2$ uname -a Linux ip-192-168-1-159.ec2.internal 6.1.134-152.225.amzn2023.aarch64 #1 SMP Wed May 7 09:10:22 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux sh-5.2$ ping 192.168.1.35 PING 192.168.1.35 (192.168.1.35) 56(84) bytes of data. 64 bytes from 192.168.1.35: icmp_seq=1 ttl=119 time=76.0 ms 64 bytes from 192.168.1.35: icmp_seq=2 ttl=119 time=70.6 ms 64 bytes from 192.168.1.35: icmp_seq=3 ttl=119 time=70.5 ms 64 bytes from 192.168.1.35: icmp_seq=4 ttl=119 time=70.5 ms 64 bytes from 192.168.1.35: icmp_seq=5 ttl=119 time=70.6 ms 64 bytes from 192.168.1.35: icmp_seq=6 ttl=119 time=70.6 ms 64 bytes from 192.168.1.35: icmp_seq=7 ttl=119 time=70.6 ms 64 bytes from 192.168.1.35: icmp_seq=8 ttl=119 time=70.6 ms 64 bytes from 192.168.1.35: icmp_seq=9 ttl=119 time=70.6 ms ^C --- 192.168.1.35 ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8013ms rtt min/avg/max/mdev = 70.529/71.191/75.977/1.692 msComo vimos en la explicación del diagrama, el tráfico en sentido inverso también llega a su destino.
Siéntete libre de modificar el código Terraform proporcionado para experimentar, modificar la Service Insertion o abrir y cerrar los Network Firewalls.
Recuerda destruir los recursos de Terraform cuando hayas terminado de usarlos.
terraform destroy
Wrapping up #
En este artículo hemos explorado cómo integrar AWS Network Firewall con AWS Cloud WAN mediante Network Function Groups y service insertions para inspeccionar tráfico en arquitecturas globales distribuidas. A través de una configuración detallada y una demo práctica, vimos cómo dirigir el tráfico este-oeste entre regiones para su inspección, asegurando un control granular del flujo de red.
Este artículo pertenece a una serie sobre AWS Cloud WAN. Si te ha parecido interesante, suscríbete a la newsletter y sé el primero en enterarte cuando se publique el siguiente.
Subscribir