ನೀವು ಮಾರ್ಗ ಸೇರಿಸುತ್ತೀರಿ, ಸುರಂಗ ಏಳುತ್ತದೆ, ಆದರೂ ಆಚೆಗಿನ ping «network unreachable» ಬದಲು ಸಂಪೂರ್ಣ ನಷ್ಟದಿಂದ ಸಾಯುತ್ತದೆ. ಈ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಅದು ಮಾರ್ಗ ಕೋಷ್ಟಕದಿಂದ ವಿಳಾಸದ ಕಡೆಗೆ ನೋಟವನ್ನು ತಿರುಗಿಸುತ್ತದೆ. 169.254 ಗಮ್ಯಸ್ಥಾನ ಲಿಂಕ್-ಲೋಕಲ್ ಆಗಿದೆ ಮತ್ತು ಅದರ ವ್ಯಾಪ್ತಿ ವಿನ್ಯಾಸದ ಪ್ರಕಾರ ಮೊದಲ hop ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ.

ಮುಂದಿನ ನಿರ್ಧಾರ ಸಂಕುಚಿತವಾಗಿದೆ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಬೇಕು: ಸರ್ವರ್ ಬದಿಯ ಸಬ್ನೆಟ್ ಸರಿಪಡಿಸಿ, ಅಥವಾ ಲೇಯರ್ 2 ವಿಭಾಗವನ್ನು ವಿಸ್ತರಿಸಿ ವಿಳಾಸ ಮತ್ತೆ ಸ್ಥಳೀಯ ಅರ್ಥ ಪಡೆಯಲಿ. ಉಳಿದೆಲ್ಲವೂ, ಅಗಲವಾದ ಮಾರ್ಗ ಸೇರಿಸುವುದೂ ಸೇರಿ, ಅದೇ ವೈಫಲ್ಯವನ್ನು ಹೆಚ್ಚು ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಹರಡುತ್ತದೆ.

ವಿಳಾಸಕ್ಕೆ ಮಾರ್ಗ ಇಲ್ಲ ಎನ್ನುವುದಲ್ಲ, ಅದು ಮಾರ್ಗಮಾಡಲು ಅಸಾಧ್ಯ

IPv4 ಲಿಂಕ್-ಲೋಕಲ್ ವಿಳಾಸಗಳು ಉತ್ತಮ ಉತ್ತರ ಬಾರದಿದ್ದಾಗ ಸ್ವತಃ ತಮ್ಮನ್ನು ನಿಗದಿಪಡಿಸಿಕೊಳ್ಳುತ್ತವೆ; Windows ನ ಸ್ವಯಂ ಖಾಸಗಿ ವಿಳಾಸೀಕರಣ ಇಲ್ಲಿಂದ ಬರುತ್ತದೆ. ಈ ಶ್ರೇಣಿ ಪ್ರತಿ ಸಂಪರ್ಕದಲ್ಲಿ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬಳಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೇ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಒಂದೇ ವಿಭಾಗದ ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ಯಾವುದೇ ಸಮನ್ವಯವಿಲ್ಲದೆ ಮಾತನಾಡಬಹುದು.

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

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

ಸುರಂಗ ವ್ಯಾಪ್ತಿ ಸಮಸ್ಯೆಯನ್ನು ಏಕೆ ತೋರಿಸುತ್ತದೆ

TUN ಇಂಟರ್ಫೇಸ್ ಎರಡು ಪಾಲುದಾರರ ನಡುವೆ IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಹಿಂದೆ ಹಂಚಿದ ವಿಭಾಗವಿಲ್ಲ. ಪ್ರಸಾರವಿಲ್ಲ, ಆಚೆಗಿನ ಬದಿಗೆ ARP ಇಲ್ಲ, ನೆರೆಹೊರೆಯ ಪತ್ತೆಯೂ ಇಲ್ಲ.

ಏನನ್ನು ಹುಡುಕಬೇಕೆಂದು ತಿಳಿದರೆ ಲಕ್ಷಣಗಳು ಸರಿಯಾಗಿ ಹೊಂದುತ್ತವೆ. ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಿದೆ, ping ಸಂಪೂರ್ಣ ನಷ್ಟವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ನೆರೆಹೊರೆ ಕೋಷ್ಟಕ ಅಪೂರ್ಣ ನಮೂದನ್ನು ತೋರಿಸುತ್ತದೆ. ಸುರಂಗದಲ್ಲಿ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಪ್ಯಾಕೆಟ್ ಹೊರಹೋಗುವುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಜನರನ್ನು ವಿಳಾಸ ವರ್ಗದ ಬದಲು ದೂರದ ತುದಿಗೆ ನೋಡುವಂತೆ ಮಾಡುತ್ತದೆ.

Windows ನಲ್ಲಿ ಅದೇ ಬೇರಿನ ಎರಡನೇ ಲಕ್ಷಣವಿದೆ: ಲಿಂಕ್-ಲೋಕಲ್ ವಿಳಾಸ ಮಾತ್ರ ಉಳಿದ ಅಡಾಪ್ಟರ್‌ಗೆ ಬಳಸಬಹುದಾದ ಗೇಟ್‌ವೇ ಇಲ್ಲ, ಆದ್ದರಿಂದ ನೆಟ್‌ವರ್ಕ್ ಗುರುತಿಸುವಿಕೆ ಸಂಪರ್ಕವನ್ನು ವರ್ಗೀಕರಿಸಲಾರದು ಮತ್ತು ಫೈರ್‌ವಾಲ್ ಪ್ರೊಫೈಲ್ public ಗೆ ಬೀಳುತ್ತದೆ. ಸುರಂಗ ಕಾರಣವಲ್ಲ; ವಿಳಾಸ ಕಾರಣ.

ಮೂರು ಪ್ರಶ್ನೆಗಳಿಂದ ನಿರ್ಧರಿಸಿ

ಸಬ್ನೆಟ್ ಸರಿಪಡಿಸುವುದು ಮತ್ತು ಸೇತುವೆ ಮಾಡುವುದರ ನಡುವಿನ ಆಯ್ಕೆ ಮೂರು ಷರತ್ತುಗಳ ಮೇಲೆ ನಿಂತಿದೆ.

QuestionIf yesIf no
Can the far-side host be given a routable address?Change the host or fix DHCP and route normallyContinue to the next question
Does the device accept a static address at all?Assign one from the site's real prefixBridging is the only remaining option
Can you accept broadcast crossing the tunnel?A bridge is viable for a small segmentReplace the device or accept no remote access

ಹೆಚ್ಚಿನ ಪ್ರಕರಣಗಳು ಮೊದಲ ಪ್ರಶ್ನೆಯಲ್ಲೇ ನಿಲ್ಲುತ್ತವೆ. ಲಿಂಕ್-ಲೋಕಲ್ ವಿಳಾಸ ತೋರಿಸುವ ಹೋಸ್ಟ್ ಸಾಮಾನ್ಯವಾಗಿ DHCP ಉತ್ತರಿಸಲಿಲ್ಲ, ಕೇಬಲ್ ಅಥವಾ VLAN ತಪ್ಪು, ಅಥವಾ ಯಾರೋ ವಿಳಾಸವನ್ನು ಕೈಯಿಂದ ಬರೆದರು ಎಂದರ್ಥ. ಅದನ್ನು ಸರಿಪಡಿಸುವುದು ಯಾವುದೇ ಸುರಂಗ ಕೆಲಸಕ್ಕಿಂತ ಅಗ್ಗ ಮತ್ತು ಮುಂದಿನ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಸಮಸ್ಯೆಯನ್ನು ತೆಗೆಯುತ್ತದೆ.

ಏನನ್ನೂ ಊಹಿಸುವ ಮೊದಲು ಸರ್ವರ್ ಬದಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಹೋಸ್ಟ್‌ನಲ್ಲಿ ip addr show ಮತ್ತು ip route, ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ arp -n ಅಥವಾ route print -4 ಚಲಾಯಿಸಿ.

ಸೇತುವೆ ಸರಿಯಾದ ಉತ್ತರವಾದಾಗ ಅದರ ವೆಚ್ಚ

ಭೌತಿಕ ಅಡಾಪ್ಟರ್ ಅನ್ನು TAP ಅಡಾಪ್ಟರ್‌ನೊಂದಿಗೆ ಸೇತುವೆ ಮಾಡಿದರೆ ದೂರದ ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ಪ್ರಸಾರ ಡೊಮೇನ್‌ನ ಭಾಗವಾಗುತ್ತದೆ.

ವೆಚ್ಚಗಳು ನಿಜವಾದವು ಮತ್ತು ಯಾರಾದರೂ ಒಪ್ಪುವ ಮೊದಲು ಹೇಳಬೇಕು. ಪ್ರಸಾರ ಸಂಚಾರ ಸುರಂಗವನ್ನು ದಾಟುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಸ್ಥಳೀಯ ವಿಭಾಗಕ್ಕೆ ಎಲ್ಲಾ ಉದ್ದೇಶಗಳಿಗೂ ಒಡ್ಡಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ಸರ್ವರ್ ಈಗ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗಮಾಡುವ ಬದಲು ಫ್ರೇಮ್ ರವಾನಿಸಬೇಕು. ಪ್ರಯೋಗಾಲಯದ ಮೇಜಿಗೆ ಅಥವಾ ಮಾರ್ಗಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲದ ಸಂರಚನಾ ಮಾರ್ಗವಿಲ್ಲದ ಸಾಧನಕ್ಕೆ ಇದು ಸೂಕ್ತ ವಿನಿಮಯ, ದೂರದ ಪ್ರವೇಶಕ್ಕೆ ಕೆಟ್ಟ ಡಿಫಾಲ್ಟ್.

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

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