IP ವಿಳಾಸದೊಂದಿಗೆ ದೋಷ 868? Windows ಮೊದಲು ಏನನ್ನು ಪರಿಹರಿಸುತ್ತದೆ

ಸಂವಾದವು ಸರ್ವರ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಲಾಗಲಿಲ್ಲ ಎಂದು ತಿಳಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ನೋಡುತ್ತಿರುವ ಪ್ರೊಫೈಲ್ ಕ್ಷೇತ್ರವು ವಿಳಾಸವಾಗಿದೆ. ಈ ಸಂಯೋಜನೆ ವಿರೋಧಾಭಾಸವಲ್ಲ: ಕ್ಲೈಂಟ್ ನೀವು ಓದುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಮೌಲ್ಯಕ್ಕಿಂತ ಬೇರೆಯದನ್ನು ಪರಿಹರಿಸುತ್ತಿದೆ. DNS ಮುರಿದಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಅದು ನಿಜವಾಗಿ ಯಾವುದಕ್ಕೆ ಡಯಲ್ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಿರಿ. ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಹಂತಗಳ ಕ್ರಮ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ನಿಮಗೆ ತೋರಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಡಯಲ್ ಮಾಡುವ ಮೊದಲು ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ

Windows‌ನ ಸ್ಥಳೀಯ VPN ಸಂಪರ್ಕವು ತನ್ನ ಪ್ರೊಫೈಲ್ ಓದುತ್ತದೆ, ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಸುರಂಗವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ನಂತರವೇ ದೃಢೀಕರಿಸುತ್ತದೆ. ದೋಷ 868 ಎರಡನೇ ಹಂತಕ್ಕೆ ಸೇರಿದೆ. ನಂತರದ ಹಂತಗಳು ಎಂದಿಗೂ ಚಲಿಸದ ಕಾರಣ, ಹುಡುಕಾಟ ಮೊದಲು ವಿಫಲವಾದಾಗ ಸಂವಾದವು ರುಜುವಾತು ಸಮಸ್ಯೆಯಂತೆ ಕಾಣಬಹುದು.

ಈ ಕ್ರಮವು ಉಪಯುಕ್ತವಾಗಿದೆ, ಏಕೆಂದರೆ ಪರಿಶೀಲಿಸಬೇಕಾದ ಪದರವನ್ನು ಕಿರಿದಾಗಿಸುತ್ತದೆ. ಒಂದೇ ಪ್ರೊಫೈಲ್ ಒಂದು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಿಂದ ವಿಫಲವಾದಾಗ, ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಸರು ಪರಿಹಾರವೇ, ಸುರಂಗದ ಪ್ರಕಾರ ಅಥವಾ ಖಾತೆ ಅಲ್ಲ. ಹುಡುಕಾಟವನ್ನು ವೈಫಲ್ಯ ಸಂಭವಿಸುವಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ಪ್ರೊಫೈಲ್ ರಚಿಸಿದಲ್ಲಿ ಅಲ್ಲ.

ಕ್ಷೇತ್ರವು ವಿಳಾಸ ತೋರಿಸಿದಾಗ ಯಾವ ಹೆಸರು

ತೋರಿಸುವ ಹೆಸರಿನ ಬದಲು ಸಂಗ್ರಹಿಸಿದ ಮೌಲ್ಯವನ್ನು ಓದಿ. ಸಂಪರ್ಕದ ಲೇಬಲ್ ಅದರ ಸರ್ವರ್ ವಿಳಾಸವಲ್ಲ, ಮತ್ತು ಸಮಾನ ಲೇಬಲ್‌ಗಳ ಎರಡು ನಮೂದುಗಳು ನಿಮ್ಮನ್ನು ತಪ್ಪಾದುದರ ಹಿಂದೆ ಕಳುಹಿಸುತ್ತವೆ:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

ಪ್ರೊಫೈಲ್ ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಸಿದ್ಧಪಡಿಸಿದ್ದರೆ, ಆ ವ್ಯಾಪ್ತಿಯನ್ನೂ ಇದರೊಂದಿಗೆ ಪ್ರಶ್ನಿಸಿ -AllUserConnection. ನಂತರ ಆಜ್ಞೆ ಮುದ್ರಿಸಿದ ಮೌಲ್ಯವನ್ನೇ ನಿಖರವಾಗಿ, ವೈಫಲ್ಯ ಸಂಭವಿಸುವ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಪರಿಹರಿಸಿ. ಆಪರೇಟರ್‌ನ ದಾಖಲಿತ ಗೇಟ್‌ವೇ ಬಳಸಿ, ಸುರಂಗ ಏರಿದ ನಂತರವೇ ಪರಿಹರಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆಂತರಿಕ ಹೆಸರನ್ನಲ್ಲ. ಆ ಎರಡನೇ ಪ್ರಶ್ನೆ ನಿರೀಕ್ಷಿತ ಕಾರಣಕ್ಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಮತ್ತು ಡಯಲ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ:

Resolve-DnsName vpn.example.com

ಸಂಗ್ರಹಿಸಿದ ಮೌಲ್ಯ ನಿಜವಾಗಿಯೂ ಸಂಖ್ಯಾತ್ಮಕವಾದಾಗ, ಕ್ಲೈಂಟ್ ಹೆಸರು ಓದುವ ಎರಡನೇ ಸ್ಥಳವನ್ನು ಹುಡುಕಿ. EAP ಸಂರಚನೆ ಸರ್ವರ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬಹುದು, ಇನ್ನೊಂದು ಸಾಧನದಿಂದ ಆಮದು ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ತನ್ನದೇ ಮೌಲ್ಯವನ್ನು ಹೊತ್ತಿರಬಹುದು, ಮತ್ತು ಹಿಂದಿನ ಸ್ಥಾಪಕವು ನಕಲಿ ನಮೂದನ್ನು ಬಿಟ್ಟುಹೋಗಬಹುದು. ಸಂವಾದದ ಕ್ಷೇತ್ರವು ಯಾವಾಗಲೂ ಏಕೈಕ ಇನ್‌ಪುಟ್ ಅಲ್ಲ.

Windows 7 ಮರುಸಂಪರ್ಕ ಮಾದರಿ

ಈ ದೋಷದ ಹಿಂದಿನ ಥ್ರೆಡ್ ಒಮ್ಮೆ ಸಂಪರ್ಕಗೊಂಡು ನಂತರದ ಪ್ರಯತ್ನದಲ್ಲಿ 868 ಜೊತೆ ವಿಫಲವಾದ, ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಏನೂ ಬದಲಾಗದ ಯಂತ್ರಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸಹಭಾಗಿಗಳು Remote Access Connection Manager ಸೇವೆಯನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಅಥವಾ ಸೈನ್ ಔಟ್ ಮಾಡಿ ಮತ್ತೆ ಸೈನ್ ಇನ್ ಮಾಡುವುದು ಸಂಪರ್ಕವನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ಮರಳಿಸಿತು ಎಂದು ವರದಿ ಮಾಡಿದರು. ಇವು ಪರ್ಯಾಯ ಮಾರ್ಗಗಳು, ಸಾಬೀತಾದ ಮೂಲ ಕಾರಣ ಅಲ್ಲ.

ಆ ಮಾದರಿಯನ್ನು ಪ್ರತ್ಯೇಕ ಕಲ್ಪನೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಮರುಪ್ರಾರಂಭವು ಕ್ಲೈಂಟ್ ಸ್ಥಿತಿಯನ್ನು ಮರುಹೊಂದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಂತರದ ತಾತ್ಕಾಲಿಕ ಯಶಸ್ಸು DNS ದಾಖಲೆ ತಪ್ಪಾಗಿತ್ತು ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ:

ಕೋಷ್ಟಕವನ್ನು ರೋಗನಿರ್ಣಯವಾಗಿ ಅಲ್ಲ, ಭೇದ ಮಾಡುವ ಅವಲೋಕನಗಳ ಗುಂಪಾಗಿ ಓದಿ. ಮೊದಲ ಸಾಲು ಹೆಸರಿನ ಸಮಸ್ಯೆ, ಎರಡನೆಯದು ಕ್ಲೈಂಟ್ ಸ್ಥಿತಿ, ಮತ್ತು ಮೂರನೆಯದು ಎಂದಿಗೂ ಸರಿಯಾಗಿರದ ಪ್ರೊಫೈಲ್. ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ವ್ಯಕ್ತಿ ಮತ್ತು ಬೇರೆ ಸರಿಪಡಿಸುವಿಕೆಗೆ ಕರೆದೊಯ್ಯುತ್ತದೆ.

ನಿರ್ವಾಹಕರಿಗಾಗಿ ಏನನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು

ಪ್ರೊಫೈಲ್ ಹೆಸರು, ಸಂಗ್ರಹಿತ ವಿಳಾಸ, ಸುರಂಗದ ಪ್ರಕಾರ, ಕ್ಲೈಂಟ್ ಇದ್ದ ನೆಟ್‌ವರ್ಕ್, ಮತ್ತು ವೈಫಲ್ಯವು ಸಂಪರ್ಕ ಕಡಿತದ ನಂತರ ಬಂದಿದೆಯೇ ಎಂಬುದನ್ನು ಬರೆಯಿರಿ. ಆ ದಾಖಲೆ ಯಾರಿಗೂ ಊಹಿಸಬೇಕಿಲ್ಲದೆ ನಿಜವಾದ ಹುಡುಕಾಟ ವೈಫಲ್ಯವನ್ನು ಐತಿಹಾಸಿಕ ಮರುಸಂಪರ್ಕ ವರ್ತನೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಪ್ರಯತ್ನದ ಸುತ್ತಲಿನ ಕ್ಲೈಂಟ್ ಈವೆಂಟ್ ಲಾಗ್ ಅನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳಿ.

ಹಳೆಯ ಬಿಲ್ಡ್‌ಗಳ ಪರ್ಯಾಯ ಮಾರ್ಗವು ವರ್ತನೆ ಇತ್ತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯ, ಅದೇ ಸೇವಾ ಮರುಪ್ರಾರಂಭವು ಪ್ರಸ್ತುತ ಯಂತ್ರವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಎಂಬ ಭರವಸೆ ಅಲ್ಲ. ದಾಖಲಿತ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಅಕ್ಷರಶಃ ವಿಳಾಸದಿಂದ ಬದಲಿಸುವುದೂ ಸರಿಪಡಿಸುವಿಕೆ ಅಲ್ಲ.

ಕೆಲವು ಪ್ರೊಫೈಲ್‌ಗಳು ಸಂರಚಿತ ಹೆಸರಿಗೆ ಹೊಂದುವ ಸರ್ವರ್ ಗುರುತನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಂಖ್ಯಾತ್ಮಕ ಪರ್ಯಾಯ ಮಾರ್ಗವು ಒಂದು ದೋಷವನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಬದಲಿಸಬಹುದು. ಹೆಸರು ಉಳಿಯಬೇಕಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ ಪಠ್ಯವನ್ನಲ್ಲ, ಪರಿಹಾರ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಏನನ್ನು ಏಕೆ ಬದಲಿಸಿದಿರಿ ಎಂಬುದನ್ನು ಬರೆಯಿರಿ.