ಸ್ಥಿರ OpenVPN ವಿಳಾಸಗಳು ಮೂಲ IP ಅಲ್ಲ, ಗುರುತನ್ನು ಅನುಸರಿಸಬೇಕು

‘ಈ ಲ್ಯಾಪ್ಟಾಪ್ 10.90.0.10 ಪಡೆಯುತ್ತದೆ’ ಎಂದು ಹೇಳುವ ವಿಳಾಸ ಯೋಜನೆಗಳು ವಾಸ್ತವವಾಗಿ ಗುರುತಿನ ಬಗ್ಗೆ ಹೇಳಿಕೆಗಳು: ಯಾವ ದೃಢೀಕೃತ ಸಾಧನವು ಆ ವಿಳಾಸವನ್ನು ಹೊಂದಬಹುದು. ಆ ಸಾಧನದ ಪ್ರಸ್ತುತ ಸಾರ್ವಜನಿಕ IP ಗೆ ಇದಕ್ಕೆ ಬಹುತೇಕ ಸಂಬಂಧವಿಲ್ಲ, ಏಕೆಂದರೆ NAT ಮತ್ತು ರೋಮಿಂಗ್ ಬಳಕೆದಾರರು ಯಾರು ಎಂಬುದನ್ನು ಬದಲಿಸದೆ ಅದನ್ನು ಬದಲಿಸುತ್ತವೆ. ಮೂಲ ವಿಳಾಸದ ಮೇಲೆ ಯೋಜನೆಯನ್ನು ನಿರ್ಮಿಸಿದರೆ ಮೊದಲ ಹೋಟೆಲ್ ನೆಟ್ವರ್ಕ್ನಲ್ಲೇ ಮುರಿಯುವ ನಿಯಮಗಳು ಉಂಟಾಗುತ್ತವೆ. ದೃಢೀಕೃತ ಗುರುತಿನ ಮೇಲೆ ಅದನ್ನು ನಿರ್ಮಿಸಿದರೆ ಪ್ರಯಾಣವನ್ನು ತಾಳಿಕೊಳ್ಳುವ ಯೋಜನೆ ಉಂಟಾಗುತ್ತದೆ.

ಸರ್ವರ್ ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ವಿಳಾಸವು ಯಾವುದಕ್ಕಾಗಿ ಎಂದು ನಿರ್ಧರಿಸಿ.

ವಿಳಾಸಕ್ಕಿಂತ ಮೊದಲು ಗುರುತಿನ ಕೀಲಿಯನ್ನು ಆಯ್ಕೆಮಾಡಿ

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

duplicate-cn ನೊಂದಿಗೆ, ಹಲವು ಏಕಕಾಲಿಕ ಸೆಷನ್ಗಳು ಒಂದೇ ಸಾಮಾನ್ಯ ಹೆಸರನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ಪಿನ್ ಮಾಡಿದ ವಿಳಾಸವು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಗುರುತಿಸಲಾರದು. ಇದು ಗುರುತಿನ ಮಾದರಿಯ ಗುಣಲಕ್ಷಣ, ಉತ್ತಮ ವಿಳಾಸ ಯೋಜನೆ ಸರಿಪಡಿಸಬಹುದಾದ ವಿಷಯವಲ್ಲ.

ಕಾಯ್ದಿರಿಸುವಿಕೆಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕ ಶ್ರೇಣಿಯ ಹೊರಗೆ ಇರಿಸಿ

10.90.0.0/24 ನಂತಹ ಸಬ್ನೆಟ್ ಟೋಪಾಲಜಿ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ, ಹೆಸರಿಸಿದ ಸದಸ್ಯರಿಗೆ ಕೆಳಗಿನ ವಿಳಾಸಗಳನ್ನು ಇರಿಸಿ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ಪೂಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಶ್ರೇಣಿಯಲ್ಲಿ ಇರಿಸಿ. ಪಿನ್ ಮಾಡಿದ ಸದಸ್ಯರ ನಿಯೋಜನೆ ಹೀಗೆ ಕಾಣುತ್ತದೆ ifconfig-push 10.90.0.10 255.255.255.0 ಸರ್ವರ್ ಆ ಗುರುತಿಗೆ ಆಯ್ಕೆಮಾಡುವ ಫೈಲ್ನಲ್ಲಿ. ಎರಡನೇ ಆರ್ಗ್ಯುಮೆಂಟ್ net30 ಅಡಿಯಲ್ಲಿ ಬೇರೆ ಅರ್ಥ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಉದಾಹರಣೆ ಟೋಪಾಲಜಿ-ತಟಸ್ಥವಲ್ಲ. ನಕಲಿಸುವ ಮೊದಲು ಟೋಪಾಲಜಿಯನ್ನು ಓದಿ.

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

ನಿಯೋಜನೆಯ ಆದ್ಯತೆ ಯಾರು ಗೆಲ್ಲುತ್ತಾರೆ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ

ಕೈಪಿಡಿಯು ಕ್ರಮವನ್ನು ದಾಖಲಿಸುತ್ತದೆ: client-connect ಸಮಯದಲ್ಲಿ ರಚಿಸಲಾದ ಸ್ಪಷ್ಟ ನಿಯೋಜನೆ client-config-dir ನಮೂದಿಗಿಂತ ಮೊದಲು ಜಾರಿಗೆ ಬರಬಹುದು, ಅದು ತಾನೇ ಸಾಮಾನ್ಯ ಪೂಲ್ ಹಂಚಿಕೆಗಿಂತ ಮೊದಲು ಬರುತ್ತದೆ. ಆ ಕ್ರಮವು ‘ಪಿನ್ ಮಾಡಿದ ವಿಳಾಸ ಅನ್ವಯವಾಗಲಿಲ್ಲ’ ಎಂಬ ಹೆಚ್ಚಿನ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದು ಪ್ರತಿ ಸೆಷನ್ಗೂ ಕಾನ್ಫಿಗರೇಶನ್ ಬರೆಯುವ ಕ್ರಿಯಾತ್ಮಕ ಹಂಚಿಕೆದಾರನು ನೀವು ಅಧಿಕೃತ ಎಂದು ಭಾವಿಸಿದ ಸ್ಥಿರ ಫೈಲ್ ಅನ್ನು ಮೌನವಾಗಿ ಬದಲಿಸಬಹುದು ಎಂದೂ ಅರ್ಥೈಸುತ್ತದೆ.

ನಿಯೋಜನೆಗಳನ್ನು ಹೊಂದಿರುವ ಒಂದು ಪದರವನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಉಳಿದವನ್ನು ಓದಲು-ಮಾತ್ರ ಮಾಡಿ. ಎರಡೂ ನಿರ್ಧರಿಸುತ್ತೇವೆ ಎಂದು ಹೇಳುವ ಎರಡು ಪದರಗಳು ಸಮಯ-ಅವಲಂಬಿತ ನಿಯೋಜನೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ.

ಕ್ರಿಯಾತ್ಮಕ ಹಂಚಿಕೆದಾರನಿಗೂ ಅದೇ ಮಾದರಿ ಬೇಕು

ಪ್ರತಿ ಸೆಷನ್ಗೂ ವಿಳಾಸಗಳನ್ನು ಹಂಚುವ client-connect ಏಕೀಕರಣ ಸಾಮಾನ್ಯ ಹಂಚಿಕೆದಾರ ಸಮಸ್ಯೆಗಳಿರುವ ಸಣ್ಣ ಹಂಚಿಕೆದಾರ. ಅದು ವಿನಂತಿಸುವ ಗುರುತನ್ನು ಪರಿಶೀಲಿಸಬೇಕು, ವಿಳಾಸವನ್ನು ಪರಮಾಣು ರೀತಿಯಲ್ಲಿ ಕಾಯ್ದಿರಿಸಬೇಕು, ಬೆಂಬಲಿತ ಪ್ರತಿ-ಸಂಪರ್ಕ ಔಟ್ಪುಟ್ ಮಾತ್ರ ನೀಡಬೇಕು, ಮತ್ತು ಸಂಪರ್ಕ ಕಡಿತ ಅಥವಾ ವೈಫಲ್ಯದಲ್ಲಿ ಕಾಯ್ದಿರಿಸುವಿಕೆಯನ್ನು ಬಿಡುಗಡೆ ಮಾಡಬೇಕು. ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳಿಗೆ ಲಾಕ್ ಅಥವಾ ಡೇಟಾಬೇಸ್ ನಿರ್ಬಂಧ ಬೇಕು, ಓದಿ-ನಂತರ-ಬರೆಯುವ ಕ್ರಮ ಅಲ್ಲ. ಸ್ವಚ್ಛಗೊಳಿಸದಿದ್ದರೆ, ಪೂಲ್ ಮರುಪ್ರಾರಂಭದವರೆಗೆ ವಿಳಾಸಗಳನ್ನು ಸೋರಿಸುತ್ತದೆ.

ಹಂಚಿಕೆದಾರನ ಸ್ಥಿತಿಯನ್ನು ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಓದಬಹುದಾದ ಸ್ಥಳದಲ್ಲಿ ಇರಿಸಿ, ಮತ್ತು ವಿಳಾಸವನ್ನು ಮಾತ್ರವಲ್ಲ, ಗುರುತು-ತೊ-ವಿಳಾಸ ನಿರ್ಧಾರವನ್ನು ಲಾಗ್ ಮಾಡಿ.

ವಿಳಾಸ ನೀತಿಯೋ ಅನುಕೂಲವೋ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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