openfortivpn ਵਾਰ-ਵਾਰ DNS ਕਿਉਂ ਬਦਲ ਰਿਹਾ ਹੈ? ਅਸਲ ਮਾਲਕ ਲੱਭੋ

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

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

ਕਨੈਕਸ਼ਨ ਨੇ ਅਸਲ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

ਆਪਣੇ ਆਮ ਹੁਕਮ ਨਾਲ ਇੱਕ ਵਾਰ ਜੁੜੋ ਅਤੇ ਪਹਿਲਾਂ ਤੇ ਬਾਅਦ ਦੀ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਦੀ ਤੁਲਨਾ ਕਰੋ। systemd-resolved ਚਲਾਉਣ ਵਾਲੇ Linux ਹੋਸਟ ਉੱਤੇ, resolvectl status ਹਰ ਲਿੰਕ ਲਈ DNS ਸਰਵਰ ਅਤੇ ਖੋਜ ਡੋਮੇਨ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਆਪਣੇ ਸਰਵਰ ਲੈ ਕੇ ਜਾਣ ਵਾਲਾ ਨਵਾਂ tun ਜਾਂ ppp ਲਿੰਕ ਕਲਾਇੰਟ-ਪਾਸੇ ਦੇ ਅਪਡੇਟ ਦੀ ਉਂਗਲੀ ਦਾ ਨਿਸ਼ਾਨ ਹੈ। macOS ਉੱਤੇ, scutil --dns ਰੈਜ਼ੌਲਵਰ ਸੰਰਚਨਾ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਇਸ ਨੂੰ ਪੁੱਛਦੇ ਹਨ।

ਇਸ ਦੀ ਤੁਲਨਾ ਉਸ ਫਾਈਲ ਨਾਲ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਬਦਲਣ ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ। ਪ੍ਰਤੀ-ਲਿੰਕ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਕਨੈਕਸ਼ਨ-ਬੱਧ ਐਂਟਰੀ ਅਤੇ ਦੁਬਾਰਾ ਲਿਖੀ /etc/resolv.conf ਦੋ ਵੱਖਰੇ ਨਤੀਜੇ ਹਨ, ਅਤੇ ਦੂਜਾ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦੀ ਸਿੰਬੋਲਿਕ ਲਿੰਕ ਹੋ ਸਕਦਾ ਹੈ। ਰੈਜ਼ੌਲਵਰ ਦਾ ਪਤਾ, ਖੋਜ ਡੋਮੇਨ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਂ ਇੱਕੋ ਪਲ ਵਿੱਚ ਲਿਖੋ; ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬਦਲਿਆ ਤਾਂ ਕਿਸੇ ਹੋਰ ਲੇਖਕ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਉਸ ਆਧਾਰ-ਰੇਖਾ ਤੋਂ ਬਿਨਾਂ, ਹਰ ਬਾਅਦ ਵਾਲਾ ਸੁਧਾਰ ਇਸ ਅਨੁਮਾਨ ਉੱਤੇ ਹੈ ਕਿ ਤਿੰਨ ਭਾਗਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹਿੱਲਿਆ।

ਦੋ ਸਵਿੱਚ ਅਤੇ ਹਰ ਇੱਕ ਜਿਸ ਲੇਖਕ ਨੂੰ ਚੁੱਪ ਕਰਾਉਂਦਾ ਹੈ

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

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns ਕਲਾਇੰਟ ਨੂੰ ਗੇਟਵੇ ਤੋਂ ਸਿੱਖੇ DNS ਸਰਵਰ ਲਾਗੂ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਜਦਕਿ --pppd-no-peerdns pppd ਨੂੰ ਸਾਥੀ ਦਾ DNS ਸਿਸਟਮ ਵਿੱਚ ਧੱਕਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। upstream ਮੈਨੁਅਲ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ PPP ਰਾਹੀਂ DNS ਅਪਡੇਟ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ DNS ਅਪਡੇਟਾਂ ਨਾਲ ਦੌੜ ਲਾ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਦੋਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਕਾਫ਼ੀ ਮੰਨਣ ਦੀ ਥਾਂ ਦੋਵੇਂ ਸਵਿੱਚ ਟੁਕੜੇ ਵਿੱਚ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

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

ਕੁਝ ਵੀ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਲਕ ਚੁਣੋ

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

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

ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਹਰ ਲਿੰਕ ਲਈ ਜਾਂਚੋ, ਹਰ ਫਾਈਲ ਲਈ ਨਹੀਂ

ਸੀਮਤ ਜਾਂ ਪ੍ਰਤੀ-ਡੋਮੇਨ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤਦੇ ਹਨ ਇਸ ਦੀ ਸੂਚੀ ਇੱਕ /etc/resolv.conf ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਪਲੇਟਫ਼ਾਰਮ ਜਿਵੇਂ ਰੈਜ਼ੌਲਵਰ ਦੀ ਸਥਿਤੀ ਖੋਲ੍ਹਦਾ ਹੈ ਉਵੇਂ ਪੜ੍ਹੋ।

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਡਿਸਕਨੈਕਟ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਕਨੈਕਸ਼ਨ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਦੋਵੇਂ ਪੁੱਛਗਿੱਛਾਂ ਦੁਹਰਾਓ। ਚੁਣੇ ਮਾਲਕ ਨੇ ਜੋ ਲਾਇਆ ਹੈ ਉਹ ਉਸੇ ਮਾਲਕ ਨੇ ਹਟਾਉਣਾ ਜਾਂ ਬਹਾਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਤੁਸੀਂ ਚੁੱਪ ਕਰਾਏ ਕਲਾਇੰਟ ਨੇ ਛੱਡਣਾ ਨਹੀਂ ਚਾਹੀਦਾ। ਟਨਲ ਨਾਲੋਂ ਵੱਧ ਟਿਕਣ ਵਾਲੀ ਪੁਰਾਣੀ ਪ੍ਰਤੀ-ਲਿੰਕ ਐਂਟਰੀ ਨਿੱਜੀ ਪੁੱਛਗਿੱਛਾਂ ਅਜਿਹੇ ਪਤੇ ਉੱਤੇ ਭੇਜਦੀ ਰਹਿੰਦੀ ਹੈ ਜੋ ਹੁਣ ਪਹੁੰਚਯੋਗ ਨਹੀਂ।

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

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