ಸ್ಥಿರ VPN IP: RADIUS Framed-IP-Address ಅಥವಾ ಪೂಲ್ ಕಾಯ್ದಿರಿಸುವಿಕೆ

VPN ಕ್ಲೈಂಟ್‌ಗೆ ಸ್ಥಿರ ಆಂತರಿಕ ವಿಳಾಸವನ್ನು ಮೂರು ಸ್ಥಳಗಳು ಹಿಡಿದಿಡಬಹುದು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಅದನ್ನು ಹೊಂದಿರಬೇಕು. RADIUS ವಿಳಾಸವನ್ನು Access-Accept ನಲ್ಲಿ ಹಿಂತಿರುಗಿಸಬಹುದು, ಗೇಟ್‌ವೇ ಖಾತೆಗೆ ಸ್ಥಿರ ಮ್ಯಾಪಿಂಗ್ ಇಟ್ಟುಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅಡಾಪ್ಟರ್ ಅನ್ನು ಕೈಯಿಂದ ಸೆಟ್ ಮಾಡಬಹುದು. ಮೊದಲ ಎರಡು ನೀತಿ, ಮತ್ತು ಮೂರನೆಯದು ಗೇಟ್‌ವೇ ನಿರ್ಲಕ್ಷಿಸಲು ಅಥವಾ ಮೇಲೆಬರೆಯಲು ಸ್ವತಂತ್ರವಾಗಿರುವ ಸ್ಥಳೀಯ ಊಹೆ. ಮೊದಲ ಎರಡರ ನಡುವಿನ ಆಯ್ಕೆಯೇ ನಿಜವಾದ ನಿರ್ಧಾರ, ಮತ್ತು ಅದು ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶ ಸರ್ವರ್ ನಿಜವಾಗಿ ಏನನ್ನು ಅಳವಡಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಸ್ಥಿರ ವಿಳಾಸ ಇರಬಹುದಾದ ಮೂರು ಸ್ಥಳಗಳು

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

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

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

RADIUS ಉತ್ತರ ಏನನ್ನು ಭರವಸೆ ನೀಡಬಹುದು ಮತ್ತು ಏನನ್ನು ನೀಡಲಾರದು

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

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

ಗೇಟ್‌ವೇ ನಿರ್ಲಕ್ಷಿಸುವ ಉತ್ತರವು ಎಂದಿಗೂ ಕಳುಹಿಸದ ಉತ್ತರದಂತೆಯೇ ಕಾಣುತ್ತದೆ. Access-Accept ಮತ್ತು ಸೆಷನ್ ವಿಳಾಸವನ್ನು ಪಕ್ಕಪಕ್ಕ ಓದುವುದೇ ಎರಡು ಸಂದರ್ಭಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಏಕೈಕ ದಾರಿ.

ನೀವು ಈಗಾಗಲೇ ರೂಟ್ ಮಾಡುವ ಪೂಲ್ ಒಳಗೆ ವಿಳಾಸವನ್ನು ಕಾಯ್ದಿರಿಸಿ

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

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗಗಳು ನಿಗದಿಯಷ್ಟೇ ಗಮನಕ್ಕೆ ಅರ್ಹ. ಗೇಟ್‌ವೇಗೆ ಪೂಲ್‌ಗೆ ಮಾರ್ಗ ಬೇಕು, ಆಂತರಿಕ ರೂಟರ್‌ಗಳಿಗೆ ಗೇಟ್‌ವೇಗೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಬೇಕು, ಮತ್ತು ಸ್ಥಿರ ವಿಳಾಸವು ಎರಡನ್ನೂ ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತದೆ. ಒಂದು ಕ್ಲೈಂಟ್ ಕೆಲಸ ಮಾಡಿ ಉಳಿದವೆಲ್ಲ ವಿಫಲವಾದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಪೂಲ್ ಮಾರ್ಗ ಇದೆ ಆದರೆ ಕಾಯ್ದಿರಿಸಿದ ವಿಳಾಸದ ಹೋಸ್ಟ್ ಮಾರ್ಗ ಇಲ್ಲ ಎಂದರ್ಥ.

ಕಾಯ್ದಿರಿಸುವಿಕೆಯನ್ನು ನಂಬುವ ಮೊದಲು ಉತ್ತರವನ್ನು ಪರೀಕ್ಷಿಸಿ

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

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

ಗುಣಲಕ್ಷಣವಿಲ್ಲದ Access-Accept ಎಂದರೆ ಸರ್ವರ್ ನಮೂದನ್ನು ಹೊಂದಿಸಲಿಲ್ಲ ಅಥವಾ ಗುಣಲಕ್ಷಣವನ್ನು ಆ ಬಳಕೆದಾರರಿಗೆ ಅನ್ವಯಿಸಲಿಲ್ಲ. ಗುಣಲಕ್ಷಣದೊಂದಿಗೆ Access-Accept ಮತ್ತು ಇನ್ನೂ ಪೂಲ್ ವಿಳಾಸ ಪಡೆಯುವ ಕ್ಲೈಂಟ್ ಎಂದರೆ ಗೇಟ್‌ವೇ ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸಿತು. Access-Reject ನಿಮ್ಮನ್ನು ರುಜುವಾತುಗಳಿಗೆ ಅಥವಾ ಗುಂಪು ನೀತಿಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಈ ಯಾವುದೇ ಫಲಿತಾಂಶಗಳನ್ನು ಕ್ಲೈಂಟ್ ಅಡಾಪ್ಟರ್ ಸಂಪಾದಿಸಿ ಡೀಬಗ್ ಮಾಡಬಾರದು.

ಮರುಸಂಪರ್ಕದ ನಂತರ ಮತ್ತು ಇನ್ನೊಂದು ಸಾಧನದಿಂದ ಎರಡನೇ ಲಾಗಿನ್ ನಂತರ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಮೊದಲ ಸೆಷನ್‌ಗೆ ಮಾತ್ರ ಉಳಿಯುವ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಸಂಭವಿಸಲು ಕಾಯುತ್ತಿರುವ ಪೂಲ್ ಸಂಘರ್ಷ, ಮತ್ತು ಆಡಿಟ್ ಸಮಯದಲ್ಲಿ ಕಂಡುಹಿಡಿಯುವುದಕ್ಕಿಂತ ಈಗ ಕಂಡುಹಿಡಿಯುವುದು ಅಗ್ಗ.

ಒಬ್ಬ ಮಾಲೀಕರನ್ನು ಆಯ್ಕೆಮಾಡಿ ಮತ್ತು ಬರೆಯಿರಿ

ಗೇಟ್‌ವೇ ಚೌಕಟಿತ ವಿಳಾಸಗಳನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಅನ್ವಯಿಸಿದರೆ, RADIUS ನಿಗದಿಯನ್ನು ಹೊಂದಲಿ ಮತ್ತು ಅದೇ ಖಾತೆಗೆ ಯಾವುದೇ ಸ್ಥಿರ ಮ್ಯಾಪಿಂಗ್ ತೆಗೆದುಹಾಕಿ. ಇಲ್ಲದಿದ್ದರೆ, ಗೇಟ್‌ವೇ ಅದನ್ನು ಹೊಂದಲಿ ಮತ್ತು ಉತ್ತರದಿಂದ ಗುಣಲಕ್ಷಣವನ್ನು ತೆಗೆದುಹಾಕಿ, ಇದರಿಂದ ಎರಡು ಮೂಲಗಳು ಭಿನ್ನವಾಗಿರಲಾರವು. ಪ್ರತಿಯೊಂದೂ ಬಹುತೇಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಎರಡನ್ನೂ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಭವಿಷ್ಯದ ಸೆಷನ್ ತಪ್ಪು ವಿಳಾಸದೊಂದಿಗೆ ಮತ್ತು ಸ್ಪಷ್ಟ ಕಾರಣವಿಲ್ಲದೆ ಇರುವುದನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ.

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