ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਬਿਨਾਂ NAT ਪਿੱਛੇ ਵਰਕਸਟੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚੋ
ਇਨਬਾਊਂਡ ਪੋਰਟ ਨਾ ਹੋਣ ਵਾਲਾ ਵਰਕਸਟੇਸ਼ਨ ਵੀ ਹੱਬ, ਰਿਲੇ ਜਾਂ ਐਪ ਬ੍ਰੋਕਰ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਲਨਾ ਕਰੋ ਕਿ ਹਰ ਡਿਜ਼ਾਈਨ ਕੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ।
ਕੈਰੀਅਰ NAT ਅਤੇ ਲਾਕ ਕੀਤੇ ਦਫ਼ਤਰੀ ਰਾਊਟਰ ਪਿੱਛੇ ਦੋ ਐਂਡਪੁਆਇੰਟ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਕੋਈ ਇਨਬਾਊਂਡ ਪੋਰਟ ਨਹੀਂ ਛੱਡਦੇ, ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਫਿਰ ਵੀ ਇੱਕ ਮੰਗਣਾ ਹੁੰਦਾ ਹੈ। ਵਧੀਆ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਪਾਸਾ ਬਾਹਰ ਡਾਇਲ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀ ਪਹੁੰਚਯੋਗ ਸੇਵਾ ਨੂੰ ਟ੍ਰੈਫਿਕ ਢੋਣ ਦੀ ਆਗਿਆ ਹੈ। ਚਾਰ ਡਿਜ਼ਾਈਨ ਇਸ ਸਵਾਲ ਦਾ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਰਾਹ ਰੁਕਣ ਤੇ ਉਹ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ। ਉਨ੍ਹਾਂ ਵਿਚਕਾਰ ਚੋਣ ਪ੍ਰੋਟੋਕੋਲ ਨਾਵਾਂ ਦੀ ਨਹੀਂ, ਗਾਰੰਟੀਆਂ ਦੀ ਤੁਲਨਾ ਹੈ।
ਚਾਰ ਡਿਜ਼ਾਈਨ, ਚਾਰ ਵੱਖਰੇ ਵਾਅਦੇ
ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਛੋਟਾ ਸੰਸਕਰਣ ਹੈ। ਵਿਚਕਾਰਲੀ ਕਾਲਮ ਨੂੰ ਉਸ ਵਾਅਦੇ ਵਜੋਂ ਪੜ੍ਹੋ ਜਿਸ ਦੀ ਤੁਸੀਂ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਸੱਜੀ ਕਾਲਮ ਨੂੰ ਉਸ ਵਾਅਦੇ ਵਜੋਂ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਦਿੱਤਾ।
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
ਕਿਹੜੀ ਕਤਾਰ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਇਹ ਪਸੰਦ ਤੇ ਨਹੀਂ, ਕੰਮ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਰਿਮੋਟ ਡੈਸਕਟਾਪ ਸੈਸ਼ਨ, ਇੱਕ ਪ੍ਰਬੰਧਕੀ ਸ਼ੈੱਲ ਅਤੇ ਪੂਰੇ ਪ੍ਰਾਈਵੇਟ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚ — ਇਹ ਤਿੰਨ ਲੋੜਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਦੀ ਲੋੜ ਨਹੀਂ, ਭਾਵੇਂ ਉਹ ਸੰਜੋਗ ਨਾਲ ਇੱਕੋ ਮਸ਼ੀਨ ਨਾਲ ਸੰਬੰਧਿਤ ਹੋਣ।
ਹੱਬ ਬਦਲਦਾ ਹੈ ਕਿ ਕੌਣ ਬਾਹਰ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕੀ ਆਗਿਆ ਹੈ
ਰਾਊਟ ਕੀਤੇ ਹੱਬ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਦੂਰ ਦਾ ਲੈਪਟਾਪ ਅਤੇ ਵਰਕਸਟੇਸ਼ਨ, ਜਾਂ ਉਸ ਦੇ ਸਾਹਮਣੇ ਦਾ ਸਾਈਟ ਗੇਟਵੇ, ਹਰ ਇੱਕ ਅਜਿਹੀ ਸੇਵਾ ਵੱਲ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਸੁਰੰਗ ਖੋਲ੍ਹਦਾ ਹੈ ਜਿੱਥੇ ਦੋਵੇਂ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਵਰਕਸਟੇਸ਼ਨ ਦੇ ਰਾਊਟਰ ਤੇ ਕੁਝ ਵੀ ਬਿਨਾਂ ਮੰਗੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸੇ ਕਾਰਨ ਇਹ ਡਿਜ਼ਾਈਨ NAT ਵਿੱਚ ਟਿਕਦਾ ਹੈ ਅਤੇ ਸਾਈਟ ਕੋਲ ਸਥਿਰ ਪਤਾ ਨਾ ਹੋਣ ਤੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਫਿਰ ਹੱਬ ਆਪਣੀ ਨੀਤੀ ਅਨੁਸਾਰ ਦੋ ਅੰਦਰੂਨੀ ਪਤਿਆਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਰਾਊਟ ਕਰਦਾ ਹੈ।
ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਹੱਬ ਦਾ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਦੋਵਾਂ ਪਾਸਿਆਂ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਨੇ ਇਸਨੂੰ ਚਲਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਫਿਲਟਰਿੰਗ ਨੇ ਟ੍ਰਾਂਸਪੋਰਟ ਦੀ ਆਗਿਆ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਰੋਕਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਦੀ ਲੋੜ ਨਾ ਹੋਣ ਤੇ ਵੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਹਰਾ ਦੇਵੇਗਾ।
ਸੂਖਮ ਹਿੱਸਾ ਇਹ ਹੈ ਕਿ ਪਹੁੰਚ ਅਤੇ ਅਧਿਕਾਰ ਵੱਖਰੇ ਥਾਵਾਂ ਤੇ ਲਏ ਜਾਂਦੇ ਵੱਖਰੇ ਫੈਸਲੇ ਹਨ। ਪ੍ਰੀਫਿਕਸ ਵੱਲ ਜਾਣ ਵਾਲਾ ਰਾਹ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਵਰਕਸਟੇਸ਼ਨ ਤੇ ਕਿਹੜੀ ਸੇਵਾ ਪਛਾਣ ਵਰਤ ਸਕਦੀ ਹੈ, ਅਤੇ ਸੁਰੰਗ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਖਾਤਾ ਲੌਗਇਨ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਦੋਵੇਂ ਸੰਰਚਿਤ ਕਰੋ, ਦੋਵੇਂ ਜਾਂਚੋ, ਅਤੇ ਅਧਿਕਾਰ ਦਾ ਫੈਸਲਾ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਕੋਲ ਨਹੀਂ, ਸਰੋਤ ਦਾ ਮਾਲਕ ਸਿਸਟਮ ਕੋਲ ਰੱਖੋ।
ਟ੍ਰੈਵਰਸਲ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਸਟੈਕ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹਨ
ਸਮਕੱਖ ਟੋਇਆਂ ਵਿਚਕਾਰ ਟ੍ਰੈਵਰਸਲ ਖਾਸ ਸਿਸਟਮ ਦੀ ਸਮਰੱਥਾ ਹੈ, VPN ਸੁਧਾਰਨ ਵਾਲੀ ਸੈਟਿੰਗ ਨਹੀਂ। Interactive Connectivity Establishment ਕਈ ਉਮੀਦਵਾਰ ਪਤੇ ਇਕੱਠੇ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕੰਮ ਕਰਨ ਤੱਕ ਜੋੜਿਆਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ: ਸਥਾਨਕ ਇੰਟਰਫੇਸ ਤੇ ਹੋਸਟ ਉਮੀਦਵਾਰ, NAT ਜੋ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ ਉਸ ਤੋਂ ਬਣੇ ਸਰਵਰ-ਪ੍ਰਤੀਬਿੰਬ ਉਮੀਦਵਾਰ, ਅਤੇ ਰਿਲੇ ਤੇ ਅਲਾਟ ਕੀਤੇ ਰਿਲੇ ਉਮੀਦਵਾਰ। ਸਿਰਫ਼ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਰਾਹ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਦੂਜਾ ਪਾਸਾ ਉੱਥੇ ਰਾਊਟ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਰਿਲੇ ਵਾਲੇ ਕੇਸ ਨੂੰ ਰੱਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਮਝਣਾ ਲਾਹੇਵੰਦ ਹੈ। RFC 8656 TURN ਨੂੰ ਅਜਿਹੇ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਬਿਆਨ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਲਾਇੰਟ ਸਰਵਰ ਤੋਂ ਰਿਲੇ ਕੀਤਾ ਟ੍ਰਾਂਸਪੋਰਟ ਪਤਾ ਮੰਗਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਉਸ ਕਲਾਇੰਟ ਅਤੇ ਉਸਦੇ ਸਮਕੱਖਾਂ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਭੇਜਦਾ ਹੈ। ਇਸ ਲਈ ਡੇਟਾ ਰਿਲੇ ਢੋਂਦਾ ਹੈ, ਜੋ ਸਿਰਫ਼ ਟੋਇਆਂ ਨੂੰ ਮਿਲਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਵਾਲੀ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵੱਖਰਾ ਹੈ। ਰਿਲੇ ਪਤਾ ਦੂਜੇ ਪਾਸੇ ਨਾਲ ਬਦਲਣਾ ਇੱਕ ਤਾਲਮੇਲ ਕਦਮ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਜੋ ਤੁਸੀਂ ਵਾਅਦਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਉਹ ਸਿੱਧਾ ਰਾਹ ਹੈ। ਸਮਮਿਤ NAT ਅਤੇ ਕੁਝ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਫਾਇਰਵਾਲ ਮੋਰੀ ਕਰਨ ਨੂੰ ਹਰਾਉਂਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਿਸਟਮ ਜਾਂ ਤਾਂ ਰਿਲੇ ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ ਜਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਇਹ ਵੀ ਨਹੀਂ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਕਿ ਦੋ ਅਨੁਵਾਦਿਤ ਟੋਏ ਕਦੇ ਗੱਲ ਨਹੀਂ ਕਰ ਸਕਦੇ; ਰਿਲੇ ਬੈਕਅੱਪ ਵਾਲਾ ਸਮਰਥਿਤ ਸਟੈਕ ਇਸੇ ਲਈ ਮੌਜੂਦ ਹੈ ਕਿਉਂਕਿ ਉਹ ਅਕਸਰ ਕਰ ਸਕਦੇ ਹਨ। ਫੈਸਲਾ ਕਰੋ ਕਿ ਉਪਲਬਧਤਾ ਵੱਧ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਾਂ ਸਿੱਧਾਪਨ, ਫਿਰ ਅਨੁਕੂਲ ਸਥਿਤੀ ਮੰਨਣ ਦੀ ਥਾਂ ਜਾਂਚੋ ਕਿ ਤੈਨਾਤੀ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਾਹ ਚੁਣਿਆ।
ਬ੍ਰੋਕਰ ਨੈੱਟਵਰਕ ਨਾਲੋਂ ਸੰਕੁਚਿਤ ਹੈ
ਜਦੋਂ ਲੋੜ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਹੋਵੇ, ਤਾਂ ਐਪ ਬ੍ਰੋਕਰ ਜਾਂ ਵਰਕਸਟੇਸ਼ਨ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਰਿਵਰਸ ਕਨੈਕਸ਼ਨ ਸਭ ਤੋਂ ਛੋਟਾ ਜਵਾਬ ਹੋ ਸਕਦਾ ਹੈ। ਵਰਕਸਟੇਸ਼ਨ ਬਾਹਰ ਬ੍ਰੋਕਰ ਵੱਲ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਬ੍ਰੋਕਰ ਦੂਰ ਦੇ ਵਰਤੋਂਕਾਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਉਹੀ ਐਪਲੀਕੇਸ਼ਨ ਸੈਸ਼ਨ ਢੋਇਆ ਜਾਂਦਾ ਹੈ। ਵਰਕਸਟੇਸ਼ਨ ਦੇ ਸਬਨੈੱਟ ਤੱਕ ਕੋਈ ਰਾਹ ਨਹੀਂ ਬਣਦਾ, ਇਸ ਲਈ ਦੂਰ ਦੇ ਸੈਸ਼ਨ ਦਾ ਸਮਝੌਤਾ ਨਾਲ ਵਾਲੇ ਹਰ ਯੰਤਰ ਤੱਕ ਰਾਹ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਪਾਉਂਦਾ।
ਇਸ ਸੰਕੁਚਨ ਦੀ ਕੀਮਤ ਹੈ: ਹਰ ਵਾਧੂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਆਪਣਾ ਏਕੀਕਰਨ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਬਾਰੇ ਜੋ ਮੰਨਦੀ ਹੈ, ਜਿਵੇਂ ਨੇੜਲੇ ਸਰਵਰ ਤੇ ਖੋਲ੍ਹੀ ਜਾਂਦੀ ਫਾਈਲ ਸ਼ੇਅਰਿੰਗ, ਉਹ ਪਹੁੰਚਯੋਗ ਨਾ ਹੋ ਸਕਦੀ ਹੈ। ਬ੍ਰੋਕਰ ਨੀਤੀ ਅਤੇ ਲੌਗਿੰਗ ਨੂੰ ਇੱਕ ਥਾਂ ਕੇਂਦ੍ਰਿਤ ਕਰਦੇ ਹਨ, ਜੋ ਉਸ ਥਾਂ ਦੇ ਰੁਕਾਵਟ ਬਣਨ ਤੱਕ ਲਾਭਦਾਇਕ ਹੈ।
ਭਰੋਸੇ ਦੀਆਂ ਹੱਦਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਰਾਹ ਦੀ ਜਾਂਚ ਕਰੋ
ਸੁਰੰਗਾਂ ਖਤਮ ਕਰਨ ਵਾਲਾ ਹੱਬ ਆਪਣੇ ਰਾਊਟ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਸਿਰੇ ਤੋਂ ਸਿਰੇ ਤੱਕ ਐਨਕ੍ਰਿਪਟ ਕਰਦੀ ਹੈ ਤਾਂ ਰਿਲੇ ਸੁਤੰਤਰ ਤੌਰ ਤੇ ਸੁਰੱਖਿਅਤ ਅਦਾਨ-ਪ੍ਰਦਾਨ ਢੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਬ੍ਰੋਕਰ ਆਮ ਤੌਰ ਤੇ ਆਪਣੇ ਪੇਸ਼ ਕੀਤੇ ਸੈਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਐਨਕ੍ਰਿਪਟਡ ਹਨ ਇਸ ਲਈ ਦੋ ਡਿਜ਼ਾਈਨ ਬਰਾਬਰ ਹਨ, ਇਹ ਫੈਸਲਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਿਤ ਕਰੋ ਕਿ ਸੁਰੱਖਿਆ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਖਤਮ ਹੁੰਦੀ ਹੈ।
ਫਿਰ ਜਾਂਚੋ ਕਿ ਵਰਕਸਟੇਸ਼ਨ ਬਾਹਰ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਪਹੁੰਚਦਾ ਹੈ, ਕਿਉਂਕਿ ਉੱਪਰਲਾ ਹਰ ਡਿਜ਼ਾਈਨ ਇਸ ਤੇ ਨਿਰਭਰ ਹੈ। ਇਹ ਵਰਕਸਟੇਸ਼ਨ ਤੇ ਚਲਾਓ, ਅਤੇ ਉਹ ਹੋਸਟਨਾਮ ਬਦਲੋ ਜੋ ਤੁਸੀਂ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comਡਿਜ਼ਾਈਨ ਨੂੰ ਤਦ ਹੀ ਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ ਮਨਜ਼ੂਰ ਪਛਾਣ ਹੇਠ ਲੋੜੀਂਦੀ ਦੂਰ ਦੀ ਕਾਰਵਾਈ ਸਫਲ ਹੋਵੇ, ਮਨਜ਼ੂਰ ਨਾ ਕੀਤੀ ਪਛਾਣ ਰੱਦ ਹੋਵੇ, ਅਤੇ ਸਿੱਧਾ ਜਾਂ ਰਿਲੇ ਰਾਹ ਉਪਲਬਧ ਨਾ ਹੋਣ ਤੇ ਵਿਵਹਾਰ ਜਾਣਿਆ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਹੋਵੇ। ਦੁਬਾਰਾ ਕਨੈਕਟ ਅਤੇ ਵਰਕਸਟੇਸ਼ਨ ਦਾ ਆਮ ਸਟਾਰਟਅੱਪ ਸੰਦਰਭ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਦਫ਼ਤਰ ਵਿੱਚ LAN ਰਾਹੀਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੈਸ਼ਨ ਦੂਰ ਦੀ ਪਹੁੰਚ ਜਿਸ ਤੇ ਨਿਰਭਰ ਹੈ, ਉਸ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਨਹੀਂ ਜਾਂਚਦਾ।