ਸਪਲਿਟ ਟਨਲਿੰਗ ਬਨਾਮ ਕੰਪਨੀ ਨੀਤੀ: ਕਿਹੜਾ ਨਿਯਮ ਜਿੱਤਦਾ ਹੈ

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

ਚੈੱਕਬਾਕਸ ਬਾਰੇ ਬਹਿਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਨੀਤੀ ਕਿਸ ਗੁਣ ਦੀ ਰੱਖਿਆ ਲਈ ਹੈ।

ਨਿਯਮ ਪਿੱਛੇਲਾ ਗੁਣ

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

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

ਇਹ ਚਾਰ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਵੱਖਰਾ ਅਪਵਾਦ ਤੋੜਦਾ ਹੈ। ਬਦਲਾਅ ਸੁਝਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਜਿਸ ਨੇ ਲਿਖੀ ਹੈ ਉਹ ਤੁਰੰਤ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਗਲਤ ਲੋੜ ਪੂਰੀ ਕਰਨ ਵਾਲਾ ਬਦਲਾਅ ਕੁਝ ਨਹੀਂ ਖਰੀਦਦਾ।

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

ਜਾਂਚਾਂ ਕ੍ਰਮ ਅਨੁਸਾਰ ਕਰੋ

ਹੇਠਾਂ ਦਿੱਤਾ ਕ੍ਰਮ ਅਪਵਾਦ ਨੂੰ ਸੱਚਮੁੱਚ ਫੇਲ੍ਹ ਹੋਈ ਸਭ ਤੋਂ ਛੋਟੀ ਚੀਜ਼ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ। ਜੋ ਜਾਂਚ ਟਿਕਦੀ ਨਹੀਂ ਉੱਥੇ ਹੀ ਰੁਕੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਦਾ ਸੁਧਾਰ ਪਹਿਲਾਂ ਦੀ ਘਾਟ ਦੀ ਭਰਪਾਈ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

ਹਰ ਜਵਾਬ ਇੱਕ ਤੱਥ ਹੈ, ਅਤੇ ਅਪਵਾਦ ਬੇਨਤੀ ਨੂੰ ਤੱਥਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। VPN ਪਰੇਸ਼ਾਨ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਬਹਿਸ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ। ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਲਿਖੋ।

ਸੰਕੀਰਣ ਅਪਵਾਦ ਮੰਗੋ

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

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

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

ਅਪਵਾਦ ਨੂੰ ਟਿਕਾਊ ਬਣਾਓ

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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