ਟਨਲ ਚਾਲੂ ਹੈ, ਫਿਰ ਵੀ ਨਿੱਜੀ ਨਾਮ ਕਿਉਂ ਅਸਫਲ ਹੈ?

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

ਬੇਨਤੀ ਕਿਹੜੇ ਰਿਜ਼ਾਲਵਰ ਤੱਕ ਪਹੁੰਚੀ?

ਟਨਲ ਵੱਲ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਲਿੰਕ ਨਾਲ ਜੁੜਿਆ ਰਿਜ਼ਾਲਵਰ ਲੱਭੋ। Linux ਰਿਜ਼ਾਲਵਰ ਸਥਿਤੀ ਕਮਾਂਡ ਰਾਹੀਂ ਹਰ ਲਿੰਕ ਦੇ ਸਰਵਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ macOS ਆਪਣੇ DNS ਸੰਰਚਨਾ ਡੰਪ ਵਿੱਚ ਸਕੋਪਡ ਰਿਜ਼ਾਲਵਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਜੇ ਜਵਾਬ ਅਜੇ ਵੀ ਘਰ ਦੇ ਰਾਊਟਰ ਤੋਂ ਆ ਰਿਹਾ ਹੈ, ਤਾਂ ਟਨਲ ਲਿੰਕ ਦੀ ਕਦੇ ਜਾਂਚ ਨਹੀਂ ਹੋਈ।

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

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

ਅਜਿਹਾ ਪਤਾ ਵਰਤੋ ਜਿਸ ’ਤੇ ਕਲਾਊਡ ਨੈੱਟਵਰਕ ਸੱਚਮੁੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

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

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

ਟਨਲ ਨਾਮਾਂ ਦੀ ਥਾਂ ਨਹੀਂ ਚੁੱਕਦੀ

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

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

ਹੱਦਾਂ ਕ੍ਰਮ ਵਿੱਚ ਪਾਰ ਕਰੋ

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

ਲਿਖੋ ਕਿ ਕਿਹੜਾ ਕਦਮ ਅਸਫਲ ਹੋਇਆ। ਉਹੀ ਇੱਕ ਲਾਈਨ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਦਰਜ ਕਰਨ ਵਿੱਚ ਦਸ ਸਕਿੰਟ ਲੱਗਦੇ ਹਨ।

ਜ਼ੰਜੀਰ ਨੂੰ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਅਗਲਾ ਵਿਅਕਤੀ ਇਸਨੂੰ ਲੱਭ ਸਕੇ

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

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