VGW ನ BGP ಜಾಹೀರಾತುಗಳು ಮತ್ತು VPC ರೂಟ್ ಟೇಬಲ್: ಯಾವುದು ಯಾವುದನ್ನು ಬದಲಿಸುತ್ತದೆ

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

ಯಾವುದೇ ಟೇಬಲ್ ಓದುವ ಮೊದಲು ಲಗತ್ತನ್ನು ಹೆಸರಿಸಿ

ಸೈಟ್-ಟು-ಸೈಟ್ VPN ವರ್ಚುವಲ್ ಖಾಸಗಿ ಗೇಟ್‌ವೇ ಅಥವಾ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಸಂಪನ್ಮೂಲ IDಗಳು ಯಾವ ರೂಟಿಂಗ್ ಮಾದರಿ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಮೊದಲು ಅವುಗಳನ್ನು ಓದಿ: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. ಮುಂದೆ ಪರಿಶೀಲಿಸಬೇಕಾದ ಟೇಬಲ್ VPC ರೂಟ್ ಟೇಬಲ್ ಅಥವಾ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ರೂಟ್ ಟೇಬಲ್ ಎಂದು ಉತ್ತರ ತಿಳಿಸುತ್ತದೆ.

VPN ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇಗೆ ಲಗತ್ತಿಸಿದ್ದರೆ, VPC ರೂಟ್ ಟೇಬಲ್ ಅನ್ನು ನಿಯಂತ್ರಣ ಸಮತಲವಾಗಿ ಪರಿಗಣಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅಲ್ಲಿ VPC ಟೇಬಲ್ ಗೇಟ್‌ವೇ ಲಗತ್ತನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಮತ್ತು ಸಂಯೋಜನೆ ಹಾಗೂ ಪ್ರಸರಣ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ರೂಟ್ ಟೇಬಲ್‌ನಲ್ಲಿ ನಡೆಯುತ್ತವೆ. ಎರಡೂ ದೃಷ್ಟಿಕೋನಗಳನ್ನು ಬೆರೆಸುವುದು ತಪ್ಪು ವಸ್ತುವಿನ ಬಗ್ಗೆ ಆತ್ಮವಿಶ್ವಾಸದ ತೀರ್ಮಾನಗಳನ್ನು ನೀಡುತ್ತದೆ.

AWS ನಿಂದ ಕಚೇರಿಗೆ ಇರುವ ದಿಕ್ಕು ಒಂದು ಜಾಹೀರಾತು

VGW ಲಗತ್ತಿಗೆ, ಗೇಟ್‌ವೇ ತನ್ನ VPCಗೆ ಸಂಬಂಧಿಸಿದ CIDR ಬ್ಲಾಕ್‌ಗಳನ್ನು BGP ಮೂಲಕ ಗ್ರಾಹಕರ ಗೇಟ್‌ವೇಗೆ ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಸಬ್‌ನೆಟ್ ರೂಟ್ ಸೇರಿಸುವುದು, ಅಥವಾ ರೂಟ್ ಅನ್ನು ಪೀರ್ ಮಾಡಿದ VPC ಅಥವಾ ಸಾಧನದತ್ತ ನಿರ್ದೇಶಿಸುವುದು, ಇನ್ನೊಂದು ಸಂಬಂಧಿತ CIDR ಸೇರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಆ ಜಾಹೀರಾತಿನಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ. ಕಚೇರಿಯಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ ಕಾಣೆಯಾಗಿದ್ದರೆ, ಯಾವುದೇ ರೂಟ್ ಟೇಬಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸ್ವೀಕರಿಸಿದ ರೂಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು VPC ಸಂಯೋಜನೆಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಸರಳ ನಿಯಮಕ್ಕೆ ಅಪವಾದಗಳಿವೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಅದರ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ ಇರಿಸಿ. VPN CloudHub ವ್ಯವಸ್ಥೆ ಗ್ರಾಹಕರ ಗೇಟ್‌ವೇಗಳ ನಡುವೆ ಸೈಟ್ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಮರು ಜಾಹೀರಾತು ಮಾಡಬಹುದು, ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್‌ವೇ ತನ್ನದೇ ಆದ ಪ್ರಸರಣ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುತ್ತದೆ. VGW ತನ್ನದೇ VPC ಅನ್ನು ಮಾತ್ರ ಜಾಹೀರಾತು ಮಾಡುತ್ತದೆ ಎಂಬ ಹೇಳಿಕೆ ಉಪಯುಕ್ತ ಡೀಫಾಲ್ಟ್, ನೀವು ಎದುರಿಸುವ ಪ್ರತಿಯೊಂದು ಟೋಪೋಲಜಿಯನ್ನೂ ಆವರಿಸುವ ಕಾನೂನಲ್ಲ.

ಕಚೇರಿಯಿಂದ AWSಗೆ ಇರುವ ದಿಕ್ಕು ಪ್ರಸರಣ ಜೊತೆಗೆ ಆಯ್ಕೆ

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

ಊಹಿಸುವ ಬದಲು ಮೂಲವನ್ನು ಓದಿ: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. EnableVgwRoutePropagation ಮೂಲದ ನಮೂದು BGP ನಿಂದ ಬಂದಿದೆ; CreateRoute ಮೂಲದ ನಮೂದನ್ನು ಮನುಷ್ಯ ಟೈಪ್ ಮಾಡಿದ್ದಾನೆ ಮತ್ತು ಯಾರಾದರೂ ಅದನ್ನು ಅಳಿಸುವವರೆಗೂ ಗೆಲ್ಲುತ್ತಲೇ ಇರುತ್ತದೆ.

ಎರಡು ದಿಕ್ಕುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸುವ ರನ್‌ಬುಕ್

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು AWS ಬದಿಯಲ್ಲಿ ನಾಲ್ಕು ಅಂಶಗಳನ್ನು ದಾಖಲಿಸಿ: ಲಗತ್ತಿನ ಪ್ರಕಾರ, VPCಯ ಸಂಬಂಧಿತ CIDR, ಪ್ರಶ್ನೆಯಲ್ಲಿರುವ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಸಬ್‌ನೆಟ್ ರೂಟ್‌ನ ಮೂಲ, ಮತ್ತು ಟನಲ್ ಹಾಗೂ BGP ಸ್ಥಿತಿ. ಅದೇ describe ಕರೆ ಪ್ರತಿ ಟನಲ್‌ಗೆ ಸ್ವೀಕೃತ ರೂಟ್‌ಗಳ ಎಣಿಕೆಯೊಂದಿಗೆ VgwTelemetry ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಇದು AWS ಯಾವುದೇ ರೂಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದೆಯೇ ಎಂದು ತಿಳಿಸುತ್ತದೆ. ನಂತರ ಅದನ್ನು ಗ್ರಾಹಕರ ಸಾಧನವು ನಿಜವಾಗಿ ಸ್ಥಾಪಿಸಿದ್ದರೊಂದಿಗೆ ಹೋಲಿಸಿ. BGP ನಲ್ಲಿದ್ದು ಫಾರ್ವರ್ಡಿಂಗ್ ಟೇಬಲ್‌ನಲ್ಲಿ ಇಲ್ಲದ ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಳೀಯ ಆಮದು ಅಥವಾ ಉತ್ತಮ-ಮಾರ್ಗದ ಸಮಸ್ಯೆ, AWS ರೂಟ್ ಟೇಬಲ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.

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

ಅಲ್ಲಿ ಇರುವಾಗ ಏನನ್ನು ಬದಲಿಸಬಾರದು

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

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

ಪ್ರತಿ ರೂಟ್ ಟೇಬಲ್ ಪ್ರಶ್ನೆಯ ಮೊದಲು ಮತ್ತು ನಂತರದ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಉಳಿಸಿ. ಬದಲಾವಣೆ ಪರಿಸ್ಥಿತಿಯನ್ನು ಕೆಡಿಸಿದರೆ, ಹಿಂದಿನ ರೂಟ್‌ಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಿ ಮತ್ತು ಅದೇ ಪ್ರಶ್ನೆಯಿಂದ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ನೀವು ಪರಿಶೀಲಿಸಲಾಗದ ರೋಲ್‌ಬ್ಯಾಕ್ ಕೇವಲ ಒಂದು ಊಹೆ.