VPN ਰਾਹੀਂ Wake-on-LAN ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ? ਬ੍ਰਾਡਕਾਸਟ ਕਦੇ ਪਾਰ ਨਹੀਂ ਹੁੰਦਾ

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

ਤੁਸੀਂ ਦਫ਼ਤਰ ਦੀ ਮਸ਼ੀਨ ਨੂੰ ਸੁਲਾਉਂਦੇ ਹੋ, ਘਰੋਂ VPN ਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਉਹ ਬੰਦ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਟਨਲ ਚਾਲੂ ਹੈ, ਫ਼ਾਈਲ ਸ਼ੇਅਰ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਰਾਊਟਰ ਦਾ wake-on-LAN ਪੰਨਾ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸਨੇ ਬੇਨਤੀ ਭੇਜ ਦਿੱਤੀ ਹੈ। ਹਰ ਦਿਸਦਾ ਸੰਕੇਤ ਕਹਿੰਦਾ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਠੀਕ ਹੈ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਇਹ ਮਾਮਲਾ ਉਲਝਾਉਂਦਾ ਹੈ: ਜੋ ਫ਼ਰੇਮ ਮਸ਼ੀਨ ਨੂੰ ਜਗਾਏਗਾ ਉਹ ਕਦੇ ਉਸ ਸੈਗਮੈਂਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ ਜਿਸ ਵਿੱਚ ਉਹ ਹੈ।

ਲੱਛਣ ਸਬਨੈੱਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਟਨਲ ਵੱਲ ਨਹੀਂ

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

ਜਿਵੇਂ ਹੀ ਉਸੇ ਸੈਗਮੈਂਟ ਵਿੱਚ ਜਾਂਚ ਪਾਸ ਹੁੰਦੀ ਹੈ, ਗੜਬੜ ਦਾਇਰੇ ਵਿੱਚ ਹੈ। ਤੁਸੀਂ ਜੋ ਭੇਜਣ ਵਾਲਾ ਵਰਤ ਰਹੇ ਹੋ ਉਹ VPN ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਜੋ ਪੈਕੇਟ ਉਹ ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਸਥਾਨਕ ਲਿੰਕ ਲਈ ਬ੍ਰਾਡਕਾਸਟ ਹੈ, ਇਸ ਲਈ ਉਹ ਗਲਤ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਨਿਕਲਦਾ ਹੈ ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ ਨਿਕਲਦਾ। ਟਨਲ ਖਰਾਬ ਨਹੀਂ; ਉਹ ਗਲਤ ਕਿਸਮ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਢੋ ਰਿਹਾ ਹੈ। ਰਾਊਟਰ ਦੀ ਇੱਕ ਵੀ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਲਗਾਓ ਕਿ ਭੇਜਣ ਵਾਲਾ ਕਿਹੜਾ ਇੰਟਰਫ਼ੇਸ ਚੁਣਦਾ ਹੈ।

magic packet ਇੱਕ ਫ਼ਰੇਮ ਹੈ, ਸੇਵਾ ਨਹੀਂ

ਪੇਲੋਡ ਛੇ ਬਾਈਟ ਦੇ ਸਥਿਰ ਹੈਡਰ 0xFF ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਫਿਰ ਟਾਰਗਿਟ ਕਾਰਡ ਦਾ ਹਾਰਡਵੇਅਰ ਪਤਾ ਸੋਲਾਂ ਵਾਰ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਚਾਰ ਬਾਈਟ ਦਾ ਚੋਣਵਾਂ SecureOn ਪਾਸਵਰਡ ਆਉਂਦਾ ਹੈ। ਭੇਜਣ ਵਾਲੇ ਇਸਨੂੰ ਆਮ ਤੌਰ ’ਤੇ UDP ਵਿੱਚ ਲਪੇਟ ਕੇ ਪੋਰਟ 7 ਜਾਂ ਪੋਰਟ 9 ’ਤੇ ਭੇਜਦੇ ਹਨ, ਪਰ ਪੋਰਟ ਨੰਬਰ ਭੇਜਣ ਵਾਲੇ ਅਤੇ ਕਾਰਡ ਵਿਚਕਾਰ ਇੱਕ ਰੀਤ ਹੈ, ਸੁਣਨ ਵਾਲੀ ਸੇਵਾ ਨਹੀਂ ਜਿਸ ਨਾਲ ਜੁੜਿਆ ਜਾ ਸਕੇ। ਕੋਈ ਨਹੀਂ ਸੁਣਦਾ, ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।

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

ਰੂਟ ਕੀਤਾ ਟਨਲ ਇਸਨੂੰ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚਾ ਸਕਦਾ

ਰੂਟ ਕੀਤਾ VPN ਇੰਟਰਫ਼ੇਸ ਦੋ ਟਨਲ ਪਤਿਆਂ ਵਿਚਕਾਰ ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ IP ਲਿੰਕ ਹੈ। ਇਹ ਪੀਅਰ ਨੂੰ ਸੰਬੋਧਿਤ ਪੈਕੇਟ ਢੋਣ ਲਈ ਹੈ, ਇਸ ਲਈ ਪਿੰਗ, SSH ਅਤੇ ਫ਼ਾਈਲ ਸ਼ੇਅਰ ਇਸ ਰਾਹੀਂ ਆਮ ਤਰ੍ਹਾਂ ਚੱਲਦੇ ਹਨ। ਬ੍ਰਾਡਕਾਸਟ ਫ਼ਰੇਮ ਉਸ ਪੀਅਰ ਨੂੰ ਸੰਬੋਧਿਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਸੀਮਤ ਬ੍ਰਾਡਕਾਸਟ ਪਤਾ ਰਾਊਟਰ ਕਦੇ ਆਪਣੇ ਆਪ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ।

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

ਕਾਰਡ ਤੱਕ ਸੱਚਮੁੱਚ ਪਹੁੰਚਣ ਵਾਲੀਆਂ ਤਿੰਨ ਥਾਵਾਂ

ਹਰ ਕਾਰਗਰ ਬੰਦੋਬਸਤ ਫ਼ਰੇਮ ਨੂੰ ਟਾਰਗਿਟ ਦੇ ਸੈਗਮੈਂਟ ਵਿੱਚ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਉਹ ਇਸ ਗੱਲ ਵਿੱਚ ਵੱਖਰੀਆਂ ਹਨ ਕਿ ਨੈੱਟਵਰਕ ਨੂੰ ਕਿੰਨਾ ਖ਼ਲਲ ਪਾਉਂਦੀਆਂ ਹਨ:

  1. ਟਾਰਗਿਟ ਸੈਗਮੈਂਟ ਵਿੱਚ ਹਮੇਸ਼ਾ ਚਾਲੂ ਰਹਿਣ ਵਾਲਾ ਜੰਤਰ ਰੱਖੋ। ਬਿਜਲੀ ’ਤੇ ਰਹਿਣ ਵਾਲਾ ਰਾਊਟਰ, NAS ਜਾਂ ਛੋਟਾ ਲਿਨਕਸ ਡੱਬਾ ਫ਼ਰੇਮ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਟਨਲ ਰਾਹੀਂ ਉੱਥੇ ਪਹੁੰਚਦੇ ਹੋ, ਅਤੇ VPN ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।
  2. ਰਾਊਟਰ ਨੂੰ ਖੁਦ ਫ਼ਰੇਮ ਭੇਜਣ ਦਿਓ। ਕਈ ਫ਼ਰਮਵੇਅਰ ਜਗਾਉਣ ਵਾਲਾ ਪੰਨਾ ਦਿੰਦੇ ਹਨ ਜੋ LAN ਬ੍ਰਿਜ ਤੋਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਇਹ ਤਦ ਤੱਕ ਚੱਲਦਾ ਹੈ ਜਦ ਤੱਕ ਟਾਰਗਿਟ ਉਸੇ ਬ੍ਰਿਜ ’ਤੇ ਹੈ, ਦੂਜੇ ਰਾਊਟਰ ਪਿੱਛੇ ਨਹੀਂ।
  3. ਜਦੋਂ ਬ੍ਰਾਡਕਾਸਟ ਨੂੰ ਸੱਚਮੁੱਚ ਪਾਰ ਜਾਣਾ ਹੋਵੇ ਤਾਂ ਥਾਵਾਂ ਨੂੰ TAP ਕਿਸਮ ਦੇ ਟਨਲ ਨਾਲ ਪੁਲ ਬਣਾਓ। ਇਹ ਦੋ ਬ੍ਰਾਡਕਾਸਟ ਡੋਮੇਨ ਮਿਲਾ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਬ੍ਰਾਡਕਾਸਟ ਤੂਫ਼ਾਨ, ਇੱਕੋ ਪਤਾ ਯੋਜਨਾ ਅਤੇ ਦੋਵੇਂ ਥਾਵਾਂ ਇਕੱਠੀਆਂ ਦੇਖਣ ਵਾਲਾ ਹਰ ਖੋਜ ਪ੍ਰੋਟੋਕਾਲ ਲਿਆਉਂਦਾ ਹੈ।

ਪਹਿਲਾ ਵਿਕਲਪ ਇੱਕ ਮਸ਼ੀਨ ਲਈ ਤਰਜੀਹੀ ਹੈ। ਤੀਜਾ ਲਗਾਤਾਰ ਖ਼ਰਚ ਵਾਲਾ ਨੈੱਟਵਰਕ ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ, ਇਸ ਲਈ ਉਸਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਸਮਝੋ, ਇੱਕ ਡੈਸਕਟਾਪ ਲਈ ਤੇਜ਼ ਹੱਲ ਨਹੀਂ।

ਲਿਖੋ ਕਿਹੜਾ ਸਹਾਇਕ ਫ਼ਰੇਮ ਭੇਜਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿਹੜੇ ਬ੍ਰਿਜ ਜਾਂ VLAN ’ਤੇ ਹੈ। ਗਲਤ ਇੰਟਰਫ਼ੇਸ ਤੋਂ ਭੇਜਣ ਵਾਲਾ ਸਹਾਇਕ ਪੂਰੀ ਰਿਕਾਰਡਿੰਗ ਅਤੇ ਕਦੇ ਨਾ ਜਾਗਣ ਵਾਲੀ ਮਸ਼ੀਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਜੋੜੀ ਇੱਕ ਦੁਪਹਿਰ ਖਾ ਜਾਂਦੀ ਹੈ।

ਕਲਾਇੰਟ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਭੇਜਣਾ ਜਾਂਚੋ

ਪਹਿਲਾਂ ਟਾਰਗਿਟ ਕਾਰਡ ਵੇਖੋ, ਕਿਉਂਕਿ ਕੋਈ ਵੀ ਭੇਜਣ ਵਾਲਾ ਤਿਆਰ ਨਾ ਹੋਏ ਕਾਰਡ ਨੂੰ ਨਹੀਂ ਜਗਾ ਸਕਦਾ। ਹੇਠਾਂ ਦਿੱਤਾ ਹੁਕਮ ਸਮਰਥਿਤ ਅਤੇ ਮੌਜੂਦਾ ਜਗਾਉਣ ਦੇ ਢੰਗ ਪੜ੍ਹਦਾ ਹੈ, ਜਿੱਥੇ ਮੌਜੂਦਾ g ਮੁੱਲ ਦਾ ਅਰਥ ਹੈ ਕਿ magic packet ਚਾਲੂ ਹੈ:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

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

Windows ਵਿੱਚ ਕਾਰਡ ਦੀ ਬਰਾਬਰ ਜਾਂਚ powercfg /devicequery wake_armed ਹੈ ਜੋ ਸਿਸਟਮ ਜਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਵਾਲੇ ਜੰਤਰ ਗਿਣਾਉਂਦੀ ਹੈ। ਉਸ ਸੂਚੀ ਤੋਂ ਗ਼ੈਰਹਾਜ਼ਰ ਨੈੱਟਵਰਕ ਅਡੈਪਟਰ ਉਸ ਨੂੰ ਭੇਜੇ ਹਰ ਪੈਕੇਟ ਨੂੰ ਅਣਡਿੱਠ ਕਰੇਗਾ, ਫ਼ਰੇਮ ਤਾਰ ’ਤੇ ਕਿੰਨਾ ਵੀ ਸਹੀ ਦਿਸੇ।

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

ਸੰਬੰਧਿਤ ਲੇਖ