ਡਾਊਨਸਟ੍ਰੀਮ ਸਬਨੈੱਟ ਬਨਾਮ ਡੈਸਕਟਾਪ VPN: ਟ੍ਰਾਂਜ਼ਿਟ ਬਾਹਰ ਰੱਖੋ, ਐਪਾਂ ਨਹੀਂ
ਪ੍ਰਤੀ-ਐਪ ਬਾਈਪਾਸ ਸਿਰਫ਼ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਦੀ ਸ਼੍ਰੇਣੀ ਬਣਾਉਂਦਾ ਹੈ। ਵਰਕਸਟੇਸ਼ਨ ਪਿੱਛੇ ਦੇ ਯੰਤਰਾਂ ਨੂੰ ਆਪਣੀ ਇਨਗ੍ਰੈਸ, ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਵਾਪਸੀ-ਮਾਰਗ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ।
ਇੱਕ ਮਸ਼ੀਨ, ਦੋ ਕੰਮ, ਇੱਕ ਫਾਇਰਵਾਲ: ਇੱਕ Wi-Fi ਅਪਲਿੰਕ, ਇਸਦੇ ਪਿੱਛੇ ਛੋਟਾ Ethernet ਸਬਨੈੱਟ, ਅਤੇ ਇੱਕ ਡੈਸਕਟਾਪ VPN ਕਲਾਇੰਟ ਜੋ ਮੰਨਦਾ ਹੈ ਕਿ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਹਰ ਚੀਜ਼ ਸਥਾਨਕ ਹੈ। ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਕੀਤੀਆਂ ਐਪਾਂ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਮਾਰਗ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀਆਂ ਹਨ। ਵਰਕਸਟੇਸ਼ਨ ਪਿੱਛੇ ਦੇ ਯੰਤਰ Ethernet ਪੋਰਟ 'ਤੇ ਆਉਂਦੇ ਹਨ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲਾ ਚਾਹੁੰਦੇ ਹਨ। ਪਹਿਲੇ ਮਾਰਗ ਲਈ ਲਿਖੀ ਛੋਟ ਦੂਜੇ ਨੂੰ ਕਦੇ ਨਹੀਂ ਦੇਖਦੀ, ਅਤੇ ਇਸੇ ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਟਨਲ ਨੂੰ ਬਾਈਪਾਸ ਕਰਦਾ ਹੈ, ਯੰਤਰ ਨਹੀਂ।
ਦੋ ਪੈਕੇਟ ਮਾਰਗ, ਇੱਕ ਨੀਤੀ
| Origin | Path | Decision owner |
|---|---|---|
| Application on the workstation | OUTPUT then egress | The VPN app's routing policy |
| Device behind the workstation | PREROUTING then FORWARD | The workstation's own forwarding policy |
ਪਹਿਲੀ ਕਤਾਰ ਉਹ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ split-tunneling ਗਾਈਡਾਂ ਦੱਸਦੀਆਂ ਹਨ। ਦੂਜੀ ਇੱਕ ਰਾਊਟਰ ਸੰਰਚਨਾ ਹੈ ਜੋ ਇਤਫ਼ਾਕਨ ਉਸੇ ਮਸ਼ੀਨ 'ਤੇ ਰਹਿੰਦੀ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਮਾਨਸਿਕ ਮਾਡਲ ਵਿੱਚ ਪਿਘਲਾਉਣਾ ਹੀ ਗਲਤੀ ਹੈ; ਉਹ ਕਰਨਲ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਨੀਤੀ ਨਹੀਂ। ਕੋਈ ਵੀ ਨਿਯਮ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਮਾਰਗ ਖਿੱਚੋ, ਅਤੇ ਬਾਕੀ ਡਿਜ਼ਾਈਨ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਮਾਰਗ ਗੁੰਮ ਹੈ।
ਇੱਕ ਮਸ਼ੀਨ ਇੱਕ ਟੈਸਟ ਪਾਸ ਕਰਕੇ ਦੂਜੇ ਵਿੱਚ ਫੇਲ ਕਿਉਂ ਹੁੰਦੀ ਹੈ, ਇਹ ਵੀ ਸਾਰਣੀ ਦੱਸਦੀ ਹੈ। ਵਰਕਸਟੇਸ਼ਨ ਦਾ ਬ੍ਰਾਊਜ਼ਰ ਸਥਾਨਕ ਮਾਰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ; Ethernet ਪੋਰਟ ਵਿੱਚ ਲੱਗਾ ਲੈਪਟਾਪ ਫਾਰਵਰਡਿੰਗ ਮਾਰਗ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਹਰ ਬਦਲਾਅ ਦੋਵਾਂ ਨਾਲ ਜਾਂਚੋ, ਨਹੀਂ ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਕਿੰਨੀ ਵੀ ਵਾਰ ਰਿਫ਼੍ਰੈਸ਼ ਹੋਵੇ, ਦੂਜਾ ਅਣਜਾਂਚਿਆ ਰਹਿੰਦਾ ਹੈ।
ਐਪ ਛੋਟ ਅਸਲ ਵਿੱਚ ਕੀ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਦੀ ਹੈ
ਪ੍ਰਤੀ-ਐਪ ਛੋਟ ਆਮ ਤੌਰ 'ਤੇ ਇੰਝ ਕੰਮ ਕਰਦੀ ਹੈ: ਕਿਸੇ ਪ੍ਰੋਸੈਸ ਜਾਂ ਵਰਤੋਂਕਾਰ ਦੇ ਪੈਕਟਾਂ 'ਤੇ ਨਿਸ਼ਾਨ ਲਾਉਣਾ, ਫਿਰ ਨਿਸ਼ਾਨ ਲੱਗੇ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਟਨਲ ਤੋਂ ਬਾਹਰ ਰੂਟ ਕਰਨਾ। ਇਹ ਸਥਾਨਕ-ਆਉਟਪੁੱਟ ਬਣਤਰ ਹੈ। ਡਾਊਨਸਟ੍ਰੀਮ ਯੰਤਰ ਦੇ ਪੈਕਟ ਦਾ ਕੋਈ ਸਥਾਨਕ ਪ੍ਰੋਸੈਸ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਉਹ ਸਿਲੈਕਟਰ ਨਾਲ ਕਦੇ ਨਹੀਂ ਮਿਲਦਾ, ਸਿਲੈਕਟਰ ਜੋ ਵੀ ਹੋਵੇ।
ਸਿਲੈਕਟਰ ਜੋ ਵੀ ਹੋਵੇ, ਦੋਵੇਂ ਸੂਚੀਆਂ ਇੱਕੋ ਸੂਚੀ ਨਹੀਂ ਹਨ, ਅਤੇ ਪੂਰੀ ਗੱਲ ਇਹੀ ਹੈ। Mullvad ਦੀ Linux ਗਾਈਡ ਉਹਨਾਂ ਨਿਸ਼ਾਨਾਂ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਜੋ ਉਸਦਾ ਫਾਇਰਵਾਲ ਅਤੇ ਰੂਟਿੰਗ ਨੀਤੀ ਵਰਤਦੀ ਹੈ, ਅਤੇ ਉਸਦੀਆਂ ਉਦਾਹਰਨਾਂ ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀਆਂ ਹਨ; ਉਹ ਡਾਊਨਸਟ੍ਰੀਮ ਰਾਊਟਰ ਦਾ ਸਮਰਥਿਤ ਵਰਣਨ ਨਹੀਂ ਹਨ। ਉਹਨਾਂ ਨੂੰ ਕਾਪੀ ਕਰਨ ਨਾਲ ਅਜਿਹੀ ਮਸ਼ੀਨ ਮਿਲਦੀ ਹੈ ਜੋ ਆਪਣੇ ਆਪ ਨੂੰ ਛੋਟ ਵਾਲੀ ਮੰਨਦੀ ਹੈ ਜਦਕਿ ਸਭ ਕੁਝ ਟਨਲ ਵਿੱਚ ਫਾਰਵਰਡ ਕਰਦੀ ਹੈ।
ਟ੍ਰਾਂਜ਼ਿਟ ਇਕਰਾਰਨਾਮਾ ਲਿਖੋ
ਡਾਊਨਸਟ੍ਰੀਮ ਸਰੋਤ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਇਨਗ੍ਰੈਸ ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਇਕੱਠਿਆਂ ਨਾਮ ਦਿਓ, ਫਿਰ ਉਸ ਪ੍ਰੀਫ਼ਿਕਸ ਨੂੰ ਇਨਗ੍ਰੈਸ 'ਤੇ ਸੀਮਿਤ ਕਰੋ। ਸੀਮਾ ਤੋਂ ਬਿਨਾਂ, ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਕੋਈ ਵੀ ਯੰਤਰ ਛੋਟ ਵਾਲਾ ਪਤਾ ਦਾਅਵਾ ਕਰਕੇ ਬਾਈਪਾਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਦੋ ਸਵਾਲਾਂ ਵਜੋਂ ਲਓ: ਕੀ ਇਹ ਹੋਸਟ ਇਹ ਅਪਲਿੰਕ ਬਿਲਕੁਲ ਵਰਤ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੀ ਉਹ ਵਰਕਸਟੇਸ਼ਨ ਜਾਂ ਟਨਲ ਦੀਆਂ ਪ੍ਰਾਈਵੇਟ ਰੇਂਜਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ? ਇਹ ਵਾਧੂ ਇਜਾਜ਼ਤਾਂ ਹਨ, ਅਪਲਿੰਕ ਚੋਣ ਦੇ ਮਾੜੇ ਪ੍ਰਭਾਵ ਨਹੀਂ।
ਫਾਰਵਰਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਫਿਰ ਇਸਨੂੰ ਫਿਲਟਰ ਕਰੋ। Linux ਗੇਟਵੇ ਨੂੰ ਫਾਰਵਰਡਿੰਗ ਸਮਰੱਥ, ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਲੋੜੀਂਦੇ ਟ੍ਰੈਫ਼ਿਕ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੇ ਨਿਯਮ, ਅਤੇ ਜਾਂ ਤਾਂ ਅਪਸਟ੍ਰੀਮ ਵਾਪਸੀ ਰੂਟ ਜਾਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੀਮਿਤ ਸਰੋਤ ਅਨੁਵਾਦ ਚਾਹੀਦਾ ਹੈ। NAT ਇਕੱਲਾ ਅਪਲਿੰਕ ਨਹੀਂ ਚੁਣਦਾ ਅਤੇ ਫਿਲਟਰ ਵਿੱਚੋਂ ਲੰਘਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ; ਉਹ ਉਹਨਾਂ ਫੈਸਲਿਆਂ ਤੋਂ ਬਾਅਦ ਸਿਰਫ਼ ਪਤਾ ਮੁੜ ਲਿਖਦਾ ਹੈ।
ਟ੍ਰਾਂਜ਼ਿਟ ਲਈ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨਾ ਫਾਰਵਰਡਿੰਗ ਰੂਟ ਫੈਸਲੇ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਭਾਵ output ਨਹੀਂ, prerouting ਪੜਾਅ ਵਿੱਚ। ਫੈਸਲੇ ਤੋਂ ਬਾਅਦ ਰੱਖਿਆ ਨਿਯਮ ਪੈਕਟ ਬਦਲ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਨਹੀਂ ਬਦਲ ਸਕਦਾ ਕਿ ਪੈਕਟ ਪਹਿਲਾਂ ਹੀ ਕਿੱਥੇ ਭੇਜਿਆ ਗਿਆ ਹੈ।
ਨਿਸ਼ਾਨ ਉਸ ਐਪ ਦੇ ਹਨ ਜੋ ਉਹਨਾਂ ਦਾ ਮਾਲਕ ਹੈ
ਨਿਸ਼ਾਨ ਮੁੱਲ, ਸਾਰਣੀ ਨੰਬਰ ਅਤੇ ਚੇਨ ਤਰਜੀਹਾਂ VPN ਐਪ ਦੀ ਨੀਤੀ ਦਾ ਹਿੱਸਾ ਹਨ, ਸਦੀਵੀ ਸਥਿਰਾਂਕ ਨਹੀਂ। ਜੋ ਨੈੱਟਵਰਕ ਦੂਜੇ ਪ੍ਰੋਗਰਾਮ ਵੱਲੋਂ ਦੁਬਾਰਾ ਬਣਾਈ ਜਾਣ ਵਾਲੀ ਸਾਰਣੀ ਵਿੱਚ ਨਿਯਮ ਪਾਉਣ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਉਹ ਅਗਲੇ ਅਪਡੇਟ ਵਿੱਚ ਟੁੱਟ ਜਾਵੇਗਾ, ਆਮ ਤੌਰ 'ਤੇ ਮੁੜ-ਕਨੈਕਟ ਵੇਲੇ, ਸੁਵਿਧਾਜਨਕ ਸਮੇਂ 'ਤੇ ਨਹੀਂ।
accept ਫ਼ੈਸਲੇ ਵਾਲੀ ਦੂਜੀ ਅਧਾਰ ਚੇਨ ਜੋੜਨਾ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਬਾਅਦ ਦੀ ਚੇਨ ਦੇ drop ਨੂੰ ਹਰਾਏ। ਅਧਾਰ ਚੇਨਾਂ ਵਿੱਚ ਹੁੱਕ ਅਤੇ ਤਰਜੀਹਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਕ੍ਰਮ ਵਿੱਚ ਪਹਿਲਾ ਫ਼ੈਸਲਾ ਜਿੱਤਦਾ ਹੈ; ਇੱਕ ਚੇਨ ਦਾ accept ਉਸ drop ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ ਜਿੱਥੇ ਦੂਜੀ ਚੇਨ ਪਹਿਲਾਂ ਪਹੁੰਚਦੀ ਹੈ। ਵਧਿਆ ਇੱਕ ਕਾਊਂਟਰ ਨਹੀਂ, ਪੂਰਾ ਨਿਯਮ-ਸਮੂਹ ਅਤੇ ਰੂਟਿੰਗ ਨੀਤੀ ਦਾ ਕ੍ਰਮ ਦੇਖੋ। ਕਾਊਂਟਰ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਨਿਯਮ ਚੱਲਿਆ, ਕਦੇ ਨਹੀਂ ਕਿ ਉਸਦਾ ਫ਼ੈਸਲਾ ਹੀ ਲਾਗੂ ਹੋਇਆ।
ਇਕੱਠਾ ਕਰੋ, ਜਾਂ ਸਬਨੈੱਟ ਹਿਲਾਓ
ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਇਸ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਬਾਈਪਾਸ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ। ਇਕੱਠਾ ਡਿਜ਼ਾਈਨ ਇੱਕ ਮਸ਼ੀਨ ਅਤੇ ਇੱਕ ਨੀਤੀ ਰੱਖਦਾ ਹੈ, ਪਰ ਇਸਦੀ ਕੀਮਤ VPN ਐਪ ਦੇ ਸਾਰਣੀ ਜੀਵਨ-ਚੱਕਰ ਅਤੇ ਉਹਨਾਂ ਨਿਸ਼ਾਨਾਂ ਦੇ ਸਮੂਹ 'ਤੇ ਨਿਰਭਰਤਾ ਹੈ ਜੋ ਉਸਦੀ ਦਸਤਾਵੇਜ਼ ਬਦਲ ਸਕਦੀ ਹੈ। ਡਾਊਨਸਟ੍ਰੀਮ ਨੈੱਟਵਰਕ ਲਈ ਸਮਰਪਿਤ ਰਾਊਟਰ ਉਹ ਨਿਰਭਰਤਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦਾ ਹੈ: ਸਬਨੈੱਟ ਦਾ ਆਪਣਾ ਅਪਲਿੰਕ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਰਕਸਟੇਸ਼ਨ ਬਿਨਾਂ ਫਾਰਵਰਡਿੰਗ ਭੂਮਿਕਾ ਦਾ ਕਲਾਇੰਟ ਰਹਿੰਦਾ ਹੈ।
ਦੂਜਾ ਚੁਣੋ ਜਦੋਂ ਡਾਊਨਸਟ੍ਰੀਮ ਨੈੱਟਵਰਕ ਨੂੰ VPN ਅਪਡੇਟਾਂ ਦੌਰਾਨ ਕੰਮ ਕਰਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਹਰ ਰਿਲੀਜ਼ ਤੋਂ ਬਾਅਦ ਇਕੱਠੀ ਨੀਤੀ ਕੋਈ ਜਾਂਚ ਨਹੀਂ ਸਕਦਾ। ਪਹਿਲਾ ਸਿਰਫ਼ ਤਦ ਚੁਣੋ ਜਦੋਂ ਏਕੀਕਰਨ ਦਸਤਾਵੇਜ਼ੀ ਹੋਵੇ ਅਤੇ ਕੋਈ ਇਸਦਾ ਜ਼ਿੰਮੇਵਾਰ ਹੋਵੇ।
ਚਾਰ ਹਾਲਾਤਾਂ ਵਿੱਚ ਸੀਮਾ ਜਾਂਚੋ: ਜੁੜਿਆ, ਮੁੜ-ਜੁੜਦਾ, ਜਾਣ-ਬੁੱਝ ਕੇ ਰੋਕਿਆ ਅਤੇ ਰੋਕਿਆ ਗਿਆ। ਹਰ ਇੱਕ ਵਿੱਚ ਨਾਮ-ਹੱਲ ਅਤੇ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ DNS ਲੀਕ ਕਰਨ ਵਾਲਾ ਬਾਈਪਾਸ ਤੁਹਾਡੀ ਬਣਾਈ ਛੋਟ ਨਹੀਂ ਹੈ। ਟੈਸਟ ਨੂੰ ਸਹੀ ਸੀਮਾ ਸਾਬਤ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਇੱਕ ਸਫ਼ਾ ਲੋਡ ਹੋਇਆ ਇਹ ਨਹੀਂ।