Android VPN ನಲ್ಲಿ Keystore ದೋಷ: ಮತ್ತೆ ನೋಂದಣಿ, ಅನ್‌ಲಾಕ್ ಅಥವಾ ಮತ್ತೆ ಪ್ರಯತ್ನ?
Android keystore ನ ಮೂರು ಫಲಿತಾಂಶಗಳಿಗೆ ಮೂರು ಬೇರೆ ಬೇರೆ ಚೇತರಿಕೆಗಳು ಬೇಕು. ಅಪ್ಲಿಕೇಶನ್ ಸಂಗ್ರಹವನ್ನು ಅಳಿಸುವ ಮೊದಲು ಅನ್‌ಲಾಕ್, ಮರುನೋಂದಣಿ ಮತ್ತು ಪೂರೈಕೆದಾರರ ಮರುಪ್ರಯತ್ನವನ್ನು ಹೋಲಿಸಿ.
ಪ್ರೊಫೈಲ್ ಇನ್ನೂ ಪಟ್ಟಿಯಲ್ಲಿದೆ, ಪ್ರಮಾಣಪತ್ರವು ಇನ್ನೂ ಸ್ಥಾಪಿತವಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕ ಬಟನ್ «Keystore ದೋಷ» ಎಂದು ಮಾತ್ರ ಹೇಳುವ ಸಂದೇಶದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಬೇರೆ ಏನೂ ಇಲ್ಲ. ಅಪ್ಲಿಕೇಶನ್ ಸಂಗ್ರಹವನ್ನು ಅಳಿಸುವ ಅಥವಾ ಫೋನ್ ಒಪ್ಪಿಸುವ ಮೊದಲು ಯಾವ ಕೀಲಿ ಕಾರ್ಯಾಚರಣೆ ವಿಫಲವಾಯಿತು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. ಮೂರು ಫಲಿತಾಂಶಗಳು ಅದೇ ಸಂವಾದವನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಮೂರು ವಿಭಿನ್ನ ಕ್ರಿಯೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತವೆ — ಅವುಗಳಲ್ಲಿ ಒಂದೇ ವಿನಾಶಕಾರಿ. ಈ ಹೋಲಿಕೆ ಹತ್ತು ನಿಮಿಷಗಳಿಗೆ ಯೋಗ್ಯವಾಗಿದೆ, ಏಕೆಂದರೆ ತಪ್ಪು ಶಾಖೆಯು ನೀವು ಉಳಿಸಿಕೊಳ್ಳಲು ಬಯಸಿದ ಗುರುತನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ.
ಒಂದು ಸಂವಾದದ ಹಿಂದೆ ಮೂರು ವೈಫಲ್ಯಗಳು
ಮೊದಲನೆಯದು ದೃಢೀಕರಣ. ಕೀಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಮತ್ತು ಮಾನ್ಯವಾಗಿದೆ, ಆದರೆ ಅದನ್ನು ಬಳಸಲು ಬಳಕೆದಾರರು ಉಪಸ್ಥಿತಿಯನ್ನು ಸಾಬೀತುಪಡಿಸಬೇಕು — ಸಾಧನ ಅನ್‌ಲಾಕ್, ಬಯೋಮೆಟ್ರಿಕ್ ಅಥವಾ ಕೆಲಸದ ಪ್ರೊಫೈಲ್ ಸವಾಲು. ಲಾಕ್ ಸಮಯಮಿತಿ, ನೋಂದಾಯಿತ ಬಯೋಮೆಟ್ರಿಕ್ ಅಥವಾ ಪ್ರೊಫೈಲ್ ಸ್ಥಿತಿ ಇತ್ತೀಚೆಗೆ ಬದಲಾಗಿದ್ದರೆ, ಕೀಲಿಯೇ ಸಂಪೂರ್ಣ ಸರಿಯಾಗಿದ್ದರೂ ಕೀಲಿ ಬಳಕೆ ವಿಫಲವಾಗಬಹುದು.
ಎರಡನೆಯದು ಶಾಶ್ವತ ಅಮಾನ್ಯೀಕರಣ. ಕೆಲವು ಕೀಲಿ ಸಾಮಗ್ರಿಯನ್ನು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನೀತಿಯು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ, ಲಾಕ್ ವಿಧಾನವನ್ನು ಮರುಹೊಂದಿಸಿದಾಗ ಅಥವಾ ಬಯೋಮೆಟ್ರಿಕ್ ನೋಂದಣಿ ಬದಲಾದಾಗ, ಏಕೆಂದರೆ ಅದನ್ನು ರಕ್ಷಿಸಿದ ಬಂಧನವು ಇನ್ನು ಮುಂದೆ ಇರುವುದಿಲ್ಲ. ಕೀಲಿಯನ್ನು ಸರಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಮತ್ತು ಮರುಪ್ರಯತ್ನವು ಚೇತರಿಕೆ ಯೋಜನೆ ಅಲ್ಲ; ಗುರುತನ್ನು ಅದನ್ನು ನೀಡಿದ ನೋಂದಣಿ ಪ್ರಕ್ರಿಯೆಯ ಮೂಲಕ ಬದಲಾಯಿಸಬೇಕು.
ಮೂರನೆಯದು ಪೂರೈಕೆದಾರರ ವೈಫಲ್ಯ: keystore ಸೇವೆ ಈಗ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಕೆಲವೊಮ್ಮೆ ಮರುಪ್ರಯತ್ನಕ್ಕೆ ಯೋಗ್ಯವಾದ ವರ್ಗ ಇದು, ಮತ್ತು ಒಂದೇ ಒಂದು.
| Failure | What it means | What recovers it | What does not |
|---|---|---|---|
| User not authenticated | Key needs a presence check | Supported unlock or authorization flow | A VPN account password reset |
| Key permanently invalidated | Binding is gone; key unusable | Replacement enrollment for that identity | Retrying, rebooting, reinstalling the client |
| Transient provider error | Service could not complete now | The provider's documented retry path | Clearing app data |
ಮೂರರಲ್ಲಿ ಎರಡು ವಿನಾಶಕಾರಿ ಅಲ್ಲ ಮತ್ತು ಒಂದಕ್ಕೆ ಸಾಧನ ಮಟ್ಟದಲ್ಲಿ ಯಾವುದೇ ಪರಿಹಾರವಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಫೋನ್ ಅನ್ನು ಅಳಿಸುವುದರಿಂದ ಪರಿಹಾರವಾಗುವುದಿಲ್ಲ, ಜನರು ಮೊದಲು ಮಾಡುವ ಹೆಜ್ಜೆ ಅದೇ, ಏಕೆಂದರೆ ಸಂವಾದವು ಅವರಿಗೆ ಬೇರೆ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ.
ಮರುನೋಂದಣಿ ಮತ್ತು ಡೇಟಾ ಅಳಿಸುವಿಕೆ
ಈ ಎರಡೂ ಹೊರಗಿನಿಂದ ಸಮಾನವಾಗಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಹಾಗಲ್ಲ. ಮರುನೋಂದಣಿ ನೀಡುವ ವ್ಯವಸ್ಥೆಯಿಂದ ಹೊಸ ಗುರುತನ್ನು ಕೇಳುತ್ತದೆ — ಈ ಸಾಧನಕ್ಕೆ ಬದ್ಧವಾದ ಹೊಸ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಕೀಲಿ — ಮತ್ತು ಹಳೆಯದನ್ನು ನಿವೃತ್ತಿಗೊಳಿಸುತ್ತದೆ. ಡೇಟಾ ಅಳಿಸುವಿಕೆ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂಗ್ರಹಿತ ಸ್ಥಿತಿಯನ್ನು ಅಳಿಸುತ್ತದೆ, ಅದು ಕೀಲಿಯನ್ನು ತೆಗೆಯದೆ ಕೀಲಿಯ ಉಲ್ಲೇಖವನ್ನು ತೆಗೆಯಬಹುದು, ಅಥವಾ ಕೀಲಿಯನ್ನು ತೆಗೆದು ಅದನ್ನು ಮತ್ತೆ ರಚಿಸುವ ಅಧಿಕಾರವಿಲ್ಲದೆ ಬಿಡಬಹುದು.
ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯವಾದುದು ಏಕೆಂದರೆ ರಫ್ತು ಮಾಡಲಾಗದ ಕೀಲಿಗಳು ವಿನ್ಯಾಸದಿಂದಲೇ ಸಾಗಿಸಲಾಗದವು. ಅವು ಸಾಧನದ keystore ನಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಲಭ್ಯವಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ಅಥವಾ ಪೂರೈಕೆದಾರರ ಬೆಂಬಲದೊಂದಿಗೆ, ಮತ್ತು ಅವು ಬ್ಯಾಕಪ್ ಹಿಡಿದು ಮರುಸ್ಥಾಪನೆ ಹಿಂತಿರುಗಿಸುವಂತಹದ್ದಲ್ಲ. ನಿಯೋಜನೆಯ ಗುರುತು ರಫ್ತು ಮಾಡಲಾಗದ ಕೀಲಿಯಾಗಿದ್ದರೆ, ಚೇತರಿಕೆಯಾಗಿ ಮರುನೋಂದಣಿಯನ್ನು ಯೋಜಿಸಿ, ಮತ್ತು ಆ ನೋಂದಣಿಯನ್ನು ಪಡೆಯಲು ಅನುಮೋದಿತ ಮಾರ್ಗವಿದೆ ಎಂದು ಮೊದಲೇ ದೃಢೀಕರಿಸಿ — ಕೆಲವು ಸಂಸ್ಥೆಗಳು ಅದಕ್ಕೆ ಖಾಸಗಿ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ಬೇಡುತ್ತವೆ, ಅದು ಮುರಿದ VPN ಒದಗಿಸುತ್ತಿದ್ದದ್ದೇ ಆಗಿತ್ತು.
ಆದ್ದರಿಂದ ಕ್ರಮ ಹೀಗಿದೆ: ಬೆಂಬಲಿತ ದೃಢೀಕರಣ ಮಾರ್ಗವನ್ನು ಪ್ರಯತ್ನಿಸಿ, ನಂತರ ಕೀಲಿ ಶಾಶ್ವತವಾಗಿ ಅಮಾನ್ಯವೇ ಎಂದು ನಿರ್ಧರಿಸಿ, ಮತ್ತು ಹಾಗಿದ್ದರೆ ಮಾತ್ರ ಗುರುತನ್ನು ಬದಲಾಯಿಸಿ. ಸಂಗ್ರಹ ಅಳಿಸುವಿಕೆ ಕೊನೆಯದು, ಏನು ಮತ್ತೆ ರಚನೆಯಾಗುತ್ತದೆ ಎಂದು ತಿಳಿದ ನಂತರ, ಸುಲಭವೆಂದು ಮೊದಲಲ್ಲ.
ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದಾದುದನ್ನು ಮಾತ್ರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ
ಹಳೆಯ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಆವೃತ್ತಿಗಳು keystore ದೋಷಗಳನ್ನು ಒಂದೇ ಅಪವಾದದಲ್ಲಿ ಒಟ್ಟುಗೂಡಿಸಿದ್ದವು, ಅದಕ್ಕಾಗಿಯೇ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಎಲ್ಲವನ್ನೂ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತವೆ. API 33 ರಿಂದ ಅಪವಾದ ಪ್ರಕಾರವು ರಚನೆಯನ್ನು ಹೊತ್ತಿದೆ: ಸಂಖ್ಯಾತ್ಮಕ ದೋಷ, ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯದ ಧ್ವಜ ಮತ್ತು ಮರುಪ್ರಯತ್ನ ನೀತಿ. ಕ್ಲೈಂಟ್ ಡೆವಲಪರ್‌ಗೆ ಮರುಪ್ರಯತ್ನ ನೀತಿಯು ತಾತ್ಕಾಲಿಕತೆಯ ಧ್ವಜ ಸತ್ಯವಾದಾಗ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣ; ಶಾಶ್ವತ ಅಮಾನ್ಯೀಕರಣಕ್ಕೆ ಮರುಪ್ರಯತ್ನ ವೇಳಾಪಟ್ಟಿ ಇಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಲೂಪ್‌ನಲ್ಲಿ ಬಡಿಯುವುದು ಬ್ಯಾಟರಿ ಖಾಲಿ ಮಾಡಿ ಲಾಗ್ ತುಂಬಿಸುತ್ತದೆ ಅಷ್ಟೇ.
ನೀವು ಕ್ಲೈಂಟ್ ಬರೆಯುವ ಬದಲು ರೋಗನಿರ್ಣಯ ಮಾಡುತ್ತಿದ್ದರೆ, ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮ ಅದೇ. ಪ್ರತಿ ಪ್ರಯತ್ನದಲ್ಲೂ ಒಂದೇ ರೀತಿಯ ವೈಫಲ್ಯಗಳು ಒಂದು ಬಾರಿಯ ದೋಷವನ್ನು ಹೊರಗಿಡುತ್ತವೆ, ಆದರೆ ಶಾಶ್ವತವಾಗಿ ಅಮಾನ್ಯಗೊಂಡ ಕೀಲಿಯನ್ನು ಸ್ವಲ್ಪ ಕಾಲ ಲಭ್ಯವಿಲ್ಲದ ಪೂರೈಕೆದಾರರಿಂದ ಬೇರ್ಪಡಿಸುವುದಿಲ್ಲ — ಪೂರೈಕೆದಾರರ ಅಡಚಣೆ ಹತ್ತನೇ ಪ್ರಯತ್ನದಲ್ಲೂ ಮೊದಲನೆಯಂತೆಯೇ ಕಾಣುತ್ತದೆ. API 33 ರ ರಚನಾತ್ಮಕ ಕ್ಷೇತ್ರಗಳಿಲ್ಲದೆ, ಪುನರಾವರ್ತನೆಯನ್ನು ಎರಡನೇ ಸಂಕೇತದ ಹುಡುಕಾಟಕ್ಕೆ ಕಾರಣವೆಂದು ಪರಿಗಣಿಸಿ — ದೋಷ ಕೋಡ್ ನಿಮ್ಮ ಬಿಲ್ಡ್ ಅದನ್ನು ತೋರಿಸಿದರೆ, ಆಪರೇಟರ್ ಸ್ಥಿತಿ, ಅಥವಾ ಅದೇ ಸಾಧನದಲ್ಲಿ ಇನ್ನೊಂದು ಕೀಲಿ ಯಶಸ್ವಿಯಾಗುವುದು — ಕೀಲಿ ಸತ್ತಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಾಗಿ ಅಲ್ಲ.
ಕಾರಣ ಸರಪಣಿಯನ್ನು ಓದಿ, ಲೇಬಲ್ ಅಲ್ಲ
ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮೂಲ ಅಪವಾದವನ್ನು ಸುತ್ತುತ್ತವೆ, ಮತ್ತು ಇಂಟರ್ಫೇಸ್‌ನ ಸ್ನೇಹಪರ ಪಠ್ಯವು ಶಾಖೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಏಕೈಕ ಕ್ಷೇತ್ರವನ್ನು ಹೆಚ್ಚಾಗಿ ಮರೆಮಾಡುತ್ತದೆ. ಕಾರಣ ಸರಪಣಿ ಮತ್ತು ಪ್ರಯತ್ನದ ಸಮಯಮುದ್ರೆಯನ್ನು ಉಳಿಸಿ: ಹೊರಗಿನ ಅಪವಾದ ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಕಾರಣವು ಕೀಲಿಯ ಸ್ಥಿತಿಯನ್ನು ಹೆಸರಿಸುತ್ತದೆ.
ಎರಡು ವಿಫಲ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ದೋಷಯುಕ್ತ ಹ್ಯಾಂಡ್‌ಸೆಟ್ ಸಾಬೀತುಪಡಿಸುತ್ತವೆ ಎಂಬ ಅನುಮಾನವನ್ನು ಪ್ರತಿರೋಧಿಸಿ. ವಿಭಿನ್ನ ಕೀಲಿಗಳನ್ನು ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರು ಮತ್ತು ಭದ್ರತಾ ಮಟ್ಟಗಳು ಬೆಂಬಲಿಸಬಹುದು, ಮತ್ತು ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಅದೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮಾಡದಿರಬಹುದು — ಸಹಿ, ಡೀಕ್ರಿಪ್ಷನ್ ಮತ್ತು ಕೀಲಿ ದೃಢೀಕರಣವು ಅದೇ ಸೇವೆಗೆ ವಿಭಿನ್ನ ವಿನಂತಿಗಳು. KeyStoreException ಉಲ್ಲೇಖ ಹೊಸ API ಮಟ್ಟಗಳಲ್ಲಿನ ರಚನಾತ್ಮಕ ಕ್ಷೇತ್ರಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಬಿಲ್ಡ್ ನಿಜವಾಗಿ ಏನನ್ನು ವರದಿ ಮಾಡಬಹುದು ಎಂದು ಪರಿಶೀಲಿಸುವ ಸ್ಥಳ.
ಹಾರ್ಡ್‌ವೇರ್ ತೀರ್ಮಾನಕ್ಕೆ ಬೆಂಬಲ ನೀಡುವುದು ಹೆಚ್ಚಿನವರು ಊಹಿಸುವುದಕ್ಕಿಂತ ಸಂಕುಚಿತವಾಗಿದೆ: ಅದೇ ಕಾರ್ಯಾಚರಣೆ, ಅದೇ ಪೂರೈಕೆದಾರರಲ್ಲಿ, ಸ್ವತಂತ್ರ ಕೀಲಿಗಳಲ್ಲಿ ಕೀಲಿ ಮಟ್ಟದ ದೋಷದ ಬದಲು ಪೂರೈಕೆದಾರ ಮಟ್ಟದ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುವುದು. ಅದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ರೋಗನಿರ್ಣಯಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆ, ಸಾಧನಗಳ ಬ್ಯಾಚ್ ಬಗ್ಗೆ ಬೆಂಬಲ ವೇದಿಕೆಯ ಥ್ರೆಡ್‌ಗೆ ಅಲ್ಲ.
ನಿರ್ಧರಿಸುವಾಗ ಏನನ್ನು ದಾಖಲಿಸಬೇಕು
Android ಬಿಲ್ಡ್, ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ, ಆಯ್ಕೆಮಾಡಿದ ಪ್ರೊಫೈಲ್, ವಿಫಲವಾದ ಕಾರ್ಯಾಚರಣೆ, ಮತ್ತು ಇತ್ತೀಚೆಗೆ ಏನಾದರೂ ಬದಲಾಗಿದೆಯೇ — OS ನವೀಕರಣ, ಲಾಕ್-ಸ್ಕ್ರೀನ್ ಬದಲಾವಣೆ, ಹೊಸ ಬೆರಳಚ್ಚು, ಮರುನೋಂದಣಿ — ದಾಖಲಿಸಿ. ಕ್ರಮವನ್ನು ಕಾರಣದ ಸಾಕ್ಷ್ಯವಾಗಿ ಅಲ್ಲ, ಸಂದರ್ಭವಾಗಿ ದಾಖಲಿಸಿ; ಕೀಲಿ ವೈಫಲ್ಯದ ಮೊದಲು ಲಾಕ್ ಬದಲಾವಣೆ ಸಂಭಾವ್ಯ ಪರಸ್ಪರ ಸಂಬಂಧ, ಪ್ರದರ್ಶನ ಅಲ್ಲ.
ನಂತರ ನೀವು ನಿರ್ಧರಿಸಿದ ಶಾಖೆಯಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿ. ತಾತ್ಕಾಲಿಕ: ಗುರುತನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಬೆಂಬಲಿತ ಮರುಪ್ರಯತ್ನ ಮಾರ್ಗವನ್ನು ಬಳಸಿ. ದೃಢೀಕರಣ ಅಗತ್ಯ: ಬೆಂಬಲಿತ ಅನ್‌ಲಾಕ್ ಹರಿವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ ಮತ್ತು ಸಂವಾದವನ್ನು ದಾಟಲು ಅದನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ನಿಯೋಜನೆಗೆ ಅಗತ್ಯವಿರುವ ಲಾಕ್ ನೀತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ಶಾಶ್ವತವಾಗಿ ಅಮಾನ್ಯ: ಸಾಮಾನ್ಯ ನೋಂದಣಿ ಮೂಲಕ ಗುರುತನ್ನು ಬದಲಾಯಿಸಿ ಮತ್ತು ನಿವೃತ್ತಿಗೊಳಿಸಿ.
ಹೊಸ ಅಧಿಕೃತ ಸಂಪರ್ಕದಲ್ಲಿ, ನಿಜವಾದ ಸಂಪನ್ಮೂಲಕ್ಕೆ, ಸರ್ವರ್ ಮಾನ್ಯತೆ ಇನ್ನೂ ಸಕ್ರಿಯವಾಗಿರುವಾಗ ಫಲಿತಾಂಶವನ್ನು ಸಾಬೀತುಪಡಿಸಿ ಮುಗಿಸಿ. ಸಡಿಲಗೊಳಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಯಾವುದೂ ಕೀಲಿ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಿಲ್ಲ — ಅದು ಅದನ್ನು ನೆಟ್‌ವರ್ಕ್ ಪದರಕ್ಕೆ ಸರಿಸಿದೆ, ಅಲ್ಲಿ ಅದು ನಂತರ ಕೆಟ್ಟ ಲಕ್ಷಣಗಳೊಂದಿಗೆ ಮೇಲೆ ಬರಲಿದೆ.
- ಮೂರು ಶಾಖೆಗಳು: ದೃಢೀಕರಣ ಅಗತ್ಯ, ಶಾಶ್ವತವಾಗಿ ಅಮಾನ್ಯ, ಪೂರೈಕೆದಾರರಲ್ಲಿ ತಾತ್ಕಾಲಿಕ.
- ಮೂರನೆಯದು ಮಾತ್ರ ಮರುಪ್ರಯತ್ನದಿಂದ ಲಾಭ ಪಡೆಯುತ್ತದೆ, ಮತ್ತು ಅದರ ಸ್ವಂತ ಮರುಪ್ರಯತ್ನ ನೀತಿಯ ಪ್ರಕಾರ ಮಾತ್ರ.
- ಬದಲಿ ನೋಂದಣಿ ಪ್ರವೇಶವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ; ಡೇಟಾ ಅಳಿಸುವಿಕೆ ಆ ಆಯ್ಕೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
- ಹೊಸ ಸಂಪರ್ಕ ಮತ್ತು ಸಾಮಾನ್ಯ ಸರ್ವರ್ ಗುರುತು ಪರಿಶೀಲನೆಗಳೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ.