Bloquear IPsec sin romper el Wi-Fi Calling del teléfono

La petición siempre llega con la misma forma: cierra IPsec en el borde porque transporta túneles que nadie aprobó, y la primera queja viene de alguien cuyo teléfono dejó de hacer llamadas por Wi-Fi. Ambos hechos son ciertos a la vez, y ninguno justifica abandonar el control. Lo que necesita el cortafuegos es una excepción de servicio con una función nombrada, un origen acotado, destinos documentados y un responsable. Cinco pasos la convierten en una regla que un desconocido podrá revisar el año que viene.

Nombra el servicio antes de nombrar el protocolo

Un teléfono de escritorio en un servicio SIP y un terminal que hace el Wi-Fi Calling del operador no comparten perfil de red, y VoIP como término de cortafuegos no describe a ninguno de los dos. Los datos de puertos y destinos deben venir del proveedor o del operador que presta el servicio, no de una lista de puertos recordada de otro sistema telefónico. Esa es la diferencia entre una regla que protege una función y una regla que protege una palabra.

La referencia de puertos de servicio de Apple enumera UDP 500 y 4500 para Wi-Fi Calling, que resulta ser justo el par que descartan la mayoría de los bloqueos totales de IPsec. Escribe el nombre de la función en el registro de cambio junto a esos puertos. Añade la versión o la fecha de la referencia que usaste, porque las tablas de los proveedores se editan. Una regla que nombra el servicio para el que existe se puede revisar; una que nombra una categoría de protocolo, no.

Escribe la excepción como contrato, no como favor

La excepción declara la función permitida, las clases de dispositivo que la usan, el transporte que necesita y los destinos que documenta la parte responsable. También lleva un responsable y una fecha de revisión, porque los extremos del operador y los modelos de terminal cambian sin avisar al equipo del cortafuegos. Da la revisión a una persona en lugar de a un nombre de equipo que sobrevivirá al equipo. Mantén la redacción lo bastante concreta para que un desconocido pueda derivar la regla solo con el registro.

Pon la excepción en el mismo ciclo que el resto de la política del borde, de modo que un operador que mueve un destino o una flota que cambia de modelo de terminal se note en la revisión y no en la próxima avería. Cierra el círculo con quien informó de las llamadas rotas, ya que es la única persona que puede confirmar la corrección sin reabrir el túnel que el bloqueo debía cerrar. Esa confirmación también pertenece al registro, con fecha.

Un permiso permanente etiquetado como arreglo temporal de teléfono es indefendible dos años después. Un permiso atado a un servicio identificado tiene una caducidad que se renueva a propósito.

Acota el origen con honestidad

Limitar la excepción a un segmento de dispositivos gestionados es materialmente más fuerte que abrir el protocolo a cada portátil del edificio. Si la red no puede identificar ese segmento, escríbelo en lugar de insinuar que la regla conoce los dispositivos. El resultado bueno más barato es reutilizar una frontera que ya existe por otra razón, de modo que la excepción herede un control en lugar de inventar uno. Filtrar por dirección no es autenticación de dispositivos, y el registro de cambio no debe sugerir lo contrario.

Una dirección de origen o una dirección de hardware no son prueba de un terminal físico. Que una u otra tengan significado depende por completo de los demás controles dentro de ese segmento. Si el argumento de la regla se apoya en una dirección MAC, comprueba qué impide al usuario cambiarla antes de que la regla salga.

Acepta lo que una regla de puertos no puede decirte

Los puertos identifican extremos de transporte, no intención de negocio. Cuando un servicio de llamadas aprobado y un túnel no aprobado viajan ambos por UDP 4500, ninguna regla basada en puertos los separa. Una regla que afirma hacerlo parece precisa y no lo es, lo que es peor que una regla que admite su propia forma. Es un límite del mecanismo, no un error de quien la escribió.

Dilo junto a la regla y empareja la excepción con la aplicación que la red tenga, como la gestión de dispositivos o una lista de destinos permitidos. Después expresa la excepción lo más estrechamente que permita la herramienta, por ejemplo con reglas nftables que nombran el segmento y el par de puertos y ponen la denegación general después:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables evalúa en orden y se detiene en la primera coincidencia, así que la aceptación acotada debe ir por encima de la denegación general. Invierte las dos y la excepción no hace nada en silencio.

Valida la función y la denegación

Ejecuta la validación aprobada en una llamada Wi-Fi corriente, desde la clase de dispositivo para la que existe la excepción, y confirma que un cliente excluido sigue fallando. Nunca uses llamadas de emergencia como caso de prueba bajo ninguna circunstancia. Después inspecciona la regla desplegada, porque un contador atascado en cero es la prueba más rápida de que la excepción nunca coincidió:

nft -a list chain inet edge forward

Incluye una reconexión o un cambio de red en la prueba, y repítela desde un arranque en frío con el teléfono uniéndose a la red en lugar de ya conectado. Si el contador se mueve mientras las llamadas siguen fallando, el problema ha salido del cortafuegos y pertenece a la lista de destinos del operador.