OpenVPN iroute ಮತ್ತು ಕರ್ನಲ್ ಮಾರ್ಗ: ಯಾವುದು ಕಾಣೆಯಾಗಿದೆ?

10.77.20.0/24 ಗಾಗಿ ಪ್ಯಾಕೆಟ್ OpenVPN ಸರ್ವರ್ನಲ್ಲಿ ಎರಡು ಪ್ರತ್ಯೇಕ ನಿರ್ಣಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ: ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅದನ್ನು VPN ಇಂಟರ್ಫೇಸ್ಗೆ ಒಪ್ಪಿಸಬೇಕು, ಮತ್ತು OpenVPN ಯಾವ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಆ ಪ್ರಿಫಿಕ್ಸ್ನ ಮಾಲೀಕ ಎಂದು ತಿಳಿಯಬೇಕು. ಕರ್ನಲ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ ಸುರಂಗದ ಮೊದಲೇ ಬೀಳುತ್ತದೆ, ಮತ್ತು ಪೀರ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಅದರ ನಂತರ ಬೀಳುತ್ತದೆ. ದೂರದ LAN ನಿಂದ ಎರಡೂ ವೈಫಲ್ಯಗಳು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಮತ್ತು ನಿಮ್ಮಲ್ಲಿ ಯಾವುದು ಇದೆ ಎಂದು ನಿರ್ಣಯಿಸಲು ಪ್ರತಿ ಬದಿಯಲ್ಲಿ ಒಂದು ಆದೇಶ ಬೇಕು.

ಸಾಂಪ್ರದಾಯಿಕ ಬಳಕೆದಾರ ಸ್ಥಳದ ಡೇಟಾ ಮಾರ್ಗದಲ್ಲಿ ಕರ್ನಲ್ ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸುರಂಗ ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪಿಸುತ್ತದೆ, ಮತ್ತು iroute ಆ ಪ್ರಕ್ರಿಯೆಗೆ ಯಾವ ಪೀರ್ ಅದನ್ನು ಸ್ವೀಕರಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಯಾವುದೂ ಇನ್ನೊಂದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಮಾತ್ರ ಹೊಂದಿರುವ ಸಂರಚನೆ ಮೊದಲ ping ವರೆಗೆ ಸಮಂಜಸವಾಗಿ ಕಾಣುತ್ತದೆ.

ಎರಡು ನಿರ್ಣಯಗಳು, ಒಂದು ಮಾರ್ಗವಲ್ಲ

10.77.20.0/24 ಒಂದೇ ಕ್ಲೈಂಟ್ನ ಹಿಂದೆ ಇರುವ ಸೈಟ್-ಟು-ಸೈಟ್ ಸಂಪರ್ಕವನ್ನು ಊಹಿಸಿ. ಸರ್ವರ್ನ ಕರ್ನಲ್ ಮಾರ್ಗ, ಉದಾಹರಣೆಗೆ ip route add 10.77.20.0/24 dev tun0, ಹೊಂದಿಕೆಯಾಗುವ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸುರಂಗ ಸಾಧನಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ನಂತರ OpenVPN ತನ್ನ ಆಂತರಿಕ ಕೋಷ್ಟಕವನ್ನು ನೋಡುತ್ತದೆ, ಅದು ಕ್ಲೈಂಟ್ ಸಂರಚನಾ ಕೋಶದಲ್ಲಿನ iroute ನಮೂದುಗಳಿಂದ ನಿರ್ಮಿಸಲ್ಪಟ್ಟಿದೆ, ಯಾವ ಪೀರ್ ಸಂಪರ್ಕ ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂದು ನಿರ್ಣಯಿಸಲು. ಕರ್ನಲ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ ಎಂದಿಗೂ ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪುವುದಿಲ್ಲ, ಮತ್ತು ಪೀರ್ ಮಾರ್ಗ ಇಲ್ಲದಿದ್ದರೆ ಅದು ಪ್ರಕ್ರಿಯೆಗೆ ತಲುಪಿ ಎಲ್ಲಿಗೂ ಹೋಗುವುದಿಲ್ಲ.

ಆ ವಿಭಜನೆಯನ್ನು ಮರೆಯುವುದು ಸುಲಭ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ನಲ್ಲಿನ ಒಂದೇ ಮಾರ್ಗ ಸಾಲು ಎರಡೂ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ. ಅದು ಮಾಡುವುದಿಲ್ಲ: ಮಾರ್ಗವನ್ನು ತಳ್ಳುವುದು ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸುರಂಗದ ಮೂಲಕ ಏನನ್ನು ಕಳುಹಿಸಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ iroute ಸರ್ವರ್ಗೆ ಕ್ಲೈಂಟ್ನ ಹಿಂದಿನ ವಿಳಾಸ ಶ್ರೇಣಿ ಯಾರಿಗೆ ಸೇರಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಅವು ಬೇರೆ ಬೇರೆ ಫೈಲ್ಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಬೇರೆ ಬೇರೆ ಬದಿಗಳು ಓದುತ್ತವೆ, ಮತ್ತು ವಿರುದ್ಧ ದಿಕ್ಕುಗಳಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

iroute ಎಲ್ಲಿದೆ ಮತ್ತು ಏನು ಹೇಳುತ್ತದೆ

ನಮೂದು ಕ್ಲೈಂಟ್ನ common_name ನಂತೆ ಹೆಸರಿಸಲಾದ ಪ್ರತಿ-ಕ್ಲೈಂಟ್ ಫೈಲ್ಗೆ, client-config-dir ಅಡಿಯಲ್ಲಿ, iroute 10.77.20.0/24 ರೂಪದಲ್ಲಿ ಹೋಗುತ್ತದೆ. ಫೈಲ್ನ ಹೆಸರಿನ ಹೊಂದಾಣಿಕೆ ಅಲಂಕಾರಿಕವಲ್ಲ: OpenVPN ದೃಢೀಕೃತ ಗುರುತನ್ನು ಹುಡುಕಿ ನಿಖರವಾಗಿ ಆ ಹೆಸರಿನ ಫೈಲ್ ಓದುತ್ತದೆ, ಆದ್ದರಿಂದ site-a ಎಂಬ ಫೈಲ್ ಸಾಮಾನ್ಯ ಹೆಸರು site-a ಇರುವ ಕ್ಲೈಂಟ್ಗೆ ಮಾತ್ರ ಅನ್ವಯವಾಗುತ್ತದೆ. ಅಂತಹ ಫೈಲ್ ಇಲ್ಲದ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರಾಕರಿಸಬೇಕಾದರೆ ccd-exclusive ಸೇರಿಸಿ, ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಸೈಟ್ ಗೇಟ್ವೇ ಆಗಿರುವಾಗ ಇದು ಸರಿಯಾದ ಸೆಟ್ಟಿಂಗ್. ಪ್ರತಿ ಗೇಟ್ವೇಗೆ ಒಂದು ಫೈಲ್ ಇರಿಸಿ ಮತ್ತು ನೀವು ನಿಜವಾಗಿ ನೀಡುವ ಪ್ರಮಾಣಪತ್ರದ ವಿಷಯದ ಹೆಸರಿನಿಂದ ಅದನ್ನು ಹೆಸರಿಸಿ.

ದೂರದ LAN ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸರ್ವರ್ನಿಂದ ನಮೂದನ್ನು ಪರೀಕ್ಷಿಸಿ. ಸ್ಥಿತಿ ಫೈಲ್ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಅವರ ಸಾಮಾನ್ಯ ಹೆಸರುಗಳೊಂದಿಗೆ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು --verb 4 ನಲ್ಲಿ ಚಲಿಸುವ ಸರ್ವರ್ ಪೀರ್ ಸಂಪರ್ಕಗೊಂಡಾಗ iroute ಸ್ಥಾಪನೆಯಾಗುವುದನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ. ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಏನೂ ಕಾಣದಿದ್ದರೆ, ಫೈಲ್ ತಪ್ಪು ಕೋಶದಲ್ಲಿದೆ ಅಥವಾ ತಪ್ಪು ಗುರುತನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

ಬಲೆ: ಫೈಲ್ ಇದೆ, ಗುರುತು ತಪ್ಪು

ಸರಿಯಾಗಿ ಕಾಣುವ iroute ತಪ್ಪು ಪೀರ್ನೊಂದಿಗೆ ಜೋಡಿಸಲ್ಪಟ್ಟರೆ ಕಾಣೆಯಾದ ಫೈಲ್ಗಿಂತ ಹೆಚ್ಚು ಸಮಯ ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಡಿಸ್ಕ್ನಲ್ಲಿ ಎಲ್ಲವೂ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರಗಳ ಮರುನಾಮಕರಣ, ನಕಲಿ ಸಾಮಾನ್ಯ ಹೆಸರುಗಳು, ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಗುರುತನ್ನು ಬದಲಿಸುವ username-as-common-name ಇವೆಲ್ಲವೂ ಇದನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಸರ್ವರ್ ಯಾವ ಗುರುತನ್ನು ದೃಢೀಕರಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ, ನೀವು ನಿರೀಕ್ಷಿಸಿದ್ದನ್ನು ಅಲ್ಲ: ಸ್ಥಿತಿ ಔಟ್ಪುಟ್ ಅಧಿಕೃತವಾದದ್ದು, ಫೈಲ್ ಹೆಸರು ಕೇವಲ ಹುಡುಕಾಟ ಕೀ.

ಮಾರ್ಗವು ತನ್ನ ಮಾಲೀಕನಿಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕಬಹುದು. ಸ್ಥಿರ ಮಾರ್ಗಗಳು ಮತ್ತು iroute ನಮೂದುಗಳು ಲಭ್ಯತೆಯ ಖಾತರಿಯಲ್ಲ, ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ವಿವರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಂಚಾರವು ಪ್ರಸ್ತುತ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಿರುವ ಪೀರ್ನ ಕಡೆಗೆ ಮುಂದುವರಿಯಬಹುದು.

ಪೀರ್ನ ಆಚೆಗಿನ ಮಾರ್ಗವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ

ಪೀರ್ ಮಾಲೀಕತ್ವವು ಮಾರ್ಗದ ಮಧ್ಯದಲ್ಲಿದೆ, ಅಂತ್ಯದಲ್ಲಲ್ಲ. ಕ್ಲೈಂಟ್ ಸುರಂಗದಿಂದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ತನ್ನ LAN ಗೆ ರವಾನಿಸಬೇಕು, ಅಂದರೆ ಆ ಹೋಸ್ಟ್ನಲ್ಲಿ IP ರವಾನೆ ಸಕ್ರಿಯವಾಗಿರಬೇಕು ಮತ್ತು ಅಂಗೀಕಾರಕ್ಕೆ ಅನುಮತಿಸುವ firewall ನಿಯಮ ಇರಬೇಕು. ದೂರದ LAN ನ ಹೋಸ್ಟ್ಗಳಿಗೆ ಸುರಂಗ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು: ಗೇಟ್ವೇ ಕಡೆಗೆ ತೋರುವ ಮಾರ್ಗ, ಅಥವಾ ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ NAT. ವಿತರಣೆಯ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಊಹಿಸುವ ಬದಲು sysctl net.ipv4.ip_forward ನಿಂದ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ರವಾನೆ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ.

ಇತರ VPN ಕ್ಲೈಂಟ್ಗಳು ಆ ಸಬ್ನೆಟ್ ತಲುಪಬೇಕಾದರೆ, ವ್ಯವಸ್ಥೆ ಮತ್ತೆ ಬೆಳೆಯುತ್ತದೆ: ಸರ್ವರ್ಗೆ client-to-client ಬೇಕು, ಮತ್ತು ಆ ಕ್ಲೈಂಟ್ಗಳು ಪ್ರಿಫಿಕ್ಸ್ ಅನ್ನು ಸುರಂಗದ ಮೂಲಕ ಮಾರ್ಗ ಮಾಡಬೇಕು. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸರ್ವರ್ನ ಸ್ವಂತ ಮಾರ್ಗ ಕೋಷ್ಟಕದಿಂದ ಬರುವುದಿಲ್ಲ.

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