Bloquejar IPsec sense trencar el Wi-Fi Calling del telèfon

La sol·licitud sempre arriba amb la mateixa forma: tanqueu IPsec a la vora perquè transporta túnels que ningú no ha aprovat, i la primera queixa ve d'algú a qui el telèfon ha deixat de fer trucades per Wi-Fi. Els dos fets són certs alhora, i cap dels dos no justifica abandonar el control. El que necessita el tallafoc és una excepció de servei amb una funció anomenada, un origen limitat, destinacions documentades i un responsable. Cinc passos ho converteixen en una regla que un desconegut podrà revisar l'any vinent.

Anomeneu el servei abans d'anomenar el protocol

Un telèfon d'escriptori en un servei SIP i un aparell mòbil que fa Wi-Fi Calling de l'operador no comparteixen perfil de xarxa, i VoIP com a terme de tallafoc no descriu cap dels dos. Les dades de ports i destinacions han de venir del proveïdor o de l'operador que presta el servei, no d'una llista de ports recordada d'un altre sistema telefònic. Aquesta és la diferència entre una regla que protegeix una funció i una regla que protegeix una paraula.

La referència de ports de servei d'Apple llista UDP 500 i 4500 per a Wi-Fi Calling, que resulta ser exactament la parella que la majoria de bloqueigs totals d'IPsec descarten. Escriviu el nom de la funció al registre de canvi al costat d'aquests ports. Afegiu la versió o la data de la referència que heu fet servir, perquè les taules dels proveïdors s'editen. Una regla que anomena el servei per al qual existeix es pot revisar; una que anomena una categoria de protocol, no.

Escriviu l'excepció com un contracte, no com un favor

L'excepció declara la funció permesa, les classes de dispositiu que la fan servir, el transport que necessita i les destinacions que documenta la part responsable. També porta un responsable i una data de revisió, perquè els extrems de l'operador i els models d'aparell canvien sense avisar l'equip del tallafoc. Doneu la revisió a una persona en lloc d'un nom d'equip que sobreviurà a l'equip. Manteniu la redacció prou específica perquè un desconegut pugui derivar la regla només amb el registre.

Poseu l'excepció en el mateix cicle que la resta de la política de la vora, de manera que un operador que mou una destinació o una flota que canvia de model d'aparell es noti a la revisió i no a la propera avaria. Tanqueu el cercle amb qui va informar de les trucades trencades, ja que és l'única persona que pot confirmar la solució sense reobrir el túnel que el bloqueig havia de tancar. Aquesta confirmació també pertany al registre, amb data.

Un permís permanent etiquetat com a arreglo temporal de telèfon és indefensable dos anys després. Un permís lligat a un servei identificat té una caducitat que es renova a propòsit.

Delimiteu l'origen amb honestedat

Limitar l'excepció a un segment de dispositius gestionats és substancialment més fort que obrir el protocol a cada portàtil de l'edifici. Si la xarxa no pot identificar aquest segment, escriviu-ho en lloc d'insinuar que la regla té en compte els dispositius. El resultat bo més barat és reutilitzar una frontera que ja existeix per una altra raó, de manera que l'excepció hereta un control en lloc d'inventar-ne un. Filtrar per adreça no és autenticació de dispositius, i el registre de canvi no ha de suggerir el contrari.

Una adreça d'origen o una adreça de maquinari no són prova d'un aparell físic. Que una o l'altra tinguin significat depèn del tot dels altres controls dins d'aquell segment. Si l'argument de la regla descansa en una adreça MAC, comproveu què impedeix a l'usuari canviar-la abans que la regla surti.

Accepteu què no us pot dir una regla de ports

Els ports identifiquen extrems de transport, no intenció de negoci. Quan un servei de trucades aprovat i un túnel no aprovat viatgen tots dos per UDP 4500, cap regla basada en ports no els separa. Una regla que afirma que ho fa sembla precisa i no ho és, cosa pitjor que una regla que admet la seva pròpia forma. Això és un límit del mecanisme, no un error de qui la va escriure.

Digueu-ho al costat de la regla i acompanyeu l'excepció amb l'aplicació que la xarxa tingui, com ara la gestió de dispositius o una llista de destinacions permeses. Després exposeu l'excepció tan estretament com permeti l'eina, per exemple amb regles nftables que anomenen el segment i la parella de ports i posen la denegació general despré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 avalua en ordre i s'atura a la primera coincidència, així que l'acceptació limitada ha d'anar per sobre de la denegació general. Invertiu-les i l'excepció no fa res en silenci.

Valideu la funció i la denegació

Executeu la validació aprovada en una trucada Wi-Fi corrent, des de la classe de dispositiu per a la qual existeix l'excepció, i confirmeu que un client exclòs encara falla. No feu servir mai trucades d'emergència com a cas de prova, sota cap circumstància. Després inspeccioneu la regla que s'ha desplegat, perquè un comptador encallat a zero és la prova més ràpida que l'excepció no ha coincidit mai:

nft -a list chain inet edge forward

Incloeu una reconnexió o un canvi de xarxa a la prova, i repetiu-la des d'un inici fred amb el telèfon unint-se a la xarxa en lloc d'estar ja connectat. Si el comptador es mou mentre les trucades continuen fallant, el problema ha sortit del tallafoc i pertoca a la llista de destinacions de l'operador.