Indirizzi tunnel statici in pfSense: preferenza o prenotazione?

Due progetti sembrano simili sulla carta e si comportano in modo molto diverso quando una regola dipende da loro. Uno inserisce un indirizzo in un override client e si fida dell’indirizzo come identità. L’altro chiude del tutto l’ammissione dinamica, così un endpoint o ha un’assegnazione unica o non si connette. Solo il secondo trasforma un indirizzo in un dato di policy che puoi difendere, e la differenza vale la pena di essere capita prima di scrivere anche una sola regola del firewall.

Che cosa promette davvero un indirizzo di override

Un override specifico del client porta opzioni per client, tra cui un indirizzo tunnel preferito. Netgate descrive quell’indirizzo come una preferenza e non come una prenotazione, il che significa che il pool dinamico non rinuncia all’indirizzo per nessun altro.

Di solito va bene. Una collisione è rara e il client riceve normalmente ciò che ha chiesto, il che basta per la comodità e non per l’autorizzazione. Comodità e autorizzazione sono requisiti diversi, e solo uno dei due sopravvive a una collisione.

Con la topologia a subnet, il campo prende l’indirizzo del client insieme alla maschera della rete del server, così un indirizzo dentro un tunnel 10.90.0.0/24 si scrive come 10.90.0.10/24.

Niente di tutto ciò riserva il numero. Un client il cui override non corrisponde, o una sessione duplicata, può finire altrove nel pool, e una regola basata sull’indirizzo descrive allora qualcuno che non c’è.

Chiudere il percorso dinamico con un default circoscritto

L’alternativa è un server solo statico: ogni endpoint ammesso ha la propria identità e il proprio indirizzo univoco, e nulla altro entra.

Attuarlo significa un override DEFAULT circoscritto a quel solo server con il blocco delle connessioni attivo. Un client senza un override corrispondente non può quindi ricadere sull’ammissione dinamica ordinaria. È quella singola riga a convertire una preferenza in un insieme chiuso.

L’ambito conta. Un override predefinito applicato a ogni istanza VPN della macchina bloccherà tunnel non correlati, e quel guasto sembra un servizio rotto invece di una decisione di policy. Legalo all’unico server di cui stai cambiando il modello di ammissione. Poi annota l’ambito nel registro delle modifiche, perché la persona successiva non ricorderà a quale tunnel appartiene.

Controlla poi l’intero insieme consentito. Il blocco predefinito non corregge un override nominato rimasto senza indirizzo, e quell’endpoint semplicemente non riuscirà a connettersi senza un indizio evidente del perché.

Corrispondere all’identità che il server usa davvero

Un override corrisponde a qualcosa. Su un server che confronta i common name dei certificati, il nome dell’override deve essere quel common name, non il nome visualizzato della persona. Copialo dal certificato e non dall’elenco degli account.

Un server configurato per usare il nome utente come common name confronta su una chiave del tutto diversa, e un override intitolato al certificato non scatterà mai. Leggi l’impostazione invece di dedurla da ciò che mostra l’elenco degli account.

Mantieni i fattori di autenticazione aggiuntivi richiesti dalla distribuzione. Un modello di indirizzi chiuso cambia chi può connettersi e quale indirizzo riceve; non sostituisce il controllo del certificato né il secondo fattore.

Scrivere le regole di accesso dopo che la mappa è solida

Una volta chiusa la mappa identità-indirizzo, le regole possono fare riferimento agli indirizzi senza fingere che siano persone. Un alias che raggruppa gli endpoint di una persona può raggiungere un servizio specifico mentre un altro alias ne raggiunge un altro. L’alias diventa l’oggetto verificabile, e l’indirizzo diventa un dettaglio implementativo al suo interno.

Mantieni espliciti destinazioni e porte. Consentire l’intera rete locale dall’intero pool di tunnel è proprio il progetto che questo esercizio doveva sostituire.

Leggi le regole floating, di gruppo e di interfaccia nel loro ordine reale di valutazione, perché un passaggio ampio precedente annulla uno stretto successivo. Disattivare l’inoltro interno da client a client mantiene il traffico tra pari al confine dove quelle regole vengono esaminate. Una regola che esiste solo sulla carta non è applicazione.

Provare i casi negativi

Prova quattro connessioni nuove: un endpoint nominato, uno senza alcun override, un servizio che dovrebbe essere raggiungibile e uno che non dovrebbe. L’endpoint non elencato è il caso importante, perché è quello che il progetto esiste per fermare. Se si connette, il blocco predefinito non sta facendo il suo lavoro.

Controlla IPv6 separatamente, poiché una policy di indirizzi IPv4 non dice nulla su un secondo stack. Poi conferma che l’applicazione autorizzi ancora l’utente, perché un indirizzo tunnel è un fatto di rete e non una prova di chi è alla tastiera. Entrambi i controlli vanno nella nota di accettazione.

Infine, pianifica la migrazione. Nuovi override e regole strette non cambiano retroattivamente le sessioni già stabilite, quindi gli stati esistenti devono scadere o essere cancellati deliberatamente.