OpenVPN ಕ್ಲೈಂಟ್‌ಗಳು ಗೇಟ್‌ವೇಯ IPsec ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಏಕೆ ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತವೆ

ಗೇಟ್‌ವೇಯಿಂದ ದೂರದ IPsec ಸುರಂಗದ ಹಿಂದಿನ ಹೋಸ್ಟ್‌ಗೆ ping ಮಾಡಿ ಮತ್ತು ಅದು ಸ್ವಚ್ಛವಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುರಂಗ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಟಿಕೆಟ್ ಮುಂದೆ ಸಾಗುತ್ತದೆ. ನಂತರ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಅದೇ ಹೋಸ್ಟ್ ಅನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಮತ್ತು ಏನೂ ಹಿಂತಿರುಗಿ ಸಿಗುವುದಿಲ್ಲ. ಆ ping ಎಂದಿಗೂ ಕ್ಲೈಂಟ್‌ನ ಹರಿವಿಗೆ ಸಾಕ್ಷಿಯಾಗಿರಲಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಗೇಟ್‌ವೇಯ ಸ್ವಂತ ಮೂಲ ವಿಳಾಸದೊಂದಿಗೆ ಹೊರಟಿತು ಮತ್ತು ಬೇರೆ IPsec ಸೆಲೆಕ್ಟರ್‌ಗೆ ಹೊಂದಿಕೆಯಾಯಿತು. ಎರಡು ಸಂದರ್ಭಗಳು ಏಕೆ ಭಿನ್ನವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದೇ ಪರಿಹಾರದ ದೊಡ್ಡ ಭಾಗ.

ಗೇಟ್‌ವೇಯ ping ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ಬಳಸದ ಹರಿವನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ

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

ಆದ್ದರಿಂದ ವೈಫಲ್ಯವು ಮಾರ್ಗನಿರ್ದೇಶನ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ, ವಾಸ್ತವದಲ್ಲಿ ಅದು ನೀತಿಯ ವ್ಯಾಪ್ತಿಯ ಸಮಸ್ಯೆ. ಗೇಟ್‌ವೇಯಿಂದ ತಲುಪುವಿಕೆ ಪೀರ್ ಸಕ್ರಿಯವಾಗಿದೆ ಮತ್ತು ಪ್ರಸ್ತಾವನೆಗಳು ಮಾತುಕತೆಯಾಗಿವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಪೂಲ್ ಸಂರಕ್ಷಿತವಾಗಿದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಿಜವಾಗಿ ಬೇಕಾದ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಪುಶ್ ಮಾಡಿ

ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ 10.8.0.0/24 ಮತ್ತು ಸಂರಕ್ಷಿತ ದೂರದ ನೆಟ್‌ವರ್ಕ್‌ಗೆ 172.30.239.0/25 ಎಂಬ ಉದಾಹರಣೆ ಜೋಡಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ. ಕ್ಲೈಂಟ್‌ಗೆ ಬೇಕಾಗಿರುವುದು ಆ ಎರಡನೇ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಮಾರ್ಗ, ಗೇಟ್‌ವೇಯ LAN ಅಲ್ಲ ಮತ್ತು ಬೇರೆ ಸುರಂಗ ವಿಳಾಸವೂ ಅಲ್ಲ. ಪೂಲ್‌ಗೆ ಪುಶ್ ಮಾಡಿದ ಮಾರ್ಗವೇ ಕ್ಲೈಂಟ್ ಆ ಸಂಚಾರವನ್ನು ಗೇಟ್‌ವೇಗೆ ಒಪ್ಪಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಅದಿಲ್ಲದೆ ಪ್ಯಾಕೆಟ್ ನೀವು ಡೀಬಗ್ ಮಾಡುತ್ತಿರುವ ನೀತಿ ನಿರ್ಣಯವನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.

ಪುಶ್ ಮಾಡಿದ ಮಾರ್ಗಗಳನ್ನು ಸ್ವೀಕರಿಸುವ Community ಸರ್ವರ್‌ನಲ್ಲಿ, ಸೂಚನೆ ನಿಜವಾದ ಮಾಸ್ಕ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: push "route 172.30.239.0 255.255.255.128". Access Server ಅದೇ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಾಪಿಸಿದ ಆವೃತ್ತಿಯ ಖಾಸಗಿ-ನೆಟ್‌ವರ್ಕ್ ಅಥವಾ ಪ್ರವೇಶ-ನಿಯಮ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಮೂಲಕ ಸಂರಚಿಸುತ್ತದೆ, ಮತ್ತು ರೂಟೆಡ್ ಅಥವಾ ಅನುವಾದಿತ ಮೋಡ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ. ಮಾಲೀಕರ ಸಂರಚನೆಯ ಬದಲು ಉತ್ಪಾದಿತ ಫೈರ್‌ವಾಲ್ ಸರಣಿಗಳನ್ನು ಸಂಪಾದಿಸುವುದೇ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸೆಟಪ್ ಮರುಉತ್ಪಾದಿಸಲು ಅಸಾಧ್ಯವಾಗುವ ದಾರಿ.

ಸಂಪರ್ಕಿಸಿದ ನಂತರ ಸರ್ವರ್‌ನ ಉದ್ದೇಶವಲ್ಲ, ಕ್ಲೈಂಟ್‌ನ ಮಾರ್ಗನಿರ್ದೇಶನ ಕೋಷ್ಟಕವನ್ನು ಓದಿ. ಕೇವಲ ಪೂಲ್ ಅನ್ನು ಆವರಿಸುವ ಮಾರ್ಗ ಎಂದರೆ ಪುಶ್ ಎಂದಿಗೂ ತಲುಪಲಿಲ್ಲ, ಮತ್ತು ಸುರಂಗದ ಮೂಲಕ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಈ ಅಗತ್ಯಕ್ಕಿಂತ ವಿಶಾಲವಾಗಿದೆ ಮತ್ತು ನಂತರ ನಿಮ್ಮನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುತ್ತದೆ. ಮಾಸ್ಕ್ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ /25 ಅನ್ನು /24 ಆಗಿ ಪುಶ್ ಮಾಡಿದರೆ ನೆರೆಯ ವಿಳಾಸಗಳ ಸಂಚಾರವು ಅದನ್ನು ಹೊತ್ತೊಯ್ಯಲಾಗದ ಮಾರ್ಗಕ್ಕೆ ಹೋಗುತ್ತದೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಆ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್ ಆಯ್ಕೆ ಮಾಡಿದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಸೆಲೆಕ್ಟರ್‌ಗಳು ಕ್ಲೈಂಟ್ ಪೂಲ್ ಅನ್ನು ಒಳಗೊಳ್ಳುವಂತೆ ಮಾಡಿ

ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ರೂಟೆಡ್ ಪ್ರವೇಶಕ್ಕೆ, IPsec ನೀತಿಯು ಪೂಲ್ ಮತ್ತು ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ ನಡುವಿನ ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸಬೇಕು. ಗೇಟ್‌ವೇಯ ಸ್ವಂತ LAN‌ಗಾಗಿ ಬರೆದ ಸೆಲೆಕ್ಟರ್‌ಗಳು ping ಗೆ ಅವಕಾಶ ನೀಡಿ ಕ್ಲೈಂಟ್‌ನ ವಿನಂತಿಯನ್ನು ಬಿಡುತ್ತವೆ, ಮತ್ತು ಇದೇ ಈ ತನಿಖೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ ಅಸಮಮಿತಿ.

ಸಂರಚಿತ ಪ್ರಸ್ತಾವನೆಗಳ ಜೊತೆಗೆ ಮಾತುಕತೆಯಾದ ನೀತಿಯನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಉದಾಹರಣೆಗೆ strongSwan ನಲ್ಲಿ ipsec statusall ಅಥವಾ ನಿಮ್ಮ ಅನುಷ್ಠಾನಕ್ಕೆ ಸಮಾನವಾದ ಸ್ಥಿತಿ ಆಜ್ಞೆಯಿಂದ. ನೀತಿ-ಆಧಾರಿತ IPsec ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಮಾರ್ಗವು ಭೌತಿಕ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ತೋರಿಸಬಹುದು ಆದರೆ ಹೊಂದುವ ಸಂಚಾರ ಇನ್ನೂ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುರಂಗ ಸಾಧನ ಇಲ್ಲದಿರುವುದು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸೆಲೆಕ್ಟರ್ ಜೋಡಿಗಳನ್ನು ನೀವು ಬರೆದಿಟ್ಟ ಪೂಲ್ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಗೇಟ್‌ವೇಯಲ್ಲಿನ ಸಾಮಾನ್ಯ ಮೂಲ NAT ಕೂಡ ಹೊಂದಿಕೆಯನ್ನು ಮುರಿಯಬಹುದು. ನೀತಿ ಪರಿಶೀಲನೆಗೆ ಮೊದಲು masquerade ನಿಯಮವು ಕ್ಲೈಂಟ್‌ನ ಮೂಲವನ್ನು ಮರುಬರೆದರೆ, ಪ್ಯಾಕೆಟ್ ಇನ್ನು ನೀವು ಬರೆದ ಸೆಲೆಕ್ಟರ್‌ನಂತೆ ಕಾಣುವುದಿಲ್ಲ. ಅಗಲವಾದ masquerade ನಿಯಮವು ಎರಡನೇ VPN ಗೆ ಕೆಟ್ಟ ಪರಿಹಾರವಾಗುವ ಒಂದು ಕಾರಣ ಇದು: ಯಾವ ನೀತಿ ಅನ್ವಯವಾಗುತ್ತದೆ ಮತ್ತು ದೂರದ ಬದಿ ಯಾವ ವಿಳಾಸವನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅದು ಬದಲಿಸುತ್ತದೆ. ನೀವು ಮಾರ್ಗನಿರ್ದೇಶಿಸಲು ಉದ್ದೇಶಿಸಿರುವ ಸಂಚಾರವನ್ನು ಹೊರತುಪಡಿಸಿ, ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಅನುವಾದಿಸಿ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ನವೀಕರಿಸಿ.

ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾರ್ಗನಿರ್ದೇಶನ ಅಥವಾ ಅನುವಾದ ಆಯ್ಕೆ ಮಾಡಿ

ಮಾರ್ಗನಿರ್ದೇಶನವು ಕ್ಲೈಂಟ್ ವಿಳಾಸವನ್ನು ದೂರದ ಬದಿಗೆ ಗೋಚರವಾಗಿ ಇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದೂರದ ಲಾಗ್‌ಗಳು ಮತ್ತು ಪ್ರತಿ-ಮೂಲ ನಿಯಮಗಳು ಅರ್ಥಪೂರ್ಣವಾಗಿ ಉಳಿಯುತ್ತವೆ, ಮತ್ತು ದೂರದ ಗೇಟ್‌ವೇ ಪೂಲ್‌ಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ತಿಳಿದಿರಬೇಕು ಎಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ. ಅನುವಾದವು ಪೂಲ್ ಅನ್ನು ಒಂದು ವಿಳಾಸದ ಹಿಂದೆ ಮರೆಮಾಡುತ್ತದೆ, ಇದು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆದುಹಾಕಿ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಗುರುತನ್ನು ನಾಶಮಾಡುತ್ತದೆ.

ಒಂದು ವಿನ್ಯಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಬರೆದಿಡಿ, ಏಕೆಂದರೆ ಎರಡಕ್ಕೂ ಬೇರೆ ಸೆಲೆಕ್ಟರ್‌ಗಳು ಮತ್ತು ಬೇರೆ ಫೈರ್‌ವಾಲ್ ಕ್ರಮ ಬೇಕು. ಅರ್ಧ ಅನ್ವಯಿಸಿದ masquerade ಅವುಗಳ ನಡುವೆ ಬೀಳುತ್ತದೆ ಮತ್ತು ಯಾವುದನ್ನೂ ತೃಪ್ತಿಪಡಿಸುವುದಿಲ್ಲ. ಬರೆದ ಆಯ್ಕೆಯೇ ಮುಂದಿನ ಎಂಜಿನಿಯರ್‌ಗೆ ದೋಷ ಮತ್ತು ಉದ್ದೇಶಿತ ನಿರ್ಣಯವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ.

ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ಉತ್ತರದಲ್ಲಿ ಲೂಪ್ ಮುಚ್ಚಿ

ಗೇಟ್‌ವೇ ನೀವು ಉದ್ದೇಶಿಸಿದ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು, ಅಂದರೆ IP ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯವಾಗಿರಬೇಕು ಮತ್ತು ಜೋಡಿಗೆ ಅನುಮತಿ ನೀಡುವ ಫಾರ್ವರ್ಡ್ ಸರಣಿ ಇರಬೇಕು. ನಂತರ ದೂರದ ಬದಿ ಉತ್ತರಗಳನ್ನು IPsec ಮಾರ್ಗದ ಮೂಲಕ ಹಿಂತಿರುಗಿಸಬೇಕು, ಮತ್ತು ಅದು ಅವರ ಗೇಟ್‌ವೇಯಲ್ಲಿ ನಿಮ್ಮದಲ್ಲ, ಮಾರ್ಗನಿರ್ದೇಶನ ನಿರ್ಣಯ. ಎರಡೂ ಅರ್ಧ ಭಾಗಗಳು ಸಾಮಾನ್ಯ ಸಂರಚನೆ, ಮತ್ತು ಎರಡನ್ನೂ ಅರ್ಧ ಮುಗಿಸದೆ ಬಿಡುವುದು ಸುಲಭ. ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಕಾಣೆಯಾದ ಫಾರ್ವರ್ಡ್ ನಿಯಮವನ್ನು ಮುರಿದ ಸುರಂಗ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸದಂತೆ.

ಒಂದು ನಿಜವಾದ ಕ್ಲೈಂಟ್-ಇಂದ-ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯಿಂದ ಪರಿಶೀಲಿಸಿ, ಅದು OpenVPN ಇಂಟರ್‌ಫೇಸ್, IPsec ನಿರ್ಣಯ ಮತ್ತು ದೂರದ ಹೋಸ್ಟ್ ಅನ್ನು ದಾಟುವುದನ್ನು ಗಮನಿಸಿ. ಉತ್ತರವನ್ನು ಪ್ರತ್ಯೇಕ ವೀಕ್ಷಣೆಯಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ತಲುಪುವ ವಿನಂತಿ ಮತ್ತು ಎಂದಿಗೂ ಹಿಂತಿರುಗದ ಉತ್ತರ ಕ್ಲೈಂಟ್‌ನ ಸ್ಥಾನದಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ. ಒಂದು ಟ್ರೇಸ್ ಮಾಡಿದ ವಿನಂತಿ ಎಷ್ಟೇ ಗೇಟ್‌ವೇ ping ಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯದ್ದು.

ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಗಮ್ಯಸ್ಥಾನದ ಅಧಿಕಾರವನ್ನು ಸಂಕುಚಿತವಾಗಿ ಇರಿಸಿ, ಮತ್ತು ನಿಯಮವಿಲ್ಲದ ಕ್ಲೈಂಟ್ ಸೇವೆಯನ್ನು ತಲುಪಲಾರದು ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸ್ಥಾಪಿತ ಮಾರ್ಗ ಮತ್ತು ಸ್ಥಾಪಿತ ಸಂಯೋಜನೆ ನೀಡಿದ ಪ್ರವೇಶಕ್ಕೆ ಸಮಾನವಲ್ಲ.