ರೂಟ್ ಆಧಾರಿತ vs ನೀತಿ ಆಧಾರಿತ ಸೈಟ್ ಟು ಸೈಟ್ VPN: ಏನು ಭಿನ್ನವಾಗುತ್ತದೆ
ನೀತಿ ಆಧಾರಿತ IPsec ಸೆಲೆಕ್ಟರ್ ಮೂಲಕ ಸಂಚಾರವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ; ರೂಟ್ ಆಧಾರಿತವು ಅದನ್ನು ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ. ಎರಡಕ್ಕೂ ಇನ್ನೂ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳು ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು.
ಎರಡೂ ವಿನ್ಯಾಸಗಳು ಒಂದೇ ಸಂಚಾರವನ್ನು ಒಂದೇ IPsec ಯಂತ್ರದಿಂದ ರಕ್ಷಿಸುತ್ತವೆ ಮತ್ತು ಯಾವ ಪ್ಯಾಕೆಟ್ ಟನೆಲ್ ಪ್ರವೇಶಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಯಾವುದು ನಿರ್ಧರಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನವಾಗುತ್ತವೆ. ನೀತಿ ಆಧಾರಿತ ಸಂಪರ್ಕದಲ್ಲಿ ಮಾತುಕತೆ ಮಾಡಿದ ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್ಗಳು ಆ ಕೆಲಸ ಮಾಡುತ್ತವೆ; ರೂಟ್ ಆಧಾರಿತದಲ್ಲಿ ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ಗೆ ತೋರಿಸುವ ರೂಟ್ ಮಾಡುತ್ತದೆ. ಎರಡನ್ನೂ ಗೊಂದಲಿಸಿದರೆ ಟನೆಲ್ ಸ್ಥಾಪಿತ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲಿಗೂ ತಲುಪದ ಪರಿಚಿತ ಬೆಂಬಲ ಥ್ರೆಡ್ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸವು ನೆಟ್ವರ್ಕ್ ಸೇರಿಸುವಾಗ, ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಚಲಾಯಿಸುವಾಗ ಅಥವಾ ತಪ್ಪು ನಿರ್ಗಮನದ ಮೂಲಕ ಸದ್ದಿಲ್ಲದೆ ಹೊರಟುಹೋಗುವ ಮಾರ್ಗವನ್ನು ಡೀಬಗ್ ಮಾಡುವಾಗ ಹೆಚ್ಚು ಮುಖ್ಯವಾಗುತ್ತದೆ.
ಟನೆಲ್ ಒಳಗೆ ಏನು ಹೋಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸುವ ಎರಡು ಮಾರ್ಗಗಳು
ನೀತಿ ಆಧಾರಿತ VPN ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳಿಗೆ ಹೊಂದುವ ಭದ್ರತಾ ನೀತಿಯನ್ನು ನಿರ್ಮಿಸಿ, ಹೊಂದಿಕೆಯಾಗುವುದನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ. ಸಹವರ್ತಿ ಹೊಂದಾಣಿಕೆಯ ಸೆಲೆಕ್ಟರ್ಗಳಿಗೆ ಮಾತುಕತೆ ನಡೆಸಬೇಕು, ಆದ್ದರಿಂದ ಪರಿಣಾಮಕಾರಿ ವ್ಯಾಪ್ತಿ ಕೊನೆಗೆ ಎರಡೂ ಬದಿಗಳು ಸೂಚಿಸಿದ್ದರ ಛೇದವಾಗುತ್ತದೆ. ಆ ಛೇದದ ಹೊರಗೆ ಯಾವುದೂ ರಕ್ಷಿಸಲ್ಪಡುವುದಿಲ್ಲ, ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಏನೇ ಹೇಳಲಿ.
ರೂಟ್ ಆಧಾರಿತ VPN ಟನೆಲ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುವ ಇಂಟರ್ಫೇಸ್ ರಚಿಸಿ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವು ಅದರೊಳಗೆ ಸಂಚಾರ ಕಳುಹಿಸಲು ಬಿಡುತ್ತದೆ. IKE ಡೀಮನ್ ಇನ್ನೂ ಸ್ಥಿತಿ ಮತ್ತು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ನ ನೀತಿಯನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ರೂಟ್ಗಳು ಎನ್ಕ್ರಿಪ್ಷನ್ ಬದಲಿಸಿವೆ ಎಂದು ನಿರ್ಧರಿಸುವಾಗ ಜನರು ಬಿಟ್ಟುಬಿಡುವ ವಿವರ ಇದೇ. ಎರಡೂ ವಿನ್ಯಾಸಗಳು IPsec ನಿಂದ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತವೆ; ಆಯ್ಕೆ ಕಾರ್ಯವಿಧಾನ ಮಾತ್ರ ಭಿನ್ನ.
ಕೆಳಗಿನ ಹೋಲಿಕೆಯನ್ನು ಸ್ಕೋರ್ಕಾರ್ಡ್ ಎಂದಲ್ಲ, ವೈಫಲ್ಯದ ಚಿಹ್ನೆಗಳ ಗುಂಪು ಎಂದು ಓದಿ, ಏಕೆಂದರೆ ಯಾವುದೇ ಕಾಲಮ್ ತಾನಾಗಿಯೇ ಗೆಲ್ಲುವುದಿಲ್ಲ.
| Aspect | Policy-based | Route-based |
|---|---|---|
| What selects traffic | Negotiated selectors | A route into the tunnel interface |
| Adding a network | Edit selectors on both peers | Add a route, widen the selector once |
| Dynamic routing | Awkward to run over the tunnel | Runs over the interface directly |
| Typical failure | Tunnel up, host outside the selector | Tunnel up, no route or wrong source |
ನೀತಿ ಆಧಾರಿತ: ಸೆಲೆಕ್ಟರ್ ಒಪ್ಪಂದ
ಸೆಲೆಕ್ಟರ್ಗಳಿಗೆ ಮಾತುಕತೆ ನಡೆಯುತ್ತದೆ, ಬರೀ ಸಂರಚನೆ ಮಾಡುವುದಿಲ್ಲ. ಒಂದು ಬದಿಯಲ್ಲಿ 10.10.0.0/16 ಮತ್ತು ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ 10.10.1.0/24 ಸೂಚಿಸಿ, ಆಗ ಸಂಘವು ಮಾತುಕತೆ ನಿಂತಿದ್ದನ್ನು ಆವರಿಸುತ್ತದೆ ಮತ್ತು ಉಳಿದ ಪ್ರತಿ ಹೋಸ್ಟ್ ಹೊರಗೆ ಉಳಿಯುತ್ತದೆ.
ಸಂರಚನಾ ಕಡತದ ಬದಲು ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಯನ್ನು ಓದಿ. Linux ಸಹವರ್ತಿಯಲ್ಲಿ ಕರ್ನಲ್ನ ಸ್ವಂತ ಕೋಷ್ಟಕಗಳೇ ಮೂಲ ಸತ್ಯ, ಮತ್ತು ಮಾತುಕತೆಯಿಂದ ಏನು ಉಳಿದಿದೆ ಎಂಬುದನ್ನು ಅವು ತೋರಿಸುತ್ತವೆ. ಸರಿಯಾದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಹೆಸರಿಸಿ ಹೊಂದುವ ಸ್ಥಿತಿ ಇಲ್ಲದ ನೀತಿ ಎಂದರೆ ಸಂಘ ಎಂದೂ ಎದ್ದಿಲ್ಲ. ತಪ್ಪು ಪೂರ್ವಪ್ರತ್ಯಯದ ನೀತಿಯೊಂದಿಗೆ ಜೋಡಿಯಾದ ಸ್ಥಿತಿ ವಿರುದ್ಧ ಸಮಸ್ಯೆ, ಮತ್ತು ಅದು ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುವ ಟನೆಲ್ ಸೃಷ್ಟಿಸುತ್ತದೆ ಆದರೆ ಒಂದು ಉಪಜಾಲ ಎಲ್ಲಿಗೂ ತಲುಪುವುದಿಲ್ಲ.
sudo ip xfrm state
sudo ip xfrm policy
sudo swanctl --list-sasನೀವು ರಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಂಬುವ ಪೂರ್ವಪ್ರತ್ಯಯಗಳೊಂದಿಗೆ ಎರಡೂ ಔಟ್ಪುಟ್ಗಳನ್ನು ಹೋಲಿಸಿ. ಆ ಒಂದೇ ಹೋಲಿಕೆ ಕೆಲಸ ಮಾಡುವ ಟನೆಲ್ ಮತ್ತು ತಲುಪಲಾಗದ ಸರ್ವರ್ ಬಗ್ಗೆ ಬಹುಪಾಲು ವರದಿಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಯಾವ ಸಹವರ್ತಿಯನ್ನು ಬದಲಿಸಬೇಕು ಎಂಬುದನ್ನೂ ಅದು ತೋರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಸಾಮರಸ್ಯ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಮಾತ್ರ ಕಾಣುತ್ತದೆ.
ರೂಟ್ ಆಧಾರಿತ: ಇಂಟರ್ಫೇಸ್ ಒಪ್ಪಂದ
XFRM ಇಂಟರ್ಫೇಸ್ ಟನೆಲ್ಗೆ ಹೆಸರು ಮತ್ತು ಗುರುತನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕ ಹಾಗೆ ಹೇಳುವುದರಿಂದ ಸಂಚಾರ ಅದನ್ನು ತಲುಪುತ್ತದೆ. ಹಲವು ದೂರದ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಆಗ ಸೆಲೆಕ್ಟರ್ ಸಮಸ್ಯೆಯ ಬದಲು ರೂಟಿಂಗ್ ಸಮಸ್ಯೆಯಾಗುತ್ತವೆ, ಮತ್ತು ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್ ಅವನ್ನು ಘೋಷಿಸಬಹುದು. ಅದೇ ನಿಜವಾದ ಲಾಭ, ಎನ್ಕ್ರಿಪ್ಷನ್ ಅಲ್ಲ.
ಇಂಟರ್ಫೇಸ್ ನೀತಿಯ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ಡೀಮನ್ ಇಂಟರ್ಫೇಸ್ ಗುರುತಿಗೆ ಬದ್ಧವಾದ ನಿಯಮಗಳನ್ನು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್ಗೆ ಸ್ಥಾಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ತಪ್ಪು ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುವ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ. ಸಹವರ್ತಿ ಸ್ವೀಕರಿಸದ ಮೂಲ ವಿಳಾಸವೂ ಪರಿಪೂರ್ಣ ರೂಟ್ ಇದ್ದರೂ ವಿಫಲವಾಗುತ್ತದೆ. ರೂಟ್ ಆಧಾರಿತ ಎಂದರೆ ಪ್ರವೇಶವನ್ನು ರೂಟ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ನೀತಿ ಮಾಯವಾಯಿತು ಎಂದಲ್ಲ.
sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip route add 10.20.0.0/16 dev xfrm0
ip -s link show xfrm0
ip route get 10.20.5.10ರೂಟ್ ಸ್ಥಾಪನೆಯಾದ ನಂತರ ಇಂಟರ್ಫೇಸ್ ಕೌಂಟರ್ಗಳನ್ನು ಗಮನಿಸಿ. ರೂಟ್ ಇದೆ ಆದರೆ ಕೌಂಟರ್ಗಳು ಶೂನ್ಯದಲ್ಲೇ ಉಳಿದರೆ ಟನೆಲ್ಗೆ ಏನೂ ಹೊಂದಿಸಲ್ಪಡುತ್ತಿಲ್ಲ ಎಂದರ್ಥ, ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣೆಯಾದ ರೂಟ್ಗಿಂತ ಕಾಣೆಯಾದ ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಎರಡು ವಿನ್ಯಾಸಗಳು ನಿಜವಾಗಿ ಎಲ್ಲಿ ಬೇರ್ಪಡುತ್ತವೆ
ನೆಟ್ವರ್ಕ್ ಸೇರಿಸುವುದು ಯಾವ ಮಾದರಿ ನಿಮಗೆ ಸರಿಹೊಂದುತ್ತದೆ ಎಂಬುದರ ಅತ್ಯಂತ ಸ್ವಚ್ಛ ಪರೀಕ್ಷೆ. ರೂಟ್ ಆಧಾರಿತ ವಿನ್ಯಾಸ ಒಂದು ರೂಟ್ ಸೇರಿಸಿ ಹೆಚ್ಚೆಂದರೆ ಒಮ್ಮೆ ಸೆಲೆಕ್ಟರ್ ಅಗಲಿಸುತ್ತದೆ, ಆದರೆ ನೀತಿ ಆಧಾರಿತ ವಿನ್ಯಾಸ ಎರಡೂ ಸಹವರ್ತಿಗಳಲ್ಲಿ ಪೂರ್ವಪ್ರತ್ಯಯ ಜೋಡಿಗಳನ್ನು ಸಂಪಾದಿಸಿ ಮತ್ತೆ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ. ಎರಡು ಸ್ಥಿರ ಉಪಜಾಲಗಳು ಆ ಸಂಪಾದನೆಯನ್ನು ಕ್ಷುಲ್ಲಕ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಇಪ್ಪತ್ತು ಅದನ್ನು ಯೋಜನೆಯಾಗಿಸುತ್ತವೆ.
ಯಾವುದೇ ಮಾದರಿ ಫೈರ್ವಾಲ್ ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಹೋಲಿಕೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಈ ಹಂತದ ಮೊದಲೇ ನಿಲ್ಲುತ್ತವೆ. ಅಗಲವಾದ ಸೆಲೆಕ್ಟರ್ ಅಥವಾ ಅಗಲವಾದ ರೂಟ್ ಏನು ಎನ್ಕ್ರಿಪ್ಟ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಏನು ಅನುಮತಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನಲ್ಲ.
MTU ವರ್ತನೆಯೂ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಭಿನ್ನ. ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಉಪಯುಕ್ತ ಪೇಲೋಡ್ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಮತ್ತು ರೂಟ್ ಆಧಾರಿತ ಇಂಟರ್ಫೇಸ್ ತನ್ನದೇ MTU ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡೂ ಗೇಟ್ವೇಗಳಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪ್ ಮಾಡುವುದು ಸಣ್ಣ ಪ್ರತ್ಯುತ್ತರಗಳು ಬಂದು ದೊಡ್ಡವು ಕಣ್ಮರೆಯಾಗುವ ಕಪ್ಪು ಕುಳಿ ಲಕ್ಷಣವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ನೀತಿ ಆಧಾರಿತ ಟನೆಲ್ಗಳು ಇನ್ನೊಂದು ಬದಿಯಿಂದ ಅದೇ ಗೋಡೆಯನ್ನು ಎದುರಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಸೆಲೆಕ್ಟರ್ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಸಹವರ್ತಿಯನ್ನು ದೂಷಿಸುವ ಬದಲು ಕ್ಲ್ಯಾಂಪ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಹೊಂದಿಸಿ.
ಹಿಂತಿರುಗುವ ದಾರಿ ಕಳೆದುಕೊಳ್ಳದೆ ವಲಸೆ
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಇರುವ ಪೂರ್ವಪ್ರತ್ಯಯ ಜೋಡಿಗಳನ್ನು ದಾಖಲಿಸಿ, ನಂತರ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಮಾರ್ಗವನ್ನು ಸರಿಸಿ ಅದನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ಗಮನಿಸಿ. ಸ್ಥಾಪನೆಯಾಗುವ ಟನೆಲ್ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಟನೆಲ್ ಅಲ್ಲ, ಮತ್ತು ವ್ಯತ್ಯಾಸವು ಪ್ರತ್ಯುತ್ತರದ ದಿಕ್ಕಿನಲ್ಲಿ ಕಾಣುತ್ತದೆ.
ಸಹವರ್ತಿಗಳು ಸಂಪರ್ಕಗೊಂಡರೂ LAN ಹೋಸ್ಟ್ಗಳು ಸಂಪರ್ಕಗೊಳ್ಳದಿದ್ದರೆ, ಹಿಂತಿರುಗುವ ರೂಟ್ ಮತ್ತು ದೂರದ ಹೋಸ್ಟ್ ಬಳಸುವ ಮೂಲ ವಿಳಾಸವನ್ನು ಪರಿಶೀಲಿಸಿ. ಎರಡು ಇಂಟರ್ಫೇಸ್ ಇರುವ ಹೋಸ್ಟ್ ತಪ್ಪಾದದರಿಂದ ಪ್ರತ್ಯುತ್ತರಿಸಬಹುದು, ಮತ್ತು ಯಾವುದೇ ಸೆಲೆಕ್ಟರ್ ಬದಲಾವಣೆ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಸಂಚಾರವನ್ನು ಸೆರೆಹಿಡಿಯಿರಿ.
ip route get 10.20.5.10
sudo tcpdump -ni any host 10.20.5.10 and icmp
sudo swanctl --list-connsಕೆಲಸ ಮಾಡುವಾಗ ಟನೆಲ್ ಅನ್ನು ಅವಲಂಬಿಸದ ನಿರ್ವಹಣಾ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ. ನೀವು ಡೀಬಗ್ ಮಾಡುತ್ತಿರುವ ಸಂಪರ್ಕದ ಮೇಲೆ ಗೇಟ್ವೇಯ ಸ್ವಂತ ಪ್ರವೇಶ ಸಾಗದಿದ್ದರೆ ಹಿಂತಿರುಗಿಸುವುದು ಸುಲಭ.