strongSwan trap ಮೋಡ್: IPsec ಟನೆಲ್ ಸಂಚಾರಕ್ಕಾಗಿ ಏಕೆ ಕಾಯುತ್ತದೆ

ಸ್ಥಿತಿ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಯಾವುದೇ CHILD SA ಕಾಣಿಸುವುದಿಲ್ಲ, ಟನೆಲ್ ಸತ್ತಂತೆ ಕಾಣುತ್ತದೆ, ನಂತರ ದೂರದ ಸಬ್‌ನೆಟ್‌ಗೆ ping ಅದನ್ನು ಮೇಲೆತ್ತುತ್ತದೆ. ಆನ್-ಡಿಮಾಂಡ್ IPsec ಸೆಟಪ್‌ನಲ್ಲಿ ಈ ಕ್ರಮವೇ ವಿನ್ಯಾಸ, ದೋಷವಲ್ಲ. trap ನೀತಿ ಸೆಲೆಕ್ಟರ್ ಸ್ಥಾಪಿಸಿ ಕಾಯುತ್ತದೆ, ಮತ್ತು ಅದಕ್ಕೆ ಹೊಂದುವ ಮೊದಲ ಪ್ಯಾಕೆಟ್ IKE ಮತ್ತು CHILD SA ಮಾತುಕತೆಯನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಗೊಂದಲದ ಒಂದು ಭಾಗ ಪದಕೋಶ: “up” ಎರಡು ವಿಭಿನ್ನ ಸ್ಥಿತಿಗಳಿಗೆ ಬಳಸಲಾಗುತ್ತದೆ. ಸಂರಚನೆ ಲೋಡ್ ಆಗಿದೆ ಮತ್ತು ಕರ್ನಲ್ ನೀತಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಆದರೆ ಡೇಟಾ ಸಂಘಟನೆ ಇಲ್ಲ. ಕೇವಲ ಸಕ್ರಿಯ SA ಎಣಿಸುವ ಮಾನಿಟರ್ ಆರೋಗ್ಯಕರ ಸೈಟ್ ಅನ್ನು ಯಾರೂ ಅಲ್ಲಿಗೆ ಸಂಚಾರ ಕಳುಹಿಸದಿರುವವರೆಗೆ ಡೌನ್ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.

ನಿಷ್ಕ್ರಿಯ ಆನ್-ಡಿಮಾಂಡ್ ಟನೆಲ್‌ಗೆ ತೋರಿಸಲು CHILD SA ಇಲ್ಲ

trap ನಮೂದು ತಾನೇ ಏನನ್ನೂ ದೃಢೀಕರಿಸುವುದಿಲ್ಲ. ಆಯ್ಕೆಮಾಡಿದ ಸಂಚಾರಕ್ಕೆ ನೀತಿಯನ್ನು ಇಟ್ಟುಕೊಳ್ಳಲು ಮತ್ತು ಪ್ಯಾಕೆಟ್‌ಗೆ ಆ ನೀತಿ ಬೇಕಾದಾಗ acquisition ಎತ್ತಲು ಕರ್ನಲ್‌ಗೆ ಕೇಳುತ್ತದೆ. ಡೀಮನ್ acquisition ಸ್ವೀಕರಿಸಿ, ಅದನ್ನು child ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಹೊಂದಿಸಿ ಅಲ್ಲಿಂದ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ. ಆ ಕ್ಷಣದವರೆಗೆ ತೋರಿಸಲು IKE SA ಕೂಡ ಇಲ್ಲ, ಹಾಗಾಗಿ ಎರಡೂ ಪಟ್ಟಿಗಳು ಒಟ್ಟಿಗೆ ಖಾಲಿ ಇರಬಹುದು.

ಈ ಕ್ರಮವೇ ಲಾಗ್‌ಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಮೊದಲು acquisition ಬರುತ್ತದೆ, ನಂತರ IKE_SA_INIT ಮತ್ತು IKE_AUTH, ನಂತರ CHILD SA. ಲಾಗ್ acquisition ನಂತರ ತಕ್ಷಣ ಮುಗಿದರೆ, ಟ್ರಿಗರ್ ಕೆಲಸ ಮಾಡಿದೆ. ಮಾತುಕತೆ ವಿಫಲವಾಗಿದೆ, ಮತ್ತು ಮುಂದಿನ ಪ್ರಶ್ನೆ ರುಜುವಾತು, ಪ್ರಸ್ತಾವಗಳು ಅಥವಾ ತಲುಪುವಿಕೆ ಬಗ್ಗೆ, trap ಬಗ್ಗೆ ಅಲ್ಲ.

Linux ಕರ್ನಲ್ ಬ್ಯಾಕೆಂಡ್‌ನಲ್ಲಿ ಯಾವುದೇ SA ಇರುವ ಮೊದಲೇ ನೀತಿ ನೋಡಬಹುದು. ಇದನ್ನು ಚಲಾಯಿಸಿ ip xfrm policy ಮತ್ತು out ದಿಕ್ಕು ಹಾಗೂ ಸಂಪರ್ಕಕ್ಕೆ ಸೂಚಿಸುವ ಟೆಂಪ್ಲೇಟ್ ಇರುವ ಸೆಲೆಕ್ಟರ್ ಹುಡುಕಿ. ಆ ನಮೂದೇ ಆನ್-ಡಿಮಾಂಡ್ ಸ್ಥಿತಿ, ಮತ್ತು ಅದರ ಅಸ್ತಿತ್ವವೇ ಮೊದಲು ಖಚಿತಪಡಿಸಬೇಕಾದದ್ದು.

start_action ಏನಾದರೂ ಕಾಯುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ

ಪ್ರತಿ child swanctl.conf ನಲ್ಲಿ start_action. start ಸಂರಚನೆ ಲೋಡ್ ಆದಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, trap ನೀತಿ ಸ್ಥಾಪಿಸಿ ಕಾಯುತ್ತದೆ, ಮತ್ತು none ಪ್ರಾರಂಭವನ್ನು ಬೇರೆ ಯಾವುದಕ್ಕೋ ಬಿಡುತ್ತದೆ. ಕೇವಲ trap ಮೇಲೆ ವಿವರಿಸಿದ “ping ಮತ್ತು ಅದು ಮೇಲೇರುತ್ತದೆ” ವರ್ತನೆ ಉಂಟುಮಾಡುತ್ತದೆ.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

ಎರಡು ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಯಾವುದು ಆಸಕ್ತಿಕರ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತವೆ, ಮತ್ತು ಆ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳ ಹೊರಗಿನ ಹೋಸ್ಟ್‌ನ ಪ್ಯಾಕೆಟ್ trap ಅನ್ನು ಪ್ರಚೋದಿಸುವುದಿಲ್ಲ; ಅದು ಸಾಮಾನ್ಯವಾಗಿ ರೂಟ್ ಆಗುತ್ತದೆ. ಟ್ರಿಗರ್ ಇನ್ನಷ್ಟು ಉತ್ಸಾಹಿಯಾಗಲು ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಅಗಲಿಸುವುದು ಟನೆಲ್ ರಕ್ಷಿಸುವುದಾಗಿ ಹೇಳಿಕೊಳ್ಳುವ ವ್ಯಾಪ್ತಿಯನ್ನೂ ಅಗಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ನಿಜವಾಗಿ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಬಯಸುವ ಸಂಚಾರದಿಂದ ಅವುಗಳನ್ನು ಪಡೆಯಿರಿ.

ಇಲ್ಲಿ swanctl.conf ಉಲ್ಲೇಖ ಸ್ವೀಕೃತ ಮೌಲ್ಯಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಜೊತೆಗೆ SA ಇದ್ದ ನಂತರ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿಯಂತ್ರಿಸುವ ಪ್ರತ್ಯೇಕ close ಮತ್ತು DPD ಕ್ರಿಯೆಗಳು.

ಟ್ರಿಗರ್ ಆದರೂ ಪ್ರಚೋದನೆಯಾಯಿತೇ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ಇದರಿಂದ ಪ್ರಾರಂಭಿಸಿ swanctl --list-conns ಮತ್ತು child ನೀವು ಉದ್ದೇಶಿಸಿದ ಕ್ರಿಯೆಯೊಂದಿಗೆ ಲೋಡ್ ಆಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ local_ts ಒಳಗಿನ ಹೋಸ್ಟ್‌ನಿಂದ remote_ts ಒಳಗಿನ ವಿಳಾಸಕ್ಕೆ ಒಂದು ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿ ಮತ್ತು swanctl --list-sas ಗಮನಿಸಿ. ಔಟ್‌ಪುಟ್ ಬದಲಾಗದಿದ್ದರೆ, ಯಾವುದೇ acquisition ಡೀಮನ್ ತಲುಪಿಲ್ಲ.

ಮೌನ trap ಗೆ ಎರಡು ಸಾಮಾನ್ಯ ಕಾರಣಗಳು: ಪ್ಯಾಕೆಟ್ ನೀತಿ ತಲುಪುವ ಮೊದಲೇ source-NAT ಆಗಿ ಈಗ local_ts ಗೆ ಹೊಂದಿಕೆಯಾಗುತ್ತಿಲ್ಲ, ಅಥವಾ ಸಿಂಟ್ಯಾಕ್ಸ್ ಅಥವಾ ರುಜುವಾತು ದೋಷದಿಂದ ಸಂಪರ್ಕ ಎಂದೂ ಲೋಡ್ ಆಗಿಲ್ಲ. ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು swanctl --load-all ಮತ್ತೆ ಚಲಾಯಿಸಿ ಅದರ ಔಟ್‌ಪುಟ್ ಓದಿ. ಲೋಡ್ ಆಗದ ಸಂಪರ್ಕ ಯಾವುದೇ ನೀತಿ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಸಂಚಾರಕ್ಕೆ ಪ್ರಚೋದಿಸಲು ಏನೂ ಇಲ್ಲ.

ದಿಕ್ಕೂ ಮುಖ್ಯ: ಹೊರಹೋಗುವ ಸಂಚಾರಕ್ಕೆ ಸ್ಥಾಪಿಸಿದ trap ಒಳಬರುವ ಪ್ಯಾಕೆಟ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ದೂರದ ಬದಿಯೇ ಟನೆಲ್ ಎತ್ತಬೇಕಿದ್ದರೆ ಅದಕ್ಕೆ ತನ್ನದೇ trap ಬೇಕು, ಅಥವಾ ಈ ಬದಿಗೆ start.

ಮೊದಲ ಪ್ಯಾಕೆಟ್‌ಗಾಗಿ ಕಾಯುವುದು ಯಾವಾಗಲೂ ಸರಿಯಾದ ವಿನಿಮಯವಲ್ಲ

ಸಂವಾದಾತ್ಮಕ ಅಧಿವೇಶನಗಳು ಸೆಟಪ್ ವೆಚ್ಚವನ್ನು ಗಮನಿಸುತ್ತವೆ. ಮೊದಲ ವಿನಂತಿ IKE ವಿನಿಮಯ ಮತ್ತು CHILD ಮಾತುಕತೆಯ ಬೆಲೆ ತೆರುತ್ತದೆ, ಮತ್ತು ಕಡಿಮೆ ಅವಧಿಯ ಕ್ಲೈಂಟ್ SA ಇರುವ ಮೊದಲೇ ಬಿಟ್ಟುಬಿಡಬಹುದು. ಸಕ್ರಿಯ start ಆ ಮೊದಲ-ಪ್ಯಾಕೆಟ್ ವಿಳಂಬವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಆದರೆ ಎಂದೂ ಬಾರದ ಸಂಚಾರಕ್ಕಾಗಿ ಟನೆಲ್ ಎತ್ತಿಟ್ಟಿರುತ್ತದೆ.

ಮೂರು ಸಂಗತಿಗಳು ಆಯ್ಕೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ: ಮಾರ್ಗ ಎಷ್ಟು ಬಾರಿ ಬಳಕೆಯಾಗುತ್ತದೆ, ಮೊದಲ ವಿನಂತಿಗೆ ಬಿಗಿಯಾದ ಗಡುವು ಇದೆಯೇ, ಮತ್ತು ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಪೀರ್ ತಲುಪಲು ಸಾಧ್ಯವೇ. ಆಗೊಮ್ಮೆ ಈಗೊಮ್ಮೆ ಬರುವ ಬ್ಯಾಚ್ ಸಂಚಾರ ಮತ್ತು ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಆಫ್‌ಲೈನ್ ಆಗಿರಬಹುದಾದ ಪೀರ್ ಎರಡೂ trap ಪರವಾಗಿವೆ. ವಿಳಂಬಕ್ಕೆ ಸಂವೇದನಶೀಲ ಕ್ಲೈಂಟ್ ಮತ್ತು ಯಾವಾಗಲೂ ತಲುಪಬಹುದಾದ ಪೀರ್ start ಪರವಾಗಿವೆ. ಎರಡೂ ಕಡೆ ಪ್ರಾರಂಭಿಸಬಹುದಾದರೆ, ದ್ವಿಗುಣ ಮಾತುಕತೆ ಬೇಡವೆಂದರೆ ಟ್ರಿಗರ್ ಯಾರದು ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ.

ಸ್ಥಾಪಿತ ನೀತಿ ಕೂಡ ಸೋರಿಕೆ-ನಿರೋಧಕ ಖಾತರಿ ಅಲ್ಲ. ಅಗತ್ಯ fail-closed ಆಗಿದ್ದರೆ, ಫೈರ್‌ವಾಲ್ SA ಇಲ್ಲದ ಸಂಚಾರವನ್ನು ಬೀಳಿಸಬೇಕು, ಮತ್ತು ಆ ನಿಯಮ child ವ್ಯಾಖ್ಯಾನದ ಹೊರಗಿದೆ.

ಮುಂದಿನ ವಾದವನ್ನು ಮುಗಿಸುವ ಮೂರು ಸಾಲುಗಳನ್ನು ಬರೆಯಿರಿ

ಸೆಲೆಕ್ಟರ್‌ಗಳು, ಪ್ರಾರಂಭದ ಕ್ರಿಯೆ ಮತ್ತು SA ಇಲ್ಲದೆ ನೀತಿ ಇರುವುದನ್ನು ತೋರಿಸುವ ಕಮಾಂಡ್ ಔಟ್‌ಪುಟ್ ಬರೆಯಿರಿ. ಆ ಮೂರು ಸಾಲುಗಳು ಮುಂದಿನ ಬಾರಿ ಯಾರಾದರೂ ಟನೆಲ್ ಡೌನ್ ಎಂದು ವರದಿ ಮಾಡಿದಾಗ “ಆನ್-ಡಿಮಾಂಡ್ ಮತ್ತು ನಿಷ್ಕ್ರಿಯ” ಮತ್ತು “ಲೋಡ್ ಆಗುತ್ತಿಲ್ಲ” ನಡುವೆ ವ್ಯತ್ಯಾಸ ಮಾಡುತ್ತವೆ. ಅವನ್ನು ದಾಖಲಿಸಲು ಒಂದು ನಿಮಿಷ ಸಾಕು. ಅವು ಇಲ್ಲದೆ ಅದೇ ತನಿಖೆ ಶೂನ್ಯದಿಂದ ಆರಂಭವಾಗುತ್ತದೆ.

ನಿಜವಾಗಿ ಸೆಲೆಕ್ಟರ್ ಒಳಗಿರುವ ಹೋಸ್ಟ್‌ನಿಂದ ಪರೀಕ್ಷಿಸಿ. ರೌಟರ್‌ನಿಂದಲೇ ಮಾಡುವ ping ಸಾಮಾನ್ಯವಾಗಿ ಬೇರೆ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಅದರ ಹಿಂದಿನ ಸಬ್‌ನೆಟ್ ಅನ್ನು ರಕ್ಷಿಸುವ ನೀತಿ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.