Afegir una regla de permís per a RDP no redueix el vostre accés per VPN

El pla sembla raonable: deixeu el permís existent d'Escriptori remot tal com és i afegiu-ne un de petit per a l'únic client VPN que hauria de tenir accés. El tallafocs del Windows no funciona així. Les regles no són una llista ordenada en què guanyi l'entrada més específica, i un permís estret al costat d'un d'ample no canvia res, perquè l'ample continua admetent tothom que ja admetia. Estrenyir el servei vol dir editar el permís que ja fa la feina.

La regla que afegiu no és la regla que importa

El tallafocs del Windows avalua totes les regles d'entrada aplicables als magatzems de polítiques que afecten la màquina i després decideix si alguna regla de permís coincideix i si alguna de bloqueig la sobreescriu. Afegir una regla afegeix un permís; no elimina ni matisa els permisos que ja hi són.

Per tant, la pregunta no és mai què heu afegit. És què conté la política efectiva després de fusionar la política local, la política de domini i els valors per defecte del perfil. Una estació de treball amb una sola regla local és fàcil de raonar; un servidor unit a un domini, no.

És també per això que un administrador pot fer un canvi que sembla correcte, provar-lo des de la màquina equivocada i concloure que ha funcionat. L'origen exclòs no es va provar mai. Una prova que només demostra èxit demostra menys de la meitat d'allò per a què servia el canvi.

Esbrineu quina adreça veu el servidor

Abans de limitar res, observeu una sessió permesa a l'amfitrió Windows i anoteu l'adreça d'origen que informa el servidor. No sempre és l'adreça que el client creu que té.

Si la passarel·la VPN conserva les adreces dels clients, el servidor veu l'adreça del túnel del client i una regla limitada per adreça té sentit. Si la passarel·la tradueix, cada client arriba com l'adreça de la passarel·la, i limitar-la a aquesta adreça dona accés a tots els clients que hi ha darrere. Llavors la regla és precisa sobre la cosa equivocada.

Aquests dos dissenys necessiten respostes diferents. El primer es pot expressar en una regla de tallafocs; el segon s'ha d'aplicar allà on la identitat encara existeix, és a dir, al mateix VPN o en una passarel·la autenticada davant del servei.

Un filtre de tallafocs no pot recuperar una identitat que la traducció de xarxa ha descartat, per molt acuradament que s'escrigui l'adreça.

Canvieu el propietari de la regla efectiva

Inspeccioneu la política d'entrada efectiva i trobeu cada regla que actualment admet trànsit RDP, incloses les regles el nom de les quals mai no esmenta el port 3389. Les regles limitades per servei i per aplicació també compten, i també el transport UDP que alguns desplegaments de RDP habilita.

Després editeu les regles existents a través del magatzem que les posseeix. Una edició local d'una regla que també defineix la política de domini es pot fusionar, ignorar o sobreescriure, i val la pena saber quin d'aquests casos passa abans de confiar-hi.

Aquestes ordres troben les regles actives, mostren el filtre d'adreces associat a una d'elles i previsualitzen un canvi d'abast:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

Els noms de regla aquí són marcadors del que va trobar la revisió, i l'indicador de previsualització existeix perquè una errata en una adreça no us tanqui fora del servidor que editeu.

Bloqueja-i-després-permet és un model diferent

El costum d'altres tallafocs és escriure un bloqueig ampli i després un permís estret a sobre. A Windows un bloqueig explícit generalment guanya sobre un permís, així que aquest ordre produeix un servei al qual ningú pot arribar en lloc d'una excepció per a un client. El resultat és una interrupció que sembla un servei RDP espatllat. En realitat és un error de precedència, i la solució és treure el bloqueig en lloc d'afegir un altre permís.

Manteniu el comportament per defecte de bloqueig d'entrada als perfils actius i estrenyiu en canvi els permisos específics. Això deixa la màquina amb una postura comprensible en lloc de dues regles contradictòries la interacció de les quals depèn de detalls de precedència.

Demostreu-ho amb un segon origen

Proveu des del client permès i des d'un origen que ara hauria de fallar. Una sola connexió amb èxit només demostra que el camí permès funciona; no diu res sobre l'exclusió que acabeu de fer.

Repetiu la prova per IPv6 si el servidor el té habilitat, perquè una intenció només per a IPv4 pot coexistir amb un permís ampli per a IPv6 que ningú no ha mirat.

Finalment, manteniu l'autenticació separada de l'abastabilitat. L'autenticació de nivell de xarxa, els drets del compte i les restriccions d'inici de sessió encara decideixen qui pot utilitzar la sessió, i el tallafocs només decideix qui pot preguntar. Treure un dispositiu més endavant hauria de treure tant la seva inscripció al VPN com aquest permís de xarxa, o l'adreça que heu limitat acabarà pertanyent a algú altre.