AWS Client VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ DNS: ಪರಿಹರಿಸಿದ IP ಅನ್ನು ಪಿನ್ ಮಾಡುವುದು ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ
AWS Client VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ನೀವು ಪರಿಹರಿಸಿದ ವಿಳಾಸದಿಂದ ಬದಲಾಯಿಸಿ, ನಂತರ ಸುರಂಗ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ರಫ್ತಾದ ಹೆಸರನ್ನು ಮತ್ತು ಅದರ ಯಾದೃಚ್ಛಿಕ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಇರಿಸಿಕೊಳ್ಳಿ.
ಕಳೆದ ವಾರ dig +short ನಿಮ್ಮ AWS Client VPN ಪ್ರೊಫೈಲ್‌ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರಿಗೆ ಒಂದು ವಿಳಾಸವನ್ನು ನೀಡಿತು, ಮತ್ತು ಸುರಂಗ ಸಂಪರ್ಕಗೊಂಡಿತು. ಈ ವಾರ ಅದೇ ಪ್ರೊಫೈಲ್ ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ 'Connecting' ನಲ್ಲಿ ನಿಂತಿದೆ, ಆದರೆ ಸಹೋದ್ಯೋಗಿಯ ಮುಟ್ಟದ ಪ್ರತಿ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ. ಏನೂ ನಿರ್ಬಂಧಿಸಲಿಲ್ಲ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಅವಧಿ ಮುಗಿಯಲಿಲ್ಲ. ಯಾರೋ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೋಸ್ಟ್‌ನಾಮ್ ಅನ್ನು ಆ ಪರಿಹರಿಸಿದ ವಿಳಾಸದಿಂದ ಬದಲಾಯಿಸಿದ್ದಾರೆ, ಮತ್ತು ಸೇವೆ ಅಲ್ಲಿ ಇನ್ನು ಉತ್ತರಿಸುವುದಿಲ್ಲ. ರಫ್ತಾದ ಹೆಸರು ಆ ಬದಲಾವಣೆಯನ್ನು ತಾಳಿಕೊಳ್ಳಲು ನಿರ್ಮಿಸಲಾದ ಭಾಗವಾಗಿದೆ.
ನಿಮ್ಮ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿರುವ ಹೆಸರು ಪ್ರಶ್ನಿಸಲ್ಪಡುವ ಹೆಸರಾಗದೇ ಇರಬಹುದು
Client VPN ನಿಂದ ರಫ್ತಾದ ಪ್ರೊಫೈಲ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ remote-random-hostname ಅನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಆ ಆಯ್ಕೆ ಆನ್ ಇದ್ದಾಗ, ಕ್ಲೈಂಟ್ ಒಂದು ಬಳಕೆ-ಒಮ್ಮೆ ಲೇಬಲ್ ರಚಿಸಿ, ಚುಕ್ಕೆಯಿಂದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರಿಗೆ ಸೇರಿಸಿ, ಸಂಯೋಜಿತ ಹೆಸರನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನ ವಲಯದಲ್ಲಿನ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ದಾಖಲೆ ಯಾವುದೇ ಲೇಬಲ್‌ಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಲ್ಪಿತ ಪೂರ್ವಪ್ರತ್ಯಯವೂ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಕೈಯಿಂದ ಪುನರಾವರ್ತಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ಈ ತಂತ್ರ ಕಾಣದಾಗಿರುತ್ತದೆ.
ಆದ್ದರಿಂದ ನೀವು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ಟರ್ಮಿನಲ್‌ಗೆ ಅಂಟಿಸಿ ಉತ್ತರ ಪಡೆದಾಗ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಬಳಸುವ ಹೆಸರಿಗಿಂತ ಬೇರೆ ಹೆಸರನ್ನು ನೀವು ಪರಿಹರಿಸಿದ್ದೀರಿ. ಆ ವ್ಯತ್ಯಾಸ ಪ್ರೊಫೈಲ್‌ನಲ್ಲಿ ಸರಿಪಡಿಸಬೇಕಾದ ದೋಷವಲ್ಲ. ಲೇಬಲ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮತ್ತೆ ರಚಿಸಲ್ಪಡುತ್ತದೆ: ಆಯ್ಕೆ ಕ್ಯಾಶ್‌ಗಳು ಹಳೆಯ ಉತ್ತರವನ್ನು ಇಟ್ಟುಕೊಳ್ಳದಂತೆ ತಡೆಯುತ್ತದೆ, ಮತ್ತು ಅದು ಎಂದಿಗೂ ನಿಮ್ಮ ಯಂತ್ರ ಅಥವಾ ಸೆಷನ್ ಅನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ.
ಕ್ಲೈಂಟ್ ಆಯ್ಕೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುವ ಹೊಂದಾಣಿಕೆಯ ಸಂದರ್ಭವನ್ನು ನಾನು ಎದುರಿಸಿದ್ದೇನೆ. AWS ಪರಿಹಾರವನ್ನು ದಾಖಲಿಸುತ್ತದೆ: ನಿಜವಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ಇಟ್ಟುಕೊಂಡು ಮುಂದೆ ಯಾದೃಚ್ಛಿಕ ಸ್ಟ್ರಿಂಗ್ ಮತ್ತು ಚುಕ್ಕೆಯನ್ನು ಸೇರಿಸಿ, ಅದನ್ನು ಅಂಟಿಸುವ ಮೌಲ್ಯವಲ್ಲದೆ ಹೆಸರಿಸುವ ಮಾದರಿಯಾಗಿ ಪರಿಗಣಿಸಿ. ಹಳೆಯ ಕ್ಲೈಂಟ್‌ಗೆ ಅದನ್ನು ಅನ್ವಯಿಸುವುದು ಸೂಕ್ತ; ಪೂರ್ವಪ್ರತ್ಯಯದ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುವುದು ಅಲ್ಲ.
ಉಳಿಸಿದ ಉತ್ತರ ಏಕೆ ಸರಿಯಾಗಿ ಉಳಿಯಲು ಸಾಧ್ಯವಿಲ್ಲ
Client VPN ಎಂಡ್‌ಪಾಯಿಂಟ್ ವಿಳಾಸಗಳನ್ನು AWS ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅವು ಕಾಲಾನುಕ್ರಮದಲ್ಲಿ ಬದಲಾಗುತ್ತವೆ, ಇದನ್ನು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳ ದಾಖಲೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ. ಸೆರೆಹಿಡಿದ ಉತ್ತರವು ಒಂದು ಪರಿಹಾರದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್. ಅದನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುವ ಪ್ರೊಫೈಲ್ ಸೇವೆ ಸರಿದಾಕ್ಷಣ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ಹೋಸ್ಟ್ ಕಡೆ ಗುರಿಯಿಟ್ಟ ಪ್ರೊಫೈಲ್ ಆಗುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯವು ಅಪರೂಪವಾಗಿ DNS ನಂತೆ ಕಾಣುತ್ತದೆ: ನೀವು ಸಂಪರ್ಕ ಟೈಮೌಟ್ ಅಥವಾ ನಿಂತ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪಡೆಯುತ್ತೀರಿ, ಆದ್ದರಿಂದ ಜನರು ರೂಟಿಂಗ್ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳ ಹಿಂದೆ ಓಡುತ್ತಾರೆ.
/etc/hosts ನಲ್ಲಿನ ಅದೇ ಉತ್ತರ ಅದೇ ಅವಧಿಯನ್ನು ಹೆಚ್ಚುವರಿ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ವಾರಸುದಾರನಾಗಿ ಪಡೆಯುತ್ತದೆ. hosts ನಮೂದು ರೀಬೂಟ್, ಮರು-ರಫ್ತು ಮತ್ತು 'ಕ್ಲೈಂಟ್ ಮರುಸ್ಥಾಪಿಸಿ' ಸರಿಪಡಿಸುವಿಕೆಗಳನ್ನು ಮೀರುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಳಾಸ ಸರಿಯುವ ಪ್ರತಿ ಬಾರಿಯೂ ವೈಫಲ್ಯ ಮರಳುತ್ತದೆ. ಒಂದು ವಾರಗಳ ಕಾಲ ಹಾನಿರಹಿತವಾಗಿ ಕುಳಿತು, ನಂತರ ಅದನ್ನು ಹೊತ್ತಿದ ಪ್ರತಿ ಯಂತ್ರವನ್ನೂ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ್ದನ್ನು ನಾನು ನೋಡಿದ್ದೇನೆ, ಹೊಸ ಸ್ಥಾಪನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತಿದ್ದವು. ಈ ವಿಭಜನೆ, ಒಂದು ಗುಂಪು ವಿಫಲವಾಗಿ ಇನ್ನೊಂದು ಅದೇ ಖಾತೆಯಲ್ಲಿ ಸರಿಯಾಗಿರುವುದು, ನೀವು ಪಡೆಯುವ ಅಗ್ಗದ ಸುಳಿವು.
ಯಾದೃಚ್ಛೀಕರಣದ ವ್ಯಾಪ್ತಿಯನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಧರಿಸಿ. ಅದು ಪ್ರತಿ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಕ್ಕೂ ಸಂಭವಿಸುತ್ತದೆ. ಸ್ಥಾಪಿತ ಸುರಂಗ ತನ್ನ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಮತ್ತೆ ಪರಿಹರಿಸುವುದಿಲ್ಲ, ಸೆಷನ್ ಮಧ್ಯದಲ್ಲಿ ಸರ್ವರ್ ಬದಲಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಗಳು ಪ್ರತಿಯೊಂದೂ ಹೊಸ VPN ಹೋಸ್ಟ್ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಮುಂದಿನ ಪ್ರಯತ್ನ ಮಾತ್ರ ಮತ್ತೆ ಪರಿಹರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮಧ್ಯಾಹ್ನವಿಡೀ ಕೆಲಸ ಮಾಡುವ ಸೆಷನ್ ನಾಳಿನ ಬೆಳಗ್ಗಿನ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಸುರಂಗ ಏರಿದಾಗ ಸೇವೆ ಏನನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ
Client VPN ನೀವು ಸಂಪರ್ಕಿಸಿರುವ ವಿಳಾಸವು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನ DNS ಹೆಸರಿಗೆ ಪರಿಹರಿಸಿದ ವಿಳಾಸಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗಬೇಕೆಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಆ ಒಂದು ಷರತ್ತು ಸಂಬಂಧವಿಲ್ಲದಂತೆ ಕಾಣುವ ಹಲವು ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ: ಬೇರೆಡೆ ತೋರಿಸುವ ಕಸ್ಟಮ್ DNS ದಾಖಲೆ, ನಿಜವಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ವಿಳಾಸಕ್ಕೆ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಕಸ್ಟಮ್ ಫ್ರಂಟೆಂಡ್, ಮತ್ತು ಕಚ್ಚಾ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯಲಾದ ಪ್ರೊಫೈಲ್. AWS ಕಸ್ಟಮ್-ದಾಖಲೆ-ಜೊತೆಗೆ-ರವಾನೆ ವ್ಯವಸ್ಥೆಯನ್ನು ಇತ್ತೀಚಿನ AWS ಕ್ಲೈಂಟ್‌ಗಳೊಂದಿಗೆ ವೈಫಲ್ಯ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ. ಪರಿಶೀಲನೆ ಸಂಕುಚಿತ; ಪ್ರತಿ ಉಪನಾಮವನ್ನೂ ನಿಷೇಧಿಸಲಾಗಿದೆ ಎಂಬ ತೀರ್ಪಲ್ಲ.
ಇದು VPN ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಬಗ್ಗೆ ಸಾಮಾನ್ಯ ನಿಯಮವೂ ಅಲ್ಲ. ಸಂಖ್ಯಾತ್ಮಕ remote ಸಾಮಾನ್ಯ OpenVPN ನಿಯೋಜನೆಯಲ್ಲಿ ಸಂಪೂರ್ಣ ಮಾನ್ಯವಾಗಿದೆ, ಮತ್ತು ಅನೇಕವು ಹಾಗೆ ನಡೆಯುತ್ತವೆ. ನಿರ್ಬಂಧ ನಿರ್ವಹಿತ ವ್ಯವಸ್ಥೆಯಿಂದ ಬರುತ್ತದೆ, ಅದರ ಕೆಳಗಿನ ಪ್ರೋಟೋಕಾಲ್‌ನಿಂದ ಅಲ್ಲ.
ಇದು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಯನ್ನು ಸಡಿಲಿಸುವುದನ್ನು ತಪ್ಪು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ವಿಳಾಸ ಬದಲಾವಣೆಯ ನಂತರ ಪ್ರೊಫೈಲ್ ವಿಫಲವಾದರೆ, ಸರ್ವರ್ ಪರಿಶೀಲನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ಪರಿಹಾರ ಅಥವಾ ವಿಳಾಸ-ಹೊಂದಾಣಿಕೆಯ ಷರತ್ತನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ದೋಷವನ್ನು ಸ್ಥಳಾಂತರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದನ್ನೂ ನಂಬುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ರಫ್ತಾದ CA, ಸರ್ವರ್ ಪರಿಶೀಲನೆ ಮತ್ತು ಪರಸ್ಪರ ದೃಢೀಕರಣ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬಂದಂತೆಯೇ ಇರಿಸಿ.
ಅನುಮತಿ ಪಟ್ಟಿಗಳು, ಹೊರಹರಿವು ಮತ್ತು ಖಾಸಗಿ DNS ಮೂರು ಬೇರೆ ಬೇರೆ ಸಮಸ್ಯೆಗಳು
ಲ್ಯಾಪ್‌ಟಾಪ್ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮೊದಲು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಅನುಮತಿಸಬೇಕಾದ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಹೊರಗಿನ ಶ್ರೋತೃಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ನೆಟ್‌ವರ್ಕ್ ಮಾಲೀಕರಿಗೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು, ಸಾರಿಗೆ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಪೋರ್ಟ್ ನೀಡಿ, ನಂತರ ಅವರ ನಿಯಂತ್ರಣವು ಸೇವೆಯ DNS ವರ್ತನೆಯನ್ನು ಅನುಸರಿಸಬಹುದೇ ಎಂದು ಕೇಳಿ. ಒಂದು ಸೆರೆಹಿಡಿದ ವಿಳಾಸವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ನಿಯಮವು ಬರೆಯದ ಅವಧಿಯ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್. ನಿಯಂತ್ರಣವು ಬದಲಾಗದ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಮಾತ್ರ ಸ್ವೀಕರಿಸಿದರೆ, ಮೌನವಾಗಿ ಉತ್ತರವನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡುವ ಬದಲು ರೋಲ್‌ಔಟ್‌ಗೆ ಮೊದಲು ಆ ಕೊರತೆಯನ್ನು ಇತ್ಯರ್ಥಪಡಿಸಿ.
ಸುರಂಗ ಏರಿದ ನಂತರದ ವಿನಂತಿಗಳಿಗೆ ಸ್ಥಿರ ಮೂಲ ವಿಳಾಸ ಬೇಕಾದ ಪಾಲುದಾರನಿಗೆ ಬೇರೆ ಅಗತ್ಯವಿದೆ: ಹೊರಹರಿವು. ವೆಬ್‌ಸೈಟ್ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದು ಅಪ್ಲಿಕೇಶನ್ ಮಾರ್ಗ ಮತ್ತು ವಿಭಜಿತ-ಸುರಂಗ ನೀತಿಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಿದ ವಿಳಾಸದ ಮೇಲೆ ಅಲ್ಲ. ವಿಭಜಿತ-ಸುರಂಗ ಸಂಚಾರವು AWS ಅನ್ನು ಸ್ಪರ್ಶಿಸದೇ ಇರಬಹುದು.
ಸುರಂಗದೊಳಗಿನ ಖಾಸಗಿ DNS ಮೂರನೇ ಪದರ. ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ನೀಡಲಾದ ಪರಿಹಾರಕವು ಸಂಪರ್ಕದ ನಂತರ ಆಂತರಿಕ ಹೆಸರುಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ; ಸುರಂಗ ಇರುವ ಮೊದಲು ಅದು ಸಾರ್ವಜನಿಕ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಪರಿಹರಿಸಲಾರದು. ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪರಿಹಾರ ವೈಫಲ್ಯ ಮತ್ತು ಆಂತರಿಕ ಅಪ್ಲಿಕೇಶನ್ ಪರಿಹಾರ ವೈಫಲ್ಯ ಬೇರೆ ಬೇರೆ ಹಂತಗಳಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ನಿಮ್ಮನ್ನು ತಪ್ಪು ಲಾಗ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ವಿಳಾಸ ಕುಟುಂಬ ಅದೇ ಪಟ್ಟಿಗೆ ಸೇರುತ್ತದೆ. IPv4 ಉತ್ತರವು IPv6 ಅಥವಾ ದ್ವಿ-ಸ್ಟಾಕ್ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನ ಅನುಮತಿಸಿದ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದು ಕುಟುಂಬದಲ್ಲಿ ತೆಗೆದ ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ಇನ್ನೊಂದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಏನನ್ನೂ ಪಿನ್ ಮಾಡದೆ ಸಂಪರ್ಕವನ್ನು ಪರಿಶೀಲಿಸಿ
ರಫ್ತಾದಂತೆಯೇ ಇರುವ ಪ್ರೊಫೈಲ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಅದು ನಿಜವಾಗಿ ಏನನ್ನು ಕೇಳುತ್ತದೆ ಎಂಬುದನ್ನು ಓದಿ:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'ನಂತರ ಮೂರು ವಿಷಯಗಳನ್ನು ಹೋಲಿಸಿ: ಪ್ರೊಫೈಲ್ ಹೊಂದಿರುವ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರು, ಹೊಸ ಪ್ರಯತ್ನಕ್ಕಾಗಿ ಕ್ಲೈಂಟ್ ವರದಿ ಮಾಡುವ ವಿಳಾಸ, ಮತ್ತು ಹೆಸರು ಈಗ ಯಾವುದಕ್ಕೆ ಪರಿಹರಿಸುತ್ತದೆ. ಪರಿಹರಿಸುವ ಹೆಸರು ದಾಖಲೆ ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ; ಸಾರಿಗೆ ಮತ್ತು ದೃಢೀಕರಣ ಪ್ರತ್ಯೇಕ, ಮತ್ತು ಎಂಡ್‌ಪಾಯಿಂಟ್ ping ಗೆ ಉತ್ತರಿಸಬೇಕಿಲ್ಲ. ಮಧ್ಯದ ಅಂಶಕ್ಕೆ ಕ್ಲೈಂಟ್‌ನ ಸ್ವಂತ ಲಾಗ್ ಮಾತ್ರ ಮೂಲ, ಆದ್ದರಿಂದ ಪ್ರಯತ್ನದ ಸಮಯದಲ್ಲಿ ಅದನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ, ನಂತರವಲ್ಲ.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
ಇಂದು ಉತ್ತರಿಸುವ ವಿಳಾಸ ಇಂದಿನ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯ; ಹೆಸರೇ ಸೇವೆ ಮಾನ್ಯವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವ ವಸ್ತು. ವೀಕ್ಷಣೆಯನ್ನು ದಾಖಲಿಸಿ, ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೊಂದಿರುವವರಿಗೆ ಕಳುಹಿಸಿ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಅನ್ನು ಹೆಸರಿನ ಕಡೆ ತೋರಿಸುತ್ತಾ ಬಿಡಿ.
ಬಿಡಬೇಕಾದ ಎರಡು ಅಭ್ಯಾಸಗಳು: ನಿಂತ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ದಾಟಲು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು, ಮತ್ತು ಒಂದು ಅಂಟಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬ ಆಶೆಯಲ್ಲಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರಿನ ಮುಂದೆ ಲೇಬಲ್‌ಗಳನ್ನು ರಾಶಿ ಹಾಕುವುದು. ಲೇಬಲ್ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ದಾಖಲೆಯ ಮೂಲಕ ಪರಿಹರಿಸುತ್ತದೆ ಅಥವಾ ಸಮಸ್ಯೆ ಬೇರೆಡೆ ಇದೆ. ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಉದ್ದವಾದ ಹೋಸ್ಟ್‌ನಾಮ್ ಅಲ್ಲ, ನಿಖರವಾದ ಪ್ರಶ್ನೆ ಮತ್ತು ಸಂಪರ್ಕ ಘಟನೆಯನ್ನು ಕಳುಹಿಸಿ.
ಮುಚ್ಚುವ ಮೊದಲು: ಪ್ರೊಫೈಲ್ ಇನ್ನೂ ರಫ್ತಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹೆಸರನ್ನು ಹೊಂದಿದೆ, ಯಾವುದೇ hosts ಫೈಲ್ ವಿಳಾಸವನ್ನು ಪಿನ್ ಮಾಡುವುದಿಲ್ಲ, ಕ್ಲೈಂಟ್ ಲಾಗ್‌ನ remote ಪ್ರಸ್ತುತ ಪರಿಹಾರಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮ ವಿಳಾಸವಲ್ಲದೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಮುಂದಿನ ವ್ಯಕ್ತಿಗೆ ಹಸ್ತಾಂತರಿಸಬೇಕಾದ ಸ್ಥಿತಿಯೂ ಇದೇ.