Perché un gate del firewall legato allo stato della VPN non è una regola di ping solo dal tunnel

Immaginate una regola del firewall che attiva ICMP echo per l'indirizzo pubblico del server ogni volta che un profilo VPN denominato è connesso. Si legge come «ping solo attraverso il tunnel», e questa lettura è sbagliata in un modo che conta. La regola non limita chi può raggiungere l'host; cambia ciò a cui risponde l'interfaccia pubblica mentre un'altra connessione è attiva. Sono due politiche diverse, e una di esse allarga silenziosamente l'esposizione.

La regola che credete di aver scritto

Il requisito previsto è di solito ristretto: il sistema di monitoraggio, o l'unico amministratore sulla VPN, deve poter confermare che il server è vivo. Scritto come frase, suona come un controllo degli accessi sul tunnel. Scritto come oggetto del firewall, diventa una condizione sul profilo pubblico, perché è lì che arriva la richiesta echo.

Una volta che la condizione è uno stato di connessione e non un indirizzo di origine, l'insieme dei mittenti consentiti non è più l'insieme dei peer della VPN. Chiunque possa raggiungere l'indirizzo pubblico può inviare una richiesta echo mentre il gate è aperto. Il tunnel non è diventato il percorso; il tunnel è diventato l'interruttore.

Chi promuove questa idea di solito non mente sull'effetto che voleva. Serviva un controllo che rispondesse solo quando il collegamento è sano, e la salute del collegamento era più facile da osservare tramite la VPN. L'errore è trattare un segnale di disponibilità come una decisione di accesso, e poi automatizzarlo.

Cosa controlla davvero il gate

Questo progetto fonde due cose indipendenti, e separarle è la maggior parte della correzione. La prima è l'ambito: quale indirizzo locale, quali indirizzi remoti, quale protocollo e quale tipo ICMP. La seconda è la condizione: se l'oggetto della regola è abilitato in questo momento. L'ambito è ciò che un firewall valuta per pacchetto; la condizione è ciò che uno script scrive nell'archivio dei criteri, e i due si riconciliano su orologi del tutto diversi.

Se il requisito è davvero solo i peer della VPN, l'ambito lo soddisfa senza alcuna logica di stato della connessione: legate la regola all'interfaccia del tunnel o all'intervallo di indirizzi del tunnel, limitate gli indirizzi remoti al pool dei client e specificate il tipo echo invece di «ICMP». Quella regola resta corretta quando nessuna VPN è attiva e non può essere aperta da un profilo estraneo.

Se il requisito è davvero un gate pubblico, ditelo nel testo della politica, perché i criteri di accettazione cambiano. Un gate pubblico deve nominare il profilo esatto, definire cosa significa «connesso» e dichiarare che i mittenti pubblici rientrano nell'ambito per progetto. La maggior parte della confusione svanisce nel momento in cui qualcuno è costretto a scrivere quella frase.

Costruite l'oggetto una volta, poi commutatelo

Predisponete in anticipo un'unica regola con un'identità stabile, disabilitata, e lasciate che il controller ne cambi solo lo stato di abilitazione. Creare regole per nome visualizzato a ogni esecuzione è il modo in cui un archivio di criteri finisce con cinque oggetti quasi identici e senza un modo affidabile di rimuoverli.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Il nome è l'identificatore durevole; il nome visualizzato è documentazione che una persona può modificare. Riconciliate su -Name e lo script smette di produrre duplicati. La stessa forma di comando copre il caso IPv6 con -Protocol ICMPv6 -IcmpType 128, ma è una regola separata perché i numeri del tipo echo differiscono tra le due famiglie.

Mantenete espliciti la famiglia di indirizzi e il tipo ICMP per una seconda ragione: -Protocol ICMPv4 senza un tipo consente ogni messaggio ICMPv4 che il profilo ammette, compresi quelli che non avete mai intenzione di accettare. Nominare il tipo 8 restringe la regola alla richiesta echo, e questo è l'unico che un controllo di raggiungibilità invia.

Dove l'automazione contraddice l'intento

Interrogare un profilo client ogni pochi minuti non può produrre un confine immediato. Tra la caduta della connessione e l'interrogazione successiva la regola risponde ancora sull'indirizzo pubblico; tra la salita della connessione e l'interrogazione successiva non risponde. Ammettere quel ritardo è onesto, affermare che il progetto impone un invariante rigido non lo è.

C'è una trappola di ambito nel controllo di stato stesso. Get-VpnConnection segnala i profili client configurati sulla macchina, per impostazione predefinita per l'utente corrente e per tutti gli utenti con -AllUserConnection. Non segnala gli utenti remoti attualmente collegati a un server RRAS; quella è un'altra osservazione con un altro comando. Un gate costruito su quello sbagliato non è connesso a nulla.

Poi coprite gli stati che nessuno scrive negli script: avvio con la regola già abilitata da un'esecuzione precedente, crash del controller mentre il gate è aperto e profilo eliminato mentre la sua regola resta viva. Ognuno richiede un valore predefinito definito, e il valore sicuro per un permesso pubblico è disabilitato. Se il requisito non tollera davvero la finestra di interrogazione, una regola legata allo stato è lo strumento sbagliato e l'applicazione appartiene al tunnel, non all'interfaccia pubblica.

Infine, provate la richiesta pubblica due volte, una con la connessione scelta attiva e una con essa caduta, da un host che non è sulla VPN. Un ping riuscito dall'interno del tunnel non dimostra nulla su questa politica, ed è la misura che la maggior parte delle implementazioni salta.