RRAS DHCP: ಹೊಸ ವಿಳಾಸವೋ ಅಥವಾ ಕೇವಲ ಸಂರಚನಾ ಆಯ್ಕೆಗಳೋ?

ಕ್ಯಾಪ್ಚರ್ನಲ್ಲಿ DHCPACK ಅನ್ನು VPN ಕ್ಲೈಂಟ್ ತನ್ನ ವಿಳಾಸವನ್ನು DHCP ನಿಂದ ಪಡೆದುಕೊಂಡ ಸಾಕ್ಷಿ ಎಂದು ಓದುವುದು ತಪ್ಪು. ಸಾಮಾನ್ಯವಾಗಿ ಅದು ಯಾವುದೋ DHCP ಸಂದೇಶಕ್ಕೆ ಉತ್ತರ ಬಂದಿದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. Windows RRAS ತನ್ನದೇ ಸ್ಥಿರ ಪೂಲ್ನಿಂದ ಸೆಷನ್ ವಿಳಾಸಗಳನ್ನು ನೀಡಬಹುದು, ಆಗಲೂ DHCP ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ಗೆ ಆಯ್ಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಯಾವ ಕೆಲಸ ನಡೆಯುತ್ತಿತ್ತು ಎಂಬುದನ್ನು ವಿನಂತಿಯ ಪ್ರಕಾರವೇ ಹೇಳುತ್ತದೆ.

ಒಂದೇ ಸಂದೇಶ ಪ್ರಕಾರವನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಎರಡು ಕೆಲಸಗಳು

DHCP ಎರಡು ಪ್ರತ್ಯೇಕ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅವು ಸಂದೇಶ ಪ್ರಕಾರಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ. ಒಂದು ವಿಳಾಸ ಮತ್ತು ಗುತ್ತಿಗೆ ಹಂಚುವುದು. ಇನ್ನೊಂದು ಈಗಾಗಲೇ ವಿಳಾಸವಿರುವ ಹೋಸ್ಟ್ಗೆ ಸಂರಚನೆಯನ್ನು ತಲುಪಿಸುವುದು, ಅದನ್ನು RFC 2131 DHCPINFORM ಎಂದು ಕರೆಯುತ್ತದೆ. ಎರಡನೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಉತ್ತರ ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಗುತ್ತಿಗೆ ಅವಧಿಯನ್ನು ಒಳಗೊಂಡಿರುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ACK ಉತ್ತರದ ಸಾಕ್ಷಿ, ಹಂಚಿಕೆಯ ಸಾಕ್ಷಿಯಲ್ಲ. ಯಾವ ಪ್ರಶ್ನೆ ಕೇಳಲಾಯಿತು ಎಂಬುದನ್ನು ಅದಕ್ಕಿಂತ ಹಿಂದಿನ ಸಂದೇಶ ನಿರ್ಧರಿಸುತ್ತದೆ. ಮೊದಲು ವಿನಂತಿ ಸಾಲನ್ನು ಓದಿ, ಉಳಿದ ಜಾಡು ಸಾಮಾನ್ಯವಾಗಿ ತಾನೇ ವಿವರಿಸಿಕೊಳ್ಳುತ್ತದೆ.

RRAS ವಿಳಾಸವನ್ನು ಎಲ್ಲಿಂದ ಪಡೆಯುತ್ತದೆ

RRAS ತನ್ನ ಸಂರಚಿತ IPv4 ಹಂಚಿಕೆ ವಿಧಾನದ ಮೂಲಕ VPN ವಿಳಾಸದ ನಿರ್ಣಯವನ್ನು ಹೊಂದಿದೆ: DHCP ಸರ್ವರ್ ಅಥವಾ ಸ್ಥಿರ ವಿಳಾಸ ಪೂಲ್. ಪೂಲ್ ಸ್ಥಿರವಾಗಿದ್ದರೆ ಪೂಲೇ ಹಂಚುವವರು, ಮತ್ತು ಬೇರೆ DHCP ಸರ್ವರ್ನಲ್ಲಿನ ಕಾಯ್ದಿರಿಸುವಿಕೆಗೆ ಆ ಸೆಷನ್ನಲ್ಲಿ ಯಾವುದೇ ಹೇಳಿಕೆಯಿಲ್ಲ. ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳು ಒಂದೇ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಒಂದು ಇನ್ನೊಂದನ್ನು ನಿಯಂತ್ರಿಸದೆ ಜೊತೆಯಾಗಿ ಇರಬಹುದು.

Get-Command -Module RemoteAccess *IPAddress*

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

ಬಳಕೆದಾರ ವರ್ಗ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ

DHCP ಬಳಕೆದಾರ ವರ್ಗ ಎಂಬುದು ಕ್ಲೈಂಟ್ ಕಳುಹಿಸುವ ಸ್ಟ್ರಿಂಗ್, ದೃಢೀಕೃತ ಗುಂಪು ಸದಸ್ಯತ್ವವಲ್ಲ. ಕ್ಲೈಂಟ್ ಒಂದನ್ನು ಕಳುಹಿಸಿ ಸರ್ವರ್ ಅದರ ಮೇಲೆ ನೀತಿಯನ್ನು ಹೊಂದಿಸಿದರೂ, ಆ ಲೇಬಲ್ ಸ್ಟ್ರಿಂಗ್ ತಲುಪಿದುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. RFC 3004 ಆಯ್ಕೆ ವರ್ಗದ ಮೇಲಿನ ಹಕ್ಕನ್ನು ದೃಢೀಕರಿಸುವುದಿಲ್ಲ ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತದೆ.

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

ACK ಅಲ್ಲ, ಸಾಕ್ಷ್ಯಗಳನ್ನು ಹೋಲಿಸಿ

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

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

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