ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਬੰਧਨ ਕਲਾਇੰਟ: ਤੁਹਾਡਾ ਮਾਨੀਟਰ GUI ਨੂੰ ਕਿਉਂ ਬਾਹਰ ਕੱਢਦਾ ਹੈ
ਪ੍ਰਬੰਧਨ ਸਾਕਿਟ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਹੀ ਕਨੈਕਸ਼ਨ ਲੈਂਦਾ ਹੈ। ਦੂਜਾ ਗਾਹਕ ਜਾਂ ਤਾਂ ਜੁੜ ਨਹੀਂ ਸਕਦਾ ਜਾਂ ਪ੍ਰੋਂਪਟ ਰੱਖਣ ਵਾਲੇ ਹਿੱਸੇ ਤੋਂ ਨਿਯੰਤਰਣ ਖੋਹ ਲੈਂਦਾ ਹੈ।
ਇੱਕ ਡੈਸਕਟਾਪ GUI ਪ੍ਰਬੰਧਨ ਕਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਮਾਨੀਟਰਿੰਗ ਸਕ੍ਰਿਪਟ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਪੜ੍ਹਦੀ, ਜਾਂ ਉਸ ਤੋਂ ਵੀ ਮਾੜਾ, GUI ਪ੍ਰੋਂਪਟ ਦਾ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਆਮ ਸਿੱਟਾ ਇਹ ਨਿਕਲਦਾ ਹੈ ਕਿ ਡੈਮਨ ਅਸਥਿਰ ਹੈ। ਕਮਿਊਨਿਟੀ ਡੈਮਨ ਵਿੱਚ ਇਹ ਸੀਮਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ: ਕੰਟਰੋਲ ਇੰਟਰਫ਼ੇਸ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਜੁੜੇ ਪ੍ਰਬੰਧਨ ਕਲਾਇੰਟ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਗਿਣਤੀ ਦਾ ਇਸ ਨਾਲ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ ਕਿ VPN ਕਿੰਨੇ ਉਪਭੋਗਤਾ ਚੁੱਕ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸਾਕਿਟ, ਇੱਕ ਧਾਰਕ
ਪ੍ਰਬੰਧਨ ਚੈਨਲ ਇੱਕ ਹੀ ਜੁੜਿਆ ਕਲਾਇੰਟ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਪਹਿਲਾ ਸਰਗਰਮ ਹੋਵੇ ਅਤੇ ਦੂਜਾ ਆਵੇ, ਤਾਂ ਉਹ ਉਡੀਕਦਾ ਹੈ ਜਾਂ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕਿਸੇ ਵਿਕਲਪ ਪਿੱਛੇ ਕੋਈ ਸਮਾਨਾਂਤਰ ਗਾਹਕ ਮੋਡ ਲੁਕਿਆ ਨਹੀਂ ਹੈ। ਮੌਜੂਦਾ ਧਾਰਕ ਦਾ ਕਨੈਕਸ਼ਨ ਕੱਟਣ ਨਾਲ ਡੈਮਨ ਅਗਲੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਦੂਜਾ ਚੈਨਲ ਨਹੀਂ ਸਗੋਂ ਇੱਕ ਹਸਤਾਂਤਰਣ ਹੈ।
ਇਸ ਨਾਲ ਹਰ ਵਾਧੂ ਸੰਦ ਮੁਕਾਬਲੇਬਾਜ਼ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ GUI ਕੋਲ ਕਨੈਕਸ਼ਨ ਹੈ, ਤਾਂ ਪੋਲਿੰਗ ਸਕ੍ਰਿਪਟ ਜਾਂ ਤਾਂ ਜੁੜ ਨਹੀਂ ਸਕਦੀ ਜਾਂ ਸਿਰਫ਼ ਤਦ ਸਫਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ GUI ਹਾਰ ਮੰਨ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕ੍ਰਮ ਅਗਲੇ ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਸਕ੍ਰਿਪਟ ਪਹਿਲਾਂ ਜੁੜ ਜਾਵੇ, ਤਾਂ GUI ਆਪਣਾ ਕੰਟਰੋਲ ਮਾਰਗ ਗੁਆ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਸ ਦੇ ਪ੍ਰੋਂਪਟ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। ਕੋਈ ਵੀ ਸੰਦ ਇਸ ਟਕਰਾਅ ਦੀ ਰਿਪੋਰਟ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਸਿਰਫ਼ ਆਪਣਾ ਅਸਫਲ ਹੁਕਮ ਦੇਖਦਾ ਹੈ।
| What you need | Mechanism that fits | What it cannot do |
|---|---|---|
| Periodic list of connected clients | Status file written on an interval | Deliver events as they happen |
| Interactive prompts and session control | The single management connection | Serve two controllers at once |
| Multiple consumers of either | One owner process that fans out | Exist without you writing it |
ਤੈਅ ਕਰੋ ਕਿ ਕੰਟਰੋਲ ਦਾ ਮਾਲਕ ਕਿਹੜਾ ਹਿੱਸਾ ਹੈ
ਇੰਟਰਐਕਟਿਵ ਚੈਨਲ ਲਈ ਇੱਕ ਮਾਲਕ ਚੁਣੋ ਅਤੇ ਉਸੇ ਨੂੰ ਜੁੜਨ ਵਾਲੀ ਇੱਕੋ ਇੱਕ ਚੀਜ਼ ਬਣਨ ਦਿਓ। ਕਨੈਕਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧ ਕਰਨ ਵਾਲਾ GUI, ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰੋਂਪਟ ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਅਤੇ ਸੈਸ਼ਨ ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਕੰਟਰੋਲਰ, ਸਾਰੇ ਮਾਲਕ ਗਿਣੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਇਹ ਭੂਮਿਕਾ ਲੈ ਸਕਦਾ ਹੈ।
ਜਦੋਂ GUI ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ ਹੋਵੇ, ਤਾਂ ਉਸ ਨਾਲ ਲੜਨ ਦੀ ਥਾਂ ਉਹ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਵਰਤੋ ਜੋ ਉਹ GUI ਦਿੰਦਾ ਹੈ। ਸਾਕਿਟ ਲਈ ਮਾਲਕ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਨ ਨਾਲ ਰੁਕ-ਰੁਕ ਕੇ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਬੇਤਰਤੀਬ ਲੱਗਦੀਆਂ ਹਨ, ਅਤੇ ਗੜਬੜ ਲੱਭਣ ਵਾਲਾ ਵਿਅਕਤੀ ਆਮ ਤੌਰ ਉੱਤੇ ਦੌੜ ਦਾ ਸਿਰਫ਼ ਦੂਜਾ ਅੱਧ ਦੇਖਦਾ ਹੈ। ਧਿਆਨ ਦਿਓ ਕਿ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਪਹਿਲਾਂ ਜੁੜਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹੀ ਕ੍ਰਮ ਹਰ ਵਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਜਿੱਤੇਗਾ। GUI ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਮਾਨੀਟਰ ਚੈਨਲ ਤਦ ਤੱਕ ਰੱਖੇਗਾ ਜਦ ਤੱਕ GUI ਹਾਰ ਨਹੀਂ ਮੰਨ ਲੈਂਦਾ।
ਇਕੱਠਾ ਕਰਨ ਵਾਲਿਆਂ ਲਈ ਸਥਿਤੀ ਸਨੈਪਸ਼ਾਟ ਵਰਤੋ
ਬਹੁਤੀ ਮਾਨੀਟਰਿੰਗ ਨੂੰ ਸੂਚੀ ਚਾਹੀਦੀ ਹੈ, ਗੱਲਬਾਤ ਨਹੀਂ। ਸਮੇਂ-ਸਮੇਂ ਲਿਖੀ ਜਾਣ ਵਾਲੀ ਸਥਿਤੀ ਫ਼ਾਈਲ ਕੰਟਰੋਲ ਚੈਨਲ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਇਸ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ GUI ਜੁੜਿਆ ਰਹਿਣ ਦੌਰਾਨ ਵੀ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ।
status /run/openvpn/server.status 10
management /run/openvpn/server.sock unixਅੰਤਰਾਲ ਤਾਜ਼ਗੀ ਦਾ ਬਜਟ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਉਸੇ ਉੱਤੇ ਰੱਖੋ ਜੋ ਡੈਸ਼ਬੋਰਡ ਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਉਸ ਸਭ ਤੋਂ ਛੋਟੇ ਮੁੱਲ ਉੱਤੇ ਜੋ ਸੁਰੱਖਿਅਤ ਲੱਗਦਾ ਹੈ। ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਲਿਖਿਆ ਸਨੈਪਸ਼ਾਟ ਸਸਤਾ ਹੈ; ਹਰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਕੰਟਰੋਲ ਸਾਕਿਟ ਨਾਲ ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਸਸਤੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਹਰ ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ਮਾਲਕ ਨਾਲ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ।
ਸਨੈਪਸ਼ਾਟ ਨਾ ਇਤਿਹਾਸ ਹੈ ਅਤੇ ਨਾ ਘਟਨਾ ਫ਼ੀਡ। ਇੱਕ ਅੰਤਰਾਲ ਦੇ ਅੰਦਰ ਆ ਕੇ ਚਲੇ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਕਦੇ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ, ਇਸ ਲਈ ਆਡਿਟ ਦੀ ਲੋੜ ਆਪਣੇ ਉੱਤੇ ਦੁਬਾਰਾ ਲਿਖਣ ਵਾਲੀ ਫ਼ਾਈਲ ਨੂੰ ਪੋਲ ਕਰਕੇ ਪੂਰੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ। ਜੇ ਤੁਸੀਂ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਉਪਭੋਗਤਾ ਜੁੜਿਆ ਵੀ ਸੀ ਜਾਂ ਨਹੀਂ, ਤਾਂ ਸਨੈਪਸ਼ਾਟ ਗ਼ਲਤ ਸੰਦ ਹੈ।
ਫੈਨ-ਆਊਟ ਇੱਕ ਡਿਜ਼ਾਈਨ ਹੈ, ਮੋਡ ਨਹੀਂ
ਜੇ ਕਈ ਖਪਤਕਾਰਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਲਾਈਵ ਪ੍ਰਬੰਧਨ ਡੇਟਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਸਾਕਿਟ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਹਿੱਸਾ ਰੱਖੋ ਅਤੇ ਉਸ ਨੂੰ ਬਾਕੀਆਂ ਲਈ ਧਿਆਨ ਨਾਲ ਚੁਣੇ ਨਿਰੀਖਣ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦਿਓ। ਉਹੀ ਹਿੱਸਾ ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ, ਪ੍ਰਮਾਣਿਕਤਾ ਪ੍ਰੋਂਪਟ ਅਤੇ ਇਸ ਫ਼ੈਸਲੇ ਦਾ ਮਾਲਕ ਹੈ ਕਿ ਕੀ ਪ੍ਰਗਟ ਕਰਨਾ ਸੁਰੱਖਿਅਤ ਹੈ।
ਇਸ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਣਾਓ: ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੀਆਂ ਕਿਊਰੀਆਂ ਦੀ ਆਗਿਆ ਹੈ, ਲੌਗ ਕਰੋ ਕਿ ਕਿਸ ਨੇ ਪੁੱਛਿਆ, ਅਤੇ ਫੈਨ-ਆਊਟ ਪਰਤ ਨੂੰ ਅਚਾਨਕ ਰਿਮੋਟ ਕੰਟਰੋਲ ਪੈਨਲ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਚੋ। ਡੈਮਨ ਵਿੱਚ ਸਮਰੱਥ ਕਰਨ ਲਈ ਕੋਈ ਮਲਟੀ-ਕਲਾਇੰਟ ਮੋਡ ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਲਾਈਨ ਇਸ ਨੂੰ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਮਾਲਕ ਨੂੰ ਸੁਰੱਖਿਆ ਹੱਦ ਦਾ ਹਿੱਸਾ ਮੰਨੋ, ਕਿਉਂਕਿ ਉਸ ਕੋਲ ਅਜਿਹਾ ਇੰਟਰਫ਼ੇਸ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਨਾ ਦਸਤਾਵੇਜ਼ੀ ਰਿਕਵਰੀ ਮਾਰਗ ਵਾਲਾ ਰੁਟੀਨ ਕੰਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਸਾਕਿਟ ਨੂੰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਮੰਨੋ, ਮੈਟ੍ਰਿਕਸ ਨਹੀਂ
ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰ ਸਕਦਾ ਹੈ, ਸਥਿਤੀ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਲੋਕਾਂ ਦੇ ਨਾਮ ਵਾਲੀਆਂ ਘਟਨਾਵਾਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਇਸ ਦਾ ਪਾਸਵਰਡ ਕਲਾਇੰਟ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ ਅਤੇ ਟ੍ਰਾਂਸਪੋਰਟ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਨੈੱਟਵਰਕ ਉੱਤੇ ਸੁਣਨ ਵਾਲਾ ਗੱਲਬਾਤ ਨੂੰ ਹਰ ਉਸ ਵਿਅਕਤੀ ਸਾਹਮਣੇ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ ਜੋ ਇਸ ਨੂੰ ਦੇਖ ਸਕਦਾ ਹੈ।
ਸਥਾਨਕ ਸਾਕਿਟ ਜਾਂ ਸਖ਼ਤੀ ਨਾਲ ਸੀਮਿਤ ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਤੁਹਾਡਾ ਸੰਗ੍ਰਾਹਕ ਸੱਚਮੁੱਚ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੰਬੋਧਿਤ ਕਰ ਰਿਹਾ ਹੈ, ਕਿਉਂਕਿ ਸਰਵਰ ਉਤਪਾਦ ਆਪਣੇ ਪ੍ਰਬੰਧਨ API ਲੈ ਕੇ ਆਉਂਦੇ ਹਨ ਜੋ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਗ਼ਲਤ ਡੈਮਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸੰਗ੍ਰਾਹਕ ਭਰੋਸੇਯੋਗ ਪਰ ਗ਼ਲਤ ਸਿੱਟੇ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਕੁਝ ਵੀ ਵਾਪਸ ਨਾ ਕਰਨ ਵਾਲੀ ਕਿਊਰੀ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਰਗ ਅਤੇ ਮਾਲਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।