ਕੀ ਦੋ ਸਾਈਟਾਂ ਨੂੰ ਸਾਈਟ VPN ਲਈ ਇੱਕੋ VLAN ID ਦੀ ਲੋੜ ਹੈ?
ਇੱਕੋ VLAN ID ਰਾਊਟਿਡ ਸਾਈਟ VPN ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ: ਟਨਲ IP ਪ੍ਰੀਫਿਕਸ ਢੋਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਹੁੰਚ ਐਡਰੈਸ ਪਲਾਨ ਅਤੇ ਸਿਲੈਕਟਰ ਤੈਅ ਕਰਦੇ ਹਨ, ਸਵਿੱਚ ਟੈਗ ਨਹੀਂ।
ਦੋ ਦਫ਼ਤਰਾਂ ਵਿੱਚ ਇੱਕੋ VLAN ਨੰਬਰ ਹੋਣ ਨਾਲ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਟਨਲ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ, ਅਤੇ ਇਹ ਟਨਲ ਜੋ ਢੋਂਦਾ ਹੈ ਉਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਇੱਕ VLAN ID ਇੱਕ ਇਮਾਰਤ ਦੇ ਅੰਦਰ Ethernet ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਨੂੰ ਨਿਸ਼ਾਨ ਲਗਾਉਂਦਾ ਹੈ; ਟਨਲ ਗੇਟਵੇ ਵਿਚਕਾਰ IP ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ. ਦੋ ਸਾਈਟਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ VLAN ਨੰਬਰਿੰਗ ਵਰਤ ਕੇ ਵੀ ਇੱਕ ਦੂਜੇ ਵੱਲ ਰਾਊਟ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਦੋ ਸਾਈਟਾਂ ਇੱਕੋ VLAN ਨੰਬਰਿੰਗ ਵਰਤ ਕੇ ਵੀ ਇੱਕ ਦੂਜੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦੀਆਂ। ਪਹੁੰਚ ਤੈਅ ਕਰਨ ਵਾਲਾ ਵੇਰੀਏਬਲ ਐਡਰੈਸ ਪਲਾਨ ਹੈ।
ਭਰਮ: ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਇੱਕੋ VLAN ID
ਇਹ ਵਿਸ਼ਵਾਸ ਵਾਜਬ ਥਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਇੱਕ ਇਮਾਰਤ ਦੇ ਅੰਦਰ, ਇੱਕੋ VLAN ਦੇ ਦੋ ਪੋਰਟ ਬੋਲ ਸਕਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ VLAN ਦੇ ਦੋ ਪੋਰਟ ਨਹੀਂ ਬੋਲ ਸਕਦੇ, ਇਸ ਲਈ VLAN ਨੰਬਰ ਕਨੈਕਟੀਵਿਟੀ ਦੇਣ ਵਾਲੀ ਚੀਜ਼ ਲੱਗਦਾ ਹੈ। ਰਾਊਟਿਡ ਟਨਲ ਦੇ ਪਾਰ ਟੈਗ ਦੱਸ ਸਕਣ ਵਾਲਾ ਕੋਈ ਸਾਂਝਾ Ethernet ਹਿੱਸਾ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਗੇਟਵੇ ਕਦੇ ਵੀ VLAN ਲੇਬਲ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੇ।
ਟਨਲ ਨੂੰ ਜਿਸ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ ਉਹ ਹੈ ਇੱਕ ਦੂਜੇ 'ਤੇ ਓਵਰਲੈਪ ਨਾ ਹੋਣ ਵਾਲੇ ਦੋ ਐਡਰੈਸ ਖੇਤਰ ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਨੀਤੀ। ਕਿਸੇ ਵੀ ਦਫ਼ਤਰ ਵਿੱਚ VLAN ਬਦਲੋ ਅਤੇ ਟਨਲ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਕਾਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਕਿਸੇ ਨੇ ਵੀ ਇਸਦਾ ਹਵਾਲਾ ਨਹੀਂ ਦਿੱਤਾ ਸੀ। ਇਹੀ ਵਿਵਾਦ ਨਿਪਟਾਉਣ ਵਾਲਾ ਟੈਸਟ ਹੈ: VLAN ਨੂੰ ਮੁੜ ਨੰਬਰ ਕਰੋ, ਐਡਰੈਸ ਅਛੂਤ ਰੱਖੋ ਅਤੇ ਦੇਖੋ ਟਨਲ ਟਿਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਉਲਟਾ ਟੈਸਟ ਵੀ ਉੱਨਾ ਹੀ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ। ਦੋਵੇਂ ਦਫ਼ਤਰਾਂ ਨੂੰ ਇੱਕੋ ਸਬਨੈੱਟ ਦਿਓ ਅਤੇ ਇੱਕੋ VLAN ਨੰਬਰ ਕਿੰਨੇ ਵੀ ਹੋਣ, ਉਹ ਐਡਰੈਸ ਨੂੰ ਅਸਪਸ਼ਟ ਰਹਿਣ ਨਹੀਂ ਦੇਣਗੇ।
ਟਨਲ ਅਸਲ ਵਿੱਚ ਕੀ ਢੋਂਦਾ ਹੈ
IPsec ਐਡਰੈਸ, ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ ਵਿੱਚ ਪ੍ਰਗਟ ਨੀਤੀ ਅਨੁਸਾਰ IP ਪੈਕਟ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। IPsec ਆਰਕੀਟੈਕਚਰ IP ਪਰਤ 'ਤੇ ਉਹਨਾਂ ਸਿਲੈਕਟਰਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜੋ ਸਵਿੱਚ ਟੈਗ ਦੱਸਦਾ ਹੈ ਉਸ ਤੋਂ ਕਈ ਪਰਤਾਂ ਉੱਪਰ ਹੈ। ਜਦੋਂ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ ਤਾਂ ਉਹ ਪਹਿਲਾਂ ਹੀ VLAN ਛੱਡ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ; ਟੈਗ ਸਥਾਨਕ ਸਵਿੱਚ ਨੇ ਵਰਤ ਲਿਆ ਹੁੰਦਾ ਹੈ।
ਨੀਤੀ-ਅਧਾਰਿਤ ਅਤੇ ਰੂਟ-ਅਧਾਰਿਤ ਡਿਜ਼ਾਈਨ ਟਨਲ ਚੁਣਨ ਦੇ ਢੰਗ ਵਿੱਚ ਵੱਖਰੇ ਹਨ, ਇਸ ਵਿੱਚ ਨਹੀਂ ਕਿ ਉਹ ਕੀ ਢੋ ਸਕਦੇ ਹਨ. ਨੀਤੀ-ਅਧਾਰਿਤ ਪੀਅਰ ਟ੍ਰੈਫਿਕ ਸਿਲੈਕਟਰ ਮਿਲਾਉਂਦਾ ਹੈ ਅਤੇ ਮਿਲਦੇ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਰੂਟ-ਅਧਾਰਿਤ ਪੀਅਰ ਟਨਲ ਇੰਟਰਫੇਸ 'ਤੇ ਟ੍ਰੈਫਿਕ ਰਾਊਟ ਕਰਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਰਾਊਟਿੰਗ ਟੇਬਲ 'ਤੇ ਛੱਡਦਾ ਹੈ। ਦੋਵੇਂ ਅਜੇ ਵੀ ਸੁਰੱਖਿਆ ਖੇਤਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਟਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਰੂਟ ਪੀਅਰਾਂ ਵੱਲੋਂ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਸਹਿਮਤ ਹੋਏ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦਾ।
ਇਹ ਫ਼ਰਕ ਆਮ ਅੱਧੀ-ਅਸਫ਼ਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ: ਰੂਟ ਮੌਜੂਦ ਹੈ, ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਉਹਨਾਂ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਗੱਲਬਾਤ ਵਾਲੇ ਸਿਲੈਕਟਰਾਂ ਵਿੱਚ ਉਹ ਪ੍ਰੀਫਿਕਸ ਕਦੇ ਨਹੀਂ ਸੀ। ਸਥਾਪਿਤ ਨੀਤੀਆਂ ਪੜ੍ਹਨ ਨਾਲ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਖੇਤਰ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਹੋਇਆ।
ip xfrm policy
ip route show
swanctl --list-sasਅਸਲ ਵਿੱਚ ਤੋੜਨ ਵਾਲਾ ਓਵਰਲੈਪ
ਵੱਖਰੇ ਸਬਨੈੱਟ ਵਾਲੇ ਦੋ ਦਫ਼ਤਰ ਟਨਲ ਰਾਹੀਂ ਸਾਫ਼ ਰਾਊਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ VLAN ਨੰਬਰ ਅਪ੍ਰਸੰਗਿਕ ਹਨ। ਇੱਕੋ ਸਬਨੈੱਟ ਵਾਲੇ ਦੋ ਦਫ਼ਤਰ ਨਹੀਂ, ਕਿਉਂਕਿ ਦਿੱਤੇ ਐਡਰੈਸ ਦੀ ਬੇਨਤੀ ਦੇ ਦੋ ਸੰਭਵ ਅਰਥ ਹੁੰਦੇ ਹਨ ਅਤੇ ਰਾਊਟਿੰਗ ਟੇਬਲ ਸਿਰਫ਼ ਇੱਕ ਚੁਣ ਸਕਦੀ ਹੈ। ਇੱਕ ਸਾਈਟ ਨੂੰ ਮੁੜ ਨੰਬਰ ਕਰਨਾ ਸਾਫ਼ ਹੱਲ ਹੈ, ਅਤੇ DNS ਤੇ ਫਾਇਰਵਾਲ ਬਦਲਾਅ ਗਿਣਨ ਤੋਂ ਬਾਅਦ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਬਦਲਾਂ ਨਾਲੋਂ ਸਸਤਾ ਪੈਂਦਾ ਹੈ।
| Office | Local VLAN | Subnet | Result |
|---|---|---|---|
| A | 40 | 10.31.0.0/24 | Routes normally |
| B | 55 | 10.62.0.0/24 | Routes normally |
| B after renumber | 40 | 10.31.0.0/24 | Ambiguous, tunnel cannot help |
ਜਦੋਂ ਮੁੜ ਨੰਬਰ ਕਰਨਾ ਅਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਜਾਣਬੁੱਝ ਕੇ ਕੀਤਾ ਅਨੁਵਾਦ ਡਿਜ਼ਾਈਨ ਹਰ ਪਾਸੇ ਨੂੰ ਵੱਖਰੇ ਐਡਰੈਸ ਦ੍ਰਿਸ਼ ਪੇਸ਼ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਦਾ ਅਰਥ ਹੈ ਇੱਕ-ਤੋਂ-ਇੱਕ ਮੈਪਿੰਗ, ਮਿਲਦੇ ਸਿਲੈਕਟਰ, ਅਨੁਵਾਦਿਤ ਦ੍ਰਿਸ਼ ਨੂੰ ਦਰਸਾਉਣ ਵਾਲੀਆਂ DNS ਐਂਟਰੀਆਂ ਅਤੇ ਮੁੜ-ਲਿਖਤ ਨੂੰ ਝੱਲਣ ਵਾਲੀ ਵਾਪਸੀ ਰਾਊਟਿੰਗ। ਇਹ ਅਸਲ ਕਾਰਜਸ਼ੀਲ ਖ਼ਰਚ ਵਾਲਾ ਸਮਰਥਿਤ ਡਿਜ਼ਾਈਨ ਹੈ, ਅਤੇ VLAN ID ਬਦਲਣ ਨਾਲ ਜੋ ਹੁੰਦਾ ਹੈ ਉਹ ਇਹ ਨਹੀਂ।
ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਇੱਕੋ VLAN ਨੰਬਰ ਕਦੇ-ਕਦੇ ਸਾਂਝੇ ਟੈਂਪਲੇਟ ਦਾ ਸੰਯੋਗ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਸ ਸੰਯੋਗ ਨੂੰ ਕੰਮ ਕਰਦੇ ਟਨਲ ਦਾ ਕਾਰਨ ਮੰਨਣ ਨਾਲ ਬਾਅਦ ਵਿੱਚ ਕੁਝ ਟੁੱਟਣ 'ਤੇ ਗਲਤ ਬਦਲਾਅ ਹੁੰਦਾ ਹੈ।
ਹਰ ਪਰਤ ਲਈ ਇੱਕ ਕੰਮ, ਲਿਖਤੀ ਰੂਪ ਵਿੱਚ
ਸਥਾਨਕ ਸਵਿੱਚ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਪੋਰਟ ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਸਦੀ VLAN ਨੰਬਰਿੰਗ ਸਥਾਨਕ ਹਿਸਾਬ ਹੈ ਜੋ ਕਿਸੇ ਹੋਰ ਸਾਈਟ ਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਗੇਟਵੇ ਪੀਅਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚਦਾ ਹੈ ਅਤੇ ਗੱਲਬਾਤ ਵਾਲਾ ਸੁਰੱਖਿਆ ਖੇਤਰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਰਾਊਟਿੰਗ ਟੇਬਲ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਡਿਕ੍ਰਿਪਟ ਕੀਤਾ ਪੈਕਟ ਅੱਗੇ ਕਿੱਥੇ ਜਾਵੇਗਾ, ਅਤੇ ਐਕਸੈਸ ਨੀਤੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਉਸ ਪੈਕਟ ਨੂੰ ਬਿਲਕੁਲ ਆਗਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ ਜਾਂ ਨਹੀਂ।
ਇਹ ਕੰਮ ਵੱਖਰੇ ਰੱਖਣਾ ਹੀ ਬਦਲਾਅ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਦਫ਼ਤਰ ਵਿੱਚ VLAN ਮੁੜ ਨੰਬਰਿੰਗ ਸਥਾਨਕ ਸਵਿੱਚ, DHCP ਖੇਤਰ ਅਤੇ ਸੰਭਵ ਤੌਰ 'ਤੇ ਫਾਇਰਵਾਲ ਜ਼ੋਨ ਨੂੰ ਛੂਹਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਨੂੰ ਨਹੀਂ ਛੂਹਦੀ। ਪ੍ਰੀਫਿਕਸ ਬਦਲਾਅ ਟਨਲ ਸਿਲੈਕਟਰ, ਦੋਵੇਂ ਪਾਸਿਆਂ ਦੇ ਰੂਟ ਅਤੇ ਐਕਸੈਸ ਨੀਤੀ ਨੂੰ ਛੂਹਦਾ ਹੈ, ਅਤੇ ਸਵਿੱਚ ਟੈਗ ਨੂੰ ਨਹੀਂ ਛੂਹਦਾ।
ਵਾਪਸੀ ਰੂਟ, ਨਿੱਜੀ DNS ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਪਛਾਣ ਦੀਆਂ ਲੋੜਾਂ ਫਿਰ ਵੱਖਰੇ ਕੰਮ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਦੂਜੀ ਸਾਈਟ ਤੋਂ VLAN ਨੰਬਰ ਕਾਪੀ ਕਰਕੇ ਨਹੀਂ ਆਉਂਦਾ। ਜੋ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਪਹੁੰਚਯੋਗ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਮਨਜ਼ੂਰ ਸੇਵਾਵਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਉਹ ਸਵਿੱਚ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਵੀ ਟਿਕਦਾ ਹੈ; ਜੋ VLAN ਨੰਬਰਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਉਹ ਨਹੀਂ।
ਇਹ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਟੈਗ ਟਨਲ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਬ੍ਰਿਜ ਸਾਧਨਾਂ ਨਾਲ ਸਥਾਨਕ ਤਸਵੀਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।
bridge vlan show
ip -br addr
ip route get 10.62.0.20ਜਦੋਂ layer-2 ਵਿਸਤਾਰ ਹੀ ਅਸਲ ਲੋੜ ਹੋਵੇ
ਕੁਝ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਸੱਚਮੁੱਚ Ethernet ਵਿਵਹਾਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਪ੍ਰਸਾਰਣ ਖੋਜ 'ਤੇ ਨਿਰਭਰ ਪੁਰਾਣੀ ਐਪਲੀਕੇਸ਼ਨ, ਮਸ਼ੀਨ ਖਿਸਕਣ ਵੇਲੇ ਐਡਰੈਸ ਬਚਾਉਣਾ ਪੈਣ ਵਾਲਾ ਸਥਾਨਾਂਤਰਣ, ਜਾਂ layer-2 ਧਾਰਨਾਵਾਂ ਸਮੇਟਣ ਵਾਲਾ ਪ੍ਰੋਟੋਕੋਲ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਲਈ ਫਰੇਮ ਢੋਣ ਵਾਲਾ ਓਵਰਲੇ ਜਾਂ ਬ੍ਰਿਜਡ ਸੇਵਾ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਫਿਰ VLAN ਮੈਂਬਰਸ਼ਿਪ, ਲੂਪ ਰੋਕਥਾਮ ਅਤੇ ਅਸਫ਼ਲਤਾ ਸੰਭਾਲ ਸਿਰੇ-ਤੋਂ-ਸਿਰੇ ਦੇ ਮਾਮਲੇ ਬਣ ਜਾਂਦੇ ਹਨ।
ਇਹ ਬਹੁਤ ਵੱਡਾ ਅਸਫ਼ਲਤਾ ਖੇਤਰ ਹੈ, ਅਤੇ ਇਹ ਫਾਇਲ ਸਾਂਝ ਨੂੰ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਆਕਸਮਿਕ ਨਤੀਜਾ ਨਹੀਂ, ਸੁਚੇਤ ਚੋਣ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਆਮ ਫਾਇਲ ਸਰਵਰ, ਡੇਟਾਬੇਸ ਜਾਂ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਧਿਕ੍ਰਿਤ IP ਮਾਰਗ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਹੇਠਾਂ ਖਿੱਚਿਆ ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਨਾ ਹੋਣ 'ਤੇ ਉਹ ਵਧੇਰੇ ਖੁਸ਼ ਰਹੇਗਾ।
VPN ਸਮਝੌਤੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਮਨਜ਼ੂਰ ਸੇਵਾਵਾਂ ਵਜੋਂ ਲਿਖੋ, ਅਤੇ VLAN ਲੇਬਲ ਸਿਰਫ਼ ਉੱਥੇ ਦਰਜ ਕਰੋ ਜਿੱਥੇ ਸਥਾਨਕ ਕਾਰਜਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੋਵੇ। ਫਿਰ ਹਰ ਦਫ਼ਤਰ ਹਰ ਬਦਲਾਅ ਨੂੰ ਟਨਲ ਦੇ ਮੁੜ-ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਿਨਾਂ ਆਪਣੀ ਸਵਿੱਚਿੰਗ ਮੁੜ ਨੰਬਰ ਕਰ ਸਕਦਾ ਹੈ।