Pritunl ਦਾ ਪ੍ਰਾਈਵੇਟ DNS ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ? ਇੱਕ ਤੰਗ resolver ਰੂਟ ਜੋੜੋ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ resolver ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਪੂਲ ਨੂੰ ਰੱਦ ਕਰ ਰਿਹਾ ਹੈ

ਇਹ ਸਾਬਤ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ ਕਿ ਨਾਕਾਮੀ ਸਰੋਤ ਬਾਰੇ ਹੈ, ਪਹੁੰਚ ਬਾਰੇ ਨਹੀਂ। ਜੁੜੇ ਕਲਾਇੰਟ ਤੋਂ ਪ੍ਰਾਈਵੇਟ resolver ਨੂੰ ਸਿੱਧਾ ਕੁਐਰੀ ਕਰੋ ਅਤੇ ਦੇਖੋ ਕਿ ਬੇਨਤੀ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਜਾਂ ਇਨਕਾਰ ਵਜੋਂ ਵਾਪਸ ਆਉਂਦੀ ਹੈ। dig @10.40.0.53 intranet.example.net +time=2 +tries=1 ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣਾ ਜਦਕਿ ਗੇਟਵੇ ਤੋਂ ਉਹੀ ਕੁਐਰੀ ਸਫਲ ਹੁੰਦੀ ਹੈ, resolver ’ਤੇ ਪਹੁੰਚ ਨੀਤੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। SERVFAIL ਜਵਾਬ ਬਿਲਕੁਲ ਹੋਰ ਥਾਂ, ਆਮ ਤੌਰ ’ਤੇ ਜ਼ੋਨ ਜਾਂ ਅੱਪਸਟ੍ਰੀਮ ਫਾਰਵਰਡਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।

ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਨੋਟ ਕਰੋ। ਕਲਾਇੰਟ ’ਤੇ ip -4 addr show tun0, ਜਾਂ ਕੰਸੋਲ ਵਿੱਚ ਦਿਖਾਇਆ ਲੀਜ਼, ਦੱਸਦਾ ਹੈ ਕਿ resolver ਕਿਹੜਾ ਪੂਲ ਦੇਖਦਾ ਹੈ।

ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਾਹ ਬਿਲਕੁਲ ਮੌਜੂਦ ਹੈ। ਜੋ ਰੂਟ resolver ਦਾ ਪਤਾ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ ਉਹ ਪੂਰਵ-ਸ਼ਰਤ ਹੈ, ਹੱਲ ਨਹੀਂ; ਜੇ ਪੈਕਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਤਾਂ ਸਰੋਤ ਨੀਤੀ ਦਾ ਕੋਈ ਵਿਚਾਰ ਨਹੀਂ ਹੁੰਦਾ। ਕਲਾਇੰਟ ’ਤੇ ip route get 10.40.0.53 ਨਾਲ ਇਸ ਦੀ ਜਾਂਚ ਕਰੋ।

ਸਭ ਕੁਝ ਅਨੁਵਾਦ ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ ਹੋਸਟ ਰੂਟ ਜੋੜੋ

Pritunl ਦੀ ਪ੍ਰਾਈਵੇਟ DNS ਗਾਈਡ ਤੰਗ ਉਪਾਅ ਦੱਸਦੀ ਹੈ: resolver ਪਤੇ ਲਈ NAT ਸਮਰੱਥ /32 ਰੂਟ, ਉਹ ਪਤਾ ਕਲਾਇੰਟਾਂ ਦਾ DNS ਸਰਵਰ ਚੁਣ ਕੇ। ਰੂਟ ਸਿਰਫ਼ DNS ਟ੍ਰੈਫਿਕ ਲਈ ਉਹ ਸਰੋਤ ਬਦਲਦਾ ਹੈ ਜੋ resolver ਦੇਖਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਤੁਹਾਡੇ ਵੱਲੋਂ ਇਸ ਲਈ ਚੁਣਿਆ ਸਰੋਤ-ਸੰਭਾਲ ਡਿਜ਼ਾਈਨ ਰੱਖਦਾ ਹੈ।

ਮੌਜੂਦਾ ਰੂਟਾਂ ਦੀ ਓਵਰਲੈਪ ਲਈ ਸਮੀਖਿਆ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਦੇ ਸਮਰਥਿਤ ਰੂਟ ਮਾਲਕ ਰਾਹੀਂ ਇਸ ਨੂੰ ਕਨਫਿਗਰ ਕਰੋ। ਉੱਪਰਲੇ ਉਦਾਹਰਨ ਵਿੱਚ ਮੰਜ਼ਿਲ NAT ਸਮਰੱਥ 10.40.0.53/32 ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਪੂਲ 10.90.0.0/24 ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਸੇਵਾ ਠੀਕ ਕਰਨ ਲਈ ਪੂਰੀ ਪ੍ਰਾਈਵੇਟ ਰੇਂਜ ਦਾ ਅਨੁਵਾਦ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਦੇ ਅਸਲ ਪਤੇ ’ਤੇ ਨਿਰਭਰ ਹਰ ਡਾਊਨਸਟ੍ਰੀਮ ਨੀਤੀ ਇਸ ਦੀ ਬਜਾਏ ਗੇਟਵੇ ਦੇਖਣ ਲੱਗੇਗੀ। ਜਾਂਚ ਖੋਜ ਦੌਰਾਨ resolver ਦਾ ਕੁਐਰੀ ਲੌਗ ਦੇਖ ਕੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪਤਾ ਲੈਂਦਾ ਹੈ। ਸਿਰਫ਼ ਇੱਕ ਹੋਸਟ ਰੂਟ ਅਨੁਵਾਦ ਜਾਂ ਇਜਾਜ਼ਤ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।

Resolver ਨੂੰ ਅਜੇ ਵੀ ਅਨੁਵਾਦਿਤ ਸਰੋਤ ਨੂੰ UDP ਅਤੇ TCP ’ਤੇ ਇਜਾਜ਼ਤ ਦੇਣੀ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਜਵਾਬ ਵਾਪਸ ਆ ਸਕਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਰੋਤ ਬਦਲਣਾ ਗੁੰਮ ਜ਼ੋਨ ਜਾਂ ਰਿਕਾਰਡ ਨਹੀਂ ਬਣਾ ਸਕਦਾ।

ਤੈਅ ਕਰੋ ਕਿ ਕੁਐਰੀ ਸਰਵਰ ਭੇਜਦਾ ਹੈ ਜਾਂ ਕਲਾਇੰਟ

Pritunl VPN Client DNS Mapping ਨਾਲ ਜੁੜੀ DNS-ਪ੍ਰੌਕਸੀ ਵਿਵਸਥਾ ਦਾ ਵੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਸਰਵਰ ਕਲਾਇੰਟਾਂ ਲਈ ਅੱਪਸਟ੍ਰੀਮ ਕੁਐਰੀਆਂ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ। ਉਸ ਮਾਡਲ ਵਿੱਚ ਅੱਪਸਟ੍ਰੀਮ ਸਰੋਤ ਸਰਵਰ ਦੇ ਆਪਣੇ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ-ਪਾਸੇ ਦੀ ਛੋਟ ਗਲਤ ਹੱਲ ਹੈ।

ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣੋ ਕਿ ਕਿਹੜਾ ਮਾਡਲ ਸਰਗਰਮ ਹੈ। ਤਿੰਨ ਓਵਰਲੈਪਿੰਗ ਮੁਰੰਮਤਾਂ, ਇੱਕ ਪ੍ਰੌਕਸੀ, ਕਲਾਇੰਟ ’ਤੇ resolver ਬਦਲਣਾ ਅਤੇ ਇੱਕ ਹੱਥੀ NAT ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ ’ਤੇ ਭਾਵ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਸਥਾਪਿਤ ਨਹੀਂ ਕੀਤਾ: ਕਿਹੜਾ ਹਿੱਸਾ ਕੁਐਰੀ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। bootstrap ਵੀ ਜਾਂਚੋ: ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਐਂਡਪੌਇੰਟ ਲੱਭਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਸਿਰਫ਼-ਪ੍ਰਾਈਵੇਟ resolver ਨਹੀਂ ਹੋ ਸਕਦਾ, ਅਤੇ ਸਥਾਈ resolver ਬਦਲਾਅ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਧ ਨਹੀਂ ਰਹਿਣਾ ਚਾਹੀਦਾ।

ਜਨਤਕ ਵੈੱਬ ਪੰਨਾ ਨਹੀਂ, ਪ੍ਰਾਈਵੇਟ ਖੋਜ ਦੀ ਜਾਂਚ ਕਰੋ

ਬਦਲਾਅ ਲਾਗੂ ਕਰਕੇ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕਲਾਇੰਟ ਦੀ ਪ੍ਰਭਾਵੀ resolver ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਅਜਿਹਾ ਨਾਮ ਹੱਲ ਕਰੋ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਇਹ ਸਿਰਫ਼ ਪ੍ਰਾਈਵੇਟ ਜ਼ੋਨ ਵਿੱਚ ਹੈ। ਸਪਸ਼ਟ ਸਰਵਰ ਤੋਂ ਬਿਨਾਂ dig intranet.example.net ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਉਸ ਪਤੇ ’ਤੇ ਬੇਨਤੀ ਭੇਜੋ ਜੋ ਉਸ ਖੋਜ ਨੇ ਵਾਪਸ ਕੀਤਾ, ਕਿਉਂਕਿ ਹੱਲ ਅਤੇ ਸੇਵਾ ਪਹੁੰਚ ਵੱਖਰੇ ਕਦਮ ਹਨ। DNS-over-HTTPS ਰਾਹੀਂ ਜਨਤਕ ਸਾਈਟਾਂ ਲੋਡ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਪ੍ਰਾਈਵੇਟ resolver ਰਾਹ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਜਨਤਕ ਸੈਕੰਡਰੀ resolver ਵੀ ਅੰਦਰੂਨੀ ਜ਼ੋਨ ਲਈ ਅਧਿਕਾਰ ਨਹੀਂ ਹੈ।

Resolver ਪਤਾ, /32 ਰੂਟ ਅਤੇ ਕਲਾਇੰਟ DNS ਸੈਟਿੰਗ ਇਕੱਠੇ ਸਰਵਰ ਨੋਟਾਂ ਵਿੱਚ ਦਰਜ ਕਰੋ। ਉਸ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਅੱਧਾ ਹਿੱਸਾ ਇਕੱਲਾ ਬਹਾਲ ਕਰਨ ’ਤੇ ਮੂਲ ਨਾਕਾਮੀ ਦੁਬਾਰਾ ਹੁੰਦੀ ਹੈ।

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