O adaptador VPN de Windows debe ser privado ou público?
Decida se un adaptador VPN de Windows pertence ao perfil privado con tres probas: ruta de confianza, clasificación estable e regras que realmente necesita.
Pór un adaptador VPN de Windows en Privado é correcto para un túnel corporativo e incorrecto para un cliente VPN comercial, e a diferenza non é cosmética. A categoría de rede selecciona un perfil de devasa, así que un só cambio admite todo un conxunto de regras de vez. Vin un script de inicio de sesión que poñía todos os adaptadores non identificados en Privado, o que expuxo silenciosamente a compartición de ficheiros nunha rede sen fíos de hotel. Tres condicións deciden a resposta, e todas deben cumprirse antes de tocar o axuste.
Que decide realmente a categoría
Network Location Awareness constrúe unha sinatura para cada rede conectada a partir do que o adaptador pode informar: o enderezo de pasarela e a MAC, o sufixo DNS, se responde un controlador de dominio e se a rede chega a internet. Windows asocia un perfil a esa sinatura, e a devasa aplica entón o conxunto de regras dese perfil. Público é o respaldo cando falla a identificación, por iso un túnel que funciona pode seguir etiquetado como rede non identificada.
Un adaptador TUN ou TAP adoita dar moi pouca información á identificación. O extremo do túnel é a miúdo un só enderezo en lugar dunha pasarela, o DNS pode empurrarse só dentro do túnel e o adaptador non ten a súa propia ruta predeterminada. A etiqueta resultante describe a entrada da devasa, non a saúde do túnel, e é a razón pola que as regras do perfil privado deixan de coincidir no momento en que se conecta a VPN.
Condición unha: o túnel é a ruta de confianza
Elixir Privado afirma que todo o alcanzable por esta interface é polo menos tan confiable como a súa propia LAN, porque o descubrimento e as regras de entrada tratarán esa subrede como local. Para un túnel corporativo cara a unha subrede xestionada con servidores de ficheiros e impresoras, a afirmación adoita manterse. O adaptador é unha porta cara a unha rede que controla a súa organización, e a máquina do outro lado foi admitida pola mesma política que admitiu a súa.
Unha saída VPN comercial non supera esta proba. Outros subscritores comparten a subrede de saída, e marcala como Privado pon o descubrimento de rede, LLMNR e a resolución de nomes NetBIOS nun segmento cheo de descoñecidos. O túnel dividido tamén pode fallar: cando o adaptador leva unha única ruta de host cara a unha aplicación, non hai subrede de confianza da que falar, e o cambio de categoría non lle aporta nada.
Condición dúas: a clasificación sobrevive ás reconexións
Unha pasarela ou un sufixo DNS novos producen unha sinatura nova, e Windows toma unha decisión de perfil nova para ela. Por iso un Set-NetConnectionProfile puntual sobrevive ata a próxima reconexión, non para sempre. Comprobe o perfil despois dunha reconexión en lugar de despois da primeira conexión, porque é entón cando o axuste reverte por si só.
Hai tres formas de facelo duradeiro. A máis limpa é a política: abra secpol.msc, vaia a Network List Manager Policies e defina o tipo de ubicación da rede, incluída a política de rede non identificada, para que o perfil se aplique por política e non por orde. A segunda é un script por conexión ou unha tarefa programada que execute o cmdlet de PowerShell cando sobe o túnel. A terceira é o vello truco da ruta, que dá á identificación unha pasarela que sondar:
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileO truco da ruta é un rodeo, non unha clasificación. Rómpese cando cambia a relación de métricas ou o cliente VPN reescribe as rutas ao reconectar, e cambia en silencio a selección de ruta de todo o que cae na segunda ruta predeterminada.
Condición tres: necesita o conxunto de regras privadas
Privado adoita incluír a compartición de ficheiros e impresoras, o descubrimento de rede e os grupos de administración remota. Se a tarefa é chegar a un recurso compartido SMB ou a unha impresora a través do túnel, esa é a razón real para cambiar a categoría. Se a tarefa é acceso saínte a unha aplicación web, a categoría é irrelevante: escriba a regra de saída, manteña Público e detéñase aí.
| 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 |
Lea a táboa como punto de partida e despois comprobe que regras privadas están realmente habilitadas na súa compilación. Unha imaxe endurecida pode ter eliminado por completo a compartición de ficheiros do perfil privado, e nese caso o cambio de categoría non logra nada ata que volva engadir a regra. Esa comprobación custa un comando e aforra unha tarde longa.
Facer o cambio sen ampliar todo o demais
Apunte ao índice da interface, non a un comodín, e lea a lista antes e despois:
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileOs perfís gardados viven baixo a clave NetworkList do rexistro, onde o valor Category separa as redes públicas, privadas e de dominio. Editalo é posible e fácil de facer mal: debe cambiar a entrada que coincide coa sinatura actual do adaptador, non unha entrada máis antiga deixada por un enderezo anterior. Unha entrada obsoleta parécese correcta no editor e non fai nada ao reconectar.
Faga o que faga, non distribúa un script que poña todos os adaptadores non identificados en Privado. Esa é a versión dunha liña de abrir o descubrimento nunha rede sen fíos non confiable. Se só necesita compartir coa subrede do túnel, manteña o perfil Público e engada regras de entrada limitadas ao rango de enderezos remotos do túnel; a regra de devasa é máis estreita ca categoría.
Verifique o recurso compartido, non a etiqueta
Despois do cambio, probe o recurso mesmo en lugar de confiar na etiqueta:
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleSe o recurso compartido segue fallando mentres o adaptador mostra Privado, a categoría xa non é o seu problema. A resolución de nomes, unha ruta ausente ou os permisos do recurso compartido producirán o mesmo síntoma, e cambiar o perfil outra vez non pode reparar ningún deles. Reconéctese unha vez e volva executar Get-NetConnectionProfile para confirmar que o axuste se mantivo, e logo trate o fallo restante como un problema SMB normal.
Lista de comprobación: confirme que o túnel é unha ruta xestionada, que o perfil sobrevive a unha reconexión, que as regras privadas que necesita existen na imaxe e que o recurso compartido se resolve e responde no porto 445. Se algunha das tres primeiras é falsa, deixe o adaptador en Público e resolva o problema de acceso cunha regra limitada.