LocalSubnet en una regla de firewall SMB no cubrirá a los clientes VPN
Una regla de permiso LocalSubnet cubre las subredes propias del servidor, no un grupo VPN enrutado. Compare la dirección de origen que ve el servidor antes de ampliar el alcance.
Los equipos de oficina llegan al recurso compartido, los usuarios de VPN agotan el tiempo de espera y la misma cuenta funciona desde un punto de acceso móvil. Los permisos de uso compartido rara vez son la diferencia; la dirección que llega al servidor de archivos suele serlo. Una regla limitada a LocalSubnet admite las subredes conectadas del propio servidor, y un grupo VPN enrutado por separado no es una de ellas. Dos diseños cierran la brecha, y dejan registros muy distintos.
Dos diseños, un síntoma
El primer diseño añade el grupo VPN a la condición de dirección remota de la regla. El servidor pasa a ver la dirección de túnel de cada cliente, de modo que sus registros pueden distinguir a un usuario remoto de otro. El segundo diseño enruta el tráfico VPN por una puerta de enlace que lo traduce a una dirección LAN antes de que el servidor lo vea. Eso restaura la conectividad y elimina la distinción en el mismo paso.
La tabla describe roles, no direcciones, y sus propios prefijos deciden qué fila se aplica. Imprima los valores reales del servidor en lugar de copiar un ejemplo de una entrada de blog:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthLa tabla es una ayuda para decidir, no una afirmación sobre cada despliegue. Un host con interfaces adicionales, un segundo enlace de sitio o una máscara distinta tiene un conjunto local distinto.
| Path the packet takes | Address the server records | Filter scope that admits it | What the log can still tell you |
|---|---|---|---|
| Desktop on the server LAN | Its own LAN address | LocalSubnet or the LAN prefix | Which workstation connected |
| Client on the routed VPN pool | Its tunnel address | The VPN pool as a remote address | Which VPN account connected, if the pool is logged |
| Client behind source NAT at the gateway | The gateway's LAN address | The gateway address | Only that some VPN user connected |
| Site-to-site gateway | The remote gateway's tunnel address | The remote site's prefix | Which site connected, not which user |
La referencia de New-NetFirewallRule de Microsoft documenta las condiciones de dirección remota y la palabra clave LocalSubnet. Léala antes de decidir que la palabra clave significa todas las direcciones privadas, porque no es así.
Compare qué recibe realmente el servidor
Lea la regla efectiva en lugar de la que alguien recuerda haber creado. Compruebe que está habilitada, que se aplica al perfil activo y que su condición de dirección remota coincide con el origen que ve el servidor. Una regla habilitada solo en el perfil Dominio no hace nada cuando el adaptador ha pasado a Público tras un cambio de red.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionEl primer comando imprime los filtros de dirección asociados a las reglas de uso compartido de archivos, y el segundo muestra qué perfiles están activos y cómo se trata el tráfico entrante que no coincide. Busque también una regla de bloqueo y una directiva administrada centralmente. Las reglas de bloqueo tienen prioridad sobre las de permiso, y una directiva que deshabilite la fusión de reglas locales puede dejar inerte una nueva excepción local.
Ese es el caso en que la regla parece correcta en la consola y no tiene ningún efecto sobre el tráfico. Compruebe la asignación de perfil al mismo tiempo, porque un portátil que se ha unido a otra red puede pasar al perfil Público sin que nadie toque el firewall.
Pruebe el transporte antes del inicio de sesión
Separe la accesibilidad de la autenticación. Un receptor en TCP 445 demuestra que un servicio está vinculado al puerto; no demuestra que un paquete remoto pueda alcanzarlo. Una conexión TCP completada, a su vez, todavía no dice nada sobre el establecimiento de la sesión SMB ni sobre los permisos de uso compartido. Pruebe el handshake desde ambos lados antes de editar una regla.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel DetailedEl primer comando informa si un handshake TCP se completa desde la máquina en la que lo ejecuta, y el segundo añade la dirección resuelta y los detalles de la interfaz. Ejecútelo desde el cliente VPN y desde un equipo de oficina, y compare. Ping no responde a ninguna de las dos preguntas, porque ICMP puede estar bloqueado mientras SMB está abierto, o permitido mientras el firewall descarta 445.
Si el handshake falla solo desde la VPN, el alcance de origen es el principal sospechoso. Si se completa y el recurso compartido sigue rechazándole, pase al diagnóstico de la sesión SMB y de los permisos en lugar de editar reglas de firewall.
Cuando el NAT de origen elimina la distinción
Con traducción en el camino, el servidor no puede distinguir clientes VPN individuales por dirección. Cada usuario remoto llega como la puerta de enlace. Cualquier autorización que dependa de distinguirlos debe aplicarse donde sus identidades sigan siendo visibles, lo que normalmente significa el concentrador VPN o un proxy autenticador. La regla de firewall puede admitir tráfico; no puede restaurar una distinción que la traducción eliminó.
Una vez permitida esa dirección de puerta de enlace, cada usuario remoto queda registrado bajo una única dirección, así que la regla concede todo el grupo a cualquiera que pueda alcanzar la puerta de enlace. Si importa una decisión por usuario, mantenga visibles las direcciones originales o traslade la decisión a una capa que aún conozca al usuario. De lo contrario, cada usuario remoto hereda los permisos de la única dirección que el servidor puede ver, y el rastro de auditoría ya no puede distinguirlos. Es una decisión de diseño, no un detalle del firewall.
Elija deliberadamente entre los dos diseños. Limite la regla al grupo VPN real cuando el servidor deba ver quién se conectó, y acepte la ruta traducida solo cuando el servidor realmente no necesite esa información. Anote el rango de origen elegido junto a la regla, porque la próxima persona que depure esto mirará primero la tabla de direcciones.