ಒಂದೇ Linux ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಎರಡು OpenVPN ಸುರಂಗಗಳು: ಮಾರ್ಗ ಯಾರದ್ದು?
ಪೂಲ್‌ಗಳು, ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳು ಮತ್ತು ಡೀಫಾಲ್ಟ್ ಕ್ಲೈಮ್‌ಗಳನ್ನು ನಿಗದಿಪಡಿಸಿದ ನಂತರ ಎರಡು ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್‌ಗಳು ಒಟ್ಟಿಗೆ ಇರಬಹುದು. ಮೊದಲು ಮಾಲೀಕತ್ವವನ್ನು ನಿರ್ಧರಿಸಿ, ನಂತರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗಕ್ಕೆ ಗುರುತುಗಳನ್ನು ಬಳಸಿ.
ಎರಡು ಪ್ರೊಫೈಲ್‌ಗಳು ಸಂಪರ್ಕಗೊಂಡಿವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಇನ್ನೊಂದಕ್ಕೆ ಉದ್ದೇಶಿಸಿದ ಸಂಚಾರವನ್ನು ಸದ್ದಿಲ್ಲದೆ ಸಾಗಿಸುತ್ತಿದೆ. Linux ಹೋಸ್ಟ್ ಎರಡೂ OpenVPN ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಯಾವುದೇ ಕಷ್ಟವಿಲ್ಲದೆ ಚಲಾಯಿಸಬಹುದು. ಅದು ಮಾಡಲಾಗದಿರುವುದು ಯಾವ ಪ್ರಕ್ರಿಯೆ ಯಾವ ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಕ್ಲೈಮ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿಮ್ಮ ಬದಲಿಗೆ ನಿರ್ಧರಿಸುವುದು. ಆ ನಿರ್ಧಾರವನ್ನು ಎರಡನೇ ಸುರಂಗ ಏರುವ ಮೊದಲೇ ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಯಾವುದೋ ಸಂಪನ್ಮೂಲ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ನಂತರವಲ್ಲ.
ಎರಡನೇ ಲಿಂಕ್ ಮಾಡಬೇಕಾದ ಕೆಲಸದಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಒಂದು ಪ್ರೊಫೈಲ್ ಮೂಲಕ ತಲುಪಬಹುದಾದ ಕಚೇರಿ ಮತ್ತು ಇನ್ನೊಂದರ ಮೂಲಕ ತಲುಪಬಹುದಾದ ಪ್ರಯೋಗಾಲಯಕ್ಕೆ ಎರಡೂ ಸುರಂಗಗಳು ಏರಿರಬೇಕು ಮತ್ತು ಯಾವುದೂ ಎಲ್ಲವನ್ನೂ ಕ್ಲೈಮ್ ಮಾಡಬಾರದು. ಎರಡನೇ ಪ್ರೊಫೈಲ್ ಮೂಲಕ ಹೊರಬರಬೇಕಾದ ಒಂದು ಹಠಮಾರಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಎರಡನೇ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಬದಲಿಗೆ ನೀತಿ ನಿಯಮ ಬೇಕು. ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಲಿಂಕ್‌ಗೆ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಒಂದೇ ಸುರಂಗ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ ಸಾಕು, ಆದ್ದರಿಂದ ಬಿಡಿ ಮೆಷಿನ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗಬಾರದು.
ಇವು ಮೂರು ವಿಭಿನ್ನ ಸಂರಚನೆಗಳು, ಮತ್ತು ಅವು ಗೊಂದಲಕ್ಕೀಡಾಗುತ್ತವೆ ಏಕೆಂದರೆ ಮೂರೂ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ: ಎರಡನೇ ಪ್ರೊಫೈಲ್ ಮತ್ತು ಯಶಸ್ವಿ ಸಂಪರ್ಕ. ಮೊದಲು ಉದ್ದೇಶಿಸಿದ ಜೋಡಣೆಯನ್ನು ಬರೆಯಿರಿ, ನಂತರ ಅದರ ಕಡೆಗೆ ಸಂರಚಿಸಿ. ಉದ್ದೇಶದ ಒಂದು ವಾಕ್ಯವು ಒಂದು ಗಂಟೆಯ ಪ್ಯಾಕೆಟ್ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಉಳಿಸುತ್ತದೆ.
systemctl list-units --type=service 'openvpn-client@*' ip -4 route show default
ಮೊದಲ ಆಜ್ಞೆ ಚಾಲನೆಯಲ್ಲಿರುವ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮ್ಯಾನೇಜರ್‌ನ ಹೊರಗೆ ಕೈಯಿಂದ ಪ್ರಾರಂಭಿಸಿದವುಗಳೂ ಸೇರಿ. ಎರಡನೆಯದು ಪ್ರಸ್ತುತ ಡೀಫಾಲ್ಟ್ ಕ್ಲೈಮ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ನೀವು ನಂತರ ವಿವರಿಸಬೇಕಾದ ಸ್ಥಿತಿ.
ಅತಿಪಾತವಾಗುವ ಪೂಲ್‌ಗಳು ಮಾರ್ಗದರ್ಶನಕ್ಕಿಂತ ಮೊದಲೇ ಒಡೆಯುತ್ತವೆ
ಎರಡು ಸರ್ವರ್‌ಗಳು ಅದೇ 10.8.0.0/24 ರಿಂದ ವಿಳಾಸಗಳನ್ನು ಸಂತೋಷದಿಂದ ಹಂಚುತ್ತವೆ. ನಂತರ ಕ್ಲೈಂಟ್ ಒಂದೇ ಪ್ರಿಫಿಕ್ಸ್ ಒಳಗೆ ಎರಡು ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವ ಗಮ್ಯಸ್ಥಾನ ಯಾವುದಕ್ಕೆ ಸೇರಿದೆ ಎಂದು ಹೇಳುವ ಯಾವುದೂ ಇರುವುದಿಲ್ಲ, ಮತ್ತು ಅದರಿಂದ ಉಂಟಾಗುವ ವರ್ತನೆ ಮಾರ್ಗದರ್ಶನ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ ಆದರೆ ವಾಸ್ತವವಾಗಿ ಅದು ಸಂಖ್ಯಾ ಕ್ರಮದ ದೋಷ. ಪೂಲ್ ಅನ್ನು ಮರುಸಂಖ್ಯೆ ಮಾಡಲು ಒಂದು ಸಂರಚನಾ ಸಂಪಾದನೆ ಬೇಕು; ನಂತರದ ಪ್ರತಿ ಮಾರ್ಗದರ್ಶನ ಉಪಾಯವೂ ಒಂದು ವಾರಾಂತ್ಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅದಕ್ಕೆ ಮಾರ್ಗ ಸೇರಿಸುವ ಮೊದಲು ಪೂಲ್ ಪರಿಶೀಲಿಸಿ.
ಸ್ಥಳೀಯ LAN ಅನ್ನೂ ನೋಡಿ. ಒಂದು ಸುರಂಗ ಬಹಿರಂಗಪಡಿಸುವ 192.168.1.0/24 ಸಂಖ್ಯೆಯ ಮನೆ LAN ಸಹ ಅದೇ ಅಸ್ಪಷ್ಟತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಮತ್ತು ರೋಗಲಕ್ಷಣವೆಂದರೆ ಸಂಪರ್ಕ ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದೆ ಪರಿಹರಿಸಲ್ಪಡುವ ಹೋಸ್ಟ್‌ಹೆಸರು. ಮಾರ್ಗಗಳನ್ನು ಮುದ್ರಿಸುವವರೆಗೂ ಅದು ಹೆಸರು ಪರಿಹಾರ ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.
ip -4 addr show ip route show table all | grep -E '10\.|192\.168\.'
ಕ್ಲೈಂಟ್ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡೂ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಎರಡು ಸರ್ವರ್ ಸಂರಚನೆಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಪ್ರಿಫಿಕ್ಸ್‌ಗಳು ಒಂದರ ಮೇಲೊಂದು ಬಿದ್ದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಮರುಸಂಖ್ಯೆ ಮಾಡಿ, ಏಕೆಂದರೆ ಎಷ್ಟು ಬಾರಿ ಮರುಪ್ರಾರಂಭಿಸಿದರೂ ಅವು ಬೇರ್ಪಡುವುದಿಲ್ಲ.
ಪ್ರತಿ ಪ್ರೊಫೈಲ್‌ಗೆ ಅದರದೇ ಯುನಿಟ್ ಮತ್ತು ಪ್ರತಿ ಪ್ರಿಫಿಕ್ಸ್‌ಗೆ ಮಾಲೀಕನನ್ನು ನೀಡಿ
ಪ್ರತಿ ಪ್ರೊಫೈಲ್ ತನ್ನದೇ ಇನ್‌ಸ್ಟಾನ್ಸ್ ಹೆಸರು ಮತ್ತು ತನ್ನದೇ ಸಂರಚನಾ ಫೈಲ್ ಪಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ office ಎಂಬ ಇನ್‌ಸ್ಟಾನ್ಸ್ office.conf ಲೋಡ್ ಮಾಡುತ್ತದೆ, lab ಎಂಬುದು lab.conf ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಡೈರೆಕ್ಟರಿ ಪಟ್ಟಿಯನ್ನು ನಂಬುವ ಬದಲು ಸೇವಾ ಮ್ಯಾನೇಜರ್ ಮೂಲಕ ಆ ಮ್ಯಾಪಿಂಗ್ ದೃಢೀಕರಿಸಿ, ಏಕೆಂದರೆ drop-in ಯಾವ ಫೈಲ್ ಲೋಡ್ ಆಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಬಹುದು. ಮ್ಯಾಪಿಂಗ್ ತಪ್ಪಾದರೆ ನೀವು ಚಾಲನೆಯಲ್ಲಿಲ್ಲದ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡುತ್ತಿದ್ದೀರಿ.
ನಂತರ ಮಾರ್ಗಗಳನ್ನು ಯಾರು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಾರೆ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸರ್ವರ್‌ಗಳು ಹೊಂದಿಕೆಯಾಗದ ಸೆಟ್‌ಗಳನ್ನು ತಳ್ಳಿದಾಗ, ಒಂದೋ ತಳ್ಳುವಿಕೆಯನ್ನು ನಿರಾಕರಿಸಿ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ನೀವೇ ಪಟ್ಟಿ ಮಾಡಿ, ಅಥವಾ ಒಂದು ಪ್ರೊಫೈಲ್ ಡೀಫಾಲ್ಟ್ ಉಳಿಸಿಕೊಳ್ಳಲು ಬಿಟ್ಟು ಇನ್ನೊಂದನ್ನು ನೀತಿ ನಿಯಮಗಳಿಂದ ನಿರ್ದೇಶಿಸಿ. ಎರಡೂ ಡೀಫಾಲ್ಟ್ ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುವ ಎರಡು ಪ್ರಕ್ರಿಯೆಗಳು ಮೌನ ವಿಜೇತ ಮತ್ತು ನಿರ್ಧಾರದ ಲಿಖಿತ ದಾಖಲೆ ಇಲ್ಲದೆ ಕೊನೆಗೊಳ್ಳುತ್ತವೆ.
systemctl cat [email protected] grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf
ಮೊದಲನೆಯದು ಯುನಿಟ್ ಅನ್ನು ಅದರ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಬದಲಿಸುವ ಯಾವುದೇ ಓವರ್‌ರೈಡ್‌ನೊಂದಿಗೆ ತೋರಿಸುತ್ತದೆ. ಎರಡನೆಯದು ಪ್ರೊಫೈಲ್ ತಳ್ಳಲಾದ ಮಾರ್ಗಗಳನ್ನು ಒಟ್ಟಾರೆಯಾಗಿ ಸ್ವೀಕರಿಸುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಮುಂದಿನ ಎಲ್ಲವನ್ನೂ ನಿರ್ಧರಿಸುವ ಸ್ವಿಚ್.
ಗುರುತುಗಳು ಉತ್ತರಗಳನ್ನು ಅವು ಬಂದ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲೇ ಇರಿಸುತ್ತವೆ
ಪ್ರತಿ ಸುರಂಗ ವಿಭಿನ್ನ ಮೂಲಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಿದಾಗ, ಉತ್ತರವು ತಪ್ಪು ಲಿಂಕ್ ಮೂಲಕ ಹೊರಹೋಗಬಹುದು ಮತ್ತು ಮೊದಲ ಪ್ಯಾಕೆಟ್ ನಂತರ ಸಂಪರ್ಕ ಸಾಯುತ್ತದೆ. ನಿಲ್ಲುವ ಮಾದರಿಯೆಂದರೆ ಬರುತ್ತಿರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಇನ್‌ಪುಟ್ ಇಂಟರ್‌ಫೇಸ್ ಪ್ರಕಾರ ಗುರುತಿಸುವುದು, ಆ ಗುರುತನ್ನು ಉತ್ತರದಲ್ಲಿ ಮರುಸ್ಥಾಪಿಸುವುದು, ಮತ್ತು ಪ್ರತಿ ಗುರುತಿಗೆ ತನ್ನದೇ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಇರುವ ಕೋಷ್ಟಕ ನೀಡುವುದು.
ಬಾಧಿತ ಇಂಟರ್‌ಫೇಸ್‌ಗಳಿಗೆ ಸಡಿಲವಾದ ಹಿಮ್ಮುಖ ಮಾರ್ಗ ಫಿಲ್ಟರಿಂಗ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಸಡಿಲಗೊಳಿಸಬೇಕು, ಏಕೆಂದರೆ ಉತ್ತರವು ಮುಖ್ಯ ಕೋಷ್ಟಕ ಎಂದಿಗೂ ಆಯ್ಕೆ ಮಾಡದ ಲಿಂಕ್ ಮೂಲಕ ಕಾನೂನುಬದ್ಧವಾಗಿ ಬರುತ್ತದೆ. ಗುರುತುಗಳನ್ನು ಸಂಕುಚಿತವಾಗಿ ಇರಿಸಿ, ಅವು ಸುರಂಗಗಳ ಸ್ವಂತ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಸಂಚಾರವನ್ನು ಎಂದಿಗೂ ಹಿಡಿಯದಿರಲಿ, ಅದು ಸುರಂಗವನ್ನು ಅದರ ಮೂಲಕವೇ ಕಳುಹಿಸುತ್ತದೆ.
ip rule show ip route show table 101 sysctl net.ipv4.conf.all.rp_filter
ಇನ್ನೊಂದನ್ನು ಸೇರಿಸುವ ಮೊದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿಯಮಗಳನ್ನು ಓದಿ. ನಕಲಿ ಆದ್ಯತೆಗಳು ಮತ್ತು ಮರೆತುಹೋದ ಕೋಷ್ಟಕಗಳೇ ಗುರುತು ನೀತಿ ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಣಾಮ ಬೀರದಂತೆ ಕಾಣುವ ಸಾಮಾನ್ಯ ಕಾರಣ.
ಒಂದು ಲಿಂಕ್ ನಿಲ್ಲಿಸಿ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿ
ಎರಡೂ ಸುರಂಗಗಳು ಏರಿರುವಾಗ ಪ್ರತಿ ಇಂಟರ್‌ಫೇಸ್‌ನ ವಿಳಾಸ, ಪ್ರತಿ ಸುರಂಗದ ಹಿಂದೆ ಒಂದು ಹೋಸ್ಟ್‌ಗೆ ಇರುವ ಮಾರ್ಗ, ಮತ್ತು ಸಂಬಂಧವಿಲ್ಲದ ಗಮ್ಯಸ್ಥಾನ ತೆಗೆದುಕೊಳ್ಳುವ ದಾರಿಯನ್ನು ದಾಖಲಿಸಿ. ಒಂದೇ ಕೋಷ್ಟಕ ಓದುವ ಬದಲು ಕರ್ನೆಲ್‌ಗೆ ಹುಡುಕಾಟವನ್ನು ಕೇಳಿ, ಏಕೆಂದರೆ ಒಂದು ಕೋಷ್ಟಕ ಎಂದಿಗೂ ಅಂತಿಮ ನಿರ್ಧಾರವನ್ನು ತೋರಿಸುವುದಿಲ್ಲ.
ನಂತರ ಒಂದು ಇನ್‌ಸ್ಟಾನ್ಸ್ ನಿಲ್ಲಿಸಿ, ಇನ್ನೊಂದು ಮುಂದುವರಿಯುತ್ತಿರುವಾಗ ಅದರ ಇಂಟರ್‌ಫೇಸ್ ಮತ್ತು ಮಾರ್ಗಗಳು ಮಾಯವಾಗುವುದನ್ನು ನೋಡಿ. ಉಳಿದುಕೊಂಡದ್ದರಲ್ಲಿ ಭಂಗ ಎಂದರೆ ಎರಡೂ ಇನ್ನೂ ಯಾರೂ ಬೇರ್ಪಡಿಸದ ಸಾಧನದ ಹೆಸರು, ಮಾರ್ಗ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ನಿಯಮವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಿವೆ.
ನಿಲ್ಲಿಸಿದ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಮರಳಿ ತನ್ನಿ ಮತ್ತು ಅದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಮರುಬೂಟ್ ನಂತರ ಮೊದಲ ಪ್ರಾರಂಭದಲ್ಲಿ ಮಾತ್ರ ಸುರಂಗ ಉಳಿದುಕೊಂಡರೆ, ನೀವು ಮಾರ್ಗದರ್ಶನ ವಿನ್ಯಾಸವಲ್ಲ, ಜೀವನಚಕ್ರ ದೋಷವನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ.