Els escriptoris d'oficina arriben al recurs compartit, els usuaris de VPN es queden sense temps d'espera i el mateix compte funciona des d'un punt d'accés mòbil. Els permisos de compartició poques vegades són la diferència; normalment ho és l'adreça que arriba al servidor de fitxers. Una regla limitada a LocalSubnet admet les subxarxes connectades del propi servidor, i un conjunt VPN encaminat per separat no és una d'elles. Dos dissenys tanquen aquesta bretxa i deixen registres molt diferents.

Dos dissenys, un símptoma

El primer disseny afegeix el conjunt VPN a la condició d'adreça remota de la regla. Llavors el servidor veu l'adreça de túnel de cada client, de manera que els seus registres poden distingir un usuari remot d'un altre. El segon disseny encamina el trànsit VPN per una passarel·la que el tradueix a una adreça LAN abans que el servidor el vegi. Això restaura la connectivitat i elimina la distinció en el mateix pas.

La taula descriu rols, no adreces, i els vostres prefixes decideixen quina fila s'aplica. Imprimiu els valors reals del servidor en lloc de copiar un exemple d'una entrada de blog:

Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength

La taula és una ajuda per decidir, no una afirmació sobre cada desplegament. Un amfitrió amb interfícies addicionals, un segon enllaç de lloc o una màscara diferent té un conjunt local diferent.

Path the packet takesAddress the server recordsFilter scope that admits itWhat the log can still tell you
Desktop on the server LANIts own LAN addressLocalSubnet or the LAN prefixWhich workstation connected
Client on the routed VPN poolIts tunnel addressThe VPN pool as a remote addressWhich VPN account connected, if the pool is logged
Client behind source NAT at the gatewayThe gateway's LAN addressThe gateway addressOnly that some VPN user connected
Site-to-site gatewayThe remote gateway's tunnel addressThe remote site's prefixWhich site connected, not which user

La referència de New-NetFirewallRule de Microsoft documenta les condicions d'adreça remota i la paraula clau LocalSubnet. Llegiu-la abans de decidir que la paraula clau significa totes les adreces privades, perquè no és així.

Compareu què rep realment el servidor

Llegiu la regla efectiva en lloc de la que algú recorda haver creat. Comproveu que estigui habilitada, que s'apliqui al perfil actiu i que la seva condició d'adreça remota coincideixi amb l'origen que veu el servidor. Una regla habilitada només al perfil Domini no fa res quan l'adaptador ha passat a Públic després d'un canvi de xarxa.

Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

La primera ordre imprimeix els filtres d'adreça adjunts a les regles de compartició de fitxers, i la segona mostra quins perfils són actius i com es tracta el trànsit d'entrada que no coincideix. Busqueu també una regla de bloqueig i una política gestionada centralment. Les regles de bloqueig tenen prioritat sobre les de permisos, i una política que desactivi la fusió de regles locals pot deixar inerta una excepció local nova.

Aquest és el cas en què la regla sembla correcta a la consola i no té cap efecte sobre el trànsit. Comproveu l'assignació de perfil alhora, perquè un portàtil que s'ha connectat a una altra xarxa pot passar al perfil Públic sense que ningú toqui el tallafoc.

Proveu el transport abans de l'inici de sessió

Separeu l'abastabilitat de l'autenticació. Un oient a TCP 445 demostra que un servei està lligat al port; no demostra que un paquet remot hi pugui arribar. Una connexió TCP completada, al seu torn, encara no diu res sobre l'establiment de la sessió SMB ni sobre els permisos de compartició. Proveu l'encaixada de mans des dels dos costats abans d'editar una regla.

Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed

La primera ordre informa si una encaixada de mans TCP té èxit des de la màquina on l'executeu, i la segona afegeix l'adreça resolta i els detalls de la interfície. Executeu-la des del client VPN i des d'un escriptori d'oficina, i compareu. Ping no respon cap de les dues preguntes, perquè ICMP pot estar bloquejat mentre SMB és obert, o permès mentre el tallafoc descarta 445.

Si l'encaixada de mans falla només des de la VPN, l'abast d'origen és el principal sospitós. Si té èxit i el recurs compartit encara us rebutja, passeu al diagnòstic de la sessió SMB i dels permisos en lloc d'editar regles de tallafoc.

Quan el NAT d'origen elimina la distinció

Amb traducció al camí, el servidor no pot distingir clients VPN individuals per adreça. Cada usuari remot arriba com la passarel·la. Qualsevol autorització que depengui de distingir-los s'ha d'aplicar on les seves identitats encara siguin visibles, cosa que normalment vol dir el concentrador VPN o un proxy autenticador. La regla de tallafoc pot admetre trànsit; no pot restaurar una distinció que la traducció ha eliminat.

Un cop s'admet aquesta adreça de passarel·la, cada usuari remot es registra sota una única adreça, de manera que la regla concedeix tot el conjunt a qualsevol que pugui arribar a la passarel·la. Si la decisió per usuari importa, manteniu les adreces originals visibles o moveu la decisió a una capa que encara conegui l'usuari. En cas contrari, cada usuari remot hereta els permisos de l'única adreça que el servidor pot veure, i la traça d'auditoria ja no pot distingir-los. Això és una decisió de disseny, no un detall del tallafoc.

Trieu deliberadament entre els dos dissenys. Limiteu la regla al conjunt VPN real quan el servidor hagi de veure qui s'ha connectat, i accepteu el camí traduït només quan el servidor realment no necessiti aquesta informació. Anoteu el rang d'origen triat al costat de la regla, perquè la propera persona que depuri això mirarà primer la taula d'adreces.

Articles relacionats