VPN ಮೂಲಕ ರಿಮೋಟ್ ಡೆಸ್ಕ್ಟಾಪ್: ನೀವು ಯಾವ ವೈಫಲ್ಯದಲ್ಲಿದ್ದೀರಿ?
ಟನೆಲ್ ನಿಮಗೆ ಮಾರ್ಗ ನೀಡುತ್ತದೆ; ಡೆಸ್ಕ್ಟಾಪ್ ಸೇವೆ ಇನ್ನೂ ನಿಮ್ಮನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. ಹೆಸರಿನ ಪರಿಹಾರ, TCP ತಲುಪುವಿಕೆ, ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ ಮತ್ತು ಲಾಗಿನ್ ಅನ್ನು ಬೇರ್ಪಡಿಸಿ.
ನಿಮ್ಮ ಟನೆಲ್ ಮೇಲಿದೆ, ಒಳಾಂಗಣ ವಿಕಿ ಲೋಡ್ ಆಗುತ್ತದೆ, ಆದರೆ ರಿಮೋಟ್ ಡೆಸ್ಕ್ಟಾಪ್ ಇನ್ನೂ ಸಂಪರ್ಕಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಈ ಸಂಯೋಜನೆ ಸಾಮಾನ್ಯ, ಏಕೆಂದರೆ VPN ಹೋಸ್ಟ್ಗೆ ಮಾರ್ಗ ನೀಡುತ್ತದೆ, ಆದರೆ ಡೆಸ್ಕ್ಟಾಪ್ ಸೇವೆ ಕೇಳಬೇಕು, ತನ್ನದೇ ಫೈರ್ವಾಲ್ನಿಂದ ಅನುಮತಿಸಲ್ಪಡಬೇಕು ಮತ್ತು ಖಾತೆಯನ್ನು ದೃಢೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿರಬೇಕು. ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಮತ್ತು ಬಳಸಬಹುದಾದ ಸೆಷನ್ ನಡುವೆ ನಾಲ್ಕು ವೈಫಲ್ಯ ಹಂತಗಳಿವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಸಂದೇಶದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಮೊದಲು ಸಂದೇಶವನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅದು ಹಂತದ ಹೆಸರು ಹೇಳುತ್ತದೆ.
ಒಂದೇ ರೀತಿ ಕಾಣುವ ನಾಲ್ಕು ವೈಫಲ್ಯಗಳು
ಹಂತಗಳು ಕ್ರಮದಲ್ಲಿವೆ: ಹೆಸರು ವಿನ್ಯಾಸ ಉದ್ದೇಶಿಸಿದ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಪೋರ್ಟ್ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಹೋಸ್ಟ್ ತನ್ನದೇ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಸೆಷನ್ ಲಾಗಿನ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ. ಪ್ರತಿ ಹಂತವು ಮುಂದಿನದನ್ನು ಪರೀಕ್ಷಿಸಲಾಗದಂತೆ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನೆಟ್ವರ್ಕ್ ಸ್ಥಿರವಾಗುವ ಮೊದಲು RDP ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಿಸುವುದು ಗದ್ದಲವನ್ನು ಮಾತ್ರ ಉಂಟುಮಾಡುತ್ತದೆ. ನಾಲ್ಕೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಬಳಕೆದಾರರ ಕಡೆಯಿಂದ ಲಕ್ಷಣ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ. ಅವುಗಳನ್ನು ಬೇರ್ಪಡಿಸುವುದು ಕ್ಲೈಂಟ್ನ ಸಂದೇಶ ಮಾತ್ರ.
ಕೆಲಸ ಮಾಡುವ ಒಳಾಂಗಣ ವೆಬ್ಸೈಟ್ ನಾಲ್ಕರಲ್ಲಿ ಯಾವುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದೇ ನೆಟ್ವರ್ಕ್ನ ಹೋಸ್ಟ್ ಬೇರೆ ಪೋರ್ಟ್ನಲ್ಲಿ ಬೇರೆ ಸೇವೆಯೊಂದಿಗೆ ಉತ್ತರಿಸಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದನ್ನು ರೂಟಿಂಗ್ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಿ, ಅದಕ್ಕಿಂತ ಹೆಚ್ಚೇನೂ ಅಲ್ಲ.
ಕ್ರಮವಾಗಿ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಬರೆಯಿರಿ. ಪೋರ್ಟ್ ಉತ್ತರಿಸಿದ್ದರಿಂದ ಲಾಗಿನ್ ಪರದೆಗೆ ಹಾರುವುದು ಮೊದಲ ಹಂತವೇ ಕಂಡುಹಿಡಿದ ಫೈರ್ವಾಲ್ ಸಮಸ್ಯೆಗೆ ಪೂರ್ಣ ಮಧ್ಯಾಹ್ನವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವ ದಾರಿ.
3389 ನಲ್ಲಿ ಏನಾದರೂ ಕೇಳುತ್ತಿದೆಯೇ?
ಹೆಸರಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ತಪ್ಪು ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಮುಂದಿನ ಪ್ರತಿ ಪರೀಕ್ಷೆಯನ್ನೂ ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ. ಟನೆಲ್ನ ಪರಿಹಾರಕಕ್ಕೆ ಹೆಸರಿನ ಅರ್ಥವೇನೆಂದು ಕೇಳಿ, ನಂತರ ಉತ್ತರವನ್ನು ಯಶಸ್ವಿ ಪ್ರತಿಕ್ರಿಯೆಯೊಂದಿಗಲ್ಲ, ವಿನ್ಯಾಸ ಉದ್ದೇಶಿಸಿದ ಖಾಸಗಿ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರೇ ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆ, ಮತ್ತು ಯಾವುದೇ RDP ಬದಲಾವಣೆ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ:
nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example
ನಂತರ ಹೋಸ್ಟ್ ಅಲ್ಲ, ಪೋರ್ಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ. 3389 ನಲ್ಲಿ ಪೂರ್ಣಗೊಂಡ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ತಲುಪುವಿಕೆಯನ್ನು ಅದರ ಮೇಲಿನ ಎಲ್ಲದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ:
Test-NetConnection -ComputerName desktop.corp.example -Port 3389
ಈ ಪರೀಕ್ಷೆಯನ್ನು LAN ನಿಂದ ಮತ್ತು ಟನೆಲ್ನಿಂದ ನಡೆಸಿ, ಏಕೆಂದರೆ ಎರಡು ಫಲಿತಾಂಶಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ದೋಷವನ್ನು VPN ಮಾರ್ಗಕ್ಕೆ ಸ್ಥಳೀಕರಿಸುತ್ತದೆ. ಮಾರ್ಗದಲ್ಲಿ ಎರಡು ಫೈರ್ವಾಲ್ಗಳಿವೆ ಮತ್ತು ಅವನ್ನು ಗೊಂದಲ ಮಾಡಿಕೊಳ್ಳುವುದು ಸುಲಭ: ನೆಟ್ವರ್ಕ್ ಕ್ಲೈಂಟ್ನ ಟನೆಲ್ ವಿಳಾಸವನ್ನು ಹೋಸ್ಟ್ನತ್ತ ತಲುಪಲು ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಹೋಸ್ಟ್ನ ಸ್ವಂತ ಫೈರ್ವಾಲ್ ಅದೇ ಮೂಲವನ್ನು ಕೇಳುವ ಪೋರ್ಟ್ನಲ್ಲಿ ಅನುಮತಿಸಬೇಕು. LAN ಉಪಜಾಲಕ್ಕೆ ಸೀಮಿತವಾದ ನಿಯಮ VPN ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ದೂರಸ್ಥ ಬಳಕೆದಾರರು ಮಾತ್ರ ವರದಿ ಮಾಡುವ ಸಮಯ ಮೀರುವಿಕೆಗೆ ಇದೇ ಸಾಮಾನ್ಯ ಕಾರಣ. ನಿಯಮದ ಅಸ್ತಿತ್ವವಲ್ಲ, ಅದರ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ.
ಹಿಂತಿರುಗುವ ಮಾರ್ಗವೂ ಅದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹವಾಗಿದೆ. ಉತ್ತರಗಳಿಗೆ ಕ್ಲೈಂಟ್ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, LAN ಗೆ ಅಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್ನ ಮುಂದಿನ ಅನುವಾದ ನಿಮ್ಮ ಲಾಗ್ ತೋರಿಸುವ ಮೂಲವನ್ನು ಬದಲಿಸುತ್ತದೆ. ಪೋರ್ಟ್ ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಉತ್ತರಿಸಿ ಇನ್ನೊಂದರಲ್ಲಿ ಉತ್ತರಿಸದಿದ್ದರೆ, ಕಾಣೆಯಾದ ಅರ್ಧ ಸಾಮಾನ್ಯವಾಗಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ.
ಸಂರಚನೆಯನ್ನು ಓದುವ ಮೊದಲು ಸಂದೇಶವನ್ನು ಓದಿ
ಮೂರನೇ ಹಂತ ಹೋಸ್ಟ್ ತನ್ನದೇ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುವುದು, ಅದು ಹಲವು ಬಾರಿ ತಕ್ಷಣ ತೆರೆದು ಮುಚ್ಚುವ ಪೋರ್ಟ್ನಂತೆ ಕಾಣುತ್ತದೆ. ಏನೋ ಉತ್ತರಿಸಿತು, ಮತ್ತು ಅದು ಮೌನಕ್ಕಿಂತ ಉಪಯುಕ್ತ ಮಾಹಿತಿ. ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಂಡು ಸೆಷನ್ ತಕ್ಷಣ ಸತ್ತರೆ, ನೆಟ್ವರ್ಕ್ ಸರಿಯಾಗಿದೆ ಮತ್ತು ನಿರ್ಧಾರ ಹೋಸ್ಟ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮತ್ತೆ ನೆಟ್ವರ್ಕ್ ಮುಟ್ಟುವ ಮೊದಲು ರಿಮೋಟ್ ಡೆಸ್ಕ್ಟಾಪ್ ಅನುಮತಿಗಳನ್ನು ನೋಡಿ.
ವೈಶಿಷ್ಟ್ಯವು ಯಂತ್ರಕ್ಕೆ ಸಕ್ರಿಯವಾಗಿದ್ದರೂ ಪ್ರವೇಶ ನಿರ್ದಿಷ್ಟ ಗುಂಪುಗಳಿಗೆ ಸೀಮಿತವಾಗಿರಬಹುದು, ಮತ್ತು ಆಲಿಸುವವನು ನೀವು ಬಂದ ವಿಳಾಸವನ್ನು ಹೊರಗಿಡುವ ರೀತಿಯಲ್ಲಿ ಬಂಧಿಸಲ್ಪಡಬಹುದು. ನೆಟ್ವರ್ಕ್ ಮಟ್ಟದ ದೃಢೀಕರಣವು ಡೆಸ್ಕ್ಟಾಪ್ ಲೋಡ್ ಆಗುವ ಮೊದಲೇ ವಿಫಲವಾಗುವ ದ್ವಾರವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ದೋಷ ಪಠ್ಯ ತಪ್ಪು ಗುಪ್ತಪದದಿಂದ ಭಿನ್ನ. ಕ್ಲೈಂಟ್ನ ಸಂದೇಶವನ್ನು ಹೋಸ್ಟ್ನ ಘಟನಾ ಲಾಗ್ನೊಂದಿಗೆ ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಸಂದೇಶ ದ್ವಾರವನ್ನು ಹೇಳುತ್ತದೆ ಮತ್ತು ಲಾಗ್ ಖಾತೆಯನ್ನು.
ಸೆಷನ್ ಲಾಗಿನ್ ತನ್ನದೇ ಗಡಿ
ದೃಢೀಕರಣ ಡೆಸ್ಕ್ಟಾಪ್ ಸೇವೆಗೆ ಸೇರಿದ್ದು, VPN ಗೆ ಅಲ್ಲ. ಟನೆಲ್ನ ಗುರುತು ಮತ್ತು ಡೆಸ್ಕ್ಟಾಪ್ ಖಾತೆ ಬೇರೆ ಬೇರೆ ರುಜುವಾತುಗಳು ಬೇರೆ ಬೇರೆ ಲಾಕ್ಔಟ್ ನೀತಿಗಳೊಂದಿಗೆ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಟನೆಲ್ ನಿಮ್ಮನ್ನು ಸ್ವೀಕರಿಸಿದೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಡೆಸ್ಕ್ಟಾಪ್ ಖಾತೆಯನ್ನು ಲಾಕ್ ಮಾಡುವುದು ಟನೆಲ್ಗೆ ಭಂಗ ತರುವುದಿಲ್ಲ, ಮತ್ತು ವಿರುದ್ಧವೂ ನಿಜ.
ಎರಡನ್ನೂ ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ. ಖಾಸಗಿ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದಾಗ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಆಲಿಸುವವನನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಪ್ರಕಟಿಸುವುದು ತಲುಪುವಿಕೆಯ ದೋಷವನ್ನು ತೆರೆದ ಡೆಸ್ಕ್ಟಾಪ್ಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ ಕಾಣಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಎಚ್ಚರಿಕೆಯನ್ನು ದಾಟಲು ಸೆಷನ್ ಗುರುತು ಪರಿಶೀಲನೆಗಳನ್ನೂ ದುರ್ಬಲಗೊಳಿಸಬೇಡಿ. RDP ಆಲಿಸುವವನಲ್ಲಿ ಸ್ವಯಂ-ಸಹಿ ಪ್ರಮಾಣಪತ್ರ ವಿನ್ಯಾಸದಿಂದಲೇ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಸ್ವೀಕರಿಸುವುದು ಹೆಜ್ಜೆಯಲ್ಲ, ನಿರ್ಧಾರ.
ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಮೊದಲು ಪ್ರಯತ್ನಗಳನ್ನು ಎಣಿಸಿ. ಡೆಸ್ಕ್ಟಾಪ್ ಲಾಕ್ಔಟ್ ಮಿತಿಗಳು ವಿಫಲ ಲಾಗಿನ್ಗಳನ್ನು VPN ವೈಫಲ್ಯಗಳಿಂದ ಬೇರೆಯಾಗಿ ಎಣಿಸುತ್ತವೆ, ಮತ್ತು ಟೈಮರ್ಗೆ ಮರುಪ್ರಯತ್ನಿಸುವ ಕ್ಲೈಂಟ್ ನೀವು ಇನ್ನೂ ನಿಯಮ ಸಂಪಾದಿಸುತ್ತಿರುವಾಗ ಮಿತಿಯನ್ನು ದಾಟಬಹುದು. ಗುಪ್ತಪದ ಬದಲಾವಣೆಯ ನಂತರ ಖಾತೆಗಳನ್ನು ಲಾಕ್ ಮಾಡುವ ಅದೇ ಸಮಾನಾಂತರ ಮರುಪ್ರಯತ್ನ ಕಾರ್ಯವಿಧಾನ ಇದು.
ಸೆಷನ್ ಏನನ್ನು ಸಾಗಿಸಬಹುದು, ಮತ್ತು ಎಲ್ಲಿ ಉಳಿಯುತ್ತದೆ
ಅಗತ್ಯವಾಗುವ ಮೊದಲು ಅನುಮೋದಿತ ಸೈನ್-ಔಟ್ ಹರಿವನ್ನು ಕಲಿಯಿರಿ. ಕಿಟಕಿ ಮುಚ್ಚುವುದು ನೋಟವನ್ನು ಮಾತ್ರ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಬಹುದು, ಸೆಷನ್ ತನ್ನ ಸಂರಚಿತ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಮುಂದುವರಿಯುತ್ತದೆ, ಇದು ಹಂಚಿದ ಅಥವಾ ಲೆಕ್ಕಪರಿಶೋಧಿತ ಹೋಸ್ಟ್ನಲ್ಲಿ ಮುಖ್ಯ. ನೀತಿ ನಿರೀಕ್ಷಿಸಿದಾಗ ಸೆಷನ್ನ ಒಳಗಿನಿಂದ ಸೈನ್ ಔಟ್ ಮಾಡಿ.
ನಂತರ ಸೆಷನ್ ಏನನ್ನು ಸಾಗಿಸಬಹುದೆಂದು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಕ್ಲಿಪ್ಬೋರ್ಡ್, ಮರುನಿರ್ದೇಶಿತ ಡ್ರೈವ್ಗಳು, ಮುದ್ರಕ ಮರುನಿರ್ದೇಶನ ಮತ್ತು ಕಡತ ವರ್ಗಾವಣೆ ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರಸ್ಥ ವ್ಯವಸ್ಥೆಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಸಾಗಿಸುತ್ತವೆ. ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಚಲಿಸುವ ಪ್ರಕಟಿತ ಅಪ್ಲಿಕೇಶನ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಡೌನ್ಲೋಡ್-ಮುಕ್ತ ಗಡಿಯಲ್ಲ, ಮತ್ತು ಓದಲು-ಮಾತ್ರ ಕಾಣುವ ಸೆಷನ್ ಸಹ ಕ್ಲಿಪ್ಬೋರ್ಡ್ ಸಾಗಿಸಬಹುದು. ಸಂಪರ್ಕವಲ್ಲ, ನಿಜವಾದ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಿ: ಕಡತ ತೆರೆಯಿರಿ, ಅಪ್ಲಿಕೇಶನ್ ಬಳಸಿ ಮತ್ತು ನಿಮಗೆ ಬೇಕಾದ ಮರುನಿರ್ದೇಶನವನ್ನು ದೃಢೀಕರಿಸಿ. ಹೊರಗಿನಿಂದ ರಿಮೋಟ್ ಡೆಸ್ಕ್ಟಾಪ್ ತಲುಪುವ ಬಗ್ಗೆ Microsoft ಮಾರ್ಗದರ್ಶನ ಬೆಂಬಲಿತ ಒಡ್ಡುವಿಕೆ ಆಯ್ಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಒತ್ತಡದಲ್ಲಿ ಸೇರಿಸಿದ ಸಾರ್ವಜನಿಕ ಆಲಿಸುವವನಿಗಿಂತ ಇದು ಉತ್ತಮ ಉಲ್ಲೇಖ.