VPN ಮೂಲಕ DHCP: ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಸೇತುವೆ ಮಾಡುವುದೋ ಅಥವಾ ರಿಲೇ ಮಾಡುವುದೋ?

ಸುರಂಗದ ಆಚೆ ಬದಿಯಲ್ಲಿರುವ ಹೊಸ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗೆ ವಿಳಾಸ ಸಿಗುವುದಿಲ್ಲ, ಆದರೆ ಅದೇ ಲ್ಯಾಪ್‌ಟಾಪ್ ಪ್ರಧಾನ ಕಚೇರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಸಾಮಾನ್ಯ ಮೊದಲ ಊಹೆ ಎಂದರೆ ಸುರಂಗ DHCP ಅನ್ನು ತಡೆಯುತ್ತಿದೆ. ಹೆಚ್ಚಾಗಿ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್‌ಗೆ ಎಂದೂ ಮಾರ್ಗವೇ ಇರಲಿಲ್ಲ: ಕಾನ್ಫಿಗರ್ ಮಾಡದ ಕ್ಲೈಂಟ್ 255.255.255.255 ಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಸಾಮಾನ್ಯ IP ರೌಟರ್ ಆ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವುದಿಲ್ಲ. ಸುರಂಗವು ರೂಟ್ ಮಾಡಿದ ಸುರಂಗ ಮಾಡುವುದನ್ನೇ ಮಾಡುತ್ತಿದೆ.

ಎರಡು ವಿನ್ಯಾಸಗಳು ಅದನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಮತ್ತು ಅವು ಸಮಾನವಲ್ಲ. ಒಂದು ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಒಯ್ಯುತ್ತದೆ; ಇನ್ನೊಂದು ವಿನಂತಿಯನ್ನು ರಿಲೇ ಮಾಡುತ್ತದೆ.

ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಎಂದೂ ರೌಟರ್ ದಾಟುವುದಿಲ್ಲ

ವಿಳಾಸವಿಲ್ಲದ DHCPv4 ಕ್ಲೈಂಟ್ 0.0.0.0 ನಿಂದ ಸೀಮಿತ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ವಿಳಾಸಕ್ಕೆ UDP ಪೋರ್ಟ್ 67 ಮತ್ತು 68 ರಲ್ಲಿ ಕಳುಹಿಸುತ್ತದೆ. ಆ ಪ್ಯಾಕೆಟ್ ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ತನ್ನ ಲಿಂಕ್‌ನಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ಅದನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವ ರೌಟರ್ ತಾನು ಸೇವೆ ಮಾಡುವ ಪ್ರತಿ ವಿಭಾಗವನ್ನೂ ಪ್ರವಾಹದಿಂದ ತುಂಬಿಸುತ್ತಿತ್ತು.

ಆದ್ದರಿಂದ ರೂಟ್ ಮಾಡಿದ ಸೈಟ್-ಟು-ಸೈಟ್ ಸುರಂಗವು ರಿಲೇಯನ್ನು ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ಅದು ಕ್ಲೈಂಟ್‌ನ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೇ ಫೈರ್‌ವಾಲ್ ನಿಯಮವೂ ಅದನ್ನು ಮಾಡಿಸಲಾರದು.

ಸೇತುವೆ ಮಾಡಿದ ಸುರಂಗ ನಿಜವಾಗಿ ಏನನ್ನು ವಿಸ್ತರಿಸುತ್ತದೆ

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

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

ಇದು ವಿಳಾಸ ಒದಗಿಸುವುದಕ್ಕಿಂತ ದೊಡ್ಡ ನಿರ್ಧಾರ, ಮತ್ತು ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

ಬದಲಿಗೆ ವಿನಂತಿಯನ್ನು ರಿಲೇ ಮಾಡಿ

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

ಉದಾಹರಣೆಯಾದ ದೂರದ ಕಚೇರಿಗೆ, ರಿಲೇ ಕಚೇರಿಯ LAN ನಲ್ಲಿ ಇರುತ್ತದೆ ಮತ್ತು ಸರ್ವರ್‌ಗೆ ಸೈಟ್ VPN ಮೂಲಕ ತಲುಪಲಾಗುತ್ತದೆ. ಆ ಕಚೇರಿಗೆ ಸ್ಕೋಪ್, ರಿಲೇ ಮತ್ತು ಸರ್ವರ್‌ನ ಗುರುತುಗಳು, ಮತ್ತು ಸಂಪೂರ್ಣ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಸುರಂಗದ ಮೂಲಕ UDP 67 ಗೆ ಅನುಮತಿ ನೀಡುವುದು ಯಾವ ಪೂಲ್ ಬಳಸಬೇಕೆಂದು ಸರ್ವರ್‌ಗೆ ಹೇಳುವುದಿಲ್ಲ.

ಮುಂದೆ ಕಳುಹಿಸುವ ಆದರೆ ಎಂದೂ ಉತ್ತರ ಪಡೆಯದ ರಿಲೇ ಸಾಮಾನ್ಯವಾಗಿ ಹಿಂತಿರುಗುವ ಮಾರ್ಗದ ಸಮಸ್ಯೆ. ಸ್ಕೋಪ್ ಬದಲಿಸುವ ಮೊದಲು ರಿಲೇ ವಿಳಾಸಕ್ಕೆ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ.

DHCP ಅನ್ನು ARP ನಿಂದ ಮತ್ತು ಸುರಂಗದ ವಿಳಾಸಗಳಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ

DHCP UDP/IP ಮೇಲೆ ಸಾಗುತ್ತದೆ. Ethernet ನಲ್ಲಿ, ಹೋಸ್ಟ್ ARP ಬಳಸಿಯೂ ಅಭ್ಯರ್ಥಿ ವಿಳಾಸ ಈಗಾಗಲೇ ಬಳಕೆಯಲ್ಲಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬಹುದು. ಆ ಘರ್ಷಣೆ ಪರಿಶೀಲನೆ ಪ್ರತ್ಯೇಕ ಲಿಂಕ್-ಸ್ಥಳೀಯ ಕ್ರಿಯೆ, DHCP ಸಂದೇಶಗಳ ಸಾಗಣೆ ಅಲ್ಲ. DHCP ಮೂಲತಃ ARP ಎಂದು ಹೇಳುವುದು ತಪ್ಪು; ಎರಡೂ ಎಂದೂ ಸಂಬಂಧವಿಲ್ಲ ಎಂದು ಹೇಳುವುದು ತುಂಬಾ ವಿಶಾಲ.

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

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