MSCHAPv2 ಒಂದು VPN ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ: ಮೊದಲು ಸುರಂಗದ ಬಗ್ಗೆ ಕೇಳಿ
ಪಾಸ್‌ವರ್ಡ್ ಮತ್ತು MSCHAPv2 ಪದ ಸೇರಿ ಸಂಪರ್ಕ ಆಗುವುದಿಲ್ಲ. ಯಾವ ಸುರಂಗ ಈ ವಿನಿಮಯವನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ, ನಂತರ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಅದಕ್ಕೆ ಹೊಂದಿಸಿ.
ಬಳಕೆದಾರರ ಹೆಸರುಗಳು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಒಂದು ವಾಹಕದ ಒಳಗೆ ಪ್ರಯಾಣಿಸುತ್ತವೆ, ಮತ್ತು MSCHAPv2 ಪ್ರಯಾಣಿಸುವ ವಿಧಾನದ ಹೆಸರನ್ನು ಮಾತ್ರ ಹೇಳುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಅದನ್ನು ಯಾವ ಸುರಂಗ ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಕೇಳಿ, ಏಕೆಂದರೆ ಅದೇ ಖಾತೆ ಸರಣಿ ಒಂದು ಸಾಲಿನ ಕೋಡನ್ನೂ ಹಂಚಿಕೊಳ್ಳದ ವ್ಯವಸ್ಥೆಗಳಲ್ಲೂ ಕಾಣುತ್ತದೆ. ನಿಮಗೆ ಕೊಡುವ ಪ್ರತಿ ಪ್ರೊಫೈಲ್ ಎರಡೂ ನಿರ್ಧಾರಗಳನ್ನು ಎನ್‌ಕೋಡ್ ಮಾಡುತ್ತದೆ, ಸೂಚನಾ ಹಾಳೆ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಮುದ್ರಿಸಿದಾಗಲೂ. ಕೆಳಗಿನ ಕ್ರಮವೇ ಆಪರೇಟರ್ ಊಹೆ ಇಲ್ಲದೆ ಉತ್ತರಿಸಬಹುದಾದದ್ದು ಮತ್ತು ನೀವು ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯದೆ ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದು.
ದೃಢೀಕರಣ ಸುರಂಗದ ಒಳಗೆ ಸಾಗುತ್ತದೆ
VPN ಒಂದೇ ರೀತಿ ಕಾಣುವ ಎರಡು ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಪಕ್ಷಗಳು ರಕ್ಷಿತ ಕಾಲುವೆಯನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುತ್ತವೆ, ಮತ್ತು ವ್ಯಕ್ತಿ ಅದರ ಒಳಗೆ ಗುರುತನ್ನು ಹೇಗೆ ಸಾಬೀತುಪಡಿಸುತ್ತಾನೆ. ಎರಡನೆಯದನ್ನು ಸೂಚನಾ ಹಾಳೆಯಲ್ಲಿ ಮುದ್ರಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಮನುಷ್ಯ ಟೈಪ್ ಮಾಡುವುದು ಅದನ್ನೇ. ಮೊದಲನೆಯದು ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಜನರು ಬಿಟ್ಟುಬಿಡುವುದು ಅದನ್ನೇ. ಆಪರೇಟರ್ ಮೊದಲು ವಾಹಕವನ್ನು ನಂತರ ವಿಧಾನವನ್ನು ಹೆಸರಿಸುವಂತೆ ಕೇಳಿ, ಅದೇ ಕ್ರಮದಲ್ಲಿ. ಎರಡು ಸಂಪರ್ಕಗಳು ಒಂದೇ ಖಾತೆ ಹೆಸರು ಮತ್ತು ಒಂದೇ ಪಾಸ್‌ವರ್ಡ್ ಕೇಳಬಹುದು, ಆದರೆ ಲಾಗಿನ್ ಪೆಟ್ಟಿಗೆಯ ಕೆಳಗೆ ಯಾವುದೇ ಅನುಷ್ಠಾನವನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಅದಕ್ಕೇ ಸಹೋದ್ಯೋಗಿಯ ಕೆಲಸ ಮಾಡುವ ಫೋನ್‌ನಿಂದ ನಕಲಿಸಿದ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ನಿಮ್ಮ ಫೋನ್‌ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು, ಸರ್ವರ್ ಎರಡೂ ರುಜುವಾತುಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗಲೂ. ರುಜುವಾತು ಎಂದಿಗೂ ವ್ಯತ್ಯಾಸವಾಗಿರಲಿಲ್ಲ; ಅದನ್ನು ಸುತ್ತುವರಿದ ಪ್ರೊಫೈಲ್ ವ್ಯತ್ಯಾಸವಾಗಿತ್ತು. ಎರಡೂ ಕಡೆ ಸರಿ ಮತ್ತು ಏನೂ ಸಂಪರ್ಕವಾಗುವುದಿಲ್ಲ ಸಾಮಾನ್ಯವಾಗಿ ಇದೇ ಗೊಂದಲ, ಮತ್ತು ವಾಹಕದ ಹೆಸರು ಹೇಳಿದ ಕ್ಷಣ ಅದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ಅದೇ ವಿಧಾನ ಕಾಣುವ ಮೂರು ಸ್ಥಳಗಳು
PPP ನಲ್ಲಿ ದೃಢೀಕರಣ ಹಂತವು ಕೊಂಡಿ ಇರುವವರೆಗೆ ಕಾಯುತ್ತದೆ, ಮತ್ತು RFC 2759 MS-CHAPv2 ಅನ್ನು ಆ ಹಂತವೆಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ವಿಧಾನ L2TP ಮತ್ತು ಹಳೆಯ PPTP ನಿಯೋಜನೆಗಳಲ್ಲಿ ಕಾಣುತ್ತದೆ. ಸುರಂಗ ಮೊದಲು ಮುಗಿಯುತ್ತದೆ ಮತ್ತು PPP ಮಾತುಕತೆ ಅದರ ಒಳಗೆ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಫಲವಾದ PPP ಹಂತವು ಸರ್ವರ್ ಲಾಗ್‌ನಲ್ಲಿ ಸುರಂಗವನ್ನು ಸ್ಥಾಪಿತವಾದಂತೆ ಬಿಡಬಹುದು. ರುಜುವಾತುಗಳು ತಿರಸ್ಕೃತವಾದವು ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಆ ಎರಡು ಹಂತಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ. ಆದ್ದರಿಂದ L2TP ಗಾಗಿ ಸಂರಚಿಸಲಾದ ಕ್ಲೈಂಟ್ ಸಂಪೂರ್ಣ ಸರಿಯಾಗಿರಬಹುದು ಮತ್ತು ಹಾಗಿದ್ದರೂ IKEv2 ಮಾತ್ರ ಮಾತನಾಡುವ ಗೇಟ್‌ವೇಗೆ ತಪ್ಪು ಕ್ಲೈಂಟ್ ಆಗಿರಬಹುದು.
IKEv2 ಬದಲಿಗೆ EAP-MSCHAPv2 ಅನ್ನು ಕೀಲಿ ವಿನಿಮಯದ ಒಳಗೆ ಇಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದೇ ರುಜುವಾತು ಬೇರೆ ಕ್ಷಣದಲ್ಲಿ ವಿಫಲವಾಗಿ ಸೆಷನ್ ದೋಷವಲ್ಲ, ದೃಢೀಕರಣ ದೋಷವಾಗಿ ಹೊರಬರುತ್ತದೆ. Android ನ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ IKEv2 ಪ್ರೊಫೈಲ್ ದಿನನಿತ್ಯದ ಉದಾಹರಣೆ, ಮತ್ತು ಅದು PPP ಆಯ್ಕೆಗಳ ಬದಲು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಕೇಳುತ್ತದೆ. ಖಾತೆ ಹೆಸರು ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಒಂದೇ, ಆದ್ದರಿಂದ ಯಾವುದು ನಿಮ್ಮಲ್ಲಿದೆ ಎಂದು ಅದು ಹೇಳಲಾರದು. ಆಪರೇಟರ್ ಬೆಂಬಲಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಪಟ್ಟಿ ಮಾತ್ರ ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
TLS ಆಧಾರಿತ VPN ಮೂರನೇ ವ್ಯವಸ್ಥೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ, ತನ್ನದೇ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಕ್ಷೇತ್ರಗಳೊಂದಿಗೆ ಮತ್ತು ವಿನಿಮಯದಲ್ಲಿ ಎಲ್ಲೂ MS-CHAPv2 ಇಲ್ಲದೆ. ಆದ್ದರಿಂದ ಪಾಸ್‌ವರ್ಡ್ ಪೆಟ್ಟಿಗೆ ಕಾಣುವುದು ಅದರ ಹಿಂದಿನ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಸಾಕ್ಷಿಯಲ್ಲ, ಏಕೆಂದರೆ ನಮೂನೆಯನ್ನು ಪರಿಚಿತವಾಗಿ ಕಾಣುವಂತೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಕಿಟಕಿಯ ಆಕಾರದಿಂದಲ್ಲ, ಸರ್ವರ್ ದಾಖಲೆಗಳಿಂದ ದೃಢೀಕರಿಸಿ.
ನಿಮಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ಉತ್ತರಗಳು
ವಿನಂತಿಯನ್ನು ಪಟ್ಟಿಯಾಗಿ ಕಳುಹಿಸಿ, ಏಕೆಂದರೆ ಪಟ್ಟಿಗೆ ಅರ್ಧ ಉತ್ತರ ಕೊಡುವುದು ಕಷ್ಟ. ಸುರಂಗದ ಪ್ರೋಟೋಕಾಲ್, ಅದರ ಒಳಗಿನ ವಿಧಾನ, ಮತ್ತು ಆಪರೇಟರ್ ನಿಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಬೆಂಬಲಿಸುವ ಕ್ಲೈಂಟ್ ಕೇಳಿ. ನಂತರ ಗೇಟ್‌ವೇಯ ಗುರುತು ಮತ್ತು ವಿಶ್ವಾಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳು, ಖಾತೆ ಸ್ವರೂಪ, ಮತ್ತು ಸಂಪರ್ಕ ಏರಿದ ನಂತರ ಏನು ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು ಎಂದು ಕೇಳಿ.
ಮೊದಲ ಮೂರು ನಿಮಗೆ ಕೆಲಸ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಸಿಗುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಕೊನೆಯ ಮೂರು ಆ ಪ್ರೊಫೈಲ್ ಕೆಲಸಕ್ಕೆ ಬೇಕಾದದ್ದನ್ನು ಮಾಡುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಉತ್ತರವನ್ನು ಟಿಕೆಟ್‌ಗೆ ಜೋಡಿಸಿಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿಯೂ ಅದೇ ಆರು ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳುತ್ತಾನೆ. ಉತ್ತರ ಇಲ್ಲದ ಕಡೆ ಆ ಕೊರತೆಯನ್ನು ಆಪರೇಟರ್ ಇನ್ನೂ ತೆಗೆದುಕೊಳ್ಳದ ನಿರ್ಧಾರವೆಂದು ಪರಿಗಣಿಸಿ, ನೀವು ಊಹಿಸಬಹುದಾದದ್ದೆಂದಲ್ಲ.
| What you ask for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
ಗೇಟ್‌ವೇ ಪರಿಶೀಲನೆಯನ್ನು ಸಡಿಲಿಸಬೇಡಿ
ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ಗೂ ತನ್ನ ಗುರುತನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ವಿನಿಮಯದ ಆ ಅರ್ಧ ಅಲಂಕಾರವಲ್ಲ. ಹಠಮಾರಿ ಪ್ರೊಫೈಲ್ ಸಂಪರ್ಕವಾಗಲೆಂದು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಉತ್ತರಿಸುವ ಯಾವುದೇ ಅಂತ್ಯಬಿಂದುವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಯಾರೂ ತಲುಪಲು ಉದ್ದೇಶಿಸದಿದ್ದನ್ನು ಸಹ. ಅದು ನಿಜವಾದ ಹೊಂದಾಣಿಕೆಯನ್ನು ಪರಿಹರಿಸುವ ಬದಲು ಮರೆಮಾಡುತ್ತದೆ, ಇದು ವೈಫಲ್ಯವನ್ನು ನಂತರದ ಮತ್ತು ಕಡಿಮೆ ಸ್ಪಷ್ಟ ಕ್ಷಣಕ್ಕೆ ತಳ್ಳುತ್ತದೆ. ಪರಿಶೀಲನೆ ಆಫ್ ಆಗಬೇಕಾದ ಪ್ರೊಫೈಲ್ ತಾನು ಪರಿಶೀಲಿಸಲಾಗದ ಯಾವುದನ್ನೋ ತೋರಿಸುತ್ತದೆ.
ಹೊಂದಾಣಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಹೆಸರು, ಏಕೆಂದರೆ ಒಂದು ಹೋಸ್ಟ್ ಹೆಸರಿಗೆ ನೀಡಿದ ಪ್ರಮಾಣಪತ್ರವು ಪ್ರೊಫೈಲ್ ವಿಳಾಸ ಡಯಲ್ ಮಾಡಿದಾಗ ವಿಫಲವಾಗುತ್ತದೆ. ಪರಿಶೀಲನೆಯನ್ನು ಆಫ್ ಮಾಡುವ ಬದಲು ಹೆಸರನ್ನು ಡಯಲ್ ಮಾಡಿ. ಖಾಸಗಿ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರವು ಸಾಧನಕ್ಕೆ ಮೂಲ ಎಂದಿಗೂ ನೀಡದಿದ್ದಾಗ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಪರಿಹಾರ ಆ ಮೂಲವನ್ನು ಅನುಮೋದಿತ ಮಾರ್ಗದಲ್ಲಿ ಹಂಚುವುದು. ನಿರ್ವಹಿತ ಪರಿಸರಗಳು ಆಪರೇಟರ್ ಗುರುತು ಮತ್ತು ವಿಶ್ವಾಸ ಆಂಕರ್ ಒದಗಿಸಬೇಕೆಂದು, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಎರಡನ್ನೂ ಉಲ್ಲೇಖಿಸಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ಕ್ಷೇತ್ರ ಇಲ್ಲದಿದ್ದಾಗ ಪರಿಶೀಲನೆಯಿಂದ ಹಿಂದೆ ಸರಿಯುವ ಬದಲು ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಕೇಳಿ.
ಪ್ರೊಫೈಲ್ ಹೊಂದಿಸಿ, ನಂತರ ಪ್ರತಿ ಹಂತವನ್ನು ಸಾಬೀತುಪಡಿಸಿ
ವಾಹಕ ತಿಳಿದ ನಂತರ ಆ ಕ್ಲೈಂಟ್‌ನ ದಾಖಲಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನುಸರಿಸಿ ಮತ್ತು ಅದು ಕೇಳುವ ಕ್ಷೇತ್ರಗಳನ್ನು ಮಾತ್ರ ನಮೂದಿಸಿ. ಇವೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ತುಂಬುವ ಹೆಚ್ಚುವರಿ ಕ್ಷೇತ್ರಗಳೂ ತಪ್ಪು ಮೌಲ್ಯಗಳೇ, ಮತ್ತು ಅವು ಕಡ್ಡಾಯದವುಗಳಿಗಿಂತ ನಂತರ ವಿಫಲವಾಗುತ್ತವೆ. ಮೊದಲ ಯಶಸ್ವಿ ಸಂಪರ್ಕದ ನಂತರ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಬದಲಿಸದೆ ಉಳಿಸಿ, ನಂತರದ ಸಂಪಾದನೆಯನ್ನು ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ತಿಳಿದಿರುವ ಯಾವುದೋ ಒಂದಕ್ಕೆ ಹೋಲಿಸಬಹುದಾಗಲೆಂದು.
ನಂತರ ಹಂತ ಹಂತವಾಗಿ ಪರಿಶೀಲಿಸಿ: ಸುರಂಗ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ಬಳಕೆದಾರ ದೃಢೀಕರಿಸಲ್ಪಡುತ್ತಾನೆ, ನಿಗದಿತ ವಿಳಾಸ ಮತ್ತು ಮಾರ್ಗಗಳು ಕಾಣುತ್ತವೆ, ಮತ್ತು ಒಂದು ಅನುಮತಿಸಿದ ಸೇವೆ ಉತ್ತರಿಸುತ್ತದೆ. ಪ್ರತಿ ಹಂತವೂ ಸರ್ವರ್‌ನಲ್ಲಿ ತನ್ನದೇ ಲಾಗ್ ಸಾಲನ್ನು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಕ್ರಮವಾಗಿ ಓದುವುದು ಅಸ್ಪಷ್ಟ ದೂರನ್ನು ನಿರ್ದಿಷ್ಟ ಕಂಡುಹಿಡಿಯುವಿಕೆಯಾಗಿ ಬದಲಿಸುತ್ತದೆ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆಪರೇಟರ್ ವಿವರಿಸಿದ ವ್ಯವಸ್ಥೆಯನ್ನು ಇನ್ನು ಬೆಂಬಲಿಸದಿದ್ದರೆ, ಅದು ವಲಸೆಯ ಮಾತುಕತೆ, ಸಾಧನದಲ್ಲಿ ಎಲ್ಲ ಹಳೆಯ ಆಯ್ಕೆಗಳನ್ನು ಆನ್ ಮಾಡುವ ಕಾರಣವಲ್ಲ. ವಾಹಕ, ವಿಧಾನ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಮೂರು ಬೇರೆ ಬೇರೆ ಉತ್ತರಗಳು, ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಸಂಪರ್ಕದಲ್ಲಿ ಮೂರೂ ಹೊಂದಿಕೆಯಾಗಿರುತ್ತವೆ.