VPN ਪੋਰਟ 53 ’ਤੇ ਬਲੌਕ ਹੋਣ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਤਿੰਨ ਅਜਿਹੇ ਨਿਰੀਖਣ ਰਲਾਉਂਦੀਆਂ ਹਨ ਜੋ ਵੱਖਰੇ ਕਾਰਨਾਂ ਕਰਕੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਐਂਡਪੁਆਇੰਟ ਦਾ ਨਾਮ ਹੱਲ ਕਰਨਾ ਕਿਸੇ ਟਨਲ ਦੇ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ, ਐਨਕ੍ਰਿਪਟਿਡ ਟਰਾਂਸਪੋਰਟ ਵੱਖਰੀ ਗੱਲਬਾਤ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਕੀਤੀਆਂ DNS ਪੁੱਛਗਿੱਛਾਂ ਤੀਜੀ ਹਨ। ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਫੇਲ੍ਹਤਾ ਦੀ ਨਿਸ਼ਾਨੀ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ DNS ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਮਕਸਦ ਅਨੁਸਾਰ ਵੱਖ ਕਰੋ, ਕਿਉਂਕਿ ਹੱਲ ਪੜਾਅ ਦੇ ਪਿੱਛੇ ਚੱਲਦਾ ਹੈ।

ਤਿੰਨ ਗੱਲਬਾਤਾਂ, ਇੱਕ ਪੋਰਟ ਨੰਬਰ

ਪਹਿਲੀ ਗੱਲਬਾਤ ਐਂਡਪੁਆਇੰਟ ਲਈ ਨਾਮ ਦੀ ਖੋਜ ਹੈ: ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਆਪਣੇ ਸੰਰਚਿਤ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਪੁੱਛਦੀ ਹੈ ਕਿ vpn.example.com ਕਿੱਥੇ ਹੈ, ਅਤੇ ਉਹ ਜਵਾਬ ਕਲਾਇੰਟ ਦੇ ਇੱਕ ਵੀ ਟਨਲ ਪੈਕਟ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਆਮ DNS ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ। ਦੂਜੀ OpenVPN ਟਰਾਂਸਪੋਰਟ ਆਪ ਹੈ, ਜੋ ਖੋਜ ਵੱਲੋਂ ਦਿੱਤੇ ਪਤੇ ’ਤੇ ਉਸੇ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ ’ਤੇ ਜੁੜਦਾ ਹੈ ਜੋ ਪ੍ਰੋਫਾਈਲ ਦੱਸਦੀ ਹੈ। ਤੀਜੀ ਟਨਲ ਉੱਠਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨਾਮ ਮੰਗਦੇ ਹਨ ਅਤੇ ਭੇਜੀਆਂ ਰਿਜ਼ੋਲਵਰ ਸੈਟਿੰਗਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਜਵਾਬ ਕੌਣ ਦੇਵੇਗਾ।

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

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

ਟੇਬਲ ਨੂੰ ਵਰਣਨ ਵਜੋਂ ਨਹੀਂ, ਜਾਂਚ-ਸੂਚੀ ਵਜੋਂ ਪੜ੍ਹੋ। ਜੇ ਐਂਡਪੁਆਇੰਟ ਦਾ ਨਾਮ ਹੱਲ ਨਾ ਹੋਵੇ, ਤਾਂ ਅੱਗੇ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਟਨਲ ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ।

ਪੋਰਟ ਨੰਬਰ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਾਮ ਨਹੀਂ ਦਿੰਦਾ

ਪੋਰਟ 53 ਰਵਾਇਤ ਅਨੁਸਾਰ DNS ਢੋਂਦਾ ਹੈ, ਅਤੇ OpenVPN ਓਪਰੇਟਰ ਉੱਥੇ ਸਰੋਤਾ ਵੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਇਸੇ ਕਰਕੇ ਇਹ ਨੰਬਰ ਕਮਜ਼ੋਰ ਪਛਾਣ ਹੈ। UDP 53 ’ਤੇ OpenVPN ਸੈਸ਼ਨ ਅਜੇ ਵੀ OpenVPN ਸੈਸ਼ਨ ਹੈ, ਅਤੇ ਪੋਰਟ 53 ਦੇ ਸਰਵਰ ਨੂੰ ਕੀਤੀ DNS ਪੁੱਛਗਿੱਛ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ ਕਿ ਟਨਲ ਦੀ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ। ਪ੍ਰੋਫਾਈਲ ਦੀਆਂ proto ਅਤੇ remote ਲਾਈਨਾਂ ਬਾਹਰੀ ਐਂਡਪੁਆਇੰਟ ਤੈਅ ਕਰਦੀਆਂ ਹਨ; ਪੋਰਟ ਨੰਬਰ ਆਪ ਕੁਝ ਨਹੀਂ ਤੈਅ ਕਰਦਾ।

ਨਿਦਾਨ ਵੇਲੇ ਇਹ ਦੋਵੇਂ ਪਾਸੇ ਕੱਟਦਾ ਹੈ: ਪੋਰਟ 53 ’ਤੇ ਆਮ UDP ਪਰਖ ਦੱਸਦੀ ਹੈ ਕਿ ਪੋਰਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ VPN ਸੇਵਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਅਸਲੀ ਕਲਾਇੰਟ ਅਤੇ ਅਸਲੀ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਟੈਸਟ ਕਰੋ, ਕਿਉਂਕਿ ਸੇਵਾ ਜਿਸ ਹੈਂਡਸ਼ੇਕ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ ਉਹ ਸਿਰਫ਼ ਉਹੀ ਅਭਿਆਸ ਕਰਾਉਂਦਾ ਹੈ।

ਨੈੱਟਵਰਕ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਾ ਸਾਬਤ ਕਰੋ

ਸਰਵਰ ’ਤੇ ss -lunp | grep 53 ਨਾਲ ਜਾਂਚੋ ਕਿ ਕੀ ਬੱਝਿਆ ਹੈ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਕਲਾਇੰਟ ਦੇ ਨੈੱਟਵਰਕ ਤੋਂ, ਕਲਾਇੰਟ ਨੂੰ ਵਧੇਰੇ ਵੇਰਵੇ ਨਾਲ ਚਲਾਓ ਤਾਂ ਜੋ ਲੌਗ ਦਿਖਾਏ ਕਿ ਉਸਨੇ ਕਿਹੜਾ ਪਤਾ ਅਤੇ ਟਰਾਂਸਪੋਰਟ ਅਜ਼ਮਾਇਆ। ਜੇ ਸਰਵਰ ਸੁਣ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਪੈਕਟ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਤਾਂ ਮਾਰਗ ਜਾਂ ਨੀਤੀ ਉਨ੍ਹਾਂ ਨੂੰ ਮਨ੍ਹਾਂ ਕਰ ਰਹੀ ਹੈ, ਅਤੇ ਇਹ ਨੈੱਟਵਰਕ ਮਾਲਕ ਨਾਲ ਗੱਲਬਾਤ ਹੈ, ਪੋਰਟ ਬਦਲਣ ਦਾ ਕਾਰਨ ਨਹੀਂ।

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

ਟਨਲ ਤੋਂ ਬਾਅਦ DNS ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ

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

DNS ਬਦਲਾਅ ਰਿਜ਼ੋਲਵਰ ਮਾਲਕ ਕੋਲ ਰੱਖੋ। ਇੱਕ ਟੈਸਟ ਪਾਸ ਕਰਾਉਣ ਲਈ ਪ੍ਰਬੰਧਿਤ ਰਿਜ਼ੋਲਵਰ ਸੰਰਚਨਾ ਉੱਤੇ ਲਿਖਣਾ ਮਸ਼ੀਨ ’ਤੇ ਬਾਕੀ ਸਭ ਲਈ ਨਿੱਜੀ ਨਾਮ ਤੋੜ ਸਕਦਾ ਹੈ। ਜੇ ਟਨਲ ਰਿਜ਼ੋਲਵਰ ਭੇਜਦੀ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਉਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਿਤੇ ਹੋਰ ਸਥਿਰ ਐਂਟਰੀ ਜੋੜਨ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਏਕੀਕਰਨ ਠੀਕ ਕਰੋ। ਸਥਿਰ ਐਂਟਰੀਆਂ ਫੇਲ੍ਹਤਾ ਨੂੰ ਉਦੋਂ ਤੱਕ ਲੁਕਾਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਤੱਕ ਕੋਈ ਨੈੱਟਵਰਕ ਨਾ ਬਦਲੇ। ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਕਿਹੜੇ ਨਾਮ-ਖੇਤਰ ਦਾ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ