ಒಂದೇ Linux ಗೇಟ್ವೇನಲ್ಲಿ ಎರಡು OpenVPN ಕ್ಲೈಂಟ್: ನೀತಿಯನ್ನು ವಿಭಜಿಸಿ

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

ಕರ್ನಲ್ ನಿರ್ಧರಿಸುತ್ತದೆ, ಡೀಮನ್ ಅಲ್ಲ

ಮುಂದಕ್ಕೆ ರವಾನೆಯಾಗುವ ಪ್ಯಾಕೆಟ್ LAN ಇಂಟರ್ಫೇಸ್ಗೆ ಬರುತ್ತದೆ ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಡ್ ನಿಯಮಗಳ ಪಟ್ಟಿಯನ್ನು ಆದ್ಯತೆಯ ಕ್ರಮದಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ. ಸೆಲೆಕ್ಟರ್ ಮೊದಲು ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಮವು ಒಂದು ಕೋಷ್ಟಕವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಕೋಷ್ಟಕದ ರೂಟ್ಗಳು ಔಟ್ಪುಟ್ ಸಾಧನವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. ಕೋಷ್ಟಕದಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವ ರೂಟ್ ಇಲ್ಲದಿದ್ದರೆ, ಹುಡುಕಾಟ ಮುಂದಿನ ನಿಯಮಕ್ಕೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಮತ್ತು ಈ ವಿವರವೇ ಅರ್ಧ ಮುಗಿದ ಸಂರಚನೆಯು ಗಟ್ಟಿಯಾಗಿ ಅಲ್ಲ, ಮೌನವಾಗಿ ವಿಫಲವಾಗಲು ಕಾರಣ.

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

ಪ್ರತಿ ಪ್ರತಿಗೆ ಅದರದೇ ಸಂಪನ್ಮೂಲ ಗುಂಪನ್ನು ನೀಡಿ

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

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull ಸರ್ವರ್ ತಳ್ಳುವ ರೂಟ್ಗಳನ್ನು ಸ್ಥಳೀಯ ಕೋಷ್ಟಕದಿಂದ ಹೊರಗೆ ಇಡುತ್ತದೆ, ಮತ್ತು ನೀತಿ ಕೋಷ್ಟಕಗಳು ಸ್ಪಷ್ಟವಾಗಿರಬೇಕಾದಾಗ ನೀವು ಬಯಸುವುದು ಅದನ್ನೇ. ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ redirect-gateway ಆಯ್ಕೆಯನ್ನೂ ತಳ್ಳುತ್ತದೆಯೇ, ಮತ್ತು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ ಫಿಲ್ಟರ್ ರೂಪವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಊಹಿಸುವ ಬದಲು ಕೈಪಿಡಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸುವುದು ಒಳ್ಳೆಯದು.

ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಬರೆಯಿರಿ: ಮೂಲ, ಕೋಷ್ಟಕ, ಸಾಧನ

ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಗುಂಪಿಗೆ, ಮೂಲ ವಿಳಾಸದ ಮೂಲಕ ಕೋಷ್ಟಕವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ನಿಯಮ ಸೇರಿಸಿ, ನಂತರ ಉದ್ದೇಶಿತ ಮಾರ್ಗವನ್ನು ಆ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

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

ಸುರಂಗದ ತನ್ನದೇ ಸಾಗಣೆ ಕ್ಲೈಂಟ್ ಗುಂಪಿನಲ್ಲಿಲ್ಲ

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

ಸ್ಥಳೀಯ ನಿರ್ವಹಣಾ ಅಧಿವೇಶನ ಮತ್ತು ಕೆಳಪದರದ ಮಾರ್ಗವನ್ನು ನೀತಿ ಕೋಷ್ಟಕಗಳಿಂದ ಸ್ಪಷ್ಟವಾಗಿ ಹೊರಗೆ ಇಡಿ. ಆ ವಿನಾಯಿತಿಗಳನ್ನು ಮ್ಯಾಟ್ರಿಕ್ಸ್ನ ಪಕ್ಕದಲ್ಲಿ ಬರೆಯಿರಿ; ಅವು ವಿನ್ಯಾಸದ ಭಾಗ, ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಬೇಕಾದ ಉಪಾಯವಲ್ಲ.

ಮಾರ್ಗ ಆಯ್ಕೆ ಅದನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ

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

ಮೂಲ ಭಾಷಾಂತರವು ಮೂರನೇ ನಿರ್ಧಾರ, ಮತ್ತು ಅದನ್ನು ಮೂಲ ಗುಂಪು ಮತ್ತು ಅದನ್ನು ನಿಜವಾಗಿ ಸಾಗಿಸುವ ಸುರಂಗ ಸಾಧನಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಬೇಕು. postrouting ಸರಪಳಿಯನ್ನು ಖಾಲಿ ಮಾಡುವ ಬದಲು ಎರಡು ಪ್ರತಿಗಳಿಗೆ ಮೀಸಲಾದ ಸರಪಳಿಯನ್ನು ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಸಂಬಂಧವಿಲ್ಲದ ಸೇವೆಗಳು ಅಲ್ಲಿ ನಮೂದುಗಳನ್ನು ಹೊಂದಿರಬಹುದು ಮತ್ತು ಖಾಲಿ ಮಾಡುವುದು ಅವನ್ನು ಮೌನವಾಗಿ ತೆಗೆದುಹಾಕುತ್ತದೆ.

ಒಂದು ಸುರಂಗ ಬಿದ್ದಾಗ ಏನಾಗುತ್ತದೆ

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

ಪ್ರತಿ ಮೂಲ ಗುಂಪಿನಿಂದ ಹೊಸ ವಿನಂತಿ ಕಳುಹಿಸಿ ಮತ್ತು ನಾಲ್ಕು ಅಂಶಗಳನ್ನು ದಾಖಲಿಸಿ: ಆಯ್ಕೆಯಾದ ಕೋಷ್ಟಕ, ಔಟ್ಪುಟ್ ಸಾಧನ, ಭಾಷಾಂತರಿಸಿದ ಮೂಲ, ಮತ್ತು ಉತ್ತರ ಅದೇ ಮಾರ್ಗದಲ್ಲಿ ಮರಳಿ ಬಂದಿತೇ. ನಂತರ ಒಂದು ಸುರಂಗವನ್ನು ಇಳಿಸಿ ಪುನರಾವರ್ತಿಸಿ. ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯಲ್ಲಿ ಎರಡು TUN ಸಾಧನಗಳು ಎರಡೂ ಡೀಮನ್ಗಳು ಪ್ರಾರಂಭವಾದುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತವೆ; ನಿರ್ದಿಷ್ಟ ಕ್ಲೈಂಟ್ ಯಾವುದನ್ನು ಬಳಸಿತು ಎಂಬುದನ್ನು ಅವು ಏನೂ ಹೇಳುವುದಿಲ್ಲ. ಒಂದು ಸುರಂಗ ಇಲ್ಲದ ಎರಡನೇ ಸುತ್ತು — ನಿಮ್ಮ ಫಾಲ್ಬ್ಯಾಕ್ ನಿಯಮವು ನೀವು ಉದ್ದೇಶಿಸಿದ್ದನ್ನು ಮಾಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ತೋರಿಸುವ ಸುತ್ತು.