SaaS ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਹੀ ਗਾਹਕ VPN ਵੱਲ ਕਿਵੇਂ ਰੂਟ ਕਰੀਏ
ਓਵਰਲੈਪ ਹੁੰਦੇ ਗਾਹਕ ਸਬਨੈੱਟ ਸਾਂਝੀ ਰੂਟਿੰਗ ਤੋੜਦੇ ਹਨ। ਇੱਕ ਆਈਸੋਲੇਸ਼ਨ ਮਾਡਲ ਚੁਣੋ, ਹਰ ਕੰਮ ਨੂੰ ਤਸਦੀਕਸ਼ੁਦਾ ਕਿਰਾਏਦਾਰ ਨਾਲ ਬੰਨ੍ਹੋ, ਅਤੇ ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਾਸ-ਕਿਰਾਏਦਾਰ ਰਾਹਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
ਇੱਕ SaaS ਪਲੇਟਫਾਰਮ ਦਰਜਨ ਗਾਹਕ ਨੈੱਟਵਰਕਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਗਾਹਕਾਂ ਵਿੱਚੋਂ ਦੋ ਆਪਣੇ ਪ੍ਰਾਇਮਰੀ ਡੇਟਾਬੇਸ ਲਈ 10.20.0.10 ਵਰਤਦੇ ਹਨ। ਕੰਮ ਵਿੱਚ ਉਹ ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਵਰਕਰ ਕੋਲ ਇਹ ਜਾਣਨ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਕਿ ਕੰਮ ਕਿਹੜੇ ਡੇਟਾਬੇਸ ਨੂੰ ਮਤਲਬ ਹੈ, ਅਤੇ ਸਾਂਝੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਉਸ ਨੂੰ ਖੁਸ਼ੀ ਨਾਲ ਉਸ ਸੁਰੰਗ ਵੱਲ ਭੇਜੇਗੀ ਜਿਸ ਵੱਲ ਪ੍ਰੀਫਿਕਸ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਹੱਲ ਹੋਰ ਸੁਰੰਗਾਂ ਨਹੀਂ ਹਨ; ਹੱਲ ਇਹ ਤੈਅ ਕਰਨਾ ਹੈ ਕਿ ਕਿਰਾਏਦਾਰ ਪਛਾਣ ਰਾਹ ਵਿੱਚ ਕਿੱਥੇ ਦਾਖਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪਤਾ ਯੋਜਨਾ ਨੂੰ ਕਿਹੜਾ ਆਈਸੋਲੇਸ਼ਨ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਚੋਣ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਗਾਹਕ ਪ੍ਰੀਫਿਕਸ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਇੱਕ ਗਲਤੀ ਕਿੰਨੀ ਦੂਰ ਫੈਲ ਸਕਦੀ ਹੈ, ਅਤੇ ਕਨੈਕਟਰ ਕੌਣ ਚਲਾਉਂਦਾ ਹੈ।
ਦੋ ਗਾਹਕ ਡੇਟਾਬੇਸ, ਇੱਕ ਮੰਜ਼ਿਲ ਪਤਾ
IP ਪਤਾ ਇੱਕ ਟਿਕਾਣਾ ਹੈ, ਪਛਾਣ ਨਹੀਂ। ਬੇਨਤੀ ਨੂੰ ਸਰਵਰ ਵੱਲੋਂ ਤਸਦੀਕਸ਼ੁਦਾ ਕਿਰਾਏਦਾਰ ਲੈ ਕੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮੰਜ਼ਿਲ ਹੱਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਕਿਰਾਏਦਾਰ ਨੂੰ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ।
ਜਦੋਂ ਅਜਿਹਾ ਨਹੀਂ ਹੁੰਦਾ, ਨਾਕਾਮੀ ਚੁੱਪ ਹੁੰਦੀ ਹੈ। ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਕਵੈਰੀ ਚੱਲਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਗਲਤ ਗਾਹਕ ਦੇ ਡੇਟਾਬੇਸ ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ 10.20.0.10 ਲਈ ਇੱਕੋ ਐਂਟਰੀ ਸੀ। DNS ਇਸ ਨੂੰ ਹੋਰ ਵਿਗਾੜਦਾ ਹੈ: ਕਿਰਾਏਦਾਰ A ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੱਲ ਹੋਇਆ ਕੈਸ਼ ਕੀਤਾ ਨਾਮ ਕਿਰਾਏਦਾਰ B ਲਈ ਚੱਲ ਰਹੇ ਕੰਮ ਦੁਆਰਾ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪੈਕਟ ਵਿੱਚ ਕੁਝ ਵੀ ਦੋਵਾਂ ਵਿੱਚ ਫ਼ਰਕ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਤਰਕ ਇਸ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।
ਪਹਿਲਾਂ ਆਈਸੋਲੇਸ਼ਨ ਮਾਡਲ ਤੈਅ ਕਰੋ
ਉਤਪਾਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਸ਼ਰਤਾਂ ਲਿਖੋ। ਓਵਰਲੈਪ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਪਤਾ ਥਾਂ ਬਿਲਕੁਲ ਸਾਂਝਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਪ੍ਰਭਾਵ ਦਾ ਘੇਰਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਰੂਟਿੰਗ ਗਲਤੀ ਸਹਾਇਤਾ ਟਿਕਟ ਹੈ ਜਾਂ ਉਲੰਘਣਾ; ਕਾਰਜਸ਼ੀਲ ਮਾਲਕੀਅਤ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਕਿਰਾਏਦਾਰ ਲਈ ਕਨੈਕਟਰ ਬੇੜਾ ਚਲਾ ਸਕਦੇ ਹੋ ਜਾਂ ਨਹੀਂ।
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
ਜੇ ਪ੍ਰੀਫਿਕਸ ਵੱਖਰੇ ਹਨ ਅਤੇ ਨੀਤੀ ਨਿਯੰਤਰਿਤ ਹੱਬ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਹਰ ਕਿਰਾਏਦਾਰ ਲਈ ਰੂਟਿੰਗ ਸਾਰਣੀਆਂ ਵਾਲਾ ਇੱਕ Transit Gateway ਸੰਭਵ ਹੈ। ਅਟੈਚਮੈਂਟ ਐਸੋਸੀਏਸ਼ਨ ਉਸ ਅਟੈਚਮੈਂਟ ਤੋਂ ਆਉਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਲਈ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਸਾਰ ਚੁਣਦਾ ਹੈ ਕਿ ਸਾਰਣੀ ਵਿੱਚ ਕਿਹੜੇ ਰਾਹ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਸਿਰਫ਼ ਆਪਣੀ ਸਾਰਣੀ ਨਾਲ ਜੁੜਿਆ ਅਤੇ ਸਿਰਫ਼ ਆਪਣੇ ਪ੍ਰੀਫਿਕਸ ਦਾ ਪ੍ਰਸਾਰ ਕਰਨ ਵਾਲਾ ਕਿਰਾਏਦਾਰ ਅਟੈਚਮੈਂਟ ਹੱਬ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ। ਇਹ ਰੂਟਿੰਗ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਸਹੀ ਰਹਿੰਦਾ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਸਾਂਝੀ ਸਾਰਣੀ ਵਿੱਚ ਡਿਫਾਲਟ ਰਾਹ ਨਹੀਂ ਜੋੜਦਾ।
ਜੇ ਪ੍ਰੀਫਿਕਸ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ, ਸਿਰਫ਼ ਰੂਟਿੰਗ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਤੁਹਾਨੂੰ ਹਰ ਕਿਰਾਏਦਾਰ ਲਈ ਵੱਖਰਾ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਜਾਂ ਹਰ ਗਾਹਕ ਦੀ ਥਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਰਥ ਦੇਣ ਵਾਲੀ ਅਨੁਵਾਦ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ।
Transit Gateway ਆਈਸੋਲੇਸ਼ਨ ਦਾ ਅਸਲ ਅਰਥ ਕੀ ਹੈ
ਐਸੋਸੀਏਸ਼ਨ ਅਤੇ ਪ੍ਰਸਾਰ ਦੋ ਮੁੱਖ ਨਿਯੰਤਰਣ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਉਲਝਾਉਣਾ ਸੌਖਾ ਹੈ। ਐਸੋਸੀਏਸ਼ਨ ਦੱਸਦੀ ਹੈ ਕਿ ਇਸ ਅਟੈਚਮੈਂਟ ਦਾ ਪੈਕਟ ਕਿਹੜੀ ਸਾਰਣੀ ਵਿੱਚ ਖੋਜਿਆ ਜਾਂਦਾ ਹੈ; ਪ੍ਰਸਾਰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਸਾਰਣੀਆਂ ਇਸ ਅਟੈਚਮੈਂਟ ਦੇ ਰਾਹ ਸਿੱਖਦੀਆਂ ਹਨ। ਆਈਸੋਲੇਸ਼ਨ ਦੋਵਾਂ ਨੂੰ ਕਿਰਾਏਦਾਰ-ਖਾਸ ਬਣਾਉਣ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਹੋਰ ਅਟੈਚਮੈਂਟ ਬਣਾਉਣ ਤੋਂ ਨਹੀਂ।
ਡਿਫਾਲਟ ਸਭ-ਤੋਂ-ਸਭ ਸੈਟਅਪ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਇਹ ਆਈਸੋਲੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਵੱਖਰੀਆਂ ਰੂਟਿੰਗ ਸਾਰਣੀਆਂ ਕਨੈਕਟੀਵਿਟੀ ਸੀਮਤ ਕਰਦੀਆਂ ਹਨ, ਪਰ ਇੱਕੋ ਰੂਟਿੰਗ ਸੰਦਰਭ ਵਿੱਚ ਇੱਕ ਅਟੁੱਟ ਮੰਜ਼ਿਲ ਪਤੇ ਨੂੰ ਦੋ ਅਰਥ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਕਿਰਾਏਦਾਰ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ 10.20.0.10 ਹੱਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਰੂਟਿੰਗ ਪਰਤ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਪਹਿਲਾਂ ਹੀ ਗੁਆ ਚੁੱਕੀ ਹੈ।
AWS ਨੇ 23 ਅਕਤੂਬਰ 2026 ਨੂੰ Transit Gateway ਅਤੇ Cloud WAN ਲਈ ਅਟੈਚਮੈਂਟ-ਪੱਧਰੀ 1:1 NAT ਸ਼ਾਮਲ ਕੀਤਾ, ਜੋ ਸਮਰਥਿਤ ਅਟੈਚਮੈਂਟਾਂ ਲਈ ਓਵਰਲੈਪ ਦਾ ਜਵਾਬ ਬਦਲਦਾ ਹੈ। Transit Gateway NAT ਦਸਤਾਵੇਜ਼ ਹੋਸਟ ਬਿੱਟ ਸੁਰੱਖਿਅਤ ਰੱਖਦਿਆਂ ਸਥਿਰ, ਅਵਸਥਾਹੀਣ, ਸਮਾਨ-ਪ੍ਰੀਫਿਕਸ IPv4 ਮੈਪਿੰਗਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇਸ ਦੁਆਲੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮਰਥਿਤ ਅਟੈਚਮੈਂਟ ਕਿਸਮਾਂ ਅਤੇ ਖੇਤਰੀ ਸੀਮਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।
ਕੰਮ ਨੂੰ ਤਸਦੀਕਸ਼ੁਦਾ ਕਿਰਾਏਦਾਰ ਨਾਲ ਬੰਨ੍ਹੋ
ਹਰ ਕੰਮ ਨੂੰ ਸਰਵਰ-ਤਸਦੀਕਸ਼ੁਦਾ ਕਿਰਾਏਦਾਰ ਪਛਾਣ ਲੈ ਕੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਉਸ ਪਛਾਣ ਨੂੰ ਪ੍ਰਸ਼ਾਸਕ ਦੀ ਮਾਲਕੀਅਤ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਰਿਕਾਰਡ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਰਿਕਾਰਡ ਮਨਜ਼ੂਰ ਨੈੱਟਵਰਕ ਸੰਦਰਭ, ਸੇਵਾ ਪਤਾ, ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਹਵਾਲਾ ਅਤੇ ਉੱਥੇ ਮਨਜ਼ੂਰ ਕਾਰਵਾਈਆਂ ਦੇ ਨਾਮ ਦੱਸਦਾ ਹੈ। ਅਵਿਸ਼ਵਾਸਯੋਗ ਬੇਨਤੀ ਨੂੰ ਕਦੇ ਵੀ ਆਪਣਾ VPN ਪਛਾਣਕਰਤਾ, ਗੇਟਵੇ ਜਾਂ ਨਿੱਜੀ ਟਾਰਗੇਟ ਨਹੀਂ ਦੇਣਾ ਚਾਹੀਦਾ, ਕਿਉਂਕਿ ਵੈਧ ਲੌਗਇਨ ਹਰ ਜੁੜੇ ਗਾਹਕ ਦੀ ਪਤਾ ਥਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਆਗਿਆ ਨਹੀਂ ਹੈ।
ਅਲੱਗ ਕਨੈਕਟਰਾਂ ਦੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ, ਕਿਰਾਏਦਾਰ A ਦਾ ਕੰਮ A-ਖਾਸ ਕਨੈਕਟਰ ਵੱਲ ਜਾਂਦਾ ਹੈ ਜੋ A ਦੇ VPC ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ A ਦੇ ਮਨਜ਼ੂਰ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇੱਕੋ ਹੋਸਟ ਉੱਤੇ ਅਲੱਗ ਕੰਟੇਨਰ ਉਹ ਵਿਛੋੜਾ ਆਪਣੇ ਆਪ ਨਹੀਂ ਬਣਾਉਂਦੇ; ਨੈੱਟਵਰਕ ਨਾਮਸਥਾਨ, ਰਾਹ ਅਤੇ ਨਿਰਗਮਨ ਨੀਤੀ ਨੂੰ ਇਹ ਲਾਗੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਕਨੈਕਟਰ ਨੂੰ ਕਿਰਾਏਦਾਰ-ਸੀਮਤ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਅਤੇ ਕਤਾਰਾਂ ਵੀ ਚਾਹੀਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਨਿੱਜੀ ਰਾਹ ਸਾਂਝੇ ਭੇਤ ਜਾਂ ਸਾਂਝੀ ਕੰਮ ਵਸਤੂ ਨੂੰ ਸੀਮਤ ਨਹੀਂ ਕਰਦਾ। ਸਾਂਝੇ ਐਪਲੀਕੇਸ਼ਨ ਵਰਕਰ ਠੀਕ ਹਨ ਜੇ ਨੈੱਟਵਰਕ ਸੰਦਰਭ ਅਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਹੋਸਟ ਦੀ ਥਾਂ ਕਿਰਾਏਦਾਰ ਅਨੁਸਾਰ ਚੁਣੇ ਜਾਂਦੇ ਹਨ।
ਸਿਹਤ ਜਾਂਚਾਂ ਨੂੰ ਕਿਰਾਏਦਾਰ ਅਤੇ ਪੜਾਅ ਦਾ ਨਾਮ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ: ਸੁਰੰਗ ਸਥਾਪਿਤ, ਰਾਹ ਮੌਜੂਦ ਅਤੇ ਅਸਲ ਸੇਵਾ ਬੇਨਤੀ ਸਫਲ ਤਿੰਨ ਵੱਖਰੇ ਸੰਕੇਤ ਹਨ। ਚੱਲ ਰਹੀਆਂ ਸੁਰੰਗਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ ਉਸ ਇੱਕ ਗਾਹਕ ਨੂੰ ਲੁਕਾ ਦੇਵੇਗੀ ਜਿਸਦਾ ਕਨੈਕਟਰ ਟੁੱਟਿਆ ਹੈ।
ਉਹ ਰਾਹ ਜਾਂਚੋ ਜੋ ਨਾਕਾਮ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ
ਲਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਟੈਸਟ ਚਲਾਓ। ਮਨਜ਼ੂਰ A ਕਾਰਵਾਈ ਸਫਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਮਨਜ਼ੂਰ B ਕਾਰਵਾਈ ਸਫਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਜਾਣਬੁੱਝ ਕੇ B ਦੇ ਕਨੈਕਟਰ ਜਾਂ ਇਸਦੇ ਅਨੁਵਾਦਿਤ ਉਪਨਾਮ ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ A ਕੰਮ ਬੰਦ ਰੂਪ ਵਿੱਚ ਨਾਕਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਇੱਕ ਸੁਰੰਗ ਤੋੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੰਮ ਸਿਰਫ਼ ਉਸ ਕਿਰਾਏਦਾਰ ਲਈ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ, ਕਿਸੇ ਹੋਰ ਗਾਹਕ ਦੇ ਉਸੇ-ਨੰਬਰ ਵਾਲੇ ਸਬਨੈੱਟ ਉੱਤੇ ਵਾਪਸ ਨਹੀਂ ਡਿੱਗਦਾ। ਬਹਾਲੀ ਦੀ ਵੀ ਜਾਂਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਪੁਰਾਣਾ ਰਾਹ ਜਾਂ ਕੈਸ਼ ਕੀਤਾ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਰੁਕਾਵਟ ਤੋਂ ਵੱਧ ਚੱਲ ਸਕਦਾ ਹੈ।
ਆਰਕੀਟੈਕਚਰ ਅਲੱਗ ਕਨੈਕਟਰਾਂ ਵਾਲੇ ਸਾਂਝੇ ਵਰਕਰ ਜਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਕਿਰਾਏਦਾਰ ਸਰੋਤ ਹੋ ਸਕਦਾ ਹੈ। ਅਟੱਲ ਗੱਲ ਇੱਕੋ ਹੈ: ਤਸਦੀਕਸ਼ੁਦਾ ਕਿਰਾਏਦਾਰ ਸੰਦਰਭ ਰਾਹ ਅਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਰਾਹ ਤਬਦੀਲੀ ਕਦੇ ਵੀ ਕਿਰਾਏਦਾਰਾਂ ਵਿਚਕਾਰ ਐਪਲੀਕੇਸ਼ਨ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੀ।