ಆಂತರಿಕ ALB, ಸಾರ್ವಜನಿಕ DNS ಹೆಸರು: ಅದು ನಿಜವಾಗಿಯೂ ಬಹಿರಂಗವಾಗಿದೆಯೇ?
ಸಾರ್ವಜನಿಕ ರಿಝಾಲ್ವರ್ ಆಂತರಿಕ AWS ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ಗೆ ಖಾಸಗಿ ವಿಳಾಸಗಳನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು. ಬಹಿರಂಗ ಎಂದು ಕರೆಯುವ ಮೊದಲು ಸ್ಕೀಮ್, ಮಾರ್ಗಗಳು ಮತ್ತು ಲಿಸನರ್ ಪರಿಶೀಲಿಸಿ.
ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ವಿರುದ್ಧ ಸಾರ್ವಜನಿಕ DNS ಲುಕಪ್ ನಡೆಸಿದರೆ ಖಾಸಗಿ ವಿಳಾಸ ಹಿಂತಿರುಗಬಹುದು, ಇದು ದಾಖಲೆ ಯಾವುದಕ್ಕೆ ಎಂದು ಪರಿಶೀಲಿಸುವವರೆಗೆ ತಪ್ಪು ಸಂರಚನೆಯಂತೆ ಕಾಣುತ್ತದೆ. ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಹೆಸರುಗಳು ಸಾರ್ವಜನಿಕವಾಗಿ ಪರಿಹರಿಸಬಹುದಾದರೂ ಅವುಗಳ ನೋಡ್ಗಳು ಖಾಸಗಿ ವಿಳಾಸಗಳನ್ನು ಮಾತ್ರ ಹೊಂದಿರುತ್ತವೆ ಎಂದು AWS ದಾಖಲಿಸುತ್ತದೆ. ರಿಝಾಲ್ವರ್ ಸೇವೆ ಎಲ್ಲಿದೆ ಎಂದು ಉತ್ತರಿಸಿತು; ಅದು ಮಾರ್ಗವನ್ನು ರಚಿಸಲಿಲ್ಲ, ಭದ್ರತಾ ಗುಂಪನ್ನು ತೆರೆಯಲಿಲ್ಲ ಮತ್ತು ಯಾರನ್ನೂ ದೃಢೀಕರಿಸಲಿಲ್ಲ. ಆ ಉತ್ತರ ಸಮಸ್ಯೆಯೇ ಎಂಬುದು ನೀವು ಕ್ರಮವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸಂಗತಿಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ.
ಮೊದಲ ಹಂತ: IP ಅಲ್ಲ, ಸ್ಕೀಮ್ ಓದಿ
ಸ್ಕೀಮ್ ಕ್ಷೇತ್ರವು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನ ತನ್ನ ಗಡಿಯ ಬಗ್ಗೆ ತನ್ನದೇ ಹೇಳಿಕೆ. aws elbv2 describe-load-balancers --names app-internal internal ಅಥವಾ internet-facing ಮೌಲ್ಯದ Scheme ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಜೊತೆಗೆ IPv4 ಅಥವಾ ದ್ವಿಗುಣ ಸ್ಟ್ಯಾಕ್ಗೆ ವಿಳಾಸ ಪ್ರಕಾರ. ಇಂಟರ್ನೆಟ್ ಕಡೆಗಿನ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಖಾಸಗಿ ಗುರಿಗಳಿಗೆ ಮುಂದಕ್ಕೆ ರವಾನಿಸಬಹುದು, ಆದ್ದರಿಂದ ಖಾಸಗಿ ಬ್ಯಾಕೆಂಡ್ ವಿಳಾಸಗಳನ್ನು ನೋಡುವುದು ಮುಂಭಾಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.
ಬೇರೆ ಯಾವುದನ್ನೂ ನೋಡುವ ಮೊದಲು ಸ್ಕೀಮ್ ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪ್ರತಿಯೊಂದು ತೀರ್ಮಾನವೂ ಅದನ್ನು ಅವಲಂಬಿಸಿದೆ. ಯಾವ ನಿಯಂತ್ರಣಗಳಿವೆ ಎಂಬುದನ್ನೂ ಅದು ಹೇಳುತ್ತದೆ, ಭದ್ರತಾ ಗುಂಪುಗಳು ಮತ್ತು ಲಿಸನರ್ ನಿಯಮಗಳಿಂದ ಆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಪ್ರಕಾರದ ವೈಶಿಷ್ಟ್ಯಗಳವರೆಗೆ. ಹಳೆಯ ಕನ್ಸೋಲ್ ಸ್ಕ್ರೀನ್ಶಾಟ್ನಿಂದ ನಕಲಿಸಿದ ಸ್ಕೀಮ್ ಯಾವುದೇ ಟಿಪ್ಪಣಿ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು. ಅದನ್ನು API ಯಿಂದ ಮತ್ತೆ ಓದಿ ಮೌಲ್ಯವನ್ನು ಟಿಕೆಟ್ಗೆ ಅಂಟಿಸಿ.
ಎರಡನೇ ಹಂತ: ಹೆಸರು ಯಾವುದಕ್ಕೆ ಪರಿಹಾರವಾಗುತ್ತದೆ ಎಂದು ನೋಡಿ
VPC ಯ ಹೊರಗಿನಿಂದ dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com ಬಳಸಿ ಪ್ರಶ್ನಿಸಿ ಮತ್ತು ಉತ್ತರಗಳು 10.0.0.0/8, 172.16.0.0/12 ಅಥವಾ 192.168.0.0/16 ನಲ್ಲಿವೆಯೇ ಎಂದು ಗಮನಿಸಿ. ಸಾರ್ವಜನಿಕ ರಿಝಾಲ್ವರ್ನಿಂದ ಖಾಸಗಿ ಉತ್ತರವು ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಹೆಸರಿಗೆ ನಿರೀಕ್ಷಿತ ವರ್ತನೆ; ವಿಳಾಸವು ಇಂಟರ್ನೆಟ್ನಿಂದ ಮಾರ್ಗೀಕರಿಸಬಹುದು ಎಂಬುದಕ್ಕೆ ಇದು ಸಾಕ್ಷ್ಯವಲ್ಲ.
ಅದೇ ಹೆಸರನ್ನು VPC ಒಳಗಿನಿಂದ ಪರಿಹರಿಸಿ ಮತ್ತು ಹೋಲಿಸಿ. ಎರಡು ಉತ್ತರಗಳು ಭಿನ್ನವಾದರೆ, ನೀವು ಸ್ಪ್ಲಿಟ್-ಹೊರೈಜನ್ ನಾಮಕರಣ ನೋಡುತ್ತಿದ್ದೀರಿ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸ ವಿನ್ಯಾಸದ ವಿವರ, ಸೋರಿಕೆ ಅಲ್ಲ.
ಮೂರನೇ ಹಂತ: ಅದನ್ನು ತಲುಪಬಹುದಾದ ಮಾರ್ಗಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ
ಖಾಸಗಿ ವಿಳಾಸವು ಮಾರ್ಗ ಮತ್ತು ಭದ್ರತಾ ನಿಯಮ ಇರುವ ಎಲ್ಲಿಂದಲೂ ತಲುಪಬಹುದು. ಅವುಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿ: ಸೈಟ್-ಟು-ಸೈಟ್ VPN, ಕ್ಲೈಂಟ್ VPN, VPC ಪಿಯರಿಂಗ್, ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ಲಗತ್ತುಗಳು, Direct Connect ಮತ್ತು VPC ಒಳಗಿನ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಬ್ಯಾಸ್ಟಿಯನ್. ಅವುಗಳಲ್ಲಿ ಒಂದು ಉದ್ದೇಶಿತ ಮಾರ್ಗ, ಉಳಿದವು ಆಕ್ರಮಣಕಾರ ಹುಡುಕುವ ಮಾರ್ಗಗಳು.
ನಂತರ ಪ್ರತಿ ಮಾರ್ಗದ ನಿಯಂತ್ರಣಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನಲ್ಲಿನ ಭದ್ರತಾ ಗುಂಪುಗಳು, ಸಬ್ನೆಟ್ಗಳಲ್ಲಿನ ನೆಟ್ವರ್ಕ್ ACL ಮತ್ತು ಮಾರ್ಗವನ್ನು ಉಂಟುಮಾಡುವ ರೂಟಿಂಗ್. ಬಹಿರಂಗವಾದ ಆಂತರಿಕ ಸೇವೆಯ ಬಗ್ಗೆ ವರದಿಯಾದ ಹೆಚ್ಚಿನ ಪ್ರಕರಣಗಳು ಇಲ್ಲಿಯೇ ಪರಿಹಾರವಾಗುತ್ತವೆ, ಒಂದೋ ಉದ್ದೇಶಿಸದ ಪಿಯರಿಂಗ್ ಇತ್ತು ಅಥವಾ ಮಾರ್ಗ ಉದ್ದೇಶಿತವಾಗಿತ್ತು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ಗೆ ದೃಢೀಕರಣ ಇರಲಿಲ್ಲ.
ನಾಲ್ಕನೇ ಹಂತ: ಲಿಸನರ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಸೇವೆಯನ್ನು ತಲುಪಬಾರದ ನೆಟ್ವರ್ಕ್ನಿಂದ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ದೃಢಪಡಿಸಿ. ನಂತರ ತಲುಪಬೇಕಾದ ನೆಟ್ವರ್ಕ್ನಿಂದ ಪ್ರಯತ್ನಿಸಿ ಮತ್ತು ಲಿಸನರ್ ತಲುಪುತ್ತೀರಿ ಎಂದು ದೃಢಪಡಿಸಿ. ಆ ಎರಡು ಫಲಿತಾಂಶಗಳು ನೆಟ್ವರ್ಕ್ ತಲುಪುವಿಕೆಯನ್ನು ಅಪ್ಲಿಕೇಶನ್ ವರ್ತನೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ ಮತ್ತು ಬಹಿರಂಗ ಪ್ರಶ್ನೆಗೆ ಮುಖ್ಯವಾದ ಏಕೈಕ ಸಾಕ್ಷ್ಯ ಅವು.
ತಲುಪಬಹುದಾದ ಲಿಸನರ್ ಪ್ರವೇಶಿಸಬಹುದಾದ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸಮಾನವಲ್ಲ. TLS ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ನೀತಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ದೃಢೀಕರಣ ಮತ್ತು ಅಧಿಕಾರ ಪರಿಶೀಲಿಸಿ. ಕಾರ್ಪೊರೇಟ್ VPN ನಲ್ಲಿ ಯಾವುದೇ ಕರೆ ಮಾಡುವವರನ್ನು ಸ್ವೀಕರಿಸುವ ಆಂತರಿಕ ಸಾಧನವು ಆ VPN ನಲ್ಲಿನ ಪ್ರತಿ ಸಮಾಧಾನಗೊಂಡ ಲ್ಯಾಪ್ಟಾಪ್ಗೆ ಬಹಿರಂಗವಾಗಿದೆ, ಇದು ಇಂಟರ್ನೆಟ್ ಕಡೆಗಿನ ಅಪಾಯಕ್ಕಿಂತ ಭಿನ್ನ, ಆದರೆ ಇನ್ನೂ ಅಪಾಯ.
ನಿಯಂತ್ರಣಗಳು ಪ್ರಕಾರದಿಂದ ಬೇರೆಯಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ. ಅಪ್ಲಿಕೇಶನ್ ಪದರದ ಫೈರ್ವಾಲ್ಗಳು ಒಂದು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕುಟುಂಬಕ್ಕೆ ಸೇರುತ್ತವೆ, ಇನ್ನೊಂದಕ್ಕಲ್ಲ, ಆದ್ದರಿಂದ ಸಮಾನತೆ ಊಹಿಸುವ ಬದಲು ನಿಮ್ಮ ಮುಂದಿನ ಸ್ಕೀಮ್ ಮತ್ತು ಪ್ರಕಾರಕ್ಕೆ ನಿಜವಾಗಿ ಏನು ಲಭ್ಯ ಎಂದು ದೃಢಪಡಿಸಿ.
ಐದನೇ ಹಂತ: ಹೆಸರಿನದೇ ಮಹತ್ವ ಇದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ
ಸಾರ್ವಜನಿಕ ಪರಿಹರಿಸುವಿಕೆ ಸೇವಾ ಹೆಸರು, ಪ್ರದೇಶ ಮತ್ತು ವಿಳಾಸ ಶ್ರೇಣಿಯನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು. ಅದನ್ನು ನೀತಿ ಉತ್ತರವಿರುವ ಮಾಹಿತಿ ಬಹಿರಂಗ ಪ್ರಶ್ನೆಯಾಗಿ ಪರಿಗಣಿಸಿ, ಸ್ವಯಂಚಾಲಿತ ಘಟನೆಯಾಗಿ ಅಲ್ಲ: ಸೂಕ್ಷ್ಮ ವ್ಯಾಪಾರ ಪದಗಳನ್ನು ಸಂಪನ್ಮೂಲ ಹೆಸರುಗಳಿಂದ ಹೊರಗಿಡಿ ಮತ್ತು ನಾಮಕರಣ ಸಂಪ್ರದಾಯ ನೀವು ಬಯಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಹಿರಂಗಪಡಿಸಿದರೆ ಅಪಾಯ ದಾಖಲೆಯಲ್ಲಿ ಬಹಿರಂಗವನ್ನು ದಾಖಲಿಸಿ.
ಸಂಸ್ಥೆಗೆ ಖಾಸಗಿ ನಾಮಕರಣ ಅನುಭವ ಬೇಕಿದ್ದರೆ, ಖಾಸಗಿ ಹೋಸ್ಟ್ ಮಾಡಿದ ವಲಯವು ಸಂಬಂಧಿತ VPC ಒಳಗೆ ಮಾತ್ರ ಪರಿಹರಿಸುವ ಉಪನಾಮವನ್ನು ನೀಡಬಹುದು. ಅದು ಬಳಕೆದಾರರು ನೋಡುವ ಹೆಸರನ್ನು ಬದಲಿಸುತ್ತದೆ; ಪೂರೈಕೆದಾರರು ರಚಿಸಿದ ಹೆಸರನ್ನು ರಹಸ್ಯಗೊಳಿಸುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ.
ಉತ್ತರ ಮರೆಮಾಡಲು ವಿಳಾಸಗಳನ್ನು ಪಿನ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಬೇಡಿ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ವಿಳಾಸಗಳು ಬದಲಾಗುತ್ತವೆ, ಪಿನಿಂಗ್ TLS ಪರಿಶೀಲನೆ ಅಭ್ಯಾಸಗಳನ್ನು ಮುರಿಯುತ್ತದೆ ಮತ್ತು ನಿಜವಾಗಿ ಬೇಕಾದ ನಿಯಂತ್ರಣ ಎಂದರೆ ಯಾರು ಸಂಪರ್ಕ ಸ್ಥಾಪಿಸಬಹುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅವರಿಂದ ಏನು ಬೇಡುತ್ತದೆ. ನಾಲ್ಕು ಸಂಗತಿಗಳನ್ನು ಪರಿಶೀಲಿಸಿ, ಬರೆಯಿರಿ, ಪ್ರಶ್ನೆ ಅಸ್ಪಷ್ಟವಾಗಿರುವುದಿಲ್ಲ.