Bloccare IPsec senza rompere il Wi-Fi Calling del telefono

La richiesta arriva sempre con la stessa forma: chiudete IPsec sul bordo perché trasporta tunnel che nessuno ha approvato, e la prima lamentela viene da qualcuno il cui telefono ha smesso di telefonare via Wi-Fi. Entrambi i fatti sono veri insieme, e nessuno dei due giustifica l'abbandono del controllo. Ciò che serve al firewall è un'eccezione di servizio con una funzione nominata, una sorgente limitata, destinazioni documentate e un responsabile. Cinque passi la trasformano in una regola che un estraneo potrà rivedere l'anno prossimo.

Nominate il servizio prima di nominare il protocollo

Un telefono da scrivania su un servizio SIP e un apparecchio che esegue il Wi-Fi Calling dell'operatore non condividono un profilo di rete, e VoIP come termine di firewall non descrive nessuno dei due. I dati su porte e destinazioni devono venire dal fornitore o dall'operatore che gestisce il servizio, non da un elenco di porte ricordato appartenente a un altro sistema telefonico. È la differenza tra una regola che protegge una funzione e una regola che protegge una parola.

Il riferimento alle porte di servizio di Apple elenca UDP 500 e 4500 per il Wi-Fi Calling, che è esattamente la coppia che la maggior parte dei blocchi IPsec totali scarta. Scrivete il nome della funzione nel registro delle modifiche accanto a quelle porte. Aggiungete la versione o la data del riferimento usato, perché le tabelle dei fornitori vengono modificate. Una regola che nomina il servizio per cui esiste può essere rivista; una che nomina una categoria di protocollo no.

Scrivete l'eccezione come un contratto, non come un favore

L'eccezione dichiara la funzione consentita, le classi di dispositivo che la usano, il trasporto necessario e le destinazioni documentate dalla parte responsabile. Porta anche un responsabile e una data di revisione, perché gli endpoint dell'operatore e i modelli di apparecchio cambiano senza avvisare il team del firewall. Affidate la revisione a una persona invece che a un nome di team che sopravviverà al team. Mantenete la formulazione abbastanza specifica da permettere a un estraneo di ricavare la regola dal solo registro.

Mettete l'eccezione nello stesso ciclo del resto della politica di bordo, così che un operatore che sposta una destinazione o una flotta che cambia modello di apparecchio venga notato in revisione e non al guasto successivo. Chiudete il cerchio con chi ha segnalato le chiamate rotte, perché è l'unico che può confermare la correzione senza riaprire il tunnel che il blocco doveva chiudere. Anche quella conferma appartiene al registro, con una data.

Un permesso permanente etichettato come riparazione telefonica temporanea è indifendibile due anni dopo. Un permesso legato a un servizio identificato ha una scadenza che si rinnova di proposito.

Limitate la sorgente con onestà

Limitare l'eccezione a un segmento di dispositivi gestiti è materialmente più forte che aprire il protocollo a ogni portatile dell'edificio. Se la rete non riesce a identificare quel segmento, scrivetelo invece di lasciar intendere che la regola conosca i dispositivi. Il risultato buono più economico è riutilizzare un confine che esiste già per un'altra ragione, così l'eccezione eredita un controllo invece di inventarne uno. Filtrare per indirizzo non è autenticazione del dispositivo, e il registro delle modifiche non deve suggerire il contrario.

Un indirizzo di sorgente o un indirizzo hardware non è prova di un apparecchio fisico. Che l'uno o l'altro abbiano significato dipende interamente dagli altri controlli dentro quel segmento. Se l'argomento per la regola si basa su un indirizzo MAC, verificate cosa impedisce a un utente di cambiarlo prima che la regola venga rilasciata.

Accettate ciò che una regola di porte non può dirvi

Le porte identificano endpoint di trasporto, non intento commerciale. Quando un servizio di chiamata approvato e un tunnel non approvato viaggiano entrambi su UDP 4500, nessuna regola basata sulle porte li separa. Una regola che afferma di farlo sembra precisa e non lo è, il che è peggio di una regola che ammette la propria forma. È un limite del meccanismo, non un errore di chi l'ha scritta.

Ditelo accanto alla regola e abbinate l'eccezione a qualunque applicazione la rete abbia, come la gestione dei dispositivi o un elenco di destinazioni consentite. Poi esprimete l'eccezione il più strettamente consentito dallo strumento, per esempio con regole nftables che nominano il segmento e la coppia di porte e mettono il rifiuto generale dopo:

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 valuta in ordine e si ferma alla prima corrispondenza, quindi l'accettazione limitata deve stare sopra il rifiuto generale. Invertite le due e l'eccezione non fa nulla in silenzio.

Validate la funzione e il rifiuto

Eseguite la validazione approvata su una chiamata Wi-Fi ordinaria, dalla classe di dispositivo per cui esiste l'eccezione, e confermate che un client escluso fallisca ancora. Non usate mai le chiamate di emergenza come caso di prova, in nessuna circostanza. Poi ispezionate la regola rilasciata, perché un contatore fermo a zero è la prova più rapida che l'eccezione non ha mai corrisposto:

nft -a list chain inet edge forward

Includete una riconnessione o un cambio di rete nella prova, e ripetete la prova da un avvio a freddo con il telefono che si unisce alla rete invece di essere già collegato. Se il contatore si muove mentre le chiamate falliscono ancora, il problema ha lasciato il firewall e appartiene all'elenco delle destinazioni dell'operatore.