ਤੁਹਾਡੇ /64 ਨੂੰ ਵੰਡਣਾ IPv6 ਨੂੰ VPN ਕਲਾਇੰਟਾਂ ਤੱਕ ਰੂਟ ਨਹੀਂ ਕਰਦਾ

ਕਲਾਇੰਟ ਗਲੋਬਲ IPv6 ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ, ਅਤੇ ਇੰਟਰਨੈੱਟ ਤੋਂ ਕੁਝ ਵੀ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ। ਪੂਲ ਸੈਟਿੰਗ ਸਹੀ ਦਿਖਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸੱਚਮੁੱਚ ਸਹੀ ਹੈ; ਪਤਾ ਵੈਧ ਹੈ ਅਤੇ ਟਨਲ ਇਸਨੂੰ ਢੋਂਦੀ ਹੈ। ਜੋ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਉਹ ਡਿਲੀਵਰੀ ਹੈ, ਅਤੇ ਡਿਲੀਵਰੀ VPN ਸਰਵਰ ਦੇ ਉੱਪਰ ਲਏ ਗਏ ਉਸ ਫੈਸਲੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਜਿਸ 'ਤੇ ਕੋਈ ਵੀ ਕਲਾਇੰਟ-ਸਾਈਡ ਕਨਫਿਗਰੇਸ਼ਨ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾ ਸਕਦੀ।

ਭਰਮ: ਤੁਹਾਡੇ /64 ਦਾ ਇੱਕ ਹਿੱਸਾ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚਯੋਗ ਹੈ

ਕਹਾਣੀ ਆਕਰਸ਼ਕ ਹੈ: ਸਰਵਰ ਕੋਲ ਜਨਤਕ /64 ਹੈ, ਇਸਨੂੰ ਅੱਧਾ ਕੱਟੋ, ਦੂਜਾ ਅੱਧਾ VPN ਪੂਲ ਨੂੰ ਦਿਓ, ਅਤੇ ਉਹ ਕਲਾਇੰਟ ਹੁਣ ਇੰਟਰਨੈੱਟ 'ਤੇ ਹਨ। ਪ੍ਰੀਫਿਕਸ ਵੰਡਣਾ ਟਕਰਾਅ ਤੋਂ ਬਿਨਾਂ ਪਤੇ ਅਲਾਟ ਕਰਦਾ ਹੈ। ਪਰ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਅਪਸਟ੍ਰੀਮ ਨੈੱਟਵਰਕ ਕਿਵੇਂ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਪਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਪੈਕੇਟ ਕਿੱਥੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਇਹੀ ਪੂਰੀ ਅਸਫਲਤਾ ਹੈ: ਅੱਗੇ ਵਾਲੀ ਦਿਸ਼ਾ ਕੰਮ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਸਰਵਰ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਵਾਪਸੀ ਦਿਸ਼ਾ ਇੱਕ ਹੌਪ ਦੂਰ ਮਰ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਅਪਸਟ੍ਰੀਮ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਲੱਗਾ ਕਿ ਕਲਾਇੰਟ ਮੌਜੂਦ ਹੈ।

ਲਿੰਕ 'ਤੇ ਡਿਲੀਵਰੀ ਅਸਲ ਵਿੱਚ ਕੀ ਮੰਗਦੀ ਹੈ

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

/65 ਕੱਟ ਕੇ ਵੱਖ ਕਰਨਾ ਉਸ ਉਮੀਦ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ। ਅਪਸਟ੍ਰੀਮ ਅਜੇ ਵੀ ਰੇਂਜ ਨੂੰ ਲਿੰਕ 'ਤੇ ਮੰਨਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਦਾ ਮਨ ਬਦਲਣ ਵਾਲੀ ਇੱਕੋ ਚੀਜ਼ ਕੋਈ ਰੂਟ ਜਾਂ ਪ੍ਰੌਕਸੀ ਹੈ ਜੋ ਕਲਾਇੰਟ ਵੱਲੋਂ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਦੋਵੇਂ ਵਿੱਚੋਂ ਕੋਈ ਨਹੀਂ ਦਿਸਦਾ ਕਿਉਂਕਿ ਤੁਸੀਂ VPN ਕਨਫਿਗਰੇਸ਼ਨ ਸੋਧੀ ਹੈ। ਇਹੀ ਖਾਲੀ ਥਾਂ ਦੱਸਦੀ ਹੈ ਕਿ ਪੂਲ ਆਪਣੇ ਹੀ ਕਲਾਇੰਟਾਂ ਵਿਚਕਾਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਕਿਤੇ ਹੋਰੋਂ ਅਪਹੁੰਚ ਕਿਉਂ ਰਹਿ ਸਕਦਾ ਹੈ।

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

ਰੂਟਿਡ ਡਿਲੀਵਰੀ ਕੀ ਮੰਗਦੀ ਹੈ

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

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

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

ਸਹੀ ਕਰਨ ਵਾਲੇ ਦੋ ਸੁਤੰਤਰ ਰੂਟ

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

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

ਉੱਪਰਲਾ ਪ੍ਰੀਫਿਕਸ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਥਾਂ ਹੈ, ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਸਿਰਫ IPv6 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਿ ਡਿਊਲ-ਸਟੈਕ ਤੈਨਾਤੀ ਅਕਸਰ ਤਦ ਚਾਹੁੰਦੀ ਹੈ ਜਦੋਂ IPv6 ਡਿਲੀਵਰੀ ਅਜੇ ਠੀਕ ਕੀਤੀ ਜਾ ਰਹੀ ਹੋਵੇ। IPv4 ਰੀਡਾਇਰੈਕਟ IPv6 ਕਵਰੇਜ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਦੂਜੀ ਨੂੰ ਨਿਹਿਤ ਨਹੀਂ ਕਰਦੀ।

ਤੁਸੀਂ ਜੋ ਵੀ ਨੀਤੀ ਲਾਗੂ ਕਰੋ, IPv6 ਜਿਸ ਕੰਟਰੋਲ ਟ੍ਰੈਫਿਕ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਚੱਲਦਾ ਰੱਖੋ। Packet Too Big ਸੁਨੇਹੇ ਸਿਰਫ TCP ਅਤੇ UDP ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਦਾ ਰਵਾਇਤੀ ਸ਼ਿਕਾਰ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਸੁੱਟਣ ਨਾਲ ਅਜਿਹੇ ਕਨੈਕਸ਼ਨ ਬਣਦੇ ਹਨ ਜੋ ਸਥਾਪਿਤ ਹੋ ਕੇ ਵੱਡੇ ਸਥਾਨਾਂਤਰਣਾਂ 'ਤੇ ਅਟਕ ਜਾਂਦੇ ਹਨ।

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

ਡਿਜ਼ਾਈਨ ਦਰਜ ਕਰੋ ਤਾਂ ਜੋ ਮੁੜ ਨਿਰਮਾਣ ਇਸਨੂੰ ਦੁਹਰਾਏ

ਤਿੰਨ ਚੀਜ਼ਾਂ ਵੱਖਰੀਆਂ ਲਿਖੋ: ਕਲਾਇੰਟ ਅਲਾਟਮੈਂਟ, ਕਲਾਇੰਟ ਦਾ ਟਿਕਾਣਾ ਰੂਟ, ਅਤੇ ਅਲਾਟਮੈਂਟ ਲਈ ਅਪਸਟ੍ਰੀਮ ਦੀ ਡਿਲੀਵਰੀ ਵਿਧੀ। ਤਿੰਨੇ ਰੱਖਣ ਵਾਲਾ ਪਾਠਕ ਤੈਨਾਤੀ ਮੁੜ ਬਣਾ ਸਕਦਾ ਹੈ; ਸਿਰਫ ਪੂਲ ਸੈਟਿੰਗ ਰੱਖਣ ਵਾਲਾ ਪਾਠਕ ਮੂਲ ਬੱਗ ਦੁਹਰਾਏਗਾ।

ਫਿਰ ਵਾਪਸੀ ਦਿਸ਼ਾ ਦੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕਰੋ, ਅਜਿਹੇ ਪੈਕੇਟ ਨਾਲ ਜੋ ਬਾਹਰੋਂ ਵਾਪਸ ਆਉਣਾ ਹੀ ਹੈ। openvpn(8) ਦਸਤਾਵੇਜ਼ server-ipv6 ਅਤੇ redirect ਵਿਕਲਪਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਡੇ ਪ੍ਰਦਾਤਾ ਦੀ ਰੂਟਿੰਗ ਪੁਸ਼ਟੀ ਉਹ ਅੱਧਾ ਹਿੱਸਾ ਕਵਰ ਕਰਦੀ ਹੈ ਜੋ ਦਸਤਾਵੇਜ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ।