C# OpenVPN ਸਥਿਤੀ ਨਿਰੀਖਕ: ਸੈਸ਼ਨ ਵੇਖੋ, NIC ਨਹੀਂ

ਟਨਲ ਮਰਦਿਆਂ ਵੀ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਕੰਮ ਕਰਦੀ ਰਹਿੰਦੀ ਹੈ। Wi-Fi ਅਜੇ ਵੀ ਚਾਲੂ ਹੈ, ਇੰਟਰਨੈਟ ਅਜੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਜਿਸ ਪ੍ਰਾਈਵੇਟ API 'ਤੇ ਨਿਰਭਰ ਹੈ ਉਹ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੋ ਗਈ ਹੈ। ਲੋਕ ਇੱਥੇ ਆਮ ਤੌਰ 'ਤੇ ਜਿਸ .NET ਘਟਨਾ ਵੱਲ ਜਾਂਦੇ ਹਨ, NetworkAvailabilityChanged, ਉਹ ਉਸ ਸਥਿਤੀ ਦਾ ਬਿਲਕੁਲ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀ। ਉਹ ਮਸ਼ੀਨ ਦੀ ਸਮੁੱਚੀ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀ ਦੀ ਰਿਪੋਰਟ ਕਰਦੀ ਹੈ, ਅਤੇ VPN ਡਿਸਕਨੈਕਟ ਤੇ ਮੁੜ ਕਨੈਕਟ ਦੌਰਾਨ ਵੀ ਉਹ ਸਥਿਤੀ ਸੱਚੀ ਰਹਿ ਸਕਦੀ ਹੈ। ਨਿਰੀਖਕ ਨੂੰ ਟਨਲ ਦੇ ਮਾਲਕ ਕਲਾਇੰਟ ਨੂੰ ਵੇਖਣਾ ਚਾਹੀਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਸਟੈਕ ਦੇ ਸਾਰ ਨੂੰ ਨਹੀਂ।

ਉਪਲਬਧਤਾ ਇੱਕ ਸਮੁੱਚਾ ਮੁੱਲ ਹੈ, ਤੁਹਾਡਾ ਟਨਲ ਨਹੀਂ

NetworkAvailabilityChanged ਉਦੋਂ ਸਰਗਰਮ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਮਸ਼ੀਨ ਦਾ ਸਮੁੱਚਾ ਉਪਲਬਧਤਾ ਜਵਾਬ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਉਹ ਜਵਾਬ loopback ਜਾਂ ਟਨਲ ਤੋਂ ਇਲਾਵਾ ਹਰ ਸਰਗਰਮ ਇੰਟਰਫੇਸ ਗਿਣਦਾ ਹੈ।

Wi-Fi ਚਾਲੂ ਹੁੰਦਿਆਂ VPN ਡਿੱਗਣ ਨਾਲ ਉਹ ਜੋ ਮਾਪਦੀ ਹੈ ਉਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਇਸ ਲਈ ਜਿਸ ਖਰਾਬੀ ਦੀ ਤੁਹਾਨੂੰ ਚਿੰਤਾ ਹੈ ਠੀਕ ਉਸੇ ਦੌਰਾਨ ਘਟਨਾ ਚੁੱਪ ਰਹਿ ਸਕਦੀ ਹੈ।

ਸਥਿਤੀ ਸਟ੍ਰੀਮ ਟਨਲ ਦੇ ਮਾਲਕ ਕਲਾਇੰਟ ਦੀ ਹੈ

ਪਛਾਣੋ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ ਕਨੈਕਸ਼ਨ ਦਾ ਮਾਲਕ ਹੈ: OpenVPN GUI ਜਾਂ ਸੇਵਾ, OpenVPN Connect, ਜਾਂ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵੱਲੋਂ ਸ਼ੁਰੂ ਤੇ ਨਿਯੰਤਰਿਤ ਕੀਤੀ ਪ੍ਰਕਿਰਿਆ। ਇਹ ਵੱਖਰੇ ਸਮਰਥਿਤ ਇੰਟਰਫੇਸਾਂ ਵਾਲੇ ਵੱਖਰੇ ਮਾਲਕ ਹਨ, ਅਤੇ ਨਿਰੀਖਕ ਨੂੰ ਤੈਨਾਤੀ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਇੰਟਰਫੇਸ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਿਸ OpenVPN ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਜੁੜਨ ਦਾ ਤੁਹਾਨੂੰ ਅਧਿਕਾਰ ਹੈ, ਉਸ ਲਈ ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸ ਮੌਜੂਦਾ ਸਥਿਤੀ, ਇਤਿਹਾਸ ਤੇ ਅਸਲ-ਸਮੇਂ ਸੂਚਨਾਵਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਸਥਾਨਕ ਕੀਤੇ GUI ਕੈਪਸ਼ਨ ਵਿੱਚ connected ਸ਼ਬਦ ਲੱਭਣ ਦੀ ਬਜਾਏ ਦਸਤਾਵੇਜ਼ੀ ਢਾਂਚਾਗਤ ਸੁਨੇਹਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੋ।

ਪ੍ਰਬੰਧਨ ਚੈਨਲ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੀ ਨਿਯੰਤਰਣ ਸਤਹ ਹੈ, ਇਸ ਲਈ ਨਵਾਂ ਸਰੋਤਾ ਨਾ ਖੋਲ੍ਹੋ ਅਤੇ GUI ਨਾਲ ਉਸ ਚੈਨਲ ਲਈ ਨਾ ਲੜੋ ਜੋ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ।

ਪੀੜ੍ਹੀ ਰੱਖਿਅਕ ਪੁਰਾਣੇ ਨਤੀਜੇ ਰੋਕਦੇ ਹਨ

ਹਰ ਨਿਰੀਖਣ ਕਿਸੇ ਖਾਸ ਕਨੈਕਸ਼ਨ ਯਤਨ ਦਾ ਹੁੰਦਾ ਹੈ। ਨਵਾਂ ਯਤਨ ਸ਼ੁਰੂ ਹੋਣ, ਚੈਨਲ ਗੁੰਮ ਹੋਣ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਰਿਪੋਰਟ ਕਰਨ 'ਤੇ ਪੀੜ੍ਹੀ ਗਿਣਤੀ ਵਧਾਓ।

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

var generation = _generation;
var reachable = await ProbeAsync(token);
if (generation != _generation) return;
Publish(reachable);

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

ਸ਼ੁਰੂਆਤ ਅਤੇ ਮੁੜ ਕਨੈਕਟ ਇੱਕੋ ਜੀਵਨ-ਚੱਕਰ ਹਨ

ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ, ਮੁੜ ਕਨੈਕਟ ਅਤੇ ਚੈਨਲ ਦੇ ਨੁਕਸਾਨ ਨੂੰ ਇੱਕੋ ਨਿਯਮ-ਸਮੂਹ ਨਾਲ ਇੱਕੋ ਜੀਵਨ-ਚੱਕਰ ਮੰਨੋ:

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

ਗੁੰਮ ਚੈਨਲ ਦਾ ਅਰਥ ਹੈ ਅਣਜਾਣ, ਡਿਸਕਨੈਕਟ ਨਹੀਂ। ਅਣਜਾਣ ਦੀ ਰਿਪੋਰਟ ਕਰਨਾ ਉਸ ਡਿਸਕਨੈਕਟ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਨਾਲੋਂ ਇਮਾਨਦਾਰ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਅਤੇ ਇਹ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਤਰਕ ਨੂੰ ਅੰਦਾਜ਼ੇ 'ਤੇ ਕੰਮ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ।

ਸਬੂਤ ਦੱਸੋ, ਬੂਲੀਅਨ ਨਹੀਂ

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

ਜਨਤਕ IP ਖੋਜ ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪ੍ਰਾਈਵੇਟ API ਨੇ ਲੋੜੀਂਦਾ ਰਸਤਾ ਵਰਤਿਆ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਪੇਸ਼ ਨਾ ਕਰੋ ਜਿਵੇਂ ਹੋਵੇ।

ਲਾਗੂ ਕਰਨ ਨੂੰ ਨਿਰੀਖਕ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

ਫਿਰ UI ਦਾ ਸਵਾਲ ਸਧਾਰਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਜੋ ਜਾਣਿਆ ਹੈ ਉਸ ਨੂੰ ਉਸ ਦੀ ਉਮਰ ਸਮੇਤ ਦਿਖਾਓ, ਅਤੇ ਜਦੋਂ ਅਣਜਾਣ ਹੋਵੇ ਤਾਂ ਅਣਜਾਣ ਕਹੋ।