resolvectl ਆਉਟਪੁੱਟ ਤੋਂ ਹਰ ਲਿੰਕ ਲਈ VPN DNS ਰਾਊਟਿੰਗ ਕਿਵੇਂ ਪੜ੍ਹੀਏ
resolvectl status ਹਰ ਲਿੰਕ ਲਈ ਸਰਵਰ, ਡੋਮੇਨ ਅਤੇ ਡਿਫਾਲਟ ਰੂਟ ਦਿਖਾਉਂਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਨੂੰ ਇਕੱਠੇ ਪੜ੍ਹੋ, ਫਿਰ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਜਵਾਬ ਦਿੱਤਾ।
resolvectl status ਚਲਾਓ ਅਤੇ ਤੁਹਾਨੂੰ ਹਰ ਲਿੰਕ ਲਈ ਬਲਾਕਾਂ ਦੀ ਕੰਧ ਮਿਲੇਗੀ, ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਸਰਵਰ ਅਤੇ ਆਪਣੀ ਡੋਮੇਨ ਲਾਈਨ ਹੁੰਦੀ ਹੈ। ਰਾਊਟਿੰਗ ਤੈਅ ਕਰਨ ਵਾਲੀ ਲਾਈਨ ਡੋਮੇਨ ਸੂਚੀ ਹੈ, ਨੇਮਸਰਵਰ ਦਾ ਪਤਾ ਨਹੀਂ, ਕਿਉਂਕਿ ਸਥਾਨਕ ਸਟਬ ਹਰ ਪ੍ਰਸ਼ਨ ਉਸ ਲਿੰਕ ਨੂੰ ਭੇਜਦਾ ਹੈ ਜੋ ਨਾਮ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਜਵਾਬ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਦਾਅਵੇ ਪੜ੍ਹੋ, ਫਿਰ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਜਾਂਚੋ ਕਿ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਇਹ ਬਣਾਇਆ। ਸਹੀ ਲਿੰਕ ਤੋਂ ਗਲਤ ਜਵਾਬ ਗਲਤ ਲਿੰਕ ਤੋਂ ਸਹੀ ਜਵਾਬ ਨਾਲੋਂ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ।
ਹਰ ਲਿੰਕ ਬਲਾਕ ਤੁਹਾਨੂੰ ਕੀ ਦੱਸਦਾ ਹੈ
ਹਰ ਬਲਾਕ ਉਹ ਸਰਵਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ ਜੋ ਰਿਜ਼ਾਲਵਰ ਉਸ ਇੰਟਰਫੇਸ ਲਈ ਵਰਤੇਗਾ, ਡੋਮੇਨ ਸੂਚੀ ਅਤੇ ਕਿ ਲਿੰਕ ਡਿਫਾਲਟ ਰੂਟ ਹੈ ਜਾਂ ਨਹੀਂ। ਡੋਮੇਨ ਸੂਚੀ ਦਾਅਵਿਆਂ ਦਾ ਸਮੂਹ ਹੈ ਅਤੇ ਰਿਜ਼ਾਲਵਰ ਸਭ ਤੋਂ ਲੰਬੇ ਪ੍ਰਤਿਅ ਦੀ ਮੇਲ ਲਾਉਂਦਾ ਹੈ: host.corp.example ਲਈ ਪ੍ਰਸ਼ਨ corp.example ਵਾਲਾ ਲਿੰਕ ਪਹਿਲਾਂ ਦਾਅਵਾ ਕਰਦਾ ਹੈ, ਸਿਰਫ਼ ਡਿਫਾਲਟ ਰੂਟ ਵਾਲੇ ਲਿੰਕ ਤੋਂ ਪਹਿਲਾਂ। ਇੱਕੋ ਪ੍ਰਤਿਅ ਦਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲੇ ਦੋ ਲਿੰਕ ਨਤੀਜਾ ਤਰਜੀਹ ਅਤੇ ਕ੍ਰਮ ਉੱਤੇ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਨਕਲਾਂ ਪਹਿਲਾਂ ਧਿਆਨ ਦੇਣਯੋਗ ਹਨ। ਮੌਜੂਦਾ ਸਰਵਰ ਲਾਈਨ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਸੂਚੀਬੱਧ ਸਰਵਰਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਉਸ ਪਲ ਵਰਤੋਂ ਵਿੱਚ ਹੈ।
/etc/resolv.conf ਵਿੱਚ 127.0.0.53 ਵਰਗਾ ਸਟਬ ਪਤਾ ਸਿਰਫ਼ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਸਟਬ ਅੱਗੇ ਹੈ। ਇਹ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਉੱਪਰਲੇ ਸਰੋਤ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈਂਦਾ, ਇਸ ਲਈ ਸਿਰਫ਼ resolv.conf ਉੱਤੇ ਆਧਾਰਿਤ ਨਿਦਾਨ ਅਟਕ ਜਾਂਦਾ ਹੈ।
ਤਿੰਨ ਕਿਸਮਾਂ ਦੀਆਂ ਡੋਮੇਨ ਐਂਟਰੀਆਂ ਠੀਕ ਤਰ੍ਹਾਂ ਪੜ੍ਹੋ
| ਐਂਟਰੀ | ਕੀ ਦਾਅਵਾ ਕਰਦੀ ਹੈ | ਆਮ ਗਲਤੀ |
|---|---|---|
| corp.example | ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਅਤੇ ਖੋਜ ਪ੍ਰਤਿਅ: ਇਸ ਹੇਠਲੇ ਨਾਮ ਇਸ ਲਿੰਕ ਉੱਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸਟ੍ਰਿੰਗ ਨੰਗੇ ਨਾਮਾਂ ਵਿੱਚ ਜੋੜੀ ਜਾਂਦੀ ਹੈ | ਹਟਾਈ ਗਈ ਕਿਉਂਕਿ ਰਾਊਟਿੰਗ ਫਿਰ ਵੀ ਕੰਮ ਕਰਦੀ ਜਾਪਦੀ ਹੈ |
| ~corp.example | ਸਿਰਫ਼ ਰੂਟ: ਇਸ ਹੇਠਲੇ ਨਾਮ ਇਸ ਲਿੰਕ ਉੱਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਪ੍ਰਤਿਅ ਨਹੀਂ ਜੋੜਿਆ ਜਾਂਦਾ | ਰਾਊਟਿੰਗ ਲਈ ਲੋੜੀਂਦਾ ਮੰਨਿਆ ਗਿਆ |
| ~. | ਡਿਫਾਲਟ ਰੂਟ: ਉਹ ਪ੍ਰਸ਼ਨ ਦਾਅਵਾ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਕੋਈ ਹੋਰ ਲਿੰਕ ਨਹੀਂ ਮਿਲਦਾ | ਵੰਡੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਸਰਗਰਮ ਛੱਡਿਆ, ਇਸ ਲਈ ਜਨਤਕ ਨਾਮ ਟਨਲ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ |
ਟਿਲਡਾ ਖੋਜ ਦਾ ਵਿਵਹਾਰ ਬਦਲਦਾ ਹੈ, ਰਾਊਟਿੰਗ ਨਹੀਂ। ਟਿਲਡਾ ਤੋਂ ਬਿਨਾਂ ਐਂਟਰੀ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਅਤੇ ਖੋਜ ਡੋਮੇਨ ਦੋਵੇਂ ਹੈ, ਇਸ ਲਈ ਇਸ ਹੇਠਲੇ ਨਾਮ ਉਸ ਲਿੰਕ ਉੱਤੇ ਭੇਜੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ-ਲੇਬਲ ਨਾਮਾਂ ਵਿੱਚ ਪ੍ਰਤਿਅ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਟਿਲਡਾ ਐਂਟਰੀ ਉਹੀ ਪ੍ਰਤਿਅ ਰਾਊਟ ਕਰਦੀ ਹੈ ਪਰ ਇਸਨੂੰ ਖੋਜ ਸੂਚੀ ਤੋਂ ਬਾਹਰ ਰੱਖਦੀ ਹੈ। ਇਸ ਲਈ ਟਿਲਡਾ ਹਟਾਉਣ ਨਾਲ ਬਦਲਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਨੰਗੇ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਟਿਲਡਾ ਨਾ ਹੋਣਾ ਖੋਜ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਵੰਡੇ DNS ਦੀ ਅਸਫਲਤਾ ਨਹੀਂ।
ਡਿਫਾਲਟ ਰੂਟ ਐਂਟਰੀ ਉਹ ਸਭ ਦਾਅਵਾ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਹੋਰ ਲਿੰਕ ਨਹੀਂ ਢਕਦਾ। ਪੂਰਾ-ਟਨਲ ਪ੍ਰੋਫਾਈਲ ਆਮ ਤੌਰ ਤੇ ਇਹ ਚਾਹੁੰਦਾ ਹੈ ਅਤੇ ਵੰਡਿਆ ਪ੍ਰੋਫਾਈਲ ਆਮ ਤੌਰ ਤੇ ਨਹੀਂ, ਕਿਉਂਕਿ ਫਿਰ ਜਨਤਕ ਨਾਮ ਨਿੱਜੀ ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉੱਥੇ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹਨ। ਪ੍ਰੋਫਾਈਲਾਂ ਵਿਚਕਾਰ ਫਲੈਗ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਪ੍ਰੋਫਾਈਲ ਦੇ ਇਰਾਦੇ ਦੇ ਸਾਹਮਣੇ ਸਾਰਣੀ ਪੜ੍ਹੋ। ਜਦੋਂ ਦੋ ਲਿੰਕ ਇੱਕੋ ਪ੍ਰਤਿਅ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਕੁਝ ਹੋਰ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਤਰਜੀਹ ਦਾ ਸਵਾਲ ਨਿਪਟਾਓ।
ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਵੇਖੋ ਕਿਹੜੇ ਲਿੰਕ ਨੇ ਜਵਾਬ ਦਿੱਤਾ
query ਉਪ-ਕਮਾਂਡ ਪਤਾ, ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਉਹ ਲਿੰਕ ਜਾਂ ਦਾਇਰਾ ਛਾਪਦੀ ਹੈ ਜਿਸਨੇ ਜਵਾਬ ਬਣਾਇਆ। ਨਿੱਜੀ ਪ੍ਰਤਿਅ ਦੁਆਰਾ ਦਾਅਵਾ ਕਰਨ ਯੋਗ ਇੱਕ ਨਾਮ ਅਤੇ ਇੱਕ ਆਮ ਜਨਤਕ ਨਾਮ ਪਰਖੋ, ਫਿਰ ਦੱਸੇ ਸਰੋਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਨਿੱਜੀ ਨਾਮ ਵਾਇਰਲੈਸ ਲਿੰਕ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਦਾਅਵਾ ਨਹੀਂ ਹੈ ਜਾਂ ਟਨਲ ਬੰਦ ਹੈ; ਜੇ ਵੰਡੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਜਨਤਕ ਨਾਮ ਟਨਲ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਡਿਫਾਲਟ ਰੂਟ ਬਹੁਤ ਚੌੜਾ ਹੈ। ਇਹ ਦੋ ਅਸਫਲਤਾਵਾਂ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਅਤੇ ਇਸ ਆਉਟਪੁੱਟ ਵਿੱਚ ਉਲਟੀਆਂ ਦਿਸਦੀਆਂ ਹਨ।
resolvectl status
resolvectl query host.corp.exampleਦੱਸੇ ਪ੍ਰੋਟੋਕਾਲ ਵੱਲ ਵੀ ਧਿਆਨ ਦਿਓ, ਕਿਉਂਕਿ ਕੈਸ਼ ਜਾਂ ਹੋਸਟ-ਫਾਈਲ ਤੋਂ ਜਵਾਬ ਕਿਸੇ ਵੀ ਉੱਪਰਲੇ ਸਰੋਤ ਨੂੰ ਪੁੱਛੇ ਬਿਨਾਂ ਆ ਸਕਦਾ ਹੈ। ਕੈਸ਼ ਤੋਂ ਜਵਾਬ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਨਾਮ ਕਦੇ ਹੱਲ ਹੋਇਆ ਸੀ, ਇਹ ਨਹੀਂ ਕਿ ਮੌਜੂਦਾ ਨੀਤੀ ਇਸਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਰਾਊਟ ਕਰਦੀ ਹੈ।
ਨਾਮ ਰਾਊਟਿੰਗ ਨੂੰ ਪੈਕਟ ਰਾਊਟਿੰਗ ਤੋਂ ਵੱਖ ਰੱਖੋ
ਰਿਜ਼ਾਲਵਰ ਦਾ ਫੈਸਲਾ ਰਾਹ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਚੁਣੇ ਸਰਵਰ ਨੂੰ ਅਜੇ ਵੀ ਆਪਣੇ ਪਤੇ ਤੱਕ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਵਾਪਸ ਮਿਲੇ ਪਤੇ ਨੂੰ ਅਜੇ ਵੀ ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਵਿੱਚ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਸਹੀ DNS ਨੀਤੀ ਕਦੇ ਨਾ ਖੁੱਲ੍ਹਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਨਾਲ ਰਹਿ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਦੁਬਾਰਾ DNS ਬਦਲਣ ਦੀ ਬਜਾਏ ਪਤਾ ਅਤੇ ਰੂਟ ਵੇਖੋ। ਨਾਮ ਹੱਲ ਹੋਣਾ ਅਤੇ ਪਹੁੰਚ ਦੋ ਵੱਖਰੇ ਮਾਲਕਾਂ ਵਾਲੇ ਦੋ ਸਵਾਲ ਹਨ।
ਐਪਲੀਕੇਸ਼ਨ ਆਪਣੀ ਸੁਰੱਖਿਅਤ DNS ਸੈਟਿੰਗ ਜਾਂ ਬੰਡਲ ਕੀਤੇ ਰਿਜ਼ਾਲਵਰ ਰਾਹੀਂ ਸਿਸਟਮ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦੀਆਂ ਹਨ। resolvectl ਨਤੀਜਾ ਸਿਸਟਮ ਰਾਹ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਤੁਹਾਡੇ ਹਰ ਟੈਸਟ ਨਾਲ ਅਸਹਿਮਤ ਹੋਵੇਗਾ। ਨੀਤੀ ਟੁੱਟੀ ਹੋਣ ਦਾ ਨਤੀਜਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸੈਟਿੰਗ ਜਾਂਚੋ।
ਜਿਸ ਪਤੇ ਉੱਤੇ ਨਾਮ ਹੱਲ ਹੋਇਆ ਉਹ ਲਿੰਕ ਦੇ ਕੋਲ ਨੋਟ ਕਰੋ। ਗਲਤ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਹੀ ਨਾਮ ਰਾਊਟਿੰਗ ਨਹੀਂ, ਰਿਕਾਰਡ ਦੀ ਸਮੱਸਿਆ ਹੈ।
ਲਿੰਕ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚੋ
ਦੁਬਾਰਾ ਜੁੜਨਾ ਜਾਂ ਵਾਇਰਲੈਸ ਬਦਲਣਾ ਲਿੰਕ ਦੀ ਸਥਿਤੀ ਦੁਬਾਰਾ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਹੱਥੋਂ ਸੈੱਟ ਕੀਤੇ ਸਭ ਉੱਤੇ ਆਪਣੇ ਡੋਮੇਨ ਅਤੇ ਸਰਵਰ ਦੁਬਾਰਾ ਲਗਾ ਸਕਦਾ ਹੈ। ਫਿਰ ਉਹੀ ਦੋ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਨੋਟ ਕੀਤੀ ਆਧਾਰ-ਰੇਖਾ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਜੇ ਹੱਥ ਦੀ ਸੋਧ ਗਾਇਬ ਹੋ ਗਈ ਹੈ, ਸੁਧਾਰ ਕਨੈਕਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਸ਼ੈੱਲ ਕਮਾਂਡ ਵਿੱਚ ਨਹੀਂ। ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਨੋਟ ਕਰਨਾ ਹੀ ਇਸਨੂੰ ਦਿਸਦਾ ਬਣਾਉਂਦਾ ਹੈ।
ਰਿਪੋਰਟ ਨੂੰ ਜਿਨ੍ਹਾਂ ਨਾਮਾਂ ਅਤੇ ਸਰਵਰ ਸੰਦਰਭ ਦੀ ਲੋੜ ਹੈ ਸਿਰਫ਼ ਉਹੀ ਸਾਂਝੇ ਕਰੋ, ਕਿਉਂਕਿ ਅੰਦਰੂਨੀ ਪ੍ਰਤਿਅ ਟੋਪੋਲੋਜੀ ਦੱਸ ਦਿੰਦੇ ਹਨ। systemd-resolved ਦਾ ਡੋਮੇਨ ਰਾਊਟਿੰਗ ਦਸਤਾਵੇਜ਼ ਸਭ ਤੋਂ ਲੰਬੀ ਮੇਲ ਦਾ ਨਿਯਮ ਅਤੇ ਟਿਲਡਾ ਦਾ ਵਿਵਹਾਰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਵਾਰ ਪੜ੍ਹਨ ਨਾਲ ਉੱਪਰਲੀ ਸਾਰਣੀ ਦੀਆਂ ਬਹੁਤੀਆਂ ਗਲਤੀਆਂ ਰੁਕਦੀਆਂ ਹਨ: systemd-resolved ਵਿੱਚ ਪ੍ਰਸ਼ਨ ਰਾਊਟਿੰਗ।