ਨਿੱਜੀ DNS ਨਾਮ VPN ਕਲਾਇੰਟਾਂ ਉੱਤੇ ਕਿਉਂ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕਿੱਥੇ ਜਾਂਚਣਾ ਹੈ

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

ਕੋਈ ਵੀ ਪ੍ਰੋਫਾਈਲ ਸੰਪਾਦਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਨਾਮ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ। Linux ਵਿੱਚ resolvectl query files.corp.example ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਲਿੰਕ ਅਤੇ ਕਿਹੜੇ ਰਿਜ਼ਾਲਵਰ ਨੇ ਜਵਾਬ ਬਣਾਇਆ। Windows ਵਿੱਚ Resolve-DnsName files.corp.example ਉਹ ਸਰਵਰ ਦਿਖਾਉਂਦਾ ਹੈ ਜਿਸ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਉਹ ਪਤਾ ਜੋ ਉਸ ਨੇ ਵਾਪਸ ਕੀਤਾ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਪੜ੍ਹੋ

ਜੇ ਨਾਮ ਕੁਝ ਮਿਲੀਸਕਿੰਟਾਂ ਵਿੱਚ NXDOMAIN ਵਜੋਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਪ੍ਰਸ਼ਨ ਕਦੇ ਤੁਹਾਡੇ ਜ਼ੋਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ ਅਤੇ ਕਿਸੇ ਜਨਤਕ ਜਾਂ ਹੋਟਲ ਰਿਜ਼ਾਲਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। ਜੇ ਉਹ ਲੰਬੇ ਵਿਰਾਮ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਰਾਹ ਵਿੱਚ ਕੁਝ UDP ਪੋਰਟ 53 ਸੁੱਟ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਅਖੀਰ ਵਿੱਚ ਵਿਕਲਪ ਉੱਤੇ ਉੱਤਰ ਆਇਆ। ਜੇ ਸਹੀ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਪਰ ਕਨੈਕਸ਼ਨ ਫਿਰ ਵੀ ਅਟਕਦਾ ਹੈ, ਤਾਂ ਖੋਜ ਠੀਕ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਰੂਟਿੰਗ ਵਿੱਚ ਜਾਂ ਸੇਵਾ ਵਿੱਚ ਹੀ ਹੈ।

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

ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਟਨਲ ਦੇ ਅੰਦਰੋਂ ਵੰਡੋ

ਕਲਾਇੰਟ ਦੋ ਗਰੁੱਪਾਂ ਵਿੱਚ ਵੰਡੇ ਜਾਂਦੇ ਹਨ। ਇੱਕ ਨੂੰ ਸਰਵਰ ਕਨੈਕਸ਼ਨ ਬਣਦਿਆਂ ਰਿਜ਼ਾਲਵਰ ਦੇ ਸਕਦਾ ਹੈ; ਦੂਜਾ ਉਹ ਸੈਟਿੰਗ ਸਥਾਨਕ ਫਾਈਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਗੇਟਵੇ ਦੂਰੋਂ ਬਦਲ ਨਹੀਂ ਸਕਦਾ।

OpenVPN ਪਹਿਲੇ ਗਰੁੱਪ ਵਿੱਚ ਹੈ। ਸਰਵਰ ਉੱਤੇ push "dhcp-option DNS 10.8.0.53" ਅਤੇ push "dhcp-option DOMAIN corp.example" ਕੰਟਰੋਲ ਚੈਨਲ ਰਾਹੀਂ ਹੇਠਾਂ ਜਾਂਦੇ ਹਨ, ਪਰ ਤਦ ਹੀ ਜਦੋਂ ਕਲਾਇੰਟ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ pull ਅਜੇ ਵੀ ਸਰਗਰਮ ਹੋਵੇ। ਹੱਥ ਨਾਲ ਸੰਪਾਦਿਤ ਕਲਾਇੰਟ ਜੋ pull-filter ignore "dhcp-option" ਚੁੱਕਦਾ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਨਹੀਂ ਵੇਖੇਗਾ, ਅਤੇ ਇਹ ਇੱਕ ਲਾਈਨ ਹੈਰਾਨੀਜਨਕ ਤੌਰ ’ਤੇ ਬਹੁਤ ਸਾਰੇ ਉਨ੍ਹਾਂ ਕੇਸਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ ਕਿ «ਸਰਵਰ ਇਸ ਨੂੰ ਧੱਕਦਾ ਹੈ ਪਰ ਮੇਰਾ ਲੈਪਟਾਪ ਨਹੀਂ ਮੰਨਦਾ»।

WireGuard ਦੂਜੇ ਗਰੁੱਪ ਵਿੱਚ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਵਿਕਲਪਾਂ ਦੀ ਕੋਈ ਗੱਲਬਾਤ ਹੀ ਨਹੀਂ। ਰਿਜ਼ਾਲਵਰ ਅਤੇ ਖੋਜ ਡੋਮੇਨ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ [Interface] ਬਲਾਕ ਵਿੱਚ DNS = 10.8.0.53, corp.example ਵਜੋਂ ਜਾਂਦੇ ਹਨ। wg-quick ਇਸ ਨੂੰ resolvconf ਜਾਂ systemd-resolved ਰਾਹੀਂ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਅਤੇ Windows ਉੱਤੇ ਸਰਕਾਰੀ ਕਲਾਇੰਟ NRPT ਦੇ ਉਹ ਨਿਯਮ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਟਨਲ ਖੜ੍ਹੀ ਹੋਵੇ: Get-DnsClientNrptPolicy ਉਨ੍ਹਾਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਜੋ ਇਸ ਨੂੰ ਇਹ ਵੇਖਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਤੁਹਾਡੀ ਫਾਈਲ ਕਦੇ ਲਾਗੂ ਕੀਤੀ ਜਾਂ ਨਹੀਂ।

IPsec/IKEv2 ਵਿਚਕਾਰ ਹੈ। strongSwan ਦਾ attr ਪਲੱਗਇਨ ਖੂਹ ਵਿੱਚੋਂ ਕੱਢਿਆ DNS ਸਰਵਰ ਵਾਪਸ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ Windows ਕਲਾਇੰਟ ਆਮ ਤੌਰ ’ਤੇ ਇਸ ਨੂੰ ਮੰਨ ਲੈਂਦਾ ਹੈ, ਪਰ ਆਪਣਾ ਨਾਮ ਸਰਵਰ ਜਮਾ ਦੇਣ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ ਗੇਟਵੇ ਦੀ ਹਰ ਪੇਸ਼ਕਸ਼ ਉੱਤੇ ਭਾਰੀ ਪੈਂਦੀ ਹੈ। Linux ਕਲਾਇੰਟ ਉੱਤੇ ਬਰਾਬਰ ਦਾ ਹੱਥ ਦਾ ਕਦਮ resolvectl dns wg0 10.8.0.53 ਅਤੇ ਫਿਰ resolvectl domain wg0 '~corp.example' ਹੈ; ਦੋਵੇਂ ਇੰਟਰਫੇਸ ਦੇ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਜੋ ਟਨਲ ਤੱਕ ਸੀਮਤ ਸੈਟਿੰਗ ਲਈ ਠੀਕ ਉਹੀ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।

ਹਰ ਪ੍ਰਸ਼ਨ ਨਿਗਲਣ ਦੀ ਥਾਂ ਪਿਛੇਤਰ ਸੀਮਤ ਕਰੋ

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

ਅੰਦਰ ਸਿਰਫ਼ ਨਿੱਜੀ ਪਿਛੇਤਰ ਭੇਜੋ। systemd-resolved ਵਿੱਚ ~ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਡੋਮੇਨ ਸਿਰਫ਼ ਰੂਟਿੰਗ ਲਈ ਹੈ, ਇਸ ਲਈ ~corp.example ਦਾ ਅਰਥ ਹੈ ਕਿ ਉਸ ਪਿਛੇਤਰ ਹੇਠਲੇ ਪ੍ਰਸ਼ਨ ਉਸ ਲਿੰਕ ਦੇ ਸਰਵਰਾਂ ਨੂੰ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਕਿ ਬਾਕੀ ਸਭ ਭੌਤਿਕ ਨੈੱਟਵਰਕ ਵਰਤਦਾ ਰਹਿੰਦਾ ਹੈ। Windows ਇਹੀ ਕੰਮ ਨਾਮ-ਥਾਂ ਤੱਕ ਸੀਮਤ NRPT ਨਿਯਮਾਂ ਨਾਲ ਕਰਦਾ ਹੈ, ਅਤੇ macOS /etc/resolver/ ਹੇਠ ਇੱਕ ਵਾਧੂ ਰਿਜ਼ਾਲਵਰ ਫਾਈਲ ਨਾਲ।

ਮਲਟੀਕਾਸਟ ਨਾਮ ਆਪਣੇ ਜਵਾਬ ਦੇ ਹੱਕਦਾਰ ਹਨ। .local ਨਾਮ ਬਣਾਵਟ ਅਨੁਸਾਰ link-local ਹਨ (RFC 6762) ਅਤੇ ਬਿੰਦੂ-ਤੋਂ-ਬਿੰਦੂ tun ਇੰਟਰਫੇਸ ਉਹ ਮਲਟੀਕਾਸਟ ਗਰੁੱਪ ਨਹੀਂ ਢੋਂਦਾ, ਇਸ ਲਈ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਜੋੜਨਾ ਉਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰੇਗਾ ਅਤੇ ਅੰਦਰੂਨੀ unicast ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਉਨ੍ਹਾਂ ਬਾਰੇ ਪੁੱਛਣ ’ਤੇ NXDOMAIN ਵਾਪਸ ਆਉਂਦਾ ਹੈ। avahi ਵਰਗਾ ਪਰਾਵਰਤਕ ਪਰਾਵਰਤਨ ਮੋਡ ਵਿੱਚ ਦੋ ਖੰਡ ਜੋੜ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਸਰਵਰ ਪਾਸੇ ਦਾ ਫ਼ੈਸਲਾ ਹੈ ਜਿਸ ਦੀ ਮੰਗ ਕੋਈ ਕਲਾਇੰਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਜੇ ਪ੍ਰਿੰਟਰ ਜਾਂ NAS ਨਾਮ ਨਾਲ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਹੀ ਹੈ, ਤਾਂ ਇਸ ਦੀ ਥਾਂ ਆਪਣੇ ਜ਼ੋਨ ਵਿੱਚ ਉਸ ਨੂੰ A ਰਿਕਾਰਡ ਦਿਓ।

ਸਾਬਤ ਕਰੋ ਕਿ ਜਵਾਬ ਵਾਪਸ ਆ ਸਕਦਾ ਹੈ

ਅਪਹੁੰਚ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਹੀ ਜਵਾਬ ਬਿਲਕੁਲ ਰਿਜ਼ਾਲਵਰ ਦੀ ਸਮੱਸਿਆ ਵਰਗਾ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਰਾਹ ਨਹੀਂ ਜਾਂਚਦੇ। ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਜਵਾਬ ਕਿੱਥੇ ਜਾਵੇਗਾ: ip route get 10.20.5.20 ਇੰਟਰਫੇਸ ਅਤੇ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਗੱਲ ਇਹ ਕਿ ਉਹ ਵਰਤੇਗਾ ਸਰੋਤ ਪਤਾ ਦੱਸਦਾ ਹੈ।

ਰਿਜ਼ਾਲਵਰ ਦੇ ਪਤੇ ’ਤੇ ਹੀ ਨਜ਼ਰ ਰੱਖੋ। ਜਿਸ ਕਲਾਇੰਟ ਕੋਲ DNS = 10.8.0.53 ਦੇ ਨਾਲ AllowedIPs = 10.20.0.0/16 ਹੈ, ਉਹ ਆਪਣੇ ਪ੍ਰਸ਼ਨ ਭੌਤਿਕ NIC ਰਾਹੀਂ ਬਾਹਰ ਭੇਜਦਾ ਹੈ, ਜਿੱਥੇ ਉਹ ਚੁੱਪਚਾਪ ਮਰ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਰਿਜ਼ਾਲਵਰ ਟਨਲ ਦੇ ਦਾਅਵੇ ਵਾਲੇ ਕਿਸੇ ਵੀ ਪ੍ਰਿਫਿਕਸ ਅੰਦਰ ਨਹੀਂ ਹੈ। ਇਹ ਅਸੰਗਤੀ ਇਸ ਪੂਰੇ ਖੇਤਰ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਇੱਕ-ਕਾਰਨ ਫੇਲ੍ਹ ਹੋਣਾ ਹੈ, ਅਤੇ ਇਹ ਉਦੋਂ ਤੱਕ ਅਦਿੱਖ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ DNS ਸੈਟਿੰਗ ਦੀ ਮਨਜ਼ੂਰ ਪ੍ਰਿਫਿਕਸ ਨਾਲ ਲਾਈਨ-ਦਰ-ਲਾਈਨ ਤੁਲਨਾ ਨਾ ਕਰੋ।

ਓਵਰਲੈਪਿੰਗ ਰੇਂਜਾਂ ਉਲਟੀ ਫੇਲ੍ਹਤ ਲਿਆਉਂਦੀਆਂ ਹਨ। ਜਵਾਬ ਸਹੀ ਹੈ, ਰਾਹ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਇਹ ਗਲਤ ਮੇਜ਼ਬਾਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਘਰ ਵਿੱਚ 192.168.0.0/24 ਉਸੇ ਰੇਂਜ ਵੱਲ ਟਨਲ ਦੇ ਰਾਹ ਨਾਲੋਂ ਵਧੇਰੇ ਖਾਸ ਹੈ। ਇੱਕ ਪਾਸਾ ਮੁੜ-ਸੰਖਿਆਬੱਧ ਕਰੋ ਜਾਂ ਤੰਗ ਰਾਹ ਧੱਕੋ, ਫਿਰ ਸੇਵਾ ਮੇਜ਼ਬਾਨ ਦਾ ਫਾਇਰਵਾਲ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਪੁਸ਼ਟੀ ਕਰੋ; strongSwan ਦੀਆਂ ਅਗਰੇਸ਼ਣ ਬਾਰੇ ਟਿੱਪਣੀਆਂ ਉਸ ਰਾਹ ਦੇ sysctl ਪਾਸੇ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ।

ਸਰਟੀਫਿਕੇਟ ਇੱਕ ਵੱਖਰੀ ਪਛਾਣ ਜਾਂਚ ਹੈ ਜਿਸ ਦਾ ਦੋਸ਼ ਲੋਕ DNS ’ਤੇ ਪਾਉਂਦੇ ਹਨ। ਜੇ ਬ੍ਰਾਊਜ਼ਰ ਹੱਲ ਹੋਣ ਦੀ ਗਲਤੀ ਦੀ ਥਾਂ ਨਾਮ ਦੀ ਅਸੰਗਤੀ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਖੋਜ ਪਹਿਲਾਂ ਹੀ ਚੱਲ ਚੁੱਕੀ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦਾ SAN ਹੀ ਠੀਕ ਕਰਨ ਵਾਲੀ ਚੀਜ਼ ਹੈ। HTTPS ਨਾਮ ’ਤੇ ਜਾਂਚੋ, ਕਦੇ ਨੰਗੇ IP ’ਤੇ ਨਹੀਂ।

ਗੇਟਵੇ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਤੋਂ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਜਿਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਵਰਤੋਂਕਾਰ ਸ਼ਿਕਾਇਤ ਕਰਦਾ ਹੈ, ਉਸ ਦੇ ਅੰਦਰ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਕਮਾਂਡ ਲਾਈਨ ਦੀ ਖੋਜ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਵੀ ਉਹੀ ਰਾਹ ਲੈਂਦਾ ਹੈ। Chrome ਦਾ ਸੁਰੱਖਿਅਤ DNS ਅਤੇ Firefox ਦਾ network.trr.mode ਸਿਸਟਮ ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਜਦੋਂ ਉਹ ਇਹ ਕਰਦੇ ਹਨ ਤਾਂ ਨਿੱਜੀ ਨਾਮ ਜਾਂ ਤਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਾਂ ਕਿਸੇ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਰਿਸਦਾ ਹੈ। resolvectl query ਦੀ ਹੱਥ ਨਾਲ ਚਲਾਏ dig @10.8.0.53 files.corp.example ਨਾਲ ਤੁਲਨਾ ਦੱਸਦੀ ਹੈ ਕਿ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੀ ਹੋਇਆ।

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

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