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

OPNsense ಈ overrideಗಳನ್ನು ಸರ್ವರ್ನ ಕ್ಲೈಂಟ್-ನಿರ್ದಿಷ್ಟ ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ಇಡುತ್ತದೆ, ಪ್ರಮಾಣಪತ್ರದ ಸಾಮಾನ್ಯ ಹೆಸರಿನಿಂದ ಕೀಲಿಯಾಗಿಸಿ, ಇದು ಸಾಮಾನ್ಯ ಹೆಸರನ್ನು ವಿಳಾಸ ಯೋಜನೆಯ ಭಾಗವಾಗಿಸುತ್ತದೆ.

ಅಂಟಿಕೊಳ್ಳುವ ಲೀಜ್ ಸ್ಥಿರ ವಿಳಾಸವಲ್ಲ

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

ಕ್ರಿಯಾತ್ಮಕ ಪರ್ಯಾಯ, ಅಂದರೆ client-connect ಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ನವೀಕರಣಗಳಿಂದ VPN ಅನ್ನು DNS ಗೆ ಜೋಡಿಸುವುದು, ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ನವೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸುವ resolver ಜೊತೆಗೆ ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲಿ ಸ್ಕ್ರಿಪ್ಟ್ ಬೇಕು. ಸಾಧನದಲ್ಲಿ ನೀವು ಮಾರಾಟಗಾರ ಒದಗಿಸುವ ಪ್ಯಾಕೇಜ್ಗಳಿಗೆ ಸೀಮಿತರಾಗಿರುತ್ತೀರಿ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲಿಯೇ ಆ ಯೋಜನೆ ನಿಲ್ಲುತ್ತದೆ.

ಯಾರೂ ಆನಂದಿಸದ /30 ಗಣಿತ

ಡೀಫಾಲ್ಟ್ net30 ಟೋಪಾಲಜಿಯಲ್ಲಿ ಪ್ರತಿ ಕ್ಲೈಂಟ್ ತನ್ನದೇ /30 ಪಡೆಯುತ್ತದೆ: ಮೊದಲ ಬಳಸಬಹುದಾದ ವಿಳಾಸ ಸರ್ವರ್ ಬದಿಗೆ ಹೋಗುತ್ತದೆ, ಎರಡನೆಯದು ಕ್ಲೈಂಟ್ಗೆ. ಆದ್ದರಿಂದ overrideಗಳು ಸರ್ವರ್ನ ಕ್ರಿಯಾತ್ಮಕ ಟನಲ್ ನೆಟ್ವರ್ಕ್ನ ಹೊರಗೆ ಇರಬೇಕು, ಅಂದರೆ ಮೊದಲು ಆ ನೆಟ್ವರ್ಕ್ ಅಗಲಗೊಳಿಸಬೇಕು. 10.8.0.0/24 ನಲ್ಲಿರುವ ಸರ್ವರ್ 10.8.0.0/23 ಗೆ ಹೋಗಬಹುದು, ಹಳೆಯ ವ್ಯಾಪ್ತಿಯ ಅರ್ಧ ಭಾಗವನ್ನು ಕ್ರಿಯಾತ್ಮಕ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮತ್ತು ಇನ್ನರ್ಧ overrideಗಳಿಗೆ ಬಿಟ್ಟು. ಮೂಲ /24 ಅನ್ನು ಹೆಚ್ಚುವರಿ IPv4 ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ ಆಗಿ ಸೇರಿಸಿ, ಇದರಿಂದ ಎರಡೂ ಅರ್ಧಗಳ ಸಂಚಾರ ಟನಲ್ಗೆ ರೂಟ್ ಆಗುತ್ತದೆ.

ಪ್ರತಿ override ವಿಳಾಸವೂ /30 ಗಡಿಯಲ್ಲಿ ಬೀಳಬೇಕು, ಆದ್ದರಿಂದ ಕೊನೆಯ ಆಕ್ಟೆಟ್ ನಾಲ್ಕರ ಗುಣಕ. 10.8.1.0 ನಲ್ಲಿ /30 ಕ್ಲೈಂಟ್ಗೆ 10.8.1.2 ನೀಡುತ್ತದೆ, ಮತ್ತು DNS ದಾಖಲೆ ಹೊತ್ತಿರುವುದು ಅದೇ ವಿಳಾಸ. ಬದಲಿಗೆ 10.8.1.3 ಆರಿಸಿದರೆ ಸಂಪರ್ಕಿಸಿ ಸಂಚಾರ ಹಾಯಿಸಲಾಗದ ಕ್ಲೈಂಟ್ ಉಂಟಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಆ ವಿಳಾಸ ಟೋಪಾಲಜಿ ಎಂದೂ ಅದಕ್ಕೆ ನೀಡದ ಸಬ್ನೆಟ್ಗೆ ಸೇರಿದೆ.

overrideಗಳನ್ನು ಅಗಲಗೊಳಿಸಿದ ವ್ಯಾಪ್ತಿಯ ಮೇಲಿನಿಂದ ಕೆಳಕ್ಕೆ ಹಂಚಿದರೆ ಯೋಜನೆ ಉಳಿಸಿಕೊಳ್ಳುವುದು ಸುಲಭ, ಇದರಿಂದ ಕ್ರಿಯಾತ್ಮಕ pool ಸ್ಥಿರ ದ್ವೀಪಗಳ ಸುತ್ತ ಅಲ್ಲ, ಖಾಲಿ ಜಾಗಕ್ಕೆ ಹರಡುತ್ತದೆ.

ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್ಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್ಗಳು ಕೇಳುವ ವಲಯ

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

ದೂರದ ಕ್ಲೈಂಟ್ಗಳು ನಿಜವಾಗಿ ಕೇಳುವ ವಲಯದಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಪ್ರಕಟಿಸಿ. ಕೇವಲ LAN resolver ಸೇವೆ ನೀಡುವ ವಲಯದ ದಾಖಲೆ, ತಳ್ಳಲಾದ resolver ಬೇರೆಡೆ ತೋರಿಸುವ ಕ್ಲೈಂಟ್ಗೆ ಕಾಣುವುದಿಲ್ಲ, ಮತ್ತು ತಪ್ಪು ವಲಯಕ್ಕೆ ಹೆಚ್ಚು ದಾಖಲೆ ಸೇರಿಸಿದರೆ ಅದು ಎಂದೂ ಸರಿಯಾಗುವುದಿಲ್ಲ. ಏನನ್ನಾದರೂ ಸೇರಿಸುವ ಮೊದಲು ತಳ್ಳಲಾದ DNS ಆಯ್ಕೆ ಮತ್ತು ಹುಡುಕಾಟ ಡೊಮೇನ್ ಅನ್ನು ಖಚಿತಪಡಿಸಿ.

ಹೊಸ ಸಂಪರ್ಕದಲ್ಲಿ ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು

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

ಬೇರೆ ಸಾಮಾನ್ಯ ಹೆಸರಿನಲ್ಲಿ ಮತ್ತೆ ನೀಡಿದ ಪ್ರಮಾಣಪತ್ರ ತನ್ನ overrideಗೆ ಹೊಂದುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಕ್ರಿಯಾತ್ಮಕ poolಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಯಾವುದೇ ಗುರುತು ಬದಲಾವಣೆಯ ನಂತರ ಅದನ್ನು ನಿರೀಕ್ಷಿಸಿ.

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