ਸ਼ਾਖਾ ਅਤੇ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਵਿਚਕਾਰ ਲਿੰਕ ਲਈ ਰੂਟਿਡ VPN ਜਾਂ ਬ੍ਰਿਜਡ LAN

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

ਜੋੜਨ ਦੇ ਦੋ ਤਰੀਕੇ, ਇੱਕ ਸਪਸ਼ਟ ਸਮਝੌਤਾ

ਰੂਟਿਡ ਲਿੰਕ ਘਰੇਲੂ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਨੂੰ ਆਪਣੀ ਐਡਰੈਸਿੰਗ ਵਾਲਾ ਦੂਰ ਦਾ ਨੈੱਟਵਰਕ ਮੰਨਦਾ ਹੈ। ਸ਼ਾਖਾ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦਾ ਪ੍ਰੀਫਿਕਸ ਮੰਗਦੀ ਹੈ, ਟਨਲ ਉਹ ਪੈਕਟ ਢੋਂਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦਾ ਗੇਟਵੇ ਆਪਣੇ ਹੀ ਸਬਨੈੱਟ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਸ਼ਾਖਾ ਦੀ ARP ਸਾਰਣੀ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦੇ DHCP ਘੇਰੇ ਤੋਂ ਕੁਝ ਵੀ ਸ਼ਾਖਾ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਬ੍ਰਿਜਡ ਲਿੰਕ ਇੱਕ ਹੀ ਲੇਅਰ 2 ਡੋਮੇਨ ਦੋਵਾਂ ਸਾਈਟਾਂ ਉੱਤੇ ਫੈਲਾਉਂਦਾ ਹੈ। ਖੋਜ ਪ੍ਰੋਟੋਕੋਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਡਿਵਾਈਸ ਆਪਣੇ ਆਪ ਦਿਸਦੇ ਹਨ, ਅਤੇ ਹਰ ਬ੍ਰੌਡਕਾਸਟ, ਹਰ ARP ਬੇਨਤੀ ਅਤੇ ਹਰ multicast ਪੈਕਟ ਹੁਣ ਟਨਲ ਲੰਘਣ ਦਾ ਉਮੀਦਵਾਰ ਹੈ, ਯਾਨੀ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਜੋ ਸਥਾਨਕ ਸੈਗਮੈਂਟ ਲਈ ਬਣੇ ਪ੍ਰੋਟੋਕੋਲ ਢੋਂਦੇ ਹਨ, ਵੱਖਰੇ MTU ਅਤੇ ਬਦਲਦੇ ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮੇ ਵਾਲੇ WAN ਲਈ ਨਹੀਂ।

ਰੂਟਿੰਗ ਤੁਹਾਨੂੰ ਕੀ ਦਿੰਦੀ ਹੈ

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

ਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇਹ ਉਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਟਨਲ ਅਸਲ ਵਿੱਚ ਢੋਂਦਾ ਹੈ। IPsec ਨੀਤੀ ਪ੍ਰੀਫਿਕਸਾਂ ਦੀ ਜੋੜੀ ਹੈ, ਅਤੇ ਹਰ ਪਾਸੇ ਅੱਗੇ ਭੇਜਣ ਦਾ ਰਾਹ ਗੇਟਵੇ ਉੱਤੇ ਅੱਗੇ ਭੇਜਣ ਸਮਰੱਥ ਕਰਕੇ ਆਮ IP ਰੂਟਿੰਗ ਹੈ:

sysctl -w net.ipv4.ip_forward=1
ip route add 10.20.0.0/24 via 192.168.50.1
ip route get 10.20.0.40

ਤੁਸੀਂ ਜੋ ਛੱਡਦੇ ਹੋ ਉਹ ਬ੍ਰੌਡਕਾਸਟ ਰਾਹੀਂ ਖੋਜ ਹੈ। ਇਹ ਅਸਲੀ ਨੁਕਸਾਨ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਭ ਕੁਝ ਬ੍ਰਿਜ ਕਰਕੇ ਬਚਣ ਦੀ ਥਾਂ ਜਾਣਬੁੱਝ ਕੇ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ।

ਬ੍ਰਿਜਿੰਗ ਦੀ ਲਾਗਤ

ਬ੍ਰਿਜਿੰਗ ਨੂੰ ਲੇਅਰ 2 ਫ੍ਰੇਮ ਟਨਲ ਰਾਹੀਂ ਢੋਣੇ ਪੈਂਦੇ ਹਨ, ਯਾਨੀ ਸਾਧਾਰਨ ਨੀਤੀ-ਅਧਾਰਿਤ ਟਨਲ ਦੀ ਥਾਂ IPsec ਉੱਤੇ GRE ਜਾਂ VXLAN ਵਰਗਾ ਐਨਕੈਪਸੂਲੇਸ਼ਨ। ਜਿਵੇਂ ਹੀ ਇਹ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ, ਦੋਵੇਂ ਸਾਈਟਾਂ ਇੱਕੋ ਅਸਫਲਤਾ ਡੋਮੇਨ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ। Spanning tree ਟਨਲ ਨੂੰ ਲਿੰਕ ਮੰਨਦਾ ਹੈ, ਬ੍ਰੌਡਕਾਸਟ ਟ੍ਰੈਫਿਕ ਟਨਲ ਦੀ ਬੈਂਡਵਿਡਥ ਖਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਡਿਵਾਈਸ ਜੋ ਘੱਟ ਦੇਰੀ ਵਾਲਾ ਸੈਗਮੈਂਟ ਮੰਨ ਲੈਂਦੀ ਹੈ ਅਜਿਹੇ ਢੰਗਾਂ ਨਾਲ ਗਲਤ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਵੀ ਸਿਰੇ ਤੋਂ ਜੋੜਨਾ ਔਖਾ ਹੈ।

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

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

ਬ੍ਰੌਡਕਾਸਟ ਤੋਂ ਬਿਨਾਂ ਨਾਮ

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

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

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

ਰੂਟਿਡ ਡਿਜ਼ਾਈਨ ਪਰਖਣਯੋਗ ਬਣਾਓ

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

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

ਫਿਰ ਰੱਦ ਕੀਤੀ ਮੰਜ਼ਿਲ ਵੀ ਪਰਖੋ। ਸ਼ਾਖਾ ਦੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਜਿਸਨੂੰ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ ਉਸਨੂੰ hypervisor ਕੰਸੋਲ ਨਹੀਂ ਚਾਹੀਦਾ, ਅਤੇ ਨੀਤੀ ਅਸਲੀ ਹੈ ਇਹ ਜਾਣਨ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਹੈ ਉਹੀ ਅਜ਼ਮਾਉਣਾ ਜਿਸਨੂੰ ਇਸਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਪ੍ਰੀਫਿਕਸ, ਰਿਜ਼ੌਲਵਰ ਉੱਤੇ ਨਿਰਭਰਤਾ ਅਤੇ ਪਰਖ ਨਤੀਜੇ ਦਰਜ ਕਰੋ, ਅਤੇ ਕਿਸੇ ਵੀ ਸਾਈਟ ਵਿੱਚ ਭਵਿੱਖੀ ਬਦਲਾਅ ਯਾਦ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਥਾਂ ਮਿੰਟਾਂ ਵਿੱਚ ਵੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।