Por que o adaptador VPN queda no perfil público da devasa

O túnel está activo, a conta autenticouse no dominio e Windows segue etiquetando a conexión como pública. Por tanto, unha regra de devasa escrita para o perfil de dominio non se aplica e o recurso compartido segue inaccesible. O intento habitual de arranxo é poñer o adaptador en privado, o que cambia que regras se aplican sen cambiar nada da autenticación. Tanto a etiqueta como o arranxo malinterprétanse amplamente, e separalos esixe tres comandos.

A conta que se conectou non é a categoría da rede

Durante unha conexión VPN tómanse dúas decisións distintas e é fácil confundilas. A pasarela decide se a conta pode conectarse. Windows decide como clasificar a rede resultante, e esa clasificación determina que regras de devasa se aplican á interface.

Unha autenticación de dominio correcta na pasarela é unha proba sobre a conta. Non é unha proba de que o extremo autenticase a rede contra un controlador de dominio, que é o que representa realmente a categoría de dominio.

Por iso unha máquina pode estar unida a un dominio, conectarse cunha conta de dominio e mostrar igualmente Público. A clasificación é unha determinación local sobre a rede, non unha afirmación sobre as credenciais que abriron o túnel. A conta pode ser perfectamente válida mentres a etiqueta queda onde comezou.

Tres categorías, unha das cales non pode asignar

Windows expón tres categorías e só dúas poden asignarse por un administrador. A terceira decídea o sistema operativo despois de autenticar con éxito a rede contra un controlador de dominio.

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

O terceiro comando falla, e este é o comportamento documentado, non un problema de permisos. A referencia do propio cmdlet indica que a categoría de dominio non se pode asignar deste xeito, porque Windows a deriva da autenticación de dominio. Ver o erro é unha confirmación útil de que a categoría é unha consecuencia e non un axuste.

Lea o primeiro comando no extremo cuxo tráfico está bloqueado. A clasificación da interface da propia pasarela non di nada sobre como clasificou cada estación de traballo o seu túnel.

As regras seguen o perfil para o que se escribiron

Unha vez coñece a categoría, o acceso que falta adoita explicarse só. Cada regra da devasa de Windows leva un ámbito de perfil, e unha regra limitada ao dominio non se aplica cando a interface é pública. Tres comandos converten iso nunha resposta e non nunha teoría, e o terceiro atrapa o caso no que o perfil nunca foi o problema:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

O segundo comando é o que converte un informe vago nunha solución. Se a regra está limitada a un rango de enderezos remotos que non inclúe o grupo de VPN, cambiar o perfil tampouco axudará.

Comprobe tamén a acción de entrada predeterminada. Nunha máquina onde a entrada está bloqueada por defecto, unha regra de permiso ausente produce silencio en lugar dun rexeitamento. Desde o lado do cliente iso parece idéntico a un fallo de encamiñamento, e por iso tantos destes tickets comezan coa suposición equivocada.

Determine que máquina aplica a regra

Antes de cambiar unha categoría, estableza onde se produce o bloqueo. O servidor que aloxa o recurso compartido pode ter a súa propia devasa, e as súas regras aplícanse ao tráfico que chega do grupo de VPN independentemente de como o cliente etiquetase o seu adaptador. Un rexeitamento alí é invisible para calquera comando local que execute, e o lado do cliente só informa de que o recurso non está dispoñible. Probe as regras propias do destino antes de tocar a clasificación do cliente.

Probe desde o cliente ao porto concreto e logo compare cunha proba desde outro equipo na mesma VPN. Se fallan ambas, o problema está no destino ou na ruta. Se só falla unha, a diferenza é local desa máquina e a categoría do perfil pasa a ser unha causa plausible.

Teña en conta tamén a dirección. Unha regra que permite SMB de entrada non fai nada por un cliente cuxa propia regra de saída bloquea o mesmo tráfico. Desde unha xanela do explorador de ficheiros os dous fallos son indistinguibles, así que probe cada dirección por separado antes de editar nada.

Que facer en lugar de reetiquetar todo

Facer privada unha rede non identificada para satisfacer unha regra ampla é un cambio real con consecuencias reais. O perfil privado normalmente permite máis descubrimento e máis tráfico de entrada que o público.

Se o obxectivo é que un servizo concreto chegue aos clientes VPN, limite a regra por enderezo remoto en lugar de por perfil. Iso expresa a intención con precisión, funciona independentemente da clasificación e non depende de que Windows acerte cun adaptador virtual. Tamén sobrevive a unha actualización do cliente que reclasifique a interface. Escriba o grupo na regra e a seguinte persoa poderá ler a intención sen preguntar.

Se a categoría de dominio se espera de verdade e nunca aparece, iso é unha investigación aparte. Comprobe que a máquina estea unida ao dominio, que poida chegar a un controlador de dominio polo túnel e que a canle segura estea san. Esas tres ordes respóndeno sen unha soa edición do rexistro:

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

Esas tres responden se o extremo podía autenticar a rede. Se non pode chegar a un controlador, a categoría de dominio nunca se asignará, por moitas veces que se reinicie o adaptador. A regra de devasa que perseguía nunca foi o problema real, e a etiqueta era un síntoma dun camiño roto, non unha causa.