Bloquear IPsec sem quebrar o Wi-Fi Calling do telemóvel

O pedido chega sempre com a mesma forma: fechem o IPsec na fronteira porque transporta túneis que ninguém aprovou, e a primeira queixa vem de alguém cujo telemóvel deixou de fazer chamadas por Wi-Fi. Ambos os factos são verdadeiros ao mesmo tempo, e nenhum deles justifica abandonar o controlo. O que a firewall precisa é de uma exceção de serviço com uma funcionalidade nomeada, uma origem limitada, destinos documentados e um responsável. Cinco passos transformam isso numa regra que um estranho poderá rever no próximo ano.

Nomeie o serviço antes de nomear o protocolo

Um telefone de secretária num serviço SIP e um terminal que faz o Wi-Fi Calling da operadora não partilham perfil de rede, e VoIP como termo de firewall não descreve nenhum deles. Os dados de portas e destinos devem vir do fornecedor ou da operadora que opera o serviço, não de uma lista de portas memorizada pertencente a outro sistema telefónico. É a diferença entre uma regra que protege uma funcionalidade e uma regra que protege uma palavra.

A referência de portas de serviço da Apple lista UDP 500 e 4500 para Wi-Fi Calling, que é exatamente o par que a maioria dos bloqueios totais de IPsec descarta. Escreva o nome da funcionalidade no registo de alterações junto dessas portas. Acrescente a versão ou a data da referência que usou, porque as tabelas dos fornecedores são editadas. Uma regra que nomeia o serviço para o qual existe pode ser revista; uma que nomeia uma categoria de protocolo, não.

Escreva a exceção como contrato, não como favor

A exceção declara a funcionalidade permitida, as classes de dispositivo que a usam, o transporte necessário e os destinos que a parte responsável documenta. Também tem um responsável e uma data de revisão, porque os pontos finais da operadora e os modelos de terminal mudam sem avisar a equipa da firewall. Dê a revisão a uma pessoa em vez de a um nome de equipa que sobreviverá à equipa. Mantenha a redação suficientemente concreta para que um estranho possa derivar a regra apenas a partir do registo.

Coloque a exceção no mesmo ciclo do resto da política de fronteira, para que uma operadora que move um destino ou uma frota que troca de modelo seja notada na revisão e não na próxima avaria. Feche o ciclo com quem comunicou as chamadas quebradas, porque é a única pessoa que pode confirmar a correção sem reabrir o túnel que o bloqueio devia fechar. Essa confirmação também pertence ao registo, com data.

Uma autorização permanente rotulada como reparação temporária de telefone é indefensável dois anos depois. Uma autorização ligada a um serviço identificado tem uma validade que se renova de propósito.

Delimite a origem com honestidade

Limitar a exceção a um segmento de dispositivos geridos é materialmente mais forte do que abrir o protocolo a cada portátil do edifício. Se a rede não consegue identificar esse segmento, escreva isso em vez de sugerir que a regra conhece os dispositivos. O resultado bom mais barato é reutilizar uma fronteira que já existe por outra razão, de modo que a exceção herde um controlo em vez de inventar um. Filtrar por endereço não é autenticação de dispositivo, e o registo de alterações não deve sugerir o contrário.

Um endereço de origem ou um endereço de hardware não é prova de um terminal físico. Se algum deles tem significado depende inteiramente dos outros controlos dentro desse segmento. Se o argumento da regra assenta num endereço MAC, verifique o que impede o utilizador de o alterar antes de a regra ser publicada.

Aceite o que uma regra de portas não lhe pode dizer

As portas identificam extremos de transporte, não intenção de negócio. Quando um serviço de chamadas aprovado e um túnel não aprovado viajam ambos por UDP 4500, nenhuma regra baseada em portas os separa. Uma regra que afirma fazê-lo parece precisa e não é, o que é pior do que uma regra que admite a sua própria forma. É um limite do mecanismo, não um erro de quem a escreveu.

Diga isso ao lado da regra e associe a exceção à aplicação que a rede tiver, como a gestão de dispositivos ou uma lista de destinos permitidos. Depois exprima a exceção o mais estreitamente que a ferramenta permitir, por exemplo com regras nftables que nomeiam o segmento e o par de portas e colocam a negação geral depois:

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 avalia por ordem e para na primeira correspondência, pelo que a aceitação delimitada tem de ficar acima da negação geral. Inverta as duas e a exceção não faz nada em silêncio.

Valide a funcionalidade e a negação

Execute a validação aprovada numa chamada Wi-Fi comum, a partir da classe de dispositivo para a qual a exceção existe, e confirme que um cliente excluído continua a falhar. Nunca utilize chamadas de emergência como caso de teste, em circunstância alguma. Depois inspecione a regra implementada, porque um contador parado em zero é a prova mais rápida de que a exceção nunca correspondeu:

nft -a list chain inet edge forward

Inclua uma reconexão ou uma mudança de rede no teste, e repita-o a partir de um arranque a frio com o telemóvel a entrar na rede em vez de já ligado. Se o contador se mover enquanto as chamadas continuam a falhar, o problema saiu da firewall e pertence à lista de destinos da operadora.