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

ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਨਾਮ ਦੋ ਸਿਰੇ ਛੁਪਾਉਂਦਾ ਹੈ

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

ਉਤਪਾਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲੋੜ ਨੂੰ ਜੋੜੀ ਵਜੋਂ ਲਿਖੋ। ਉਹੀ ਜੋੜੀ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪਰਖੋਗੇ।

ਜਿਹੜਾ ਉਤਪਾਦ ਡਿਵਾਈਸ-ਸੂਚੀ ਜਾਂ ਗਲੋਬਲ ਟਿਕਾਣਾ-ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਉਹ ਸ਼ਾਇਦ «ਸਿਰਫ਼ ਇਹ ਡਿਵਾਈਸ, ਸਿਰਫ਼ ਇਹ ਟਿਕਾਣੇ» ਨਹੀਂ ਕਹਿ ਸਕਦਾ। ਇਹ ਅੰਤਰ ਦਿਖਾਵੇ ਦਾ ਨਹੀਂ: ਗਲੋਬਲ ਟਿਕਾਣਾ-ਨਿਯਮ ਉਸ ਸਾਈਟ ਲਈ ਹਰ ਡਿਵਾਈਸ ਦਾ ਟ੍ਰੈਫਿਕ ਟਨਲ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ-ਨਿਯਮ ਉਸ ਡਿਵਾਈਸ ਦਾ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਭੇਜਦਾ ਹੈ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਲੋੜ ਨਹੀਂ। ਸਕ੍ਰੀਨ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸਥਿਤੀ ਦੋ ਡਿਵਾਈਸਾਂ ਨਾਲ ਪਰਖੋ।

ਨਿਯਮ ਨੂੰ ਕੱਟ ਵਜੋਂ ਬਣਾਓ

ਇੱਕ ਸਾਰਣੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖਦੀ ਹੈ। ਸਥਿਤੀ ਖੱਬੇ ਪਾਓ, ਫਿਰ ਭੇਜਣ ਵਾਲੇ ਦਾ ਮੇਲ ਅਤੇ ਨਿਸ਼ਾਨੇ ਦਾ ਮੇਲ ਵੱਖਰੇ ਨਾਮ ਦਿਓ:

ScenarioSender matchTarget matchRule shape
Media player uses the tunnelPlayer addressAny internet destination except the LANSource only
Office prefix reachableAuthorized LAN devices10.40.0.0/16Target only
One app on one laptopLaptop addressThe service address setSource and target
Guest network never tunnelsGuest subnetAnyDeny, evaluated first

ਤੀਜੀ ਕਤਾਰ ਦਿਲਚਸਪ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਦੋਵੇਂ ਅੱਧ ਇਕੱਠੇ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਫਰਮਵੇਅਰ ਸਿਰਫ਼ ਇੱਕ ਧੁਰਾ ਦੱਸ ਸਕਦਾ ਹੈ, ਤਾਂ ਲੋੜ ਨੂੰ ਦੋ ਨਿਯਮਾਂ ਵਿੱਚ ਵੰਡਣਾ ਪਵੇਗਾ ਜਾਂ ਅਜਿਹੀ ਡਿਵਾਈਸ ਵਿੱਚ ਭੇਜਣਾ ਪਵੇਗਾ ਜੋ ਇਹ ਕਰ ਸਕੇ।

ਸਰੋਤ ਦੀ ਪਛਾਣ ਸਥਿਰ ਰੱਖੋ। DHCP ਰਿਜ਼ਰਵੇਸ਼ਨ, ਸਮਰਪਿਤ ਸੈਗਮੈਂਟ ਜਾਂ ਡਿਵਾਈਸ-ਪਛਾਣ ਵਿਧੀ ਸਭ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਲੀਜ਼ ਖ਼ਤਮ ਹੋਣ ਮਗਰੋਂ ਬਦਲਣ ਵਾਲਾ ਪਤਾ ਨਹੀਂ। IPv6 ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਇੱਕ IPv4 ਪਤਾ ਡਿਵਾਈਸ ਦਾ ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਪਛਾਣਦਾ।

ਓਵਰਲੈਪ ਤਰਜੀਹ ਤੈਅ ਕਰਦੀ ਹੈ

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

ਕ੍ਰਮ ਅਤੇ ਮੇਲ ਨਾ ਹੋਣ ਵਾਲੀ ਸਥਿਤੀ ਲਈ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੋ, ਫਿਰ ਦੋਵਾਂ ਨੂੰ ਉਸ ਟ੍ਰੈਫਿਕ ਨਾਲ ਪਰਖੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ:

ip rule show
ip route get 203.0.113.10

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

ਨਾਵਾਂ ਨੂੰ ਰਿਫ੍ਰੈਸ਼ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ

ਡੋਮੇਨ ਵਜੋਂ ਲਿਖਿਆ ਟਿਕਾਣਾ ਸੰਭਾਲ ਦੀ ਸਮੱਸਿਆ ਜੋੜਦਾ ਹੈ। ਰਾਊਟਰ ਨੂੰ ਇਸ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਵੇਗਾ, ਮੈਪਿੰਗ ਰਿਫ੍ਰੈਸ਼ ਕਰਨੀ ਪਵੇਗੀ, ਕਈ ਪਤੇ ਅਤੇ ਸਬ-ਡੋਮੇਨ ਸੰਭਾਲਣੇ ਪੈਣਗੇ, ਅਤੇ ਉਮੀਦ ਕੀਤੇ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਵਾਲੇ ਐਪਲੀਕੇਸ਼ਨ DNS ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਵੇਗਾ।

ਇੱਕ ਖੋਜ ਨਤੀਜੇ ਨੂੰ IP ਨਿਯਮ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਸਨੈਪਸ਼ਾਟ ਹੈ, ਡੋਮੇਨ ਨੀਤੀ ਨਹੀਂ।

ਨਿਯਮ ਗਲਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਕਿੰਨਾ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਫੇਲ੍ਹ ਹੋਣ ਉੱਤੇ ਰਾਊਟਰ ਕੀ ਕਰਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ। ਆਖਰੀ ਜਾਣਿਆ ਪਤਾ ਰੱਖਣ ਵਾਲਾ ਨਿਯਮ ਸੇਵਾ-ਤਬਾਦਲੇ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕ ਸਕਦਾ ਹੈ; ਐਂਟਰੀ ਸੁੱਟਣ ਵਾਲਾ ਨਿਯਮ ਟਨਲਿੰਗ ਚੁੱਪਚਾਪ ਰੋਕ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਵਿਵਹਾਰ ਮੰਨਣਯੋਗ ਹਨ ਜੇ ਉਹ ਨਿਯਮ ਦੇ ਕੋਲ ਲਿਖੇ ਹੋਣ।

ਉਪਲਬਧ ਨਾ ਹੋਣ ਦੀ ਸਥਿਤੀ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ

ਰੂਟ ਤਰਜੀਹ ਸਿਰਫ਼-VPN ਟ੍ਰੈਫਿਕ ਲਾਗੂ ਨਹੀਂ ਕਰਦੀ। ਜਦੋਂ ਟਨਲ ਬੰਦ ਹੁੰਦਾ ਹੈ, ਰਾਊਟਰ ਪ੍ਰਵਾਹ ਰੋਕ ਸਕਦਾ ਹੈ, ਸਿੱਧਾ ਭੇਜ ਸਕਦਾ ਹੈ ਜਾਂ ਦੂਜੀ ਟਨਲ ਵਰਤ ਸਕਦਾ ਹੈ, ਅਤੇ ਹਰ ਚੋਣ ਦਾ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਨਿਸ਼ਾਨ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ।

ਲੋੜ ਨੂੰ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਤੈਅ ਕਰੋ, ਫਿਰ ਟਨਲ ਬੰਦ ਕਰਕੇ ਅਤੇ ਪ੍ਰਵਾਹ ਦੇਖ ਕੇ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

ਰਾਊਟਰ ਤੋਂ ਹੀ ਪੈਦਾ ਹੋਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਵੱਖਰਾ ਖੇਤਰ ਹੈ। DNS ਫਾਰਵਰਡਿੰਗ, ਅਪਡੇਟ-ਜਾਂਚਾਂ ਅਤੇ ਨਿਗਰਾਨੀ ਡਿਵਾਈਸ ਦੇ ਸਰੋਤ-ਮੇਲ ਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਦੀ ਬਜਾਏ ਰਾਊਟਰ ਤੋਂ ਹੀ ਨਵੇਂ ਪ੍ਰਵਾਹ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਪ੍ਰਵਾਹਾਂ ਦਾ ਸਪਸ਼ਟ ਹਿਸਾਬ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਉਹ ਲੌਗਾਂ ਵਿੱਚ ਅਸਪਸ਼ਟ ਲੀਕ ਵਜੋਂ ਦਿਖਣਗੇ।

ਸੰਬੰਧਿਤ ਲੇਖ