Por qué el adaptador VPN se queda en el perfil público del firewall

El túnel está activo, la cuenta se ha autenticado en el dominio y Windows sigue etiquetando la conexión como pública. Por tanto, una regla de firewall escrita para el perfil de dominio no se aplica y el recurso compartido sigue inaccesible. El intento habitual de arreglo es poner el adaptador en privado, lo que cambia qué reglas se aplican sin cambiar nada de la autenticación. Tanto la etiqueta como el arreglo se malinterpretan ampliamente, y separarlos exige tres comandos.

La cuenta que se ha conectado no es la categoría de la red

Durante una conexión VPN se toman dos decisiones distintas y es fácil confundirlas. La puerta de enlace decide si la cuenta puede conectarse. Windows decide cómo clasificar la red resultante, y esa clasificación determina qué reglas de firewall se aplican a la interfaz.

Una autenticación de dominio correcta en la puerta de enlace es una prueba sobre la cuenta. No es una prueba de que el extremo haya autenticado la red contra un controlador de dominio, que es lo que representa realmente la categoría de dominio.

Por eso una máquina puede estar unida a un dominio, conectarse con una cuenta de dominio y mostrar igualmente Público. La clasificación es una determinación local sobre la red, no una afirmación sobre las credenciales que abrieron el túnel. La cuenta puede ser perfectamente válida mientras la etiqueta se queda donde empezó.

Tres categorías, una de las cuales no puede asignar

Windows expone tres categorías y solo dos pueden asignarse por un administrador. La tercera la decide el sistema operativo después de autenticar con éxito la red 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

El tercer comando falla, y este es el comportamiento documentado, no un problema de permisos. La referencia del propio cmdlet indica que la categoría de dominio no puede asignarse de esta forma, porque Windows la deriva de la autenticación de dominio. Ver el error es una confirmación útil de que la categoría es una consecuencia y no un ajuste.

Lea el primer comando en el extremo cuyo tráfico está bloqueado. La clasificación de la interfaz de la propia puerta de enlace no dice nada sobre cómo ha clasificado cada estación de trabajo su túnel.

Las reglas siguen el perfil para el que se escribieron

Una vez conoce la categoría, el acceso que falta suele explicarse solo. Cada regla del firewall de Windows lleva un ámbito de perfil, y una regla limitada al dominio no se aplica cuando la interfaz es pública. Tres comandos convierten eso en una respuesta y no en una teoría, y el tercero atrapa el caso en el que el perfil nunca fue el problema:

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

El segundo comando es el que convierte un informe vago en una solución. Si la regla está limitada a un rango de direcciones remotas que no incluye el grupo de VPN, cambiar el perfil tampoco ayudará.

Compruebe también la acción de entrada predeterminada. En una máquina donde la entrada está bloqueada por defecto, una regla de permiso ausente produce silencio en lugar de un rechazo. Desde el lado del cliente eso parece idéntico a un fallo de enrutamiento, y por eso tantos de estos tickets empiezan con la suposición equivocada.

Determine qué máquina aplica la regla

Antes de cambiar una categoría, establezca dónde se produce el bloqueo. El servidor que aloja el recurso compartido puede tener su propio firewall, y sus reglas se aplican al tráfico que llega del grupo de VPN independientemente de cómo el cliente haya etiquetado su adaptador. Un rechazo allí es invisible para cualquier comando local que ejecute, y el lado del cliente solo informa de que el recurso no está disponible. Pruebe las reglas propias del destino antes de tocar la clasificación del cliente.

Pruebe desde el cliente al puerto concreto y luego compare con una prueba desde otro equipo en la misma VPN. Si fallan ambas, el problema está en el destino o en la ruta. Si solo falla una, la diferencia es local de esa máquina y la categoría del perfil pasa a ser una causa plausible.

Tenga en cuenta también la dirección. Una regla que permite SMB de entrada no hace nada por un cliente cuya propia regla de salida bloquea el mismo tráfico. Desde una ventana del explorador de archivos los dos fallos son indistinguibles, así que pruebe cada dirección por separado antes de editar nada.

Qué hacer en lugar de reetiquetarlo todo

Hacer privada una red no identificada para satisfacer una regla amplia es un cambio real con consecuencias reales. El perfil privado normalmente permite más descubrimiento y más tráfico de entrada que el público.

Si el objetivo es que un servicio concreto llegue a los clientes VPN, limite la regla por dirección remota en lugar de por perfil. Eso expresa la intención con precisión, funciona independientemente de la clasificación y no depende de que Windows acierte con un adaptador virtual. También sobrevive a una actualización del cliente que reclasifique la interfaz. Escriba el grupo en la regla y la siguiente persona podrá leer la intención sin preguntar.

Si la categoría de dominio se espera de verdad y nunca aparece, eso es una investigación aparte. Compruebe que la máquina esté unida al dominio, que pueda llegar a un controlador de dominio por el túnel y que el canal seguro esté sano. Esos tres comandos lo responden sin una sola edición del registro:

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

Esos tres responden si el extremo podía haber autenticado la red. Si no puede llegar a un controlador, la categoría de dominio nunca se asignará, por muchas veces que se reinicie el adaptador. La regla de firewall que perseguía nunca fue el problema real, y la etiqueta era un síntoma de un camino roto, no una causa.