Clients VPN bloquejats pel perfil Públic del tallafoc de Windows

El vostre túnel està actiu, la passarel·la respon al ping i el recurs compartit continua esgotant el temps d'espera. Aquesta combinació poques vegades és un problema d'encaminament: Windows ha posat la subxarxa de l'adaptador VPN al perfil Públic, i cada regla de permís escrita per a Privat o Domini no s'ha aplicat mai. M'he trobat amb això en portàtils que arriben a l'oficina sense problemes i en servidors RRAS que atenen tots els altres clients, i la reparació és curta un cop identifiqueu el perfil en joc. Aquí teniu l'ordre en què treballo, amb la comprovació que us diu quan aturar-vos abans del pas següent.

Esbrineu per quin perfil arriba realment el trànsit

El tallafoc de Windows no té un únic mode global. Cada interfície connectada porta una categoria, i els paquets entrants es filtren segons la categoria de la interfície per la qual arriben, així que és el perfil de l'adaptador VPN qui decideix què pot assolir un client en túnel, no l'adaptador Wi-Fi o Ethernet del costat. Llegiu tots dos fets abans de canviar res:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

En una instal·lació estàndard d'OpenVPN o WireGuard, l'adaptador VPN apareix com una xarxa no identificada i cau a Públic, el valor predeterminat per a qualsevol xarxa que Windows no pugui classificar: cap controlador de domini no hi ha respost i cap perfil de passarel·la no ha coincidit. El nom de la interfície és irrellevant aquí, així que anomenar l'adaptador «VPN» o «Corp» no canvia res. DomainAuthenticated requereix una màquina unida al domini , que pugui assolir realment un controlador de domini per aquesta interfície; un túnel dividit que només transporti una subxarxa no complirà el requisit.

Si la regla que necessiteu ja està limitada a la piscina de VPN i ja s'aplica a la categoria que acabeu de llegir, atureu-vos aquí: el filtratge no és la vostra capa, i el següent lloc on mirar és la configuració del servei. Aquesta comprovació triga deu segons i estalvia una hora d'edició de regles. Els noms de les categories i què cobreix cadascuna estan documentats a la referència de Get-NetConnectionProfile.

Confirmeu el filtratge, no l'encaminament, abans d'editar regles

El ping és una prova feble. ICMP pot passar mentre es descarta el port del servei, i un amfitrió pot respondre des de la LAN mentre rebutja la mateixa petició pel túnel. Proveu el port que necessita el client, des del client:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Si la prova del port falla, separeu les dues capes. Una fallada de túnel o de ruta sol aparèixer com cap resposta de l'adreça de passarel·la, mentre que un descart del tallafoc mostra una passarel·la que respon i un port de servei que no respon. En un servidor Windows que publica la piscina mitjançant RRAS, executeu la mateixa prova des d'un client i llegiu el perfil del propi servidor: la interfície RAS pot estar en una categoria les regles d'entrada de la qual no esmenten mai el rang de clients, i per això l'equip atén la seva LAN i rebutja tots els clients en túnel.

Quan el resultat encara és ambigu, registreu els descarts del perfil en joc i llegiu-los:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Les entrades que anomenen l'adreça i el port del client amb DROP són concloents, i també us diuen quina regla faltava. Un registre buit mentre el SYN del client no apareix mai apunta aigües amunt de l'amfitrió, així que torneu al túnel, a la regla NAT o a la ruta de la piscina abans de tocar cap altre objecte del tallafoc.

Limiteu una regla d'entrada a la piscina de clients

La reparació és una única regla de permís d'entrada l'adreça remota de la qual és la piscina, no el món sencer. Des d'una sessió elevada:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Quan el servei és un sol binari, preferiu una regla limitada al programa amb -Program en lloc d'una llista de ports; això limita l'excepció tant al procés com al rang d'origen.

L'elecció del perfil és on es comet el mateix error en la direcció oposada. -Profile Public és suficient quan l'adaptador és Públic i continua Públic. -Profile Any és defensable quan el servei ha de funcionar independentment de com Windows classifiqui l'adaptador, però només mentre es mantingui l'àmbit remot. El que mai és defensable és -RemoteAddress Any al perfil Públic: aquesta regla segueix el portàtil a cada xarxa de cafè i hotel a la qual es connecta i obre el port a qui comparteixi aquesta subxarxa.

Anoteu la piscina al costat de la regla. -RemoteAddress 10.8.0.0/24 deixa de coincidir silenciosament el dia que es renumeri la piscina de VPN, i la fallada sembla exactament l'error original, i per això costa una segona tarda. Anomeneu les regles pel servei i el rang d'origen, manteniu-les juntes amb -Group, i rellegiu-les sempre que canviï la definició de la piscina. Un inventari de regles que podeu auditar en una sola pantalla supera una regla correcta que ningú no troba.

Canvieu la categoria només quan la categoria sigui la decisió

Canviar la interfície a Privat també funciona, i és el valor predeterminat equivocat. El perfil Privat porta una llarga llista de regles de permís integrades, que cobreixen compartició de fitxers i impressores, descobriment de xarxa, escriptori remot i més segons la línia base, així que reclasificar l'adaptador VPN les habilita totes alhora per a cada client del túnel. Una regla limitada atorga un servei a un rang. En un portàtil que també es connecta a xarxes no fiables, aquesta diferència no és cosmètica.

Hi ha casos en què la classificació és realment errònia: un túnel sempre actiu o de lloc a lloc que transporta una subxarxa d'oficina és infraestructura de confiança, i marcar aquest adaptador com a Privat és una decisió de disseny legítima, presa una vegada per política i no per tiquet. Quan ho feu, feu-ho explícitament:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

En un dispositiu gestionat, comproveu primer si una Directiva de grup o una línia base MDM posseeix la configuració. Si la posseeix, el canvi local es desfà a la propera actualització i gpresult /h nomenarà la directiva que la posseeix; corregiu-ho allà, no al punt final.

Verifiqueu des de tots dos extrems i deixeu rastre

Verifiqueu el flux que va informar l'usuari, des del client, després del canvi:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Després tanqueu el bucle en les coses que es trencaran la setmana que ve. Reinicieu l'amfitrió i torneu a provar, perquè una regla limitada al perfil equivocat continua funcionant fins que l'adaptador torna en una altra categoria. Proveu des d'un segon client, ja que un client amb una concessió obsoleta pot amagar una discrepància de la piscina. Compteu les regles que heu afegit davant les que heu eliminat, perquè les excepcions solapades són la manera com una correcció de dues línies es converteix en una política de filtratge que ningú no pot revisar.

Abans de donar-ho per acabat:

• El perfil anomenat a la regla és el perfil de la interfície per la qual arriba el trànsit.
• L'àmbit remot és la piscina de VPN, i aquesta piscina coincideix amb el que el servidor lliura realment.
• Cap regla que hàgiu afegit no fa servir -RemoteAddress Any al perfil Públic.
• No s'ha desactivat res per fer passar la prova, i qualsevol canvi de categoria registra qui l'ha aprovat.