PPP CHAP ಒಂದೇ MPPE ಅಗತ್ಯವನ್ನು ಏಕೆ ಪೂರೈಸಲಾರದು

ಗೂಢಲಿಪೀಕರಣಕ್ಕೆ ಒತ್ತಾಯಿಸುವ PPTP ಪ್ರೊಫೈಲ್ ಸಾಮಾನ್ಯವಾಗಿ ಅದೇ ಸ್ಥಳದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ: MPPE ಗೆ ಬೇಕಾದ ಕೀ ವಸ್ತುವನ್ನು ಎಂದಿಗೂ ಉತ್ಪಾದಿಸದ ದೃಢೀಕರಣ ವಿನಿಮಯಕ್ಕೆ PPP ಒಪ್ಪುತ್ತದೆ. ಸುರಂಗ ಅರ್ಧ ಜೀವಂತವಾಗಿ ಕಾಣುತ್ತದೆ, ಗುಪ್ತಪದ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಸಂಚಾರ ಅದನ್ನು ದಾಟುವ ಮೊದಲು ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ. ಏನಾದರೂ ಸಂಪರ್ಕಗೊಳ್ಳುವವರೆಗೆ CHAP ಡ್ರಾಪ್‌ಡೌನ್‌ಗೆ ಕೈಚಾಚುವುದು ನಿಜವಾದ ದೋಷವನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದು ದೃಢೀಕರಣ ವಿಧಾನ ಮತ್ತು ರಕ್ಷಣಾ ನೀತಿಯ ನಡುವಿನ ಒಪ್ಪಂದ. ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ಪ್ರತಿಯೊಂದೂ ಮುಂದಿನದಕ್ಕಿಂತ ಅಗ್ಗದ ಕಾರಣವನ್ನು ಹೊರಗಿಡುವಂತೆ ಜೋಡಿಸಲಾಗಿದೆ.

ಒಂದು PPTP ಸಂಪರ್ಕದ ಒಳಗೆ ಎರಡು ಮಾತುಕತೆಗಳು ನಡೆಯುತ್ತವೆ

PPTP GRE ಸುರಂಗದ ಒಳಗೆ ಸಾಮಾನ್ಯ PPP ಅಧಿವೇಶನವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾತುಕತೆ ನಡೆಸುತ್ತವೆ. ಹೊರ ಪದರವು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹೇಗೆ ಸುತ್ತುವರಿಯುತ್ತದೆ ಮತ್ತು ಯಾವ ನಿಯಂತ್ರಣ ಕಾಲುವೆ ಇದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ; ಒಳ PPP ಅಧಿವೇಶನವು ಯಾರು ಸಹವರ್ತಿ ಮತ್ತು ಮೇಲೆ ಯಾವ ರಕ್ಷಣೆ ಸಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಗುಪ್ತಪದ ಕೇಳಿಕೆ ಒಳ ಪದರದ ಬಗ್ಗೆ ಮಾತ್ರ ಏನನ್ನಾದರೂ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಪೂರ್ಣಗೊಂಡ ಹೊರ ಕೈಕುಲುಕುವಿಕೆ ಎರಡರ ಬಗ್ಗೆಯೂ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್‌ಗಳು ಇಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಜನರು ಸುರಂಗವನ್ನು ಡೀಬಗ್ ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಭಿನ್ನಾಭಿಪ್ರಾಯ PPP ಒಳಗೆ ಕುಳಿತಿರುತ್ತದೆ.

ಸಾಮಾನ್ಯ CHAP ಎಂಬುದು RFC 1994 ನ ಸವಾಲು-ಪ್ರತಿಕ್ರಿಯೆ ವಿನಿಮಯ, ಹಂಚಿದ ರಹಸ್ಯ ಮತ್ತು ಬೇರೆ ಯಾವುದೇ ಅಲ್ಲದ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. MS-CHAPv2 ವಿಭಿನ್ನ ಸಂದೇಶಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಔಟ್‌ಪುಟ್‌ನೊಂದಿಗೆ ಬೇರೆ ವಿನಿಮಯ, RFC 2759 ನಲ್ಲಿ ಪ್ರಮಾಣೀಕರಿಸಲಾಗಿದೆ. ಎರಡು ಹೆಸರುಗಳಲ್ಲಿನ ಹಂಚಿದ ಪದವೇ ತಂತಿಯ ಮೇಲೆ ಅವುಗಳಿಗೆ ಸಾಮಾನ್ಯವಾದ ಏಕೈಕ ವಿಷಯ. ಯಾವ ಹೆಸರೂ ವಿನಿಮಯ ಏನನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಏಕೈಕ ಮುಖ್ಯ ಭಾಗ.

ಅದಕ್ಕೇ ಕೇವಲ CHAP ಎಂದು ಲೇಬಲ್ ಮಾಡಿದ ಆಯ್ಕೆ ಹಳೆಯ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ಸರ್ವರ್ MS-CHAPv2 ಬಯಸಿದಾಗ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯ CHAP ನೀಡಿದಾಗ, ಸಂಪರ್ಕ ನಿಯಂತ್ರಣ ಇನ್ನೂ ಪೂರ್ಣಗೊಳ್ಳಬಹುದು ಮತ್ತು ಗುಪ್ತಪದ ಇನ್ನೂ ಸ್ವೀಕರಿಸಲ್ಪಡಬಹುದು. ವೈಫಲ್ಯ ನಂತರ ಬರುತ್ತದೆ, ಸರ್ವರ್ ಏನನ್ನೂ ಉತ್ಪಾದಿಸದ ವಿನಿಮಯದಿಂದ ರಕ್ಷಣಾ ಕೀಗಳನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸಿದಾಗ.

ಬೇಡಿಕೆಯ ವಿಧಾನವನ್ನು ಅದು ಉತ್ಪಾದಿಸಬಲ್ಲ ಕೀಗಳಿಗೆ ಹೊಂದಿಸಿ

MPPE ಕೀಗಳು ಸಾಮಾನ್ಯವಾಗಿ PPP ಯ ಗುಣವಲ್ಲ. Microsoft CHAP ಕುಟುಂಬಕ್ಕೆ ವ್ಯುತ್ಪತ್ತಿ RFC 3079 ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದು ಇನ್‌ಪುಟ್ ಆಗಿ ಹಂಚಿದ ರಹಸ್ಯವಲ್ಲದೆ MS-CHAP ವಿನಿಮಯದ ಔಟ್‌ಪುಟ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. EAP ವಿಧಾನಗಳು ಬೇರೆ ಮಾರ್ಗದಲ್ಲಿ ಅದೇ ಸ್ಥಳವನ್ನು ತಲುಪುತ್ತವೆ, ದೃಢೀಕರಣ ಸರ್ವರ್ ಕೀಗಳನ್ನು MS-MPPE-Recv-Key ಮತ್ತು MS-MPPE-Send-Key ಗುಣಲಕ್ಷಣಗಳಾಗಿ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಸಾಮಾನ್ಯ CHAP ಎರಡೂ ಮಾರ್ಗಗಳಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಈ ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆಯ ಇರುವಿಕೆಯ ಸಂಪೂರ್ಣ ಕಾರಣ ಅದೇ.

MPPE ಬೇಡುತ್ತಾ ಕೀ ನೀಡಬಲ್ಲ ಪ್ರತಿಯೊಂದು ವಿಧಾನವನ್ನೂ ನಿರಾಕರಿಸುವ ಸಂರಚನೆ ಆಂತರಿಕವಾಗಿ ವಿರುದ್ಧವಾಗಿದೆ. pppd ಆ ವಿರೋಧವನ್ನು ಕೀಗಳನ್ನು ಕಲ್ಪಿಸುವ ಮೂಲಕವಲ್ಲ, ಸಂಪರ್ಕವನ್ನು ನಿರಾಕರಿಸುವ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಗೋಚರ ಫಲಿತಾಂಶ ದೃಢೀಕರಿಸಿ ನಂತರ ಜಾಲ ಹಂತದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಅಧಿವೇಶನ. ಸರ್ವರ್ ಏನನ್ನಾದರೂ ವ್ಯುತ್ಪತ್ತಿ ಮಾಡುವ ಏಕೈಕ ವಿಧಾನಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತಿರುವವರೆಗೆ ಕ್ಲೈಂಟ್ ಅನ್ನು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಇದರಿಂದ ಬರುವ ನಿಯಮ ಚಿಕ್ಕದು: ಪ್ರೊಫೈಲ್ MPPE ಬೇಡಿದರೆ, ವಿಧಾನ MS-CHAP ನ ರೂಪ ಅಥವಾ ಸರ್ವರ್ ಕೀಗಳನ್ನು ಹಿಂತಿರುಗಿಸುವ EAP ವಿಧಾನವಾಗಿರಬೇಕು. ಕೇವಲ MS-CHAPv2 ಅನ್ನು ನಿರಾಕರಿಸುವುದು ಅದನ್ನು ಜಾರಿಗೊಳಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ MS-CHAPv1 ಸಹ ಕೀಗಳನ್ನು ವ್ಯುತ್ಪತ್ತಿ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿರಾಕರಿಸದಿದ್ದರೆ ಲಭ್ಯವಿರುತ್ತದೆ; ಎರಡನ್ನೂ ನಿರಾಕರಿಸಿದರೆ ಸಾಮಾನ್ಯ CHAP ಮತ್ತು PAP ಉಳಿಯುತ್ತವೆ, ಅವು ಏನನ್ನೂ ವ್ಯುತ್ಪತ್ತಿ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಅಗತ್ಯವನ್ನು ಪೂರೈಸಲಾಗದಂತೆ ಮಾಡುತ್ತವೆ. ಇಷ್ಟವಿಲ್ಲದವುಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುವ ಬದಲು ಸ್ವೀಕೃತ ವಿಧಾನವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೆಸರಿಸಿ. ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳಲಿ ಎಂದು ಗೂಢಲಿಪೀಕರಣದ ಅಗತ್ಯವನ್ನು ಬಿಟ್ಟುಬಿಡುವುದು ರಿಪೇರಿಯಲ್ಲ, ಅವನತಿ.

ಕ್ಲೈಂಟ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸರ್ವರ್‌ನ ಆಯ್ಕೆಗಳನ್ನು ಓದಿ

ಈ ಹೊಂದಾಣಿಕೆಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಸರ್ವರ್‌ನಲ್ಲಿ ಎರಡು ಕಡತಗಳಲ್ಲಿ ಗೋಚರಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಓದುವುದು ಕ್ಲೈಂಟ್ ಮರುನಿರ್ಮಿಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ಖರ್ಚು. Linux PPTP ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನಲ್ಲಿ ಸಂಬಂಧಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳು pptpd ರವಾನಿಸುವ pppd ಆಯ್ಕೆ ಕಡತದಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಅದನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಿ, ಕ್ಲೈಂಟ್ ಸ್ಥಿತಿ ಪರದೆಯಿಂದಲ್ಲ. ರಕ್ಷಣಾ ಮೋಡ್ ಬೇಡುವ, ನಿರಾಕರಿಸುವ ಅಥವಾ ಹೆಸರಿಸುವ ಸಾಲುಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ:

sudo grep -nE 'require-|refuse-|mppe|mschap' /etc/ppp/options.pptpd

ಔಟ್‌ಪುಟ್ ಅನ್ನು ಫ್ಲ್ಯಾಗ್‌ಗಳ ಪಟ್ಟಿಯಲ್ಲ, ಒಪ್ಪಂದವಾಗಿ ಓದಿ. MPPE ಬೇಡುತ್ತಾ MS-CHAP ನ ಎರಡೂ ರೂಪಗಳನ್ನು ನಿರಾಕರಿಸುವ ಸಾಲನ್ನು ಯಾವ ಕ್ಲೈಂಟ್‌ಗೂ ಪೂರೈಸಲಾಗದು, ಮತ್ತು MS-CHAP ವಿಧಾನಕ್ಕೆ ಅಗತ್ಯದ ಕೊರತೆ ಕೀ ನೀಡದ ವಿನಿಮಯಗಳಿಗೆ ಬಾಗಿಲನ್ನು ತೆರೆದಿಡುತ್ತದೆ. ನಂತರ ಯಾರಿಗೆ ದೃಢೀಕರಣಕ್ಕೆ ಅನುಮತಿ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಅದನ್ನು ರಹಸ್ಯ ಕಡತ ನಿರ್ಧರಿಸುತ್ತದೆ:

sudo sed -n '1,20p' /etc/ppp/chap-secrets
sudo pppd --version

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಬರೆಯಿರಿ: ಹೊರ ಪ್ರೋಟೋಕಾಲ್, ಸರ್ವರ್ ಬೇಡುವ ದೃಢೀಕರಣ ವಿಧಾನ, ಮತ್ತು ರಕ್ಷಣೆ ಕಡ್ಡಾಯವೇ ಅಥವಾ ಐಚ್ಛಿಕವೇ. ಆ ಮೂರು ನಂತರದ ಪ್ರತಿಯೊಂದು ನಿರ್ಧಾರವನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಕ್ಲೈಂಟ್ ಸಂವಾದದಿಂದ ಊಹಿಸುವುದು ಪ್ರೊಫೈಲ್ ಅರ್ಧ ಸಂರಚಿತವಾಗಿ ಉಳಿಯುವ ದಾರಿ. ಕೆಲಸ ಮಾಡುವಾಗ ಕಡತವನ್ನು ತೆರೆದಿಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ವಿಭಾಗಕ್ಕೆ ಅದೇ ಮೂರು ಮೌಲ್ಯಗಳು ಬೇಕು.

PPP ಹಂತದ ಪ್ರಕಾರ ವೈಫಲ್ಯವನ್ನು ಗುರುತಿಸಿ

PPP ವೈಫಲ್ಯಗಳನ್ನು ಹಂತಗಳಲ್ಲಿ ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹಂತವು ಒಪ್ಪಂದದ ಯಾವ ಷರತ್ತು ಮುರಿಯಿತು ಎಂದು ಹೇಳುತ್ತದೆ. ಸಂಪರ್ಕ ನಿಯಂತ್ರಣವನ್ನು ಎಂದಿಗೂ ಬಿಡದ ಸಂಪರ್ಕಕ್ಕೆ ಸುತ್ತುವರಿಕೆ ಅಥವಾ ಮಾತುಕತೆಯ ಸಮಸ್ಯೆ ಇರುತ್ತದೆ, ಆದರೆ ದೃಢೀಕರಿಸಿ ನಂತರ ಸಾಯುವ ಸಂಪರ್ಕಕ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ನೀತಿ ಅಥವಾ ಕೀ ಸಮಸ್ಯೆ ಇರುತ್ತದೆ. ಮೇಲೆ ಉಳಿದು ಏನನ್ನೂ ಸಾಗಿಸದ ಸಂಪರ್ಕವು ಮಾರ್ಗನಿರ್ದೇಶನಕ್ಕೆ ಸಾಗಿದೆ, ಅದು ಬೇರೆ ತನಿಖೆ.

ಜರ್ನಲ್ ಹಂತದ ಸಾಲುಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅವು ಹೆಚ್ಚಿನ ಡೀಬಗ್ ಮಟ್ಟಕ್ಕಿಂತ ಉಪಯುಕ್ತ. PPP ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ರಕ್ಷಣಾ ಸಂದೇಶಗಳನ್ನು ಕೇಳಿ, ನಂತರ ಎಲ್ಲದಕ್ಕಿಂತ ಮೊದಲು ದೃಢೀಕರಣ ಫಲಿತಾಂಶವನ್ನು ಓದಿ. ಕೊನೆಯ ಸಾಲುಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿರಾಕರಿಸಿದ ಷರತ್ತನ್ನು ಹೆಸರಿಸುತ್ತವೆ:

sudo journalctl -b --no-pager | grep -iE 'pppd|pptpd|mppe|chap' | tail -40

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

ಹಳೆಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಫ್ ಆಗುವ ಮೊದಲು ನಿರ್ಗಮನವನ್ನು ಯೋಜಿಸಿ

MPPE ಸಂಪರ್ಕ ರಕ್ಷಣೆಯ ಐತಿಹಾಸಿಕ ಕಾರ್ಯವಿಧಾನ, ಮತ್ತು ಅದರ ಇರುವಿಕೆ PPTP ಅನ್ನು ಹೊಸ ನಿಯೋಜನೆಗೆ ವಿವೇಕಯುತ ಆಯ್ಕೆಯಾಗಿಸುವುದಿಲ್ಲ. Microsoft ನ ಪ್ರಸ್ತುತ ಮಾರ್ಗದರ್ಶನವು ಹೊಸ ದೂರಸ್ಥ ಪ್ರವೇಶ ನಿಯೋಜನೆಗಳಿಗೆ PPTP ಮತ್ತು ಪೂರ್ವ-ಹಂಚಿದ ಕೀಯ L2TP/IPsec ವಿರುದ್ಧ ಈಗಾಗಲೇ ಸಲಹೆ ನೀಡುತ್ತದೆ. ಹಳೆಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಜೀವಂತವಾಗಿ ಇಡುವುದು ಇರುವ ಸೇವೆಯ ಬಗ್ಗೆ ನಿರ್ಧಾರ, ಮುಂದಿನದಕ್ಕೆ ಮಾದರಿಯಲ್ಲ.

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

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