VPN DNS ਰਿਪੋਰਟ: ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਯੋਗ ਬਣਾਉਣ ਲਈ ਕੀ ਸ਼ਾਮਲ ਕਰੀਏ

«DNS ਟੁੱਟਾ ਹੋਇਆ ਹੈ» ਇੱਕ ਸਿੱਟਾ ਹੈ, ਅਤੇ ਇਹ ਅਜਿਹਾ ਸਿੱਟਾ ਨਹੀਂ ਜਿਸ ਉੱਤੇ ਸਹਾਇਕ ਕੁਝ ਕਰ ਸਕੇ। ਰਿਪੋਰਟ ਦਾ ਉਪਯੋਗੀ ਹਿੱਸਾ ਅਸਫਲਤਾ ਦਾ ਆਕਾਰ ਹੈ: ਕਿਹੜਾ ਨਾਮ, ਕਿਹੜੇ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ, ਕਿਹੜੇ ਜਵਾਬ ਨਾਲ। ਤਿੰਨ ਵੇਰਵੇ ਸ਼ਿਕਾਇਤ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਨਿੱਜੀ ਹਿੱਸਿਆਂ ਦੇ ਨਾਮ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਤਿੰਨੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਾਂਝੇ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਅੱਗੇ ਉਹ ਘੱਟੋ-ਘੱਟ ਹੈ ਜੋ ਕਿਸੇ ਦੇ ਮਦਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ VPN DNS ਰਿਪੋਰਟ ਨੂੰ ਚਾਹੀਦਾ ਹੈ।

ਨਾਮ ਦੀ ਸ਼੍ਰੇਣੀ, ਫੈਸਲਾ ਨਹੀਂ

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

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

ਰਿਜ਼ੋਲਵਰ ਮਾਰਗ ਦਰਜ ਕਰੋ

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

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

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

ਨਿਯੰਤਰਿਤ ਤੁਲਨਾ ਦੱਸੋ

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

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

ਨੇਮਸਪੇਸ ਲੁਕਾਓ, ਸੰਬੰਧ ਰੱਖੋ

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

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