AWS Transit Gateway ನಲ್ಲಿ ಹಲವು VPC ಗಾಗಿ ಒಂದು ಸೈಟ್-ಟು-ಸೈಟ್ VPN

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

VPN ಸೇರಿಕೆ ಮತ್ತು VPC ಸೇರಿಕೆಗಳು ಒಂದೇ ಗೇಟ್ವೇ ಮೇಲಿನ ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳು, ಆದ್ದರಿಂದ ರೂಟಿಂಗ್ ಸಂಬಂಧಗಳನ್ನು ನಂತರ ಕಟ್ಟಬೇಕು.

On-premises network <-> Site-to-Site VPN <-> Transit Gateway
                                            |- VPC A
                                            |- VPC B

ಪಿಯರಿಂಗ್ ಜನರು ನಿರೀಕ್ಷಿಸುವ ಸಣ್ಣ ದಾರಿ ಏಕೆ ಅಲ್ಲ

ಪ್ರಲೋಭನೆಯ ಪರ್ಯಾಯವೆಂದರೆ VPN ಅನ್ನು VPC A ನಲ್ಲಿ ಮುಗಿಸಿ VPC B ಅನ್ನು ಅದಕ್ಕೆ ಪಿಯರ್ ಮಾಡುವುದು. ಸಾಮಾನ್ಯ VPC ಪಿಯರಿಂಗ್ A ಯ VPN ಸಂಪರ್ಕದ ಮೂಲಕ ಅಂಚಿನಿಂದ ಅಂಚಿಗೆ ಟ್ರಾನ್ಸಿಟ್ ನೀಡುವುದಿಲ್ಲ. ಪಿಯರ್ ಪಿಯರಿಂಗ್ ತಾನೇ ನೀಡುವ ವಿಳಾಸಗಳನ್ನು ಮಾತ್ರ ತಲುಪುತ್ತದೆ, ಮತ್ತು VPN ಅಂಚು ಅವುಗಳಲ್ಲಿ ಒಂದಲ್ಲ. ಟ್ರಾನ್ಸಿಟ್ ಹಬ್ ಕೊಡುತ್ತದೆ; ಪಿಯರಿಂಗ್ ನಿಮಗೆ ಒಂದು ಜೋಡಿ ಕೊಡುತ್ತದೆ.

ಆ ಮಿತಿ ಪಿಯರಿಂಗ್ನ ಲಕ್ಷಣ, ನೀವು ಹೆಚ್ಚಿಸಬಹುದಾದ ಕೋಟಾ ಅಲ್ಲ.

ಸಂಬಂಧ ಮತ್ತು ಪ್ರಸರಣ ಬೇರೆ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ

ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ಒಳಗೆ ಸಂಬಂಧವು, ಸೇರಿಕೆಯಿಂದ ಬರುವ ಸಂಚಾರವನ್ನು ಹುಡುಕಲು ಬಳಸುವ ರೂಟ್ ಟೇಬಲ್ ಅನ್ನು ಆರಿಸುತ್ತದೆ. ಪ್ರಸರಣವು ಯಾವ ಟೇಬಲ್ಗಳಿಗೆ ಸೇರಿಕೆಯ ಕಲಿತ ಅಥವಾ ಸಂಪರ್ಕಿತ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಸಿಗುತ್ತವೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಒಂದೇ ಸೇರಿಕೆ ಒಂದು ಟೇಬಲ್ಗೆ ಸಂಬಂಧಿಸಿ ಅದೇ ಸಮಯದಲ್ಲಿ ಹಲವಕ್ಕೆ ಹರಡಬಹುದು. ಎರಡನ್ನೂ ಬೆರೆಸುವುದೇ, ಯಾರೂ ಯೋಜಿಸದ ತಲುಪುವಿಕೆಗೆ ವಿನ್ಯಾಸ ತಲುಪುವ ದಾರಿ.

ಸಂಪೂರ್ಣ ಸಂಪರ್ಕಿತ ಸಣ್ಣ ಹಬ್ ಸುಲಭ ಪ್ರಕರಣ.

ಪ್ರತಿ ಸೇರಿಕೆಯನ್ನು ಒಂದೇ ಟೇಬಲ್ನಲ್ಲಿ ಇರಿಸಿ, VPN ಮತ್ತು ಎರಡೂ VPC ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಸ್ವಚ್ಛವಾಗಿ ಬಿಡಿಸಿಕೊಳ್ಳುತ್ತವೆ. ಇದು ಸಂಸ್ಥೆ ಎಂದೂ ಉದ್ದೇಶಿಸದಿರಬಹುದಾದ VPC-ಗಳ ನಡುವಿನ ತಲುಪುವಿಕೆಯನ್ನೂ ಅನುಮತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಹಂಚಿಕೆಯ ಟೇಬಲ್ಗೆ ಸ್ಪೋಕ್ ಎಂಬ ಕಲ್ಪನೆ ಇಲ್ಲ.

ವರ್ಕ್ಲೋಡ್ ಮಾರ್ಗಗಳು ಬೇರೆಡೆ ವಾಸಿಸುತ್ತವೆ

ಪ್ರತಿ ವರ್ಕ್ಲೋಡ್ ಸಬ್ನೆಟ್ಗೆ ಉದ್ದೇಶಿತ ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳಿಗಾಗಿ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ಕಡೆಗೆ ತನ್ನದೇ ಮಾರ್ಗ ಬೇಕು. ಆ VPC ರೂಟ್ ಟೇಬಲ್ಗಳು ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇಯ ಸ್ವಂತ ಟೇಬಲ್ಗಳಿಂದ ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳು. ಬೇಕಾದ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊಸ ಡಿಫಾಲ್ಟ್ನಿಂದ ಬದಲಿಸುವ ಬದಲು ಇರುವ ಮಾರ್ಗಗಳನ್ನು ಉಳಿಸಿ. ಸಬ್ನೆಟ್ ಮಾರ್ಗವೂ ಗ್ರಾಹಕ ಸಾಧನಕ್ಕೆ ಏನನ್ನೂ ಜಾಹೀರಾತು ಮಾಡುವುದಿಲ್ಲ.

ಕ್ರಿಯಾತ್ಮಕ ಅಥವಾ ಸ್ಥಿರ ರೂಟಿಂಗ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆರಿಸಿ; ಪಿಯರಿಂಗ್ ಎರಡನ್ನೂ ನೀಡುವುದಿಲ್ಲ.

ಸ್ಥಳೀಯ ಪ್ರವೇಶ ಕಳೆದುಕೊಳ್ಳದೆ ಸ್ಪೋಕ್ ಬೇರ್ಪಡಿಸಿ

A ಮತ್ತು B ಇಬ್ಬರೂ ಕಚೇರಿಗೆ ತಲುಪಬಹುದು ಆದರೆ ಒಂದಕ್ಕೊಂದು ರೂಟ್ ಆಗಬಾರದು ಎಂದಾದರೆ, ಟೇಬಲ್ಗಳನ್ನು ವಿಭಜಿಸಿ. VPN ಸೇರಿಕೆಯ ಸಂಬಂಧಿತ ಟೇಬಲ್ VPC ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಹೊಂದಿದೆ. VPC ಸೇರಿಕೆಗಳ ಸಂಬಂಧಿತ ಟೇಬಲ್ ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಹೊಂದಿದೆ, A ಯನ್ನು B ಗೆ ಜೋಡಿಸುವ ಮಾರ್ಗವಿಲ್ಲದೆ. ಪ್ರಸರಣವೇ ಆ ಸಂಬಂಧವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಡಿಫಾಲ್ಟ್ ಸಂಬಂಧಗಳನ್ನು ಸ್ವೀಕರಿಸಬೇಕಿಲ್ಲ.

ಇದು ರೂಟಿಂಗ್ ಪ್ರತ್ಯೇಕತೆ, ಮತ್ತು ಇದು ಅಪ್ಲಿಕೇಶನ್ ಅಧಿಕಾರವಲ್ಲ.

ಭದ್ರತಾ ಗುಂಪುಗಳು, ನೆಟ್ವರ್ಕ್ ACL ಗಳು, ಹೋಸ್ಟ್ ಫಯರ್ವಾಲ್ಗಳು ಮತ್ತು ಪ್ರತಿ ಸೇವೆಯ ಸ್ವಂತ ಅನುಮತಿಗಳು ಯಾವ ಸಂಚಾರ ಸ್ವೀಕೃತವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಇನ್ನೂ ನಿರ್ಧರಿಸುತ್ತವೆ. ಪರಿಶೀಲನೆ ಬೇಕಾದರೆ, ಹಬ್ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ಅದರ ಬೆಂಬಲಿತ ಮಾರ್ಗವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿನ್ಯಾಸ ಮಾಡಿ.

ಹಬ್ ಸರಿಪಡಿಸದ್ದು

ವಿಳಾಸ ಯೋಜನೆಗಳು ಇನ್ನೂ ಅತಿಕ್ರಮಣ ರಹಿತವಾಗಿರಬೇಕು, ಏಕೆಂದರೆ ಹಬ್ ಒಂದು ಪ್ರಿಫಿಕ್ಸ್ ಎರಡು ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಗುರುತಿಸಲು ಬಿಡುವುದಿಲ್ಲ. ಪ್ರತಿ VPC ಸೇರಿಕೆಗೆ ಅದರ ವರ್ಕ್ಲೋಡ್ಗಳು ನಿರೀಕ್ಷಿಸುವ Availability Zone ವ್ಯಾಪ್ತಿ ಬೇಕು. BGP ಜೊತೆಗೆ, ಗ್ರಾಹಕ ಸಾಧನದ ಪ್ರತಿ ಅಗತ್ಯ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗಗಳು ವಿನ್ಯಾಸ ಮತ್ತು ಅದರ ಆಮದು ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಕಾಣೆಯಾದ ಜಾಹೀರಾತು ಮುರಿದ ಸುರಂಗದಂತೆಯೇ ಕಾಣುತ್ತದೆ.

VPN ಸಂಪರ್ಕ ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ಈಗ ಹಂಚಿಕೆಯ ಮೂಲಸೌಕರ್ಯ.

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

ಇರುವ virtual private gateway ವ್ಯವಸ್ಥೆಯಿಂದ ಸ್ಥಳಾಂತರವೂ ಅದೇ ಸ್ಪಷ್ಟ ಯೋಜನೆಗೆ ಅರ್ಹ. ಸೇರಿಕೆಗಳು ಮತ್ತು ನೀತಿಗಳನ್ನು ನಿರ್ಮಿಸಿ, ಒಂದು ನಿಯಂತ್ರಿತ ವರ್ಕ್ಲೋಡ್ ಮಾರ್ಗವನ್ನು ಸರಿಸಿ, ಮತ್ತು ಹಳೆಯ ಮಾರ್ಗವನ್ನು ನಿವೃತ್ತಿಗೊಳಿಸುವ ಮೊದಲು ಅನುಮತಿಸಿದ ಮತ್ತು ನಿರಾಕರಿಸಿದ ಸಂಬಂಧಗಳನ್ನು ದೃಢೀಕರಿಸಿ. ಕೇಂದ್ರೀಕರಣವು ನೆಟ್ವರ್ಕ್ ತಂಡಕ್ಕೆ ಹಂಚಿಕೆಯ ಸಂಪರ್ಕ ನಿರ್ವಹಿಸಲು ಒಂದೇ ಸ್ಥಳ ನೀಡಿದಾಗ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ದೊಡ್ಡ ಟೇಬಲ್ನ ಹಿಂದೆ ಯಾರು ಯಾರಿಗೆ ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಮರೆಮಾಡಿದಾಗ ಹಾನಿ ಮಾಡುತ್ತದೆ.