SNMP ਜਾਂ API ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ VPN ਵਸਤੂ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

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

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

ਅਲਰਟ ਦਾ ਅਸਲ ਵਿੱਚ ਕੀ ਅਰਥ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

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

ਇਸਨੂੰ ਅਜਿਹੇ ਵਾਕ ਵਜੋਂ ਲਿਖੋ ਜਿਸ ’ਤੇ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰ ਕੰਮ ਕਰ ਸਕੇ। ਜੇ ਵਾਕ ਨੂੰ ਦੋ ਵਸਤੂਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਤਾਂ ਉਹ ਦੋ ਅਲਰਟ ਹਨ, ਅੱਧਾ-ਸਹੀ ਇੱਕ ਨਹੀਂ।

TCP ਸਾਰਣੀ TCP ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ

RFC 4022 tcpConnectionTable ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ, ਜਿਸਦੀਆਂ ਕਤਾਰਾਂ ਸਥਾਪਿਤ TCP ਕਨੈਕਸ਼ਨਾਂ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਪਤੇ ਦੀ ਕਿਸਮ, ਪਤਾ ਅਤੇ ਪੋਰਟ ਨਾਲ ਕੁੰਜੀਬੱਧ। ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋਣ ’ਤੇ ਕਤਾਰਾਂ ਗਾਇਬ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਸੁਣਨ ਵਾਲੇ ਸਾਕਟ ਕਿਸੇ ਹੋਰ ਸਾਰਣੀ ਵਿੱਚ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਇੱਕੋ ਬਕਸੇ ’ਤੇ VPN ਚਲਾਉਣਾ TCP ਸਾਰਣੀ ਨੂੰ IPsec ਸੁਰੱਖਿਆ ਸੰਗਠਨਾਂ ਦੀ ਸੂਚੀ ਨਹੀਂ ਬਣਾ ਦਿੰਦਾ। ਇਹ ਪ੍ਰਬੰਧਨ ਸੈਸ਼ਨ, ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਵਾਹ, ਜਾਂ TCP ਉੱਤੇ ਢੋਏ ਜਾਂਦੇ ਟਨਲ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਤਾਰ ਆਪ ਹੀ ਨਹੀਂ ਦੱਸੇਗੀ ਕਿ ਕਿਹੜਾ।

ਇੰਟਰਫ਼ੇਸ ਕਾਊਂਟਰ ਵਧੇਰੇ ਮੋਟੇ ਪੱਧਰ ’ਤੇ ਉਹੀ ਅਸਪਸ਼ਟਤਾ ਰੱਖਦੇ ਹਨ: ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਬਾਈਟ ਹਰ ਪੀਅਰ ਅਤੇ ਹਰ ਪ੍ਰਵਾਹ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਨ ਜੋ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ।

ਇੱਕ ਛੋਟਾ ਨਿਰੀਖਣ ਸਮਝੌਤਾ ਬਣਾਓ

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

ਜੇ ਸਥਾਪਿਤ ਏਜੰਟ ਕੋਲ ਲੋੜੀਂਦੀਆਂ ਵਸਤੂਆਂ ਨਹੀਂ ਹਨ, ਤਾਂ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਸਮਰਥਿਤ ਹੋਰ ਪੜ੍ਹਨ-ਸਿਰਫ਼ ਇੰਟਰਫ਼ੇਸ ਚੁਣੋ। OID ਈਜਾਦ ਕਰਨਾ, ਆਮ TCP ਗਿਣਤੀ ਨੂੰ ਟਨਲ ਗਿਣਤੀ ਵਜੋਂ ਪੜ੍ਹਨਾ, ਜਾਂ ਪੁਰਾਣੀ ਵਿਕਰੇਤਾ API ਦੇ ਸਹੋਦਰ ਉਤਪਾਦ ਵਿੱਚ ਅਟੱਲ ਰਹਿਣ ਦੀ ਉਮੀਦ ਕਰਨਾ—ਸਾਰੇ ਬੰਦ ਰਾਹ ਹਨ।

ਪੁਰਾਣਾ ਡੇਟਾ ਟਨਲ ਅਸਫਲਤਾ ਨਹੀਂ ਹੈ

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

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

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