strongSwan ನಿಂದ AWS Site-to-Site ಗೆ: Child SA ಏಕೆ ಏನನ್ನೂ ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ

IKE ಸುರಂಗವು ಮೇಲಿರಬಹುದು, ಆದರೆ ಚೈಲ್ಡ್ ಸಂಬಂಧವು ನಿಮ್ಮ ಸಬ್ನೆಟ್ಗಳನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಮೊದಲು AWS ನ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ CIDR ಅನ್ನು leftsubnet ಮತ್ತು rightsubnet ಜೊತೆ ಹೋಲಿಸಿ.

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

AWS ನ ಹೆಸರುಗಳನ್ನು strongSwan ಪದಗಳಿಗೆ ಅನುವಾದಿಸಿ

AWS ಸಂಪರ್ಕವನ್ನು ಗ್ರಾಹಕರ ಬದಿಯಿಂದ ವಿವರಿಸುತ್ತದೆ: ಗ್ರಾಹಕ ಗೇಟ್ವೇ ವಿಳಾಸ ಮತ್ತು ಸ್ಥಳೀಯ CIDR ನಿಮ್ಮದು, ಮತ್ತು ದೂರದ CIDR VPC ಗೆ ಸೇರಿದೆ. strongSwan ಎರಡು ತುದಿಗಳನ್ನು left ಮತ್ತು right ಎಂದು ಕರೆಯುತ್ತದೆ, ನಿಮ್ಮ ಪ್ರಿಫಿಕ್ಸ್ leftsubnet ನಲ್ಲಿದೆ, VPC ಯ ಪ್ರಿಫಿಕ್ಸ್ rightsubnet ನಲ್ಲಿದೆ. ಒಂದು ಜೋಡಿಯನ್ನು ತಿರುಗಿಸಿದರೆ ತಪ್ಪು ಸಂಚಾರವನ್ನು ಮಾತುಕತೆ ನಡೆಸಿ ಆಯ್ಕೆ ಮಾಡುವ ಸುರಂಗ ಉಂಟಾಗುತ್ತದೆ.

AWS ಸಂಪರ್ಕಕ್ಕಾಗಿ ರಚಿಸುವ ಸಂರಚನೆಯನ್ನು ಡೌನ್ಲೋಡ್ ಮಾಡಿ ಮತ್ತು ಸುರಂಗದ ವಿಳಾಸಗಳು ಹಾಗೂ ಪ್ರಿಫಿಕ್ಸ್ಗಳೊಂದಿಗೆ ಅದನ್ನೇ ಆ ಸಂಪರ್ಕದ ಉಲ್ಲೇಖವೆಂದು ಪರಿಗಣಿಸಿ. ರಚಿಸುವಾಗ ಎರಡೂ CIDR ಕ್ಷೇತ್ರಗಳನ್ನು ಖಾಲಿ ಬಿಟ್ಟರೆ ಸೇವೆ ಪ್ರತಿ ಬದಿಯಲ್ಲಿ 0.0.0.0/0 ಡಿಫಾಲ್ಟ್ ಬಳಸುತ್ತದೆ. ಸಂಕುಚಿತ ಪ್ರಿಫಿಕ್ಸ್ನೊಂದಿಗೆ ಸಂರಚಿಸಿದ ರೂಟರ್ ಆಗ ಎಂದಿಗೂ ಹೊಂದಿಕೆಯಾಗದು, ಆದ್ದರಿಂದ ಕ್ಷೇತ್ರಗಳನ್ನು ತುಂಬಿಸಿ ಅಥವಾ ಸೆಲೆಕ್ಟರ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅಗಲಗೊಳಿಸಿ.

ಇಲ್ಲಿನ ಅಸಂಗತಿ ರೂಟಿಂಗ್ ವೈಫಲ್ಯದಂತೆ ಕಾಣುತ್ತದೆ ಮತ್ತು ಅದಲ್ಲ.

AWS ನಿಜವಾಗಿ ನೋಡುವ ವಿಳಾಸವನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ

NAT ಹಿಂದಿನ ರೂಟರ್ ಎದುರು ಬದಿ ಎಂದೂ ತಿಳಿಯದ ಇಂಟರ್ಫೇಸ್ನಿಂದ IKE ಕಳುಹಿಸಬಹುದು. AWS ನಲ್ಲಿ ದಾಖಲಾದ ಗೇಟ್ವೇ ವಿಳಾಸವು AWS ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ನೋಡುವ ವಿಳಾಸವೇ ಆಗಿರಬೇಕು, ಮತ್ತು ರೂಟರ್ ತನ್ನ ಡಿಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸುವ ಬದಲು ಅದೇ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಸ್ಥಿರಗೊಳ್ಳಬೇಕು.

conn %default
    local_addrs = 203.0.113.10

strongSwan ನಲ್ಲಿ local_addrs IKE ಗಾಗಿ ಮೂಲ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಹಳೆಯ OpenSwan ಸಂರಚನೆಗಳು ಅದೇ ಕಲ್ಪನೆಯನ್ನು left ಎಂದು ಬರೆಯುತ್ತವೆ. ಅದನ್ನು ಸಾರ್ವಜನಿಕ ವಿಳಾಸವಿರುವ ಇಂಟರ್ಫೇಸ್ಗೆ ತೋರಿಸಿ, ನಂತರ NAT ಸಾಧನದಲ್ಲೇ UDP 500 ಮತ್ತು 4500 ಆ ಹೋಸ್ಟ್ ತಲುಪುತ್ತವೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ರೂಟರ್ನಿಂದ ಉಳಿದ ನಿಯಮ ಅವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಸರಿಯಾದ ಸೆಲೆಕ್ಟರ್ ಜೋಡಿ ತಪ್ಪು ಮೂಲ ವಿಳಾಸದೊಂದಿಗೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ ಪ್ರಸ್ತಾಪವನ್ನೇ ದೂಷಿಸುತ್ತದೆ. ಈ ದಾರಿತಪ್ಪಿಸುವಿಕೆಯೇ ಮೂಲ ವಿಳಾಸಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಪರಿಶೀಲನೆ ಬೇಕೆಂಬ ಕಾರಣ.

ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮವನ್ನು ಊಹಿಸುವ ಬದಲು ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನ ರೂಟರ್ಗೆ ಸರಿಯಾಗಿದ್ದ ನಿಯಮ ಹೆಚ್ಚಾಗಿ ಉಳಿಯುತ್ತದೆ.

ಹಂತ 1 ಮತ್ತು ಹಂತ 2 ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನಿರ್ವಹಿಸಿ

AWS IKE ಮತ್ತು ESP ಆಯ್ಕೆಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಪಟ್ಟಿಗಳಾಗಿ ತೋರಿಸುತ್ತದೆ. ಎರಡೂ ಬದಿಗಳು ಒಪ್ಪುವ IKE ಸೆಟ್ ESP ಪ್ರಸ್ತಾಪದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಎರಡು ಪಟ್ಟಿಗಳು ಸ್ವತಂತ್ರ. ಎರಡನ್ನೂ ರಚಿಸಿದ ಸಂರಚನೆಯಿಂದ ಓದಿ ಒಂದೊಂದಾಗಿ ಹೋಲಿಸಿ.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

ವಾಕ್ಯರಚನೆ ಅನುಷ್ಠಾನಗಳ ನಡುವೆ ಸಾಗುವುದಿಲ್ಲ. OpenSwan ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಜೋಡಿ, ಉದಾಹರಣೆಗೆ phase2alg=aes_gcm ಜೊತೆಗೆ ike=aes256-sha1;modp1024, strongSwan ನ esp= ಮತ್ತು ike= ರೂಪಕ್ಕೆ ಅನುವಾದಿಸಬೇಕು, ಮತ್ತು ಅಲ್ಗಾರಿದಮ್ ಹೆಸರುಗಳು ಭಿನ್ನ. GCM ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವಾಗಲೇ ದೃಢೀಕರಿಸುವುದರಿಂದ ಅದಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಸಮಗ್ರತಾ ರೂಪಾಂತರ ಬೇಕಿಲ್ಲ, SHA ಜೊತೆ ಜೋಡಿಸಿದ CBC ಸೆಟ್ಗಿಂತ ಭಿನ್ನವಾಗಿ. ಒಂದು ಡೀಮನ್ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಅನುವಾದವಿಲ್ಲದೆ ಅಂಟಿಸಿದ ಹಂತ 2 ಸಾಲು ಸೆಲೆಕ್ಟರ್ ಅಸಂಗತಿಯಂತೆ ಕೇಳಿಸುವ ನಿರಾಕರಣೆ ಉಂಟುಮಾಡುತ್ತದೆ.

ಸುರಂಗ ಸೂಚಕವಲ್ಲ, ಚೈಲ್ಡ್ ಸಂಬಂಧವನ್ನು ಪರಿಶೀಲಿಸಿ

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

ipsec statusall

ಚೈಲ್ಡ್ ಭದ್ರತಾ ಸಂಬಂಧವನ್ನು ಹುಡುಕಿ ಅದರ ಪಕ್ಕದಲ್ಲಿ ಮುದ್ರಿತ ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಓದಿ, ನಂತರ ಅವನ್ನು ರಚಿಸಿದ ಸಂರಚನೆಯ ಪ್ರಿಫಿಕ್ಸ್ಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಸ್ಥಳೀಯ ಪ್ರಿಫಿಕ್ಸ್ ಒಳಗಿನ ಹೋಸ್ಟ್ನಿಂದ VPC ಪ್ರಿಫಿಕ್ಸ್ ಒಳಗಿನ ಹೋಸ್ಟ್ಗೆ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಮರಳು ಮಾರ್ಗವನ್ನೂ AWS ಬದಿಯ ಯಾವುದೇ ಭದ್ರತಾ ಗುಂಪು ಅಥವಾ ನೆಟ್ವರ್ಕ್ ACL ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಸರಿಯಾದ ಸೆಲೆಕ್ಟರ್ಗಳು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನಂತರ ಬಿಟ್ಟುಬಿಡುವುದರಿಂದ ರಕ್ಷಿಸುವುದಿಲ್ಲ.

ಸೆಲೆಕ್ಟರ್ಗಳು ಹೊಂದಿದ ನಂತರವೂ ವಿಫಲವಾದಾಗ

ಎರಡೂ ಬದಿಗಳ ಮಾರ್ಗ ಸುರಂಗದ ಕಡೆಗೆ ಇದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ನಂತರ NAT ಸಾಧನವು ನೀತಿ ನಿರೀಕ್ಷಿಸದ ರೀತಿಯಲ್ಲಿ ಸಂಚಾರವನ್ನು ಪುನಃ ಬರೆಯುತ್ತಿಲ್ಲ ಎಂದು ದೃಢೀಕರಿಸಿ. ನೀತಿ ಆಧಾರಿತ ಸುರಂಗ ಪ್ಯಾಕೆಟ್ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀತಿ ನಿರ್ಣಯದ ನಂತರ ಅನ್ವಯಿಸುವ ಅನುವಾದ ಫಲಿತಾಂಶವನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಇನ್ನೊಂದು ಪ್ರಸ್ತಾಪ ಬದಲಿಸುವ ಮೊದಲು ಪ್ರತಿ ಬದಿಯಲ್ಲಿ ಒಂದು ಒಳಬರುವ ಮತ್ತು ಒಂದು ಹೊರಹೋಗುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ.

ಟಿಕೆಟ್ನಲ್ಲಿ ಸೆಲೆಕ್ಟರ್ಗಳು, ಹಂತ 1 ಮತ್ತು ಹಂತ 2 ಪ್ರಸ್ತಾಪಗಳು ಮತ್ತು ಮೂಲ ವಿಳಾಸ ಬರೆಯಿರಿ. ಈ ನಾಲ್ಕು ಮೌಲ್ಯಗಳು ಕರೆಯಿಲ್ಲದೆ ಹೆಚ್ಚಿನ site-to-site ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು