AWS Site-to-Site VPN ನಿಂದ NAT Gateway ಗೆ: VGW vs Transit Gateway

ಮೊದಲ ಬಾರಿಗೆ ಎಲ್ಲರೂ ಒಂದೇ ರೇಖಾಚಿತ್ರ ಬರೆಯುತ್ತಾರೆ: VPC ಗೆ VPN, ನಂತರ NAT gateway ಮೂಲಕ ಇಂಟರ್ನೆಟ್ಗೆ, ಮುಗಿಯಿತು. ಆದರೆ VPN virtual private gateway ನಲ್ಲಿ ಕೊನೆಗೊಂಡಾಗ AWS ಆ ಮಾರ್ಗವನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ವೈಫಲ್ಯ ಎಷ್ಟು ಮೌನವಾಗಿದೆ ಎಂದರೆ ತಂಡಗಳು ಅದನ್ನು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬಾರಿ ಮರುನಿರ್ಮಿಸುತ್ತವೆ. ಕೆಲಸ ಮಾಡುವ ವಿನ್ಯಾಸಕ್ಕೆ transit gateway ಬೇಕು, ಅದು ಎರಡೂ ಕಡೆ gateway ಮತ್ತು route tables ಅನ್ನು ಬದಲಿಸುತ್ತದೆ. ಏನನ್ನೂ ಬರೆಯುವ ಮೊದಲು ಎರಡೂ ಆಕಾರಗಳನ್ನು ಹೋಲಿಸಿ.

ಸ್ಪಷ್ಟವಾಗಿ ಕಾಣುವ ಆದರೆ ಬೆಂಬಲವಿಲ್ಲದ ಟೋಪಾಲಜಿ

AWS ನ NAT gateway ದಾಖಲೆ ಒಂದೇ VPC ವಿನ್ಯಾಸಗಳನ್ನು ಮಾತ್ರ ನಿರ್ಮಿಸಿದವರನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುವ ಗೆರೆ ಎಳೆಯುತ್ತದೆ: Site-to-Site VPN ಸಂಪರ್ಕದ ಟ್ರಾಫಿಕ್ ಅನ್ನು virtual private gateway ಮೂಲಕ NAT gateway ಗೆ route ಮಾಡಲಾಗುವುದಿಲ್ಲ. VPN ಯಾವ ರೀತಿಯ gateway ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದು ಅನುವಾದ ಮಾರ್ಗವೇ ಇದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ತಪ್ಪು ಉಳಿಯುವುದಕ್ಕೆ ಕಾರಣ ಟನೆಲ್ ಸ್ಥಿತಿ UP ಆಗಿರುವುದು ಮತ್ತು ಅದೇ subnet ನ EC2 instance ತೊಂದರೆಯಿಲ್ಲದೆ ಇಂಟರ್ನೆಟ್ ತಲುಪುವುದು. ಈ ಎರಡೂ ವೀಕ್ಷಣೆಗಳು ಮುರಿದ ದಿಕ್ಕನ್ನು ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ.

ಪ್ರಾಯೋಗಿಕವಾಗಿ ಪ್ಯಾಕೆಟ್ ಆನ್-ಪ್ರಿಮೈಸಸ್ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಅನುವಾದಿಸುವ ಬೆಂಬಲಿತ ಮುಂದಿನ hop ಸಿಗುವುದಿಲ್ಲ. ಕೋಷ್ಟಕಗಳ ಆಧಾರದ ಮೇಲೆ ಅದನ್ನು egress ಗಡಿಯಲ್ಲಿ ಬಿಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ UP ಆಗಿ ಉಳಿದು ಅದೇ subnet ನ instance ಇಂಟರ್ನೆಟ್ ತಲುಪುವುದರಿಂದ ವೈಫಲ್ಯವನ್ನು ಆನ್-ಪ್ರಿಮೈಸಸ್ firewall ಸಮಸ್ಯೆ ಎಂದು ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ.

Virtual private gateway vs transit gateway

ಒಂದು virtual private gateway ಒಂದು VPC ಗೆ ಸೇರಿದೆ. ಅದು VPN ಅನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ, ಆ VPC ಯ route tables ಗೆ routes ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಅಲ್ಲೇ ನಿಲ್ಲುತ್ತದೆ. ಅದಕ್ಕೆ attachment ಮಾದರಿ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದು VPC ಗೆ ಅಥವಾ ಹಂಚಿದ egress ವಿಭಾಗಕ್ಕೆ ಟ್ರಾಫಿಕ್ ನೀಡಲಾಗದು. ಈ ಒಂದು VPC ವ್ಯಾಪ್ತಿಯೇ ಸಂಪೂರ್ಣ ಮಿತಿ, ಮತ್ತು VPC ಒಳಗೆ ಸೇರಿಸುವ ಯಾವುದೇ route ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

Transit gateway ಪ್ರಾದೇಶಿಕ ಕೇಂದ್ರವಾಗಿದ್ದು, ಅಲ್ಲಿ VPN, ಪ್ರತಿ spoke VPC ಮತ್ತು ಹಂಚಿದ ಸೇವೆಗಳ VPC ಎಲ್ಲವೂ attachments ಆಗಿ ಕಾಣುತ್ತವೆ. ಅದಕ್ಕೆ ತನ್ನದೇ route tables ಇವೆ, ಅವು ಯಾವ attachment ನಿರ್ದಿಷ್ಟ prefix ಪಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ.

ಈ ಕೇಂದ್ರವೇ ಕೇಂದ್ರೀಕೃತ egress ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ: VPN ಒಂದು attachment ಆಗಿ ಇಳಿಯುತ್ತದೆ, egress VPC ಇನ್ನೊಂದಾಗಿ, ಮತ್ತು transit gateway route table ಇಂಟರ್ನೆಟ್ ಕಡೆಗಿನ prefixes ಅನ್ನು ಮೊದಲನೆಯದರಿಂದ ಎರಡನೆಯದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. virtual private gateway ಜೊತೆ ಕಳುಹಿಸಲು ಎರಡನೇ attachment ಇರುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿನ್ಯಾಸವನ್ನು ನಂತರ ಪ್ಯಾಚ್ ಮಾಡಿ ಮಾಡಲಾಗದು.

ಬೆಂಬಲಿತ egress ಮಾರ್ಗ, ಹಂತ ಹಂತವಾಗಿ

ಉಲ್ಲೇಖ ವಿನ್ಯಾಸದಲ್ಲಿ ಐದು hops ಇವೆ ಮತ್ತು ಪ್ರತಿ ಬಾಣವೂ ನೀವು ಸಂರಚಿಸಬೇಕಾದ route ನಿರ್ಣಯ. ಟ್ರಾಫಿಕ್ ಆನ್-ಪ್ರಿಮೈಸಸ್ ನೆಟ್ವರ್ಕ್ನಿಂದ Site-to-Site VPN attachment ಗೆ ಹೊರಡುತ್ತದೆ, transit gateway route table ಅದನ್ನು egress VPC attachment ಗೆ ರವಾನಿಸುತ್ತದೆ, ಅಲ್ಲಿ subnet ಕೋಷ್ಟಕ ಅದನ್ನು ಸಾರ್ವಜನಿಕ NAT gateway ಗೆ ಕಳುಹಿಸುತ್ತದೆ. NAT gateway ಮೂಲವನ್ನು ಅನುವಾದಿಸುತ್ತದೆ ಮತ್ತು internet gateway ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಹೊರಗೆ ಒಯ್ಯುತ್ತದೆ.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

ಕೊನೆಯ hops ಕೆಲಸ ಮಾಡುತ್ತವೆಯೇ ಎಂಬುದನ್ನು ಎರಡು ವಿವರಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. NAT gateway ಸಾರ್ವಜನಿಕವಾಗಿರಬೇಕು, elastic IP ಮತ್ತು internet gateway ಗೆ route ಇರಬೇಕು, ಏಕೆಂದರೆ ಖಾಸಗಿ NAT gateway ನೆಟ್ವರ್ಕ್ಗಳ ನಡುವೆ ಅನುವಾದಿಸುತ್ತದೆ ಮತ್ತು ಎಂದಿಗೂ ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನವಾಗುವುದಿಲ್ಲ.

ನೀವು ಸೇವೆ ನೀಡಲು ಉದ್ದೇಶಿಸಿರುವ ಪ್ರತಿ Availability Zone ಗೆ ಒಂದು NAT gateway ಯೋಜಿಸಿ, ಮತ್ತು ಪ್ರತಿ subnet ಕೋಷ್ಟಕ ಸ್ಥಳೀಯದನ್ನು ತೋರಿಸಲಿ. ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ transit gateway ಕೋಷ್ಟಕ ಮತ್ತು VPC ಕೋಷ್ಟಕಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವಸ್ತುಗಳಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಒಂದು attachment ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಂದು VPC ಒಳಗಿನ ಸಂಪನ್ಮೂಲ. ಅವುಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಮಾತ್ರ default route ಇದ್ದರೆ ಅರ್ಧ ಮಾರ್ಗ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಗುರುತಿಸಲು ಅತ್ಯಂತ ಕಷ್ಟಕರವಾದ ಭಾಗಶಃ ವೈಫಲ್ಯಗಳು ಉಂಟಾಗುತ್ತವೆ.

ಈ ವಿನ್ಯಾಸಗಳು ಮರಳುವ ಮಾರ್ಗದಲ್ಲೇ ವಿಫಲವಾಗುತ್ತವೆ

NAT gateway ಈಗಾಗಲೇ ನೋಡಿದ flows ಗೆ stateful ಆಗಿದೆ, ಆದ್ದರಿಂದ ಹೊರಹೋಗುವ ಸಂಪರ್ಕದ ಉತ್ತರಗಳು ಹೊಸ inbound ನಿಯಮವಿಲ್ಲದೆ ಮರಳಿ ಬರುತ್ತವೆ. ಆ ಗುಣ ಯಾವುದೇ ಆನ್-ಪ್ರಿಮೈಸಸ್ ಸೇವೆಯನ್ನು ಇಂಟರ್ನೆಟ್ಗೆ ಪ್ರಕಟಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹಾಗೆ ಎಂದು ಪರಿಗಣಿಸುವುದು ಎಂದಿಗೂ ಸ್ಥಾಪನೆಯಾಗದ ಸಂಪರ್ಕವನ್ನು ಡೀಬಗ್ ಮಾಡಲು ತಂಡವು ಒಂದು ದಿನ ಕಳೆಯುವಂತೆ ಮಾಡುತ್ತದೆ. ಕ್ಲೈಂಟ್ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಟ್ರಾಫಿಕ್ಗೆ ನಾಲ್ಕು routes ಒಪ್ಪಬೇಕು: ಆನ್-ಪ್ರಿಮೈಸಸ್ ನೀತಿ, transit gateway ಕೋಷ್ಟಕ, egress subnet ಕೋಷ್ಟಕ ಮತ್ತು NAT subnet ಕೋಷ್ಟಕ. ಕೊನೆಯದನ್ನು ತಪ್ಪಿಸಿದರೆ ವಿನಂತಿ ಕಟ್ಟಡದಿಂದ ಹೊರಡುತ್ತದೆ, ಆದರೆ ಉತ್ತರ AWS ಒಳಗೇ ಸಾಯುತ್ತದೆ.

VPN ಹಿಂದಿನ ನಿಜವಾದ ಕ್ಲೈಂಟ್ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಅದು ಯಾವ ಸಾರ್ವಜನಿಕ ಮೂಲ ವಿಳಾಸವನ್ನು ತೋರಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. ಅದು NAT gateway ಯ elastic IP ಆಗಿದ್ದರೆ ಅನುವಾದ ನಡೆಯುತ್ತಿದೆ; ಬೇರೆ ಏನಾದರೂ ಆಗಿದ್ದರೆ ನೀವು ಬೇರೆ egress ಅನ್ನು ಅಳೆಯುತ್ತಿದ್ದೀರಿ.

ಈ ವೈಫಲ್ಯದ ಅಸಮಮಿತ ರೂಪವನ್ನು ಬೇಗ ಗುರುತಿಸುವುದು ಒಳ್ಳೆಯದು. ಒಂದು Availability Zone ನ NAT subnet ಕೋಷ್ಟಕದಲ್ಲಿ ಕ್ಲೈಂಟ್ prefix ಗೆ ಮರಳುವ route ಇದ್ದು ಇನ್ನೊಂದರಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೆ, ಹೊಸ ಸಂಪರ್ಕಗಳು flow ಯಾವ ವಲಯಕ್ಕೆ ಬೀಳುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ ಅಥವಾ ವಿಫಲವಾಗುತ್ತವೆ, ಮತ್ತು ಈ ಮಾದರಿಯನ್ನು ತಪ್ಪಾಗಿ ಅಸ್ಥಿರ ಇಂಟರ್ನೆಟ್ ಎಂದು ಓದಲಾಗುತ್ತದೆ. ಟಿಕೆಟ್ ತೆರೆದ ವಲಯವನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ನೀವು ಸೇವೆ ನೀಡುವ ಪ್ರತಿ ವಲಯದ subnet ಕೋಷ್ಟಕಗಳನ್ನು ಹೋಲಿಸಿ, ಏಕೆಂದರೆ ಕಾಣೆಯಾದ route ಸಂಪೂರ್ಣ ದೋಷ ಮತ್ತು ಆಚೆ ಯಾವುದನ್ನೂ ಬದಲಿಸಬೇಕಿಲ್ಲ.

ಯಾವಾಗ ಸ್ಪಷ್ಟ proxy ಉತ್ತಮ ವಿನ್ಯಾಸ

egress VPC ಯ instance ಮೇಲೆ HTTP proxy ಕಾನೂನುಬದ್ಧ ಪರ್ಯಾಯ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಅಗ್ಗ. ಕ್ಲೈಂಟ್ಗಳು ಅದನ್ನು ಬಳಸಲು ಸಂರಚಿಸಲ್ಪಡುತ್ತವೆ, proxy ತನ್ನದೇ ಸಂಪರ್ಕವನ್ನು ಹೊರಕ್ಕೆ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು ಮರಳುವ ಮಾರ್ಗ ಸಮಮಿತ routing ಒಗಟಲ್ಲ, proxy ಯ ಸಮಸ್ಯೆಯಾಗುತ್ತದೆ. ಕೆಲವೇ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಇದು transit gateway ಕೆಲಸದ ಬಹುಪಾಲನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದು NAT gateway ಒದಗಿಸಲಾಗದ ಬಳಕೆದಾರ-ಮಟ್ಟದ ಲಾಗಿಂಗ್ ಕೂಡ ನೀಡುತ್ತದೆ.

ಆದರೆ ಅದು ಪಾರದರ್ಶಕವಲ್ಲ. proxy ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಯಾವುದೇ ವಸ್ತು, ಮತ್ತು HTTP ಅಲ್ಲದ ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್, ಆ ಮಾರ್ಗದಲ್ಲಿ ಹೋಗುವುದಿಲ್ಲ.

ಆಯ್ಕೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳು ನಿಜವಾಗಿ ಏನು ಮಾತನಾಡುತ್ತವೆ ಮತ್ತು ಲಾಗ್ಗಳಲ್ಲಿ ಎಷ್ಟು ಗುರುತು ಬೇಕು ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತ. ಅವು HTTP ಮಾತನಾಡುವಲ್ಲಿ proxy ತನ್ನ ಸ್ಥಾನ ಗಳಿಸುತ್ತದೆ; ಅನಿಯಂತ್ರಿತ ಪ್ರೋಟೋಕಾಲ್ಗಳಿಗೆ ಸಾಮಾನ್ಯ egress ಬೇಕಾದಲ್ಲಿ AWS ಬೆಂಬಲಿಸುವ ವಿನ್ಯಾಸ transit gateway. ಇದನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸುವುದು route tables ನಿರ್ಮಿಸಿದ ನಂತರ ಕಂಡುಕೊಳ್ಳುವುದಕ್ಕಿಂತ ಅಗ್ಗ.