AWS Client VPN ಸಂಪರ್ಕಗೊಂಡಿದೆ, ಆದರೆ EC2 ಇನ್ನೂ ಪ್ರತಿಕ್ರಿಯಿಸುವುದಿಲ್ಲ
ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದರೆ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ SAML ಲಾಗಿನ್ ಕೆಲಸ ಮಾಡಿದೆ ಎಷ್ಟೇ. ಅನುಮತಿ ನಿಯಮಗಳು, endpoint ಮಾರ್ಗಗಳು ಮತ್ತು ಭದ್ರತಾ ಗುಂಪುಗಳು ಖಾಸಗಿ ಹೋಸ್ಟ್‌ಗೆ ಇರುವ ದಾರಿಯ ಪ್ರತ್ಯೇಕ ಭಾಗವನ್ನು ಕಾಯುತ್ತವೆ.
ನನ್ನ ಲ್ಯಾಪ್‌ಟಾಪ್ ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ತೋರಿಸುತ್ತಿತ್ತು. AWS Client VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಹಸಿರು ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸಿತು, endpoint ಒಂದು ಸೆಷನ್ ದಾಖಲಿಸಿತು, ಆದರೂ ಖಾಸಗಿ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿರುವ EC2 ಇನ್‌ಸ್ಟನ್ಸ್‌ನಲ್ಲಿ MongoDB ಪೋರ್ಟ್ ತೆರೆಯಲು ನನಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಸ್ಪಷ್ಟವಾಗಿ ಏನೂ ಮುರಿದಿರಲಿಲ್ಲ: ಪ್ರಮಾಣಪತ್ರ ಮಾನ್ಯವಾಗಿತ್ತು, ಪ್ರೊಫೈಲ್ ಕನ್ಸೋಲ್‌ನಿಂದ ಬಂದಿತ್ತು, ಟನೆಲ್ ಸಂಚಾರವನ್ನು ಸಾಗಿಸುತ್ತಿತ್ತು. ತಪ್ಪು ನನ್ನದೇ ಆಗಿತ್ತು, ಏಕೆಂದರೆ ನಾನು ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂಬುದನ್ನು ಅಧಿಕೃತ ಎಂದು ಓದುತ್ತಿದ್ದೆ.
ಲಾಗಿನ್ ನಿಖರವಾಗಿ ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಈ ಗುರುತು ಸೆಷನ್ ಸ್ಥಾಪಿಸಬಹುದೇ? ಅದರ ನಂತರದ ಎಲ್ಲವನ್ನೂ ನಿಮ್ಮ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಎಂದಿಗೂ ನೋಡದ ಪ್ರತ್ಯೇಕ ನಿಯಮಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ದೃಢೀಕರಣ ಪಾಸಾಗುವ ಸೆಷನ್ ಮತ್ತು ತಲುಪುವ ಪ್ಯಾಕೆಟ್ ಎರಡು ವಿಭಿನ್ನ ಯಶಸ್ಸುಗಳು, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಅಂತರವೇ VPN ಆನ್ ಆಗಿದೆ ಆದರೆ ಹೋಸ್ಟ್ ತಲುಪುತ್ತಿಲ್ಲ ಎಂಬ ಬಹುತೇಕ ದೂರುಗಳು ಇರುವ ಜಾಗ.
ಕೆಳಗಿನ ಪರಿಶೀಲನೆಗಳು ನಾನು ಈಗ ಬಳಸುವ ಕ್ರಮ.
ಸಂಪರ್ಕಗೊಂಡ ಸೆಷನ್ ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ
ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯದಲ್ಲಿ endpoint ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತನ್ನ trust store ವಿರುದ್ಧ ಪರಿಶೀಲಿಸುತ್ತದೆ, ಅಥವಾ SAML ಸಂರಚಿಸಿದಾಗ ಬ್ರೌಸರ್ ಅನ್ನು ನಿಮ್ಮ ಗುರುತು ಪೂರೈಕೆದಾರರಿಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಅದು ಪಾಸಾದರೆ, ಕ್ಲೈಂಟ್ endpoint ನ ಕ್ಲೈಂಟ್ CIDR ನಿಂದ ವಿಳಾಸ ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಕನ್ಸೋಲ್ ಸಕ್ರಿಯ ಸಂಪರ್ಕ ತೋರಿಸುತ್ತದೆ. ಆ ವಿನಿಮಯದ ಯಾವುದೇ ಹಂತದಲ್ಲಿ 10.0.4.17 ಅನ್ನು 27017 ಪೋರ್ಟ್‌ನಲ್ಲಿ ತಲುಪಬಹುದೇ ಎಂದು ಯಾರೂ ಕೇಳುವುದಿಲ್ಲ.
ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಅನುಮತಿ endpoint ನಲ್ಲಿ ಪ್ರತ್ಯೇಕ ವಸ್ತು. ಪ್ರತಿ ಹರಿವೂ ಅನುಮತಿ ನಿಯಮಗಳೊಂದಿಗೆ ಹೋಲಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ನಿಯಮವೂ ಗಮ್ಯಸ್ಥಾನ CIDR ಅನ್ನು ನಿಯಮ ನೀಡಲಾದ ಗುಂಪಿನೊಂದಿಗೆ ಜೋಡಿಸುತ್ತದೆ. ಯಾವುದೇ ನಿಯಮ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆವರಿಸದಿದ್ದರೆ, endpoint ಸೆಷನ್ ಸ್ವೀಕರಿಸಿ ಸಂಚಾರವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಬ್ಯಾನರ್ ಇಲ್ಲ, ಮರುಸಂಪರ್ಕ ಲೂಪ್ ಇಲ್ಲ, ಮತ್ತು ನಿರಾಕರಿಸಲಾಗಿದೆ ಎಂದು ಹೇಳುವ ಯಾವುದೂ ಕ್ಲೈಂಟ್ UI ನಲ್ಲಿ ಇಲ್ಲ.
ಅನುಮತಿ ನಿಯಮವನ್ನು VPC ಯೊಂದಿಗೆ ಅಲ್ಲ, ಸಂಪನ್ಮೂಲದೊಂದಿಗೆ ಹೋಲಿಸಿ
ನಿಯಮಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಇನ್‌ಸ್ಟನ್ಸ್‌ಗೆ ನಿಜವಾಗಿ ಇರುವ ವಿಳಾಸದ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ:
aws ec2 describe-client-vpn-authorization-rules \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ಔಟ್‌ಪುಟ್ ಪ್ರತಿ ನಿಯಮಕ್ಕೂ ಗಮ್ಯಸ್ಥಾನ CIDR ಮತ್ತು ಗುಂಪು ID ತೋರಿಸುತ್ತದೆ. ಅದರಲ್ಲಿ ಎರಡು ವೈಫಲ್ಯಗಳು ಅಡಗಿವೆ. ನಿಯಮ 10.0.0.0/16 ಗೆ ಅನುಮತಿ ನೀಡಬಹುದು, ಆದರೆ ಇನ್‌ಸ್ಟನ್ಸ್ 10.1.0.0/16 ರ ಪೀರ್ ಮಾಡಿದ VPC ಯಲ್ಲಿದೆ; ಪೀರಿಂಗ್ ಮಾರ್ಗ ಇದೆ, ಆದರೆ ಎರಡನೇ ಶ್ರೇಣಿಗೆ ಯಾರೂ ಅನುಮತಿ ನಿಯಮ ಬರೆದಿಲ್ಲ. ಅಥವಾ ನಿಯಮವು ಬಳಕೆದಾರರು ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಸದಸ್ಯರಾಗಿರುವ ಆದರೆ endpoint ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಗುಂಪಿನಲ್ಲಿ ಇಲ್ಲದ ಡೈರೆಕ್ಟರಿ ಗುಂಪನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಗಮ್ಯಸ್ಥಾನವನ್ನು ಆವರಿಸುವ ಅತ್ಯಂತ ಕಿರಿದಾದ ನಿಯಮ ಬರೆಯಿರಿ, ಮತ್ತು ಎರಡನೇ CIDR ನಿಜವಾಗಿ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಎರಡನೇ ನಿಯಮ ಸೇರಿಸಿ. ತ್ವರಿತ ಆರಂಭದಿಂದ ಬಂದ ವಿಶಾಲ 0.0.0.0/0 ನಿಯಮ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೇ ಅದು ಉತ್ಪಾದನೆಯವರೆಗೂ ಉಳಿದು ಮಾದರಿಯನ್ನು ಮರೆಮಾಡುತ್ತದೆ.
ಪ್ಯಾಕೆಟ್ ಚಲಿಸುತ್ತದೆಯೇ ಎಂದು ಎರಡು ಮಾರ್ಗ ಕೋಷ್ಟಕಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ
endpoint ಮಾರ್ಗವು ಗಮ್ಯಸ್ಥಾನ CIDR ಅನ್ನು endpoint ಸಂಬಂಧಿಸಿದ ಸಬ್‌ನೆಟ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ನಕ್ಷೆ ಮಾಡುತ್ತದೆ. ಅದು ಅರ್ಧ ದಾರಿ. ಸಬ್‌ನೆಟ್‌ನ ಸ್ವಂತ ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೇಗೆ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬೇಕೆಂದು ಇನ್ನೂ ತಿಳಿದಿರಬೇಕು, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವು ಪೀರಿಂಗ್ ಸಂಪರ್ಕ, ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ಅಥವಾ ಸೈಟ್-ಟು-ಸೈಟ್ ಟನೆಲ್ ಮೂಲಕ ತಲುಪಬಹುದಾದ ಆನ್-ಪ್ರೆಮೈಸಸ್ ಶ್ರೇಣಿಯ ಹಿಂದೆ ಇರುವ ಕ್ಷಣದಲ್ಲಿ ಅದು ಮುಖ್ಯವಾಗುತ್ತದೆ.
aws ec2 describe-client-vpn-routes \
--client-vpn-endpoint-id cvpn-endpoint-0a1b2c3d4e5f6a7b8ಗಮ್ಯಸ್ಥಾನವು ಸಂಪನ್ಮೂಲದ CIDR ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಮತ್ತು ಗುರಿಯು ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ ಆಗಿರುವ ಮಾರ್ಗವನ್ನು ಹುಡುಕಿ. ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಸೇರಿಸಿ. ಇದ್ದು ಹೋಸ್ಟ್ ಇನ್ನೂ ಮೌನವಾಗಿದ್ದರೆ, ಅಂತರ VPC ಬದಿಯಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಸಂಬಂಧಿತ ಸಬ್‌ನೆಟ್‌ನ ಮಾರ್ಗ ಕೋಷ್ಟಕದೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಕ್ಲೈಂಟ್ ಬದಿಯ ಒಂದು ಸೆಟ್ಟಿಂಗ್ ಟನೆಲ್ ಮುರಿಯದೆ ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಮುರಿಯುತ್ತದೆ: route-nopull ಹೊಂದಿರುವ ಪ್ರೊಫೈಲ್. ಈ ಸೂಚನೆ OpenVPN ಆಧಾರಿತ ಕ್ಲೈಂಟ್‌ಗೆ ಸರ್ವರ್ ತಳ್ಳುವ ಮಾರ್ಗಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಲು ಹೇಳುತ್ತದೆ, ಹೀಗಾಗಿ ಇಂಟರ್‌ಫೇಸ್ endpoint ನ ಸ್ವಂತ ವಿಳಾಸದೊಂದಿಗೆ ಮಾತ್ರ ಏಳುತ್ತದೆ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಮಾರ್ಗವೇ ಇರುವುದಿಲ್ಲ. Linux ನಲ್ಲಿ ip route show ಅಥವಾ macOS ನಲ್ಲಿ netstat -rn ಬಳಸಿ tun ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಮಾರ್ಗ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ರಫ್ತು ಮಾಡಿದ ಪ್ರೊಫೈಲ್‌ನಿಂದ route-nopull ತೆಗೆದು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳು ಅನ್ವಯವಾಗುವಂತೆ.
ಭದ್ರತಾ ಗುಂಪುಗಳು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ನೋಡುವುದಿಲ್ಲ
ಇದು ನಾನು ಒಂದು ಮಧ್ಯಾಹ್ನ ತಪ್ಪಾಗಿ ಹಿಡಿದಿದ್ದ ಭಾಗ. ಸಬ್‌ನೆಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದ IPv4 endpoint ಗೆ, ಸೇವೆಯು ಕ್ಲೈಂಟ್‌ನ ಮೂಲ ವಿಳಾಸವನ್ನು ಆ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ endpoint ನ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸುತ್ತದೆ. ಇನ್‌ಸ್ಟನ್ಸ್‌ಗೆ ತಲುಪುವ ಪ್ಯಾಕೆಟ್ ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ತೋರಿಸಿದ ವಿಳಾಸವನ್ನು ಹೊತ್ತಿರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಪೂಲ್, ಹೇಳುವುದಾದರೆ 172.16.0.0/22, ಗೆ ಅನುಮತಿ ನೀಡುವ ಭದ್ರತಾ ಗುಂಪಿನ ನಿಯಮ ಯಾವುದಕ್ಕೂ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.
ಪೋರ್ಟ್‌ಗೆ ಕ್ಲೈಂಟ್ CIDR ನಿಂದ ಅಲ್ಲ, ಸಂಬಂಧದ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಜೋಡಿಸಲಾದ endpoint ನ ಭದ್ರತಾ ಗುಂಪಿನಿಂದ ಅನುಮತಿ ನೀಡಿ. ಗುಂಪನ್ನು ಉಲ್ಲೇಖಿಸುವುದು ವಿಳಾಸವನ್ನು ಗಟ್ಟಿಯಾಗಿ ಕೋಡ್ ಮಾಡುವುದಕ್ಕಿಂತ ದೀರ್ಘಕಾಲ ಉಳಿಯುತ್ತದೆ, ಏಕೆಂದರೆ ಇಂಟರ್‌ಫೇಸ್ ವಿಳಾಸ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ACL ಗಳು ಸ್ಥಿತಿರಹಿತ, ಆದ್ದರಿಂದ ಕಸ್ಟಮ್ ನಮೂದುಗಳಿರುವಲ್ಲಿ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಎರಡೂ ದಿಕ್ಕುಗಳು ಹರಿವಿಗೆ ಅನುಮತಿ ನೀಡಬೇಕು.
ಇನ್‌ಸ್ಟನ್ಸ್‌ನ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೂ ಸಂಪರ್ಕಿಸಿ. ಸಾರ್ವಜನಿಕ IP ಪ್ಯಾಕೆಟ್ ಅನ್ನು VPC ಯಿಂದ ಹೊರಗೆ ಕರೆದೊಯ್ದು ಬೇರೆ ನಿಯಮಗಳಿರುವ ಬೇರೆ ದಾರಿಯಲ್ಲಿ ಒಳಗೆ ತರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಪರೀಕ್ಷೆ ಖಾಸಗಿ ದಾರಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲುವ ಪ್ರತ್ಯೇಕತೆಯ ಕ್ರಮ
ಇವುಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಒಂದು ವಿಫಲವಾದಲ್ಲಿ ಅಲ್ಲೇ ನಿಲ್ಲಿ. ಪ್ರತಿ ಹೆಜ್ಜೆಯೂ ಎಲ್ಲಾ ಪದರಗಳನ್ನಲ್ಲ, ಒಂದು ಪದರವನ್ನು ಹೊರಗಿಡುತ್ತದೆ.
- ಸೆಷನ್ ಯಾವ ಗುರುತನ್ನು ಬಳಸಿತು ಮತ್ತು endpoint ಯಾವ ಗುಂಪನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಒಂದು trust store ನ ಪ್ರಮಾಣಪತ್ರವು ಡೈರೆಕ್ಟರಿಯಿಂದ ಬಂದ SAML ಪ್ರತಿಪಾದನೆಯಂತೆಯೇ ಅದೇ ಪ್ರಿನ್ಸಿಪಾಲ್ ಅಲ್ಲ.
- ಅನುಮತಿ ನಿಯಮವು ಆ ಗುಂಪಿಗೆ ಸಂಪನ್ಮೂಲದ CIDR ಅನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
- endpoint ಮಾರ್ಗವು ಇದೆ ಮತ್ತು ಸಂಬಂಧಿತ ಸಬ್ನೆಟ್ ಅನ್ನು ಗುರಿಯಾಗಿಸುತ್ತದೆ ಎಂದು, ನಂತರ ಸಬ್ನೆಟ್ ಮಾರ್ಗ ಕೋಷ್ಟಕವು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಬಲ್ಲದು ಎಂದು ಖಚಿತಪಡಿಸಿ.
- ಭದ್ರತಾ ಗುಂಪು ಪೋರ್ಟ್ ಅನ್ನು ಕ್ಲೈಂಟ್ ಪೂಲ್‌ನಿಂದ ಅಲ್ಲ, endpoint ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.
- ಅಪ್ಲಿಕೇಶನ್ ಸಮಸ್ಯೆಯನ್ನು ಕ್ಲೈಂಟ್ ಮಾರ್ಗದ ಸಮಸ್ಯೆಯಿಂದ ಬೇರ್ಪಡಿಸಲು VPC ಯ ಒಳಗಿನಿಂದ, ಅದೇ ಸಬ್‌ನೆಟ್‌ನ ಇನ್ನೊಂದು ಇನ್‌ಸ್ಟನ್ಸ್‌ನಲ್ಲಿ SSM ಸೆಷನ್ ಬಳಸಿ ಪರೀಕ್ಷಿಸಿ.
ಹೆಜ್ಜೆಗಳು ನಿರ್ಣಾಯಕವಲ್ಲದಿದ್ದಾಗ, ನಾನು ಈ ಕೋಷ್ಟಕವನ್ನು ಅವಲಂಬಿಸುತ್ತೇನೆ:
| Symptom | Layer to inspect |
|---|---|
| Client shows connected, host times out, no byte growth on the interface | Authorization rule, then security group |
| Ping fails but a TCP connect to the port succeeds | ICMP is blocked; not an access failure |
| Tunnel reconnects every few minutes | Two machines sharing one client certificate |
| Works on one laptop, fails on another | Local profile has route-nopull or stale pushed routes |
ಖಾತೆಯ ಎರಡು ವಿವರಗಳು ಅನುಮತಿ ವೈಫಲ್ಯದಂತೆ ಕಾಣುವ ಲಕ್ಷಣಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೂ ಪ್ರತ್ಯೇಕ ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಬೇಕು; ಒಂದನ್ನು ಎರಡು ಯಂತ್ರಗಳಲ್ಲಿ ಹಂಚಿಕೊಂಡರೆ ಸೆಷನ್‌ಗಳು ಪರಸ್ಪರ ಸ್ಥಳಾಂತರಿಸುತ್ತವೆ, ಮತ್ತು ಫಲಿತಾಂಶ ನಿರಾಕರಣೆಯಲ್ಲ, ಮರುಸಂಪರ್ಕ ಲೂಪ್. ಹೊಸ endpoint ರಚಿಸಿದಾಗ ಕನ್ಸೋಲ್ DNS ಹೆಸರನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದನ್ನು ಕೆಲವು ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿಗಳು endpoint ಪುಟದಲ್ಲಿ ತೋರಿಸಿದ ಯಾದೃಚ್ಛಿಕ ಪೂರ್ವಪ್ರತ್ಯಯದೊಂದಿಗೆ ಮಾತ್ರ ಸ್ವೀಕರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಮತ್ತೆ ನಿರ್ಮಿಸುವ ಬದಲು ಪೂರ್ಣ ಹೆಸರನ್ನು ನಕಲಿಸಿ.
ಐದನೇ ಹೆಜ್ಜೆ ನಿಮ್ಮನ್ನು ಸಿಕ್ಕಿಸಿದರೆ, ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು endpoint ನ ಸಂಪರ್ಕ ಲಾಗ್ ತೆಗೆದು ಅನುಮತಿ ನಮೂದುಗಳನ್ನು ಓದಿ. ಲಾಗ್ ಪರಿಶೀಲಿಸಿದ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಹೊಂದಿಕೆಯಾದ ಅಥವಾ ಆಗದ ನಿಯಮವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ನಾಲ್ಕು ಪದರಗಳ ಪ್ರಶ್ನೆಯನ್ನು ಒಂದೇ ಉತ್ತರಕ್ಕೆ ಇಳಿಸುತ್ತದೆ.