EC2 ಲಭ್ಯತೆಯ ವಲಯಗಳಾದ್ಯಂತ: VPN ಮೊದಲು ರೂಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ

ಎರಡು EC2 ಇನ್ಸ್ಟೆನ್ಸ್‌ಗಳ ನಡುವೆ VPN ಸಾಫ್ಟ್‌ವೇರ್ ಸ್ಥಾಪಿಸುವ ಮೊದಲು ಒಂದು ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಿ: ಅವು ಒಂದೇ VPC ಯಲ್ಲಿವೆಯೇ? ಹಾಗಿದ್ದರೆ, ಖಾಸಗಿ ಮಾರ್ಗ ಈಗಾಗಲೇ ಇದೆ ಮತ್ತು ವಲಯಗಳ ನಡುವಿನ ನಿಯೋಜನೆ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ ಹೆಚ್ಚಿನ ಕೆಲಸವೆಂದರೆ ಪ್ರತಿ ಸಬ್‌ನೆಟ್ ನಿಜವಾಗಿ ಯಾವ ರೂಟ್ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸುವುದು, ನಂತರ ವೈಫಲ್ಯವು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯೇ ಆಗಿತ್ತೇ ಎಂದು ಕಂಡುಹಿಡಿಯುವುದು. ಈ ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆಗೆ ಸುರಂಗ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪು ಉತ್ತರ.

ಪರಿಶೀಲನೆ 1: ಒಂದೇ VPC ಅಥವಾ ಬೇರೆ ಬೇರೆ VPC

VPC ಪ್ರಾದೇಶಿಕವಾಗಿದ್ದು ಲಭ್ಯತೆಯ ವಲಯಗಳನ್ನು ವ್ಯಾಪಿಸುತ್ತದೆ, ಆದರೆ ಪ್ರತಿ ಸಬ್‌ನೆಟ್ ನಿಖರವಾಗಿ ಒಂದು ವಲಯಕ್ಕೆ ಸೇರಿದೆ. ಒಂದೇ VPC ಯ ವಿವಿಧ ವಲಯಗಳಲ್ಲಿರುವ ಎರಡು ಇನ್ಸ್ಟೆನ್ಸ್‌ಗಳು ಇನ್ನೂ ಅದೇ ಖಾಸಗಿ ರೂಟಿಂಗ್ ಡೊಮೇನ್ ಒಳಗಿವೆ.

ಬೇರೆ ಬೇರೆ VPC ಗಳು ಪ್ರದೇಶ ಅಥವಾ ವಲಯ ಲೇಬಲ್ ಹಂಚಿಕೊಳ್ಳುವುದರಿಂದ ಮಾತ್ರ ಎಂದಿಗೂ ಖಾಸಗಿ ಮಾರ್ಗ ಪಡೆಯುವುದಿಲ್ಲ. ಆ ಸಂದರ್ಭಕ್ಕೆ ಬೆಂಬಲಿತ ಸಂಪರ್ಕ ಮತ್ತು ತನ್ನದೇ ಆದ ಮಾರ್ಗ ಹಾಗೂ ಅನುಮತಿ ಕೆಲಸ ಬೇಕು, ಅದು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ.

ಪರಿಶೀಲನೆ 2: ಸಬ್‌ನೆಟ್ ರೂಟ್ ಕೋಷ್ಟಕಗಳು ಏನು ಹೇಳುತ್ತವೆ

ವಾಸ್ತವ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ವಿನ್ಯಾಸವನ್ನು ಬರೆಯಿರಿ. VPC 10.60.0.0/16 ನಲ್ಲಿ, ಸಬ್‌ನೆಟ್‌ಗಳು 10.60.1.0/24 ಮತ್ತು 10.60.2.0/24 ಇದ್ದಾಗ, ಇನ್ಸ್ಟೆನ್ಸ್‌ಗಳಿಗೆ 10.60.1.10 ಮತ್ತು 10.60.2.20 VPC ಯ ಸ್ಥಳೀಯ ಮಾರ್ಗದ ಮೂಲಕ ಮಾರ್ಗ ನೀಡುತ್ತದೆ.

ನಂತರ ಮೊದಲು ಕಂಡ ಕೋಷ್ಟಕವಲ್ಲದೆ, ಎರಡೂ ಸಬ್‌ನೆಟ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಕೋಷ್ಟಕಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟ ತಪಾಸಣೆ ಅಥವಾ ಸಾಧನ ಮಾರ್ಗವು ಮೂಲ ಮಾರ್ಗವನ್ನು ಅತಿಕ್ರಮಿಸಬಹುದು, ಮತ್ತು ಸ್ಥಳೀಯ ಮಾರ್ಗದ ಗುರಿಯೂ ಹೊಸ ಸಂರಚನೆಗಳಲ್ಲಿ ಬದಲಾಗಬಹುದು. ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಎಲ್ಲೋ ಕಾಣುವ ಸ್ಥಳೀಯ ಮಾರ್ಗವು ಎರಡೂ ಕೆಲಸದ ಭಾರಗಳು ಅದನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

VPC ನಿಜವಾಗಿ ನೀಡುವ ಖಾಸಗಿ ವಿಳಾಸಗಳು ಮತ್ತು ಹೆಸರುಗಳನ್ನು ಬಳಸಿ. ಖಾಸಗಿ ವಿಳಾಸವು 10 ರಿಂದ ಪ್ರಾರಂಭವಾಗಬೇಕಿಲ್ಲ, ಮತ್ತು ನೆನಪಿನಿಂದ ಒಂದನ್ನು ಕಲ್ಪಿಸುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಪರಿಸರಕ್ಕೆ ತಪ್ಪು ನಿದಾನ ಮಾಡುವ ದಾರಿ.

ಪರಿಶೀಲನೆ 3: ರೂಟಿಂಗ್ ಅಥವಾ ಅಧಿಕಾರ

ರೂಟಿಂಗ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಗುರಿಯ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ವರೆಗೆ ಮಾತ್ರ ತಲುಪಿಸುತ್ತದೆ. ಗುರಿಯ ಭದ್ರತಾ ಗುಂಪು ಇನ್ನೂ ಮೂಲ ಮತ್ತು ಸೇವೆಯನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬೇಕು, ಮೂಲದ ಹೊರಹೋಗುವ ನಿಯಮಗಳು ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಬೇಕು, ಮತ್ತು ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ACL ಎರಡೂ ದಿಕ್ಕುಗಳನ್ನು ಅನುಮತಿಸಬೇಕು ಏಕೆಂದರೆ ACL ಸ್ಥಿತಿಯನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದಿಲ್ಲ.

ಅದರಾಚೆಗೆ ಅತಿಥಿ ಫೈರ್‌ವಾಲ್, ಶ್ರೋತೃದ ಬಂಧನ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸ್ವಂತ ಗುರುತು ಇವೆ. ಪ್ರತಿಯೊಂದೂ ರೂಟಿಂಗ್ ನಿಖರವಾಗಿ ತಲುಪಿಸಿದ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು.

ಸ್ವೀಕೃತಿಯು ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಜವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿರಬೇಕು. ಯಶಸ್ವಿ ping ಅಪ್ಲಿಕೇಶನ್ ಪ್ರವೇಶವನ್ನು ನೀಡುವುದಿಲ್ಲ ಮತ್ತು TLS ಹೆಸರು ಹಾಗೂ ರುಜುವಾತುಗಳು ಸರಿಯಾಗಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಮತ್ತು ತಡೆಹಿಡಿದ ping ಎಲ್ಲಾ ಖಾಸಗಿ ಸೇವೆಗಳು ನಿಂತಿವೆ ಎಂದು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.

ಪರಿಶೀಲನೆ 4: ಪ್ರತ್ಯೇಕ ಸಂಪರ್ಕ ನಿಜವಾಗಿ ಅಗತ್ಯವೇ

VPN ಇನ್ನೂ ವಿನ್ಯಾಸದಲ್ಲಿರಬಹುದು, ಆದರೆ ಹೇಳಿದ ಕಾರಣಕ್ಕಾಗಿ: ಈ VPC ಅನ್ನು ಕಚೇರಿಗೆ ಸಂಪರ್ಕಿಸುವುದು, ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳಿಗೆ ಅನುಮತಿ ನೀಡುವುದು ಅಥವಾ ಓವರ್‌ಲೇ ಅಗತ್ಯವನ್ನು ಪೂರೈಸುವುದು. ಆ ಕಾರಣವು ಒಂದೇ VPC ಯ ಒಳಗಿನ ಸಾಮಾನ್ಯ ಸಂವಹನಕ್ಕಿಂತ ಭಿನ್ನ.

VPC ಏನಲ್ಲ ಎಂಬುದನ್ನೂ ನೆನಪಿಡಿ. ಇದು ಮನೆಯ ಈಥರ್ನೆಟ್ ವಿಭಾಗದ ವಿಸ್ತರಣೆಯಲ್ಲ. ಪ್ರಸಾರದ ಮೂಲಕ ಪತ್ತೆಹಚ್ಚುವಿಕೆಯನ್ನು ಅವಲಂಬಿಸಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಪ್ರತ್ಯೇಕ ಅಗತ್ಯವಿದೆ. ಅದು ರೂಟಿಂಗ್ ದೋಷವಲ್ಲ, ವಿನ್ಯಾಸದ ಕೊರತೆ.

ಪರಿಶೀಲನೆ 5: ಎನ್‌ಕ್ರಿಪ್ಶನ್ ಪ್ರಶ್ನೆ

ಖಾಸಗಿ ವಿಳಾಸ ಮತ್ತು ಅನುಮತಿ ನಿಯಮವು ಅಪ್ಲಿಕೇಶನ್ ಪದರದಲ್ಲಿ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ರಕ್ಷಣೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಡೇಟಾಗೆ ತುದಿಯಿಂದ ತುದಿಯವರೆಗೆ ರಕ್ಷಣೆ ಬೇಕಿದ್ದರೆ, ಅದು ಸೇವೆ ನಿಜವಾಗಿ ಬೆಂಬಲಿಸುವ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಗುರುತಿನ ಮಾದರಿಯಿಂದ ಬರುತ್ತದೆ.

ವಿನ್ಯಾಸ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್-ಪದರ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್-ಪದರದ ಹಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಅವನ್ನು ವಿಲೀನ ಮಾಡುವುದು ಯಾರೂ ಅಳವಡಿಸದ ರಕ್ಷಣೆಯನ್ನು ಪರಿಶೀಲನೆ ಪ್ರತಿಪಾದಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಏನನ್ನು ದಾಖಲಿಸಬೇಕು

ಎರಡೂ ಸಬ್‌ನೆಟ್ ಐಡಿಗಳು, ಪ್ರತಿಯೊಂದಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ರೂಟ್ ಕೋಷ್ಟಕ, ಭದ್ರತಾ ಗುಂಪಿನ ಉಲ್ಲೇಖಗಳು ಮತ್ತು ನೀವು ಪರೀಕ್ಷಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ದಾಖಲಿಸಿ. ಇವು ನಾಲ್ಕು ಸಂಗತಿಗಳು ಮತ್ತು ಈ ಮಾರ್ಗದ ಬಗ್ಗೆ ಭವಿಷ್ಯದ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳನ್ನು ಅವು ಬಗೆಹರಿಸುತ್ತವೆ.

ಕೇವಲ ವಲಯದಲ್ಲಿ ನಿಯೋಜನೆ ಎಂದಿಗೂ VPN ಸೇರಿಸಲು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಖಾಸಗಿ ವಿನಂತಿ ಏಕೆ ವಿಫಲವಾಯಿತು ಎಂದು ಎಂದಿಗೂ ವಿವರಿಸುವುದಿಲ್ಲ.