ਰੂਟ ਕੀਤੇ VPN ਵਿੱਚ IPv6 ਗੁਆਂਢੀ ਖੋਜ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ

IPv6 ਗੁਆਂਢੀ ਖੋਜ ਇੱਕ ਲਿੰਕ ਦੀ ਹੈ, ਅਤੇ ਰੂਟ ਕੀਤੀ ਸੁਰੰਗ ਦੋ ਲਿੰਕਾਂ ਵਿਚਕਾਰ ਸੀਮਾ ਹੈ। ਉਹ ਇੱਕ ਵਾਕ ਹੀ ਲਗਭਗ ਹਰ ਉਸ ਰਿਪੋਰਟ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਦੂਰ ਦਾ ਹੋਸਟ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ। ਸੁਰੰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਪਤੇ ਦਾ ਦਾਇਰਾ ਜਾਂਚੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਪਰਖ ਰਹੇ ਹੋ। ਲਿੰਕ-ਸਥਾਨਕ ਪਤਾ ਸਿਰਫ਼ ਆਪਣੇ ਹੀ ਲਿੰਕ ਉੱਤੇ ਅਰਥ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਕੀਤੇ ਨੋਡ ਦਾ ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਸੀਮਿਤ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰਾਊਟਰ ਨਹੀਂ ਲੰਘਦਾ, ਇਸ ਲਈ ਵਿਸ਼ਵ ਪਤੇ ਉੱਤੇ ping ਸਫਲ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਉਸੇ ਹੋਸਟ ਦੀ ਖੋਜ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ।

ਦਾਇਰਾ ਸੰਰਚਨਾ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦਾ ਹੈ

ਗੁਆਂਢੀ ਬੇਨਤੀ ਅਤੇ ਘੋਸ਼ਣਾ 255 ਹੌਪ ਸੀਮਾ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਅੱਗੇ ਨਹੀਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ। ਤੁਹਾਡੀ ਸੁਰੰਗ ਅਤੇ ਦੂਰ ਦੇ LAN ਵਿਚਕਾਰਲਾ ਰਾਊਟਰ IPv6 ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਅਤੇ ਇਸਦੇ ਵੱਲੋਂ ਗੁਆਂਢੀ ਸੁਨੇਹੇ ਰੀਲੇਅ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਲਈ ਸੁਰੰਗ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਗੁਆਂਢੀ ਕੈਸ਼ ਵਿੱਚ ਸਾਥੀ ਅਤੇ ਥੋੜ੍ਹਾ ਹੀ ਹੁੰਦਾ ਹੈ, ਜੋ ਸਹੀ ਵਿਵਹਾਰ ਹੈ, ਸੁਧਾਰਨ ਯੋਗ ਨੁਕਸ ਨਹੀਂ।

fe80:: ਵਰਗੀ ਐਂਟਰੀ ਵਾਲਾ ਲਿੰਕ-ਸਥਾਨਕ ਪਤਾ ਵੀ ਜ਼ੋਨ-ਸੀਮਿਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹੀ ਲਿਖਤ ਕਿਸੇ ਹੋਰ ਲਿੰਕ ਉੱਤੇ ਕਿਸੇ ਹੋਰ ਹੋਸਟ ਨੂੰ ਦਰਸਾ ਸਕਦੀ ਹੈ। ਸੁਰੰਗ ਦੇ ਦੂਜੇ ਪਾਸਿਓਂ ਇੱਕ ਪਰਖਣਾ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਪਤਾ ਅਸਪਸ਼ਟ ਹੈ।

ਜਾਲ ਇਹ ਮੰਨ ਲੈਣਾ ਹੈ ਕਿ ਪ੍ਰੀਫ਼ਿਕਸ ਲਿੰਕ ਉੱਤੇ ਹੈ

ਜੋ ਹੋਸਟ ਮੰਨਦਾ ਹੈ ਕਿ ਪ੍ਰੀਫ਼ਿਕਸ ਲਿੰਕ ਉੱਤੇ ਹੈ, ਉਹ ਪੈਕਟ ਆਪਣੇ ਰਾਊਟਰ ਨੂੰ ਦੇਣ ਦੀ ਥਾਂ ਗੁਆਂਢੀ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ ਦੂਰ ਦੀ ਸਾਈਟ ਲਈ ਰੂਟ ਕੀਤਾ /64 ਵੀ ਸ਼ਾਮਲ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਪ੍ਰੀਫ਼ਿਕਸ ਲਿੰਕ ਉੱਤੇ ਹੋਣ ਵਜੋਂ ਆਉਂਦਾ ਹੈ, ਹੋਸਟ ਸਥਾਨਕ ਲਿੰਕ ਨੂੰ ਕਿਤੇ ਹੋਰ ਰਹਿੰਦੇ ਹੋਸਟ ਬਾਰੇ ਪੁੱਛਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ। ਦੂਰ ਦੇ ਹੋਸਟ ਲਈ ਕੁਝ ਛੋਟਾ ਰੂਟ ਕਰੋ, ਜਾਂ ਪ੍ਰੀਫ਼ਿਕਸ ਨੂੰ ਉਸ ਰਾਊਟਰ ਉੱਤੇ ਖ਼ਤਮ ਕਰੋ ਜੋ ਇਸਦੇ ਵੱਲੋਂ ਜਵਾਬ ਦੇਵੇਗਾ।

ਇੱਕੋ ਸੇਵਾ ਲਈ /128 ਸਭ ਤੋਂ ਘੱਟ ਹੈਰਾਨ ਕਰਨ ਵਾਲੀ ਵਿਵਸਥਾ ਹੈ, ਅਤੇ ਇਹ ਅਸਪਸ਼ਟਤਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦੀ ਹੈ। ਗੁਆਂਢੀ ਖੋਜ ਵਿਸ਼ੇਸ਼ਤਾ ਸੁਨੇਹਾ-ਸਮੂਹ ਅਤੇ ਇਹ ਤੈਅ ਕਰਨ ਵਾਲੇ ਲਿੰਕ-ਉੱਤੇ-ਹੈ ਝੰਡੇ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ।

ਬ੍ਰਿਜਿੰਗ ਜਾਣਬੁੱਝ ਕੇ ਨਿਯਮ ਬਦਲਦੀ ਹੈ

ਜਦੋਂ ਸੁਰੰਗ Ethernet ਫ਼ਰੇਮ ਲੈ ਕੇ ਜਾਂਦੀ ਹੈ, ਦੂਰ ਦਾ ਅਤੇ ਸਥਾਨਕ ਖੰਡ ਇੱਕ ਲਿੰਕ ਬਣ ਜਾਂਦੇ ਹਨ, ਮਲਟੀਕਾਸਟ ਦੋਵੇਂ ਪਾਸੇ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਗੁਆਂਢੀ ਖੋਜ ਸਵਿੱਚ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਨਤੀਜੇ ਵੀ ਨਾਲ ਆਉਂਦੇ ਹਨ: ਬ੍ਰੌਡਕਾਸਟ ਅਤੇ ਮਲਟੀਕਾਸਟ ਹੜ੍ਹ, ਪੁਲ ਭਰ ਵਿੱਚ ਦੋਹਰੇ ਪਤਿਆਂ ਦੀ ਖੋਜ, ਅਤੇ ਅਜਿਹੇ ਖੰਡ ਵਿੱਚ ਰਿਸਦੀਆਂ ਰਾਊਟਰ ਘੋਸ਼ਣਾਵਾਂ ਜਿਸਨੂੰ ਉਹ ਦਿਖਣੀਆਂ ਨਹੀਂ ਚਾਹੀਦੀਆਂ। ਨਾਕਾਮੀ ਦਾ ਖੇਤਰ ਹੁਣ ਦੋ ਸਾਈਟਾਂ ਤੱਕ ਵੀ ਫੈਲਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਪੁਲ ਵਿਰੁੱਧ ਦਲੀਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਹਰ ਨੁਕਤਾ ਪੁਲ ਸੰਜੋਗ ਨਾਲ ਨਹੀਂ, ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਉਣ ਦਾ ਕਾਰਨ ਹੈ।

ਖੋਜ ਦਿਸੇ ਇਸ ਲਈ ਪ੍ਰੋਫ਼ਾਈਲ TUN ਤੋਂ TAP ਵਿੱਚ ਬਦਲਣਾ ਕਾਰਵਾਈਆਂ ਦਾ ਗਲਤ ਕ੍ਰਮ ਹੈ। ਸਰਵਰ, ਕਲਾਇੰਟ ਅਤੇ ਪਤਾ ਯੋਜਨਾ—ਸਭ ਨੂੰ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮੋਬਾਈਲ ਕਲਾਇੰਟ TAP ਇੰਟਰਫ਼ੇਸ ਬਿਲਕੁਲ ਨਹੀਂ ਦਿੰਦੇ, ਇਸ ਲਈ ਅਜਿਹਾ ਡਿਜ਼ਾਈਨ ਲੈਪਟਾਪ ਉੱਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਫ਼ੋਨ ਉੱਤੇ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਗੁਆਂਢੀ ਪ੍ਰੌਕਸੀ ਅਤੇ ਰੀਲੇ ਆਪਣੀਆਂ ਲੋੜਾਂ ਵਾਲੇ ਵੱਖਰੇ ਕਾਰਜ ਹਨ, ਅਤੇ ਉਹ ਐਪ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਦੇ ਨਹੀਂ, ਨੈੱਟਵਰਕ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਦਸਤਾਵੇਜ਼ੀ ਵਿਵਸਥਾ ਦੇ ਹਨ।

ਉਸ ਪਤੇ ਨਾਲ ਪਰਖੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਵਰਤਦੀ ਹੈ

ip -6 route get ਨਾਲ ਰੂਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ip -6 neigh ਨਾਲ ਗੁਆਂਢੀ ਐਂਟਰੀ ਵੇਖੋ, ਫਿਰ ਰੂਟ ਕੀਤੇ ਮਾਰਗ ਉੱਤੇ ਸੇਵਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। DNS ਅਤੇ ਵਾਪਸੀ ਮਾਰਗ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਹਨ, ਅਤੇ ਸਿਹਤਮੰਦ ਗੁਆਂਢੀ ਐਂਟਰੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।

ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਲਿੰਕ-ਸਥਾਨਕ ਜਾਂ ਖੋਜ-ਆਧਾਰਿਤ ਮੰਜ਼ਿਲ ਉੱਤੇ ਜ਼ੋਰ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਟਿਊਨਿੰਗ ਅਭਿਆਸ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਗੱਲਬਾਤ ਹੈ, ਕਿਉਂਕਿ ਕੋਈ ਕਲਾਇੰਟ ਸੈਟਿੰਗ ਲਿੰਕ-ਸੀਮਿਤ ਕਾਰਜ ਨੂੰ ਰਾਊਟਰ ਉੱਤੇ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਹੀਂ ਬਣਾਉਂਦੀ।

ਲਿਖੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਹੈ

ਘਟਨਾ ਤੋਂ ਪਹਿਲਾਂ ਦਰਜ ਕਰੋ ਕਿ ਇਹ ਰੂਟ ਕੀਤਾ ਹੈ ਜਾਂ ਪੁਲ ਵਾਲਾ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਤੈਨਾਤੀਆਂ ਇਹਨਾਂ ਸਵਾਲਾਂ ਦਾ ਵੱਖਰਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਡਿਊਟੀ ਉੱਤੇ ਇੰਜੀਨੀਅਰ ਨੂੰ ਇਹ ਪ੍ਰੋਫ਼ਾਈਲ ਤੋਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾਉਣਾ ਚਾਹੀਦਾ।

ਸੁਨੇਹਾ-ਸਮੂਹ ਇੱਕ ਵਾਰ ਪੜ੍ਹਨ ਨਾਲ ਲਿੰਕ-ਦਾਇਰੇ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ VPN ਨੁਕਸ ਦੱਸਣ ਦਾ ਲਾਲਚ ਹਟ ਜਾਂਦਾ ਹੈ, ਜੋ ਇਸ ਖੇਤਰ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਗਲਤ ਨਿਦਾਨ ਹੈ।