LAN ವಿಳಾಸವಿರುವ VPN ಕ್ಲೈಂಟ್ LAN ನಲ್ಲಿಲ್ಲ

ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, 10.50.0.200 ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಎರಡೂ ಸಂಖ್ಯೆಗಳು ಒಂದೇ /24 ನಲ್ಲಿದ್ದರೂ 10.50.0.20 ನಲ್ಲಿರುವ ಸರ್ವರ್ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸಂರಚನೆಯ ಹಿಂದಿನ ನಂಬಿಕೆ ಎಂದರೆ LAN ಪೂರ್ವಪ್ರತ್ಯಯದ ವಿಳಾಸ ಕ್ಲೈಂಟ್ ಅನ್ನು LAN ನ ಭಾಗವಾಗಿಸುತ್ತದೆ. ಅದು ಮಾಡುವುದಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಲಿಂಕ್‌ನಲ್ಲಿದೆ, ಸರ್ವರ್ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಳೀಯ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಮತ್ತು ಕಾಣೆಯಾದ ಭಾಗವು ಯಾರೂ ಕಳುಹಿಸದ ನೆರೆಹೊರೆಯ ಉತ್ತರವಾಗಿದೆ.

ಪುರಾಣ: ಒಂದೇ ಪೂರ್ವಪ್ರತ್ಯಯ ಎಂದರೆ ಒಂದೇ ವಿಭಾಗ

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

ಸರ್ವರ್ 10.50.0.200 ಗೆ ಕಳುಹಿಸುವಾಗ, ಅದು ಗಮ್ಯಸ್ಥಾನವನ್ನು ತನ್ನ ಮಾಸ್ಕ್‌ನೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ, ವಿಳಾಸವನ್ನು on-link ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಹೊಂದಿರುವ ಹಾರ್ಡ್‌ವೇರ್ ವಿಳಾಸವನ್ನು ಸ್ಥಳೀಯ ವಿಭಾಗದಿಂದ ಕೇಳುತ್ತದೆ. ಆ ವಿನಂತಿ Ethernet ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಹೊರಹೋಗುತ್ತದೆ, ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಅದನ್ನು ಕೇಳಲು ಅಲ್ಲಿಲ್ಲ.

ಕ್ಲೈಂಟ್‌ನ ಸಂರಚನೆಯಲ್ಲಿ ಏನೂ ತನ್ನ ಬದಿಯಿಂದ ಇದನ್ನು ಸರಿಪಡಿಸಲಾರದು. ಉತ್ತರದ ಮಾರ್ಗವು LAN ನಲ್ಲಿರುವ ಸಾಧನವು ಕ್ಲೈಂಟ್ ಪರವಾಗಿ ಉತ್ತರಿಸುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಅಥವಾ ಸರ್ವರ್ ಸ್ಥಳೀಯ ಎಂದು ಪರಿಗಣಿಸದ ವಿಳಾಸವನ್ನು ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ವಿಳಾಸದೊಂದಿಗೆ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

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

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

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

ಬೇರೆ ಸಬ್‌ನೆಟ್‌ನ ಹೋಸ್ಟ್‌ನಿಂದ ಅದೇ ಪರಿಶೀಲನೆ ಮಾಡಿ ಮತ್ತು ಹೋಲಿಸಿ. ರೌಟರ್ ಮೂಲಕ ಕ್ಲೈಂಟ್ ತಲುಪುವ ಹೋಸ್ಟ್‌ಗೆ ನೆರೆಹೊರೆ ನಮೂದು ಬೇಕೇ ಇಲ್ಲ, ಮತ್ತು ಆ ವ್ಯತ್ಯಾಸವೇ ಸಣ್ಣ ಪ್ರಮಾಣದ ವಿನ್ಯಾಸ ನಿರ್ಧಾರ.

proxy ARP ಮುಂದಿನ ಹಾಪ್ ಅನ್ನು ಹೇಗೆ ಒದಗಿಸುತ್ತದೆ

proxy ARP ಗೇಟ್‌ವೇಯನ್ನು ಬೇರೆ ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ತಲುಪಬಹುದಾದ ಗಮ್ಯಸ್ಥಾನದ ಪರವಾಗಿ ಲಿಂಕ್ ಪದರದ ವಿನಂತಿಗೆ ಉತ್ತರಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. LAN ಹೋಸ್ಟ್ ಹಾರ್ಡ್‌ವೇರ್ ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ, ಫ್ರೇಮ್ ಅನ್ನು ಗೇಟ್‌ವೇಗೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಗೇಟ್‌ವೇ ಪ್ಯಾಕೆಟ್ ಅನ್ನು VPN ಸೆಷನ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ದೃಷ್ಟಿಯಿಂದ ಕ್ಲೈಂಟ್ ಸರಳವಾಗಿ ಗೇಟ್‌ವೇಯ ಹಿಂದೆ ಇರುವಂತೆ ಕಾಣುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ ಸಂರಚನೆಯಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ.

MikroTik ನ RouterOS ARP ದಾಖಲೆ ಸಂಪರ್ಕಿತ LAN ನ ವಿಳಾಸ ಸ್ಥಳವನ್ನು ಎರವಲು ಪಡೆಯುವ ಡಯಲ್-ಇನ್ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಈ ಬಳಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಯಾಂತ್ರಿಕೆಯು ನೆರೆಹೊರೆ ಪರಿಹಾರದ ದುರಸ್ತಿ, ಮತ್ತು ಗೇಟ್‌ವೇ ನಿಜವಾಗಿಯೂ ಎರಡೂ ಮಾರ್ಗಗಳಲ್ಲಿರುವುದರಿಂದ ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.

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

ವೇದಿಕೆಯ ಮೋಡ್ ಹೆಸರುಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಿ. RouterOS proxy-arp ಅನ್ನು local-proxy-arp ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಅದೇ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಸಂಚಾರವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇವು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದ ಕಾಗುಣಿತಗಳಲ್ಲ, ಮತ್ತು ಎರಡನ್ನೂ ಭೇದವಿಲ್ಲದೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಸಣ್ಣ ದಾರಿಯಲ್ಲ.

proxy ARP ನಿಮಗೆ ಏನನ್ನು ಕೊಡುವುದಿಲ್ಲ

ಇದು broadcast ಅಥವಾ multicast ಪತ್ತೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ. broadcast ಮೂಲಕ ಸೇವೆಯನ್ನು ಹುಡುಕಬೇಕಾದ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ವಿಫಲವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಗೇಟ್‌ವೇ unicast ಅನ್ನು ಸೆಷನ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಅನ್ನು LAN ನ broadcast ಕ್ಷೇತ್ರದ ಸದಸ್ಯನನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ. broadcast ಅನ್ನು ಅವಲಂಬಿಸುವ ಪತ್ತೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಎರವಲು ವಿಳಾಸಗಳ ವಿನ್ಯಾಸಗಳಲ್ಲಿ «ಒಂದಕ್ಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಇನ್ನೊಂದಕ್ಕೆ ಇಲ್ಲ» ಎಂಬ ವರದಿಗಳ ಸಾಮಾನ್ಯ ಮೂಲ.

ಇದು ವಿಳಾಸವನ್ನು ಕಾಯ್ದಿರಿಸುವುದಿಲ್ಲ. ಎರವಲು ಪಡೆದ ಸಂಖ್ಯೆಯು DHCP ಪೂಲ್ ಅಥವಾ ಸ್ಥಿರ ನಿಯೋಜನೆಯಲ್ಲಿಯೂ ಇದ್ದರೆ, ಎರಡು ಸಾಧನಗಳು ಒಂದೇ ವಿಳಾಸಕ್ಕೆ ಬರಬಹುದು ಮತ್ತು ಪರಿಣಾಮದ ವರ್ತನೆ ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿದೆ. ಯಶಸ್ವಿ ಲಾಗಿನ್ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಅಲ್ಲ.

ಮತ್ತು ಇದು LAN ನ ಮಾಲೀಕರೊಂದಿಗೆ ಸಮನ್ವಯದ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ. ವಿಳಾಸ ಯೋಜನೆಯ ಮಾಲೀಕರನ್ನು ಆಶ್ಚರ್ಯಗೊಳಿಸುವ proxy ARP ನಮೂದು ಶಾಂತ ವಾರಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವ ಬೆಂಬಲ ಘಟನೆ.

ಪ್ರತ್ಯೇಕವಾಗಿ ರೌಟ್ ಮಾಡಿದ ಪೂಲ್‌ನೊಂದಿಗೆ ಹೋಲಿಕೆ

ಪರ್ಯಾಯವೆಂದರೆ VPN ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಅವರದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ನೀಡುವುದು ಮತ್ತು LAN ಹೋಸ್ಟ್‌ಗಳು ಅಲ್ಲಿಗೆ ರೌಟ್ ಮಾಡಲು ಬಿಡುವುದು. ಆಗ ಸರ್ವರ್ ತನ್ನ ಗೇಟ್‌ವೇಗೆ off-link ಉತ್ತರಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಗೇಟ್‌ವೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು VPN ಅಂತ್ಯಬಿಂದುವಿಗೆ ರೌಟ್ ಮಾಡುತ್ತದೆ, ಮತ್ತು LAN ವಿಭಾಗದಲ್ಲಿ ನೆರೆಹೊರೆ ಪರಿಹಾರದ ಅಗತ್ಯವೇ ಇಲ್ಲ. ಇದು ಎರವಲು ವಿಳಾಸ ಮತ್ತು proxy ಉತ್ತರಕ್ಕಿಂತ ಕಡಿಮೆ ಚಲಿಸುವ ಭಾಗಗಳು.

ಆ ವಿನ್ಯಾಸವನ್ನು ಯೋಚಿಸುವುದು ಸುಲಭ ಮತ್ತು ಆಡಿಟ್ ಮಾಡುವುದು ಸುಲಭ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಶ್ರೇಣಿ LAN ಶ್ರೇಣಿಯಿಂದ ಗೋಚರವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿದೆ. ಅದು ಒಂದು ಮಾರ್ಗ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮವನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ, ಅಂದರೆ proxy ARP ವಿನ್ಯಾಸವು ಕಡಿಮೆ ಸ್ಪಷ್ಟ ಸ್ಥಳದಲ್ಲಿ ಬೇಕಾಗುವ ಅದೇ ವಸ್ತುಗಳು.

ಮಾದರಿಗಳ ನಡುವೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಅಲ್ಲ. proxy ARP ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಬಂಧವನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ; ರೌಟ್ ಮಾಡಿದ ಪೂಲ್ ಆ ದುರಸ್ತಿಯ ಅಗತ್ಯವನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ನೀವು ಯಾವುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿದಿರಿ ಮತ್ತು ಏಕೆ ಎಂದು ಬರೆಯಿರಿ, ಮತ್ತು ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದನ್ನು ವಿಫಲ ನೆರೆಹೊರೆ ನಮೂದಿನಿಂದ ಮತ್ತೆ ಕಂಡುಹಿಡಿಯಬೇಕಾಗಿಲ್ಲ.