ਟਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਆਖਰੀ ਕਦਮ ਆਮ ਤੌਰ 'ਤੇ ਬੁੱਕਮਾਰਕ ਵਿੱਚ ਚਿਪਕਾਏ ਪਤੇ ਦੀ ਥਾਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਾਮ ਹੁੰਦਾ ਹੈ। dnsmasq ਹੋਸਟ ਰਿਕਾਰਡ ਅਤੇ ਕਲਾਇੰਟ ਪਹੁੰਚ ਸਕਣ ਵਾਲਾ resolver ਪਤਾ ਦੋ ਫਾਈਲਾਂ ਵਿੱਚ ਅਤੇ multicast ਤੋਂ ਬਿਨਾਂ ਇਹ ਕਰਦੇ ਹਨ। ਜਿਸ ਫੈਸਲੇ 'ਤੇ ਸੱਚਮੁੱਚ ਸੋਚਣਾ ਪੈਂਦਾ ਹੈ ਉਹ ਹੋਰ ਸੰਕਰਾ ਹੈ: ਕਲਾਇੰਟ ਸਾਰਾ DNS ਘਰ ਦੇ resolver ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਜਾਂ ਸਿਰਫ਼ home.arpa ਦੇ ਹੇਠਲੇ ਨਾਮ? ਹੇਠਾਂ ਸਭ ਕੁਝ Linux ਕਲਾਇੰਟ ਅਤੇ ਘਰ ਦੇ ਪ੍ਰਬੰਧਕ ਵੱਲੋਂ ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲੇ ਜਾ ਰਹੇ ਲੈਬ resolver ਵਾਲੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ WireGuard ਸੈੱਟਅੱਪ ਨੂੰ ਮੰਨਦਾ ਹੈ।

ਕਲਾਇੰਟ ਨੂੰ resolver ਦੇਣ ਦੇ ਤਿੰਨ ਤਰੀਕੇ

ApproachScopeCost
DNS = in the wg-quick interfacethe client's general DNS while the tunnel is upevery name in the house now depends on the tunnel
Platform split-DNS for home.arpaonly that suffixmore configuration per client platform
Manual dig @resolverone query at a timefine for testing, useless for applications

ਕਦੇ-ਕਦਾਈਂ ਟਨਲ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਵਾਲੇ ਲੈਪਟਾਪ ਲਈ split-DNS ਬਿਹਤਰ ਡਿਫਾਲਟ ਹੈ: ਇਹ ਆਮ ਇੰਟਰਨੈੱਟ ਨਾਮ ਉਸ resolver 'ਤੇ ਰੱਖਦਾ ਹੈ ਜਿਸ 'ਤੇ ਮਸ਼ੀਨ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦੀ ਹੈ। ਜਿਹੜੀ ਮਸ਼ੀਨ ਘਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਹੈ, ਉਸ ਲਈ resolver ਪੁਸ਼ ਕਰਨਾ ਸੌਖਾ ਹੈ ਅਤੇ ਦਾਇਰੇ ਦੀ ਕੀਮਤ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦੀ।

ਜ਼ੋਨ ਦਾ ਮਾਲਕ resolver 'ਤੇ ਰਿਕਾਰਡ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ

ਕੌਂਫਿਗਰੇਸ਼ਨ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਭੂਮਿਕਾਵਾਂ ਵੱਖ ਰੱਖੋ: VPN ਕਲਾਇੰਟ ਪਤਾ, resolver ਅਤੇ ਸੇਵਾ ਤਿੰਨ ਵੱਖਰੇ ਕੰਮਾਂ ਵਾਲੇ ਤਿੰਨ ਵੱਖਰੇ ਹੋਸਟ ਹਨ। ਇਸ ਲੈਬ ਵਿੱਚ ਉਹ ਕਲਾਇੰਟ ਲਈ 10.77.0.2, dnsmasq ਲਈ 192.168.50.53 ਅਤੇ NAS ਲਈ 192.168.50.20 ਹਨ, ਅਤੇ ਟਨਲ ਘਰ ਦੀ LAN ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ।

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

host-record ਲਾਈਨ ਪਤਾ ਦਿੰਦੀ ਹੈ ਅਤੇ local= ਲਾਈਨ ਅਣਜਾਣ home.arpa ਸਵਾਲਾਂ ਨੂੰ ਉੱਪਰ ਭੇਜਣ ਦੀ ਥਾਂ ਇਸ resolver ਦੇ ਅੰਦਰ ਰੱਖਦੀ ਹੈ। ਪਹਿਲਾਂ ਆਪਣੀ ਮੌਜੂਦਾ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹੋ ਅਤੇ ਜੋ ਪਹਿਲਾਂ ਹੀ ਸਰਵਰ, ਇੰਟਰਫੇਸ ਜਾਂ ਉਹੀ ਸਥਾਨਕ ਡੋਮੇਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਉਸ ਨਾਲ ਮਿਲਾਓ; ਵਿਰੋਧਾਭਾਸੀ ਉੱਤੇ ਟੁਕੜਾ ਚੜ੍ਹਾਉਣ ਨਾਲ ਅਜਿਹਾ resolver ਬਣਦਾ ਹੈ ਜੋ ਖੁਸ਼ੀ ਨਾਲ ਲੋਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗਲਤ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। dnsmasq ਮੈਨੂਅਲ ਦੋਵੇਂ ਨਿਰਦੇਸ਼ ਅਤੇ ਸੁਣਨ ਦੇ ਨਿਯੰਤਰਣ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ।

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

resolver ਨੂੰ ਰੂਟ ਕਰੋ, ਸਿਰਫ਼ ਵੈੱਬ ਪੇਜ ਨਹੀਂ

WireGuard ਦਾ AllowedIPs ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਮੰਜ਼ਿਲਾਂ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ resolver ਪਤਾ ਉਸ ਤੋਂ ਬਾਹਰ ਪੈਂਦਾ ਹੈ, ਕਵੈਰੀ ਆਮ ਮਾਰਗ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਅਤੇ dnsmasq ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਭਾਵੇਂ NAS ਆਪਣੇ ਆਪ ਪਹੁੰਚਯੋਗ ਹੋਵੇ। resolver ਦਾ ਪਤਾ ਜਾਂ ਉਸ ਨੂੰ ਸਮੇਟਣ ਵਾਲਾ LAN ਅਗੇਤਰ ਸ਼ਾਮਲ ਕਰੋ, ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਗੇਟਵੇ ਦੀ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ ਜਾਂਚੋ।

ਅਧਿਕਾਰਤ ਟਨਲ ਰੇਂਜ ਤੋਂ ਪੋਰਟ 53 'ਤੇ UDP ਅਤੇ TCP ਦੀ ਆਗਿਆ ਦਿਓ, ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਪਤੇ ਤੱਕ ਵਾਪਸੀ ਮਾਰਗ ਸਮੇਤ। ਟੈਸਟ ਸੌਖਾ ਕਰਨ ਲਈ WAN ਤੋਂ ਪੋਰਟ 53 ਫਾਰਵਰਡ ਨਾ ਕਰੋ: ਘਰ ਦੇ ਕਨੈਕਸ਼ਨ 'ਤੇ ਖੁੱਲ੍ਹਾ ਰਿਕਰਸਿਵ resolver ਘੰਟਿਆਂ ਵਿੱਚ ਲੱਭ ਜਾਂਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਨਾਲ ਬੰਨ੍ਹਣਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਪਹੁੰਚ ਨੀਤੀ ਨਹੀਂ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਜਾਂਚੋ

ਪਹਿਲਾਂ ਸਿੱਧਾ resolver ਨੂੰ ਪੁੱਛੋ, ਫਿਰ ਸਿਸਟਮ ਨੂੰ, ਫਿਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ। ਹਰ ਕਦਮ ਚੇਨ ਦੀ ਇੱਕ ਕੜੀ ਅਲੱਗ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੀ ਨਿਦਾਨ ਹੈ।

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

TCP ਕਵੈਰੀ ਚਲਾਉਣਾ ਲਾਹੇਵੰਦ ਹੈ, ਕਿਉਂਕਿ ਕਟਿਆ UDP ਜਵਾਬ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਅਤੇ TCP 53 ਸੁੱਟਣ ਵਾਲੀ ਨੀਤੀ ਰੁਕ-ਰੁਕ ਕੇ ਦਿਖਣ ਵਾਲੀਆਂ ਅਸਫਲਤਾਵਾਂ ਪੈਦਾ ਕਰਦੀ ਹੈ। getent ਕਦਮ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਮਸ਼ੀਨ ਦੀ resolver ਕੌਂਫਿਗਰੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦੀ ਹੈ, ਜੋ ਹਮੇਸ਼ਾ ਤੁਸੀਂ ਭੇਜਿਆ ਹੀ ਨਹੀਂ ਹੁੰਦਾ।

ਟਨਲ ਬੰਦ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਤੈਅ ਕਰੋ

ਜੇ ਕਲਾਇੰਟ ਦਾ ਆਮ DNS 192.168.50.53 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਟਨਲ ਉੱਪਰ ਨਾ ਹੋਣ 'ਤੇ ਹਰ ਨਾਮ ਵਿਸ਼ਲੇਸ਼ਣ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਅਜਿਹੀ ਮਸ਼ੀਨ 'ਤੇ ਸਵੀਕਾਰਯੋਗ ਹੈ ਜੋ ਸਿਰਫ਼ ਟਨਲ ਨਾਲ ਲਾਹੇਵੰਦ ਹੈ, ਅਤੇ ਕੈਫੇ ਦੀ Wi-Fi ਵੀ ਵਰਤਣ ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ ਅਸਵੀਕਾਰਯੋਗ ਹੈ। Split-DNS ਇਸ ਸਵਾਲ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਾਲ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਿਰਫ਼ home.arpa ਖੋਜਾਂ ਘਰ ਦੇ resolver 'ਤੇ ਨਿਰਭਰ ਹਨ।

ਯਾਦ ਰੱਖੋ ਨਾਮ ਕੀ ਹੈ: home.arpa ਰਿਹਾਇਸ਼ੀ ਨੈੱਟਵਰਕਾਂ ਲਈ ਰਾਖਵਾਂ ਹੈ ਅਤੇ ਵਿਸ਼ਵ ਪੱਧਰ 'ਤੇ ਯੂਨੀਕ ਨਹੀਂ, ਇਸ ਲਈ ਦੂਜਾ ਨੈੱਟਵਰਕ ਉਹੀ ਨਾਮ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਵਰਤ ਸਕਦਾ ਹੈ। ਇਹ ਸਥਾਨਕ ਸਹੂਲਤ ਹੈ, ਭਰੋਸੇਯੋਗ ਪਛਾਣਕਰਤਾ ਨਹੀਂ। ਸੇਵਾ ਬਦਲਣ 'ਤੇ ਰਿਕਾਰਡ ਨਵੀਨਤਮ ਰੱਖੋ, ਅਤੇ ਲੈਬ ਰਿਟਾਇਰ ਹੋਣ 'ਤੇ resolver ਨੀਤੀ ਹਟਾ ਦਿਓ, ਹੁਣ ਨਾ ਰਹਿੰਦੀ ਟਨਲ ਰਾਹੀਂ ਹੀ ਪਹੁੰਚਯੋਗ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਲੈਪਟਾਪ ਛੱਡਣ ਦੀ ਥਾਂ।

ਸੰਬੰਧਿਤ ਲੇਖ