ನಿಮ್ಮ IPv6 ಟನೆಲ್ ಸಹಚರರಿಗೆ ping ವಿಫಲವೇ? :: ವಿಳಾಸ ಪರಿಶೀಲಿಸಿ

ನಿಮ್ಮ IPv6 ಟನೆಲ್ನ ಒಂದು ತುದಿ ಇನ್ನೊಂದಕ್ಕೆ ping ಮಾಡುತ್ತದೆ, ಮತ್ತು ಯಾವಾಗಲೂ ಒಂದೇ ದಿಕ್ಕು ಉತ್ತರಿಸುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ ಚಾಲನೆಯಲ್ಲಿದೆ, ರೂಟ್ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಲಾಗ್ನಲ್ಲಿ ಏನೂ ಇದನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ. ನೀವು ನಿಯೋಜಿಸಿದ ವಿಳಾಸ ಸಬ್ನೆಟ್-ರೌಟರ್ anycast ವಿಳಾಸವಾಗಿದೆ, ಅದು ಹೋಸ್ಟ್ ವಿಳಾಸವೇ ಅಲ್ಲ, ಮತ್ತು ಎರಡು ತುದಿಗಳ ಕೊಂಡಿಯಲ್ಲಿ ಅದಕ್ಕೆ ನಿಖರವಾಗಿ ಒಂದೇ ವಿತರಣಾ ಗುರಿ ಇದೆ: ಕಳುಹಿಸುವವರು. ಯಾವುದೇ ಟೈಮೌಟ್ ಮೌಲ್ಯ ಇದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಳಾಸವು ನೀವು ಭಾವಿಸುವ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತಿಲ್ಲ.

ವಿಳಾಸದ ಕಡೆಗೆ ತೋರಿಸುವ ಲಕ್ಷಣ

ಕೊಂಡಿಯಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಹೋಸ್ಟ್ ಉತ್ತರಿಸುತ್ತದೆ, ಇಂಟರ್ಫೇಸ್ ಗುರುತಿಸುವಿಕೆ ಎಲ್ಲಾ ಶೂನ್ಯವಾಗಿರುವ ಹೋಸ್ಟ್ ಹೊರತುಪಡಿಸಿ. ಆ ರೂಪಕ್ಕೆ ವಿಳಾಸ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ ವ್ಯಾಖ್ಯಾನದಂತೆ ಸಬ್ನೆಟ್ನಲ್ಲಿನ ರೌಟರ್ಗೆ ತಲುಪಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಟನೆಲ್ನಲ್ಲಿ ಅದು ಕಳುಹಿಸಿದ ಯಂತ್ರಕ್ಕೇ ಮರಳುತ್ತದೆ. ದೂರದ ತುದಿಯಿಂದ ಇದು ತಲುಪಲಾಗದ ಸಹಚರರಂತೆ ಓದಲ್ಪಡುತ್ತದೆ; ಹತ್ತಿರದ ತುದಿಯಿಂದ ಮೌನದಂತೆ. ಅದೇ ಪ್ರಿಫಿಕ್ಸ್ನ ಇನ್ನೊಂದು ಗುರುತಿಸುವಿಕೆಯನ್ನು ಬದಲಾಯಿಸಿ, ಬೇರೆ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಲಕ್ಷಣ ಮಾಯವಾಗುತ್ತದೆ, ಮತ್ತು ರೂಟ್ಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಪಡೆಯಬೇಕಾದ ದೃಢೀಕರಣ ಅದೇ.

ಸರ್ವ-ಶೂನ್ಯ ಗುರುತಿಸುವಿಕೆ anycast ಆಗಿ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ

RFC 4291 ಸರ್ವ-ಶೂನ್ಯ ಇಂಟರ್ಫೇಸ್ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಸಬ್ನೆಟ್-ರೌಟರ್ anycast ವಿಳಾಸವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ /64 ನಂತಹ 2001:db8:4a::/64 ನಲ್ಲಿ ಯಾವುದೇ ಉಪಯುಕ್ತ ಹೋಸ್ಟ್ ಇಲ್ಲ 2001:db8:4a:: ವಿಳಾಸದಲ್ಲಿ. ಈ ಕಾಯ್ದಿರಿಸುವಿಕೆ ತನ್ನ ಸ್ಥಾನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ: ರೌಟರ್ ಪ್ರಕಟಣೆಗಳು ಮತ್ತು ನೆರೆಹೊರೆಯವರ ಅನ್ವೇಷಣೆ ಆ ರೂಪವನ್ನೇ ವಿಳಾಸ ಮಾಡುತ್ತವೆ, ಮತ್ತು ರೌಟರ್ ತಾನು ಸೇವೆ ಸಲ್ಲಿಸುವ ಪ್ರಿಫಿಕ್ಸ್ಗಾಗಿ ಉತ್ತರಿಸುತ್ತದೆ. ಆ ಮೌಲ್ಯವನ್ನು ಟನೆಲ್ ತುದಿಗೆ ನಿಯೋಜಿಸುವುದು ಎಲೆಗೆ ರೌಟರ್ ಪಾತ್ರವನ್ನು ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಏನೂ ಮರಳಿ ಬರುವುದಿಲ್ಲ. ಪ್ರಿಫಿಕ್ಸ್ನಲ್ಲಿನ ಯಾವುದೇ ಇತರ ಗುರುತಿಸುವಿಕೆ ಹೋಸ್ಟ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಪರಿಹಾರ ಸಾಮಾನ್ಯವಾಗಿ ಒಂದು ಅಂಕಿ.

ಈ ಕಾಯ್ದಿರಿಸುವಿಕೆಯನ್ನು ಟನೆಲ್ ತುದಿಯಿಂದ ತೆಗೆದುಕೊಳ್ಳುವ ಹಕ್ಕಿಲ್ಲದ ಪಾತ್ರವಾಗಿ ಪರಿಗಣಿಸಿ, ರೂಟ್ನಿಂದ ಬಳಸಿಕೊಳ್ಳಬಹುದಾದ ವಿಚಿತ್ರತೆಯಾಗಿ ಅಲ್ಲ.

ಹೋಸ್ಟ್ ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ರೂಟ್ ಮಾಡಿ

ಎರಡು ತುದಿಗಳಿಗೆ ::1 ಮತ್ತು ::2 ಆಯ್ಕೆಮಾಡಿ, ಒಂದನ್ನು ಇದರೊಂದಿಗೆ ಸೇರಿಸಿ: ip -6 addr add 2001:db8:4a::2/64 dev tun0, ನಂತರ ದೂರದ ಪ್ರಿಫಿಕ್ಸ್ಗೆ ವಿಳಾಸ ನೀಡಲು ಪ್ರಯತ್ನಿಸುವ ಬದಲು ಅದನ್ನು ರೂಟ್ ಮಾಡಿ. 2001:db8:4a::/64 ಗಾಗಿ ಟನೆಲ್ನಿಂದ ಹೊರಹೋಗುವ ರೂಟ್ ದೂರದ ಭಾಗವನ್ನು ತಲುಪಬಹುದಾಗಿಸುತ್ತದೆ; ವಿಳಾಸ ಮಾತ್ರ ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಸಂರಚಿಸುತ್ತದೆ.

ಪೂರ್ಣ ಟನೆಲ್ಗೆ ಮೂರನೇ ಹಂತವಿದೆ, ಸಾಧನದ ಮೂಲಕ ಜಾಗತಿಕ unicast ಗಾಗಿ ಡೀಫಾಲ್ಟ್ ರೂಟ್, ಇದು ಎಲ್ಲವನ್ನೂ ಟನೆಲ್ಗೆ ಕಳುಹಿಸುವ IPv6 ಸಮಾನಾಂತರ. ಅದನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ, IPv4 ಟನೆಲ್ನ ಒಳಗೆ ಸಂಚರಿಸುವಾಗ IPv6 ಭೌತಿಕ ಕೊಂಡಿಯನ್ನು ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ನೀವು ಆವರಿಸಿದೆ ಎಂದು ಭಾವಿಸಿದ ಸಂಚಾರವನ್ನೇ ಸೋರಿಸುತ್ತದೆ. ಇದರೊಂದಿಗೆ ದೃಢೀಕರಿಸಿ: ip -6 route get 2001:4860:4860::8888 ಮತ್ತು ಉತ್ತರವನ್ನು ಊಹಿಸುವ ಬದಲು ಯಾವ ಸಾಧನವನ್ನು ಹೆಸರಿಸುತ್ತದೆ ಎಂದು ಓದಿ.

ರೂಟಿಂಗ್ಗೆ ಮೊದಲೇ multicast ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ

Android VpnService.Builder ಗಾಗಿ ವಿಳಾಸಗಳು ಮತ್ತು ರೂಟ್ಗಳನ್ನು LinkAddress ಮೂಲಕ ಪರಿಶೀಲಿಸುತ್ತದೆ, ಮತ್ತು ಆ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ multicast ಅನ್ನು ನೇರವಾಗಿ ನಿರಾಕರಿಸುತ್ತದೆ. ಅದಕ್ಕೆ ರೂಟ್ ಆಗಿ multicast ಪ್ರಿಫಿಕ್ಸ್ ನೀಡಿದರೆ ಫಲಿತಾಂಶ ರೂಟ್ ಅಲ್ಲ, ಕೆಟ್ಟ LinkAddress ನಿಯತಾಂಕಗಳ ವೈಫಲ್ಯ, ಇದು ನೆಟ್ವರ್ಕ್ನ ಉತ್ತರವಲ್ಲ, ಮಾನ್ಯತೆಯ ಉತ್ತರ. ಈ ನಿರಾಕರಣೆ ಮಾಧ್ಯಮಕ್ಕೆ ಹೊಂದುತ್ತದೆ: ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ tun ಸಾಧನಕ್ಕೆ ಲಿಂಕ್-ಪದರದ multicast ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದರ ಮೇಲೆ ಗುಂಪು ರೂಟ್ಗೆ ಸ್ಥಾಪಿಸಲು ವಿತರಣಾ ಮಾದರಿ ಇಲ್ಲ. ಗುಂಪು ವಿಳಾಸಗಳನ್ನು ಕೈಯಿಂದ ಸಂರಚಿಸುವ ಬದಲು ಸ್ಟಾಕ್ ಸ್ವತಃ ರಚಿಸಿ ಬಳಸುತ್ತದೆ.

IPv6 all-nodes ಮತ್ತು solicited-node ವಿಳಾಸಗಳು ಅದೇ ನಿಯಮದ ಅಡಿಯಲ್ಲಿ ಬರುತ್ತವೆ. ಇಂಟರ್ಫೇಸ್ ಅವುಗಳನ್ನು ಸ್ಟಾಕ್ ಅಲ್ಲಿ ಇಟ್ಟಿರುವುದರಿಂದ ಹೊತ್ತುಕೊಳ್ಳುತ್ತದೆ, ಯಾವುದೋ ನೀತಿ ಅವುಗಳನ್ನು ಉದ್ದೇಶಿಸಿದ್ದರಿಂದ ಅಲ್ಲ.

ಟನೆಲ್ ಬದಲಿಗೆ ಏನನ್ನು ಹೊತ್ತುಕೊಳ್ಳಬಹುದು

ಟನೆಲ್ ಅಡ್ಡಲಾಗಿ multicast ಅನ್ವೇಷಣೆ ಯನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಗುಂಪು ಸದಸ್ಯತ್ವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಪದರ ಬೇಕು: Ethernet ವಿಭಾಗವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುವ TAP ಸೇತುವೆ, ಅಪ್ಲಿಕೇಶನ್-ಮಟ್ಟದ ರಿಲೇ, ಅಥವಾ ಯಾವ ಸಹಚರರಿಗೆ ನಕಲು ಮಾಡಬೇಕೆಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಲಾದ ರೂಟಿಂಗ್ ಪ್ರೋಟೋಕಾಲ್. VpnService ಮಾದರಿಯಲ್ಲಿ ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಇಲ್ಲ, ಅಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಓದಿ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಟನೆಲ್ಗಾಗಿ ಗುಂಪಿಗೆ ಸೇರುವ ಕರೆ ಇಲ್ಲ. ಗುಂಪುಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಘಟಕವನ್ನು ಸೇರಿಸಿ ಅಥವಾ ವಿನ್ಯಾಸದಿಂದ ಅಗತ್ಯವನ್ನು ತೆಗೆದುಹಾಕಿ.

ಇದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ unicast ಮೇಲಿನ ವಿಳಾಸಗಳು ಮತ್ತು ರೂಟ್ಗಳ ಹೊರತಾಗಿ ಏನನ್ನೂ ಬೇಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಟನೆಲ್ಗಳು ಅದನ್ನು ಹೊತ್ತುಕೊಳ್ಳುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಅನ್ವೇಷಣಾ ಪ್ರೋಟೋಕಾಲ್ ವಿಫಲವಾದಾಗ ಅವುಗಳನ್ನೇ ದೂಷಿಸಲಾಗುತ್ತದೆ.

ಏನನ್ನಾದರೂ ನಿಯೋಜಿಸುವ ಮೊದಲು ಮೂರು ಪರಿಶೀಲನೆಗಳು

ವಿಳಾಸ anycast ರೂಪವಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಅದು multicast ಅಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಪ್ರಿಫಿಕ್ಸ್ ಸಾಧನಕ್ಕೆ ಸುಮ್ಮನೆ ನಿಯೋಜಿಸಲ್ಪಡದೆ ರೂಟ್ ಆಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ನಂತರ ನಿಮ್ಮ ಪರೀಕ್ಷೆಯನ್ನು ನಿಜವಾದ ಹೋಸ್ಟ್ ಆಗಿರುವ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಕಳುಹಿಸಿ, ಏಕೆಂದರೆ anycast ವಿಳಾಸದತ್ತ ಗುರಿಪಡಿಸಿದ ping ಕಳುಹಿಸುವವರನ್ನು ಅಳೆಯುತ್ತದೆ ಮತ್ತು ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಆ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಇರಿಸಿ, ಮುಂದಿನ ನಿಯೋಜನೆ ಅವುಗಳನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳದಂತೆ.

ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಎಂದೂ ಸ್ಥಾಪಿಸದ ರೂಟ್ ಅನ್ನು ಹೆಚ್ಚು ಕಾಲ ಕಾಯ್ದು ಡೀಬಗ್ ಮಾಡಲಾಗದು, ಮತ್ತು ಎಂದೂ ಹೋಸ್ಟ್ ಆಗದ ವಿಳಾಸವನ್ನು ಉತ್ತಮ ping ನಿಂದ ಸರಿಪಡಿಸಲಾಗದು.