ਕੀ ਕੋਈ ਨੈੱਟਵਰਕ ਇਨਕ੍ਰਿਪਸ਼ਨ ਤੋੜੇ ਬਿਨਾਂ ਤੁਹਾਡਾ VPN ਬਲਾਕ ਕਰ ਸਕਦਾ ਹੈ?
ਇਨਕ੍ਰਿਪਸ਼ਨ ਸਮੱਗਰੀ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਪਹੁੰਚਾਉਣ ਦੀ ਨਹੀਂ। ਬਲਾਕਲਿਸਟ, ਆਗਿਆ-ਸੂਚੀ ਅਤੇ ਪੂਰੀ ਬੰਦੀ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਪੁੱਛੋ ਕਿ ਇੱਕ ਨਿਰੀਖਣ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰ ਸਕਦਾ ਹੈ।
ਕਿਸੇ ਵੀ ਓਪਰੇਟਰ ਨੂੰ ਟਨਲ ਰੋਕਣ ਲਈ ਸੈਸ਼ਨ ਕੁੰਜੀ ਦੀ ਲੋੜ ਨਹੀਂ: ਰਸਤੇ ਵਿੱਚ ਪੈਕੇਟ ਸੁੱਟੋ ਅਤੇ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਓਨੀ ਹੀ ਮਜ਼ਬੂਤ ਰਹਿੰਦੀ ਹੈ ਜਿੰਨਾ ਇਸਦੇ ਡਿਜ਼ਾਈਨ ਨੇ ਵਾਅਦਾ ਕੀਤਾ ਸੀ। ਇਨਕ੍ਰਿਪਸ਼ਨ ਉਸ ਚੀਜ਼ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ ਜੋ ਗੱਲਬਾਤ ਢੋਂਦੀ ਹੈ, ਕਿਸੇ ਵੀ ਨੈੱਟਵਰਕ ਦੀ ਉਸਨੂੰ ਢੋਣ ਦੀ ਤਿਆਰੀ ਦੀ ਨਹੀਂ। ਇਹਨਾਂ ਦੋ ਗੁਣਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਨਾਲ ਬਲਾਕ ਨਾ ਹੋਣ ਬਾਰੇ ਬਹਿਸ ਇਸ ਸਵਾਲ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਨੀਤੀ ਲਾਗੂ ਹੈ ਅਤੇ ਇਹ ਕਿੰਨੀ ਦੂਰ ਪਹੁੰਚਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਤੁਲਨਾ ਉਪਲਬਧਤਾ ਅਤੇ ਗੋਪਨੀਯਤਾ ਨੂੰ ਵੱਖ ਰੱਖਦੀ ਹੈ, ਕਿਉਂਕਿ VPN ਬਲਾਕਿੰਗ ਬਾਰੇ ਜ਼ਿਆਦਾਤਰ ਪੱਕੇ ਦਾਅਵੇ ਚੁੱਪਚਾਪ ਦੋਵਾਂ ਨੂੰ ਮਿਲਾ ਦਿੰਦੇ ਹਨ।
ਪਹੁੰਚਯੋਗਤਾ ਰਸਤੇ ਦਾ ਫੈਸਲਾ ਹੈ
ਹਰ ਆਵਾਜਾਈ ਉਸ ਰਸਤੇ ਉੱਤੇ ਨਿਰਭਰ ਹੈ ਜੋ ਪੈਕੇਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇੱਥੇ ਹਰ ਨੀਤੀ ਸਵਾਲ ਉਸੇ ਭੇਜਣ ਦੇ ਫੈਸਲੇ ਵੱਲ ਆਉਂਦਾ ਹੈ। ਪੈਕੇਟ ਸੁੱਟਣ ਵਾਲਾ ਨਿਯਮ ਗੋਪਨੀਯਤਾ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਉਪਲਬਧਤਾ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੀ ਇੱਕ ਟਨਲ ਨਿਰਦੋਸ਼ ਢੰਗ ਨਾਲ ਇਨਕ੍ਰਿਪਟ ਹੋ ਕੇ ਵੀ ਉਸੇ ਪਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਕਾਰ ਹੋ ਸਕਦੀ ਹੈ। ਉਸ ਨਤੀਜੇ ਵਿੱਚ ਕੁਝ ਵੀ ਸਾਈਫਰ ਤੋੜਨ ਜਾਂ ਕੁੰਜੀ ਵਾਪਸ ਲੈਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਸਿਰਫ਼ ਰਸਤੇ ਉੱਤੇ ਕੰਟਰੋਲ ਮੰਗਦਾ ਹੈ।
ਉਲਝਣ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਦੋ ਗੁਣ ਇੱਕੋ ਸ਼ਬਦ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਮਜ਼ਬੂਤ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਦੱਸਦੀ ਹੈ ਕਿ ਪ੍ਰਵਾਹ ਕੌਣ ਪੜ੍ਹ ਸਕਦਾ ਹੈ; ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ ਵਿਚਕਾਰਲਾ ਯੰਤਰ ਇਸਨੂੰ ਲੰਘਣ ਦੇਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਇਸ ਲਈ VPN ਬਲਾਕ ਨਹੀਂ ਹੋ ਸਕਦਾ ਦੇ ਦਾਅਵੇ ਹੇਠਾਂ ਦੂਜਾ ਦਾਅਵਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ ਰਸਤੇ ਉੱਤੇ ਕੋਈ ਵੀ ਪੈਕੇਟ ਸੁੱਟਣ ਨੂੰ ਤਿਆਰ ਨਹੀਂ।
ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਸ਼ੈਲੀਆਂ ਅਤੇ ਹਰੇਕ ਦੀ ਕੀਮਤ
ਤਿੰਨ ਸ਼ੈਲੀਆਂ ਜ਼ਿਆਦਾਤਰ ਅਸਲ ਨੀਤੀਆਂ ਨੂੰ ਢਕਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਇਸ ਵਿੱਚ ਵੱਖਰੀਆਂ ਹਨ ਕਿ ਕੀ ਜਾਣਨਾ ਹੈ, ਚਲਾਉਣ ਦਾ ਖਰਚ ਕੀ ਹੈ ਅਤੇ ਹੋਰ ਕੌਣ ਦੁੱਖ ਝੱਲਦਾ ਹੈ। ਹਰੇਕ ਕੁਝ ਵੀ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਬਿਨਾਂ ਟਨਲ ਤੋਂ ਇਨਕਾਰ ਕਰ ਸਕਦੀ ਹੈ। ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਇੱਕੋ ਸ਼ਬਦ, ਬਲਾਕਿੰਗ, ਤਿੰਨਾਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
ਉਹ ਸਾਰਣੀ ਖਰਚ ਦਾ ਨਕਸ਼ਾ ਹੈ, ਦਰਜਾਬੰਦੀ ਨਹੀਂ। ਬਲਾਕਲਿਸਟ ਸ਼ੁਰੂ ਕਰਨਾ ਸਸਤਾ ਅਤੇ ਸਹੀ ਰੱਖਣਾ ਮਹਿੰਗਾ ਹੈ; ਆਗਿਆ-ਸੂਚੀ ਖੋਜ ਨੂੰ ਮਨਜ਼ੂਰ ਸਮੂਹ ਦੀ ਸੰਭਾਲ ਨਾਲ ਬਦਲਦੀ ਹੈ, ਅਤੇ ਪੂਰੀ ਬੰਦੀ ਨੂੰ ਕੋਈ ਵਰਗੀਕਰਨ ਲੋੜੀਂਦਾ ਨਹੀਂ। ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਤਕਨੀਕੀ ਸੂਖਮਤਾ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਹਰੇਕ ਲਗਾਤਾਰ ਮਿਹਨਤ ਕਿੱਥੇ ਰੱਖਦੀ ਹੈ। ਕਾਗਜ਼ ਉੱਤੇ ਸਧਾਰਨ ਦਿਸਣ ਵਾਲੀ ਨੀਤੀ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਕਿਤੇ ਹੋਰ ਲੁਕੀ ਸੰਭਾਲ ਦੀ ਲਾਈਨ ਹੁੰਦੀ ਹੈ।
ਬਲਾਕਲਿਸਟ ਇਸ ਗੱਲ ਤੱਕ ਸੀਮਤ ਹੈ ਕਿ ਪਤਾ ਸੇਵਾ ਦਾ ਕਿੰਨਾ ਚੰਗਾ ਨਾਮ ਦਿੰਦਾ ਹੈ
ਬਲਾਕਲਿਸਟ ਪਹਿਲਾਂ ਹੀ ਪਛਾਣੇ ਗਏ ਮੰਜ਼ਿਲਾਂ ਨੂੰ ਇਨਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਰੱਖਦੀ ਹੈ। ਇਸਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਪਤੇ ਅਤੇ ਪੋਰਟ ਚਾਹੀਦੇ ਹਨ, ਸਪਸ਼ਟ ਪਾਠ ਨਹੀਂ, ਅਤੇ ਇਹੀ ਇਸਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਸਸਤਾ ਬਣਾਉਂਦਾ ਹੈ। ਖਰਚ ਬਾਅਦ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਜੋ ਰੇਂਜ ਇੱਕ ਸਮੇਂ ਇੱਕ ਪ੍ਰਦਾਤਾ ਦੀ ਪਛਾਣ ਸੀ, ਉਹ ਬਾਅਦ ਵਿੱਚ ਦਰਜਨ ਭਰ ਅਸੰਬੰਧਿਤ ਕਿਰਾਏਦਾਰਾਂ ਨੂੰ ਥਾਂ ਦੇ ਸਕਦੀ ਹੈ। ਹਰ ਪਤਾ ਬਦਲਾਅ ਸੂਚੀ ਦੀ ਸੋਧ ਲਾਜ਼ਮੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਪੁਰਾਣੀ ਐਂਟਰੀ ਮਾਸੂਮ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਾਲ ਲੈ ਜਾਂਦੀ ਹੈ।
ਇਸ ਮਾਡਲ ਵਿੱਚ ਸ਼ੁੱਧਤਾ ਇਸ ਗੱਲ ਨਾਲ ਸੀਮਤ ਹੈ ਕਿ ਮੰਜ਼ਿਲ ਸੇਵਾ ਦੀ ਕਿੰਨੀ ਚੰਗੀ ਪਛਾਣ ਕਰਦੀ ਹੈ, ਅਤੇ ਰੁਝੇਵੇਂ ਵਾਲਾ ਸਾਂਝਾ ਅੰਤ-ਬਿੰਦੂ ਮਾੜਾ ਪਛਾਣਕਰਤਾ ਹੈ। ਇਹ ਢਾਂਚਾਗਤ ਸੀਮਾ ਹੈ, ਲਾਗੂ ਕਰਨ ਦੀ ਖ਼ਰਾਬੀ ਨਹੀਂ, ਇਸ ਲਈ ਵਧੀਆ ਸਾਧਨ ਇਸਨੂੰ ਹਟਾਉਂਦੇ ਨਹੀਂ। ਇਹ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਬਲਾਕਲਿਸਟ ਕਿਉਂ ਵਧਦੀਆਂ ਹਨ: ਹਰ ਨਵਾਂ ਅੰਤ-ਬਿੰਦੂ ਛੋਟਾ ਜੋੜ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਨਾਲ ਵਾਲਾ ਨੁਕਸਾਨ ਸੂਚੀ ਨਾਲ ਵਧਦਾ ਹੈ।
ਆਗਿਆ-ਸੂਚੀ ਸੰਭਾਲ ਦਾ ਭਾਰ ਹਟਾਉਂਦੀ ਹੈ
ਆਗਿਆ-ਸੂਚੀ ਡਿਫਾਲਟ ਨੂੰ ਉਲਟ ਦਿੰਦੀ ਹੈ ਤਾਂ ਜੋ ਸਿਰਫ਼ ਪਹਿਲਾਂ ਚੁਣੀਆਂ ਮੰਜ਼ਿਲਾਂ ਜਾਂ ਟ੍ਰੈਫਿਕ ਕਿਸਮਾਂ ਲੰਘ ਸਕਣ। ਹਰ ਮਨਾਹੀ ਵਾਲੇ ਅੰਤ-ਬਿੰਦੂ ਦੀ ਸੂਚੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਜੋ ਉਦੋਂ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਮਨਾਹੀ ਵਾਲਾ ਸਮੂਹ ਵੱਡਾ ਹੋਵੇ ਜਾਂ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲੇ। ਇਸਦੀ ਥਾਂ ਇਸਨੂੰ ਮਨਜ਼ੂਰ ਦੀ ਸੰਭਾਲੀ ਪਰਿਭਾਸ਼ਾ ਅਤੇ ਉਸ ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਲਾਗੂਕਰਨ ਚਾਹੀਦਾ ਹੈ।
ਪੋਰਟ ਨੰਬਰ ਅਜਿਹੀ ਪਰਿਭਾਸ਼ਾ ਵਿੱਚ ਆਮ ਕਮਜ਼ੋਰ ਥਾਂ ਹਨ। ਪੋਰਟ ਮਨਜ਼ੂਰ ਕਰਨਾ ਉਹਨਾਂ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਜੋ ਇਸਨੂੰ ਵਰਤ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਪੋਰਟ-ਆਧਾਰਿਤ ਆਗਿਆ-ਸੂਚੀ ਅਕਸਰ ਲੇਖਕ ਦੇ ਇਰਾਦੇ ਤੋਂ ਵੱਧ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੀ ਵੀ ਦੂਜੇ ਕੋਣ ਤੋਂ ਉਹੀ ਸਮੱਸਿਆ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਟ੍ਰੈਫਿਕ ਦੀ ਸ਼ਕਲ ਪਛਾਣਦੇ ਹਨ, ਇਰਾਦਾ ਨਹੀਂ। ਇਸ ਲਈ ਆਗਿਆ-ਸੂਚੀ ਆਪਣੇ ਆਪ ਬਲਾਕਲਿਸਟ ਨਾਲੋਂ ਵੱਧ ਸਹੀ ਨਹੀਂ; ਇਹ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਬਾਰੇ ਸਹੀ ਹੈ।
ਇੱਕ ਨਿਰੀਖਣ ਕੀ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ
ਬਲਾਕਿੰਗ ਬਾਰੇ ਕੋਈ ਵੀ ਦਾਅਵਾ ਹੱਥ ਵਿੱਚ ਚਾਰ ਸਵਾਲ ਲੈ ਕੇ ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ: ਕਿਹੜੇ ਪਹੁੰਚ ਨੈੱਟਵਰਕ, ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ, ਕਿਹੜੇ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਕਿੰਨਾ ਨਿਰੀਖਣ ਸਮਾਂ। ਅੱਜ ਇੱਕ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਉੱਤੇ ਦਿਸੀ ਅਸਫਲਤਾ ਕੱਲ੍ਹ ਦੂਜੇ ਨੈੱਟਵਰਕ ਤੋਂ ਉਸੇ ਅੰਤ-ਬਿੰਦੂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਇੱਕ ਵਾਰ ਚੱਲੀ ਟਨਲ ਵੀ ਟਿਕਾਊ ਉਪਲਬਧਤਾ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ।
ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਬਾਰੇ ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਸ਼ਕਲ ਵੇਖੀ ਜਾ ਸਕਦੀ ਹੈ। ਚੁੱਪ ਅਟਕਣਾ, ਤੁਰੰਤ ਇਨਕਾਰ ਅਤੇ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਰੀਸੈਟ ਵੱਖ-ਵੱਖ ਲਾਗੂ ਕਰਨ ਸ਼ੈਲੀਆਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੋ ਕਮਾਂਡ ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀਆਂ ਹਨ:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comਸਮਾਂ-ਸੀਮਾ ਵਿੱਚ ਖ਼ਤਮ ਹੋਣ ਵਾਲਾ ਅਟਕਣਾ ਚੁੱਪ ਸੁੱਟਣ ਵੱਲ, ਤੇਜ਼ ਇਨਕਾਰ ਰਸਤੇ ਉੱਤੇ ਇਨਕਾਰ ਕਰਨ ਵਾਲੇ ਯੰਤਰ ਵੱਲ, ਅਤੇ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਦਾ ਰੀਸੈਟ ਗੁੰਮ ਰਸਤੇ ਦੀ ਥਾਂ ਹਾਲਤ ਵਾਲੇ ਦਖ਼ਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਸੈਂਸਰਸ਼ਿਪ ਤਕਨੀਕਾਂ ਬਾਰੇ RFC 9505 ਸਰਵੇਖਣ ਉਹਨਾਂ ਸ਼ਕਲਾਂ ਪਿੱਛੇਲੇ ਕੰਟਰੋਲ-ਬਿੰਦੂਆਂ ਅਤੇ ਦਖ਼ਲ ਦੇ ਨਮੂਨਿਆਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਪਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਨੀਤੀ ਕਿੰਨੀ ਵਿਆਪਕ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਟਿਕਾਊਪਣ ਪਹੁੰਚਯੋਗਤਾ ਨਾਲੋਂ ਮਜ਼ਬੂਤ ਦਾਅਵਾ ਹੈ: ਅੰਤ-ਬਿੰਦੂ, ਸੌਫਟਵੇਅਰ, ਨੀਤੀਆਂ ਅਤੇ ਮਨਜ਼ੂਰ ਸੇਵਾਵਾਂ ਸਭ ਬਦਲਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਅਨਿਸ਼ਚਿਤ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਲਈ ਲਾਗੂਕਰਨ ਜਾਰੀ ਰਹਿਣ ਦੀਆਂ ਧਾਰਨਾਵਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਇੱਕ ਪਲ ਵਿੱਚ ਵੇਖੇ ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਨਹੀਂ।