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ಮೊದಲ ಆಜ್ಞೆಯು ಫೈಲ್ ಹಂಚಿಕೆ ನಿಯಮಗಳಿಗೆ ಲಗತ್ತಿಸಲಾದ ವಿಳಾಸ ಫಿಲ್ಟರ್ಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಯಾವ ಪ್ರೊಫೈಲ್ಗಳು ಸಕ್ರಿಯವಾಗಿವೆ ಮತ್ತು ಹೊಂದಿಕೆಯಾಗದ ಒಳಬರುವ ಸಂಚಾರವನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. Blocking ನಿಯಮ ಮತ್ತು ಕೇಂದ್ರೀಯವಾಗಿ ನಿರ್ವಹಿಸಲಾದ ನೀತಿಯನ್ನು ಸಹ ನೋಡಿ. Block ನಿಯಮಗಳು ಅನುಮತಿ ನಿಯಮಗಳಿಗಿಂತ ಆದ್ಯತೆ ಪಡೆಯುತ್ತವೆ, ಮತ್ತು ಸ್ಥಳೀಯ ನಿಯಮ ವಿಲೀನವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ನೀತಿಯು ಹೊಸ ಸ್ಥಳೀಯ ವಿನಾಯಿತಿಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು.
ನಿಯಮವು ಕನ್ಸೋಲ್ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಸಂಚಾರದ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂಬುದು ಇದೇ ಸಂದರ್ಭ. ಅದೇ ಸಮಯದಲ್ಲಿ ಪ್ರೊಫೈಲ್ ನಿಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಬೇರೆ ನೆಟ್ವರ್ಕ್ಗೆ ಸೇರಿದ ಲ್ಯಾಪ್ಟಾಪ್ ಯಾರೂ ಫೈರ್ವಾಲ್ಗೆ ತಾಕದೆಯೇ 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 ಪೂಲ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ಸರ್ವರ್ಗೆ ಆ ಮಾಹಿತಿ ನಿಜವಾಗಿಯೂ ಬೇಡವಾದಾಗ ಮಾತ್ರ ಅನುವಾದಿತ ಮಾರ್ಗವನ್ನು ಸ್ವೀಕರಿಸಿ. ಆಯ್ಕೆಮಾಡಿದ ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ನಿಯಮದ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಇದನ್ನು ಡೀಬಗ್ ಮಾಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಮೊದಲು ವಿಳಾಸ ಕೋಷ್ಟಕವನ್ನು ನೋಡುತ್ತಾನೆ.