VGW ಅಥವಾ TGW? AWS Site-to-Site ನ IPsec ಸುರಂಗ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ

AWS Site-to-Site VPN ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎಲ್ಲಿ ರಕ್ಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂದು ಜನರು ಕೇಳುತ್ತಾರೆ ಮತ್ತು ಒಂದೇ ಉತ್ತರವನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ: ಗೇಟ್ವೇಯಲ್ಲಿ. ಆ ಉತ್ತರದ ಉಪಯುಕ್ತ ಆವೃತ್ತಿ ಯಾವ ಗೇಟ್ವೇ ಎಂದು ಹೆಸರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ವರ್ಚುವಲ್ ಖಾಸಗಿ ಗೇಟ್ವೇ ಮತ್ತು ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇ ವಿಭಿನ್ನ ಲಗತ್ತು ವಸ್ತುಗಳನ್ನು ಹೊಂದಿರುವ ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳು, ಮತ್ತು ತಪ್ಪಾದದ್ದನ್ನು ಊಹಿಸುವ ವಿಮರ್ಶಕರು ಉಳಿದ ಮೌಲ್ಯಮಾಪನವನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ರೇಖಾಚಿತ್ರದ ಮೇಲೆ ಕಟ್ಟುತ್ತಾರೆ. ಕೆಳಗಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ. ಪ್ರತಿಯೊಂದೂ ಗಡಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ ಅಥವಾ ಹಿಂದಿನ ಉತ್ತರ ಬೇರೆ ಸಂಪನ್ಮೂಲದ ಬಗ್ಗೆ ಎಂದು ಹೇಳುತ್ತದೆ.

ಏನನ್ನೂ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವ ಮೊದಲು ಮೂರು ತುದಿ ಬಿಂದುಗಳನ್ನು ಹೆಸರಿಸಿ

ಈ ಮಾರ್ಗದ ಎನ್ಕ್ರಿಪ್ಷನ್ ಪರಿಶೀಲನೆಗೆ ಮೂರು ಹೆಸರಿಸಿದ ವಸ್ತುಗಳು ಬೇಕು: ಗ್ರಾಹಕ ಗೇಟ್ವೇ, IPsec ಅನ್ನು ಕೊನೆಗೊಳಿಸುವ AWS VPN ಗುರಿ, ಮತ್ತು ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ತುದಿ ಬಿಂದು. ಒಂದೂ ಕನ್ಸೋಲ್ ಪುಟ ತೆರೆಯುವ ಮೊದಲು ಅವುಗಳನ್ನು ಅವುಗಳ ಸಂಪನ್ಮೂಲ ಗುರುತಿಸುವಿಕೆಗಳೊಂದಿಗೆ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಈ ಬಿಂದುವಿನ ನಂತರದ ಎಲ್ಲವೂ ಆ ಮೂರರಲ್ಲಿ ಒಂದರ ಬಗ್ಗೆ ಹೇಳಿಕೆ.

ಗ್ರಾಹಕ ಗೇಟ್ವೇ ನಿಮ್ಮದು ಮತ್ತು ಅದರ ಸಂರಚನೆ ನಿಮಗೆ ಕಾಣುತ್ತದೆ. AWS ಗುರಿ ನಿರ್ವಹಿತ ಸಂಪನ್ಮೂಲ, ಮತ್ತು ತಪ್ಪು ಅದನ್ನು ಊಹಿಸುವುದು: VPN ಸಂಪರ್ಕ ವರ್ಚುವಲ್ ಖಾಸಗಿ ಗೇಟ್ವೇಗೆ ಅಥವಾ ನೇರವಾಗಿ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇಗೆ ಜೋಡಣೆಯಾಗಬಹುದು, ಮತ್ತು ಒಂದೂ ಇನ್ನೊಂದನ್ನು ಸೂಚಿಸುವುದಿಲ್ಲ. ಮೂರನೇ ತುದಿ ಬಿಂದು ಜನರು ಬಿಟ್ಟುಬಿಡುವ ಬಿಂದು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾದ ನಿಜವಾದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಏಕೈಕ ಬಿಂದು.

ಪರಿಶೀಲನೆ 1: ಸುರಂಗವನ್ನು ವಾಸ್ತವವಾಗಿ ಯಾವ ಗೇಟ್ವೇ ಕೊನೆಗೊಳಿಸುತ್ತದೆ

ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು ಬೆಂಬಲಿತವಾಗಿವೆ ಮತ್ತು Site-to-Site VPN ಆರ್ಕಿಟೆಕ್ಚರ್ ಮಾರ್ಗದರ್ಶಿ ಅವನ್ನು ಅಕ್ಕಪಕ್ಕ ವಿವರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ವರ್ಷ ಹಳೆಯದಾದ ರೇಖಾಚಿತ್ರದ ಬದಲು API ಅನ್ನು ಕೇಳಿ. ಒಂದು ಸಂಪರ್ಕದ ಮೇಲಿನ ಓದು-ಮಾತ್ರ ಪ್ರಶ್ನೆ VPN ಗುರಿ ಕ್ಷೇತ್ರಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

ಭೇದಕ TransitGatewayId, VpnGatewayId ಅಲ್ಲ. TransitGatewayId ಖಾಲಿಯಿರುವ ಸಂಪರ್ಕ ಸ್ವತಂತ್ರ ವರ್ಚುವಲ್ ಖಾಸಗಿ ಗೇಟ್ವೇಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಆ ಕ್ಷೇತ್ರ ಸೆಟ್ ಆಗಿರುವ ಸಂಪರ್ಕ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇಯ VPN ಲಗತ್ತಿನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಆ ಸಂದರ್ಭದಲ್ಲಿ VpnGatewayId ಇನ್ನೂ ತುಂಬಿರಬಹುದು ಏಕೆಂದರೆ ಅದು ಲಗತ್ತಿನ ಆಧಾರ ಗೇಟ್ವೇ ಅನ್ನು ಹೆಸರಿಸಬಹುದು. ಮೊದಲು TGW ಕ್ಷೇತ್ರ ಓದಿ, ನಂತರ ಲಗತ್ತಿನ ಪ್ರಕಾರವನ್ನು ಕ್ಷೇತ್ರದ ಹೆಸರಿನಿಂದ ಅಲ್ಲ, ಲಗತ್ತುಗಳ ಪಟ್ಟಿಯಿಂದ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಆ ಟ್ರಾನ್ಸಿಟ್ ಗೇಟ್ವೇಯಲ್ಲಿನ VPC ಲಗತ್ತು VPN ಲಗತ್ತು ಅಲ್ಲ. ಸಂಪರ್ಕಿತ VPC ಯಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನ ಇನ್ಸ್ಟನ್ಸ್ ಸಿಗುವುದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಯಾವ VPN ಲಗತ್ತು ಸಾಗಿಸಿತು ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ.

ಅಲ್ಲಿರುವಾಗ ಸುರಂಗಗಳನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಸಂಪರ್ಕ ಪುನರಾವರ್ತನೆಗಾಗಿ ಎರಡು IPsec ಸುರಂಗಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಎರಡನೇ ಸುರಂಗ ಎಂದೂ ಏಳದ ಸಂಪರ್ಕ ಎನ್ಕ್ರಿಪ್ಷನ್ ಗಡಿಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಬದಲಿಸದಿದ್ದರೂ ಲಭ್ಯತೆಗೆ ನಿಜವಾದ ಸಂಶೋಧನೆಯಾಗಿದೆ:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

ಪರಿಶೀಲನೆ 2: ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ ಏನನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ

IPsec ಕೊನೆಗೊಂಡ ನಂತರ AWS ಡೀಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅದಕ್ಕೆ ಹೊಂದಿಕೆಯಾದ ಮಾರ್ಗದಲ್ಲಿ ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ. ಆ ಬಿಂದುವಿನಿಂದ ಸಂಚಾರ ಸಾಮಾನ್ಯ VPC ಸಂಚಾರ, ಮತ್ತು VPN ನ ರಕ್ಷಣೆ ಮುಗಿದಿದೆ. ಇದು ಸೇವೆಯಲ್ಲಿ ಕೊರತೆ ಅಲ್ಲ; ಇದೇ ಗಡಿಯ ಅರ್ಥ, ಮತ್ತು ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯ ಅಂಶ ಎಂದರೆ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುವುದು, "VPN ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ" ಎಂಬುದನ್ನು "ಡೇಟಾ ತುದಿಯಿಂದ ತುದಿಗೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ" ಎಂಬುದರ ಸ್ಥಾನದಲ್ಲಿ ನಿಲ್ಲಲು ಬಿಡದೆ.

ಈಗ ಒಳಗೆ ಏನಿತ್ತು ಎಂದು ಪರಿಶೀಲಿಸಿ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಸರಳ ಪಠ್ಯದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದರೆ, ಬೇರೆ ಯಾವುದೋ ಅದನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವವರೆಗೆ ಕೆಳಮುಖವಾಗಿ ಯಾವುದೂ ಗೋಪ್ಯತೆಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಈಗಾಗಲೇ TLS ಅಧಿವೇಶನವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತಿದ್ದರೆ, ಹೊರಗಿನ IPsec ತೆಗೆದುಹಾಕುವುದು ಆ ಅಧಿವೇಶನಕ್ಕೆ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ: ಅದು ತನ್ನದೇ ತುದಿ ಬಿಂದುವಿನವರೆಗೆ ರಕ್ಷಿತವಾಗಿರುತ್ತದೆ, ಆ ತುದಿ ಬಿಂದು ಎಲ್ಲಿದ್ದರೂ.

ಸಾಮಾನ್ಯ ಅತಿ-ಸರಿಪಡಿಸುವಿಕೆ ಎಂದರೆ ಗೇಟ್ವೇಯ ಹಿಂದೆ ಎಲ್ಲವೂ ಬಯಲಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವುದು. ಹಾಗಿಲ್ಲ. ಸೇವಾ ಸಾಗಣೆ, ಸಂಗ್ರಹ ಎನ್ಕ್ರಿಪ್ಷನ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ TLS ವಿಭಿನ್ನ ಷರತ್ತುಗಳಿರುವ ವಿಭಿನ್ನ ಕಾರ್ಯವಿಧಾನಗಳು, ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನೂ VPN ನ ಆಕಾರದಿಂದ ಊಹಿಸುವ ಬದಲು ಅದರದೇ ಷರತ್ತುಗಳ ಮೇಲೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಬೇಕು. ACCEPT ತೋರಿಸುವ ಹರಿವು ಲಾಗ್ ನಮೂದು ಮಾರ್ಗನಿರ್ದೇಶನ ಕೆಲಸ ಮಾಡಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ ಮತ್ತು ಗೋಪ್ಯತೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಈ ಪರಿಶೀಲನಾ ಪಟ್ಟಿ ಅದೇ ತಪ್ಪನ್ನು ತಡೆಯಲು ಇದೆ.

ಪರಿಶೀಲನೆ 3: ಗೇಟ್ವೇಯ ಹಿಂದೆ TLS ಅನ್ನು ಯಾವುದು ಕೊನೆಗೊಳಿಸುತ್ತದೆ

ವಿಳಾಸವನ್ನಲ್ಲ, ಶ್ರೋತೃವನ್ನು ಅನುಸರಿಸಿ. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅಥವಾ ಪ್ರಾಕ್ಸಿ TLS ಅನ್ನು ಕೊನೆಗೊಳಿಸಿದರೆ, ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವ ಸಂಪರ್ಕ ಅಲ್ಲೇ ಮುಗಿಯುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಬ್ಯಾಕೆಂಡ್ಗೆ ಎರಡನೇ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ, ಅದು ಸರಳ ಪಠ್ಯ ಅಥವಾ ಬೇರೆ ನಂಬಿಕೆ ಸರಪಳಿಯ TLS ಆಗಿರಬಹುದು. ಖಾಸಗಿ IP ವಿಳಾಸ ಮತ್ತು ಹೊಂದಿಕೆಯಾಗುವ ಮಾರ್ಗ ಆ ಎರಡನೇ ಸಂಪರ್ಕದ ಬಗ್ಗೆ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ನಿಮಗೆ ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ತುದಿ ಬಿಂದುವನ್ನು VPC ಒಳಗಿನಿಂದ ಪರೀಕ್ಷಿಸಿ, ಒಮ್ಮೆ ಪರಿಹರಿಸಿದ IP ಬದಲು ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ಹೆಸರಿನೊಂದಿಗೆ:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

ವಿನಂತಿ ಹಾದುಹೋಗುವ ಪ್ರತಿ ಹಾಪ್ಗೂ ಇದನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಉತ್ತರ ಕ್ಲೈಂಟ್ ಕಡೆಗಿನ ಹೆಸರು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಹೆಸರಿನ ನಡುವೆ ಭಿನ್ನವಾಗಿದ್ದರೆ, VPN ಎಂದೂ ಆವರಿಸದಿದ್ದ ವಿಭಾಗವನ್ನೇ ನೀವು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ, ಮತ್ತು ಅದೇ ಬರೆಯಬೇಕಾದ ಸಂಶೋಧನೆ.

ಫಲಿತಾಂಶವನ್ನು ತೀರ್ಪಿನಂತೆ ಅಲ್ಲ, ವಿಭಾಗಗಳಂತೆ ದಾಖಲಿಸಿ

ಈ ಪರಿಶೀಲನಾ ಪಟ್ಟಿಯ ಔಟ್ಪುಟ್ ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಒಂದು ಸಾಲಿನ ಸಣ್ಣ ಕೋಷ್ಟಕ: ಗ್ರಾಹಕ ಗೇಟ್ವೇಯಿಂದ AWS VPN ಗುರಿಯವರೆಗೆ, ಗೇಟ್ವೇಯಿಂದ ಕೆಲಸದ ಹೊರೆಗೆ, ಕೆಲಸದ ಹೊರೆಯಿಂದ ಡೇಟಾ ಸಂಗ್ರಹಕ್ಕೆ, ಮತ್ತು ನಡುವೆ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಹಾಪ್. ಪ್ರತಿ ಸಾಲು ಅದನ್ನು ಯಾವುದು ರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಆ ರಕ್ಷಣೆ ಯಾವುದನ್ನು ಅವಲಂಬಿಸಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಕಾರ್ಯವಿಧಾನ ಮತ್ತು ತುದಿ ಬಿಂದು ಇಲ್ಲದ "ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿದೆ" ಸಾಲಲ್ಲ.

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

ಸಂಪರ್ಕ ಗುರುತಿಸುವಿಕೆಗಳು, ಸುರಂಗಗಳ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳ ವಿಷಯಗಳನ್ನು ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ. ಆರು ತಿಂಗಳ ನಂತರ ಯಾರಾದರೂ ವಿನ್ಯಾಸಕ್ಕೆ ಮರಳಿದಾಗ, ಆ ಮೂರು ಕಲಾಕೃತಿಗಳು ನಿಮಿಷಗಳಲ್ಲಿ ಗಡಿಯ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ, ರೇಖಾಚಿತ್ರದಿಂದ ವಾದವನ್ನು ಮತ್ತೆ ಆರಂಭಿಸುವ ಬದಲು.