L’adattatore VPN di Windows deve essere privato o pubblico?
Decidete se un adattatore VPN di Windows appartiene al profilo privato con tre prove: percorso fidato, classificazione stabile e regole che vi servono davvero.
Impostare un adattatore VPN di Windows su Privato è giusto per un tunnel aziendale e sbagliato per un client VPN commerciale, e la differenza non è estetica. La categoria di rete seleziona un profilo del firewall, quindi una sola modifica ammette un intero set di regole in una volta. Ho visto uno script di accesso impostare ogni adattatore non identificato su Privato, cosa che ha esposto silenziosamente la condivisione file su una rete wireless d’albergo. Tre condizioni decidono la risposta, e tutte devono valere prima di toccare l’impostazione.
Che cosa decide davvero la categoria
Network Location Awareness costruisce una firma per ogni rete connessa da ciò che l’adattatore può riportare: l’indirizzo del gateway e il MAC, il suffisso DNS, se risponde un controller di dominio e se la rete raggiunge internet. Windows associa un profilo a quella firma, e il firewall applica poi il set di regole di quel profilo. Pubblico è il ripiego quando l’identificazione fallisce, perciò un tunnel funzionante può restare etichettato come rete non identificata.
Un adattatore TUN o TAP di solito dà all’identificazione pochissime informazioni. L’estremità del tunnel è spesso un solo indirizzo invece di un gateway, il DNS può essere spinto solo dentro il tunnel e l’adattatore non ha una propria route predefinita. L’etichetta risultante descrive l’input del firewall, non la salute del tunnel, ed è il motivo per cui le regole del profilo privato smettono di corrispondere nel momento in cui la VPN si connette.
Prima condizione: il tunnel è il percorso fidato
Scegliere Privato afferma che tutto ciò che è raggiungibile tramite questa interfaccia è almeno altrettanto affidabile della vostra LAN, perché il rilevamento e le regole in ingresso tratteranno quella sottorete come locale. Per un tunnel aziendale verso una sottorete gestita con file server e stampanti, l’affermazione di solito regge. L’adattatore è una porta verso una rete controllata dalla vostra organizzazione, e la macchina dall’altro lato è stata ammessa dalla stessa politica che ha ammesso la vostra.
Un’uscita VPN commerciale non supera questa prova. Altri abbonati condividono la sottorete di uscita, e marcarla come Privato mette il rilevamento di rete, LLMNR e la risoluzione dei nomi NetBIOS su un segmento pieno di estranei. Anche il tunnel diviso può fallire: quando l’adattatore porta un’unica route host verso un’applicazione, non c’è alcuna sottorete fidata di cui parlare, e il cambio di categoria non vi dà nulla.
Seconda condizione: la classificazione sopravvive alle riconnessioni
Un nuovo gateway o un nuovo suffisso DNS produce una nuova firma, e Windows prende una decisione di profilo nuova per quella. Un Set-NetConnectionProfile una tantum sopravvive quindi fino alla riconnessione successiva, non per sempre. Controllate il profilo dopo una riconnessione e non dopo la prima connessione, perché è allora che l’impostazione torna indietro da sola.
Ci sono tre modi per renderlo duraturo. Il più pulito è la politica: aprite secpol.msc, andate in Network List Manager Policies e impostate il tipo di posizione per la rete, inclusa la politica per le reti non identificate, così che il profilo sia applicato dalla politica e non da un comando. Il secondo è uno script per connessione o un’attività pianificata che esegue il cmdlet PowerShell quando il tunnel è attivo. Il terzo è il vecchio trucco della route, che dà all’identificazione un gateway da sondare:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileIl trucco della route è un aggiramento, non una classificazione. Si rompe quando cambia il rapporto fra le metriche o il client VPN riscrive le route alla riconnessione, e cambia silenziosamente la selezione del percorso per tutto ciò che ricade sulla seconda route predefinita.
Terza condizione: vi serve il set di regole privato
Privato di solito include la condivisione di file e stampanti, il rilevamento di rete e i gruppi di amministrazione remota. Se il compito è raggiungere una condivisione SMB o una stampante attraverso il tunnel, questa è la vera ragione per cambiare categoria. Se il compito è l’accesso in uscita a un’applicazione web, la categoria è irrilevante: scrivete la regola in uscita, tenete Pubblico e fermatevi lì.
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
Leggete la tabella come punto di partenza e poi verificate quali regole private sono effettivamente abilitate sulla vostra immagine. Un’immagine rafforzata può aver rimosso del tutto la condivisione file dal profilo privato, e in quel caso il cambio di categoria non ottiene nulla finché non rimettete la regola. Quel controllo costa un comando e fa risparmiare un lungo pomeriggio.
Fare la modifica senza allargare tutto il resto
Puntate all’indice dell’interfaccia, non a un carattere jolly, e leggete l’elenco prima e dopo:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileI profili memorizzati vivono sotto la chiave NetworkList del registro, dove il valore Category separa le reti pubbliche, private e di dominio. Modificarla è possibile ed è facile sbagliare: dovete cambiare la voce che corrisponde alla firma attuale dell’adattatore, non una voce più vecchia lasciata da un indirizzo precedente. Una voce obsoleta sembra corretta nell’editor e non fa nulla alla riconnessione.
Qualunque cosa facciate, non distribuite uno script che imposta ogni adattatore non identificato su Privato. È la versione da una riga di aprire il rilevamento su una rete wireless non affidabile. Se vi serve la condivisione solo con la sottorete del tunnel, tenete il profilo Pubblico e aggiungete regole in ingresso limitate all’intervallo di indirizzi remoti del tunnel; la regola del firewall è più stretta della categoria.
Verificate la condivisione, non l’etichetta
Dopo la modifica, provate la risorsa stessa invece di fidarvi dell’etichetta:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleSe la condivisione continua a fallire mentre l’adattatore mostra Privato, la categoria non è più il vostro problema. La risoluzione dei nomi, una route mancante o i permessi di condivisione produrranno lo stesso sintomo, e un altro cambio di profilo non può ripararne nessuno. Riconnettetevi una volta e rieseguite Get-NetConnectionProfile per confermare che l’impostazione abbia tenuto, poi affrontate il guasto residuo come un normale problema SMB.
Lista di controllo: confermate che il tunnel sia un percorso gestito, che il profilo sopravviva a una riconnessione, che le regole private necessarie esistano sull’immagine e che la condivisione si risolva e risponda sulla porta 445. Se una delle prime tre è falsa, lasciate l’adattatore su Pubblico e risolvete il problema di accesso con una regola limitata.