VPN ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਐਪ ਨਹੀਂ ਚੱਲਣੀ ਚਾਹੀਦੀ: ਇਸਨੂੰ ਕੀ ਲਾਗੂ ਕਰਦਾ ਹੈ

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

ਭਰਮ: kill switch ਪ੍ਰੋਗਰਾਮ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ

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

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

ਸਾਧਨ ਦਾ ਨਾਮ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ ਮੋਡ ਦਾ ਨਾਮ ਲਵੋ

ਨਿਯਮ ਨੂੰ ਤਿੰਨ ਅਵਸਥਾਵਾਂ ਵਾਲੀ ਸਟੇਟ ਮਸ਼ੀਨ ਵਜੋਂ ਲਿਖੋ: ਆਮ ਵਰਤੋਂ, VPN ਕੰਮ ਸੈਸ਼ਨ ਅਤੇ ਰਵਾਨਗੀ। ਵਰਜਿਤ ਓਵਰਲੈਪ ਵਿਚਕਾਰਲੀ ਅਵਸਥਾ ਦਾ ਹੈ, ਕਲਾਇੰਟ ਸੌਫਟਵੇਅਰ ਦਾ ਨਹੀਂ।

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

ਦੋ-ਪਾਸੜ ਟਕਰਾਅ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

ਸੱਚਮੁੱਚ systemd ਵੱਲੋਂ ਪ੍ਰਬੰਧਿਤ ਦੋ ਸੇਵਾਵਾਂ ਲਈ Conflicts= ਸਮਮਿਤ ਹੈ: ਇੱਕ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਦੂਜੀ ਰੁਕ ਜਾਂਦੀ ਹੈ। ਯੂਨਿਟ ਸੰਦਰਭ ਇਸ ਵਿਵਹਾਰ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ ਅਤੇ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਕ੍ਰਮ ਮੰਗਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਨੂੰ ਦੂਜੀ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੁਕਣਾ ਪੂਰਾ ਕਰਨਾ ਹੁੰਦਾ ਹੈ। ਉਹਨਾਂ ਕ੍ਰਮ-ਐਂਟਰੀਆਂ ਤੋਂ ਬਿਨਾਂ ਰੁਕਣਾ ਅਤੇ ਸ਼ੁਰੂ ਹੋਣਾ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਸਮੇਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

ਸਿਰਫ਼ ਪਹਿਲਾ ਲਾਂਚ ਨਹੀਂ, ਤਬਦੀਲੀਆਂ ਪਰਖੋ

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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