ನಿಗದಿಪಡಿಸಿದ ವರ್ಚುವಲ್ IP ಯಲ್ಲಿ IKEv2 ಕ್ಲೈಂಟ್‌ಗೆ ತಲುಪುವುದು

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

ಸುರಂಗ ಮೂಲ ವಿಳಾಸವನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ

CHILD SA ಟ್ರಾಫಿಕ್ ಆಯ್ಕೆಗಾರರ ಒಂದು ಜೋಡಿಯನ್ನು ಒಳಗೊಂಡಿದೆ, ಪ್ರತಿ ಬದಿಗೂ ಒಂದು, ಮತ್ತು ಆ ಜೋಡಿಯ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಯಾವ ಪೀರ್ IKE ವಿನಿಮಯವನ್ನು ಮೊದಲು ತೆರೆಯಿತು ಎಂಬುದರ ಬಗ್ಗೆ ಅದು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಮೊದಲು ಸುರಂಗಕ್ಕೆ ಕೇಳಿಸಿಕೊಳ್ಳುತ್ತಿದ್ದ ಗೇಟ್‌ವೇ ಈಗಲೂ ಮೊದಲ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು, ಆಯ್ಕೆ ಮಾಡಿದ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವು ಸ್ಥಾಪಿಸಿದ ಆಯ್ಕೆಗಾರರ ಒಳಗೆ ಬಿದ್ದರೆ. ವಿನಂತಿ ತಪ್ಪು ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಹೊರಟಾಗ, ಅದು ಸುರಂಗಕ್ಕೆ ಅರ್ಹವಲ್ಲ.

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

ಸ್ಥಾಪಿಸಿದ ನೀತಿಯನ್ನು ಓದಿ, ಕಾನ್ಫಿಗ್ ಫೈಲ್ ಅಲ್ಲ

ಸಕ್ರಿಯ ಸಂಘ ಮತ್ತು ಅದರ ಆಯ್ಕೆಗಾರರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಕ್ರಿಯಾತ್ಮಕ ಹಂಚಿಕೆ ಕರ್ನಲ್‌ನಲ್ಲಿ ಸ್ಥಾಪಿಸಿದ್ದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.

ipsec statusall
ip xfrm policy

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

ಕ್ಲೈಂಟ್ ಪ್ಯಾಕೆಟ್ ಬರುವಲ್ಲಿಯೇ ಕೇಳಿಸಿಕೊಳ್ಳಬೇಕು

ಸೇವೆ ಕೇವಲ ಲೂಪ್‌ಬ್ಯಾಕ್‌ಗೆ ಬದ್ಧವಾಗಿದ್ದಾಗ ಪರಿಪೂರ್ಣ ನೀತಿಯೂ ಮುಚ್ಚಿದ ಪೋರ್ಟ್‌ಗೆ ತಲುಪುತ್ತದೆ. ಆಲಿಸುವವರು ನಿಗದಿಪಡಿಸಿದ ವಿಳಾಸದಲ್ಲೋ ಅಥವಾ ಸ್ಥಳೀಯ ವೈಲ್ಡ್‌ಕಾರ್ಡ್ ವಿಳಾಸದಲ್ಲೋ ಇರಬೇಕು.

ss -ltnp 'sport = :9090'
iptables -S INPUT

ಸಾಕೆಟ್ ಪಟ್ಟಿ ಪೋರ್ಟ್ ವರ್ಚುವಲ್ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಸಂರಕ್ಷಿತ ಮೂಲದಿಂದ ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತವೆ. ಸ್ಥಾಪಿತ ಸಂಪರ್ಕಗಳಿಗಾಗಿ ಬರೆದ ನಿಯಮ ಗೇಟ್‌ವೇ ಪ್ರಾರಂಭಿಸುವ ಸಂಪರ್ಕವನ್ನು ಒಪ್ಪುವುದಿಲ್ಲ. ಸೇವೆಯ ಸ್ವಂತ ದೃಢೀಕರಣವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಸುರಂಗದ ಮೂಲಕ ಬರುವುದು ಪ್ಯಾಕೆಟ್ ಯಾವ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಬಂತು ಎಂಬುದನ್ನು ಮಾತ್ರ ಸ್ಥಾಪಿಸುತ್ತದೆ. ತನ್ನದೇ NAT ಹಿಂದಿನ ಕ್ಲೈಂಟ್‌ಗೆ ಇನ್ನೂ ಒಳಬರುವ ಪೋರ್ಟ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಅಗತ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಈ ವಿನಂತಿಗಳು ಇರುವ ಸುರಂಗದ ಒಳಗೆ ಸಂಚರಿಸುತ್ತವೆ.

ಹೊಸ ದಿಕ್ಕನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

ಕ್ಲೈಂಟ್‌ನಿಂದ ಸರ್ವರ್‌ಗೆ ಯಶಸ್ವಿ ವಿನಂತಿ ಈ ಮಾರ್ಗವನ್ನು ಎಂದಿಗೂ ಅಭ್ಯಾಸ ಮಾಡುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇಯಿಂದ ವಿನಂತಿ ರಚಿಸಿ ಎರಡೂ ತುದಿಗಳನ್ನು ಗಮನಿಸಿ.

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

ಕೀ ಬದಲಾವಣೆ ಅಥವಾ ಮರುಸಂಪರ್ಕದ ನಂತರ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ VIP ಬದಲಾಗಬಹುದು. ಮುಂದಿನ ಅಧಿವೇಶನದವರೆಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವಲ್ಲ.