ਨਿੱਜੀ DNS ਨਾਮ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ IP? ਸਾਂਝਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫੈਸਲਾ ਕਰੋ

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

ਪਹਿਲੀ ਸ਼ਰਤ: ਗਾਹਕਾਂ ਕੋਲ ਕਿਹੜਾ resolver ਮਾਰਗ ਹੈ?

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

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

ਲੈਪਟਾਪ VPN ਨਾਲ ਜੁੜਿਆ ਸੀ ਇਸ ਕਰਕੇ ਜਨਤਕ resolver ਨਿੱਜੀ ਜ਼ੋਨ ਨਹੀਂ ਸਿੱਖੇਗਾ।

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

ਦੂਜੀ ਸ਼ਰਤ: ਸੇਵਾ ਕਿਹੜਾ ਸਰੋਤ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ?

ਪਹੁੰਚ ਨਿਯਮ ਪਤਿਆਂ ਦੇ ਵਿਰੁੱਧ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਲਾਭਦਾਇਕ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਰੂਟਿੰਗ ਅਤੇ ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਸੇਵਾ ਕਿਹੜਾ ਪਤਾ ਵੇਖਦੀ ਹੈ। 10.20.30.40 ’ਤੇ ਇੱਕ ਉਦਾਹਰਨ ਸੇਵਾ ਲਈ, ਦਫ਼ਤਰ ਦੇ ਗਾਹਕ 10.20.30.0/24 ਤੋਂ ਆਉਂਦੇ ਹਨ ਅਤੇ ਦੂਰਸਥ ਗਾਹਕ 10.99.0.0/24 ਵਰਗੇ ਵੱਖਰੇ ਪੂਲ ਤੋਂ ਆਉਂਦੇ ਹਨ।

ਜੇ ਗੇਟਵੇ ਦੂਰਸਥ ਪੂਲ ਦਾ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਸੇਵਾ ਅਨੁਵਾਦਕ ਨੂੰ ਵੇਖਦੀ ਹੈ, ਅਤੇ 10.99.0.0/24 ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਮੇਲ ਨਹੀਂ ਖਾਵੇਗਾ।

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

ਤੀਜੀ ਸ਼ਰਤ: ਨਾਮ ਸੇਵਾ ਨਾਲ ਜੁੜਿਆ ਹੈ ਜਾਂ ਹੋਸਟ ਨਾਲ?

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

ਇੱਕੋ ਇੱਕ ਅੰਦਰੂਨੀ ਸੇਵਾ ਲਈ, ਸਿੱਧਾ ਰਿਕਾਰਡ ਆਮ ਤੌਰ ’ਤੇ ਠੀਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੋਚਣਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ।

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

ਦੋਵੇਂ ਫੈਸਲੇ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਜਾਂਚੋ

ਪਹਿਲਾਂ ਹੱਲ ਕਰੋ, ਫਿਰ ਜੁੜੋ। ਉਮੀਦ ਕੀਤੇ ਪਤੇ ਨੂੰ ਵਾਪਸ ਕਰਨ ਵਾਲੀ ਹੱਲ ਜਾਂਚ ਨਾਮ ਦੇ ਮਾਰਗ ਨੂੰ ਸਾਬਤ ਕਰਦੀ ਹੈ ਅਤੇ ਪਹੁੰਚ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਕਨੈਕਸ਼ਨ ਜਾਂਚ ਮਾਰਗ ਅਤੇ ਨਿਯਮ ਇਕੱਠੇ ਸਾਬਤ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਹੱਲ ਸਫਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ ਚਲਾਓ।

curl -sv --max-time 5 https://files.corp.example/health

ਫਿਰ ਇੱਕ ਵਾਰ ਕਿਸੇ ਮਨਾਹੀ ਵਾਲੇ ਸਰੋਤ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਨਤੀਜਾ ਲਿਖੋ।

ਆਪਣੇ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਦੋਵੇਂ ਰਿਕਾਰਡ ਵੱਖਰੇ ਰੱਖੋ: ਨਾਮ ਅਤੇ ਉਸ ਦਾ ਜ਼ੋਨ, ਸਵੀਕਾਰ ਕੀਤੇ ਸਰੋਤ ਅਤੇ ਨਿਯਮ ਦਾ ਮਾਲਕ। ਜਦੋਂ ਇੱਕ ਬਦਲਦਾ ਹੈ, ਦੂਜੇ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਨਹੀਂ।

ਫੈਸਲਾ ਆਮ ਤੌਰ ’ਤੇ ਕਿੱਥੇ ਗਲਤ ਹੁੰਦਾ ਹੈ

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

ਇੱਕ ਸਫਲ ਜਾਂਚ ਤੋਂ ਕੋਈ ਵੀ ਗਲਤੀ ਦਿਸਦੀ ਨਹੀਂ। ਇਸ ਲਈ ਦੋਵੇਂ ਫੈਸਲੇ ਵੱਖਰੇ ਰਿਕਾਰਡ ਅਤੇ ਵੱਖਰੀਆਂ ਜਾਂਚਾਂ ਦੇ ਯੋਗ ਹਨ, ਭਾਵੇਂ ਇੱਕੋ ਵਿਅਕਤੀ ਦੋਵੇਂ ਲਵੇ।

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