ਗੈਸਟ Wi-Fi ਮੁੱਖ ਰੂਟ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ: ਇਸਨੂੰ ਆਪਣਾ ਬਾਹਰ ਜਾਣ ਦਾ ਰਾਹ ਦਿਓ

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

ਲੱਛਣ: ਮਹਿਮਾਨ ਅਜੇ ਵੀ WAN ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ

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

ਦੂਜਾ ਸੰਕੇਤ ਇਹ ਹੈ ਕਿ ਮਹਿਮਾਨਾਂ ਦੇ ਬ੍ਰਾਊਜ਼ ਕਰਦੇ ਸਮੇਂ ਸੁਰੰਗ ਇੰਟਰਫੇਸ 'ਤੇ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਕਾਊਂਟਰ ਨਹੀਂ ਹਿੱਲਦੇ, ਤਾਂ ਨੀਤੀ ਕਦੇ ਲਾਗੂ ਨਹੀਂ ਹੋਈ, ਅਤੇ ਸੁਰੰਗ ਨੂੰ ਆਪ ਸਮਾਯੋਜਿਤ ਕਰਨ ਨਾਲ ਮਦਦ ਨਹੀਂ ਹੋ ਸਕਦੀ।

ਕਦਮ 1: ਸਿਰਫ਼ ਨਾਮ ਨਹੀਂ, ਅਸਲ ਸੈਗਮੈਂਟ

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

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

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

ਕਦਮ 2: ਸਰੋਤ ਅਨੁਸਾਰ ਸੁਰੰਗ ਚੁਣੋ

ਰੂਟਿੰਗ ਟੇਬਲ ਮੰਜ਼ਿਲ ਅਨੁਸਾਰ ਚੁਣੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ «0.0.0.0/0 ਸੁਰੰਗ ਵਿੱਚ ਭੇਜੋ» ਵਾਲਾ ਨਿਯਮ ਸਾਰਿਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਨੀਤੀ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਦੂਜਾ ਆਯਾਮ ਜੋੜਦੀ ਹੈ: ਸਰੋਤ ਪਤੇ ਅਨੁਸਾਰ ਟੇਬਲ ਚੁਣੋ। Linux-ਅਧਾਰਿਤ ਰਾਊਟਰ 'ਤੇ, ਇਹ ਵਾਧੂ ਨਿਯਮ ਅਤੇ ਇੱਕ ਸਮਰਪਿਤ ਟੇਬਲ ਹੈ, ਅਤੇ ਕ੍ਰਮ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਪਹਿਲਾ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਜਿੱਤਦਾ ਹੈ:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

ਕਦਮ 3: ਜਵਾਬ ਰਾਹ ਅਤੇ ਅਨੁਵਾਦ

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

ਵੱਖਰਾਪਣ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ਼ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੀ ਨਹੀਂ

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

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

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

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