DNS ਨੂੰ ਸਿਰਫ਼ ਤੁਹਾਡੇ VPN ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਹੀ ਜਾਣ ਦਿਓ: ਕਦਮ-ਦਰ-ਕਦਮ ਗਾਈਡ
ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਜਵਾਬ ਤੱਕ ਇੱਕ ਨਾਮ ਖੋਜ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਦੇਖੋ ਰਿਜ਼ੋਲਵਰ ਕਿੱਥੇ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ, ਫਾਇਰਵਾਲ ਕਿੱਥੇ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਪੋਰਟ 53 ਦਾ ਨਿਯਮ ਕਦੇ ਕੀ ਨਹੀਂ ਢਕਦਾ।
ਜਿਸ ਪਲ ਤੁਸੀਂ ਨਾਮ ਟਾਈਪ ਕਰਦੇ ਹੋ, ਉਸੇ ਪਲ ਤੋਂ ਇੱਕ ਨਾਮ ਖੋਜ ਦਾ ਪਿੱਛਾ ਕਰੋ। ਬ੍ਰਾਊਜ਼ਰ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਦਾ ਹੈ, ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਉਸ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਜੋ ਉਸ ਦੀ ਨੀਤੀ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਕੁਐਰੀ ਕਿਸੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਕਿਸੇ ਟਰਾਂਸਪੋਰਟ ਨਾਲ ਡਿਵਾਈਸ ਤੋਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਡਾ VPN ਡਿਜ਼ਾਈਨ ਕਹਿੰਦਾ ਹੈ ਕਿ ਜਵਾਬ ਕਿਸੇ ਖ਼ਾਸ ਰਿਜ਼ੋਲਵਰ ਤੋਂ ਕਿਸੇ ਖ਼ਾਸ ਰਾਹੀਂ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਦੋ ਬਿਆਨਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੀ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਕਰਦੇ ਹੋ ਅਤੇ ਫਿਰ ਲਾਗੂ ਕਰਦੇ ਹੋ।
ਕਦਮ 1: ਰਿਜ਼ੋਲਵਰ ਅਤੇ ਰਾਹ ਦਾ ਨਾਮ ਦਿਓ
ਫਾਇਰਵਾਲ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਗੱਲਾਂ ਲਿਖੋ: ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ, ਉਹ ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਪੋਰਟ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਅਤੇ ਉਹ ਇੰਟਰਫੇਸ ਜਿਸ ਰਾਹੀਂ ਕੁਐਰੀ ਬਾਹਰ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਸੂਚੀ ਤੋਂ ਬਿਨਾਂ ਨਿਯਮ ਟ੍ਰੈਫਿਕ ਬਾਰੇ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ, ਕਿਸੇ ਫ਼ੈਸਲੇ ਦਾ ਅਮਲ ਨਹੀਂ। VPN ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਡੇਟਾ ਲੈ ਜਾ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ DNS ਵੱਖਰੀ ਵਿਵਸਥਾ ਫੁਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਗ਼ਲਤੀ ਨਹੀਂ। ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਨੇ ਕਲਾਇੰਟ ਨੂੰ ਹੋਰ ਕੁਝ ਨਹੀਂ ਦੱਸਿਆ।
ਰਾਹ ਦਾ ਸਪਸ਼ਟ ਨਾਮ ਦੇਣਾ ਡਿਜ਼ਾਈਨ ਅਤੇ ਹਾਦਸੇ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪਰਖਣ ਲਈ ਕੁਝ ਵੀ ਦਿੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹਰ ਨਿਰੀਖਣ ਦੀ ਤੁਲਨਾ ਲਿਖਤੀ ਉਮੀਦ ਨਾਲ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਉਹ ਸੂਚੀ ਤਬਦੀਲੀ ਟਿਕਟ ਵਿੱਚ ਰੱਖੋ, ਕਿਸੇ ਦੇ ਸਿਰ ਵਿੱਚ ਨਹੀਂ।
ਕਦਮ 2: ਨੀਤੀ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਉਹ ਸੱਚਮੁੱਚ ਰਹਿੰਦੀ ਹੈ
ਰਿਜ਼ੋਲਵਰ ਦੀ ਚੋਣ ਕਲਾਇੰਟ ਦੀ ਗੱਲ ਹੈ: ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਨੈੱਟਵਰਕ ਸੰਰਚਨਾ, VPN ਕਲਾਇੰਟ ਦੀਆਂ ਆਪਣੀਆਂ ਸੈਟਿੰਗਾਂ, ਜਾਂ ਪ੍ਰਬੰਧਿਤ ਬ੍ਰਾਊਜ਼ਰ ਨੀਤੀ। ਪਹਿਲਾਂ ਉੱਥੇ ਹੀ ਰੱਖੋ, ਉਸ ਢੰਗ ਨਾਲ ਜਿਸ ਦਾ ਪਲੇਟਫਾਰਮ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਫਾਇਰਵਾਲ ਕਲਾਇੰਟ ਨੂੰ ਉਹ ਰਿਜ਼ੋਲਵਰ ਚੁਣਨ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਿਸ ਬਾਰੇ ਉਸ ਨੂੰ ਕਦੇ ਦੱਸਿਆ ਹੀ ਨਹੀਂ ਗਿਆ। ਸਪਲਿਟ-ਟਨਲ ਕਲਾਇੰਟ ਉੱਤੇ ਸਪਸ਼ਟ ਕਹੋ ਕਿ ਕਿਹੜੇ ਡੋਮੇਨ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਜਾਂਦੇ ਹਨ। ਪ੍ਰਬੰਧਿਤ ਫਲੀਟ ਵਿੱਚ DoH ਲਈ ਬ੍ਰਾਊਜ਼ਰ ਨੀਤੀ ਹੀ ਅਕਸਰ ਇੱਕੋ-ਇੱਕ ਲੀਵਰ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਸਿਸਟਮ ਸੈਟਿੰਗ ਤੋਂ ਆਜ਼ਾਦ ਹੋ ਕੇ ਆਪਣਾ ਇਨਕ੍ਰਿਪਟਿਡ ਰਿਜ਼ੋਲਵਰ ਚੁਣ ਸਕਦਾ ਹੈ।
ਇਹ ਛੱਡ ਕੇ ਸਿੱਧਾ ਫਾਇਰਵਾਲ ਵੱਲ ਜਾਓ ਤਾਂ ਤੁਹਾਨੂੰ ਸਹੀ ਰਿਜ਼ੋਲਵਰ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਅਤੇ ਉਸ ਨੂੰ ਕਦੇ ਨਾ ਵਰਤਣ ਵਾਲਾ ਕਲਾਇੰਟ ਮਿਲੇਗਾ। ਨਿਯਮ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਦੇ ਲੌਗ ਖਾਲੀ ਰਹਿੰਦੇ ਹਨ, ਜੋ ਡੀਬੱਗ ਕਰਨ ਲਈ ਉਲਝਾਊ ਜੋੜੀ ਹੈ। ਪਹਿਲਾਂ ਚੋਣ ਸੰਰਚਿਤ ਕਰੋ, ਫਿਰ ਲਾਗੂ ਕਰੋ।
ਕਦਮ 3: ਰਾਹ ਨੂੰ ਤੰਗ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰੋ
ਹੁਣ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਾਹ ਲਈ ਨੈੱਟਵਰਕ ਆਗਿਆ ਸ਼ਾਮਲ ਕਰੋ: ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ, ਪ੍ਰੋਟੋਕਾਲ ਅਤੇ ਪੋਰਟ, ਅਤੇ ਉਹ ਇੰਟਰਫੇਸ ਜਿਸ ਰਾਹੀਂ ਇਸ ਨੂੰ ਬਾਹਰ ਜਾਣਾ ਹੈ। ਸਾਰੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ DNS ਦੀ ਆਗਿਆ ਦੇਣ ਦੀ ਥਾਂ ਨਿਯਮ ਨੂੰ ਉਸੇ ਰਿਜ਼ੋਲਵਰ ਤੱਕ ਸੀਮਤ ਰੱਖੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਤਿੰਨ ਰਾਹ ਉਹ ਹਨ ਜੋ ਆਧੁਨਿਕ ਕਲਾਇੰਟ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਪੋਰਟ 53 ਦਾ ਨਿਯਮ ਸਿਰਫ਼ ਪਹਿਲੇ ਨੂੰ ਹੀ ਢਕਦਾ ਹੈ।
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH ਅਤੇ DoT ਨੂੰ ਰੋਕਣਾ ਜਾਇਜ਼ ਹੈ; ਇਹ ਮੰਨਣਾ ਕਿ ਪੋਰਟ 53 ਦੇ ਨਿਯਮ ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੱਤਾ ਹੈ, ਜਾਇਜ਼ ਨਹੀਂ। DoH ਵਰਤਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਨਾਮ ਉਸ ਰਾਹ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਨਿਯਮ ਨੇ ਕਦੇ ਬਿਆਨ ਨਹੀਂ ਕੀਤਾ, ਅਤੇ ਆਪਣਾ ਰਿਜ਼ੋਲਵਰ ਲਿਆਉਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਅਜਿਹਾ ਹੀ ਕਰਦੀ ਹੈ। ਹਰ ਉਹ ਰਾਹ ਲਿਖੋ ਜਿਸ ਦੀ ਤੁਸੀਂ ਆਗਿਆ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਹਰ ਉਹ ਜਿਸ ਨੂੰ ਰੱਦ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਜੋ ਨਿਯਮ ਕਿਸੇ ਰਾਹ ਦਾ ਨਾਮ ਨਹੀਂ ਲੈਂਦਾ, ਉਸ ਨੇ ਉਸ ਬਾਰੇ ਫ਼ੈਸਲਾ ਨਹੀਂ ਕੀਤਾ।
ਕਦਮ 4: ਨਿੱਜੀ ਅਤੇ ਜਨਤਕ ਨਾਮਾਂ ਦਾ ਪਿੱਛਾ ਕਰੋ
ਵੰਡਿਆDNS ਜਾਣ-ਬੁੱਝ ਕੇ ਸਿਰਫ਼ ਨਿੱਜੀ ਨਾਮ-ਥਾਂ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਭੇਜਦਾ ਹੈ ਜਦੋਂ ਕਿ ਜਨਤਕ ਨਾਮ ਕਿਤੇ ਹੋਰ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਰਿਜ਼ੋਲਵਰ ਹੋਣਾ ਲੀਕ ਨਹੀਂ। ਲੀਕ ਉਹ ਕੁਐਰੀ ਹੈ ਜੋ ਤੁਹਾਡੇ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਜਾਣੀ ਚਾਹੀਦੀ ਸੀ ਅਤੇ ਕਿਤੇ ਹੋਰ ਪਹੁੰਚਦੀ ਹੈ, ਜਾਂ ਕੋਈ ਅਣਪਹੁੰਚਯੋਗ ਇੱਛਤ ਰਾਹ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਚੁੱਪ-ਚਾਪ ਪਿੱਛੇ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਦੋ ਹਾਲਤਾਂ ਖੋਜਣ ਯੋਗ ਹਨ। ਇੱਛਤ ਨੀਤੀ ਹੇਠ ਇੱਕ ਅੰਦਰੂਨੀ ਅਤੇ ਇੱਕ ਜਨਤਕ ਨਾਮ ਦਾ ਪਿੱਛਾ ਕਰੋ ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜੇ ਰਿਜ਼ੋਲਵਰ ਨੇ ਕਿਸ ਨੂੰ ਜਵਾਬ ਦਿੱਤਾ।
ਤੁਹਾਡੇ ਰਿਜ਼ੋਲਵਰ ਦੀ ਰਿਪੋਰਟ ਦੇਣ ਵਾਲੀ ਜਾਂਚ ਸਾਈਟ ਇੱਕ ਸੰਕੇਤ ਹੈ, ਸਬੂਤ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਉਹ ਕੁਐਰੀ ਵੇਖਦੀ ਹੈ ਜੋ ਇਸ ਤੱਕ ਪਹੁੰਚੀਆਂ। ਜਦੋਂ ਇਹ ਜਾਣਨਾ ਹੋਵੇ ਕਿ ਕੁਐਰੀ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਾਹ ਲਿਆ, ਤਾਂ ਇਸ ਨੂੰ ਕਲਾਇੰਟ ਪਾਸੇ ਕੈਪਚਰ ਕਰੋ, ਫਿਰ ਦੋਵੇਂ ਨਿਰੀਖਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਜਦੋਂ ਉਹ ਨਹੀਂ ਮਿਲਦੇ, ਤਾਂ ਤੁਸੀਂ ਉਹ ਪਿੱਛੇ ਹਟਣਾ ਲੱਭ ਲਿਆ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਦਰਜ ਨਹੀਂ ਕੀਤਾ।
ਜੇ ਰਿਜ਼ੋਲਵਰ ਦਾ ਪਤਾ ਸਹੀ ਹੈ ਪਰ ਪਹੁੰਚਯੋਗ ਨਹੀਂ, ਤਾਂ ਸਮੱਸਿਆ ਨੀਤੀ ਵਿੱਚ ਨਹੀਂ, ਰਾਊਟਿੰਗ ਜਾਂ ਫਿਲਟਰਿੰਗ ਵਿੱਚ ਹੈ। ਕੁਐਰੀ ਨੂੰ ਉਸ ਪਤੇ ਤੱਕ ਟਰੇਸ ਕਰੋ ਅਤੇ ਕੋਈ ਵੀ ਰਿਜ਼ੋਲਵਰ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਉਮੀਦ ਕੀਤੇ ਇੰਟਰਫੇਸ ਉੱਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ।
ਕਦਮ 5: ਵਾਪਸ ਆਉਣ ਦਾ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ
ਗੇਟਵੇ ਉੱਤੇ DNS ਪਹੁੰਚ ਸਖ਼ਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਕਰਨ ਉੱਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲੀ ਰਿਕਵਰੀ ਵਿਧੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਟੁੱਟਿਆ ਰਿਜ਼ੋਲਵਰ ਹਰ ਮੁਰੰਮਤ ਸੰਦ ਤੱਕ ਪਹੁੰਚ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ, ਉਹ ਵੀ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਤਬਦੀਲੀ ਵਾਪਸ ਲੈਂਦੇ। ਨਵੀਂ ਨੀਤੀ ਸਾਬਤ ਹੋਣ ਤੱਕ ਲੋਕਲ ਕੰਸੋਲ ਜਾਂ ਬੈਂਡ ਤੋਂ ਬਾਹਰਲਾ ਰਾਹ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। ਇਸ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਹਟਾਓ ਜਦੋਂ ਨੀਤੀ ਨੇ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਝੱਲ ਲਿਆ ਹੋਵੇ।
ਮੁੜ-ਕਨੈਕਸ਼ਨ ਜਾਂ ਬ੍ਰਾਊਜ਼ਰ ਨੀਤੀ ਅਪਡੇਟ ਤੋਂ ਬਾਅਦ ਪ੍ਰਭਾਵੀ ਸਥਿਤੀ ਦੁਬਾਰਾ ਵੇਖੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਤੁਹਾਡੇ ਨਿਯਮ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਰਿਜ਼ੋਲਵਰ ਬਦਲ ਸਕਦੇ ਹਨ। ਲੋੜ ਕੁਐਰੀਆਂ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਪ੍ਰਾਪਤਕਰਤਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰਾਹ ਹੈ, ਇੱਕ ਸਕ੍ਰੀਨਸ਼ਾਟ ਵਿੱਚ ਤਸੱਲੀ ਦੇਣ ਵਾਲਾ ਰਿਜ਼ੋਲਵਰ ਲੇਬਲ ਨਹੀਂ। RFC 8484 DNS over HTTPS ਵਿਸ਼ੇਸ਼ਣ ਉਸ ਇਨਕ੍ਰਿਪਟਿਡ ਰਾਹ ਦਾ ਹਵਾਲਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਪੋਰਟ ਨਿਯਮ ਨਹੀਂ ਵੇਖਦਾ।