ਦੋ VPN ਪੂਲਾਂ ਲਈ ਸਰੋਤ ਰਾਊਟਿੰਗ: ਤੁਹਾਡਾ ਨਿਯਮ ਕੀ ਖੁੰਝਾਉਂਦਾ ਹੈ
from ਸ਼ਕਲ ਦਾ ਨਿਯਮ SNAT ਦੁਆਰਾ ਦੁਬਾਰਾ ਲਿਖੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਪਤੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਤੋਂ ਕੀਤੀ ਜਾਂਚ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨਾਲ ਵੀ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀ। ਹਰ ਪੂਲ ਲਈ ਲੁੱਕਅਪ ਚਲਾਓ ਅਤੇ ਇਸ ਦੀ ਥਾਂ ਤਰਜੀਹਾਂ ਪੜ੍ਹੋ।
ਦੋ ਕਲਾਇੰਟ ਪੂਲ, ਇੱਕ ਗੇਟਵੇ ਅਤੇ ਯੋਜਨਾ ਸਧਾਰਨ ਲੱਗਦੀ ਹੈ: ਇੱਕ ਨਿਯਮ ਪਹਿਲੇ ਪੂਲ ਨੂੰ ਤੇਜ਼ ਅੱਪਲਿੰਕ ਰਾਹੀਂ ਬਾਹਰ ਭੇਜਦਾ ਹੈ, ਦੂਜਾ ਦੂਜੇ ਪੂਲ ਨੂੰ ਸਾਥੀ ਟਨਲ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ। ਫਿਰ ਨਿਯਮ ਥਾਂ 'ਤੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਦੂਜਾ ਪੂਲ ਫਿਰ ਵੀ ਡਿਫਾਲਟ ਰੂਟ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਨਿਯਮ ਟੁੱਟਿਆ ਨਹੀਂ ਹੈ। ਲੁੱਕਅੱਪ ਦੇ ਪਲ ਲੇਖਕ ਨੇ ਜੋ ਉਮੀਦ ਕੀਤੀ ਸੀ ਉਹ ਪੈਕੇਟ ਦਾ ਸਰੋਤ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਅਨੁਵਾਦ ਅਤੇ ਲੁੱਕਅੱਪ ਇੱਕੋ ਪੈਕੇਟ ਦੀ ਯਾਤਰਾ ਦੇ ਵੱਖਰੇ ਬਿੰਦੂਆਂ 'ਤੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕ੍ਰਮ ਉਸ ਮਾਨਸਿਕ ਚਿੱਤਰ ਦੇ ਉਲਟ ਹੈ ਜੋ ਬਹੁਤੇ ਲੋਕ ਬਣਾਉਂਦੇ ਹਨ।
ਲੁੱਕਅੱਪ ਸਰੋਤ ਦੇ ਦੁਬਾਰਾ ਲਿਖੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ
VPN ਕਲਾਇੰਟ ਤੋਂ ਅੱਗੇ ਭੇਜੇ ਜਾਂਦੇ ਪੈਕੇਟ ਲਈ ਕਰਨਲ ਇੱਕ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਚਲਾਉਂਦਾ ਹੈ। ਇਹ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਆਉਂਦਾ ਹੈ, conntrack ਅਤੇ DNAT ਵਾਲੇ prerouting ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਫਿਰ ਰਾਊਟਿੰਗ ਫੈਸਲਾ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਫਾਰਵਰਡਿੰਗ, ਫਿਰ SNAT ਸਭ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਹੋਣ ਵਾਲਾ postrouting। from ਸ਼ਕਲ ਦਾ ਨਿਯਮ ਉਸੇ ਰਾਊਟਿੰਗ ਫੈਸਲੇ ਵੇਲੇ ਵੇਖਿਆ ਜਾਂਦਾ ਹੈ, ਭਾਵ ਇਹ ਕਲਾਇੰਟ ਦਾ ਮੂਲ ਪਤਾ ਵੇਖਦਾ ਹੈ, ਅਨੁਵਾਦਿਤ ਪਤਾ ਨਹੀਂ।
ਇਸ ਲਈ masquerade ਨਿਯਮ ਜੋੜਨ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਬਾਹਰ ਜਾਂਦੇ ਪ੍ਰਵਾਹ ਉੱਤੇ ਕਿਹੜੀ ਨੀਤੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ। ਬਦਲਦਾ ਇਹ ਹੈ ਕਿ ਦੂਰਲਾ ਸਿਰਾ ਕੀ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਕਿਹੜਾ ਵਾਪਸੀ ਮਾਰਗ ਮੌਜੂਦ ਹੈ। ਇਹ ਦੋ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ, ਅਤੇ ਤਬਦੀਲੀ ਸਮੀਖਿਆਵਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਲਗਾਤਾਰ ਰਲਾਉਂਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕਰੋ ਅਤੇ ਡਿਜ਼ਾਈਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ।
ਜਵਾਬ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ ਹੀ ਅਨੁਵਾਦਿਤ ਪਤਾ ਨਿਯਮਾਂ ਵਿੱਚ ਦਿਖਦਾ ਹੈ। ਗੇਟਵੇ 'ਤੇ ਵਾਪਸ ਆਉਣ ਵਾਲਾ ਪੈਕੇਟ ਅਨੁਵਾਦਿਤ ਪਤੇ ਨੂੰ ਸੰਬੋਧਿਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜੇ ਮੰਜ਼ਿਲ ਜਾਂ ਜਿਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਇਹ ਆਇਆ ਉਸ ਦੇ ਆਧਾਰ 'ਤੇ ਨੀਤੀ ਨਿਯਮ ਹਨ, ਤਾਂ ਉਹੀ ਮੁੱਲ ਤੁਸੀਂ ਮਿਲਾਓਗੇ। ਇੱਕੋ ਕਨੈਕਸ਼ਨ, ਹਰ ਦਿਸ਼ਾ ਵਿੱਚ ਸੱਚ ਦਾ ਵੱਖਰਾ ਸਰੋਤ।
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
ਇਸ ਲਈ ਵੱਖਰੇ ਸਰੋਤਾਂ ਵਾਲੇ ਦੋ ਪੂਲਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਵੱਖਰੀਆਂ ਟੇਬਲਾਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਡਿਜ਼ਾਈਨ ਸਹੀ ਹੈ। ਉੱਪਰਲੀ ਟੇਬਲ ਜਿਸ ਨੂੰ ਰੱਦ ਕਰਦੀ ਹੈ ਉਹ ਦੂਰਲੀ ਸਾਈਟ ਨੇ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ ਇਹ ਵੇਖ ਕੇ ਨਿਯਮ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦਾ ਛੋਟਾ ਰਾਹ ਹੈ।
ਗੇਟਵੇ ਤੋਂ ਕੀਤੀ ਜਾਂਚ ਪੂਲ ਦੀ ਜਾਂਚ ਨਹੀਂ ਹੈ
ਗੇਟਵੇ ਆਪ ਜੋ ਟ੍ਰੈਫਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ ਉਹ ਕਦੇ prerouting ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ, ਕਿਉਂਕਿ ਉਹ ਕਿਸੇ ਇੰਟਰਫੇਸ 'ਤੇ ਆਇਆ ਨਹੀਂ। ਉਹ ਆਊਟਪੁੱਟ ਮਾਰਗ ਵਿੱਚ ਰਾਊਟ ਹੁੰਦਾ ਹੈ, ਸਰੋਤ ਵਜੋਂ ਗੇਟਵੇ ਦਾ ਆਪਣਾ ਪਤਾ, ਅਤੇ ਕਲਾਇੰਟ ਰੇਂਜ 'ਤੇ ਆਧਾਰਿਤ from ਨਿਯਮ ਮੇਲ ਨਹੀਂ ਖਾਏਗਾ। ਇਸ ਖੇਤਰ ਦੀ ਹਰ ਟਿਕਟ ਜੋ ਕਹਿੰਦੀ ਹੈ ਕਿ ਬਾਕਸ ਤੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਕਲਾਇੰਟ ਤੋਂ ਨਹੀਂ, ਉਹ ਉਸੇ ਤੱਥ ਦੀ ਪੁਨਰਾਵ੍ਰਿੱਤੀ ਹੈ।
ਕਲਾਇੰਟ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਉਸ ਦੀ ਨਕਲ ਕਰੋ। ਰਾਊਟਿੰਗ ਲੁੱਕਅੱਪ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸਰੋਤ ਅਤੇ ਇਨਗ੍ਰੈਸ ਇੰਟਰਫੇਸ ਦੇ ਕੇ:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201ਇਹ ਹਰ ਪੂਲ ਲਈ ਇੱਕ ਵਾਰ ਚਲਾਓ। ਜੇ ਦੋਵੇਂ ਕਮਾਂਡਾਂ ਇੱਕੋ ਇੰਟਰਫੇਸ ਵਾਪਸ ਦਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਨਿਯਮ ਪੂਲਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਰਹੇ, ਅਤੇ ਕਾਰਨ ਜਾਂ ਤਾਂ ਗੁੰਮ ਨਿਯਮ ਹੈ ਜਾਂ ਦੋਵਾਂ ਨਾਲ ਮੇਲ ਖਾਣ ਵਾਲਾ ਵੱਧ ਤਰਜੀਹ ਵਾਲਾ ਨਿਯਮ। ਜੇ ਉਹ ਵੱਖਰੇ ਇੰਟਰਫੇਸ ਵਾਪਸ ਦਿੰਦੀਆਂ ਹਨ ਪਰ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਖਰਾਬੀ ਲੁੱਕਅੱਪ ਤੋਂ ਬਾਅਦ ਹੈ ਅਤੇ ਤੁਸੀਂ ਨਿਯਮ ਵੇਖਣਾ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ।
ਤਰਜੀਹ, ਫਾਈਲ ਵਿੱਚ ਥਾਂ ਨਹੀਂ
ਨਿਯਮ ਤਰਜੀਹ ਦੇ ਵਧਦੇ ਕ੍ਰਮ ਵਿੱਚ ਮੁਲਾਂਕਣ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਸੰਖਿਆ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤੁਸੀਂ ਜੋ ਕ੍ਰਮ ਟਾਈਪ ਕੀਤਾ ਉਹ ਨਹੀਂ। local ਟੇਬਲ ਤਰਜੀਹ 0 'ਤੇ, main ਟੇਬਲ 32766 'ਤੇ ਅਤੇ ਡਿਫਾਲਟ ਨਿਯਮ 32767 'ਤੇ ਹੈ, ਇਸ ਲਈ ਡਿਫਾਲਟ ਤਰਜੀਹ ਨਾਲ ਜੋੜਿਆ ਨਿਯਮ ਸੂਚੀ ਦੇ ਅੰਤ ਨੇੜੇ ਪੈਂਦਾ ਹੈ ਅਤੇ ਲਗਭਗ ਸਭ ਤੋਂ ਹਾਰ ਜਾਂਦਾ ਹੈ।
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201ਸਪੱਸ਼ਟ ਤਰਜੀਹ ਇੱਛਤ ਕ੍ਰਮ ਨੂੰ ਫਾਈਲ ਵਿੱਚ ਅਤੇ ਸਮੀਖਿਆ ਵਿੱਚ ਦਿਖਣਯੋਗ ਬਣਾਉਂਦੀ ਹੈ। ਇਹ ਬਾਅਦ ਦੇ ਜੋੜ ਨੂੰ ਮੌਜੂਦਾ ਨਿਯਮ ਤੋਂ ਚੁੱਪਚਾਪ ਅੱਗੇ ਛਾਲ ਮਾਰਨ ਤੋਂ ਵੀ ਰੋਕਦੀ ਹੈ, ਜੋ ਅਸੰਬੰਧਿਤ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਚੱਲ ਰਹੀ ਨੀਤੀ ਦੇ ਰੁਕਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ।
ਅਧੂਰੀ ਟੇਬਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਮੇਲ ਖਾਣ ਵਾਲਾ ਨਿਯਮ ਦੂਜਾ ਜਾਲ ਹੈ। ਜੇ ਟੇਬਲ 201 ਵਿੱਚ ਡਿਫਾਲਟ ਰੂਟ ਹੈ ਪਰ ਮੰਜ਼ਿਲ ਦਾ ਰੂਟ ਨਹੀਂ, ਤਾਂ ਪੈਕੇਟ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਾਂ ਗਲਤ ਥਾਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਿਯਮ ਅਲੱਗ ਵੇਖਿਆਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹੀ ਲੱਗਦਾ ਹੈ। ਨਿਯਮ ਨਹੀਂ, ਟੇਬਲ ਪੜ੍ਹੋ। ਨਿਯਮ ਇੱਕ ਸੂਚਕ ਹੈ, ਅਤੇ ਖਾਲੀ ਟੇਬਲ ਕੁਝ ਵੀ ਨਾ ਹੋਣ ਵੱਲ ਸੂਚਕ ਹੈ।
ਵਾਪਸੀ ਮਾਰਗ ਫਿਰ ਵੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ
ਸਰੋਤ ਨੀਤੀ ਇੱਕ ਨਿਕਾਸ ਚੁਣਦੀ ਹੈ। ਇਹ ਵਾਪਸੀ ਮਾਰਗ ਨਹੀਂ ਬਣਾਉਂਦੀ। ਜੇ ਦੂਜਾ ਪੂਲ ਸਾਥੀ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਥੀ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ 172.31.8.0/24 ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ, ਜਾਂ ਤਾਂ ਗੇਟਵੇ ਵੱਲ ਵਾਪਸੀ ਰੂਟ ਨਾਲ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਜਾਣੇ ਅਨੁਵਾਦਿਤ ਪਤੇ ਪ੍ਰਾਪਤ ਕਰਕੇ।
ਇਨ੍ਹਾਂ ਵਿਚਕਾਰ ਚੋਣ ਦਿਖਣਯੋਗ ਨਤੀਜਿਆਂ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਹੈ। ਕਲਾਇੰਟ ਰੇਂਜ ਨੂੰ ਵਾਪਸ ਰਾਊਟ ਕਰਨ ਨਾਲ ਸਾਥੀ ਕੋਲ ਹਰ ਕਲਾਇੰਟ ਦੀ ਪਛਾਣ ਬਚਦੀ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਤੁਹਾਡਾ ਪ੍ਰਿਫਿਕਸ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਅਨੁਵਾਦ ਪੂਲ ਨੂੰ ਇੱਕ ਪਤੇ ਪਿੱਛੇ ਲੁਕਾਉਂਦਾ ਹੈ ਅਤੇ ਸਾਥੀ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਪਤਾ ਸਵੀਕਾਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਕੀਮਤ 'ਤੇ ਕਿ ਤੁਹਾਡੇ ਅਤੇ ਉਸ ਦੇ ਲਾਗ ਹੁਣ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਣਗੇ ਕਿ ਕੌਣ ਜੁੜਿਆ।
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਉਹ ਪੂਲ ਪਰਿਭਾਸ਼ਾ ਦੇ ਕੋਲ ਲਿਖੋ। ਸਿਰਫ਼ ਕਿਸੇ ਦੀ ਯਾਦ ਵਿੱਚ ਹੀ ਮੌਜੂਦ ਵਾਪਸੀ ਰੂਟ ਠੀਕ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਸਾਥੀ ਦੇ ਫਾਇਰਵਾਲ ਬਦਲਣ ਤੱਕ ਟਿਕੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਵਿੱਚ ਇੱਕ ਦਿਨ ਲੱਗਦਾ ਹੈ।
ਨੀਤੀ ਵਿੱਚ ਗੇਟਵੇ ਦਾ ਆਪਣਾ ਟਨਲ ਨਾ ਫੜੋ
ਕਲਾਇੰਟਾਂ ਲਈ ਲਿਖੇ ਨਿਯਮ ਗੇਟਵੇ ਦੁਆਰਾ ਪੈਦਾ ਟ੍ਰੈਫਿਕ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਸ ਨੂੰ ਬਾਹਰ ਨਾ ਰੱਖੋ। ਮਾਰਕ ਜਾਂ ਆਊਟਪੁੱਟ ਇੰਟਰਫੇਸ 'ਤੇ ਆਧਾਰਿਤ ਚੌੜਾ ਨਿਯਮ ਗੇਟਵੇ ਦਾ ਸਾਥੀ ਨਾਲ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਫੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਨੀਤੀ ਢੋਣ ਵਾਲਾ ਟਨਲ ਨੀਤੀ ਰਾਹੀਂ ਰਾਊਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਨਾਲ ਲੂਪ ਜਾਂ ਰੁਕਾਵਟ ਪੈਦਾ ਹੁੰਦੀ ਹੈ ਜੋ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੀ ਖਰਾਬੀ ਵਰਗੀ ਲੱਗਦੀ ਹੈ।
ਹਰ ਨਿਯਮ ਨੂੰ ਡਿਜ਼ਾਈਨ ਦੀ ਆਗਿਆ ਤੱਕ ਤੰਗ ਰੱਖੋ: ਸਰੋਤ ਪ੍ਰਿਫਿਕਸ, ਇਨਗ੍ਰੈਸ ਇੰਟਰਫੇਸ ਅਤੇ ਜਿੱਥੇ ਸਮਰਥਨ ਹੋਵੇ ਉੱਥੇ ਉਹ ਮਾਰਕ ਜੋ ਸਿਰਫ਼ ਕਲਾਇੰਟ ਪੈਕੇਟ ਢੋਂਦੇ ਹਨ। ਫਿਰ ਹਰ ਨਿਯਮ ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਗੇਟਵੇ ਦੀ ਆਪਣੀ ਕਨੈਕਟੀਵਿਟੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਖਰਾਬੀ ਸਵੈ-ਹਵਾਲਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਜਾਂਚ ਵਿੱਚ ਨਹੀਂ ਦਿਖਦੀ।
ip-rule ਮੈਨੁਅਲ ਪੰਨਾ ਚੋਣਕਰਤਾ ਅਤੇ ਤਰਜੀਹ ਦਾ ਅਰਥ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਇਸ ਨੂੰ ਹਰ ਪੂਲ ਦੀ ਲੁੱਕਅੱਪ ਜਾਂਚ ਨਾਲ ਜੋੜੋ ਅਤੇ ਡਿਜ਼ਾਈਨ ਜਾਂਚਣਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਸਾਲ ਟਿਕਣ ਵਾਲੀ ਨੀਤੀ ਰਾਊਟਿੰਗ ਅਤੇ ਸਭ ਨੂੰ ਛੂਹਣ ਤੋਂ ਡਰਨ ਵਾਲੀ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ।