IPsec ಒಳಗೆ IPsec: ಹೊರ ಸುರಂಗ ಯಾವ ವಿಳಾಸಗಳನ್ನು ಹೊತ್ತೊಯ್ಯಬೇಕು

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

ನಾಲ್ಕು ಪ್ರವೇಶ ದ್ವಾರಗಳ ಮಾದರಿ

ಹೊರ ಪ್ರವೇಶ ದ್ವಾರಗಳಾದ A ಮತ್ತು B ಎರಡು ಸೈಟ್ಗಳ ನಡುವೆ ಮೊದಲ ಸುರಂಗವನ್ನು ನಿರ್ಮಿಸುತ್ತವೆ. A ಯ ಹಿಂದೆ ಸಾಗಣೆ ವಿಳಾಸ 10.60.0.2 ಹೊಂದಿರುವ ಒಳ ಪ್ರವೇಶ ದ್ವಾರ C, ಮತ್ತು B ಯ ಹಿಂದೆ ಸಾಗಣೆ ವಿಳಾಸ 10.70.0.2 ಹೊಂದಿರುವ ಒಳ ಪ್ರವೇಶ ದ್ವಾರ D ಇದೆ. ಅಪ್ಲಿಕೇಶನ್ ಜಾಲಗಳು C ಮತ್ತು D ಯ ಹಿಂದೆ ಇವೆ, ಮತ್ತು ಉದಾಹರಣೆಯ ಪ್ರತಿ ವಿಳಾಸವೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅತಿಕ್ರಮಿಸುವುದಿಲ್ಲ.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

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

ಪ್ರತಿ ಪದರವು ತನ್ನದೇ ರಕ್ಷಣೆಯನ್ನು ಮಾತ್ರ ತೆಗೆದುಹಾಕುತ್ತದೆ

C, D ಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. ಫಲಿತಾಂಶ C ಯಿಂದ D ಗೆ ವಿಳಾಸಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಅದೇ A ಗೆ ತಲುಪುತ್ತದೆ. ಮುಂದಿನ ಎಲ್ಲವೂ ಆ ಮರುಬರವಣಿಗೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ.

A ಅದನ್ನು B ಗಾಗಿ ಮತ್ತೆ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. B ಹೊರ ಪದರವನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿ, C ಯಿಂದ D ಗೆ ಪ್ಯಾಕೆಟ್ ನೋಡಿ, ಅದನ್ನು ಇನ್ನೂ ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗಿಯೇ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. D ಒಳ ರಕ್ಷಣೆಯನ್ನು ತೆಗೆದು ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ ತಲುಪಿಸುತ್ತದೆ.

ಹೀಗಾಗಿ A ಮತ್ತು B ಒಳ ತುದಿಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ಮೆಟಾಡೇಟಾವನ್ನು ನೋಡುತ್ತವೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಪೇಲೋಡ್ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಪಕ್ಷಗಳು ಅವಲ್ಲ. ಇದು ವಿನ್ಯಾಸದ ನಿಜವಾದ ಗುಣಲಕ್ಷಣ, C, D ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಹೋಸ್ಟ್ಗಳು ವಿಶ್ವಾಸಾರ್ಹ ಎಂಬ ಹೇಳಿಕೆಯಲ್ಲ.

ಹೊರ ಸೆಲೆಕ್ಟರ್ಗಳು ಒಳ ಪ್ರವೇಶ ದ್ವಾರಗಳನ್ನು ಹೆಸರಿಸುತ್ತವೆ

ಇಲ್ಲಿಯೇ ಇಂತಹ ನಿರ್ಮಾಣಗಳ ಬಹುಪಾಲು ವಿಫಲವಾಗುತ್ತವೆ. ನೀತಿ ಆಧಾರಿತ ಹೊರ ಸುರಂಗಕ್ಕೆ, ನೀವು ಮಾತುಕತೆ ನಡೆಸುವ ಸೆಲೆಕ್ಟರ್ಗಳು A ಮತ್ತು B ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುವ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿರಬೇಕು: 10.60.0.2/32 ಮತ್ತು 10.70.0.2/32, ಸರಿಯಾದ ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ಕ್ರಮದಲ್ಲಿ.

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

ಹೊರ ಅನುಮತಿಯನ್ನು UDP 500 ಗೆ ಸಂಕುಚಿಸಬೇಡಿ. ಒಳ ಸಂಪರ್ಕಕ್ಕೆ ತನ್ನದೇ ಡೇಟಾ ಮಾರ್ಗವಿದೆ, ಅದು ಮಾತುಕತೆಯಾದುದನ್ನು ಅವಲಂಬಿಸಿ ESP ಅಥವಾ UDP ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಬಳಸುತ್ತದೆ, ಮತ್ತು ಹೊರ ನೀತಿ ಆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅನುಮತಿಸಬೇಕು.

ಪ್ರತಿ ಪ್ರವೇಶ ದ್ವಾರದಲ್ಲಿ swanctl --list-sas ಬಳಸಿ ಫಲಿತಾಂಶ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಚೈಲ್ಡ್ ಭದ್ರತಾ ಸಂಘಗಳು ನೀವು ಉದ್ದೇಶಿಸಿದ ವಿಳಾಸಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತವೆಯೇ, ಊಹಿಸಿದವುಗಳನ್ನಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪಟ್ಟಿ ಅಪ್ಲಿಕೇಶನ್ ಉಪಜಾಲಗಳನ್ನು ತೋರಿಸಿದರೆ, ಹೊರ ನೀತಿ ತಪ್ಪು ಪದರಕ್ಕೆ ಬರೆಯಲಾಗಿದೆ. ಮಾರ್ಗನಿರ್ದೇಶನ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಮಾರ್ಗನಿರ್ದೇಶನ ಸರಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಕೌಂಟರ್ಗಳು ಚಲಿಸುವುದಿಲ್ಲ.

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ಬಲೆ

ಸೆಲೆಕ್ಟರ್ಗಳು ಮಾರ್ಗನಿರ್ದೇಶನವನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. A ಮತ್ತು B C ಮತ್ತು D ನಡುವೆ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಸಂಚಾರ ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು, ಅಂದರೆ IP ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯ, ಸುರಂಗದತ್ತ ತೋರಿಸುವ ಮಾರ್ಗಗಳು ಮತ್ತು ಆಚೆಯ ಬದಿಯಲ್ಲಿ ಇರುವ ಮರಳು ಮಾರ್ಗ.

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

ಬಲೆ ಪುನರಾವರ್ತನೆ. B ಯ ಹೊರ ತುದಿಗೆ A ಯ ಮಾರ್ಗವು A ನಿರ್ಮಿಸುತ್ತಿರುವ ಸುರಂಗವನ್ನಲ್ಲ, ಕೆಳ ಪದರದ ಜಾಲವನ್ನು ಅನುಸರಿಸಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ತನ್ನೊಳಗೇ ಪ್ರಯಾಣಿಸಲು ಯತ್ನಿಸುತ್ತದೆ ಮತ್ತು ಸಂಪರ್ಕ ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳುವುದಿಲ್ಲ.

ಪದರಗಳನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಅನುವಾದವನ್ನು ಪರಿಶೀಲಿಸಿ

ಬೇರೆ ಯಾವುದನ್ನೂ ಟ್ಯೂನ್ ಮಾಡುವ ಮೊದಲು A ಮತ್ತು B ಯಲ್ಲಿನ ಯಾವುದೇ ಮೂಲ NAT ಅನ್ನು ನೋಡಿ. IPsec ನೀತಿ ಅನ್ವಯವಾಗುವ ಮೊದಲು C ಯ ವಿಳಾಸವನ್ನು ಮರುಬರೆಯುವ ನಿಯಮವು ಒಪ್ಪಿದ ಸೆಲೆಕ್ಟರ್ಗಳನ್ನು ಮುರಿಯಬಹುದು, ಮತ್ತು D ಆಚೆಯ ಬದಿಯಲ್ಲಿ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನೂ ಬದಲಾಯಿಸಬಹುದು.

ಎರಡು ಪದರಗಳಿರುವುದರಿಂದ ವಿಶಾಲ ಮಸ್ಕರೇಡಿಂಗ್ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವಾಗುವುದಿಲ್ಲ. ಅದು ದೂರದ ತುದಿ ಯಾವ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಸುರಂಗ ಚಾಲ್ತಿಯಲ್ಲಿದ್ದು ಅಪ್ಲಿಕೇಶನ್ ಇಲ್ಲದಿರುವಾಗ ಸರಿಯಾಗಿ ಆ ಮಾಹಿತಿ ಬೇಕಾಗುತ್ತದೆ.

NAT ನಿಯಮ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದರೆ, ಪ್ರತಿ ಬದಿಯೂ ಯಾವ ವಿಳಾಸದೊಂದಿಗೆ ಮಾತನಾಡುತ್ತಿದೆ ಎಂದು ಭಾವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಬರೆಯಿರಿ. ಆ ಒಂದೇ ಸಾಲು ಸುರಂಗವೋ ಅನುವಾದವೋ ತಪ್ಪಿತಸ್ಥ ಎಂಬ ಚರ್ಚೆಯ ಬಹುಪಾಲನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ. ಒಂದು ವರ್ಷದ ನಂತರ ನಿಯಮ ತೆಗೆದಾಗ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದೂ ಹೇಳುತ್ತದೆ. ಪಿಂಗ್ ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

fail-closed ಸಾಬೀತುಪಡಿಸಿ ಮತ್ತು MTU ಪರಿಶೀಲಿಸಿ

ಮಾರ್ಗ ಕಣ್ಮರೆಯಾಗುವುದು ತಾನಾಗಿಯೇ fail-closed ನೀತಿಯಲ್ಲ. ಇನ್ನೊಂದು ಕೋಷ್ಟಕ, ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಅಥವಾ ನೀತಿ ನಿಯಮವು ಮೌನವಾಗಿ ಪರ್ಯಾಯ ನೀಡಬಹುದು, ಮತ್ತು ಅದನ್ನು ತಿಳಿಯುವ ಏಕೈಕ ದಾರಿ ಹೊರ ಸುರಂಗವನ್ನು ಇಳಿಸಿ ಅಪ್ಲಿಕೇಶನ್ ಸಂಚಾರ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಗಮನಿಸುವುದು. ಆಕಸ್ಮಿಕವಾಗಿ ಕಂಡುಹಿಡಿಯುವ ಬದಲು ವಿಂಡೋದಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾಡಿ.

ಮೂರು ಸ್ಥಿತಿಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ: ಹೊರ ಸುರಂಗ ಕೆಳಗೆ, ಒಳ ಸುರಂಗ ಕೆಳಗೆ, ಮತ್ತು ಎರಡೂ ಮರಳಿ ಬಂದ ನಂತರ ಚೇತರಿಕೆ. ಪ್ರತಿ ಪ್ರವೇಶ ದ್ವಾರದಲ್ಲಿ ನೀತಿ ಕೌಂಟರ್ಗಳನ್ನು ಬಳಸಿ, ಏಕೆಂದರೆ ಎರಡು ಸ್ಥಾಪಿತ IKE ಅವಧಿಗಳು ನಿಯಂತ್ರಣ ಸ್ತರದ ಮಾತುಕತೆ ಯಶಸ್ವಿಯಾಯಿತು ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತವೆ.

ಎರಡೂ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ಗಳಿಗೂ ಬಜೆಟ್ ಮಾಡಿ. ಕೆಲಸ ಮಾಡುವ IKE ಸಣ್ಣ ಪ್ಯಾಕೆಟ್ಗಳ ಫಲಿತಾಂಶ, ಮತ್ತು ಎರಡು ಹೆಡರ್ಗಳನ್ನು ಸೇರಿಸಿದ ನಂತರ ಪೂರ್ಣ ಗಾತ್ರದ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ಗಳು ಇನ್ನೂ ವಿಫಲವಾಗಬಹುದು; ಸಂಖ್ಯೆಗಳು ಕೂಡುತ್ತವೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿಜವಾದ ಮಾರ್ಗದಲ್ಲಿ ತಿಳಿದ ಪೇಲೋಡ್ ಗಾತ್ರದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಗಣಿತ ಸುಲಭ, ಮಾರ್ಗ ಅಲ್ಲ.