client-connect ಸ್ಕ್ರಿಪ್ಟ್ನಿಂದ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುವುದು ಕ್ಲೈಂಟ್ನ IP ಅನ್ನು ಸೆಟ್ ಮಾಡಬೇಕು ಎಂಬಂತೆ ಕಾಣುತ್ತದೆ. ಆದರೆ ಅದು ಮಾಡುವುದಿಲ್ಲ: ಹುಕ್ ನಿಂದ ಸರ್ವರ್ಗೆ ಇರುವ ಏಕೈಕ ಮಾರ್ಗವೆಂದರೆ ತಾತ್ಕಾಲಿಕ ಫೈಲ್, ಅದರ ಪಥವು ಸ್ಕ್ರಿಪ್ಟ್ನ ಕೊನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಬರುತ್ತದೆ, ಮತ್ತು ವಿಳಾಸವನ್ನು ಅಲ್ಲಿ ifconfig-push ಸಿಂಟ್ಯಾಕ್ಸ್ನಲ್ಲಿ ಬರೆಯಬೇಕು. ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸುವ ಅಥವಾ ಏನನ್ನೂ ಬರೆಯದೆ ಶೂನ್ಯದೊಂದಿಗೆ ನಿರ್ಗಮಿಸುವ ಸ್ಕ್ರಿಪ್ಟ್ ಪೂಲ್ನಿಂದ ವಿಳಾಸವನ್ನು ಹೊಂದಿರುವ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಲಾಗ್ ಸಂಪೂರ್ಣವಾಗಿ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣುತ್ತದೆ.

ಗೊಂದಲ ಸಮಂಜಸವಾಗಿದೆ, ಏಕೆಂದರೆ ಇತರ ಹಲವು ಹುಕ್ ಗಳು ನಿರ್ಗಮನ ಕೋಡ್ ಅಥವಾ ಪರಿಸರ ಚರಗಳ ಮೂಲಕ ನಿಜವಾಗಿಯೂ ಉತ್ತರಿಸುತ್ತವೆ. ಈ ಹುಕ್ ಗೆ ತನ್ನದೇ ಆದ ಒಪ್ಪಂದವಿದೆ, ಮತ್ತು ಒಪ್ಪಂದವು ಫೈಲ್ ಹೆಸರಿನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಹುಕ್ ಫೈಲ್ ಬರೆಯುತ್ತದೆ, ಮರಳಿಸುವ ಮೌಲ್ಯವಲ್ಲ

ಘೋಷಣೆ ಎರಡು ಸಾಲುಗಳು: ಕರೆಯನ್ನು ಅನುಮತಿಸಲು script-security 2, ನಂತರ client-connect /etc/openvpn/server/assign-address.sh. ಕ್ಲೈಂಟ್ ದೃಢೀಕರಣಗೊಂಡಾಗ, ಸರ್ವರ್ ಆ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ರಚಿಸಲಾದ ಫೈಲ್ ಪಥವನ್ನು ಕೊನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಸೇರಿಸಿ ಚಲಾಯಿಸುತ್ತದೆ, ಅದು $1 ಆಗುವುದು ಘೋಷಣೆ ತನ್ನದೇ ಹೆಚ್ಚುವರಿ ಆರ್ಗ್ಯುಮೆಂಟ್ಗಳನ್ನು ರವಾನಿಸದಿದ್ದರೆ ಮಾತ್ರ. ಆ ಕ್ಲೈಂಟ್ಗೆ ಅನ್ವಯಿಸುವ ಎಲ್ಲವೂ ಆ ಫೈಲ್ನಲ್ಲಿ ಸಾಮಾನ್ಯ ಸೂಚನೆಗಳಾಗಿ, ಪ್ರತಿ ಸಾಲಿಗೆ ಒಂದು, ಸಂರಚನೆಯಲ್ಲಿ ಕಾಣುವಂತೆಯೇ ನಿಖರವಾಗಿ ಬರೆಯಲಾಗುತ್ತದೆ. ತನ್ನದೇ ನಿಯತಾಂಕಗಳನ್ನು ಸೇರಿಸುವ ಹೊದಿಕೆ ಸ್ಥಾನವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ ಲಕ್ಷಣವೆಂದರೆ --verbose ನಂತೆ ಕಾಣುವ ಪಥಕ್ಕೆ ಬರೆಯುವ ಸ್ಕ್ರಿಪ್ಟ್.

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

ಎರಡು ಸೂಚನೆಗಳು ಗಮನಾರ್ಹ, ಏಕೆಂದರೆ ಅವು ಉಳಿದ ಎಲ್ಲದರೊಂದಿಗೆ ಪರಸ್ಪರ ಕ್ರಿಯಿಸುತ್ತವೆ. ifconfig-push ವಿಳಾಸವನ್ನು ನಿಗದಿಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಕಳುಹಿಸಲಾದ route ಟನೆಲ್ ಮೂಲಕ ಏನು ತಲುಪಬಹುದೆಂದು ಕ್ಲೈಂಟ್ಗೆ ತಿಳಿಸುತ್ತದೆ; ಮೊದಲನೆಯದನ್ನು ಮರಳಿಸಿ ಎರಡನೆಯದನ್ನು ಮರೆತರೆ ವಿಳಾಸವಿದ್ದರೂ ಹೋಗಲು ಸ್ಥಳವಿಲ್ಲದ ಕ್ಲೈಂಟ್ ಸಿಗುತ್ತದೆ. ಫೈಲ್ನೊಳಗಿನ ಕ್ರಮ ಮುಖ್ಯವಲ್ಲ, ಆದರೆ ಸಂಪೂರ್ಣತೆ ಮುಖ್ಯ. ಯಾವುದೇ ಸಹಭಾಗಿ ತಲುಪಲಾಗದ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ಮಾರ್ಗವನ್ನು ಕಳುಹಿಸುವ ಹುಕ್ ಇನ್ನೊಂದು ತುದಿಯಿಂದ ನೋಡಿದ ಅದೇ ತಪ್ಪು.

ಒಳಹರಿವು ಪರಿಸರ ಚರಗಳ ಮೂಲಕ ಬರುತ್ತದೆ: common_name, trusted_ip, ifconfig_pool_remote_ip ಮತ್ತು ಉಳಿದವು. ಅವೆಲ್ಲವನ್ನೂ ಸರ್ವರ್ನ ಹೊರಗಿನ ಸ್ಟ್ರಿಂಗ್ಗಳಂತೆ ಪರಿಗಣಿಸಿ, ಎಂದಿಗೂ ಶೆಲ್ ತುಣುಕುಗಳಂತೆ ಅಲ್ಲ.

ವಿಳಾಸ ಮ್ಯಾಪಿಂಗ್ ಒಂದು ನೀತಿ, ಅಂಕಗಣಿತವಲ್ಲ

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

ಹೆಸರನ್ನು ನಿಯಂತ್ರಿಸುವವರು ವಿಳಾಸವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಈ ನಿಯೋಜನೆಯಲ್ಲಿ common_name ನಿಜವಾಗಿ ಏನನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಿ. username-as-common-name ಸಕ್ರಿಯವಾದಾಗ ಗುರುತು ಎಂದರೆ ಲಾಗಿನ್, ಪ್ರಮಾಣಪತ್ರದ ವಿಷಯವಲ್ಲ. ಆ ಮೌಲ್ಯವನ್ನು ಎಂದಿಗೂ ಶೆಲ್ ಮೌಲ್ಯಮಾಪನಕ್ಕೆ ರವಾನಿಸಬೇಡಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಫೈಲ್ ಪಥವನ್ನು ಪ್ರಭಾವಿಸಲು ಎಂದಿಗೂ ಅವಕಾಶ ನೀಡಬೇಡಿ.

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

ifconfig-push ಎಂದರೇನು ಎಂಬುದನ್ನು ಟೋಪೊಲಜಿ ನಿರ್ಧರಿಸುತ್ತದೆ

10.77.0.0/24 ನಲ್ಲಿ topology subnet ಇದ್ದಾಗ, ifconfig-push 10.77.0.20 255.255.255.0 ಎಂಬುದು ವಿಳಾಸ ಮತ್ತು ಅದರ ನೆಟ್ಮಾಸ್ಕ್. topology net30 ಅಡಿಯಲ್ಲಿ ಎರಡನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಮಾಸ್ಕ್ ಅಲ್ಲ, ಸಹಭಾಗಿಯ ವಿಳಾಸ, ಆದ್ದರಿಂದ ಸಬ್ನೆಟ್ ರೂಪವನ್ನು net30 ಸರ್ವರ್ಗೆ ನಕಲಿಸಿದರೆ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಆದರೆ ಸಂಚಾರವನ್ನು ರವಾನಿಸಲಾಗದ ಕ್ಲೈಂಟ್ ಸಿಗುತ್ತದೆ. ಟೋಪೊಲಜಿಯನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬದಲಿಸಿ, ಉದಾಹರಣೆ ಸ್ಥಿರವಾಗಿ ಕಾಣಲು ಎಂದಿಗೂ ಬದಲಿಸಬೇಡಿ. ಈಗಾಗಲೇ net30 ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸರ್ವರ್ ಹಳೆಯ ವಿಳಾಸದಲ್ಲಿ ಜೀವಂತ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಬದಲಾವಣೆ ನಿರ್ವಹಣಾ ಕಿಟಕಿಯ ಮೈಗ್ರೇಷನ್, ಒಂದು ಸಾಲಿನ ಸಂಪಾದನೆಯಲ್ಲ.

ಸ್ಥಿರ ವಿಳಾಸಗಳು ಕ್ರಿಯಾತ್ಮಕ ಪೂಲ್ನ ಹೊರಗೆ ಮತ್ತು ಪ್ರತಿ ಇತರ ಸ್ಥಿರ ನಿಯೋಜನೆಯ ಹೊರಗೆ ಇರಬೇಕು, ಸಾಮಾನ್ಯ client-config-dir ಫೈಲ್ಗಳು ನೀಡುವವು ಸೇರಿದಂತೆ. ಎರಡು ಕಾರ್ಯವಿಧಾನಗಳು ವಿವಿಧ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಒಂದೇ ವಿಳಾಸವನ್ನು ಉತ್ಪಾದಿಸಬಲ್ಲವಾದರೆ, ಅವುಗಳಲ್ಲಿ ಒಂದು ಕೊನೆಗೆ ಹಾಗೆ ಮಾಡುತ್ತದೆ.

ಅದನ್ನು ನಂಬುವ ಮೊದಲು ನಾಲ್ಕು ಸಂದರ್ಭಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ಅದೇ ಪರಿಶೀಲನೆಗಳನ್ನು ಮ್ಯಾಪ್ ಮಾಡಿದ ಗುರುತು, ಮ್ಯಾಪ್ ಮಾಡದ ಗುರುತು, ಮರುಸಂಪರ್ಕ ಮತ್ತು ಅನುಕರಿಸಿದ ರಿಜಿಸ್ಟ್ರಿ ವೈಫಲ್ಯದ ವಿರುದ್ಧ ಚಲಾಯಿಸಿ. openvpn --config client.ovpn --verb 4 ನಿಗದಿಪಡಿಸಿದ ವಿಳಾಸವನ್ನು ಪುಶ್ ಉತ್ತರದಲ್ಲಿ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ನಲ್ಲಿ grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log ನಿಜವಾಗಿ ಏನು ಕಳುಹಿಸಲಾಗಿದೆ ಎಂಬುದನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಮ್ಯಾಪ್ ಮಾಡದ ಗುರುತಿಗೆ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶ ತಿರಸ್ಕೃತ ಸಂಪರ್ಕ, ಪೂಲ್ ವಿಳಾಸವಲ್ಲ.

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

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು