EC2 ನಲ್ಲಿ strongSwan: VPC ಕೆಲಸದ ಹೊರೆಯನ್ನು ರೂಟ್ ಮಾಡಲಿ

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

ಮೊದಲು ನಾಲ್ಕು ವಿಳಾಸಗಳನ್ನು ಬರೆದಿಡಿ

ಕೆಳಗಿನ ಪ್ರತಿ ಹಂತವೂ ಇವುಗಳನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಅವನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಖಾತೆಗೆ ಭರ್ತಿ ಮಾಡಿ.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

ಉದಾಹರಣೆಯು ಅನುಮೋದಿತ, ಕಾರ್ಯನಿರ್ವಹಣೆಯ ನೀತಿ-ಆಧಾರಿತ IPsec ಸಂಪರ್ಕ ಮತ್ತು ಮೂಲವನ್ನು ಕಾಪಾಡುವ ಹರಿವನ್ನು ಊಹಿಸುತ್ತದೆ. ಇದು ಒಂದು ಹಂಚಿಕೆಯಾದ ವಿಳಾಸವನ್ನು ಎರವಲು ಪಡೆಯುವ NAT ಇರುವ ದೂರಸ್ಥ ಪ್ರವೇಶ ಕ್ಲೈಂಟ್ ಅಲ್ಲ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಆಯ್ಕೆಕಾರಕಗಳನ್ನು ಬದಲಿಸಬೇಕೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಹಂತ 1: ಕೆಲಸದ ಹೊರೆಯ ಉಪಜಾಲಕ್ಕೆ ಒಂದು ರೂಟ್ ಕೊಡಿ

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

AWS ನ ಸಾಧನದ ಮೂಲಕ ರೂಟಿಂಗ್ ಮಾರ್ಗದರ್ಶನ ಜಾಲ ಸಂಪರ್ಕಸಾಧನದ ಗುರಿಗಳನ್ನು ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಇನ್‌ಸ್ಟನ್ಸ್‌ನ ಮೂಲ/ಗಮ್ಯ ಪರಿಶೀಲನೆಯ ಅಗತ್ಯವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಆ ಪರಿಶೀಲನಾ ಬದಲಾವಣೆಯನ್ನು ಗೇಟ್‌ವೇ ಪಾತ್ರಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ, ಮತ್ತು ಸಾಮಾನ್ಯ ಅಪ್ಲಿಕೇಶನ್ ಇನ್‌ಸ್ಟನ್ಸ್‌ಗಳನ್ನು ಶಾಂತಿಯಿಂದ ಬಿಡಿ.

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

ಹಂತ 2: ಅತಿಥಿಯಲ್ಲಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಆನ್ ಮಾಡಿ

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

ಭದ್ರತಾ ಗುಂಪುಗಳು ಈ ಹಂತ ಸಾಮಾನ್ಯವಾಗಿ ನಿಲ್ಲುವ ಸ್ಥಳ. ಮಧ್ಯವರ್ತಿ ಸಾಧನವು ನೇರ ಇನ್‌ಸ್ಟನ್ಸ್ ಸಂವಹನದ ಭದ್ರತಾ ಗುಂಪು ಉಲ್ಲೇಖ ವರ್ತನೆಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿರ್ವಹಿತ Client VPN ಉದಾಹರಣೆಯಿಂದ ನಕಲಿಸಿದ ನಿಯಮ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದಿರಬಹುದು. ನಿಜವಾದ ಮಾರ್ಗದಲ್ಲಿ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಭದ್ರತಾ ಗುಂಪು ಮತ್ತು ಉಪಜಾಲದ ACL ಪರಿಶೀಲಿಸಿ.

ಹಂತ 3: ಆಯ್ಕೆಕಾರಕಗಳನ್ನು ನಿಜವಾದ ಮೂಲಗಳವರೆಗೆ ವಿಸ್ತರಿಸಿ

AWS ಬದಿಯಲ್ಲಿ ಕೇವಲ 10.60.1.10/32 ಅನ್ನು ಆವರಿಸುವ ನೀತಿ 10.60.2.20 ಅನ್ನು ಆವರಿಸದೆ ಗೇಟ್‌ವೇಯಿಂದ ಪ್ರಾರಂಭವಾದ ಯಶಸ್ಸನ್ನು ವಿವರಿಸುತ್ತದೆ. ದೂರದ ಗಮ್ಯದ ಕಡೆಗಿನ ಮಾರ್ಗ ಸಂಚಾರ ಆಯ್ಕೆಕಾರಕವನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಅಚ್ಚರಿಯ ಎರಡನೇ ಅರ್ಧ.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

ಒಪ್ಪಿದ ವಿನ್ಯಾಸವು ಇಡೀ VPC ಯನ್ನು ರಕ್ಷಿಸಿದರೆ, ಎರಡೂ ಪಕ್ಷಗಳು 10.60.0.0/16 ಮತ್ತು 10.90.0.0/24 ಅನ್ನು ಒಪ್ಪಬೇಕು. ಅದು ಒಂದು ಕೆಲಸದ ಹೊರೆಯನ್ನು ರಕ್ಷಿಸಿದರೆ, ಆ ಕಿರಿದಾದ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬಳಸಿ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಸ್ಥಾಪಿತ CHILD-SA ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನೀವು ಸಂಪಾದಿಸಿದ ಸಂರಚನೆ ಮತ್ತು ಅದನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಕಿರಿದಾಗಿಸಿದ ಪಕ್ಷ ಒಂದೇ ಒಪ್ಪಂದವಲ್ಲ.

ದೂರದ ತಾಣವೂ ಸಹ ಸಂರಕ್ಷಿತ VPC ಮೂಲಗಳ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಉದ್ದೇಶಿತ IPsec ಗೇಟ್‌ವೇ ಮೂಲಕ ಹಿಂತಿರುಗಿ ರೂಟ್ ಮಾಡಬೇಕು. ಬೇರೆ ಮೂಲ NAT ನಿಯಮಗಳಿರುವಲ್ಲಿ ಸಂರಕ್ಷಿತ ಸಂಚಾರಕ್ಕೆ ಬೆಂಬಲಿತ NAT ವಿನಾಯಿತಿಯನ್ನು ಉಳಿಸಿ; ಅನುಮೋದಿಸದ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಅನುಮತಿಸಿದ ಹೋಸ್ಟ್ ವಿಳಾಸಕ್ಕೆ ಅನುವಾದಿಸುವುದು ಬೇರೆ ಗುರುತಿನ ಒಪ್ಪಂದ, ನೀವು ಬಯಸಿದ ಪ್ರವೇಶದ ಶಾರ್ಟ್‌ಕಟ್ ಅಲ್ಲ.

ಹಂತ 4: ಪರಿಶೀಲಿಸಿ, ನಂತರ ಅಗತ್ಯವಿದ್ದರೆ ಹಿಂತಿರುಗಿಸಿ

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

ಗೇಟ್‌ವೇ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗಲೂ ಕೆಲಸದ ಹೊರೆ ವಿಫಲವಾದರೆ, ಹಂತಗಳ ಮೂಲಕ ಕ್ರಮವಾಗಿ ಹಿಂದಕ್ಕೆ ಹೋಗಿ: ಆಯ್ಕೆಕಾರಕ, ನಂತರ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಭದ್ರತಾ ಗುಂಪುಗಳು, ನಂತರ ಸಂಬಂಧಿತ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಬೇರೆ ಲಕ್ಷಣವಿದೆ, ಮತ್ತು ಊಹೆ ನಿಜವಾಗಿ ತಪ್ಪಾದದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.

ಹಿಂತಿರುಗಿಸುವಿಕೆ ಅದೇ ಕ್ರಮವನ್ನು ತಿರುಗಿಸುತ್ತದೆ. ಕೆಲಸದ ಹೊರೆಯ ಉಪಜಾಲದ ರೂಟ್ ಅನ್ನು ಕೊನೆಯದಾಗಿ ತೆಗೆಯಿರಿ, ಹಿಂದಿನ ಆಯ್ಕೆಕಾರಕಗಳನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ, ಅದರ ಮೂಲಗಳನ್ನು ಇನ್ನು ರಕ್ಷಿಸದ ಗೇಟ್‌ವೇ ಕಡೆಗೆ ತೋರುವ ಉಪಜಾಲವನ್ನು ಬಿಡದಿರಲು. ಈ ಒಪ್ಪಂದಗಳು ನಿಂತಾಗ ಸ್ವಯಂ-ಹೋಸ್ಟಿಂಗ್ ಗೇಟ್‌ವೇ ಹೋಸ್ಟ್‌ಗಿಂತ ಹೆಚ್ಚು ಸೇವೆ ಮಾಡಬಹುದು, ಮತ್ತು AWS-ನಿರ್ವಹಿತ Site-to-Site VPN ಎಂಬುದು ಬೇರೆ ಕಾರ್ಯಾಚರಣಾ ಮಾದರಿ, ಅಲ್ಲಿ strongSwan ಬದಲಿಗೆ ಗ್ರಾಹಕ ಗೇಟ್‌ವೇ ತುದಿಯಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳಬಹುದು.