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

ಎರಡು ಹಂಚಿಕೆದಾರರು, ಒಂದು ವಿಳಾಸ ಸ್ಥಳ

LAN ನ DHCP ಸರ್ವರ್ಗೆ ತಾನು ಯಾವ ವಿಳಾಸಗಳನ್ನು ಯಾವ MAC ವಿಳಾಸಕ್ಕೆ ಗುತ್ತಿಗೆ ನೀಡಿದೆ ಎಂದು ತಿಳಿದಿದೆ, ಮತ್ತು ಅವುಗಳನ್ನು ARP ನಿಂದ ರಕ್ಷಿಸುತ್ತದೆ. VPN ಸರ್ವರ್ಗೆ ತನ್ನದೇ ಪೂಲ್ ಇದೆ ಮತ್ತು ಆ ಗುತ್ತಿಗೆಗಳ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. ಎರಡೂ ತಪ್ಪಲ್ಲ; ಅವುಗಳನ್ನು ಎಂದಿಗೂ ಪರಸ್ಪರ ಪರಿಚಯಿಸಲಿಲ್ಲ.

VPN ಸರ್ವರ್ LAN ಪೂಲ್‌ನಿಂದ ನೀಡುವ ವಿಳಾಸ ಈಗಾಗಲೇ ಮುದ್ರಕದ್ದಾಗಿರಬಹುದು. ಈಗ ಎರಡು ಸಾಧನಗಳು ಒಂದೇ ಪೂರ್ವಪ್ರತ್ಯಯದಲ್ಲಿ ಒಂದು ವಿಳಾಸವನ್ನು ಕೇಳುತ್ತವೆ, ಮತ್ತು ಸ್ವಿಚ್‌ನ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಕೋಷ್ಟಕ ಯಾರು ಉತ್ತರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಇದು ಜನರು ಮೊದಲು ಎದುರಿಸುವ ವೈಫಲ್ಯ: ಯಶಸ್ವಿಯಾಗಿ ಸಂಪರ್ಕಗೊಂಡು ನಂತರ ತಪ್ಪು ಯಂತ್ರವನ್ನು ತಲುಪುವ ಕ್ಲೈಂಟ್, ಅಥವಾ ಸರಿಯಾದ ಯಂತ್ರವನ್ನು ಮಧ್ಯೆ ಮಧ್ಯೆ ತಲುಪುವ ಕ್ಲೈಂಟ್.

ರೌಟರ್ ಏಕೆ VPN ವಿಳಾಸಗಳನ್ನು ಹಂಚುವುದಿಲ್ಲ

DHCP ಅನ್ವೇಷಣೆ ಒಂದು ಪ್ರಸಾರ, ಮತ್ತು ಪ್ರಸಾರಗಳು ರೌಟ್ ಆದ ಗಡಿಯಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ. ವಿನ್ಯಾಸವು ಸುರಂಗವನ್ನು ಸೇತುವೆ ಮಾಡದಿದ್ದರೆ ಅಥವಾ ಹೊಂದಿಕೆಯಾದ ಅಧಿಕಾರವಿರುವ DHCP ರಿಲೇ ಚಲಾಯಿಸದಿದ್ದರೆ, ಕ್ಲೈಂಟ್‌ನ ವಿನಂತಿ LAN ಸರ್ವರ್‌ನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ VPN ಸರ್ವರ್ ಸ್ವತಃ ವಿಳಾಸವನ್ನು ನಿಗದಿಪಡಿಸುತ್ತದೆ: ಸರ್ವರ್ ಸಂರಚನೆಯಲ್ಲಿ ಒಂದು ಪೂಲ್, WireGuard ಸಂಯೋಜನೆಯಲ್ಲಿ ಪ್ರತಿ ಪೀರ್‌ಗೆ ಒಂದು ವಿಳಾಸ, ಅಥವಾ IKEv2 ನಿಯೋಜನೆಯಲ್ಲಿ ದೃಢೀಕರಣ ಪದರವು ತಳ್ಳುವ ವಿಳಾಸ. ಈ ಕಾರ್ಯವಿಧಾನಗಳು LAN ನ ಗುತ್ತಿಗೆ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಸ್ವತಂತ್ರ, ಮತ್ತು ಅದಕ್ಕೇ ಅವುಗಳಿಗೆ ತಮ್ಮದೇ ಶ್ರೇಣಿ ಬೇಕು.

ಅದೇ ತರ್ಕವು DHCP ವ್ಯಾಪ್ತಿಯನ್ನು ಬದಲಿಸಿದರೆ ಎಂದಿಗೂ ವಿಳಾಸ ಪಡೆಯದ VPN ಕ್ಲೈಂಟ್ ಏಕೆ ಸರಿಯಾಗುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ LAN ಸರ್ವರ್‌ನ್ನು ಕೇಳುತ್ತಿಲ್ಲ, ಮತ್ತು ವ್ಯಾಪ್ತಿಯ ಯಾವುದೇ ಸಂಪಾದನೆ ಅದನ್ನು ಕೇಳುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.

ಅತಿಕ್ರಮಣವು ನಿಧಾನ ನೆಟ್ವರ್ಕ ಆಗಿ ಅಲ್ಲ, ಸಂಘರ್ಷವಾಗಿ ಕಾಣುತ್ತದೆ

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

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

ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆ

ಸ್ವಚ್ಛ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಪೂಲ್ ಇದ್ದರೂ, LAN ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಕ್ಲೈಂಟ್‌ಗೆ ಹೇಗೆ ಉತ್ತರಿಸಬೇಕು ಎಂದು ತಿಳಿದಿರಬೇಕು. ಅವುಗಳ ಪೂರ್ವನಿಗದಿ ಗೇಟ್‌ವೇ ರೌಟರ್, ಮತ್ತು ರೌಟರ್‌ಗೆ ಪೂಲ್‌ಗಾಗಿ VPN ಸರ್ವರ್‌ನ್ನು ತೋರಿಸುವ ಮಾರ್ಗ ಬೇಕು, ವಿನ್ಯಾಸವು ಬದಲಿಗೆ ಕ್ಲೈಂಟ್ ಸಂಚಾರವನ್ನು ಅನುವಾದಿಸದಿದ್ದರೆ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಓದಿ. ಗೇಟ್‌ವೇಯಲ್ಲಿ ಕ್ಲೈಂಟ್ ವಿಳಾಸಕ್ಕೆ ಕರ್ನಲ್ ಯಾವ ಇಂಟರ್ಫೇಸ್ ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿ; ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ LAN ವಿಳಾಸಕ್ಕೆ ಅದು ಯಾವ ಮಾರ್ಗ ಬಳಸುತ್ತದೆ ಎಂದು ಕೇಳಿ.

ಈ ಆದೇಶಗಳು ಗೇಟ್‌ವೇಯಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ನಿರ್ಧಾರ ಮತ್ತು ನಕಲನ್ನು ಬಯಲು ಮಾಡುವ ನೆರೆಯ ನಮೂದುಗಳನ್ನು ತೋರಿಸುತ್ತವೆ:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

ಮೊದಲ ಆದೇಶವು ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಉತ್ತರಿಸಿದರೆ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇದೆ. ಅದು LAN ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಉತ್ತರಿಸಿದರೆ, ರೌಟರ್ ಕ್ಲೈಂಟ್ ತಂತಿಯ ಮೇಲಿದೆ ಎಂದು ನಂಬಿ ಅದಕ್ಕಾಗಿ ARP ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ.

ಸೇತುವೆ ವಿನ್ಯಾಸಗಳು ಇವೆ, ಆದರೆ ಅವನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು

ಸುರಂಗವನ್ನು LAN ಗೆ ಸೇತುವೆ ಮಾಡುವುದು ನಿಜವಾದ ವಿನ್ಯಾಸ, ಕ್ಲೈಂಟ್‌ಗಳು ಪ್ರಸಾರವನ್ನು ಪಡೆಯಬೇಕಾದಾಗ ಅಥವಾ ಒಂದು ವಿಭಾಗವನ್ನು ಊಹಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಅವನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕಾದಾಗ ಬಳಸಲಾಗುತ್ತದೆ. ಅದು ಸರ್ವರ್‌ಗೆ ಆ ಸೇತುವೆ ವರ್ತನೆ ಮತ್ತು ಅದರೊಂದಿಗೆ ಬರುವ ವಿಳಾಸ ನಿರ್ವಹಣೆ ಇರಬೇಕೆಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ.

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

ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನಿಜವಾಗಿಯೂ ವಿಭಾಗ ಬೇಕಾಗಿಲ್ಲದಿದ್ದರೆ ಪ್ರತ್ಯೇಕ ಪೂಲ್ ಜೊತೆ ಮೂರನೇ ಪದರವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ, ಮತ್ತು ಪೂಲ್ ಅನ್ನು ದಾಖಲಿಸಿ, ಮುಂದಿನ ನಿರ್ವಾಹಕರು ಸ್ವಚ್ಛತೆಗಾಗಿ DHCP ಶ್ರೇಣಿಯನ್ನು ಮತ್ತೆ ಬಳಸದಂತೆ.

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