ಸ್ಥಿರ VPN ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕಾಗಿ RADIUS Framed-IP-Address

RADIUS ನಿರ್ದಿಷ್ಟ ಬಳಕೆದಾರರಿಗೆ ವಿಳಾಸದೊಂದಿಗೆ ಉತ್ತರಿಸಬಹುದು; ಸುರಂಗವು ಅದನ್ನು ನಿಜವಾಗಿ ಪಡೆಯುತ್ತದೆಯೇ ಎಂಬುದು ಗೇಟ್‌ವೇ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಸ್ಥಿರ ವಿಳಾಸದ ಹೆಚ್ಚಿನ ಯೋಜನೆಗಳು ಹಿಂತಿರುಗಿಸಿದ ಮತ್ತು ಅನ್ವಯಿಸಿದ ನಡುವಿನ ಈ ಕಂದರದಲ್ಲೇ ವಿಫಲವಾಗುತ್ತವೆ. ಪರೀಕ್ಷಾ ಉತ್ತರದಲ್ಲಿನ ಗುಣಲಕ್ಷಣವು ಸರ್ವರ್ ಅದನ್ನು ಕಳುಹಿಸಬಲ್ಲದು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ದೂರಸ್ಥ ಪ್ರವೇಶ ಸೇವೆ ಅದನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ ಎಂದಲ್ಲ. ಕೆಳಗಿನ ಕ್ರಮವು ವಿಳಾಸವು ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳಿಗೆ ತಲುಪುವ ಮೊದಲು ಎರಡೂ ಭಾಗಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.

ವಿಳಾಸ ಯಾವ ಪದರದ್ದು ಎಂದು ನಿರ್ಧರಿಸಿ

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

RFC 2865 Framed-IP-Address ಅನ್ನು ಬಳಕೆದಾರರಿಗೆ ಸಂರಚಿಸಬೇಕಾದ ವಿಳಾಸ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ಗೇಟ್‌ವೇ ಅದನ್ನು ಗೌರವಿಸಲು ಸಿದ್ಧವಿದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆದ್ಯತೆಯ ಬಗ್ಗೆ ಅಧಿಕಾರ ತಯಾರಕರ ದಾಖಲೆಗಳಿಗೆ ಇದೆ, ಗುಣಲಕ್ಷಣದ ವ್ಯಾಖ್ಯಾನಕ್ಕಲ್ಲ.

ಪರೀಕ್ಷಾ ವಿನಂತಿ ಕಳುಹಿಸಿ ಮತ್ತು ಉತ್ತರವನ್ನು ಓದಿ

ಮೊದಲು ಸರ್ವರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ಕಾಣೆಯಾದ ಗುಣಲಕ್ಷಣವನ್ನು ಗೇಟ್‌ವೇ ಸಮಸ್ಯೆ ಎಂದು ತಪ್ಪಾಗಿ ಭಾವಿಸಬಹುದು. radtest ಒಂದು Access-Request ಕಳುಹಿಸಿ ಹಿಂತಿರುಗಿ ಬರುವ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಮುದ್ರಿಸುತ್ತದೆ.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Access-Accept ನಲ್ಲಿ Framed-IP-Address ಹುಡುಕಿ ಮತ್ತು ಮೌಲ್ಯವು ಉದ್ದೇಶಿಸಿದ್ದೇ ಹೊರತು ಬ್ಯಾಕಪ್ ನಿಯಮದಿಂದ ಬಂದ ಪೂಲ್ ವಿಳಾಸವಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಗುಣಲಕ್ಷಣ ಇಲ್ಲದಿದ್ದಾಗ, ಬಳಕೆದಾರ ನಮೂದು ಅಥವಾ ಅಧಿಕಾರ ನೀತಿ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಗೇಟ್‌ವೇ ಹೊಂದಾಣಿಕೆ ಸರ್ವರ್ ಎಂದೂ ಕಳುಹಿಸದ್ದನ್ನು ಒದಗಿಸಲಾರದು. ಉತ್ತರವನ್ನು ನಿರ್ದಿಷ್ಟ ನಿಯಮಕ್ಕೆ ಜೋಡಿಸುವುದು ಕಷ್ಟವಾದರೆ ಸರ್ವರ್ ಡೀಬಗ್ ಮೋಡ್‌ನಲ್ಲಿ ಚಲಿಸುತ್ತಿರುವಾಗ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಹಂಚಿದ ರಹಸ್ಯವನ್ನು ಶೆಲ್ ಇತಿಹಾಸ ಮತ್ತು ಟಿಕೆಟ್‌ಗಳಿಂದ ದೂರವಿಡಿ, ಏಕೆಂದರೆ ಮೇಲಿನ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಲಾಗಿನ್ ರುಜುವಾತು ಅಲ್ಲ.

ಗೇಟ್‌ವೇ ಮೌಲ್ಯವನ್ನು ಗೌರವಿಸಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ

ಸರಿಯಾದ ಉತ್ತರ ಒಪ್ಪಂದದ ಅರ್ಧ ಭಾಗ ಮಾತ್ರ. ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಕಾಣುವ ವಿಳಾಸವೇ ಮುಖ್ಯವಾದ ವೀಕ್ಷಣೆ, ಮತ್ತು ಅದನ್ನು ಗೇಟ್‌ವೇ ಸಂರಚನೆಯಿಂದ ಊಹಿಸುವ ಬದಲು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಓದಲಾಗುತ್ತದೆ.

ip -4 addr show tun0

ಆ ವಿಳಾಸವನ್ನು Access-Accept ನ ಗುಣಲಕ್ಷಣದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಹೊಂದಿಕೆಯಾಗದಿರುವುದು ಎಂದರೆ ಗೇಟ್‌ವೇ ಮೌಲ್ಯವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದೆ ಅಥವಾ ಮತ್ತೆ ಬರೆದಿದೆ, ಇದು ಮೊದಲ ವಿಭಾಗದ ಆದ್ಯತೆಯ ಪ್ರಶ್ನೆಯನ್ನು ಮತ್ತೆ ತೆರೆಯುತ್ತದೆ. ಇನ್ನೊಮ್ಮೆ ಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ಮೊದಲ ಪ್ರಯತ್ನದಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುವ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಹಳೆಯ ಅವಧಿ ಅಥವಾ ಹಿಂದಿನ ಸಂಪರ್ಕ ಇನ್ನೂ ಹಿಡಿದಿರುವ ಗುತ್ತಿಗೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಗೇಟ್‌ವೇ ಆವೃತ್ತಿ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಫಲಿತಾಂಶದ ಪಕ್ಕದಲ್ಲಿ ದಾಖಲಿಸಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ವರ್ತನೆ ಆವೃತ್ತಿ-ನಿರ್ದಿಷ್ಟವೇ ಎಂದು ತಿಳಿಯಲು.

ಏಕಕಾಲಿಕತೆ ಮತ್ತು ರದ್ದತಿಗೆ ಯೋಜನೆ ಹಾಕಿ

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

ಸ್ಥಿರ ವಿಳಾಸೀಕರಣ ನಿಯಮಗಳು ಮತ್ತು ದಾಖಲೆಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ, ಆದರೆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಯಾರು ರಚಿಸಿದರು ಎಂದು ಎಂದೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಆ ವಿಳಾಸ ನಂತರ ಇನ್ನೊಂದು ಅವಧಿಗೆ ಹೋದಾಗ ದೃಢೀಕರಣ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಅಧಿಕಾರ ಇನ್ನೂ ಮುಖ್ಯ.