ਤੁਹਾਡੇ 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 ਨਾਲ ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।