ಒಂದು OpenVPN ಹಬ್, ಮೂರು LAN: ವಿಳಾಸ ಯೋಜನೆ ಮತ್ತು iroute ಫೈಲ್‌ಗಳು

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

ಹಂತಗಳನ್ನು ಕ್ರಮವಾಗಿ ನಿರ್ವಹಿಸಿ. ಪ್ರತಿ ಹಂತವೂ ಹಿಂದಿನ ಹಂತದ ಯೋಜನೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಯಾವುದೂ ಹೊಸ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಧಿಕಾರವನ್ನು ಬೇಡುವುದಿಲ್ಲ.

ಯಾರೂ ಊಹಿಸಬೇಕಾಗಿಲ್ಲದ ಯೋಜನೆಯಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಸಂರಚನಾ ಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು ನಾಲ್ಕು ಪರಸ್ಪರ ಬೇರ್ಪಟ್ಟ ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಬರೆಯಿರಿ: ಹಬ್‌ನ ಸ್ವಂತ LAN, ಪ್ರತಿ ಶಾಖೆಯ LAN, ಮತ್ತು ಸಂಚರಿಸುವ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ನೀಡುವ ಪೂಲ್. ಬೇರ್ಪಡುವಿಕೆಯೇ ಉಳಿದೆಲ್ಲವನ್ನೂ ಸರಳವಾಗಿಡುತ್ತದೆ, ಏಕೆಂದರೆ ಅತಿಕ್ರಮಿಸುವ ಶ್ರೇಣಿಗಳು ರೂಟಿಂಗ್ ಅನ್ನು ದೀರ್ಘತಮ ಹೊಂದಾಣಿಕೆಯ ಒಗಟಾಗಿಸುತ್ತವೆ, ಅದನ್ನು ಎಷ್ಟೇ ಕ್ಲೈಂಟ್-ವಾರು ಸಂರಚನೆ ಸರಿಪಡಿಸಲಾರದು. ನಂತರ ಪ್ರತಿ LAN‌ಗೆ ಯಾವ ಯಂತ್ರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ತನ್ನ LAN‌ನ ಗೇಟ್‌ವೇ ಅಲ್ಲದ ಶಾಖಾ ರೌಟರ್‌ಗೆ ದೂರದ ರೂಟ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆ ಸ್ಥಾಪಿಸಬೇಕು. ಕೊನೆಗೆ, ಪ್ರತಿ ಶಾಖೆಯನ್ನು ಗುರುತಿಸುವ ದೃಢೀಕೃತ ಹೆಸರುಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಆ ಹೆಸರುಗಳೇ ಕ್ಲೈಂಟ್-ವಾರು ಫೈಲ್‌ಗಳನ್ನು ಹುಡುಕುವ ಕೀಲಿಗಳು.

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

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

ಶಾಖೆಗಳು ಎಲ್ಲಿವೆ ಎಂದು ಹಬ್ ಕರ್ಣಲ್‌ಗೆ ಹೇಳಿ

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

ಕರ್ಣಲ್ ನಿಯಮಗಳ ಜಾರಿ ಬಿಂದುವಾಗಿರಬೇಕಾದಾಗ client-to-client ಆಫ್ ಆಗಿರಲಿ. ಆ ಆಯ್ಕೆ ಪೀರ್‌ಗಳ ನಡುವಿನ ಸಂಚಾರವನ್ನು ಡೀಮನ್ ಒಳಗೆ ರವಾನಿಸುತ್ತದೆ, ಅದು ಅನುಕೂಲಕರವಾದರೂ ನಿಮ್ಮ ಫಾರ್ವರ್ಡಿಂಗ್ ನಿಯಮಗಳು ಆ ಹರಿವನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ ಎಂದರ್ಥ. ಕೆಳಗಿನ ಎಲ್ಲವೂ ಕರ್ಣಲ್ ಪ್ರತಿ ಶಾಖೆ-ನಡುವಿನ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ.

ಪ್ರತಿ ಶಾಖೆಗೆ ಬೇಕಾದ ರೂಟ್‌ಗಳನ್ನು ನೀಡಿ

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

ನಾಲ್ಕನೇ ಸೈಟ್ ಅದೇ ಮಾದರಿಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ: ಪ್ರತ್ಯೇಕ ದೃಢೀಕೃತ ಹೆಸರು, ಸ್ವಂತ ಪ್ರಿಫಿಕ್ಸ್, ಹಬ್ ಕರ್ಣಲ್ ರೂಟ್, iroute ನಮೂದು, ಮತ್ತು ಅದನ್ನು ತಲುಪಲು ಅನುಮತಿಸಿದ ಸೈಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಪ್ರಕಟಣೆಗಳು.

ಮುಗಿಯಿತು ಎನ್ನುವ ಮೊದಲು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ

ಮೂರೂ ರೌಟರ್‌ಗಳಲ್ಲಿ IPv4 ಫಾರ್ವರ್ಡಿಂಗ್ ಸಕ್ರಿಯಗೊಳಿಸಿ, ನಂತರ ಫೈರ್‌ವಾಲ್ ಉದ್ದೇಶಿತ ಹರಿವುಗಳನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಏಕೆಂದರೆ ಏಕ-ದಿಕ್ಕಿನ ಪರೀಕ್ಷೆ ಮುರಿದ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದೊಂದಿಗೆ ಯಾರೂ ನಿರೀಕ್ಷಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಉತ್ತೀರ್ಣವಾಗುತ್ತದೆ. ಸೈಟ್‌ಗಳ ನಡುವೆ ಮೂಲ ವಿಳಾಸದ ಅನುವಾದ ಅಗತ್ಯವಿಲ್ಲ, ಮತ್ತು ಮೂಲ ವಿಳಾಸವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದೇ ಪ್ರತಿ ಶಾಖೆಗೆ ತನ್ನದೇ ನೀತಿಯನ್ನು ವಿನಂತಿಗೆ ಅನ್ವಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

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

ಯೋಜನೆ, ಕ್ಲೈಂಟ್-ವಾರು ಫೈಲ್‌ಗಳು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳನ್ನು ಒಂದೇ ದಾಖಲೆಯಾಗಿ ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಸೈಟ್ ಸೇರ್ಪಡೆ ಅವುಗಳ ಆಧಾರದಲ್ಲಿ ನಿರ್ಣಯಿಸಲಾಗುತ್ತದೆ.

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