VPN ਲੌਗਇਨ ਚੇਤਾਵਨੀਆਂ: ਉਨ੍ਹਾਂ ਨੂੰ ਅਸਲ ਵਿੱਚ ਕਿਹੜੀ ਘਟਨਾ ਟ੍ਰਿਗਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?
ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਸਫਲਤਾ, ਸਥਾਪਿਤ ਟਨਲ ਅਤੇ RADIUS accounting Start ਤਿੰਨ ਵੱਖਰੇ ਦਾਅਵੇ ਹਨ। ਉਹ ਦਾਅਵਾ ਚੁਣੋ ਜਿਸ 'ਤੇ ਤੁਹਾਡਾ ਪ੍ਰਾਪਤਕਰਤਾ ਕਾਰਵਾਈ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਸਹਿਸੰਬੰਧਿਤ ਕਰੋ।
ਪ੍ਰਮਾਣਿਕਤਾ ਦੀ ਸਫਲਤਾ, ਸਥਾਪਿਤ ਟਨਲ ਅਤੇ RADIUS accounting Start ਤਿੰਨ ਵੱਖਰੇ ਦਾਅਵੇ ਹਨ, ਅਤੇ ਲੌਗਇਨ ਈਮੇਲ ਦਾ ਅਰਥ ਤਦ ਹੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਚੁਣਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ VPN ਚੇਤਾਵਨੀ ਡਿਜ਼ਾਈਨ ਤਿੰਨੇ ਨੂੰ ਮਿਲਾ ਕੇ ਅਜਿਹਾ ਇਨਬਾਕਸ ਬਣਾਉਂਦੇ ਹਨ ਜਿਸ 'ਤੇ ਕੋਈ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦਾ। ਫੈਸਲਾ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਚੇਤਾਵਨੀ ਕੌਣ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਪੰਜ ਮਿੰਟਾਂ ਵਿੱਚ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਗਲਤ ਕਰਨ 'ਤੇ ਚੇਤਾਵਨੀ ਅਜਿਹਾ ਸ਼ੋਰ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦੀ ਇੱਕੋ ਇੱਕ ਘਟਨਾ ਨੂੰ ਲੁਕਾ ਦਿੰਦੀ ਹੈ।
ਤਿੰਨ ਸਵਾਲ ਟ੍ਰਿਗਰ ਤੈਅ ਕਰਦੇ ਹਨ
ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਸ ਨੂੰ ਮਿਲੇਗਾ, ਉਹ ਕੀ ਕਰੇਗਾ, ਅਤੇ ਕਾਰਵਾਈ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦੇ ਦੁਰਉਪਯੋਗ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲੀ ਸੁਰੱਖਿਆ ਟੀਮ ਨੂੰ ਇੱਕ ਖਾਤੇ ਤੋਂ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਅਸਫਲ-ਫਿਰ-ਸਫਲ ਪੈਟਰਨ ਚਾਹੀਦਾ ਹੈ। ਸਮਰੱਥਾ 'ਤੇ ਨਜ਼ਰ ਰੱਖਣ ਵਾਲੀ ਸੰਚਾਲਨ ਟੀਮ ਨੂੰ ਲੌਗਇਨ ਨਹੀਂ, ਸਗੋਂ ਸੈਸ਼ਨ ਦੀ ਮਿਆਦ ਅਤੇ ਡਿਸਕਨੈਕਟ ਦੇ ਕਾਰਨ ਚਾਹੀਦੇ ਹਨ। ਹੈਲਪਡੈਸਕ ਨੂੰ ਸੈਸ਼ਨ ਦੀ ਪਛਾਣ ਚਾਹੀਦੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਟਿਕਟ ਨਾਲ ਮਿਲਾ ਸਕੇ।
ਉਹ ਜਵਾਬ ਵੱਖਰੀਆਂ ਘਟਨਾਵਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਇੱਕ ਨਿਯਮ ਤਿੰਨਿਆਂ ਨੂੰ ਸੰਤੁਸ਼ਟ ਨਹੀਂ ਕਰਦਾ। ਜੇ ਪ੍ਰਾਪਤਕਰਤਾ ਦੀ ਕਾਰਵਾਈ «ਵਰਤੋਂਕਾਰ ਨੂੰ ਫੋਨ ਕਰੋ» ਹੈ, ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਾਫ਼ੀ ਹੈ। ਜੇ ਕਾਰਵਾਈ «ਲਾਇਸੈਂਸ ਮੁਕਤ ਕਰੋ» ਜਾਂ «ਟਨਲ ਨੇ ਟ੍ਰੈਫਿਕ ਢੋਇਆ ਜਾਂ ਨਹੀਂ, ਜਾਂਚੋ» ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਸਥਾਪਨਾ ਜਾਂ accounting Start ਹੀ ਕੰਮ ਕਰੇਗਾ। ਜੇ ਕਾਰਵਾਈ «ਸਮੇਂ ਦਾ ਬਿੱਲ ਬਣਾਓ» ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਲੌਗਇਨ ਦੀ ਥਾਂ Stop ਰਿਕਾਰਡ ਚਾਹੀਦੇ ਹਨ।
ਕੁਝ ਵੀ ਕਨਫਿਗਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਇੱਕ ਵਾਕ ਵਿੱਚ ਲਿਖੋ। «ਇਹ ਈਮੇਲ ਆਨ-ਕਾਲ ਇੰਜੀਨੀਅਰ ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਖਾਤੇ X ਨੇ ਸਮੇਂ Z 'ਤੇ ਨੈੱਟਵਰਕ Y ਤੋਂ ਟਨਲ ਖੋਲ੍ਹਿਆ, ਤਾਂ ਜੋ ਉਹ ਜਾਂਚ ਸਕੇ ਕਿ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਵਰਤੀ ਗਈ ਸੀ ਜਾਂ ਨਹੀਂ।» ਜੇ ਤੁਸੀਂ ਹਰ ਥਾਂ ਨਹੀਂ ਭਰ ਸਕਦੇ, ਤਾਂ ਟ੍ਰਿਗਰ ਹਾਲੇ ਨਹੀਂ ਚੁਣਿਆ ਗਿਆ।
ਘਟਨਾ ਨੂੰ ਉਸ ਦਾਅਵੇ ਨਾਲ ਮਿਲਾਓ ਜੋ ਤੁਸੀਂ ਕਰ ਰਹੇ ਹੋ
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
ਸਾਰਣੀ ਇੱਕ ਨਿਰਭਰਤਾ ਲੁਕਾਉਂਦੀ ਹੈ: ਹਰ ਕਤਾਰ ਤਦ ਹੀ ਭਰੋਸੇਯੋਗ ਹੈ ਜਦੋਂ ਗੇਟਵੇ ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਜਾਰੀ ਕਰੇ ਅਤੇ ਤੁਹਾਡਾ ਸੰਗ੍ਰਹਿਕਰਤਾ ਲੋੜੀਂਦੀ ਫੀਲਡ ਰੱਖੇ। ਤੁਸੀਂ ਜੋ ਸਹੀ ਸੰਸਕਰਣ ਚਲਾ ਰਹੇ ਹੋ ਉਸ ਲਈ ਘਟਨਾ ਦੀ ਪਰਿਭਾਸ਼ਾ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ «ਸੈਸ਼ਨ ਸਥਾਪਿਤ» ਨਾਮ ਸੰਸਕਰਣਾਂ ਵਿਚਕਾਰ ਬਦਲਦਾ ਹੈ ਅਤੇ ਅਰਥ ਨਾਮ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਬਦਲਦਾ ਹੈ। ਜਦੋਂ ਪਰਿਭਾਸ਼ਾ ਧੁੰਦਲੀ ਹੋਵੇ, ਤਾਂ ਲੇਬਲ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਸੈਸ਼ਨ ਕੈਪਚਰ ਮੰਗੋ।
Access-Accept ਨੂੰ ਇਸ ਤੋਂ ਬਾਅਦ ਦੀ ਹਰ ਚੀਜ਼ ਦੀ ਪੂਰਤੀ ਮੰਨਣਾ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਹੈ। ਇਹ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਬਾਰੇ ਫੈਸਲਾ ਹੈ, ਸੈਸ਼ਨ ਨਹੀਂ। ਉਲਟੀ ਗਲਤੀ ਨੀਤੀ ਮੇਲ ਨੂੰ ਅਧਿਕਾਰ ਦਾ ਸਬੂਤ ਪੜ੍ਹਨਾ ਹੈ, ਜਦੋਂ ਨਿਯਮ ਮੇਲ ਖਾ ਸਕਦਾ ਹੈ ਅਤੇ ਅਗਲਾ ਕਦਮ ਫਿਰ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸੈਸ਼ਨ, ਇੱਕ ਸੂਚਨਾ
ਇੱਕ ਖਾਤਾ, ਕਈ ਡਿਵਾਈਸਾਂ, ਮੁੜ-ਭੇਜਣਾ ਅਤੇ ਮੁੜ-ਕਨੈਕਟ ਹੋਣਾ: ਹਰ ਘਟਨਾ ਲਈ ਇੱਕ ਈਮੇਲ ਦੋਨਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਗਲਤ ਹੋਵੇਗੀ, ਇੱਕ ਸੈਸ਼ਨ ਦੀ ਨਕਲ ਕਰੇਗੀ ਅਤੇ ਦੂਜੇ ਨੂੰ ਵੰਡ ਦੇਵੇਗੀ। ਸੂਚਨਾ ਦੀ ਕੁੰਜੀ ਗੇਟਵੇ ਅਤੇ ਸੈਸ਼ਨ ਪਛਾਣਕਰਤਾ 'ਤੇ ਰੱਖੋ, ਅਤੇ ਖਾਤੇ ਦੇ ਨਾਮ ਨੂੰ ਕੁੰਜੀ ਨਹੀਂ ਸਗੋਂ ਵਿਸ਼ੇਸ਼ਤਾ ਮੰਨੋ। ਲੈਪਟਾਪ ਅਤੇ ਫੋਨ ਵਾਲੇ ਵਰਤੋਂਕਾਰ ਕੋਲ ਇੱਕ ਹੀ ਸਮੇਂ ਦੋ ਟਨਲ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਆਪਣੀ ਲਾਈਨ ਦੇ ਹੱਕਦਾਰ ਹਨ।
ਮੁੜ-ਭੇਜੇ ਲੇਖਾ ਰਿਕਾਰਡ ਆਮ ਹਨ, ਇਸ ਲਈ ਸੁਨੇਹਾ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਸੈਸ਼ਨ ਆਈਡੀ ਅਤੇ ਟਾਈਮਸਟੈਂਪ 'ਤੇ ਡੁਪਲੀਕੇਟ ਹਟਾਓ। ਇੱਕੋ ਡਿਵਾਈਸ ਤੋਂ ਲਗਾਤਾਰ ਸੈਸ਼ਨ ਵੱਖਰੇ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਦੌਰਾਨ ਮੁੜ-ਕਨੈਕਟ ਪਿਛਲੇ ਵਿੱਚ ਮਿਲਣ ਦੀ ਥਾਂ ਦਿਖਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਸੰਗ੍ਰਹਿਕਰਤਾ ਪ੍ਰਾਪਤੀ ਵੇਲੇ ਟਾਈਮਸਟੈਂਪ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਤਾਂ ਸੰਗ੍ਰਹਿਤ ਫੀਲਡਾਂ 'ਤੇ ਨਹੀਂ, ਮੂਲ ਰਿਕਾਰਡ ਦੀਆਂ ਫੀਲਡਾਂ 'ਤੇ ਡੁਪਲੀਕੇਟ ਹਟਾਓ।
ਗੁੰਮ Stop ਰਿਕਾਰਡ ਅਨਿਸ਼ਚਿਤਤਾ ਹੈ, ਸਥਾਈ ਸੈਸ਼ਨ ਨਹੀਂ। ਗੇਟਵੇ ਰੀਬੂਟ, ਸੰਗ੍ਰਹਿਕਰਤਾ ਖਰਾਬੀ ਅਤੇ UDP ਨੁਕਸਾਨ ਸਾਰੇ ਖਾਲੀ ਥਾਂ ਛੱਡਦੇ ਹਨ, ਇਸ ਲਈ ਚੇਤਾਵਨੀ ਨੂੰ ਅਜਿਹਾ ਸਮਝੌਤਾ ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਿਸੇ ਦੇ ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਟਨਲ ਅਜੇ ਵੀ ਚਾਲੂ ਹੈ, ਲਾਈਵ ਸੈਸ਼ਨ ਸਾਰਣੀ ਨੂੰ ਪੁੱਛੇ।
ਆਡਿਟ ਅਤੇ ਸੂਚਨਾ ਵੱਖਰੇ ਰੱਖੋ
ਆਡਿਟ ਸਟ੍ਰੀਮ ਅਤੇ ਚੇਤਾਵਨੀ ਸਟ੍ਰੀਮ ਦੇ ਕੰਮ ਵੱਖਰੇ ਹਨ। ਕੱਚੇ ਰਿਕਾਰਡ ਰੱਖੋ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਖਾਤਾ, ਗੇਟਵੇ, ਸੈਸ਼ਨ ਆਈਡੀ, ਟਾਈਮਸਟੈਂਪ ਅਤੇ ਸਮਾਪਤੀ ਦਾ ਕਾਰਨ ਸ਼ਾਮਲ ਹੈ, ਭਾਵੇਂ ਰੁਟੀਨ ਈਮੇਲਾਂ ਨੂੰ ਸਮੂਹਿਤ, ਦਬਾਇਆ ਜਾਂ ਛੋਟੀ ਆਨ-ਕਾਲ ਸੂਚੀ 'ਤੇ ਭੇਜਿਆ ਜਾਵੇ। ਗੰਭੀਰਤਾ ਦੀ ਹੱਦ ਇੱਕ ਡਿਲੀਵਰੀ ਫਿਲਟਰ ਹੈ, ਤੁਹਾਡੇ ਵੱਲੋਂ ਐਲਾਨੀ ਜਾਣ ਵਾਲੀ ਜੀਵਨ-ਚੱਕਰ ਘਟਨਾ ਦੀ ਚੋਣ ਨਹੀਂ।
ਸੁਰੱਖਿਅਤ ਰਿਕਾਰਡ ਲੱਭਣ ਲਈ ਪ੍ਰਾਪਤਕਰਤਾ ਨੂੰ ਲੋੜੀਂਦਾ ਘੱਟੋ-ਘੱਟ ਸੰਦਰਭ ਭੇਜੋ। ਖਾਤਿਆਂ ਦੇ ਨਾਮ, ਅੰਦਰੂਨੀ ਪਤੇ ਅਤੇ ਸੈਸ਼ਨ ਦੇ ਵੇਰਵੇ ਸੰਵੇਦਨਸ਼ੀਲ ਹਨ, ਅਤੇ ਜੋ ਈਮੇਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅੱਗੇ ਭੇਜੀ ਜਾਂਦੀ ਹੈ ਉਹੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲੀਕ ਹੁੰਦੀ ਹੈ।
ਫਿਰ ਇਹਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਸਾਬਤ ਕਰੋ। ਆਮ ਲੌਗਇਨ ਅਤੇ ਲੌਗਆਉਟ, ਇੱਕ ਮੁੜ-ਕਨੈਕਟ, ਦੋ ਇੱਕਸਾਥ ਸੈਸ਼ਨ ਅਤੇ ਇੱਕ ਜ਼ਬਰਦਸਤੀ ਡਿਲੀਵਰੀ ਫੇਲ੍ਹ ਚਲਾਓ, ਅਤੇ ਗੇਟਵੇ ਤੋਂ ਸੰਗ੍ਰਹਿਕਰਤਾ ਰਾਹੀਂ ਪਹੁੰਚਾਏ ਸੁਨੇਹੇ ਤੱਕ ਇੱਕ ਘਟਨਾ ਦਾ ਪਤਾ ਲਗਾਓ। ਜੇ ਈਮੇਲ ਸੈਸ਼ਨ ਆਈਡੀ ਤੋਂ ਬਿਨਾਂ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਇਕਰਾਰਨਾਮਾ ਅਧੂਰਾ ਹੈ। ਜੇ ਦੋ ਈਮੇਲਾਂ ਇੱਕ ਸੈਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਸਬੰਧ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਪਰਖਦੇ ਹੋ ਕਿ ਮੇਲ ਡਿਲੀਵਰੀ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਦੋਵੇਂ ਸਮੱਸਿਆਵਾਂ ਦਿਖਦੀਆਂ ਨਹੀਂ।