SMB ఫైర్వాల్ నియమంలో LocalSubnet VPN క్లయింట్లను కవర్ చేయదు
LocalSubnet అనుమతి నియమం సర్వర్ యొక్క స్వంత సబ్నెట్లను కవర్ చేస్తుంది, రూట్ చేసిన VPN పూల్ను కాదు. పరిధిని విస్తరించే ముందు సర్వర్ చూసే మూల చిరునామాను పోల్చండి.
కార్యాలయ డెస్క్టాప్లు షేర్ను చేరుకుంటాయి, VPN వినియోగదారులకు సమయం ముగుస్తుంది, అదే ఖాతా మొబైల్ హాట్స్పాట్ నుండి పని చేస్తుంది. షేర్ అనుమతులు అరుదుగా తేడా అవుతాయి; ఫైల్ సర్వర్కు చేరే చిరునామా సాధారణంగా తేడా. LocalSubnet వరకు పరిమితమైన నియమం సర్వర్ యొక్క స్వంత కనెక్ట్ చేయబడిన సబ్నెట్లను అనుమతిస్తుంది, విడిగా రూట్ చేసిన VPN పూల్ వాటిలో ఒకటి కాదు. రెండు డిజైన్లు ఈ అంతరాన్ని మూస్తాయి, అవి చాలా భిన్నమైన రికార్డులను వెనుక వదిలివేస్తాయి.
రెండు డిజైన్లు, ఒక లక్షణం
మొదటి డిజైన్ నియమం యొక్క రిమోట్ చిరునామా షరతుకు VPN పూల్ను జోడిస్తుంది. అప్పుడు సర్వర్ ప్రతి క్లయింట్ యొక్క టన్నెల్ చిరునామాను చూస్తుంది, కాబట్టి దాని లాగ్లు ఒక రిమోట్ వినియోగదారుని మరొకరి నుండి వేరు చేయగలవు. రెండవ డిజైన్ VPN ట్రాఫిక్ను సర్వర్ చూసే ముందు LAN చిరునామాకు అనువదించే గేట్వే ద్వారా రూట్ చేస్తుంది. అది కనెక్టివిటీని పునరుద్ధరిస్తుంది మరియు అదే దశలో భేదాన్ని తొలగిస్తుంది.
పట్టిక చిరునామాలకు బదులుగా పాత్రలను వివరిస్తుంది, ఏ వరుస వర్తిస్తుందో మీ స్వంత ప్రిఫిక్స్లు నిర్ణయిస్తాయి. బ్లాగ్ పోస్ట్ నుండి ఉదాహరణను కాపీ చేయడానికి బదులుగా సర్వర్ యొక్క నిజమైన విలువలను ముద్రించండి:
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias, IPAddress, PrefixLengthపట్టిక నిర్ణయానికి సహాయకం, ప్రతి అమలు గురించి ప్రకటన కాదు. అదనపు ఇంటర్ఫేస్లు, రెండవ సైట్ లింక్ లేదా వేరే మాస్క్ ఉన్న హోస్ట్కు వేరే స్థానిక సెట్ ఉంటుంది.
| 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 యొక్క New-NetFirewallRule సూచన రిమోట్ చిరునామా షరతులను మరియు LocalSubnet కీవర్డ్ను డాక్యుమెంట్ చేస్తుంది. కీవర్డ్ అన్ని ప్రైవేట్ చిరునామాలను సూచిస్తుందని నిర్ణయించే ముందు దాన్ని చదవండి, ఎందుకంటే అలా కాదు.
సర్వర్ నిజంగా ఏమి పొందుతుందో పోల్చండి
ఎవరో గుర్తుంచుకున్న నియమం బదులు ప్రభావవంతమైన నియమాన్ని చదవండి. అది ప్రారంభించబడిందా, క్రియాశీల ప్రొఫైల్కు వర్తిస్తుందా, దాని రిమోట్ చిరునామా షరతు సర్వర్ చూసే మూలానికి సరిపోతుందా అని తనిఖీ చేయండి. Domain ప్రొఫైల్లో మాత్రమే ప్రారంభించిన నియమం నెట్వర్క్ మార్పు తర్వాత అడాప్టర్ Publicకి మారినప్పుడు ఏమీ చేయదు.
Get-NetFirewallRule -DisplayGroup 'File and Printer Sharing' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionమొదటి ఆదేశం ఫైల్ షేరింగ్ నియమాలకు జోడించిన చిరునామా ఫిల్టర్లను ముద్రిస్తుంది, రెండవది ఏ ప్రొఫైల్లు క్రియాశీలంగా ఉన్నాయో మరియు సరిపోని ఇన్బౌండ్ ట్రాఫిక్ ఎలా నిర్వహించబడుతుందో చూపిస్తుంది. బ్లాకింగ్ నియమం మరియు కేంద్రీయంగా నిర్వహించబడే విధానాన్ని కూడా చూడండి. బ్లాక్ నియమాలు అనుమతి నియమాలపై ప్రాధాన్యత పొందుతాయి, స్థానిక నియమ విలీనాన్ని నిలిపివేసే విధానం కొత్త స్థానిక మినహాయింపును నిష్ప్రభావంగా చేయగలదు.
నియమం కన్సోల్లో సరిగ్గా కనిపించి ట్రాఫిక్పై ఎటువంటి ప్రభావం లేని సందర్భం ఇది. అదే సమయంలో ప్రొఫైల్ కేటాయింపును తనిఖీ చేయండి, ఎందుకంటే మరొక నెట్వర్క్లో చేరిన ల్యాప్టాప్ ఎవరూ ఫైర్వాల్ను తాకకుండా Public ప్రొఫైల్కు మారవచ్చు.
లాగిన్కు ముందు రవాణాను పరీక్షించండి
ప్రాప్యతను ప్రామాణీకరణ నుండి వేరు చేయండి. TCP 445లోని లిజనర్ సేవ పోర్టుకు బంధించబడిందని నిరూపిస్తుంది; రిమోట్ ప్యాకెట్ దాన్ని చేరుకోగలదని నిరూపించదు. పూర్తయిన TCP కనెక్షన్, మరోవైపు, SMB సెషన్ సెటప్ లేదా షేర్ అనుమతుల గురించి ఇంకా ఏమీ చెప్పదు. నియమాన్ని సవరించే ముందు రెండు వైపుల నుండి హ్యాండ్షేక్ను పరీక్షించండి.
Test-NetConnection -ComputerName files.corp.example -Port 445
Test-NetConnection -ComputerName files.corp.example -Port 445 -InformationLevel Detailedమొదటి ఆదేశం మీరు అమలు చేసే మెషీన్ నుండి TCP హ్యాండ్షేక్ విజయవంతమవుతుందా అని నివేదిస్తుంది, రెండవది పరిష్కరించబడిన చిరునామా మరియు ఇంటర్ఫేస్ వివరాలను జోడిస్తుంది. దాన్ని VPN క్లయింట్ నుండి మరియు కార్యాలయ డెస్క్టాప్ నుండి అమలు చేసి, తర్వాత పోల్చండి. Ping రెండు ప్రశ్నలకూ సమాధానం ఇవ్వదు, ఎందుకంటే SMB తెరిచి ఉన్నప్పుడు ICMP నిరోధించబడవచ్చు, లేదా ఫైర్వాల్ 445ని పడేసినప్పుడు అనుమతించబడవచ్చు.
హ్యాండ్షేక్ VPN నుండి మాత్రమే విఫలమైతే, మూల పరిధి ప్రధాన అనుమానితం. అది విజయవంతమై షేర్ ఇప్పటికీ నిరాకరిస్తే, ఫైర్వాల్ నియమాలను సవరించడానికి బదులుగా SMB సెషన్ మరియు అనుమతి నిర్ధారణకు వెళ్లండి.
మూల NAT భేదాన్ని తొలగించినప్పుడు
మార్గంలో అనువాదం ఉంటే, వ్యక్తిగత VPN క్లయింట్లను చిరునామా ద్వారా సర్వర్ వేరు చేయలేదు. ప్రతి రిమోట్ వినియోగదారు గేట్వేగా వస్తారు. వారిని వేరు చేయడంపై ఆధారపడే ఏ అధికారమైనా వారి గుర్తింపులు ఇంకా కనిపించే చోట అమలు చేయాలి, అంటే సాధారణంగా VPN కన్సంట్రేటర్ లేదా ప్రామాణీకరించే ప్రాక్సీ. ఫైర్వాల్ నియమం ట్రాఫిక్ను అనుమతించగలదు; అనువాదం తొలగించిన భేదాన్ని అది పునరుద్ధరించలేదు.
ఆ గేట్వే చిరునామా అనుమతించబడిన తర్వాత, ప్రతి రిమోట్ వినియోగదారు ఒకే చిరునామా కింద నమోదు చేయబడతారు, కాబట్టి గేట్వేను చేరుకోగల ఎవరికైనా నియమం మొత్తం పూల్ను ఇస్తుంది. వినియోగదారు వారీగా నిర్ణయం ముఖ్యమైతే, అసలు చిరునామాలను కనిపించేలా ఉంచండి లేదా నిర్ణయాన్ని ఇంకా వినియోగదారుని తెలిసిన పొరకు తరలించండి. లేకపోతే ప్రతి రిమోట్ వినియోగదారు సర్వర్ చూడగల ఒకే చిరునామా యొక్క అనుమతులను వారసత్వంగా పొందుతారు, ఆడిట్ ట్రైల్ తర్వాత వారిని వేరు చేయలేదు. అది డిజైన్ నిర్ణయం, ఫైర్వాల్ వివరం కాదు.
రెండు డిజైన్ల మధ్య ఉద్దేశపూర్వకంగా ఎంచుకోండి. ఎవరు కనెక్ట్ అయ్యారో సర్వర్ చూడాల్సి వచ్చినప్పుడు నియమాన్ని నిజమైన VPN పూల్కు పరిమితం చేయండి, సర్వర్కు ఆ సమాచారం నిజంగా అవసరం లేనప్పుడు మాత్రమే అనువదించబడిన మార్గాన్ని అంగీకరించండి. ఎంచుకున్న మూల పరిధిని నియమం పక్కన నమోదు చేయండి, ఎందుకంటే దీన్ని డీబగ్ చేసే తదుపరి వ్యక్తి మొదట చిరునామా పట్టికను చూస్తారు.