LocalSubnet i ein SMB-brannmurregel dekkjer ikkje VPN-klientar
Ein tillatingsregel med LocalSubnet dekkjer serveren sine eigne subnett, ikkje ein ruta VPN-pool. Samanlikn kjeldeadressa serveren ser før du utvidar omfanget.
Kontordatamaskinar når delinga, VPN-brukarar får tidsavbrot, og same konto fungerer frå eit mobilhotspot. Delingstillatingane er sjeldan skilnaden; adressa som kjem til filserveren er det vanlegvis. Ein regel avgrensa til LocalSubnet slepp inn serveren sine eigne tilkopla subnett, og ein separat ruta VPN-pool er ikkje eitt av dei. To design lukkar gapet, og dei etterlèt svært ulike loggar.
To design, eitt symptom
Det første designet legg VPN-poola til vilkåret for ekstern adresse i regelen. Serveren ser då tunneladressa til kvar klient, slik at loggane kan skilje ein ekstern brukar frå ein annan. Det andre designet ruter VPN-trafikk gjennom ein gateway som omset han til ei LAN-adresse før serveren ser han. Det gjenopprettar tilkoplinga og fjernar skilnaden i same trinn.
Tabellen skildrar roller og ikkje adresser, og dine eigne prefiks avgjer kva rad som gjeld. Skriv ut dei faktiske verdiane til serveren i staden for å kopiere eit døme frå eit blogginnlegg:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLength
Tabellen er ei beslutningsstøtte, ikkje ei påstand om kvar utrulling. Ein vert med ekstra grensesnitt, ein annan stadlenkje eller ei anna maske har eit anna lokalt sett.
| 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 |
Microsoft si referanse for New-NetFirewallRule dokumenterer vilkåra for ekstern adresse og nøkkelordet LocalSubnet. Les han før du avgjer at nøkkelordet tyder alle private adresser, for det gjer det ikkje.
Samanlikn det serveren faktisk mottek
Les den effektive regelen i staden for den nokon hugsar at dei oppretta. Kontroller at han er aktivert, gjeld den aktive profilen, og at vilkåret for ekstern adresse stemmer med kjelda serveren ser. Ein regel som berre er aktivert på Domain-profilen, gjer ingenting når adapteren har gått over til Public etter ei nettverksendring.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction
Den første kommandoen skriv ut adressefiltra som er knytte til fildelingsreglane, og den andre viser kva profilar som er aktive og korleis inngåande trafikk som ikkje samsvarar, vert handsama. Sjå òg etter ein blokkeringsregel og ein sentralt administrert policy. Blokkeringsreglar går føre tillatingsreglar, og ein policy som slår av samanslåing av lokale reglar kan gjere eit nytt lokalt unntak utan verknad.
Det er tilfellet der regelen ser rett ut i konsollen og ikkje har nokon verknad på trafikken. Kontroller profiltildelinga samtidig, for ein berbar PC som har kopla seg til eit anna nettverk, kan flytte til Public-profilen utan at nokon rører brannmuren.
Test transporten før pålogging
Skil tilgjenge frå autentisering. Ein lyttar på TCP 445 beviser at ein teneste er bunden til porten; det beviser ikkje at ein ekstern pakke kan nå han. Ei fullført TCP-tilkopling seier på si side enno ingenting om oppsett av SMB-økta eller delingstillatingar. Test handtrykket frå begge sider før du redigerer ein regel.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailed
Den første kommandoen rapporterer om eit TCP-handtrykk lukkast frå maskina du køyrer han på, og den andre legg til den oppslåtte adressa og grensesnittdetaljar. Køyr han frå VPN-klienten og frå ein kontordatamaskin, og samanlikn. Ping svarar ikkje på nokon av spørsmåla, fordi ICMP kan vere blokkert medan SMB er open, eller tillaten medan brannmuren droppar 445.
Viss handtrykket mislukkast berre frå VPN, er kjeldeomfanget hovudmistenkt. Viss det lukkast og delinga framleis nektar deg, gå til diagnose av SMB-økt og tillatingar i staden for å redigere brannmurreglar.
Når kjelde-NAT fjernar skilnaden
Med omsetjing i banen kan ikkje serveren skilje enkelte VPN-klientar frå kvarandre etter adresse. Kvar ekstern brukar kjem inn som gatewayen. Kvar autorisasjon som er avhengig av å skilje dei, må handhevast der identitetane deira framleis er synlege, som vanlegvis tyder VPN-konsentratoren eller ein autentiserande proxy. Brannmurregelen kan sleppe inn trafikk; han kan ikkje gjenopprette ein skilnad som omsetjinga fjerna.
Når den gatewayadressa er tillaten, vert kvar ekstern brukar registrert under éi enkel adresse, slik at regelen gjev heile poolen til alle som kan nå gatewayen. Viss eit vedtak per brukar er viktig, hald dei opphavlege adressene synlege eller flytt vedtaket til eit lag som framleis kjenner brukaren. Elles arvar kvar ekstern brukar tillatingane til den eine adressa serveren kan sjå, og revisjonssporet kan ikkje skilje dei etterpå. Det er eit designvedtak, ikkje ein brannmurdetalj.
Vel medvite mellom dei to designa. Avgrens regelen til den verkelege VPN-poola når serveren må sjå kven som kopla til, og godta den omsette banen berre når serveren verkeleg ikkje treng den informasjonen. Noter det valde kjeldeområdet ved sida av regelen, fordi neste person som feilsøkjer dette, vil sjå på adressetabellen først.