El firewall de Azure le borraba la dirección a cada visitante

Mi laboratorio de Azure tiene una sola puerta: la dirección pública del firewall. Por ella sale todo lo que el clúster necesita y por ella entra todo lo que llega desde internet. Me gustaba ese diseño, porque a un tercero le basta con poner una dirección en su lista de permitidos.

El día que conecté la primera aplicación detrás de esa puerta abrí el registro de acceso para ver quién llegaba, y todas las peticiones venían de la misma dirección privada, una de la subred del propio firewall. Ningún visitante aparecía con su dirección real.

Por qué pasa

La entrada funciona con una traducción de direcciones en el firewall: la petición llega a la dirección pública y el firewall la reenvía a un balanceador interno del clúster. Lo que yo no esperaba es que, además del destino, el firewall reescribe el origen. Lo hace siempre con el tráfico que entra por una regla de traducción, para que la respuesta vuelva por él y la sesión no se rompa.

Microsoft lo documenta, pero en ninguna de las guías que leí antes de empezar aparecía como algo que hubiera que planear.

Mi primera reacción fue desconfiar de mi propia configuración, así que lo convertí en prueba. La verificación número nueve del laboratorio manda una petición desde internet, lee el registro del ingress y exige que el origen anotado sea una dirección de la subred del firewall. Si algún día Azure cambia este comportamiento, esa prueba falla y me entero.

La trampa que parece arreglarlo

Quien haya trabajado con Kubernetes conoce el ajuste que preserva la dirección del cliente en un balanceador, externalTrafficPolicy en Local, y el manifiesto del ingress ya lo trae encendido. Aquí no sirve de nada: preserva la dirección que recibe, y la que recibe ya es la del firewall. La información se perdió un salto antes.

Lo cuento porque es exactamente lo primero que uno tocaría, y lo primero que uno toca es lo que más tiempo hace perder cuando no funciona.

Lo que se pierde

Sin la dirección del visitante no puedes limitar peticiones por cliente, no puedes aplicar reglas por país y el registro de acceso deja de servir para investigar un abuso. En un laboratorio me da igual. En una tienda en línea o un portal con usuarios reales es un requisito que casi siempre aparece, y suele aparecer tarde.

La única forma de recuperarla es poner algo más afuera que lea la dirección antes del firewall y la pase en un encabezado, una pasarela de aplicación o un borde global. Cada una es otro producto, con su precio y su ciclo de vida.

Viniendo de Google Cloud, esto fue lo que más me sorprendió. Allá un balanceador de red externo de paso entrega la dirección original del cliente, y uno de aplicación la pasa en X-Forwarded-For. En Azure, hacer del firewall la única puerta de entrada tiene este precio, y conviene decidirlo sabiéndolo.

Las opciones que pesé

Me quedé con la traducción en el firewall porque el laboratorio corre en una cuenta de prueba que solo permite tres direcciones públicas, y el firewall ya gasta dos: una para el tráfico y otra para la administración que exige el nivel Basic. Un balanceador público por aplicación no cabía y, además, sacaba la entrada de la vista del firewall.

El borde global lo descarté por un costo que no se ve en la tabla de precios: se cobra por mes y no prorratea, y mi laboratorio se destruye al terminar cada sesión para no pagar el firewall por horas que no uso.

Lo que hago distinto ahora

Cuando una propuesta menciona reglas por país, límites por cliente o trazabilidad del visitante, ya sé que la traducción en el firewall no alcanza como entrada, y la pieza de capa 7 se presupuesta desde el primer día. Descubrirlo en producción obliga a rediseñar la entrada con los clientes adentro.

La decisión completa, con las referencias de Microsoft, está en el repositorio del laboratorio, en la decisión número doce.

Me queda una pregunta para cualquier arquitectura con un firewall en la entrada: ¿qué requisito de tu cliente depende de saber quién llama, y en qué salto de tu red se pierde ese dato?