MagicDNS ਡਿਵਾਈਸਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਪਰ ਦਫ਼ਤਰ ਦੇ ਹੋਸਟਨਾਮ ਕਿਉਂ ਨਹੀਂ

MagicDNS tailnet ਵਿੱਚ ਹਰ ਡਿਵਾਈਸ ਨੂੰ ਉਸ ਦੇ ਮਸ਼ੀਨ ਨਾਮ ਅਤੇ tailnet ਦੇ DNS ਡੋਮੇਨ ਤੋਂ ਲਿਆ ਨਾਮ ਦਿੰਦਾ ਹੈ। ਉਹ ਨਾਮ Tailscale ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਉਸ ਦਾ ਜਵਾਬ Tailscale ਦੇ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। files.office.example ਵਰਗਾ ਦਫ਼ਤਰ ਹੋਸਟਨਾਮ ਅਜਿਹੇ ਜ਼ੋਨ ਦਾ ਹੈ ਜੋ Tailscale ਨੇ ਕਦੇ ਨਹੀਂ ਲਿਖਿਆ, ਇਸ ਲਈ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਬਦਲਣ ਨਾਲ ਉਹ ਬਣ ਨਹੀਂ ਸਕਦਾ। ਦੋਵੇਂ ਨਾਮ-ਥਾਂ ਇਕੱਠੇ ਮੌਜੂਦ ਹਨ; ਬੱਸ ਉਨ੍ਹਾਂ ਦੇ ਮਾਲਕ ਵੱਖਰੇ ਹਨ।

ਉਹ ਵਿਧੀ ਇੱਕ ਬਹੁਤ ਆਮ ਸ਼ਿਕਾਇਤ ਪਿੱਛੇ ਹੈ: Tailscale ਹੋਸਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਫਾਈਲ ਸਰਵਰ ਅਜੇ ਵੀ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਗਲਤੀ ਵਾਪਸ ਕਰਦਾ ਹੈ।

ਦੋ ਨਾਮ-ਥਾਂ, ਦੋ ਮਾਲਕ

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

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

ਦਫ਼ਤਰ ਜ਼ੋਨ ਨੂੰ ਉਸ ਦੇ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਮੋੜੋ

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

ਸੀਮਿਤ ਨਾਮ ਸਰਵਰ ਨੂੰ ਉਸ ਨਾਲ ਜੁੜੇ ਡੋਮੇਨ ਲਈ ਅਧਿਕਾਰਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਪਤੇ ਦੀ ਥਾਂ ਹਵਾਲਾ ਹੋਵੇਗਾ।

ਪਹੁੰਚ ਹੱਲ ਤੋਂ ਪਹਿਲਾਂ ਆਉਂਦੀ ਹੈ

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

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

ਨਾਮ ਦੀ ਅਸਫਲਤਾ ਨੂੰ ਸੇਵਾ ਦੀ ਅਸਫਲਤਾ ਤੋਂ ਵੱਖ ਕਰੋ

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

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

ਜ਼ੋਨ, ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ ਅਤੇ ਕਿਊਰੀ ਲੈ ਜਾਣ ਵਾਲਾ ਰੂਟ ਨੋਟ ਕਰੋ। ਇਹ ਤਿੰਨ ਹੋਰ ਇੱਕ ਨਾਮ-ਬਦਲੀ ਦੌਰ ਤੋਂ ਬਿਨਾਂ ਬਹੁਤੇ MagicDNS ਹੈਰਾਨੀਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ।