ರೂಟ್ ಮಾಡಿದ VPN ಮೂಲಕ IPv6 ನೆರೆಹೊರೆ ಪತ್ತೆ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ

IPv6 ನೆರೆಹೊರೆ ಪತ್ತೆ ಒಂದು ಲಿಂಕ್ಗೆ ಸೇರಿದ್ದು, ಮತ್ತು ರೂಟ್ ಮಾಡಿದ ಸುರಂಗ ಎರಡು ಲಿಂಕ್ಗಳ ನಡುವಿನ ಗಡಿ. ಆ ಒಂದು ವಾಕ್ಯವೇ ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುವ ಆದರೆ ಬೇರೆ ಯಾವುದರಿಂದಲೂ ಸಿಗದ ದೂರದ ಆತಿಥೇಯದ ಬಗ್ಗೆ ಬಹುತೇಕ ಎಲ್ಲ ವರದಿಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಸುರಂಗವನ್ನು ಪರಿಶೀಲಿಸುವ ಮೊದಲು ನೀವು ಪರೀಕ್ಷಿಸುತ್ತಿರುವ ವಿಳಾಸದ ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. ಲಿಂಕ್-ಸ್ಥಳೀಯ ವಿಳಾಸವು ತನ್ನದೇ ಲಿಂಕ್ನಲ್ಲಿ ಮಾತ್ರ ಅರ್ಥಪೂರ್ಣ, ಮತ್ತು ಕೋರಿದ ನೋಡ್ನ ಮಲ್ಟಿಕಾಸ್ಟ್ ಗುಂಪು ಅದೇ ರೀತಿ ಸೀಮಿತವಾಗಿದೆ. ಎರಡೂ ರೂಟರ್ ಅನ್ನು ದಾಟುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಜಾಗತಿಕ ವಿಳಾಸಕ್ಕೆ ping ಯಶಸ್ವಿಯಾಗಬಹುದು ಆದರೆ ಅದೇ ಆತಿಥೇಯದ ಪತ್ತೆ ವಿಫಲವಾಗುತ್ತದೆ.

ವ್ಯಾಪ್ತಿ ಸಂರಚನೆಗಿಂತ ಮೊದಲು ಬರುತ್ತದೆ

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

fe80:: ನಮೂದಿನಂತಹ ಲಿಂಕ್-ಸ್ಥಳೀಯ ವಿಳಾಸವೂ ವಲಯ-ಸೀಮಿತವಾಗಿದೆ, ಮತ್ತು ಅದೇ ಪಠ್ಯ ಬೇರೆ ಲಿಂಕ್ನಲ್ಲಿ ಬೇರೆ ಆತಿಥೇಯವನ್ನು ಸೂಚಿಸಬಹುದು. ಸುರಂಗದ ಇನ್ನೊಂದು ಬದಿಯಿಂದ ಒಂದನ್ನು ಪರೀಕ್ಷಿಸುವುದು ವಿಳಾಸ ಅಸ್ಪಷ್ಟವಾಗಿದೆ ಎಂಬುದಲ್ಲದೆ ಬೇರೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಬಲೆ ಎಂದರೆ ಮುನ್ನಡಿ ಲಿಂಕ್ನಲ್ಲಿದೆ ಎಂಬ ಊಹೆ

ಮುನ್ನಡಿ ಲಿಂಕ್ನಲ್ಲಿದೆ ಎಂದು ನಂಬುವ ಆತಿಥೇಯವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ತನ್ನ ರೂಟರ್ಗೆ ಒಪ್ಪಿಸುವ ಬದಲು ನೆರೆಹೊರೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಇದರಲ್ಲಿ ದೂರದ ತಾಣಕ್ಕೆ ರೂಟ್ ಮಾಡಿದ /64 ಸಹ ಸೇರುತ್ತದೆ. ಅಂತಹ ಮುನ್ನಡಿ ಲಿಂಕ್ನಲ್ಲಿರುವಂತೆ ಬಂದಾಗ, ಆತಿಥೇಯವು ಸ್ಥಳೀಯ ಲಿಂಕ್ ಅನ್ನು ಬೇರೆಡೆ ವಾಸಿಸುವ ಆತಿಥೇಯದ ಬಗ್ಗೆ ಕೇಳುತ್ತದೆ, ಮತ್ತು ಯಾವುದೂ ಉತ್ತರಿಸುವುದಿಲ್ಲ. ದೂರದ ಆತಿಥೇಯಕ್ಕೆ ಸಣ್ಣದನ್ನು ರೂಟ್ ಮಾಡಿ, ಅಥವಾ ಅದರ ಪರವಾಗಿ ಉತ್ತರಿಸುವ ರೂಟರ್ನಲ್ಲಿ ಮುನ್ನಡಿಯನ್ನು ಕೊನೆಗೊಳಿಸಿ.

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

ಸೇತುವೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಯಮಗಳನ್ನು ಬದಲಿಸುತ್ತದೆ

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

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

ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ವಿಳಾಸದಿಂದಲೇ ಪರೀಕ್ಷಿಸಿ

ip -6 route get ನಿಂದ ಮಾರ್ಗವನ್ನು ದೃಢೀಕರಿಸಿ, ip -6 neigh ನಿಂದ ನೆರೆಹೊರೆ ನಮೂದನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ರೂಟ್ ಮಾಡಿದ ಮಾರ್ಗದಲ್ಲಿ ಸೇವೆಯನ್ನು ದೃಢೀಕರಿಸಿ. DNS ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಪ್ರತ್ಯೇಕ ಪರಿಶೀಲನೆಗಳು, ಮತ್ತು ಆರೋಗ್ಯಕರ ನೆರೆಹೊರೆ ನಮೂದು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ಅಪ್ಲಿಕೇಶನ್ ಲಿಂಕ್-ಸ್ಥಳೀಯ ಅಥವಾ ಪತ್ತೆ-ಆಧಾರಿತ ಗಮ್ಯಸ್ಥಾನದ ಮೇಲೆ ಪಟ್ಟು ಹಿಡಿದರೆ, ಅದು ಟ್ಯೂನಿಂಗ್ ಅಭ್ಯಾಸವಲ್ಲ, ವಿನ್ಯಾಸದ ಸಂಭಾಷಣೆ, ಏಕೆಂದರೆ ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಸೆಟ್ಟಿಂಗ್ ಲಿಂಕ್-ಸೀಮಿತ ಕಾರ್ಯವಿಧಾನವನ್ನು ರೂಟರ್ ಮೂಲಕ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಬಳಿ ಯಾವ ವಿನ್ಯಾಸವಿದೆ ಎಂದು ಬರೆಯಿರಿ

ಘಟನೆಗೆ ಮೊದಲು ಅದು ರೂಟ್ ಆಗಿದೆಯೋ ಸೇತುವೆಯೋ ಎಂದು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಎರಡು ನಿಯೋಜನೆಗಳು ಈ ಪ್ರಶ್ನೆಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ಉತ್ತರಿಸುತ್ತವೆ ಮತ್ತು ಕರ್ತವ್ಯದ ಇಂಜಿನಿಯರ್ ಅದನ್ನು ಪ್ರೊಫೈಲ್ನಿಂದ ಊಹಿಸಬಾರದು.

ಸಂದೇಶ ಸಮೂಹವನ್ನು ಒಮ್ಮೆ ಓದುವುದು ಲಿಂಕ್-ವ್ಯಾಪ್ತಿ ಗುಣವನ್ನು VPN ದೋಷವೆಂದು ವಿವರಿಸುವ ಪ್ರಲೋಭನೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇದು ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ ಅತ್ಯಂತ ದುಬಾರಿ ತಪ್ಪು ನಿರ್ಣಯ.