ਉਹ NAT ਜੋ ਤੁਸੀਂ ਕਨਫਿਗਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਉਸ ਪਿੱਛੇ VPN: ਹਾਲੇ ਵੀ ਕੀ ਕੰਮ ਕਰਦਾ ਹੈ

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

ਮੈਪਿੰਗ ਟੇਬਲ ਹੀ ਸਭ ਕੁਝ ਤੈਅ ਕਰਦੀ ਹੈ

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

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

ਮਿਲਣ ਸੇਵਾ ਕੀ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

UDP ਹੋਲ ਪੰਚਿੰਗ ਫਿਲਟਰ ਨੂੰ ਹਰਾਉਣ ਦੀ ਥਾਂ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਰਿਕਾਰਡ ਨੂੰ ਅਸਥਾਈ ਖੁੱਲ੍ਹ ਵਜੋਂ ਵਰਤਦੀ ਹੈ। ਦੋਵੇਂ ਸਾਥੀ ਮਿਲਣ ਸੇਵਾ ਨਾਲ ਸੰਪਰਕ ਕਰਦੇ ਹਨ, ਜੋ ਹਰ ਸਾਰਵਜਨਿਕ ਐਂਡਪੌਇੰਟ ਜਾਣਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਨੂੰ ਉਸਦਾ ਐਂਡਪੌਇੰਟ ਵਾਪਸ ਦੱਸਦੀ ਹੈ। ਫਿਰ ਦੋਵੇਂ ਇੱਕ-ਦੂਜੇ ਵੱਲ ਭੇਜਦੇ ਹਨ, ਅਤੇ ਹਰ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕਟ ਉਹ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ ਜਾਂ ਤਾਜ਼ਾ ਕਰਦਾ ਹੈ ਜੋ ਜਵਾਬ ਨੂੰ ਅੰਦਰ ਆਉਣ ਦਿੰਦਾ ਹੈ। ਕ੍ਰਮ ਹੀ ਇਸਨੂੰ ਕੰਮ ਕਰਵਾਉਂਦਾ ਹੈ, ਅਤੇ ਕ੍ਰਮ ਹੀ ਇਸਨੂੰ ਨਾਜ਼ੁਕ ਬਣਾਉਂਦਾ ਹੈ: ਜੋ ਸਾਥੀ ਦੂਜੇ ਪਾਸੇ ਦੇ ਰਿਕਾਰਡ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਭੇਜਦਾ ਹੈ ਉਹ ਸਿਰਫ਼ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਇੱਕ ਪਲ ਬਾਅਦ ਦੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਸਫਲ ਹੁੰਦੀ ਹੈ। ਸੇਵਾ ਖੁਦ ਕੋਈ VPN ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਢੋਂਦੀ, ਇਸ ਲਈ ਉਸਦਾ ਇੱਕੋ-ਇੱਕ ਲਾਭ ਉਹ ਸਮਾਂ-ਸੰਗਠਨ ਹੈ ਜੋ ਉਹ ਕਰਦੀ ਹੈ।

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

ਕੀਪਅਲਾਈਵ, ਰੀਬੂਟ ਅਤੇ ਖਿਸਕਦਾ ਐਂਡਪੌਇੰਟ

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

ਇੱਕ ਘੰਟਾ ਸੁੱਤਾ ਲੈਪਟਾਪ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਸਾਰਵਜਨਿਕ ਐਂਡਪੌਇੰਟ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਜੋ ਰਸਤਾ ਮੁੜ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਉਸਨੂੰ ਫਿਰ ਅੰਦਰੋਂ ਚੱਲਣਾ ਪਵੇਗਾ, ਜੋ ਉਹੀ ਸ਼ਰਤ ਕਲਾਇੰਟ 'ਤੇ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ।

ਗੁੰਮ ਫਾਰਵਰਡ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਤਿੰਨ ਰਸਤੇ

ਪਹਿਲਾ ਰਸਤਾ ਰਾਊਟਰ ਨੂੰ ਕਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਖੁਦ ਐਂਟਰੀ ਬਣਾਵੇ, UPnP IGD, NAT-PMP ਜਾਂ PCP ਰਾਹੀਂ, ਜਦੋਂ ਵਿਸ਼ੇਸ਼ਤਾ ਮੌਜੂਦ ਹੋਵੇ ਅਤੇ ਚਾਲੂ ਹੋਵੇ। ਦੂਜਾ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਾਰਵਜਨਿਕ ਪਤੇ ਵਾਲੇ ਰਿਲੇ ਨੂੰ ਸੌਂਪਦਾ ਹੈ, ਜੋ ਹਮੇਸ਼ਾ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਹਮੇਸ਼ਾ ਬੈਂਡਵਿਡਥ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰੀ ਭਰੋਸੇ-ਸੀਮਾ ਦਾ ਖਰਚਾ ਲੈਂਦਾ ਹੈ। ਤੀਸਰਾ ਦਿਸ਼ਾ ਉਲਟ ਦਿੰਦਾ ਹੈ: ਅੰਦਰੂਨੀ ਹੋਸਟ ਸਾਰਵਜਨਿਕ ਸਰਵਰ ਵੱਲ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਟਨਲ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਉਸਦੇ ਅੰਦਰ ਸਵਾਰੀ ਕਰਦਾ ਹੈ।

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

ਹੱਲ ਨੂੰ ਰਾਊਟਰ ਦੇ ਮਾਲਕ ਨਾਲ ਮਿਲਾਓ

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

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