¿Debe ser privado o público el adaptador VPN de Windows?

Poner un adaptador VPN de Windows en Privado es correcto para un túnel corporativo e incorrecto para un cliente VPN comercial, y la diferencia no es cosmética. La categoría de red selecciona un perfil de firewall, así que un solo cambio admite todo un conjunto de reglas a la vez. He visto un script de inicio de sesión que ponía todos los adaptadores no identificados en Privado, lo que expuso en silencio el uso compartido de archivos en una red inalámbrica de hotel. Tres condiciones deciden la respuesta, y todas deben cumplirse antes de tocar el ajuste.

Qué decide realmente la categoría

Network Location Awareness construye una firma para cada red conectada a partir de lo que el adaptador puede informar: la dirección de puerta de enlace y la MAC, el sufijo DNS, si responde un controlador de dominio y si la red llega a internet. Windows asocia un perfil a esa firma, y el firewall aplica entonces el conjunto de reglas de ese perfil. Público es el respaldo cuando falla la identificación, por eso un túnel que funciona puede seguir etiquetado como red no identificada.

Un adaptador TUN o TAP suele dar muy poca información a la identificación. El extremo del túnel suele ser una sola dirección en lugar de una puerta de enlace, el DNS puede empujarse solo dentro del túnel y el adaptador no tiene su propia ruta predeterminada. La etiqueta resultante describe la entrada del firewall, no la salud del túnel, y es la razón por la que las reglas del perfil privado dejan de coincidir en el momento en que se conecta la VPN.

Condición uno: el túnel es la ruta de confianza

Elegir Privado afirma que todo lo alcanzable por esta interfaz es al menos tan confiable como su propia LAN, porque el descubrimiento y las reglas de entrada tratarán esa subred como local. Para un túnel corporativo hacia una subred gestionada con servidores de archivos e impresoras, la afirmación suele sostenerse. El adaptador es una puerta hacia una red que controla su organización, y la máquina del otro lado fue admitida por la misma política que admitió la suya.

Una salida VPN comercial no supera esta prueba. Otros suscriptores comparten la subred de salida, y marcarla como Privado pone el descubrimiento de red, LLMNR y la resolución de nombres NetBIOS en un segmento lleno de desconocidos. El túnel dividido también puede fallar: cuando el adaptador lleva una única ruta de host hacia una aplicación, no hay subred de confianza de la que hablar, y el cambio de categoría no le aporta nada.

Condición dos: la clasificación sobrevive a las reconexiones

Una nueva puerta de enlace o un sufijo DNS nuevo producen una firma nueva, y Windows toma una decisión de perfil nueva para ella. Por eso un Set-NetConnectionProfile puntual sobrevive hasta la próxima reconexión, no para siempre. Compruebe el perfil después de una reconexión en lugar de después de la primera conexión, porque es entonces cuando el ajuste revierte por sí solo.

Hay tres formas de hacerlo duradero. La más limpia es la política: abra secpol.msc, vaya a Network List Manager Policies y defina el tipo de ubicación de la red, incluida la política de red no identificada, para que el perfil se aplique por política y no por comando. La segunda es un script por conexión o una tarea programada que ejecute el cmdlet de PowerShell cuando sube el túnel. La tercera es el viejo truco de la ruta, que da a la identificación una puerta de enlace que sondear:

route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfile

El truco de la ruta es un rodeo, no una clasificación. Se rompe cuando cambia la relación de métricas o el cliente VPN reescribe las rutas al reconectar, y cambia en silencio la selección de ruta de todo lo que cae en la segunda ruta predeterminada.

Condición tres: necesita el conjunto de reglas privadas

Privado suele incluir el uso compartido de archivos e impresoras, el descubrimiento de red y los grupos de administración remota. Si la tarea es llegar a un recurso compartido SMB o a una impresora a través del túnel, esa es la razón real para cambiar la categoría. Si la tarea es acceso saliente a una aplicación web, la categoría es irrelevante: escriba la regla de salida, mantenga Público y deténgase ahí.

Lea la tabla como punto de partida y luego compruebe qué reglas privadas están realmente habilitadas en su compilación. Una imagen endurecida puede haber eliminado por completo el uso compartido de archivos del perfil privado, y en ese caso el cambio de categoría no logra nada hasta que vuelva a añadir la regla. Esa comprobación cuesta un comando y ahorra una tarde larga.

Hacer el cambio sin ampliar todo lo demás

Apunte al índice de la interfaz, no a un comodín, y lea la lista antes y después:

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfile

Los perfiles guardados viven bajo la clave NetworkList del registro, donde el valor Category separa las redes públicas, privadas y de dominio. Editarlo es posible y fácil de hacer mal: debe cambiar la entrada que coincide con la firma actual del adaptador, no una entrada más antigua dejada por una dirección anterior. Una entrada obsoleta se ve correcta en el editor y no hace nada al reconectar.

Haga lo que haga, no distribuya un script que ponga todos los adaptadores no identificados en Privado. Esa es la versión de una línea de abrir el descubrimiento en una red inalámbrica no confiable. Si solo necesita compartir con la subred del túnel, mantenga el perfil Público y añada reglas de entrada limitadas al rango de direcciones remotas del túnel; la regla de firewall es más estrecha que la categoría.

Verifique el recurso compartido, no la etiqueta

Después del cambio, pruebe el recurso mismo en lugar de confiar en la etiqueta:

Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.example

Si el recurso compartido sigue fallando mientras el adaptador muestra Privado, la categoría ya no es su problema. La resolución de nombres, una ruta ausente o los permisos del recurso compartido producirán el mismo síntoma, y cambiar el perfil otra vez no puede reparar ninguno de ellos. Reconéctese una vez y vuelva a ejecutar Get-NetConnectionProfile para confirmar que el ajuste se mantuvo, y luego trate el fallo restante como un problema SMB normal.

Lista de comprobación: confirme que el túnel es una ruta gestionada, que el perfil sobrevive a una reconexión, que las reglas privadas que necesita existen en la imagen y que el recurso compartido se resuelve y responde en el puerto 445. Si alguna de las tres primeras es falsa, deje el adaptador en Público y resuelva el problema de acceso con una regla limitada.