DNS ਰੀਡਾਇਰੈਕਟ ਤੋਂ ਬਾਅਦ dnsmasq ਕਿਊਰੀਆਂ VPN ਤੋਂ ਬਾਹਰ ਕਿਉਂ ਨਿਕਲਦੀਆਂ ਹਨ

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

ਨਿਸ਼ਾਨ ਕਿਊਰੀ ਨਾਲ ਸਫ਼ਰ ਨਹੀਂ ਕਰਦਾ

ਪੈਕਟ ਨਿਸ਼ਾਨ conntrack ਐਂਟਰੀ ਅਤੇ ਉੱਡ ਰਹੇ ਪੈਕਟ ਉੱਤੇ ਰਹਿੰਦੇ ਹਨ। REDIRECT ਨਿਯਮ ਉਹ ਉਡਾਣ ਖ਼ਤਮ ਕਰਦਾ ਹੈ: ਪੇਲੋਡ ਸਥਾਨਕ ਸਾਕਟ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਮੂਲ ਐਂਟਰੀ ਆਪਣਾ ਕੰਮ ਕਰ ਚੁੱਕੀ ਹੁੰਦੀ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਰਾਊਟਰ ਤੋਂ ਜੋ ਨਿਕਲਦਾ ਹੈ ਉਹ ਰਿਜ਼ਾਲਵਰ ਪ੍ਰਕਿਰਿਆ ਵੱਲੋਂ ਬਣਾਇਆ ਨਵਾਂ ਸਾਕਟ ਹੈ, ਜਿਸ ਦਾ ਸਰੋਤ ਰਾਊਟਰ ਦਾ ਆਪਣਾ ਪਤਾ ਹੈ।

ਇਸ ਲਈ LAN ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਉੱਤੇ ਆਧਾਰਿਤ ਪਾਲਿਸੀ ਰੂਟ ਕਦੇ ਵੀ ਅਪਸਟ੍ਰੀਮ ਕਿਊਰੀ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ। ਨਵਾਂ ਸਾਕਟ ਕਲਾਇੰਟ ਦਾ ਨਹੀਂ ਸਗੋਂ dnsmasq ਦਾ ਹੈ, ਅਤੇ ਕਰਨਲ ਰੂਟ ਦਾ ਮੁਲਾਂਕਣ ਰਾਊਟਰ ਦੀ ਆਪਣੀ ਟ੍ਰੈਫਿਕ ਲਈ ਕਰਦਾ ਹੈ। ਸਰੋਤ ਨਿਯਮ, ਇੰਟਰਫ਼ੇਸ ਨਿਯਮ ਅਤੇ ਨਿਸ਼ਾਨ ਨਿਯਮ ਸਾਰੇ ਵੱਖਰਾ tuple ਵੇਖਦੇ ਹਨ। ਨਿਸ਼ਾਨ ਦਾ ਫੈਲਣਾ ਮੰਨ ਲੈਣਾ ਇਸ ਸੈੱਟਅੱਪ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਗ਼ਲਤੀ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਕੈਪਚਰ ਵਿੱਚ ਇਹ ਅਦਿੱਖ ਹੈ।

ਦੋਵੇਂ ਗੱਲਬਾਤਾਂ ਸੱਚਮੁੱਚ ਇੱਕ ਨਾਮ ਅਤੇ ਇੱਕ ਸਮਾਂ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਕੈਪਚਰ ਨੂੰ ਛੇਤੀ ਨਾਲ ਵੇਖਣ ਵੇਲੇ ਉਹ ਇੱਕੋ ਫਲੋ ਵਰਗੀਆਂ ਲੱਗਣ ਦਾ ਕਾਰਨ ਇਹੀ ਹੈ।

ਕਿੱਥੇ ਅੱਗੇ ਭੇਜਣਾ ਸਥਾਨਕ ਹੱਲ ਬਣਦਾ ਹੈ

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

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

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

ਉਹ ਆਉਟਪੁੱਟ ਕ੍ਰਮ ਨਾਲ ਤਿੰਨ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ: ਕਿਊਰੀ ਨੂੰ ਕੀ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਉਸ ਨੂੰ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੁਣਦੇ ਸਾਕਟ ਦਾ ਮਾਲਕ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਮਾਲਕ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਾਅਦ ਅਪਸਟ੍ਰੀਮ ਪਾਲਿਸੀ ਕੋਲ ਰਹਿਣ ਦੀ ਥਾਂ ਹੁੰਦੀ ਹੈ।

ਰਿਜ਼ਾਲਵਰ ਨੂੰ ਉਸ ਦੀ ਆਪਣੀ ਐਗਰੈਸ ਪਾਲਿਸੀ ਦਿਓ

ਜਦੋਂ ਸਿਰਫ਼ ਕੁਝ ਨਾਵਾਂ ਨੂੰ ਟਨਲ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ ਡੋਮੇਨ-ਖ਼ਾਸ ਅਪਸਟ੍ਰੀਮ ਸਭ ਤੋਂ ਸਾਫ਼ ਸਾਧਨ ਹੈ। dnsmasq ਡੋਮੇਨ ਤੱਕ ਸੀਮਿਤ server ਲਾਈਨ ਸਵੀਕਾਰਦਾ ਹੈ, ਲਾਜ਼ਮੀ ਨਹੀਂ ਇੰਟਰਫ਼ੇਸ ਜਾਂ ਸਰੋਤ ਪਤੇ ਨਾਲ ਕਿਊਰੀ ਨੂੰ ਚੁਣੇ ਯੰਤਰ ਤੋਂ ਬਾਹਰ ਲੈ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਮਾਰਗਦਰਸ਼ਨ ਦੂਜੀ ਗੱਲਬਾਤ ਨੂੰ VPN ਦਾ ਪਿੱਛਾ ਕਰਵਾਉਂਦਾ ਹੈ।

server=/corp.example/10.30.0.53@tun_work
log-queries

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

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

ਸਾਂਝਾ ਕੈਸ਼ ਕੀ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦਾ

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

ਕੈਸ਼ ਕੀਤਾ ਜਵਾਬ ਵੀ ਨਵੇਂ ਰਾਹ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਜਵਾਬ ਯਾਦਦਾਸ਼ਤ ਤੋਂ ਆ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਅਪਸਟ੍ਰੀਮ ਰੂਟ ਟੁੱਟਿਆ ਰਹਿੰਦਾ ਹੈ।

ਪੋਰਟ 53 ਦੇ ਨਿਯਮ DNS ਨੂੰ HTTPS ਜਾਂ TLS ਉੱਤੇ ਬੋਲਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੇ। ਉਹ ਕਿਊਰੀਆਂ ਕਦੇ ਰੀਡਾਇਰੈਕਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀਆਂ, ਇਸ ਲਈ ਸਿਰਫ਼ ਪੋਰਟ 53 ਉੱਤੇ ਬਣੀ ਪਾਲਿਸੀ ਟ੍ਰੈਫਿਕ ਦਾ ਇੱਕ ਉੱਪ-ਸਮੂਹ ਬਿਆਨ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਉੱਪ-ਸਮੂਹ ਵਜੋਂ ਦਰਜ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੂਜੀ ਗੱਲਬਾਤ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਪਹਿਲੀ ਦੀ ਨਹੀਂ

ਉਸ ਨਾਮ ਨਾਲ ਪਰਖੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ ਅਤੇ ਦੋਵੇਂ ਪਾਸੇ ਵੇਖੋ। ਕਲਾਇੰਟ ਪਾਸੇ ਦੀ ਕੈਪਚਰ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਕਿਊਰੀ ਨੇ LAN ਛੱਡਿਆ; ਅੱਗੇ ਕਿੱਥੇ ਗਈ ਇਹ ਸਿਰਫ਼ ਰਾਊਟਰ ਪਾਸਾ ਸਾਬਤ ਕਰਦਾ ਹੈ।

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

ਹਰ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ ਖ਼ਾਲੀ ਕਰੋ, ਕਿਉਂਕਿ ਗਰਮ ਜਵਾਬ ਟੁੱਟੇ ਅਪਸਟ੍ਰੀਮ ਨੂੰ ਲੁਕਾ ਦਿੰਦਾ ਹੈ। TCP ਉੱਤੇ ਦੁਹਰਾਓ, ਫਿਰ ਟਨਲ ਬੰਦ ਕਰਕੇ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਵੇਖ ਸਕੋ ਕਿ ਰਿਜ਼ਾਲਵਰ ਆਪਣਾ ਪਸੰਦੀਦਾ ਰਾਹ ਜਾਣ ਤੋਂ ਬਾਅਦ ਕੀ ਕਰਦਾ ਹੈ। ਉਹੀ ਆਖ਼ਰੀ ਵਿਵਹਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨ fail-closed ਹੈ ਜਾਂ ਸਿਰਫ਼ ਖ਼ੁਸ਼ਕਿਸਮਤ।