wg-quick ਜੁੜਨ ਵੇਲੇ DNS ਤੋੜਦਾ ਹੈ: ਸੈਟਅਪ ਗਲਤੀ ਪੜ੍ਹੋ

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

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

DNS ਲਾਈਨ ਸਹਾਇਕ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ

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

ਇਸੇ ਲਈ ਸੰਰਚਨਾ ਫ਼ਾਈਲ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਵੈਧ ਹੋ ਕੇ ਵੀ ਸੈਟਅਪ ਵੇਲੇ ਫੇਲ੍ਹ ਹੋ ਸਕਦੀ ਹੈ: ਨੁਕਸ ਉਸ ਹੁੱਕ ਦਾ ਹੈ ਜਿਸਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ।

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

ਕਿਹੜਾ ਚੱਲ ਰਿਹਾ ਹੈ ਇਹ ਜਾਣਨਾ ਪਹਿਲਾ ਨਿਦਾਨ ਕਦਮ ਹੈ, ਅਤੇ ਇਹ ਆਮ ਤੌਰ ’ਤੇ ਸੰਰਚਨਾ ਫ਼ਾਈਲ ਵਿੱਚ ਨਹੀਂ, ਤੁਹਾਡੇ ਟਾਈਪ ਕੀਤੇ ਆਦੇਸ਼ ਵਿੱਚ ਦਿਸਦਾ ਹੈ।

ਸਹਾਇਕ ਜੋ ਪਹਿਲੀ ਗਲਤੀ ਛਾਪਦਾ ਹੈ ਉਹ ਪੜ੍ਹੋ

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

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

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

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

ਹੋਸਟ ਕੋਲ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਹੈ

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

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

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

ਸਫ਼ਾਈ ਸੈਟਅਪ ਜਿੰਨੀ ਹੀ ਜ਼ਰੂਰੀ ਹੈ

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

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

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