ਫੇਲ-ਓਪਨ ਬਨਾਮ ਫੇਲ-ਕਲੋਜ਼ਡ: VPN ਕਿਲ ਸਵਿੱਚ ਕੀ ਤੈਅ ਕਰਦਾ ਹੈ
ਦੋਵੇਂ ਸ਼ਬਦ ਦੱਸਦੇ ਹਨ ਕਿ ਟਨਲ ਜਾਣ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਇਨਕ੍ਰਿਪਸ਼ਨ ਕਿੰਨਾ ਮਜ਼ਬੂਤ ਹੈ। ਤੁਹਾਡੇ ਚੁਣੇ ਦਾਇਰੇ ਤੋਂ ਤੈਅ ਹੁੰਦਾ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਸੱਚਮੁੱਚ ਲੀਕ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਮਿੱਥ ਇਹ ਹੈ ਕਿ ਫੇਲ-ਕਲੋਜ਼ਡ ਸੁਰੱਖਿਅਤ ਸੈਟਿੰਗ ਹੈ ਅਤੇ ਫੇਲ-ਓਪਨ ਲਾਪਰਵਾਹ। ਦੋਵੇਂ ਦੱਸਦੇ ਹਨ ਕਿ ਟਨਲ ਜਾਣ ਤੋਂ ਬਾਅਦ ਟ੍ਰੈਫਿਕ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਉਹ ਟਨਲ ਕਿੰਨਾ ਚੰਗਾ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਲੰਮੀ ਛੋਟ-ਸੂਚੀ ਵਾਲੀ ਫੇਲ-ਕਲੋਜ਼ਡ ਨੀਤੀ ਅਜਿਹੇ ਯੰਤਰ ਉੱਤੇ ਫੇਲ-ਓਪਨ ਨੀਤੀ ਨਾਲੋਂ ਵੱਧ ਲੀਕ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਕਦੇ ਦਫ਼ਤਰ ਦਾ ਨੈੱਟਵਰਕ ਨਹੀਂ ਛੱਡਦਾ। ਉਹ ਨਤੀਜਾ ਚੁਣੋ ਜੋ ਤੁਸੀਂ ਟ੍ਰੈਫਿਕ ਦੇ ਮਾਲਕ ਨੂੰ ਸਮਝਾ ਸਕੋ।
ਲੇਬਲ ਨਤੀਜਾ ਦੱਸਦਾ ਹੈ, ਤਾਕਤ ਨਹੀਂ
ਇਹ ਸ਼ਬਦਾਵਲੀ ਕੰਟਰੋਲ ਪ੍ਰਣਾਲੀਆਂ ਤੋਂ ਆਈ ਹੈ: ਕੋਈ ਹਿੱਸਾ ਫੇਲ ਹੋਣ ਵੇਲੇ ਫੇਲ-ਓਪਨ ਕੰਮ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਫੇਲ-ਕਲੋਜ਼ਡ ਉਸ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ। VPN ਉੱਤੇ ਲਾਗੂ ਕਰਨ ’ਤੇ ਫੇਲ ਹੋਣ ਵਾਲਾ ਹਿੱਸਾ ਟਨਲ ਹੈ, ਅਤੇ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਸੇ ਹੋਰ ਰਾਹ ਰਾਹੀਂ ਜਾਰੀ ਰਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਾਈਫ਼ਰ ਦੀ ਚੋਣ, ਕੁੰਜੀ ਦੀ ਲੰਬਾਈ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਵੱਖਰੇ ਫ਼ੈਸਲੇ ਹਨ।
ਉਲਝਣ ਬਣੀ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਕਿਲ ਸਵਿੱਚ ਸੁਰੱਖਿਆ ਵਿਸ਼ੇਸ਼ਤਾ ਵਾਂਗ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਵਿਕਰੇਤਾ ਇਸ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਮਾਰਕੀਟ ਕਰਦੇ ਹਨ। ਯਾਂਤਰਿਕ ਤੌਰ ’ਤੇ ਇਹ ਇੱਕ ਰਾਊਟਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਹੈ ਜੋ ਉਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਦਾ ਹੈ ਜੋ ਟਨਲ ਨੇ ਲਿਜਾਣਾ ਸੀ, ਜੋ ਕਲਾਇੰਟ ਵਿੱਚ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਵਿੱਚ ਜਾਂ ਗੇਟਵੇ ’ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਜੋ ਪਰਤ ਇਸ ਨੂੰ ਲਾਗੂ ਕਰਦੀ ਹੈ ਉਹੀ ਇਸ ਦਾ ਦਾਇਰਾ ਵੀ ਤੈਅ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ ਪਰਤ ਦਾ ਨਿਯਮ ਦੂਜੀ ਨੂੰ ਨਹੀਂ ਢਕਦਾ। ਗੇਟਵੇ ਦਾ ਨਿਯਮ ਉਸ ਲੈਪਟਾਪ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਹੋਰ ਨੈੱਟਵਰਕ ’ਤੇ ਜਾ ਚੁੱਕਾ ਹੈ।
ਹਰ ਨਤੀਜਾ ਕਿਹੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ
ਇੱਕੋ ਨੀਤੀ ਤੁਹਾਨੂੰ ਕਿਹੜੀ ਨਾਕਾਮੀ ਮਿਲਦੀ ਹੈ ਇਸ ਆਧਾਰ ’ਤੇ ਬਹੁਤ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਲੇਬਲ ਨਹੀਂ, ਘਟਨਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।
| Event | Fail-open result | Fail-closed result |
|---|---|---|
| Tunnel drops while a transfer runs | Transfer continues on the direct path | Transfer stalls until the tunnel returns |
| Client exits or crashes | Rules disappear with the process | Rules persist only if the OS owns them |
| Device boots before sign-in | Normal network access | Blocked until the VPN connects |
| Captive portal needed | Portal loads normally | Portal unreachable without an exception |
| IPv6 not carried by the tunnel | IPv6 traffic leaks directly | Leaks too, unless the block covers IPv6 |
ਆਖ਼ਰੀ ਕਤਾਰ ਉਹੀ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਫੜਦੀ ਹੈ ਜੋ ਮੰਨਦੇ ਹਨ ਕਿ ਕਿਲ ਸਵਿੱਚ ਇੱਕੋ ਸਵਿੱਚ ਹੈ। IPv4 ਰਾਊਟ ਸਾਰਣੀ ਲਈ ਲਿਖਿਆ ਨਿਯਮ IPv6 ਡਿਫ਼ਾਲਟ ਰਾਹ ਨੂੰ ਅਛੂਤਾ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਉਸ ਨੂੰ ਖ਼ੁਸ਼ੀ ਨਾਲ ਵਰਤ ਸਕਦੀ ਹੈ।
ਦਾਇਰਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਲੀਕ ਹੁੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ
ਇਹ ਪੁੱਛਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕਿਹੜਾ ਮੋਡ ਹੈ, ਪੁੱਛੋ ਕਿ ਨੀਤੀ ਕੀ ਢਕਦੀ ਹੈ। ਪ੍ਰਤੀ-ਐਪਲੀਕੇਸ਼ਨ ਨਿਯਮ ਇੱਕ ਐਪ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਯੰਤਰ-ਵਿਆਪੀ ਨਿਯਮ ਛੋਟਾਂ ਨੂੰ ਛੱਡ ਕੇ ਸਭ ਦੀ, ਅਤੇ ਗੇਟਵੇ ਨਿਯਮ ਸਿਰਫ਼ ਉਸ ਟ੍ਰੈਫਿਕ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। DNS ਨੂੰ ਆਪਣਾ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਭੇਜੀ ਕਵੈਰੀ ਪੇਲੋਡ ਰੋਕੇ ਹੋਣ ’ਤੇ ਵੀ ਨਾਮ ਜ਼ਾਹਰ ਕਰ ਸਕਦੀ ਹੈ।
ਸਥਾਨਕ-ਨੈੱਟਵਰਕ ਛੋਟਾਂ ਪ੍ਰਿੰਟਰ, ਕਾਸਟਿੰਗ ਅਤੇ ਕੈਪਟਿਵ ਪੋਰਟਲ ਲਈ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਰੋਕ ਵਿੱਚ ਇੱਕ ਮੋਰੀ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਨੀਤੀ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਣ ਵਾਲਾ ਵਿਅਕਤੀ ਵਰਨਾ ਫੇਲ-ਕਲੋਜ਼ਡ ਨੂੰ ਨਿਰਪੇਖ ਪੜ੍ਹੇਗਾ।
ਦੁਬਾਰਾ ਜੁੜਨਾ ਅਤੇ ਰੋਕਣਾ ਵੀ ਵੱਖਰੇ ਨਿਯੰਤਰਣ ਹਨ। ਕਲਾਇੰਟ ਕਦੇ ਰੋਕੇ ਬਿਨਾਂ ਆਪਣੇ-ਆਪ ਦੁਬਾਰਾ ਜੁੜ ਸਕਦਾ ਹੈ, ਜਾਂ ਦੁਬਾਰਾ ਜੁੜੇ ਬਿਨਾਂ ਰੋਕ ਸਕਦਾ ਹੈ, ਅਤੇ ਸੰਯੋਗ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਰੁਕਾਵਟ ਦੌਰਾਨ ਵਰਤੋਂਕਾਰ ਕੀ ਅਨੁਭਵ ਕਰਦਾ ਹੈ।
ਸੰਕਰਮਣ ਦੌਰਾਨ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰੋ
ਸਥਿਰ ਅਵਸਥਾ ਦੀ ਜਾਂਚ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ। ਟਨਲ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਡੇਗੋ ਅਤੇ ਜਿਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਰੱਖਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਉਸ ਨੂੰ ਅਜ਼ਮਾਓ, ਫਿਰ ਜਾਂਚੋ ਕਿ ਕੀ ਉਹ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚੀ। ਕਲਾਇੰਟ ਦੇ ਸੂਚਕ ਦੀ ਨਤੀਜੇ ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਅਜੇ ਵੀ ਜੁੜਿਆ ਕਹਿਣ ਵਾਲਾ ਸੂਚਕ ਹੀ ਉਹ ਅਵਸਥਾ ਹੈ ਜਿਸ ਲਈ ਇਹ ਨੀਤੀ ਮੌਜੂਦ ਹੈ। ਜੇ ਸੁਰੱਖਿਅਤ ਐਪਲੀਕੇਸ਼ਨ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਮੋਡ ਦੇ ਨਾਮ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ; ਤੁਹਾਡੇ ਕੋਲ ਲੀਕ ਹੈ।
ਸਾਈਨ-ਇਨ ਤੋਂ ਪਹਿਲਾਂ ਕੋਲਡ ਬੂਟ ਤੋਂ ਦੁਹਰਾਓ, Wi-Fi ਤੋਂ ਸੈਲੂਲਰ ’ਤੇ ਜਾਂਦੇ ਸਮੇਂ, ਅਤੇ ਸੁਰੱਖਿਅਤ ਐਪ ਨੂੰ ਬੈਕਗਰਾਊਂਡ ਵਿੱਚ ਰੱਖ ਕੇ। ਜੇ ਰੋਕ ਕਲਾਇੰਟ ਪ੍ਰਕਿਰਿਆ ਲਾਗੂ ਕਰਦੀ ਹੈ, ਤਾਂ ਇਹ ਵੀ ਜਾਂਚੋ ਕਿ ਜਦੋਂ ਉਹ ਪ੍ਰਕਿਰਿਆ ਸਾਫ਼ ਬੰਦ ਹੋਣ ਦੀ ਬਜਾਏ ਮਾਰ ਦਿੱਤੀ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।
ਅਖ਼ੀਰ ਵਿੱਚ, ਸਫ਼ਾਈ ਦਾ ਰਾਹ ਜਾਂਚੋ। ਜੇ ਕਲਾਇੰਟ ਦੇ ਨਿਯਮ ਸਰਗਰਮ ਹੁੰਦਿਆਂ ਉਹ ਅਣਇੰਸਟਾਲ ਕੀਤਾ ਜਾਵੇ, ਤਾਂ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰਨ ਦੀ ਬਜਾਏ ਵਿਕਰੇਤਾ ਦੀ ਦਰਜ ਹਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਰਤੋ, ਕਿਉਂਕਿ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰਨ ਨਾਲ ਅਸੰਬੰਧਿਤ ਸੁਰੱਖਿਆ ਹਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਬਚੇ ਨਿਯਮ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ ਇਸ ਦਾ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ।