dnsmasq ਵਿੱਚ ਤੁਹਾਡਾ VPN ਡੋਮੇਨ ਜ਼ੋਨ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਹੈ

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

ਕਲਾਇੰਟ ਨੇ ਜੋ ਸਵੀਕਾਰ ਕੀਤਾ ਉਹ ਉਹ ਨਹੀਂ ਜੋ ਗੇਟਵੇ ਨੇ ਪੇਸ਼ ਕੀਤਾ

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

ਇਹ ਫ਼ਰਕ ਕਦੇ ਨਾ ਆਏ ਡੋਮੇਨ ਦੀਆਂ ਬਹੁਤੀਆਂ ਰਿਪੋਰਟਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ। ਇਹ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ।

ਡੋਮੇਨ ਐਂਟਰੀ ਦੀਆਂ ਦੋ ਕਿਸਮਾਂ

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

ਨਿੱਜੀ ਨਾਮਸਥਾਨ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼-ਰਾਹ ਰੂਪ ਹੀ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਕਾਰਪੋਰੇਟ ਸਫਿਕਸ ਨੂੰ ਕਾਰਪੋਰੇਟ resolver ਵੱਲ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।

resolv.conf ਵਿੱਚ localhost ਕੋਈ ਬੱਗ ਨਹੀਂ ਹੈ

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

ਉਸ ਐਂਟਰੀ ਨੂੰ ਜਨਤਕ resolver ਨਾਲ ਬਦਲਣਾ ਕਲਾਸਿਕ ਗਲਤ ਸੁਧਾਰ ਹੈ। ਇਹ ਜਨਤਕ ਨਾਮ ਹੱਲ ਬਹਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸੇ ਸੰਪਾਦਨ ਵਿੱਚ ਸ਼ਰਤੀ ਨੀਤੀ ਤਿਆਗ ਦਿੰਦਾ ਹੈ।

ਬੈਕਐਂਡ ਨੂੰ ਨਾ ਮਿਲਾਓ

ਪ੍ਰਬੰਧਿਤ dnsmasq ਇੰਸਟੈਂਸ ਅਤੇ ਸਿਸਟਮ resolver ਵੱਖਰੀ ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਵੱਖਰੇ ਸਥਿਤੀ ਨਜ਼ਾਰਿਆਂ ਵਾਲੇ ਵੱਖਰੇ ਪ੍ਰੋਗਰਾਮ ਹਨ। ਇੱਕ ਲਈ ਸਥਿਤੀ ਕਮਾਂਡ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਵੀ ਲਾਭਦਾਇਕ ਨਹੀਂ ਦੱਸਦੀ।

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

ਨਾਮਸਥਾਨ ਦੀ ਪਰਖ ਕਰੋ, ਸਿਰਫ਼ ਜਵਾਬ ਦੀ ਨਹੀਂ

ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਮ ਰਾਹ ਰਾਹੀਂ ਇੱਕ ਮਨਜ਼ੂਰ ਨਿੱਜੀ ਨਾਮ ਅਤੇ ਇੱਕ ਜਨਤਕ ਨਿਯੰਤਰਣ ਨਾਮ ਪੁੱਛੋ। ਕਾਰਪੋਰੇਟ ਸਰਵਰ 'ਤੇ ਸਿੱਧੀ ਕਿਊਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕਲਾਇੰਟ ਨੇ ਉਹ ਸਰਵਰ ਚੁਣਿਆ। ਦੂਜੀ ਕਿਊਰੀ ਹੀ ਨੀਤੀ ਦੀ ਪਰਖ ਕਰਦੀ ਹੈ।

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