Bloquear IPsec sen romper o Wi-Fi Calling do teléfono

A petición chega sempre coa mesma forma: pecha IPsec no bordo porque transporta túneles que ninguén aprobou, e a primeira queixa vén de alguén cuxo teléfono deixou de facer chamadas por Wi-Fi. Ambos os feitos son certos á vez, e ningún xustifica abandonar o control. O que necesita a devasa é unha excepción de servizo cunha función nomeada, unha orixe limitada, destinos documentados e un responsable. Cinco pasos convértena nunha regra que un descoñecido poderá revisar o ano que vén.

Nomea o servizo antes de nomear o protocolo

Un teléfono de escritorio nun servizo SIP e un terminal que fai o Wi-Fi Calling do operador non comparten perfil de rede, e VoIP como termo de devasa non describe ningún dos dous. Os datos de portos e destinos deben vir do provedor ou do operador que presta o servizo, non dunha lista de portos recordada doutro sistema telefónico. Esa é a diferenza entre unha regra que protexe unha función e unha regra que protexe unha palabra.

A referencia de portos de servizo de Apple enumera UDP 500 e 4500 para Wi-Fi Calling, que resulta ser xusto o par que descartan a maioría dos bloqueos totais de IPsec. Escribe o nome da función no rexistro de cambio xunto a eses portos. Engade a versión ou a data da referencia que usaches, porque as táboas dos provedores edítanse. Unha regra que nomea o servizo para o que existe pódese revisar; unha que nomea unha categoría de protocolo, non.

Escribe a excepción como contrato, non como favor

A excepción declara a función permitida, as clases de dispositivo que a usan, o transporte que necesita e os destinos que documenta a parte responsable. Tamén leva un responsable e unha data de revisión, porque os extremos do operador e os modelos de terminal cambian sen avisar ao equipo da devasa. Dá a revisión a unha persoa en lugar dun nome de equipo que sobrevivirá ao equipo. Mantén a redacción o bastante concreta para que un descoñecido poida derivar a regra só co rexistro.

Pon a excepción no mesmo ciclo que o resto da política do bordo, de modo que un operador que move un destino ou unha frota que cambia de modelo de terminal se note na revisión e non na próxima avaría. Pecha o círculo con quen informou das chamadas rotas, xa que é a única persoa que pode confirmar a corrección sen reabrir o túnel que o bloqueo debía pechar. Esa confirmación tamén pertence ao rexistro, con data.

Un permiso permanente etiquetado como arranxo temporal de teléfono é indefendible dous anos despois. Un permiso ligado a un servizo identificado ten unha caducidade que se renova a propósito.

Limita a orixe con honestidade

Limitar a excepción a un segmento de dispositivos xestionados é materialmente máis forte que abrir o protocolo a cada portátil do edificio. Se a rede non pode identificar ese segmento, escríbeo en lugar de insinuar que a regra coñece os dispositivos. O resultado bo máis barato é reutilizar unha fronteira que xa existe por outra razón, de modo que a excepción herde un control en lugar de inventar un. Filtrar por enderezo non é autenticación de dispositivos, e o rexistro de cambio non debe suxerir o contrario.

Un enderezo de orixe ou un enderezo de hardware non son proba dun terminal físico. Que un ou outro teñan significado depende por completo dos demais controis dentro dese segmento. Se o argumento da regra se apoia nun enderezo MAC, comproba que impide ao usuario cambialo antes de que a regra saia.

Acepta o que unha regra de portos non pode dicirche

Os portos identifican extremos de transporte, non intención de negocio. Cando un servizo de chamadas aprobado e un túnel non aprobado viaxan ambos por UDP 4500, ningunha regra baseada en portos os separa. Unha regra que afirma facelo parece precisa e non o é, o que é peor que unha regra que admite a súa propia forma. É un límite do mecanismo, non un erro de quen a escribiu.

Dio xunto á regra e emparella a excepción coa aplicación que a rede teña, como a xestión de dispositivos ou unha lista de destinos permitidos. Despois expresa a excepción o máis estreitamente que permita a ferramenta, por exemplo con regras nftables que nomean o segmento e o par de portos e poñen a denegación xeral despois:

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 avalía en orde e detense na primeira coincidencia, así que a aceptación limitada debe ir por riba da denegación xeral. Inverte as dúas e a excepción non fai nada en silencio.

Valida a función e a denegación

Executa a validación aprobada nunha chamada Wi-Fi corrente, desde a clase de dispositivo para a que existe a excepción, e confirma que un cliente excluído segue fallando. Nunca empregues chamadas de emerxencia como caso de proba baixo ningunha circunstancia. Despois inspecciona a regra despregada, porque un contador atascado en cero é a proba máis rápida de que a excepción nunca coincidiu:

nft -a list chain inet edge forward

Inclúe unha reconexión ou un cambio de rede na proba, e repítea desde un arranque en frío co teléfono uníndose á rede en lugar de xa conectado. Se o contador se move mentres as chamadas seguen fallando, o problema saíu da devasa e pertence á lista de destinos do operador.