ਘਰ ਦੇ VPN ਸਰਵਰ ਲਈ ਡਾਇਨਾਮਿਕ DNS ਲੋੜੀਂਦਾ ਹੈ?

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

ਸ਼ਰਤ ਇੱਕ: ਤੁਹਾਡਾ ਪਤਾ ਸੱਚਮੁੱਚ ਬਦਲਦਾ ਹੈ

ਰਿਹਾਇਸ਼ੀ ਪਤੇ ਆਮ ਕਾਰਨਾਂ ਕਰਕੇ ਬਦਲਦੇ ਹਨ: ਬਿਜਲੀ ਜਾਣ ’ਤੇ ਮੋਡਮ ਮੁੜ ਸਿੰਕ ਹੁੰਦਾ ਹੈ, ISP ਪੂਲ ਮੁੜ ਸੰਤੁਲਿਤ ਕਰਦਾ ਹੈ, ਲੰਮੇ ਵਿਘਨ ਤੋਂ ਬਾਅਦ ਨਵਾਂ ਲੀਜ਼ ਆਉਂਦਾ ਹੈ। ਕੁਝ ਲਾਈਨਾਂ ’ਤੇ ਇਹ ਬਹੁਤ ਘੱਟ ਬਦਲਦੇ ਹਨ, ਅਤੇ ਮੈਂ ਇੱਕੋ ਪਤਾ ਸਾਲ ਭਰ ਟਿਕਿਆ ਦੇਖਿਆ ਹੈ; ਕਾਰੋਬਾਰੀ ਪਲਾਨਾਂ ਵਿੱਚ ਅਕਸਰ ਸਥਿਰ ਪਤਾ ਹੁੰਦਾ ਹੈ। ਜੇ ਬਾਰਾਂ ਮਹੀਨਿਆਂ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ, ਤਾਂ ਹੱਥ ਨਾਲ ਸੋਧਣ ਵਾਲਾ ਇੱਕ A ਰਿਕਾਰਡ ਇੱਕ ਡੈਮਨ ਘੱਟ ਜ਼ਿੰਦਾ ਰੱਖਣਾ ਹੈ।

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਮਾਪੋ। ਰਾਊਟਰ ਦੇ ਸਟੇਟਸ ਪੇਜ ’ਤੇ WAN ਪਤਾ ਪੜ੍ਹੋ, ਫਿਰ ਬਾਹਰੀ ਦੁਨੀਆ ਜੋ ਦੇਖਦੀ ਹੈ ਉਸ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਇਹ LAN ਦੀ ਮਸ਼ੀਨ ਤੋਂ ਚਲਾਓ:

curl -fsS https://api.ipify.org; echo

ਜੇ ਦੋਵੇਂ ਮੁੱਲ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਰਾਊਟਰ ਦੇ ਅੱਗੇ ਕੁਝ ਅਨੁਵਾਦ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਹੋਸਟਨਾਮ ਅਪਡੇਟ ਉਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ। 100.64.0.0/10 ਅੰਦਰਲਾ ਪਤਾ ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਲਈ ਸਾਂਝੀ ਰੇਂਜ ਹੈ, ਅਤੇ ਇਹੀ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਸਹੀ ਢੰਗ ਨਾਲ ਅਪਡੇਟ ਕੀਤਾ ਨਾਮ ਵੀ ਬਾਹਰੋਂ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਜਾਂਦਾ ਹੈ।

ਸ਼ਰਤ ਦੋ: ਕਲਾਇੰਟ ਨਾਮ ਮੁੜ ਖੋਜਦੇ ਹਨ

ਛੋਟਾ TTL ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਰਿਕਰਸਿਵ ਰਿਜ਼ੌਲਵਰ ਰਿਕਾਰਡ ਦੇ TTL ਦਾ ਸਤਿਕਾਰ ਕਰਦੇ ਹਨ, ਪਰ ਕਲਾਇੰਟ ਸਟੈਕ ਵੱਖਰੇ ਕੈਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਖੜ੍ਹੀ ਸੁਰੰਗ ਕੁਝ ਵੀ ਮੁੜ ਹੱਲ ਨਹੀਂ ਕਰਦੀ। ਡੀਬੱਗ ਕਰਦੇ ਸਮੇਂ ਰਿਕਾਰਡ 60-300 ਸਕਿੰਟ ’ਤੇ ਰੱਖੋ; ਇਹ ਪੁਰਾਣਾ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਖਿੜਕੀ ਛੋਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਜੁੜੇ ਸੈਸ਼ਨ ਨੂੰ ਭੇਜਦਾ ਨਹੀਂ।

OpenVPN ਹਰ ਵਾਰ ਮੁੜ ਜੁੜਨ ’ਤੇ ਲਾਈਨ remote vpn.example.net 1194 ਮੁੜ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ resolv-retry infinite ਖੋਜ ਫੇਲ੍ਹ ਹੋਣ ’ਤੇ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਥਾਂ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਰਹਿਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਸਰਵਰ ’ਤੇ float ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਨੂੰ ਸਰੋਤ ਪਤਾ ਬਦਲ ਚੁੱਕੇ ਸਾਥੀ ਦਾ ਪਿੱਛਾ ਕਰਨ ਦਿੰਦਾ ਹੈ। WireGuard ਵਧੇਰੇ ਸਿੱਧਾ ਹੈ: wg-quick up ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਲਾਗੂ ਹੋਣ ’ਤੇ Endpoint ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਸੁਰੰਗ ਮੁੜ ਬਣਾਉਣ ’ਤੇ ਉਸਨੂੰ ਮੁੜ ਹੱਲ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪੁਰਾਣੇ ਪਤੇ ਨਾਲ ਅਜੇ ਵੀ ਸਫਲ ਹੋਣ ਵਾਲਾ ਹੈਂਡਸ਼ੇਕ ਰੁਕਣ ਤੱਕ ਸਫਲ ਰਹਿੰਦਾ ਹੈ।

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

ਸ਼ਰਤ ਤਿੰਨ: ਅੰਦਰ ਆਉਣ ਦਾ ਰਾਹ ਅਜੇ ਖੁੱਲ੍ਹਾ ਹੈ

ਡਾਇਨਾਮਿਕ DNS ਸਿਰਫ਼ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਨਾਮ ਕਿੱਥੇ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ। ਰਾਊਟਰ ’ਤੇ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ, VPN ਹੋਸਟ ’ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ ISP ਦੀ ਆਉਂਦੇ ਪੈਕਟਾਂ ਨੂੰ ਇਜਾਜ਼ਤ — ਸਭ ਰਿਕਾਰਡ ਦਾ ਮਤਲਬ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਵੇਖੋ ਫਾਰਵਰਡਿੰਗ ਕਿਸ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦੀ ਹੈ: ਜੇ ਇਹ ਇੰਟਰਫ਼ੇਸ ਦੀ ਥਾਂ WAN ਪਤੇ ਨਾਲ ਪਿੰਨ ਹੈ, ਤਾਂ ਪਤਾ ਬਦਲਣ ’ਤੇ ਫਾਰਵਰਡਿੰਗ ਚੁੱਪਚਾਪ ਟੁੱਟ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੋਸ਼ ਰਿਕਾਰਡ ’ਤੇ ਆਉਂਦਾ ਹੈ।

ਬਾਹਰੋਂ ਪਰਖੋ। Wi-Fi ਬੰਦ ਕਰਕੇ ਸੈਲੂਲਰ ਡੇਟਾ ’ਤੇ ਫ਼ੋਨ ਸਭ ਤੋਂ ਸਸਤਾ ਇਮਾਨਦਾਰ ਪਰੀਖਣ ਹੈ; ਉਸੇ LAN ਦਾ ਲੈਪਟਾਪ ਨਹੀਂ। ਜਦੋਂ ਨਾਮ ਤੁਹਾਡੇ ਜਨਤਕ ਪਤੇ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਰਾਊਟਰ ਵਿੱਚ NAT ਲੂਪਬੈਕ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਅੰਦਰਲਾ ਪਰੀਖਣ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਦਕਿ ਰਿਕਾਰਡ ਬਿਲਕੁਲ ਸਹੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਬਹੁਤਿਆਂ ਨੂੰ ਕਦੇ ਗ਼ਲਤ ਨਾ ਹੋਏ ਰਿਕਾਰਡ ਨੂੰ ਸੋਧਣ ਭੇਜਦਾ ਹੈ।

ਤਿੰਨੇ ਪੂਰੀਆਂ ਹੋਣ ’ਤੇ ਕੀ ਚਲਾਉਣਾ

ਛੋਟੇ ਹੋਸਟ ਲਈ ddclient ਸਭ ਤੋਂ ਘੱਟ ਹੈਰਾਨ ਕਰਨ ਵਾਲਾ ਅਪਡੇਟਰ ਹੈ। ਘੱਟੋ-ਘੱਟ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਪ੍ਰਦਾਤਾ ਵੱਲੋਂ ਦੇਖਿਆ ਪਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ, ਜੋ ਦੋਹਰੇ NAT ਦੀ ਗ਼ਲਤੀ ਬਚਾਉਂਦੀ ਹੈ:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

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

ਪਾਬੰਦ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ

ਇੱਕ ਖੋਜ ਦੱਸਦੀ ਹੈ ਕਿ ਬਾਕੀ ਦੁਨੀਆ ਕੀ ਦੇਖਦੀ ਹੈ, ਅਤੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਡੀਕਣ ਵਾਲਾ TTL ਛਾਪਦੀ ਹੈ:

dig +noall +answer vpn.example.net @1.1.1.1

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

ਇੱਕ ਮਿੰਟ ਦਾ ਰੋਲਬੈਕ ਰੱਖੋ: ਆਖ਼ਰੀ ਕੰਮ ਕਰਨ ਵਾਲਾ ਪਤਾ ਅਤੇ ਪਿਛਲਾ TTL ਨੋਟ ਕਰੋ, ਤਾਂ ਜੋ ਪ੍ਰਦਾਤਾ ਦੀ ਮਾੜੀ ਦੁਪਹਿਰ ਵੇਲੇ ਦੋਵੇਂ ਹੱਥ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕੋ।

ਜਦੋਂ ਜਵਾਬ ਨਾਂਹ ਹੋਵੇ

ਜੇ ਸ਼ਰਤ ਇੱਕ ਜਾਂ ਤਿੰਨ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਕਾਨਫ਼ਿਗਰੇਸ਼ਨ ਨਹੀਂ ਬਲਕਿ ਫ਼ੈਸਲਾ ਬਦਲਦਾ ਹੈ। ਕੈਰੀਅਰ NAT ਪਿੱਛੇ ਤੁਹਾਡੇ ਵਿਹਾਰਕ ਵਿਕਲਪ ਹਨ ISP ਤੋਂ ਜਨਤਕ ਪਤਾ ਮੰਗਣਾ, ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਨੂੰ ਸਥਿਰ ਪਤੇ ਵਾਲੇ ਛੋਟੇ VPS ’ਤੇ ਭੇਜਣਾ, ਜਾਂ ਆਪਣੀ ਮੁਲਾਕਾਤ ਰੱਖਣ ਵਾਲਾ ਓਵਰਲੇ ਵਰਤਣਾ। ਜੇ ਪਤਾ ਸਥਿਰ ਹੈ, ਤਾਂ ਅਪਡੇਟਰ ਛੱਡੋ: ਇੱਕ A ਰਿਕਾਰਡ, IPv6 ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਇੱਕ AAAA ਰਿਕਾਰਡ, ਉਹੀ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ।

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

ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਕ੍ਰਮ ਵਿੱਚ ਪੱਕੀਆਂ ਕਰੋ:

• ਅਪਡੇਟਰ ਜੋ ਪਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਉਹ ਰਾਊਟਰ ਦੇ WAN ਪਤੇ ਨਾਲ ਮਿਲਦਾ ਹੈ।
• ਰਿਕਾਰਡ ਦਾ TTL ਇੰਨਾ ਛੋਟਾ ਹੈ ਕਿ ਬਦਲਾਅ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਦਿਸੇ।
• ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬੱਝੀ ਹੈ, ਸਥਿਰ ਪਤੇ ਨਾਲ ਨਹੀਂ।
• ਆਖ਼ਰੀ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇੱਕ ਅਸਲੀ ਕਲਾਇੰਟ ਮੁੜ ਜੁੜਿਆ ਹੈ ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਲੰਘਿਆ ਹੈ।

ਜੇ ਚਾਰੇ ਪੂਰੀਆਂ ਹਨ, ਸੈਟਅਪ ਨੂੰ ਛੇੜੋ ਨਾ; ਤੁਹਾਡੀ ਅਗਲੀ ਖਰਾਬੀ ਨਾਮਕਰਨ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਸਗੋਂ ਚਾਬੀ ਜਾਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਹੈ। ਜੇ ਕੋਈ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਹੋਰ ਚੱਲਦਾ ਹਿੱਸਾ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਲਾਈਨ ਸੁਧਾਰੋ। RFC 2136 ਆਪ ਅਪਡੇਟ ਵਿਧੀ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜੇ ਤੁਸੀਂ ਦੇਖਣਾ ਚਾਹੋ ਕਿ ਡੈਮਨ ਤਾਰ ’ਤੇ ਕੀ ਰੱਖਦਾ ਹੈ।