Kantoorrekenaars bereik die deel, VPN-gebruikers kry 'n tydverstreke fout, en dieselfde rekening werk van 'n selfoon-hotspot. Die deeltoestemmings is selde die verskil; die adres wat by die lêerbediener aankom, is gewoonlik die verskil. 'n Reël wat tot LocalSubnet beperk is, laat die bediener se eie gekoppelde subnette toe, en 'n apart gerouteerde VPN-poel is nie een daarvan nie. Twee ontwerpe sluit die gaping, en hulle laat baie verskillende rekords agter.

Twee ontwerpe, een simptoom

Die eerste ontwerp voeg die VPN-poel by die reël se voorwaarde vir die afstandadres. Die bediener sien dan elke kliënt se tonneladres, so sy logboeke kan een afstandgebruiker van 'n ander onderskei. Die tweede ontwerp stuur VPN-verkeer deur 'n poort wat dit na 'n LAN-adres vertaal voordat die bediener dit sien. Dit herstel die verbinding en verwyder die onderskeid in dieselfde stap.

Die tabel beskryf rolle eerder as adresse, en jou eie voorvoegsels bepaal watter ry geld. Druk die bediener se werklike waardes uit eerder as om 'n voorbeeld uit 'n blogpos te kopieer:

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

Die tabel is 'n besluitnemingshulpmiddel, nie 'n bewering oor elke ontplooiing nie. 'n Gasheer met ekstra koppelvlakke, 'n tweede werfverbinding of 'n ander masker het 'n ander plaaslike stel.

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

Microsoft se New-NetFirewallRule-verwysing dokumenteer die voorwaardes vir die afstandadres en die sleutelwoord LocalSubnet. Lees dit voordat jy besluit dat die sleutelwoord alle private adresse beteken, want dit doen nie.

Vergelyk wat die bediener werklik ontvang

Lees die effektiewe reël eerder as die een wat iemand onthou hy geskep het. Kontroleer dat dit geaktiveer is, dat dit op die aktiewe profiel van toepassing is, en dat sy voorwaarde vir die afstandadres ooreenstem met die bron wat die bediener sien. 'n Reël wat slegs op die Domeinprofiel geaktiveer is, doen niks wanneer die adapter ná 'n netwerkverandering na Publiek oorgeslaan het nie.

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

Die eerste opdrag druk die adresfilters wat aan die lêerdelingsreëls gekoppel is, en die tweede wys watter profiele aktief is en hoe ongeëwenaarde inkomende verkeer hanteer word. Kyk ook vir 'n blokkeerreël en vir sentraal bestuurde beleid. Blokreëls het voorrang bo toelaatreëls, en 'n beleid wat plaaslike reëlsamesmelting deaktiveer, kan 'n nuwe plaaslike uitsondering onaktief maak.

Dit is die geval waar die reël in die konsole korrek lyk en geen uitwerking op verkeer het nie. Kontroleer die profieltoewysing terselfdertyd, want 'n skootrekenaar wat by 'n ander netwerk aangesluit het, kan na die Publieke profiel skuif sonder dat iemand die firewall aanraak.

Toets die vervoer voor die aanmelding

Skei bereikbaarheid van verifikasie. 'n Luisteraar op TCP 445 bewys dat 'n diens aan die poort gebind is; dit bewys nie dat 'n afstandpakket dit kan bereik nie. 'n Voltooide TCP-verbinding sê op sy beurt nog niks oor SMB-sessieopstelling of deeltoestemmings nie. Toets die handdruk van beide kante voordat jy 'n reël wysig.

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

Die eerste opdrag rapporteer of 'n TCP-handdruk van die masjien waarop jy dit uitvoer, slaag, en die tweede voeg die opgeloste adres en koppelvlakbesonderhede by. Voer dit uit vanaf die VPN-kliënt en vanaf 'n kantoorrekenaar, en vergelyk dan. Ping antwoord nie een van die twee vrae nie, want ICMP kan geblokkeer word terwyl SMB oop is, of toegelaat word terwyl die firewall 445 laat val.

As die handdruk slegs vanaf die VPN misluk, is die bronomvang die voorste verdagte. As dit slaag en die deel weier jou steeds, skuif na SMB-sessie- en toestemmingsdiagnose eerder as om firewallreëls te wysig.

Wanneer bron-NAT die onderskeid verwyder

Met vertaling in die pad kan die bediener nie individuele VPN-kliënte per adres onderskei nie. Elke afstandgebruiker kom as die poort aan. Enige magtiging wat daarop berus om hulle te onderskei, moet afgedwing word waar hul identiteite nog sigbaar is, wat gewoonlik die VPN-konsentrator of 'n verifiërende proxy beteken. Die firewallreël kan verkeer toelaat; dit kan nie 'n onderskeid herstel wat vertaling verwyder het nie.

Sodra daardie poortadres toegelaat word, word elke afstandgebruiker onder 'n enkele adres aangeteken, so die reël verleen die hele poel aan enigiemand wat die poort kan bereik. As 'n besluit per gebruiker saak maak, hou die oorspronklike adresse sigbaar of skuif die besluit na 'n laag wat die gebruiker nog ken. Anders erf elke afstandgebruiker die toestemmings van die een adres wat die bediener kan sien, en die ouditspoor kan hulle daarna nie onderskei nie. Dit is 'n ontwerpbesluit, nie 'n firewallbesonderheid nie.

Kies doelbewus tussen die twee ontwerpe. Beperk die reël tot die werklike VPN-poel wanneer die bediener moet sien wie gekoppel het, en aanvaar die vertaalde pad slegs wanneer die bediener daardie inligting werklik nie nodig het nie. Teken die gekose bronreeks langs die reël aan, want die volgende persoon wat dit ontfout, sal eerste na die adrestabel kyk.

Verwante artikels