ਨਿੱਜੀ VPN ਨਾਮ ਫੇਲ ਹੋ ਰਹੇ ਹਨ? ਸ਼ੱਕ DNS ਰੀਬਾਈਂਡ ਸੁਰੱਖਿਆ 'ਤੇ

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

ਰੀਬਾਈਂਡ ਸੁਰੱਖਿਆ ਇੱਕ ਖ਼ਾਸ ਚਾਲ ਰੋਕਣ ਲਈ ਹੈ। ਜਾਣ-ਬੁੱਝ ਕੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਿੱਜੀ ਨਾਮ ਓਨਾ ਮਿਲਦਾ-ਜੁਲਦਾ ਦਿਸਦਾ ਹੈ ਕਿ ਬਚਾਅ ਸਰਗਰਮ ਹੋ ਜਾਵੇ।

ਨੀਤੀ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਪੜ੍ਹੋ

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

ਲੱਛਣ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਨਿਦਾਨ ਜਵਾਬ ਦੀ ਸ਼ਕਲ ਤੈਅ ਕਰਦੀ ਹੈ। NXDOMAIN ਗੁੰਮ ਰਿਕਾਰਡ ਹੈ, REFUSED ਪਹੁੰਚ ਨਿਯਮ ਹੈ, ਅੰਦਰੂਨੀ ਨਾਮ ਲਈ ਜਨਤਕ ਟਿਕਾਣਾ ਨੀਤੀ ਜਾਂ split-DNS ਦੀ ਗਲਤੀ ਹੈ, ਅਤੇ ਸਹੀ ਨਿੱਜੀ ਟਿਕਾਣਾ ਜੋ ਕਲਾਇੰਟ ਵਰਤ ਨਹੀਂ ਸਕਦਾ, ਬਿਲਕੁਲ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ। ਰੱਦ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਜਾਂ ਰੁਕੀ ਬੇਨਤੀ ਆਪਣੇ ਆਪ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ, ਇਸੇ ਲਈ ਅਜਿਹੇ ਟਿਕਟਾਂ ਵਿੱਚ ਪਹਿਲਾ ਹੁਕਮ ਮੁੜ-ਚਾਲੂ ਕਰਨਾ ਨਹੀਂ, ਖੋਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਲਿਖ ਲਓ।

ਬਚਾਅ ਅਸਲ ਵਿੱਚ ਕੀ ਰੋਕਦਾ ਹੈ

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

dnsmasq ਠੀਕ ਇਹੀ ਵਿਵਹਾਰ, ਹਰ ਡੋਮੇਨ ਦੀਆਂ ਛੋਟਾਂ ਸਮੇਤ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਆਪਣੇ ਮੈਨੂਅਲ ਵਿੱਚ ਇਹ rebind-domain-ok ਨੂੰ ਅਜਿਹੇ ਟਿਕਾਣੇ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਵਾਪਸ ਕਰ ਸਕਣ ਵਾਲੇ ਡੋਮੇਨਾਂ ਦਾ ਨਾਮ ਦੇਣ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਦੱਸਦਾ ਹੈ। ਇਸ ਨੂੰ ਇਹ ਸੰਕੇਤ ਪੜ੍ਹੋ ਕਿ ਲੋੜੀਂਦਾ ਸੁਧਾਰ ਸੀਮਤ ਇਜਾਜ਼ਤ ਹੈ, ਵਿਸ਼ਵਵਿਆਪੀ ਸਵਿੱਚ ਨਹੀਂ।

ਛੋਟ ਨੂੰ ਨਾਮ ਥਾਂ ਤੱਕ ਸੀਮਤ ਕਰੋ

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

# ask the resolver the VPN pushed, and show the full answer
dig +noall +answer db.corp.example @10.40.0.1
dig +short db.corp.example @10.40.0.1

# dnsmasq: what does the running configuration already allow?
grep -R 'rebind' /etc/dnsmasq.d /etc/dnsmasq.conf

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

Split DNS ਉਸੇ ਫ਼ੈਸਲੇ ਦਾ ਹਿੱਸਾ ਹੈ। ਜੇ ਨਿੱਜੀ ਨਾਮ ਥਾਂ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਰਿਜ਼ੌਲਵਰ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਉੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰਾਂ ਵੱਲ ਇਸ ਦਾ ਰਿਸਾਅ ਰੋਕੋ, ਤਾਂ ਜੋ ਛੋਟ ਹਰ ਰਾਹ ਦੀ ਬਜਾਏ ਇੱਕ ਰਾਹ ਨੂੰ ਢਕੇ।

ਸਰੋਤ ਅਤੇ ਬਚਾਅ ਦੁਬਾਰਾ ਪਰਖੋ

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

# the internal name and the public control should behave differently
dig +short db.corp.example @10.40.0.1
dig +short www.example.com @10.40.0.1

# and the service itself, with the certificate it presents
curl -sS -o /dev/null -w '%{http_code}\n' https://db.corp.example/health

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

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