ਤੁਹਾਡਾ Mac VPN ਤੇ ਕਿਹੜੇ DNS ਰਿਜ਼ੋਲਵਰ ਵਰਤਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਜਾਂਚੀਏ

scutil --dns ਉਹ ਰਿਜ਼ੋਲਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਛਾਪਦਾ ਹੈ ਜਿਸ ਨਾਲ macOS ਸੱਚਮੁੱਚ ਸਲਾਹ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ ਉਹ ਇੱਕੋ DNS ਸਰਵਰ ਜੋ ਤੁਸੀਂ ਸੈਟਿੰਗਾਂ ਪੈਨਲ ਵਿੱਚ ਟਾਈਪ ਕੀਤਾ ਸੀ। ਆਉਟਪੁੱਟ ਬਹੁਤਿਆਂ ਦੀ ਉਮੀਦ ਨਾਲੋਂ ਲੰਬਾ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਿਸਟਮ ਡਿਫਾਲਟ ਰਾਹ, ਸਕੋਪ ਕੀਤੇ ਇੰਟਰਫੇਸ ਅਤੇ ਡੋਮੇਨ-ਖਾਸ ਫਾਰਵਰਡਿੰਗ ਲਈ ਵੱਖਰੇ ਰਿਜ਼ੋਲਵਰ ਬਲਾਕ ਰੱਖਦਾ ਹੈ। ਆਉਟਪੁੱਟ ਦੇ ਸਿਖਰਲਾ ਬਲਾਕ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਹੀ ਹੋਵੇ ਜੋ ਕੁਏਰੀ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜੇ ਕੋਈ ਨਿੱਜੀ ਨਾਮ ਦਫ਼ਤਰ ਵਿੱਚ ਰਿਜ਼ੋਲਵ ਹੁੰਦਾ ਹੈ ਅਤੇ VPN ਉੱਠਦਿਆਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬੇਮੇਲ ਮਿਲਾਨ ਨਿਯਮਾਂ ਅਤੇ ਰੂਟਾਂ ਵਿੱਚ ਹੈ, ਸਰਵਰ ਪਤੇ ਵਿੱਚ ਨਹੀਂ। ਪਹਿਲਾਂ ਕ੍ਰਮ ਪੜ੍ਹੋ, ਫਿਰ ਅਸਲ ਲੁਕਅੱਪ ਨਾਲ ਜਵਾਬ ਸਾਬਤ ਕਰੋ।

ਪਤਿਆਂ ਤੋਂ ਪਹਿਲਾਂ ਬਲਾਕ ਕ੍ਰਮ ਪੜ੍ਹੋ

ਹਰ ਐਂਟਰੀ resolver #N ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ nameserver[0], ਕਦੇ if_index, flags ਲਾਈਨ, reach ਅਤੇ, ਜਦੋਂ ਬਲਾਕ ਸਾਧਾਰਨ ਡਿਫਾਲਟ ਨਹੀਂ ਹੁੰਦਾ, domain ਤੇ search domain ਸੂਚੀ ਦਿਖਾਉਂਦੀ ਹੈ। ਡੋਮੇਨ ਤੋਂ ਬਿਨਾਂ 1 ਨੰਬਰ ਦਾ ਰਿਜ਼ੋਲਵਰ ਉਹ ਡਿਫਾਲਟ ਹੈ ਜੋ ਜਨਤਕ ਨਾਮ ਸੰਭਾਲਦਾ ਹੈ। ਆਪਣੇ ਫਲੈਗਾਂ ਵਿੱਚ Scoped ਰੱਖਣ ਵਾਲਾ ਹਰ ਬਲਾਕ ਉਸ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਧਾ ਹੈ ਜਿਸਦਾ ਨਾਮ if_index ਦੱਸਦਾ ਹੈ, ਅਤੇ Supplemental ਨਾਲ ਚਿੰਨ੍ਹਿਤ ਹਰ ਚੀਜ਼ ਸਿਰਫ਼ ਉਸਦੇ ਹੇਠ ਸੂਚੀਬੱਧ ਡੋਮੇਨਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।

ਚੋਣ ਪ੍ਰਤਿਯ ਮਿਲਾਨ ਹੈ। intranet.corp.example ਵਰਗੇ ਨਾਮ ਲਈ, macOS ਉਸ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ domain ਐਂਟਰੀ ਸਭ ਤੋਂ ਲੰਬਾ ਮਿਲਦਾ ਪ੍ਰਤਿਯ ਹੈ, ਇਸ ਲਈ domain : corp.example ਵਾਲਾ ਬਲਾਕ ਆਉਟਪੁੱਟ ਵਿੱਚ ਬਹੁਤ ਹੇਠਾਂ ਹੋਣ 'ਤੇ ਵੀ ਡਿਫਾਲਟ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ। ਇੱਕੋ ਲੰਬਾਈ ਦੇ ਡੋਮੇਨਾਂ ਵਿੱਚੋਂ ਬਰਾਬਰੀ order ਤੋੜਦਾ ਹੈ। ਪਹਿਲੀ ਨਜ਼ਰ ਨੂੰ ਘੱਟ ਹੀ ਇਸ ਤੋਂ ਵੱਧ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਬਲਾਕ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਪੜ੍ਹਨਾ ਹੋਵੇ ਤਾਂ ਪੂਰੀ ਆਉਟਪੁੱਟ, ਬਲਾਕ ਕ੍ਰਮ ਜਾਣਨ ਲਈ ਸ਼ੁਰੂਆਤੀ ਲਾਈਨਾਂ, ਅਤੇ ਫੀਲਡ ਲਾਈਨਾਂ ਦੇ ਕੋਲ ਬਲਾਕ ਹੈਡਰ ਛਾਪਣ ਵਾਲਾ ਫਿਲਟਰ ਕੀਤਾ ਇੱਕ ਦੌਰ। ਸਕੋਪ ਕੀਤੇ ਬਲਾਕ ਆਪਣੇ ਹੈਡਿੰਗ ਹੇਠ ਦਿਖਦੇ ਹਨ ਅਤੇ ਉੱਪਰਲੀ ਸੂਚੀ ਦੀ ਨਿਰੰਤਰਤਾ ਵਾਂਗ ਪੜ੍ਹੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਆਉਟਪੁੱਟ ਦਾ ਹਵਾਲਾ ਦਿੰਦਿਆਂ ਹੈਡਿੰਗ ਨਜ਼ਰ ਵਿੱਚ ਰੱਖੋ।

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index ਨੂੰ ਟਨਲ ਇੰਟਰਫੇਸ ਨਾਲ ਮਿਲਾਓ

ਇੰਡੈਕਸ ਸਿਰਫ਼ ਤਦ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਉਸਦੇ ਪਿੱਛੇ ਦਾ ਇੰਟਰਫੇਸ ਦੱਸ ਸਕੋ। scutil --nwi ਸਿਸਟਮ ਕੋਲ ਮੌਜੂਦ ਨੈੱਟਵਰਕ ਜਾਣਕਾਰੀ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪ੍ਰਾਇਮਰੀ ਇੰਟਰਫੇਸ ਅਤੇ ਪਹੁੰਚ ਸ਼ਾਮਲ ਹੈ, ਜਦਕਿ ifconfig -l ਤੁਹਾਨੂੰ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਜਿੱਥੇ utun0 ਤੋਂ utun9 ਤੱਕ ਉਹ ਟਨਲ ਉਮੀਦਵਾਰ ਹਨ ਜੋ ਕਲਾਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਬਣਾਉਂਦਾ ਹੈ। Apple ਆਪਣੇ ਜਾਂਚ ਉਦਾਹਰਨ ਵਜੋਂ scutil --dns ਨੂੰ ਤੈਨਾਤੀ ਗਾਈਡ ਵਿੱਚ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਕਿ Network Extension ਚੁਣੇ ਡੋਮੇਨਾਂ ਨੂੰ ਚੁਣੇ ਰਿਜ਼ੋਲਵਰਾਂ ਤੱਕ ਕਿਵੇਂ ਭੇਜ ਸਕਦਾ ਹੈ; ਉਹ ਸਕੋਪ ਕੀਤੇ ਬਲਾਕ ਉਹੀ ਤੰਤਰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ।

ਸਵਾਲ ਦਾ ਫੈਸਲਾ ਕਰਨ ਵਾਲੀ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਰਿਜ਼ੋਲਵਰ ਟਨਲ ਵੱਲੋਂ ਲਾਈ ਗਈ ਰਾਹ 'ਤੇ ਹੈ ਕਿ ਨਹੀਂ:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

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

ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਤੋਂ ਪੁੱਛੋ, ਫਿਰ ਸਰਵਰ ਤੋਂ

ਤਿੰਨ ਸੰਦ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਇਸ ਖੇਤਰ ਦੇ ਬਹੁਤੇ ਗਲਤ ਸਿੱਟੇ ਪੈਦਾ ਹੁੰਦੇ ਹਨ। dscacheutil -q host -a name ਉਸੇ ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ ਜੋ ਆਮ ਐਪਾਂ ਵਰਤਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸਕੋਪ ਕੀਤੇ ਅਤੇ ਪੂਰਕ ਬਲਾਕ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ ਆਰਗਿਊਮੈਂਟ ਤੋਂ ਬਿਨਾਂ dig /etc/resolv.conf ਪੜ੍ਹਦਾ ਹੈ, ਜੋ macOS 'ਤੇ ਸਕੋਪ ਕੀਤੇ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਲਈ ਸੱਚ ਦਾ ਸਰੋਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਤੀ-ਡੋਮੇਨ ਨਿਯਮ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ। dig @address ਬਿਲਕੁਲ ਇੱਕ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਚੋਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ।

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

ਜਦੋਂ ਪਹਿਲਾ ਕਮਾਂਡ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਦੂਜਾ NXDOMAIN ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਵੰਡ ਲੱਭ ਲਈ ਹੈ ਜਿਸਦੀ ਭਾਲ ਕਰ ਰਹੇ ਸੀ ਅਤੇ ਕੁਝ ਵੀ ਟੁੱਟਾ ਨਹੀਂ ਹੈ। ਜਦੋਂ ਪਹਿਲਾ ਸਮਾਂ ਖ਼ਤਮ ਕਰਦਾ ਹੈ ਜਦਕਿ dig @10.20.0.53 ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਰਿਜ਼ੋਲਵਰ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਟਨਲ ਵੱਲੋਂ ਚੁਣੀ ਰਾਹ 'ਤੇ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਅਗਲਾ ਕਦਮ DNS ਸੈਟਿੰਗਾਂ ਬਦਲਣਾ ਨਹੀਂ ਸਗੋਂ route -n get ਹੈ। ਨਿੱਜੀ ਨਾਮ ਟਿਕਟ ਜਾਂ ਸਾਂਝੇ ਨੋਟ ਵਿੱਚ ਚਿਪਕਾਈ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

ਆਉਟਪੁੱਟ ਤੁਹਾਨੂੰ ਕੀ ਨਹੀਂ ਦਿਖਾ ਸਕਦੀ

ਰਿਜ਼ੋਲਵਰ ਸੂਚੀ ਦੇ ਉੱਪਰ ਜਾਂ ਕੋਲ ਕਈ ਪਰਤਾਂ ਬੈਠਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਕੁਏਰੀ ਉਸ ਥਾਂ ਭੇਜ ਸਕਦੀ ਹੈ ਜਿਸ ਦਾ ਆਉਟਪੁੱਟ ਕਦੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕਰਦੀ। ਸੁਰੱਖਿਅਤ DNS ਚਾਲੂ ਵਾਲਾ ਬਰਾਊਜ਼ਰ ਆਪਣੇ ਐਨਕ੍ਰਿਪਟਿਡ ਚੈਨਲ ਰਾਹੀਂ ਰਿਜ਼ੋਲਵ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ dscacheutil ਸਮਾਂ ਖ਼ਤਮ ਕਰਦਿਆਂ ਸਫ਼ਾ ਲੋਡ ਹੋਣਾ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ ਹੈ। ਸੁਰੱਖਿਆ ਸਾਫਟਵੇਅਰ ਵੱਲੋਂ ਲਾਇਆ DNS ਪ੍ਰੌਕਸੀ Network Extension ਪ੍ਰਦਾਤਾ ਵਜੋਂ ਚੱਲਦਾ ਹੈ ਅਤੇ ਕੁਏਰੀਆਂ ਖੁਦ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ, ਅਤੇ scutil --dns ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਕਨਫਿਗਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਨਾ ਕਿ ਉਹ ਅੱਪਸਟਰੀਮ ਪਤਾ ਜੋ ਪ੍ਰੌਕਸੀ ਨੇ ਅੰਤ ਵਿੱਚ ਵਰਤਿਆ। ਖੋਜ ਡੋਮੇਨ ਤੀਜਾ ਮੋੜ ਜੋੜਦੇ ਹਨ: ਅਯੋਗ ਨਾਮ ਨਾਲ ਸੂਚੀਬੱਧ ਹਰ ਪ੍ਰਤਿਯ ਕ੍ਰਮ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਇਸ ਲਈ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਬਲਾਕ ਉਹ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਕਦੇ ਸ਼ੱਕ ਨਹੀਂ ਕੀਤਾ।

ਪੁਰਾਣੇ ਜਵਾਬ ਬਾਹਰ ਕਰਨੇ ਸਭ ਤੋਂ ਸਸਤੇ ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਛੁੱਟਣ ਵਾਲੇ ਹਨ:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

ਜੇ ਫਲਸ਼ ਤੋਂ ਬਾਅਦ ਆਉਟਪੁੱਟ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਸਥਿਤੀ ਕੈਸ਼ ਵਿੱਚ ਸੀ ਅਤੇ ਪਿਛਲੀ ਆਉਟਪੁੱਟ ਉਸ ਟਨਲ ਦਾ ਵਰਣਨ ਕਰ ਰਹੀ ਸੀ ਜੋ ਹੁਣ ਨਹੀਂ ਸੀ। ਜੇ ਨਹੀਂ ਬਦਲਦੀ, ਤਾਂ ਕਨਫਿਗਰੇਸ਼ਨ ਜਿਵੇਂ ਹੈ ਤਿਵੇਂ ਹੈ, ਅਤੇ ਸਵਾਲ ਰੂਟਾਂ ਤੇ ਐਪ ਨੀਤੀ ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ।

ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਲਈ ਛੋਟੀ ਰਨਬੁੱਕ

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

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

ਫ਼ਰਕ ਨੂੰ ਲਾਈਨਾਂ ਦੀ ਬਜਾਏ ਬਲਾਕਾਂ ਅਨੁਸਾਰ ਪੜ੍ਹੋ। ਟਨਲ ਇੰਟਰਫੇਸ ਇੰਡੈਕਸ ਅਤੇ ਨਿੱਜੀ ਪ੍ਰਤਿਯ ਲਈ domain ਐਂਟਰੀ ਲੇ ਜਾਣ ਵਾਲਾ ਨਵਾਂ ਸਕੋਪ ਕੀਤਾ ਰਿਜ਼ੋਲਵਰ ਹੀ ਉਮੀਦ ਕੀਤਾ ਰੂਪ ਹੈ। ਜਨਤਕ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਨਵਾਂ ਡਿਫਾਲਟ ਰਿਜ਼ੋਲਵਰ ਇੱਕ ਖੋਜ ਹੈ ਜੋ ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਦੇ ਮਾਲਕ ਸਾਹਮਣੇ ਰੱਖਣ ਯੋਗ ਹੈ। ਫਿਰ ਲੁਕਅੱਪ ਉਸ ਐਪ ਅੰਦਰ ਦੁਹਰਾਓ ਜੋ ਸੱਚਮੁੱਚ ਫੇਲ੍ਹ ਹੋਇਆ ਸੀ, ਸਿਰਫ਼ ਸ਼ੈੱਲ ਵਿੱਚ ਨਹੀਂ, ਅਤੇ ਨਤੀਜੇ ਦੇ ਕੋਲ route -n get ਦਾ ਇੰਟਰਫੇਸ ਲਿਖੋ।

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

ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਚਾਰ ਜਾਂਚਾਂ: ਕੋਈ ਰਿਜ਼ੋਲਵਰ ਬਲਾਕ ਨਾਮ ਦੇ ਸਭ ਤੋਂ ਲੰਬੇ ਪ੍ਰਤਿਯ ਨਾਲ ਮਿਲਦਾ ਹੈ ਕਿ ਨਹੀਂ; ਉਹ ਬਲਾਕ ਟਨਲ ਵੱਲੋਂ ਲਾਏ ਇੰਟਰਫੇਸ ਨਾਲ ਬੱਧਾ ਹੈ ਕਿ ਨਹੀਂ; ਉਸਦੇ ਨਾਮ ਸਰਵਰ ਤੱਕ ਦੀ ਰਾਹ ਟਨਲ ਵਰਤਦੀ ਹੈ ਕਿ ਨਹੀਂ; ਅਤੇ dig ਨਹੀਂ, ਸਿਸਟਮ ਰਿਜ਼ੋਲਵਰ ਜਵਾਬ ਵਾਪਸ ਦਿੰਦਾ ਹੈ ਕਿ ਨਹੀਂ। ਪਹਿਲੀ ਫੇਲ੍ਹ ਜਾਂਚ ਦੱਸਦੀ ਹੈ ਕਿ DNS ਨੀਤੀ, ਟਨਲ ਰੂਟ ਜਾਂ ਐਪ ਬਦਲਣਾ ਹੈ। ਚਾਰੇ ਪਾਸ ਹੋਣ ਅਤੇ ਨਾਮ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਸਮੱਸਿਆ DNS ਤੋਂ ਉੱਪਰ ਹੈ, ਅਤੇ ਅੱਗੇ ਜਾਂਚਣ ਵਾਲੀ ਚੀਜ਼ ਉਹ ਹੈ ਜੋ ਇਸਦੇ ਸਾਮ੍ਹਣੇ ਪੋਰਟ 53 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।