Clientes VPN bloqueados polo perfil Público da devasa de Windows

O teu túnel está activo, a pasarela responde ao ping e o recurso compartido segue esgotando o tempo de espera. Esa combinación raramente é un problema de encamiñamento: Windows puxo a subrede do adaptador VPN no perfil Público, e cada regra de permiso escrita para Privado ou Dominio nunca se aplicou. Atopei isto en portátiles que chegan á oficina sen problema e en servidores RRAS que atenden todos os demais clientes, e a reparación é curta así que nomeas o perfil en xogo. Velaquí a orde na que traballo, coa comprobación que che di cando parar antes do seguinte paso.

Averigua por que perfil chega realmente o tráfico

A devasa de Windows non ten un único modo global. Cada interface conectada leva unha categoría, e os paquetes entrantes fíltrandse segundo a categoría da interface pola que chegan, así que é o perfil do adaptador VPN o que decide a que pode chegar un cliente en túnel, non o adaptador Wi-Fi ou Ethernet de ao lado. Le ambos os feitos antes de cambiar nada:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

Nunha instalación estándar de OpenVPN ou WireGuard, o adaptador VPN aparece como unha rede non identificada e cae en Público, o valor predeterminado para calquera rede que Windows non poida clasificar: ningún controlador de dominio respondeu por ela e ningún perfil de pasarela coincidiu. O nome da interface é irrelevante aquí, así que chamar ao adaptador «VPN» ou «Corp» non cambia nada. DomainAuthenticated require unha máquina unida ao dominio , que poida chegar realmente a un controlador de dominio por esa interface; un túnel dividido que só transporte unha subrede non cumprirá o requisito.

Se a regra que necesitas xa está limitada á piscina de VPN e xa se aplica á categoría que acabas de ler, para aquí: o filtrado non é a túa capa, e o seguinte lugar onde mirar é a configuración do servizo. Esa comprobación leva dez segundos e aforra unha hora de edición de regras. Os nomes das categorías e o que cobre cada unha están documentados na referencia de Get-NetConnectionProfile.

Confirma o filtrado, non o encamiñamento, antes de editar regras

O ping é unha proba feble. ICMP pode pasar mentres se descarta o porto do servizo, e un host pode responder desde a LAN mentres rexeita a mesma petición polo túnel. Proba o porto que necesita o cliente, desde o cliente:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Se a proba do porto falla, separa as dúas capas. Un fallo de túnel ou de ruta adoita aparecer como ningunha resposta desde o enderezo da pasarela, mentres que un descarte da devasa mostra unha pasarela que responde e un porto de servizo que non responde. Nun servidor Windows que publica a piscina mediante RRAS, executa a mesma proba desde un cliente e le o perfil do propio servidor: a interface RAS pode estar nunha categoría cuxas regras de entrada nunca mencionan o rango de clientes, e por iso o equipo atende a súa LAN e rexeita todos os clientes en túnel.

Cando o resultado aínda é ambiguo, rexistra os descartes do perfil en xogo e léos:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

As entradas que nomean o enderezo e o porto do cliente con DROP son concluíntes, e tamén che din que regra faltaba. Un rexistro baleiro mentres o SYN do cliente nunca aparece apunta augas arriba do host, así que volve ao túnel, á regra NAT ou á ruta da piscina antes de tocar outro obxecto da devasa.

Limita unha regra de entrada á piscina de clientes

A reparación é unha única regra de permiso de entrada cuxo enderezo remoto é a piscina, non o mundo enteiro. Desde unha sesión elevada:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Cando o servizo é un único binario, prefire unha regra limitada ao programa con -Program en vez dunha lista de portos; iso limita a excepción tanto ao proceso como ao rango de orixe.

A elección do perfil é onde se comete o mesmo erro na dirección oposta. -Profile Public abonda cando o adaptador é Público e segue séndoo. -Profile Any é defendible cando o servizo debe funcionar independentemente de como Windows clasifique o adaptador, pero só mentres se manteña o ámbito remoto. O que nunca é defendible é -RemoteAddress Any no perfil Público: esa regra segue o portátil en cada rede de cafetería e hotel á que se conecta e abre o porto a quen comparta esa subrede.

Anota a piscina xunto á regra. -RemoteAddress 10.8.0.0/24 deixa de coincidir silenciosamente o día que se renumera a piscina de VPN, e o fallo parece exactamente o erro orixinal, e por iso custa unha segunda tarde. Nomea as regras polo servizo e o rango de orixe, manténas xuntas con -Group, e volve lelas sempre que cambie a definición da piscina. Un inventario de regras que podes auditar nunha soa pantalla supera unha regra correcta que ninguén atopa.

Cambia a categoría só cando a categoría é a decisión

Cambiar a interface a Privado tamén funciona, e é o valor predeterminado equivocado. O perfil Privado leva unha longa lista de regras de permiso integradas, que cobren compartición de ficheiros e impresoras, descuberta de rede, escritorio remoto e máis segundo a liña base, así que reclasificar o adaptador VPN habilítaas todas á vez para cada cliente do túnel. Unha regra limitada concede un servizo a un rango. Nun portátil que tamén se conecta a redes non fiables, esa diferenza non é cosmética.

Hai casos en que a clasificación é realmente errónea: un túnel sempre activo ou de sitio a sitio que transporta unha subrede de oficina é infraestrutura de confianza, e marcar ese adaptador como Privado é unha decisión de deseño lexítima, tomada unha vez por política e non por tícket. Cando o fagas, faino explicitamente:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Nun dispositivo xestionado, comproba primeiro se unha Directiva de grupo ou unha liña base MDM posúe a configuración. Se a posúe, o cambio local desfaise na seguinte actualización e gpresult /h nomeará a directiva que a posúe; corríxeo alí, non no punto final.

Verifica desde ambos os extremos e deixa rastro

Verifica o fluxo que informou o usuario, desde o cliente, despois do cambio:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

Despois pecha o bucle nas cousas que se romperán a próxima semana. Reinicia o host e proba de novo, porque unha regra limitada ao perfil equivocado segue funcionando ata que o adaptador volve noutra categoría. Proba desde un segundo cliente, xa que un cliente cunha concesión obsoleta pode ocultar unha discrepancia da piscina. Conta as regras que engadiches fronte ás que eliminaches, porque as excepcións solapadas son a forma en que unha corrección de dúas liñas se converte nunha política de filtrado que ninguén pode revisar.

Antes de dalo por rematado:

• O perfil nomeado na regra é o perfil da interface pola que chega o tráfico.
• O ámbito remoto é a piscina de VPN, e esa piscina coincide co que o servidor entrega realmente.
• Ningunha regra que engadiches usa -RemoteAddress Any no perfil Público.
• Non se desactivou nada para que a proba pase, e calquera cambio de categoría rexistra quen o aprobou.