Blocco VPN PF su Mac: una politica di sede, non una funzione distribuibile

Funziona sul tuo Mac, quindi sembra qualcosa che puoi consegnare agli utenti. Questa supposizione è la prima cosa da perdere. Il TN3165 di Apple afferma chiaramente che Packet Filter non è un'API supportata per i prodotti distribuiti in generale, e presenta l'amministrazione di sede privilegiata e controllata come il caso ragionevole. Un blocco VPN costruito su PF è quindi una politica operativa locale con un proprietario, non una funzione che puoi distribuire dentro un'app.

PF non è una superficie di confezionamento

La distinzione non è accademica. Un prodotto distribuito che dipende da PF eredita ogni modifica che Apple vi apporta, ogni conflitto con un altro strumento che scrive anch'esso regole, e nessun impegno di supporto che l'assetto continui a funzionare. Una sede che amministra le proprie macchine ha un rapporto diverso: può documentare la dipendenza, testarla contro ogni versione del sistema operativo e accettare la manutenzione.

Alcuni consigli di installazione superano una linea che vale la pena nominare. Sovrascrivere l'intero set di regole di sistema per fare in modo che un solo ancoraggio si carichi, modificare la configurazione di avvio di sistema di Apple o disattivare System Integrity Protection non sono requisiti accettabili per una ricetta riutilizzabile. Se una guida pubblicata ha bisogno di una di queste cose, descrive un laboratorio, non una politica distribuibile.

Scrivete l'intenzione in uscita prima della sintassi

Decidete cosa è consentito prima di scegliere una sola parola chiave. Di solito devono esistere tre percorsi: il trasporto proprio del client VPN verso il suo server, il traffico dell'applicazione protetta dentro il tunnel e tutto ciò che la configurazione o i servizi locali richiedono davvero come percorso diretto.

Date a ogni eccezione proposta una destinazione, un trasporto e un proprietario. Consentire tutte le porte verso un endpoint permette molto più dell'unico trasporto usato dal tunnel, e l'esposizione aggiuntiva arriva senza che nessuno abbia deciso che dovesse esserci. Consentire un resolver pubblico è la stessa trappola in un travestimento più amichevole: crea un percorso DNS diretto anche mentre il tunnel è abbassato, quindi le ricerche dei nomi trapelano ancora.

Il test utile per un'eccezione è se riuscite a nominare la persona che l'ha richiesta e il guasto che evita. Se nessuna delle due risposte esiste, la regola è probabilmente un aggiramento per una configurazione errata che altrimenti resterebbe invisibile.

I numeri utun non sono un'identità

MacOS crea interfacce di tunnel come dispositivi utun, e il numero assegnato alla vostra VPN non è stabile tra riavvii, riconnessioni o la presenza di un altro client. Una regola che elenca diversi numeri ipotizzati non è una politica; è un'istantanea di un pomeriggio.

Ancorate la regola a qualcosa che identifichi il fornitore previsto: il piano di indirizzi assegnato dal tunnel, il processo che possiede l'interfaccia o una configurazione mantenuta dal client VPN stesso. Poi registrate come funziona quell'identificazione, perché chi rivedrà la regola tra un anno non avrà la vostra cronologia della shell.

Rendete attribuibile la politica caricata

Un nome di ancoraggio organizza le regole; non dimostra che la politica effettiva sia quella che intendevate. La precedenza tra ancoraggi, le regole caricate da altro software e lo stato esistente possono tutti cambiare l'esito. Rivedete l'insieme effettivo con chiunque altro possieda PF su quella macchina, e documentate la proprietà nello stesso posto della configurazione. Due proprietari che modificano ancoraggi diversi con ipotesi diverse sono il modo ordinario in cui un blocco sviluppa un buco.

Tenete il set di regole nel percorso di configurazione supportato della sede, versionatelo e annotate quali versioni di macOS sono state testate. Una modifica applicata a mano e ricordata da una sola persona non è infrastruttura mantenuta, qualunque cosa dica l'intestazione del file.

Testate le transizioni, non lo stato connesso

Uno screenshot scattato mentre il tunnel è attivo non dimostra quasi nulla. Percorrete invece gli stati: avvio prima di qualsiasi connessione, tunnel funzionante, tunnel che cade senza avviso, disconnessione deliberata e passaggio da Wi-Fi a hotspot. Ogni stato ha la propria risposta, e quelli interessanti sono i guasti, non il percorso felice.

In ogni stato, registrate ciò che è raggiungibile intenzionalmente. Controllate IPv4 e IPv6 separatamente, testate la risoluzione dei nomi e includete un flusso già stabilito prima della transizione, poiché le connessioni esistenti non seguono sempre la nuova politica. Un browser che si blocca mentre il tunnel è abbassato è un singolo punto dati, non la prova che ogni altro percorso sia bloccato.

Infine, mantenete un metodo di ripristino che non dipenda dal percorso di rete che state modificando. Una configurazione buona conosciuta su archiviazione locale e un modo documentato di caricarla trasformano un blocco in una politica; senza di esse, una cattiva revisione chiude l'amministratore fuori dalla macchina che doveva essere protetta.