ಫೈರ್‌ವಾಲ್ ಪ್ರೊಫೈಲ್‌ಗಳು ಮತ್ತು VPN ಇಗ್ರೆಸ್: ಸಾರ್ವಜನಿಕ ಏಕೆ ಮಾರ್ಗವಲ್ಲ
ಫೈರ್‌ವಾಲ್ ಪ್ರೊಫೈಲ್ ಯಾವ ನಿಯಮ ಗುಂಪು ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಪ್ಯಾಕೆಟ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೋಯಿತು ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಸ್ಪಷ್ಟ ಬ್ಲಾಕ್ ಸಣ್ಣ ಅನುಮತಿಗಿಂತ ಮೇಲುಗೈ ಸಾಧಿಸುತ್ತದೆ.
ನಿಯಮ ನಿಖರವಾಗಿ ಕೇಳಿಸುತ್ತದೆ: ಖಾಸಗಿ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಸಂಚಾರಕ್ಕೆ ಮತ್ತು ಸಾರ್ವಜನಿಕದಲ್ಲಿ VPN ಸಂಚಾರಕ್ಕೆ ಮಾತ್ರ ಅನುಮತಿ ನೀಡು. ಆದರೆ ಹಾಗಲ್ಲ, ಏಕೆಂದರೆ ನೆಟ್‌ವರ್ಕ್ ಪ್ರೊಫೈಲ್ ಯಾವ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಗುಂಪು ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಯಾವ ಅಡಾಪ್ಟರ್ ಮೂಲಕ ಹೋಯಿತು ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ಹೆಸರನ್ನು ಮಾರ್ಗದ ಅಗತ್ಯವೆಂದು ಪರಿಗಣಿಸುವುದು, ಮಿತವಾದ ಇಗ್ರೆಸ್ ವಿನ್ಯಾಸವನ್ನು ಪೂರ್ಣಗೊಳ್ಳದಿದ್ದರೂ ಪೂರ್ಣವೆಂದು ಕಾಣಿಸುವ ತಪ್ಪು.
ಮೊದಲು ಹರಿವುಗಳನ್ನು ಬರೆಯಿರಿ, ನಂತರ ಪ್ರತಿಯೊಂದನ್ನು ನಿಜವಾಗಿ ಜಾರಿಗೊಳಿಸಬಲ್ಲ ಕಾರ್ಯವಿಧಾನ ಯಾವುದೆಂದು ನಿರ್ಧರಿಸಿ. ಆ ಹರಿವು ಪಟ್ಟಿಯೇ ಮುಂದಿನ ನಿಯಮ ಬದಲಾವಣೆಯನ್ನು ದಾಟಿ ಉಳಿಯುವ ಏಕೈಕ ಕಲಾಕೃತಿ.
ವರ್ಗವು ನಿಯಮಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮಾರ್ಗಗಳನ್ನಲ್ಲ
Windows ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ ಅಥವಾ ಖಾಸಗಿ ಎಂದು ವರ್ಗೀಕರಿಸಿದಾಗ, ಫೈರ್‌ವಾಲ್ ಆ ಪ್ರೊಫೈಲ್‌ಗಾಗಿ ಸಂರಚಿಸಿದ ನಿಯಮ ಗುಂಪನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ. ವರ್ಗೀಕರಣವು ಅಡಾಪ್ಟರ್ ಸೇರಿದ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ, ಮತ್ತು ನಿಯಮ ಗುಂಪು ಅದರ ಮೇಲೆ ಏನು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಸಂಗತಿಗಳಲ್ಲಿ ಯಾವುದೂ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಚಾರ ಟನೆಲ್ ಬಳಸಿತೇ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ. ಆ ಸ್ವಾತಂತ್ರ್ಯವೇ ಇಡೀ ಕಷ್ಟ.
ಮಾರ್ಗದ ಆಯ್ಕೆಯನ್ನು ರೂಟಿಂಗ್ ಮಾಡುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ಮೆಟ್ರಿಕ್ ಮತ್ತು ಟನೆಲ್ ಸ್ಥಾಪಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ ಮೂಲಕ. ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಸಾರ್ವಜನಿಕ ಎಂದು ಲೇಬಲ್ ಆಗಿರಬಹುದು, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕ ಭೌತಿಕ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಹೇಗಿದ್ದರೂ ಸಾರ್ವಜನಿಕ ನಿಯಮ ಗುಂಪು ಅನ್ವಯವಾಯಿತು ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.
ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್‌ಗೆ ಸೀಮಿತವಾದ ನಿಯಮ ಕೇವಲ-ಟನೆಲ್ ಎಂದು ಅರ್ಥವಾಗಲಾರದು. ಈ ಎರಡು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಬೇರೆ ಬೇರೆ ಘಟಕಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ ಮತ್ತು ಒಂದು ಇನ್ನೊಂದರ ಜಾಗ ತೆಗೆದುಕೊಳ್ಳಲಾರದು.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
ಸ್ಪಷ್ಟ ಬ್ಲಾಕ್ ಸಣ್ಣ ಅನುಮತಿಗಿಂತ ಮೇಲುಗೈ ಸಾಧಿಸುತ್ತದೆ
Microsoft ನ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಮಾರ್ಗದರ್ಶನವು ಡೀಫಾಲ್ಟ್ ಬ್ಲಾಕ್ ಕ್ರಿಯೆಗೆ ಅನುಮತಿಯ ವಿನಾಯಿತಿ ಮತ್ತು ಅನುಮತಿಗೆ ವಿರುದ್ಧವಾಗುವ ಸ್ಪಷ್ಟ ಬ್ಲಾಕ್ ನಡುವೆ ವ್ಯತ್ಯಾಸ ಮಾಡುತ್ತದೆ. ಸ್ಪಷ್ಟ ಬ್ಲಾಕ್‌ಗಳು ಆ ಸಂಘರ್ಷದಲ್ಲಿ ಗೆಲ್ಲುತ್ತವೆ, ಮತ್ತು ಔಟ್‌ಬೌಂಡ್ ನಿಯಮಗಳು ಅದೇ ಆದ್ಯತೆಯನ್ನು ಪಾಲಿಸುತ್ತವೆ.
ಆದ್ದರಿಂದ ಎಲ್ಲವನ್ನೂ ಬ್ಲಾಕ್ ಮಾಡುವ ನಿಯಮ ಸೇರಿಸಿ ಅದರ ಮೇಲೆ ಇರಿಸಿದ ಸಣ್ಣ ಅನುಮತಿಯನ್ನು ನಂಬುವ ಜನಪ್ರಿಯ ವಿಧಾನವು ಅದರ ಲೇಖಕರು ನಿರೀಕ್ಷಿಸಿದ್ದನ್ನು ಮಾಡುವುದಿಲ್ಲ. Windows Firewall ಆಡಳಿತಗಾರ ನಿಗದಿಪಡಿಸಿದ ನಿಯಮ ಕ್ರಮದಿಂದ ಸಂಘರ್ಷವನ್ನು ಬಗೆಹರಿಸುವುದಿಲ್ಲ. ಬ್ಲಾಕ್ ಸರಳವಾಗಿ ಅನ್ವಯವಾಗುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಸಮಯ ಮೀರಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ವಿನಾಯಿತಿಯಂತೆ ಕಾಣುತ್ತಿದ್ದ ನಿಯಮ ಎಂದಿಗೂ ಆಟದಲ್ಲಿರಲಿಲ್ಲ.
ಬೆಂಬಲಿತ ರೂಪವೆಂದರೆ ಅನುಮೋದಿತ ಅನುಮತಿ ನಿಯಮಗಳೊಂದಿಗೆ ಡೀಫಾಲ್ಟ್-ನಿರಾಕರಣೆ ನೀತಿ, ಅಲ್ಲಿ ಪ್ರತಿ ಅನುಮತಿಯೂ ಪ್ರೋಗ್ರಾಂ, ಸೇವೆ ಅಥವಾ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪರಿಶೀಲಿಸಲು ಸಾಕಷ್ಟು ನಿಖರವಾಗಿ ಹೆಸರಿಸುತ್ತದೆ. ಆ ವಿನ್ಯಾಸವು ಲೆಕ್ಕಪರಿಶೋಧನೆಯನ್ನು ತಾಳಿಕೊಳ್ಳುತ್ತದೆ, ಏಕೆಂದರೆ ಪ್ರತಿ ವಿನಾಯಿತಿಯೂ ಗೋಚರವಾಗಿರುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸೃಷ್ಟಿಸಿದ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ.
ಪರಸ್ಪರ ವಿರೋಧಿಸುವ ಎರಡು ನಿಯಮಗಳು ಒಂದು ನಿಯಮಕ್ಕಿಂತ ಕೆಟ್ಟವು, ಏಕೆಂದರೆ ಪರಿಣಾಮದ ವರ್ತನೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸರಿ ಮತ್ತು ವಿವರಿಸಲಾಗದ್ದು.
ಔಟ್‌ಬೌಂಡ್ ನೀತಿಗೆ ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ನೀಡಿ
ಬೆಂಬಲಿತ VPN ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ತನ್ನದೇ ಬ್ಲಾಕಿಂಗ್ ವರ್ತನೆ ಮತ್ತು ತನ್ನದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ ವಿನಾಯಿತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಸಮನ್ವಯವಿಲ್ಲದ ಕೈಯಿಂದ ಮಾಡಿದ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವುದು ಆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸೆಟಪ್‌ಗೆ ಬೇಕಾದ ಟನೆಲ್‌ನ ಹೊರಗೆ ಬಿಡಬಹುದು, ಅಥವಾ ಯಾರೂ ಗಮನಿಸದ ಎರಡನೇ ಮಾರ್ಗವನ್ನು ತೆರೆದಿಡಬಹುದು.
ನಿಯಮ ಬರೆಯುವ ಮೊದಲು ಔಟ್‌ಬೌಂಡ್ ನೀತಿ ಯಾರಿಗೆ ಸೇರಿದ್ದು ಎಂದು ನಿರ್ಧರಿಸಿ: ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಸಂರಚನೆ, ನಿರ್ವಹಿತ ಫೈರ್‌ವಾಲ್ ನೀತಿ, ಅಥವಾ ಮಾಲೀಕರೊಂದಿಗೆ ದಾಖಲಿಸಿದ ಸ್ಥಳೀಯ ವಿನಾಯಿತಿ ಪಟ್ಟಿ. ನಂತರ ಏನಾದರೂ ಸಂಪರ್ಕಗೊಳ್ಳುವವರೆಗೆ ಪ್ರಯೋಗಗಳನ್ನು ಒಟ್ಟುಗೂಡಿಸುವ ಬದಲು ಪದರಗಳನ್ನು ಸಮನ್ವಯಗೊಳಿಸಿ. ಹೆಸರಿಸಿದ ಮಾಲೀಕರೇ ಎರಡು ಪದರಗಳು ಒಪ್ಪದಿದ್ದಾಗ ಕೇಳುವ ವ್ಯಕ್ತಿ.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮರುಪ್ರಾಪ್ತಿ ಚಾನಲ್ ಉಳಿಸಿಕೊಳ್ಳಿ. ತನ್ನದೇ ನಿರ್ವಹಣಾ ಮಾರ್ಗದಿಂದ ಹೊರಗೆ ಲಾಕ್ ಆದ ದೂರದ ಯಂತ್ರವು ನೀವು ಮುಚ್ಚುತ್ತಿದ್ದ ನೀತಿ ಅಂತರಕ್ಕಿಂತ ಕೆಟ್ಟ ಫಲಿತಾಂಶ. ಮರುಪ್ರಾಪ್ತಿ ನಿಯಮವನ್ನು ಮುಂಚಿತವಾಗಿ ಬರೆದಿಟ್ಟರೆ ಅದನ್ನು ಸಮರ್ಥಿಸುವುದು ಸುಲಭ, ಮತ್ತು ಯಾರಿಗೂ ಇಷ್ಟವಿಲ್ಲದ ಗಂಟೆಯಲ್ಲಿ ಬದಲಾವಣೆ ತಪ್ಪಾದರೆ ಅದನ್ನು ಹುಡುಕುವುದೂ ಸುಲಭ.
ಲೇಬಲ್ ಓದುವ ಬದಲು ನಾಲ್ಕು ಫಲಿತಾಂಶಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ
ನೀತಿ ಎಷ್ಟು ಪ್ರಕರಣಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆಯೋ ಅಷ್ಟೇ ಉತ್ತಮ, ಆದ್ದರಿಂದ ಪ್ರೊಫೈಲ್ ಲೇಬಲ್ ಅನ್ನು ಫಲಿತಾಂಶವಲ್ಲದೆ ಆರಂಭಿಕ ಬಿಂದುವೆಂದು ಪರಿಗಣಿಸಿ. ನಾಲ್ಕು ಫಲಿತಾಂಶಗಳು ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತವೆ: ಉದ್ದೇಶಿತ LAN ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಒಳಗೊಂಡ ಇಂಟರ್ನೆಟ್ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ನಿಷೇಧಿತ ನೇರ ವಿನಂತಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ವೈಫಲ್ಯದ ಪ್ರಕರಣವು ಸದ್ದಿಲ್ಲದೆ ಹಿಂಜರಿಯುವ ಬದಲು ವಿನ್ಯಾಸದಂತೆ ವರ್ತಿಸುತ್ತದೆ. ನಾಲ್ಕು ಫಲಿತಾಂಶಗಳನ್ನು ನಿಯಮ ಬದಲಾವಣೆಯ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ. ನಾಲ್ಕು ಹೆಸರಿಸಿದ ಪ್ರಕರಣಗಳ ಪರೀಕ್ಷಾ ಯೋಜನೆ ಪ್ರತಿ ಬಾರಿ ಚಲಾಯಿಸಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದು ಮತ್ತು ಗಟ್ಟಿಯಾಗಿ ವಿಫಲವಾಗಲು ಸಾಕಷ್ಟು ನಿರ್ದಿಷ್ಟ.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
ಮೊದಲ ಆಜ್ಞೆ ಪ್ರತಿ ಸಂಪರ್ಕಿತ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹೇಗೆ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಅದು ಹಲವು ಬಾರಿ ನಿಯಮ ಬರೆದವರು ಊಹಿಸಿದ್ದಲ್ಲ. ಎರಡನೆಯದು ಪ್ರತಿ ಪ್ರೊಫೈಲ್‌ನ ಡೀಫಾಲ್ಟ್ ಕ್ರಿಯೆಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಮೂರನೆಯದು ಸಕ್ರಿಯ ಔಟ್‌ಬೌಂಡ್ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಸಣ್ಣ ಅನುಮತಿಯನ್ನು ಸದ್ದಿಲ್ಲದೆ ರದ್ದುಗೊಳಿಸುವವುಗಳೂ ಸೇರಿದಂತೆ.
ನೆಟ್‌ವರ್ಕ್ ಬದಲಾವಣೆಯ ನಂತರ ನಾಲ್ಕು ಪ್ರಕರಣಗಳನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಯಂತ್ರ ಬೇರೆ ನೆಟ್‌ವರ್ಕ್ ಸೇರಿದಾಗ ಪ್ರೊಫೈಲ್ ಮರು ವರ್ಗೀಕರಣಗೊಳ್ಳಬಹುದು. ಹೊಂದಿಕೆಯಾಗುವ ಪ್ರೊಫೈಲ್ ಲೇಬಲ್ ಮಾರ್ಗ ನೀವು ಉದ್ದೇಶಿಸಿದ್ದು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.