ਡੁਅਲ-ਸਟੈਕ VPN: ਐਡਰੈਸ ਫੈਮਲੀ ਕਲਾਇੰਟ ਚੁਣਦਾ ਹੈ, ਤੁਸੀਂ ਨਹੀਂ

ਟਨਲ ਚੱਲ ਰਹੀ ਹੈ, IPv4 ਸਾਈਟਾਂ ਲੋਡ ਹੋ ਰਹੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਹੋਸਟਨਾਮ ਦਾ ਸਮਾਂ ਖਤਮ ਹੋ ਰਿਹਾ ਹੈ। ਤੁਰੰਤ ਸਿੱਟਾ ਇਹ ਨਿਕਲਦਾ ਹੈ ਕਿ VPN ਖਰਾਬ ਹੈ ਜਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਗਲਤ ਹਨ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਨਾਮ ਨੇ IPv4 ਅਤੇ IPv6 ਦੋਵੇਂ ਪਤੇ ਵਾਪਸ ਕੀਤੇ, ਐਪ ਨੇ ਇੱਕ ਚੁਣਿਆ, ਅਤੇ ਉਨ੍ਹਾਂ ਉਮੀਦਵਾਰਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਦਾ ਹੀ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਸਤਾ ਸੀ। ਚੋਣ ਦਾ ਫੈਸਲਾ ਕਲਾਇੰਟ ਨੇ ਲਿਆ; ਟਨਲ ਨੇ ਬੱਸ ਉਹ ਨਹੀਂ ਢਕਿਆ ਜੋ ਉਸਨੇ ਚੁਣਿਆ ਸੀ।

ਚੋਣ ਕਵਰੇਜ ਦਾ ਵਾਅਦਾ ਨਹੀਂ ਹੈ

RFC 6724 ਵਿੱਚ ਵਰਣਿਤ ਡਿਫਾਲਟ ਐਡਰੈਸ ਚੋਣ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕਈ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਹੋਸਟ ਕਿਹੜੀ ਸਰੋਤ-ਟਿਕਾਣਾ ਜੋੜੀ ਨੂੰ ਤਰਜੀਹ ਦੇਵੇਗਾ। Happy Eyeballs ਉਸ ਉੱਤੇ ਕਨੈਕਸ਼ਨ ਰਣਨੀਤੀ ਜੋੜਦਾ ਹੈ: ਦੋਵੇਂ ਫੈਮਲੀ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ਾਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਜੋ ਪਹਿਲਾਂ ਜਵਾਬ ਦੇਵੇ ਉਸਨੂੰ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਵਰਤੋਂਕਾਰ ਨੂੰ ਖਰਾਬ ਫੈਮਲੀ ਦੇ ਟਾਈਮਆਊਟ ਦੀ ਉਡੀਕ ਨਾ ਕਰਨੀ ਪਵੇ।

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

ਉਸੇ ਪਿੱਛੇ ਹਟਣ ਕਾਰਨ ਲੱਛਣ ਐਪਾਂ ਵਿੱਚ ਅਸੰਗਤ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਦੇਰੀ ਲੁਕਾਉਂਦਾ ਹੈ; ਸਥਿਰ ਫੈਮਲੀ ਵਾਲਾ ਕਮਾਂਡ-ਲਾਈਨ ਕਲਾਇੰਟ ਅਸਲ ਫੇਲ੍ਹਤਾ ਤੁਰੰਤ ਦਿਖਾਉਂਦਾ ਹੈ।

ਪਤਾ ਲਗਾਓ ਕਿ ਬੇਨਤੀ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਫੈਮਲੀ ਵਰਤੀ

ਟਨਲ ਤੋਂ ਨਹੀਂ, ਨਾਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਦੋਵੇਂ ਰਿਕਾਰਡ ਕਿਸਮਾਂ ਪੁੱਛੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕੀ ਵਾਪਸ ਆਇਆ:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

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

ਉਸ ਫੈਮਲੀ ਲਈ ਰਸਤਾ ਜਾਂਚੋ

ਫੇਲ ਹੋ ਰਹੀ ਫੈਮਲੀ ਲਈ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿਹੜਾ ਰਸਤਾ ਵਰਤੇਗਾ ਅਤੇ ਉਸਦੀ ਟਨਲ ਦੇ ਸੰਰਚਿਤ ਪਤਿਆਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। Linux 'ਤੇ, ip -6 route get ਟਿਕਾਣੇ ਲਈ ਚੁਣਿਆ ਜਾਣ ਵਾਲਾ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਦਿਖਾਉਂਦਾ ਹੈ।

ਫਿਰ ਟਨਲ ਦੀ ਆਪਣੀ ਜਾਂਚ ਕਰੋ। WireGuard ਪੀਅਰ ਮਨਜ਼ੂਰ IP ਦੀ ਸੂਚੀ ਰੱਖਦੇ ਹਨ, ਅਤੇ 0.0.0.0/0 ਲਈ ਐਂਟਰੀ IPv6 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਜੇ ਪੀਅਰ ਦੀ ਸੂਚੀ ਵਿੱਚ IPv6 ਪ੍ਰੀਫਿਕਸ ਨਹੀਂ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਕੋਲ AAAA ਟ੍ਰੈਫਿਕ ਟਨਲ ਵਿੱਚ ਭੇਜਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ, ਅਤੇ ਪੈਕਟ ਹੋਸਟ ਦੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਜਾਣ ਵਾਲੇ ਰਸਤੇ ਰਾਹੀਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ।

ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ NAT ਨੀਤੀ ਹਰ ਫੈਮਲੀ ਲਈ ਉਸੇ ਜਾਂਚ ਦੇ ਯੋਗ ਹਨ। IPv4 ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਕਿਸੇ ਵੀ ਪਲੇਟਫਾਰਮ 'ਤੇ IPv6 ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇੱਕ ਫੈਮਲੀ ਦੇ ਕੰਮ ਕਰਨ ਅਤੇ ਦੂਜੀ ਦੇ ਨਾ ਕਰਨ ਦਾ ਇਹੀ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।

ਸਕ੍ਰੀਨਸ਼ਾਟ ਸੌਖਾ ਕਰਨ ਲਈ IPv6 ਬੰਦ ਨਾ ਕਰੋ

ਸਿਸਟਮ ਭਰ ਵਿੱਚ IPv6 ਬੰਦ ਕਰਨ ਨਾਲ ਲੱਛਣ ਗਾਇਬ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਤੁਸੀਂ ਨਿਦਾਨ ਤੋਂ ਬਿਨਾਂ ਰਹਿ ਜਾਵੋਗੇ। ਇਹ ਸਿਰਫ IPv6 ਵਾਲੇ ਕਿਸੇ ਵੀ ਟਿਕਾਣੇ ਨੂੰ ਵੀ ਤੋੜਦਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਐਪ ਲਈ ਉਹੀ ਬੱਗ ਲੁਕਾਉਂਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਮਸ਼ੀਨ ਨੂੰ ਸੱਚਮੁੱਚ IPv6 ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੀਦਾ, ਤਾਂ ਉਹ ਮਾਲਕ ਅਤੇ ਟੈਸਟ ਵਾਲੀ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਈ ਨੀਤੀ ਹੈ। ਘਟਨਾ ਦੇ ਸਮੇਂ ਇਸਨੂੰ ਬੰਦ ਕਰਨਾ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ।

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

ਟਿਕਟ ਵਿੱਚ ਕੀ ਲਿਖਣਾ ਹੈ

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

RFC 6724 ਐਡਰੈਸ ਚੋਣ ਨਿਯਮ ਦੱਸਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਨੇ ਉਸ ਉਮੀਦਵਾਰ ਨੂੰ ਕਿਉਂ ਤਰਜੀਹ ਦਿੱਤੀ, ਅਤੇ RFC 8305 ਉਸ ਦੌੜ ਵਾਲੇ ਵਿਵਹਾਰ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ ਜਿਸਨੇ ਦੇਰੀ ਲੁਕਾਈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤੁਹਾਡੇ ਲਈ ਪੈਕਟ ਰੂਟ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਟਨਲ ਨੂੰ ਇਹੀ ਹਿੱਸਾ ਕਰਨਾ ਹੈ।