Always On VPN ಎಂಬುದು LAN ಪ್ರವೇಶವಲ್ಲ: ಸಂಪನ್ಮೂಲ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ

Always On ಒಂದು ಸಂಪರ್ಕದ ಜೀವನಚಕ್ರ: ಪ್ರೊಫೈಲ್ ಸೈನ್-ಇನ್ ಸಮಯದಲ್ಲಿ ಅಥವಾ ಅದಕ್ಕೂ ಮೊದಲು ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರು ಏನನ್ನೂ ಒತ್ತದೆಯೇ ಮತ್ತೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ. ಇದರರ್ಥ ಪ್ರತಿ ಖಾಸಗಿ ಗಮ್ಯಸ್ಥಾನ, ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಅನುಮತಿ ಇದೆ ಎಂದಲ್ಲ. ನಿಜವಾದ ಪ್ರಶ್ನೆ ಎಂದರೆ ನಿಯೋಜಿತ ಪ್ರೊಫೈಲ್ ವಾಸ್ತವವಾಗಿ ಯಾವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ತಲುಪಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಉತ್ತರಕ್ಕೆ Connected ಬ್ಯಾಡ್ಜ್ ನೋಡುವ ಬದಲು ಪ್ರತಿ ಸಂಪನ್ಮೂಲದ ಪರಿಶೀಲನೆ ಬೇಕು.

ಹಂತ 1: ಪರೀಕ್ಷಿಸುವ ಮೊದಲು ಸಂಪನ್ಮೂಲವನ್ನು ಬರೆಯಿರಿ

ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಒಂದು ಸಣ್ಣ ದಾಖಲೆ ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ಮೌಲ್ಯಗಳು ನಿಜವಾದ ಪರಿಸರದಿಂದ ಬರಲಿ: ಹೆಸರು, ಗಮ್ಯಸ್ಥಾನದ ಪೂರ್ವಪ್ರತ್ಯಯ, ಸೇವೆ ಮತ್ತು ಪೋರ್ಟ್, ಸುರಂಗದ ಪಾತ್ರ, ಗುರುತಿನ ಗುಂಪು ಮತ್ತು ಪರಿಹಾರಕದ ಮಾರ್ಗ.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

ದಾಖಲೆ ನಾಲ್ಕು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಮಾರ್ಗವು ವಿಳಾಸ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; DNS ನೀತಿ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ಸಂಚಾರ ಫಿಲ್ಟರ್ ಆ ಸಂಚಾರ ಸಂಪರ್ಕವನ್ನು ಬಳಸಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ; ಗಮ್ಯಸ್ಥಾನದ ಫೈರ್‌ವಾಲ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನುಮತಿಗಳು ವಿನಂತಿ ಸ್ವೀಕೃತವಾಗುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸಂಪರ್ಕಗೊಂಡ ಸುರಂಗದಿಂದ ಬರುವುದಿಲ್ಲ.

ಹಂತ 2: ಯಾವ ಸುರಂಗವು ಅದನ್ನು ಸಾಗಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ

Windows Always On VPN ನಲ್ಲಿ ಸಾಧನ ಸುರಂಗ ಮತ್ತು ಬಳಕೆದಾರ ಸುರಂಗ ಇವೆ, ಅವು ಪ್ರತ್ಯೇಕ ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು ವ್ಯಾಪ್ತಿಗಳೊಂದಿಗೆ ಪ್ರತ್ಯೇಕ ಪ್ರೊಫೈಲ್‌ಗಳಾಗಿ ಸಂರಚಿಸಲಾಗುತ್ತವೆ. ಸಾಧನ ಸುರಂಗ ಸಾಮಾನ್ಯವಾಗಿ ಸೈನ್-ಇನ್‌ಗೆ ಮೊದಲು ಬೇಕಾದ ಮೂಲಸೌಕರ್ಯವನ್ನು ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ನಿರ್ವಹಣೆ ಮತ್ತು ಡೊಮೇನ್ ಸೇವೆಗಳು; ಉದ್ಯೋಗಿಗಳ ವಿಶಾಲ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರವೇಶ ಬಳಕೆದಾರ ಸುರಂಗಕ್ಕೆ ಸೇರುತ್ತದೆ.

ಸಂಚಾರ ಫಿಲ್ಟರ್‌ಗಳು ಸಾಧನ ಸುರಂಗದ ವೈಶಿಷ್ಟ್ಯ, ಆದ್ದರಿಂದ Microsoft ನ ಉದಾಹರಣೆ ಅವನ್ನು ನಿರ್ವಹಣಾ ಸಂಚಾರಕ್ಕೆ ಬಳಸುತ್ತದೆ. ಆ ಉದಾಹರಣೆಯನ್ನು ಸಾಮಾನ್ಯ ಸಂಪನ್ಮೂಲ ಪ್ರೊಫೈಲ್‌ಗೆ ನಕಲಿಸಿದರೆ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಆದರೆ ತಪ್ಪು ಗುಂಪನ್ನು ಸಾಗಿಸುವ ಸುರಂಗ ಸಿಗುತ್ತದೆ. Get-VpnConnection ನಿಂದ ಸಕ್ರಿಯ ಸಂಪರ್ಕವನ್ನು ಖಚಿತಪಡಿಸಿ ಮತ್ತು ಅದೇ ಸಂಪರ್ಕದ ಅಡಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ.

ಹಂತ 3: ನಿಜವಾದ ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ

ಹೆಸರನ್ನು ಒಮ್ಮೆ ಪರಿಹರಿಸಿ, ನಂತರ ಮಾರ್ಗವನ್ನು ನೋಡಿ: Find-NetRoute -RemoteIPAddress 10.20.5.10 ಆಯ್ಕೆಯಾದ ಇಂಟರ್ಫೇಸ್, ಮುಂದಿನ ಹಾಪ್ ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಆಗಿದ್ದರೆ, ಪೂರ್ವಪ್ರತ್ಯಯ ಸುರಂಗದ ಮಾರ್ಗ ಗುಂಪಿನಲ್ಲಿ ಇಲ್ಲ ಅಥವಾ ಕ್ಲೈಂಟ್ ವಿಭಜಿತ ಸುರಂಗದಿಂದ ಹೊರಗಿಟ್ಟಿದೆ. ಸ್ಥಳೀಯ ಮಾರ್ಗ ಸೇರಿಸುವ ಬದಲು ಪ್ರೊಫೈಲ್ ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಸ್ಥಳೀಯ route add ಪರೀಕ್ಷೆಯನ್ನು ಉತ್ತೀರ್ಣಗೊಳಿಸಿ ಮುಂದಿನ ನೀತಿ ನವೀಕರಣದಲ್ಲಿ ಮಾಯವಾಗಬಹುದು, ಆದ್ದರಿಂದ ಬದಲಾವಣೆ ನಿರ್ವಹಿತ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಇರಬೇಕು. ಬಳಕೆದಾರ ಮತ್ತು ಸಾಧನ ಎರಡೂ ಪ್ರೊಫೈಲ್‌ಗಳಲ್ಲಿ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಪರಿಶೀಲಿಸಿ, ವಿಭಜಿತ ಸುರಂಗದ ಸೆಟ್ಟಿಂಗ್ ಕೂಡ ನೋಡಿ: ಪೂರ್ಣ ಸುರಂಗಕ್ಕೆ ಪ್ರತಿ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೂ ಮಾರ್ಗ ಬೇಕಿಲ್ಲ, ವಿಭಜಿತ ಸುರಂಗಕ್ಕೆ ಸಾಗಿಸುವ ಪ್ರತಿ ಖಾಸಗಿ ಪೂರ್ವಪ್ರತ್ಯಯಕ್ಕೂ ಒಂದು ಬೇಕು.

ಹಂತ 4: ಖಾಸಗಿ ಹೆಸರುಗಳ ಪರಿಹಾರವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

ಖಾಸಗಿ ಹೆಸರುಗಳಿಗೆ ತಮ್ಮದೇ ನೀತಿ ಮಾರ್ಗವಿದೆ. ಪ್ರೊಫೈಲ್ NRPT ನಿಯಮಗಳು ಮತ್ತು DNS ಪ್ರತ್ಯಯ ಹುಡುಕಾಟ ಪಟ್ಟಿಯನ್ನು ತಲುಪಿಸಬಹುದು, ಅವು ಸುರಂಗ ಇರುವವರೆಗೆ ಮಾನ್ಯ. Get-DnsClientNrptPolicy ನಿಂದ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನನ್ನು ಪಡೆದಿದೆ ಎಂದು ಓದಿ, ನಂತರ ಅದೇ ಅಧಿವೇಶನದಲ್ಲಿ ಹೆಸರು ಮತ್ತು ವಿಳಾಸವನ್ನು ಪರೀಕ್ಷಿಸಿ. ವಿಳಾಸಗಳು ಕೆಲಸ ಮಾಡುವಾಗ ಹೆಸರುಗಳು ವಿಫಲವಾದರೆ ಪರಿಹಾರಕ; ಎರಡೂ ವಿಫಲವಾದರೆ ಮಾರ್ಗ.

ಹೆಸರು ಸುರಂಗದ ಮಾರ್ಗಗಳ ಹೊರಗಿನ ವಿಳಾಸಕ್ಕೂ ಪರಿಹರಿಸಬಹುದು, ಇದು ಯಶಸ್ಸು ಮತ್ತು ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಮಿಶ್ರಣ ಮಾಡುತ್ತದೆ. ಹಿಂತಿರುಗಿದ ವಿಳಾಸವನ್ನು ನಿಮ್ಮ ದಾಖಲೆಯ ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಹೋಲಿಸಿ; ಬೇರೆಯಾಗಿದ್ದರೆ ಖಾಸಗಿ ವಲಯವು ಸಾರ್ವಜನಿಕ ಅಥವಾ ಪರ್ಯಾಯ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತಿದೆ ಮತ್ತು ಹೊಂದಿಕೆಯಾದ ಮಾರ್ಗ ವಿನ್ಯಾಸ ಮಾಡಿದ ಮಾರ್ಗವಲ್ಲ.

ಹಂತ 5: ಫಿಲ್ಟರ್, ಗುರುತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ದ್ವಾರವನ್ನು ಪರಿಶೀಲಿಸಿ

ಸಂಚಾರ ಫಿಲ್ಟರ್‌ಗಳು ಯಾವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳು ಸಾಧನ ಸುರಂಗವನ್ನು ಬಳಸಬಹುದು ಎಂದು ಮಿತಿಗೊಳಿಸುತ್ತವೆ, ಮತ್ತು ಸಣ್ಣ ಗುಂಪು ಮಾರ್ಗ ಸಾಗಿಸುತ್ತಿದ್ದ ಸಂಪನ್ಮೂಲವನ್ನು ತಡೆಯಬಹುದು. ಪ್ರೊಫೈಲ್ ಸಂಪರ್ಕವನ್ನು ಗುಂಪಿಗೆ ನಿಗದಿಪಡಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪನ್ಮೂಲಕ್ಕೆ ತನ್ನದೇ ಅಧಿಕಾರವಿದೆ: ಸಂಪರ್ಕಿಸಬಲ್ಲ ಬಳಕೆದಾರನನ್ನು ಕಡತ ಸರ್ವರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.

ನಿರ್ವಹಿತ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅದರ ಮಾಲೀಕರ ಮೂಲಕ ಬದಲಿಸಿ, ಅದು Intune ಆಗಿರಲಿ, ProfileXML ನಿಯೋಜನೆ ಅಥವಾ ಕಾರ್ಯಾಚರಣೆ ಸ್ಕ್ರಿಪ್ಟ್ ಆಗಿರಲಿ, ನಂತರ ಸಾಮಾನ್ಯ ಮರುಸಂಪರ್ಕದ ನಂತರ ಮತ್ತು ಮರುಬೂಟ್ ನಂತರ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ: ಸಾಮಾನ್ಯ ವೈಫಲ್ಯ ಹಳೆಯ ಸ್ಥಳೀಯ ಮಾರ್ಗ ಅಥವಾ ಒಮ್ಮೆ ಮಾತ್ರ ಅನ್ವಯಿಸಿದ ಪ್ರೊಫೈಲ್. ಪ್ರೊಫೈಲ್ ಆವೃತ್ತಿಯನ್ನು ಪರೀಕ್ಷಾ ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ಇಡಿ.