ਗੇਟਵੇ 'ਤੇ OpenVPN DNS: dnsmasq ਅਤੇ ਫਾਇਰਵਾਲ ਦਾ ਘੇਰਾ

ਟਨਲ ਪਤੇ 'ਤੇ dnsmasq ਚਲਾਓ, ਸਿਰਫ਼ ਕਲਾਇੰਟ ਪੂਲ ਤੋਂ DNS ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਰਿਜ਼ੌਲਵਰ ਪੁਸ਼ ਕਰੋ, ਅਤੇ ਫਿਰ ਸਿੱਧੀਆਂ ਕੁਐਰੀਆਂ ਤੇ ਐਪ ਦੀ ਆਪਣੀ ਖੋਜ ਜਾਂਚੋ।

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

ਸੁਣਨ ਵਾਲਾ ਦੋ ਦਿਸ਼ਾਵਾਂ ਵਾਲੀ ਸਥਾਨਕ ਸੇਵਾ ਹੈ

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

ਕਲਾਇੰਟ ਵੱਲੋਂ ਦੱਸਿਆ ਟਾਈਮਆਊਟ ਅਤੇ ਗੇਟਵੇ 'ਤੇ ਦਿਸਣ ਵਾਲਾ ਟਾਈਮਆਊਟ ਇੱਕੋ ਖਰਾਬੀ ਨਹੀਂ ਹਨ।

ਟਨਲ ਪਤਾ ਬੰਨ੍ਹੋ, ਹਰ ਪਤਾ ਨਹੀਂ

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

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic ਵੱਖਰੇ ਪਤਿਆਂ ਨੂੰ ਬੰਨ੍ਹਦਾ ਹੈ ਅਤੇ tun0 ਬਾਅਦ ਵਿੱਚ ਦਿਸਣ 'ਤੇ ਸੰਭਾਲਦਾ ਹੈ, ਜੋ ਉਸ ਹੋਸਟ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜਿੱਥੇ VPN ਸੇਵਾ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। loopback ਦੀ ਸੂਚੀ ਰੱਖਣਾ ਜਨਤਕ ਸੁਣਨ ਵਾਲਾ ਜੋੜੇ ਬਿਨਾਂ ਸਥਾਨਕ ਟੂਲ ਚਾਲੂ ਰੱਖਦਾ ਹੈ। no-resolv ਡੈਮਨ ਨੂੰ ਹੋਸਟ ਦੀ ਰਿਜ਼ੌਲਵਰ ਸੰਰਚਨਾ ਤੋਂ ਅਪਸਟ੍ਰੀਮ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ no-hosts ਇਸ ਇੰਸਟੈਂਸ ਨੂੰ ਗੇਟਵੇ ਦੀ hosts ਫਾਈਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹਨਾਂ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਿਸੇ ਨੂੰ ਸੇਵਾ ਦੀ ਕੁਐਰੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ।

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

DNS ਇਨਪੁਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਟਨਲ ਟ੍ਰਾਂਜ਼ਿਟ ਦੀ ਨਹੀਂ

ਇਸਨੂੰ ਕੰਮ ਕਰਾਉਣ ਵਾਲੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਥਾਨਕ-ਇਨਪੁਟ ਨਿਯਮ ਹਨ, ਟਨਲ ਇੰਟਰਫ਼ੇਸ, ਕਲਾਇੰਟ ਪੂਲ, ਗੇਟਵੇ ਪਤਾ ਅਤੇ ਪੋਰਟ 53 ਤੱਕ ਸੀਮਿਤ। ਦੋ ਨਿਯਮ, ਹਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਇੱਕ, ਕਾਫ਼ੀ ਹਨ:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS UDP ਦੇ ਨਾਲ TCP 'ਤੇ ਵੀ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ UDP ਵਾਲਾ ਨਿਯਮ ਵੱਡੇ ਜਵਾਬਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੋਣ ਦਿੰਦਾ ਹੈ ਜੋ ਰੁਕ-ਰੁਕ ਕੇ ਲੱਗਦਾ ਹੈ। ਇਹ ufw route ਇਜਾਜ਼ਤਾਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ tun0 'ਤੇ ਵਿਆਪਕ ਇਜਾਜ਼ਤ ਨਹੀਂ ਬਣਨਾ ਚਾਹੀਦਾ। ਕ੍ਰਮ ਦਾ ਮਹੱਤਵ ਸਮੱਗਰੀ ਜਿੰਨਾ ਹੀ ਹੈ: tun0 ਤੋਂ ਸਾਰਾ ਇਨਪੁਟ ਸੁੱਟਣ ਵਾਲਾ ਪੁਰਾਣਾ ਨਿਯਮ ਫਿਰ ਵੀ ਜਿੱਤਦਾ ਹੈ, ਅਤੇ ਅੰਤਿਮ ਡ੍ਰਾਪ ਹੇਠਾਂ ਇਜਾਜ਼ਤ ਜੋੜਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਣਦਾ।

ਜੇ ਗੇਟਵੇ DNS ਹੁਣ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੈ, ਤਾਂ ਉਸ ਪੁਰਾਣੀ ਨੀਤੀ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਸੋਧੋ ਅਤੇ ਕਾਰਨ ਦਰਜ ਕਰੋ।

ਅਪਸਟ੍ਰੀਮ ਅੱਧਾ ਹਿੱਸਾ ਵੱਖਰਾ ਰਾਹ ਹੈ

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

ਜਵਾਬਾਂ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਅਸੀਮਤ ਟਨਲ ਆਉਟਪੁਟ ਨਾ ਜੋੜੋ; ਟਰੈਕ ਕੀਤੇ ਜਵਾਬਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਵਿਕਲਪ ਪੁਸ਼ ਕਰੋ, ਫਿਰ ਹੈਂਡਆਫ਼ ਜਾਂਚੋ

ਸਰਵਰ ਪੁਸ਼ ਕੀਤੇ ਵਿਕਲਪ ਨਾਲ ਕਲਾਇੰਟਾਂ ਨੂੰ ਰਿਜ਼ੌਲਵਰ ਦੀ ਘੋਸ਼ਣਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਵਿਕਲਪ ਹੈ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਮੰਨਣਾ ਪਵੇ ਐਸਾ ਨਿਰਦੇਸ਼ ਨਹੀਂ:

push "dhcp-option DNS 10.90.0.1"

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

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

ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਣਾਇਆ ਹੈ ਉਸਦੀ ਜਾਂਚ ਕਰੋ

ਇੱਕ ਨਿੱਜੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਅਤੇ ਇੱਕ ਮਨਜ਼ੂਰ ਬਾਹਰੀ ਨਾਮ ਸਿੱਧਾ ਟਨਲ ਪਤੇ ਦੇ ਸਾਮ੍ਹਣੇ, UDP ਅਤੇ TCP ਦੋਵਾਂ 'ਤੇ ਕੁਐਰੀ ਕਰੋ। ਫਿਰ ਐਪ ਦੇ ਆਮ ਖੋਜ ਰਾਹ ਰਾਹੀਂ ਦੁਹਰਾਓ।

ਜੇ ਸਿੱਧੀਆਂ ਕੁਐਰੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਐਪ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਖਰਾਬੀ ਸਰਵਰ 'ਤੇ ਨਹੀਂ, ਹੈਂਡਆਫ਼ ਵਿੱਚ ਹੈ:

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

ਅੰਤ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮਨਜ਼ੂਰ VPN ਰਾਹ ਤੋਂ ਬਾਹਰ ਦਾ ਸਰੋਤ ਸੁਣਨ ਵਾਲੇ ਦੀ ਵਰਤੋਂ ਬਿਲਕੁਲ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਸਫਲ ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਉਸ ਪਤੇ ਨੂੰ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦਾ ਜੋ ਇਸਨੇ ਵਾਪਸ ਕੀਤਾ, ਇਸ ਲਈ ਇਹ ਦੋ ਸਵਾਲ ਵੱਖਰੇ ਰੱਖੋ।

ਸੰਬੰਧਿਤ ਲੇਖ