OpenVPN ਵੱਲੋਂ ਧੱਕਿਆ DNS ਅਣਡਿੱਠਾ: ਕਿਹੜਾ ਹਿੱਸਾ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ

ਲੌਗ ਸਰਵਰ ਵੱਲੋਂ ਧੱਕਿਆ ਵਿਕਲਪ ਦਿਖਾਉਂਦਾ ਹੈ, ਟਨਲ ਚਾਲੂ ਹੈ, ਅਤੇ ਅੰਦਰੂਨੀ ਨਾਮ ਅਜੇ ਵੀ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਸਿੱਧੀ ਕਵੈਰੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਭਾਵ ਸਰਵਰ ਠੀਕ ਹੈ, ਪਰ ਹਰ ਐਪਲੀਕੇਸ਼ਨ ਸਥਾਨਕ ਰਾਊਟਰ ਨੂੰ ਪੁੱਛਦੀ ਰਹਿੰਦੀ ਹੈ। ਕਲਾਇੰਟ ਤੱਕ ਜੋ ਪਹੁੰਚਿਆ ਉਹ ਪੇਸ਼ਕਸ਼ ਹੈ, ਰਿਜ਼ੋਲਵਰ ਵਿੱਚ ਤਬਦੀਲੀ ਨਹੀਂ, ਅਤੇ ਨਾਮ-ਹੱਲ ਦਾ ਮਾਲਕ ਹਿੱਸਾ Linux, Windows ਅਤੇ macOS ਉੱਤੇ ਵੱਖਰਾ ਹੈ। ਜਿਵੇਂ ਹੀ ਤੁਸੀਂ ਵਿਕਲਪ ਨੂੰ ਉਸਦੇ ਮਾਲਕ ਤੋਂ ਵੱਖ ਕਰਦੇ ਹੋ, ਚਾਰ ਨੁਕਸ ਲਗਭਗ ਹਰ ਰਿਪੋਰਟ ਨੂੰ ਢਕ ਲੈਂਦੇ ਹਨ: ਹੁੱਕ ਨਹੀਂ, ਦੋ ਮੁਕਾਬਲੇ ਵਾਲੇ ਹੁੱਕ, ਵੰਡਿਆ DNS ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਾਂ ਛੋਟਾ ਨਾਮ ਜਿਸਨੂੰ ਸਰਵਰ ਨਹੀਂ ਸਫਿਕਸ ਚਾਹੀਦਾ ਹੈ।

ਧੱਕਿਆ ਵਿਕਲਪ ਪੇਸ਼ਕਸ਼ ਹੈ, ਸਥਾਪਨਾ ਨਹੀਂ

ਸਰਵਰ ਉੱਤੇ ਦੋ ਹਦਾਇਤਾਂ ਪ੍ਰਭਾਵ ਨਹੀਂ, ਇਰਾਦਾ ਦੱਸਦੀਆਂ ਹਨ:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

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

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

ਪੱਕਾ ਕਰੋ ਕਿ ਧੱਕਾ ਪਹੁੰਚਿਆ ਅਤੇ ਮਾਲਕ ਲੱਭੋ

ਸ਼ੁਰੂਆਤ ਲਾਂਚਰ ਦਾ ਨਾਮ ਲੈ ਕੇ ਕਰੋ: ਇੱਕ ਨੰਗੀ openvpn ਕਮਾਂਡ, systemd ਇੰਸਟੈਂਸ, NetworkManager ਜਾਂ ਵਿਕਰੇਤਾ ਕਲਾਇੰਟ। ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹੁੱਕ ਕਿੱਥੇ ਰਹਿ ਸਕਦਾ ਹੈ। systemd-resolved ਵਾਲੇ ਹੋਸਟ ਉੱਤੇ, resolvectl status ਹਰ ਲਿੰਕ ਨੂੰ ਉਸਦੇ ਅਸਲ ਵਰਤੇ DNS ਸਰਵਰਾਂ ਅਤੇ ਖੋਜ ਡੋਮੇਨਾਂ ਸਮੇਤ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਲਿੰਕ ਦਾ ਨਾਮ ਹਮੇਸ਼ਾ tun0 ਨਹੀਂ ਹੁੰਦਾ।

ਜੇ ਧੱਕਿਆ ਪਤਾ ਲੌਗ ਵਿੱਚ ਦਿਸਦਾ ਹੈ ਪਰ ਕਿਸੇ ਲਿੰਕ ਉੱਤੇ ਨਹੀਂ, ਤਾਂ ਏਕੀਕਰਨ ਨਹੀਂ ਹੈ। ਜੇ ਉਹ ਲਿੰਕ ਉੱਤੇ ਹੈ ਅਤੇ ਕਵੈਰੀਆਂ ਅਜੇ ਵੀ ਹੋਰ ਕਿਤੇ ਜਾਂਦੀਆਂ ਹਨ, ਸਮੱਸਿਆ ਇਹ ਹੈ, ਕਿਹੜੀਆਂ ਕਵੈਰੀਆਂ ਉਸ ਲਿੰਕ ਨੂੰ ਚੁਣਦੀਆਂ ਹਨ। NetworkManager dns=dnsmasq ਫਾਈਲ ਵਿੱਚ /etc/NetworkManager/NetworkManager.conf ਸਥਾਨਕ ਫਾਰਵਰਡਰ ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਵੰਡਿਆ DNS ਜਾਣ-ਬੁੱਝ ਕੇ ਲਾਗੂ ਕਰਦਾ ਹੈ: VPN ਡੋਮੇਨ ਅੰਦਰ ਦੇ ਨਾਮ VPN ਰਿਜ਼ੋਲਵਰ ਕੋਲ ਜਾਂਦੇ ਹਨ, ਬਾਕੀ ਸਭ ਆਪਣਾ ਪਿਛਲਾ ਰਾਹ ਰੱਖਦਾ ਹੈ। ਸਾਰਾ ਟ੍ਰੈਫਿਕ ਹਿਲਣ ਦੀ ਉਮੀਦ ਹੋਣ ਵੇਲੇ ਇਹ ਵਿਵਹਾਰ ਨੁਕਸ ਵਰਗਾ ਲੱਗਦਾ ਹੈ; ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਸੈਟਿੰਗਾਂ ਜਾਂਚੋ nmcli connection show "My VPN" ਨਾਲ, ਜਿੱਥੇ ipv4.dns ਅਤੇ ipv4.dns-search ਡਿਵਾਈਸ ਵੱਲੋਂ ਦੱਸੇ ਗਏ ਪਿੱਛੇ ਦੇ ਮੁੱਲ ਰੱਖਦੇ ਹਨ, ਇਸਨੂੰ ਟੁੱਟਿਆ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ। ਜੇ ਹਰ ਕਵੈਰੀ ਸੱਚਮੁੱਚ VPN ਰਿਜ਼ੋਲਵਰ ਤੱਕ ਪਹੁੰਚਣੀ ਚਾਹੀਦੀ ਹੈ, ਹਟਾਓ dns=dnsmasq ਨੂੰ NetworkManager.conf ਫਾਈਲ ਤੋਂ ਅਤੇ NetworkManager ਮੁੜ ਚਾਲੂ ਕਰੋ, ਜੋ ਨਾਮ-ਹੱਲ ਕਨੈਕਸ਼ਨ ਸੈਟਿੰਗਾਂ ਨੂੰ ਵਾਪਸ ਦਿੰਦਾ ਹੈ; ਨਹੀਂ ਤਾਂ ਵੰਡਿਆ DNS ਰੱਖੋ ਅਤੇ ਧੱਕੀ ਡੋਮੇਨ ਸੂਚੀ ਸੁਧਾਰੋ।

Linux: ਵਿਕਲਪ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਦਿਓ

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

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved ਨਾਲ ਪੁਰਾਣੀ resolv.conf ਸਕ੍ਰਿਪਟ ਕੁਝ ਵੀ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਬਦਲ ਸਕਦੀ, ਕਿਉਂਕਿ stub ਰਿਜ਼ੋਲਵਰ ਪ੍ਰਤੀ ਲਿੰਕ ਹਾਲਤ ਰੱਖਦਾ ਹੈ। update-systemd-resolved ਸਹਾਇਕ ਅਜਿਹੇ ਹੁੱਕ ਰੂਪ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਜੋ up-restart ਅਤੇ down-pre ਵਰਤਦਾ ਹੈ, ਜੋ ਤਦ ਮਹੱਤਵ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਇੰਟਰਫ਼ੇਸ ਇੱਕ ਕਨੈਕਸ਼ਨ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਵੱਧ ਰਹਿੰਦਾ ਹੈ। ਜੋ ਵੀ ਚੁਣੋ, ਹਾਲਤ ਦੀ ਮਾਲਕੀ ਇੱਕ ਹਿੱਸੇ ਕੋਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। NetworkManager ਦੇ ਕੋਲ ਅਸੰਬੰਧਿਤ ਹੁੱਕ ਜੋੜਨ ਨਾਲ ਉਸੇ ਲਿੰਕ ਨੂੰ ਦੋ ਲੇਖਕ ਮਿਲਦੇ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਤਦ ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਦੀ ਥਾਂ ਕ੍ਰਮ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

Windows ਅਤੇ macOS ਵੱਖਰੇ ਹਿੱਸੇ ਲਾਗੂ ਕਰਦੇ ਹਨ

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

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

ਜੇ ਪਤਾ ਨਹੀਂ ਹੈ, ਇਸ ਨਾਲ ਸੈੱਟ ਕਰੋ Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, ਫਿਰ ਸਫਿਕਸ ਅਡੈਪਟਰ ਦੀਆਂ IPv4 ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚ ਜੋੜੋ ਤਾਂ ਜੋ fileserver ਬਣ ਜਾਵੇ fileserver.corp.example। ਮਸ਼ੀਨ-ਵਿਆਪੀ SearchList ਮੁੱਲ Tcpip\Parameters ਅਧੀਨ ਉਹੀ ਕਰਦਾ ਹੈ। ਜਿੱਥੇ ਲੰਮਾ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਨੰਗਾ ਨਹੀਂ, ਉੱਥੇ ਰਿਜ਼ੋਲਵਰ ਪਹਿਲਾਂ ਹੀ ਸਹੀ ਹੈ ਅਤੇ ਦੋਸ਼ ਖੋਜ ਸੂਚੀ ਦਾ ਹੈ। ਸੁਧਾਰ ਕ੍ਰਮ ਵਿੱਚ: ਧੱਕੋ DOMAIN ਕਲਾਇੰਟ ਨੇ ਸਫਿਕਸ ਸਿੱਖਣ ਲਈ, ਉਹ ਸਫਿਕਸ ਅਡੈਪਟਰ ਜਾਂ ਕਨੈਕਸ਼ਨ ਦੀ ਖੋਜ ਸੂਚੀ ਵਿੱਚ ਜੋੜੋ, ਅਤੇ ਅਸਥਾਈ ਉਪਾਅ ਵਜੋਂ ਨਾਮ ਇੱਥੇ ਸਥਿਰ ਕਰੋ hosts ਫਾਈਲ ਵਿੱਚ, ਜਾਂ LMHOSTS ਵਿੱਚ Windows ਉੱਤੇ; NetBIOS ਬਰਾਊਜ਼ਿੰਗ ਰਾਊਟਰ ਪਾਰ ਨਹੀਂ ਕਰਦੀ, ਇਸੇ ਲਈ ਦਫ਼ਤਰ LAN ਉੱਤੇ ਛੋਟਾ ਨਾਮ ਲੱਭਣ ਵਾਲਾ ਪ੍ਰਸਾਰਣ ਕਦੇ ਟਨਲ ਕਲਾਇੰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ।

block-outside-dns block-outside-dns Windows ਕਲਾਇੰਟ ਦਾ ਵਿਵਹਾਰ ਹੈ, ਪੋਰਟੇਬਲ ਪਰੋਫਾਈਲ ਲਾਈਨ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ Linux ਜਾਂ macOS ਪਰੋਫਾਈਲ ਵਿੱਚ ਕਾਪੀ ਕਰਨ ਨਾਲ ਉੱਥੇ ਮੁੜ ਨਹੀਂ ਬਣਦਾ। ਜੇ Windows ਉੱਤੇ ਜਨਤਕ ਨਾਮ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਅੰਦਰੂਨੀ ਫੇਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਉੱਨਤ ਸੈਟਿੰਗਾਂ ਅਧੀਨ ਅਡੈਪਟਰ ਕ੍ਰਮ ਦੀ ਤੁਲਨਾ ਕਰੋ ipconfig /all ਨਾਲ। macOS ਉੱਤੇ ਪ੍ਰਤੀ-ਸੇਵਾ ਰਿਜ਼ੋਲਵਰ ਕ੍ਰਮ ਸਿਸਟਮ ਦਾ ਹੈ, ਇਸ ਲਈ ਵਰਤੋ scutil --dns ਇਹ ਵੇਖਣ ਲਈ ਕਿ ਕਿਹੜੇ ਡੋਮੇਨ ਲਈ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਦੱਸੇ ਗਏ ਕਿਸੇ ਵੀ ਇੱਕਲੇ ਪਰੋਫਾਈਲ ਸੁਧਾਰ ਨੂੰ ਆਮ ਨਹੀਂ, ਕਲਾਇੰਟ-ਨਿਰਭਰ ਮੰਨੋ।

ਉਸੇ ਲੈਪਟਾਪ ਉੱਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਇਸ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਦਾ। ਮਹਿਮਾਨ ਨੂੰ ਅੰਦਰੂਨੀ ਡੋਮੇਨ ਲਈ ਆਪਣੀ ਰਿਜ਼ੋਲਵਰ ਐਂਟਰੀ ਦਿਓ, ਜਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇ NAT ਨੂੰ ਇਸਦੀਆਂ ਕਵੈਰੀਆਂ ਹੋਸਟ ਰਾਹੀਂ ਭੇਜਣ ਦਿਓ, ਜੋ ਸਿਰਫ਼ ਤਦ ਸਹੀ ਹੈ ਜਦੋਂ ਹੋਸਟ ਦਾ ਟਨਲ ਚਾਲੂ ਹੈ।

ਇਤਿਹਾਸ ਤੀਜਾ ਕਾਰਨ ਹੈ। ਪਿਛਲੇ ਪਰੋਫਾਈਲ ਦੇ DNS ਸਰਵਰ ਜਾਂ ਸਫਿਕਸ ਸੈਟਿੰਗਾਂ ਮੁੜ-ਜੁੜਨ ਉੱਤੇ ਟਿਕ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਜਦੋਂ ਅਡੈਪਟਰ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਖੋਜ ਅਜੇ ਵੀ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਜੀਵਤ ਅਡੈਪਟਰ ਦੀ ਤੁਲਨਾ ਕਰੋ Get-VpnConnection ਨਾਲ ਅਤੇ ਸਰਵਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣੀ ਐਂਟਰੀ ਮਿਟਾਓ ਜਾਂ ਮੁੜ ਲਿਖੋ।

ਕਵੈਰੀ ਕਿੱਥੇ ਗਈ ਇਹ ਸਿੱਧ ਕਰੋ

ਇੱਕ ਖੋਜ ਦੌਰਾਨ ਕੈਪਚਰ ਬਹਿਸ ਖ਼ਤਮ ਕਰਦਾ ਹੈ: tcpdump -ni eth0 port 53 ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਕਵੈਰੀਆਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਭਾਵ ਉਹ ਟਨਲ ਤੋਂ ਬਾਹਰ ਜਾ ਰਹੀਆਂ ਹਨ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਕਦੇ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ। dig @10.8.0.1 name.corp.example ਫਿਰ ਬਾਕੀ ਦੋ ਮਾਮਲੇ ਵੱਖ ਕਰਦਾ ਹੈ। ਜੇ ਸਿੱਧੀ ਕਵੈਰੀ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਰਿਜ਼ੋਲਵਰ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਇਸਨੂੰ ਵਰਤ ਨਹੀਂ ਰਿਹਾ; ਜੇ ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ, ਰਿਜ਼ੋਲਵਰ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ ਅਤੇ ਕੋਈ ਸਥਾਨਕ ਤਬਦੀਲੀ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।

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

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

ਇੱਕ ਮਾਲਕ ਰੱਖੋ ਅਤੇ ਕ੍ਰਮ ਵਿੱਚ ਪਰਖੋ

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

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