WireGuard DNS ਪੁਸ਼ ਨਹੀਂ ਕਰਦਾ: ਇੱਕ ਪ੍ਰਾਈਵੇਟ BIND ਜ਼ੋਨ ਦੀ ਸੇਵਾ

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

ਟਨਲ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਵੱਖਰੇ ਸਮਝੌਤੇ ਹਨ

WireGuard ਜਾਣ-ਬੁੱਝ ਕੇ ਛੋਟਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਸੂਚੀਬੱਧ ਪਤਿਆਂ ਲਈ ਪੈਕੇਟ ਭੇਜਦਾ ਹੈ ਅਤੇ ਪੀਅਰ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ; ਉਸ ਪਰਤ ਉੱਤੇ ਸਭ ਕੁਝ ਤੁਹਾਡਾ ਡਿਜ਼ਾਈਨ ਹੈ। OpenVPN dhcp-option DNS ਪੁਸ਼ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦਾ ਕੰਟਰੋਲ ਚੈਨਲ ਸੰਰਚਨਾ ਲਿਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਦੋਹਾਂ ਵਿਚਕਾਰ ਘੁੰਮਣ ਵਾਲਿਆਂ ਨੂੰ ਠੋਕਰ ਮਾਰਦਾ ਹੈ।

ਇਸ ਲਈ ਕੰਮ ਕਰਦੀ ਟਨਲ ਨਾਮ ਹੱਲ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਕਲਾਇੰਟ ਕੋਲ 10.90.0.1 ਤੱਕ ਸੰਪੂਰਨ ਰਸਤਾ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਆਪਣੀਆਂ ਕਿਊਰੀਆਂ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਭੇਜ ਸਕਦਾ ਹੈ, ਇਸੇ ਲਈ ਲੱਛਣ “VPN ਨੇ DNS ਤੋੜ ਦਿੱਤਾ” ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਜਦੋਂ ਕਿ DNS ਕਦੇ VPN ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਨਹੀਂ ਸੀ।

ਜ਼ੋਨ ਦੀ ਸੇਵਾ ਬਿਨਾਂ ਪੁਨਰਾਵਰਤੀ ਰਿਜ਼ੋਲਵਰ ਬਣੇ ਕਰੋ

ਸਰਵਰ ਪਾਸਾ ਇੱਕ ਛੋਟਾ ਅਧਿਕਾਰਿਕ ਜ਼ੋਨ ਹੈ, ਆਮ ਰਿਜ਼ੋਲਵਰ ਨਹੀਂ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ ਗੇਟਵੇ 10.90.0.1 ਹੈ, ਕਲਾਇੰਟ 10.90.0.0/24 ਹਨ, ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਐਪਲੀਕੇਸ਼ਨ 10.60.0.20 'ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਦੂਜਾ ਬਲਾਕ ਬਣਾਉਣ ਦੀ ਥਾਂ ਇਹ ਸੈਟਿੰਗਾਂ ਮੌਜੂਦਾ options ਬਲਾਕ ਵਿੱਚ ਮਿਲਾਓ:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

ਫਿਰ ਜ਼ੋਨ ਅਤੇ ਇਸਦੀ ਫਾਈਲ ਘੋਸ਼ਿਤ ਕਰੋ:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};

$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

ਮੁੜ ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਲੋਡ ਵੇਲੇ ਵਾਕ-ਰਚਨਾ ਗਲਤੀ ਉਸ ਹਰ ਜ਼ੋਨ ਲਈ ਪੂਰਾ ਸਰਵਰ ਡੇਗ ਦਿੰਦੀ ਹੈ ਜਿਸਦੀ ਇਹ ਸੇਵਾ ਕਰਦਾ ਹੈ:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP ਅਤੇ TCP 53 ਸਿਰਫ਼ VPN ਇੰਟਰਫੇਸ 'ਤੇ ਖੋਲ੍ਹੋ। ਜਨਤਕ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿੱਜੀ ਅਧਿਕਾਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਕਿਊਰੀ ਅਤੇ ਗਿਣਤੀ ਦੋਵੇਂ ਸੱਦਦਾ ਹੈ, ਅਤੇ allow-transfer ਬੰਦ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਕਿਸੇ ਸੈਕੰਡਰੀ ਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਨਾ ਹੋਵੇ।

ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਵੱਲ ਮੋੜੋ, ਹਰ ਲਿੰਕ ਲਈ

ਮੰਨ ਲਓ ਕਿ ਕਨੈਕਸ਼ਨ NetworkManager ਦਾ ਹੈ ਅਤੇ systemd-resolved ਰਿਜ਼ੋਲਵਰ ਹੈ। ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਨੀਤੀ ਪੜ੍ਹੋ, ਖਾਸ ਕਰਕੇ ਕੋਈ ਰੂਟ ਰਾਊਟਿੰਗ ਡੋਮੇਨ, ਕਿਉਂਕਿ ~. ਐਂਟਰੀ ਉਸ ਤੋਂ ਅੱਗੇ ਨਿਕਲ ਜਾਵੇਗੀ ਜੋ ਤੁਸੀਂ ਸ਼ਾਮਲ ਕਰਨ ਜਾ ਰਹੇ ਹੋ।

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

ਟਿਲਡ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਅੱਖਰ ਹੈ। ਇਹ ਡੋਮੇਨ ਨੂੰ ਸਿਰਫ਼-ਰਸਤਾ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ: corp.example ਹੇਠਲੇ ਨਾਮ ਇਸ ਲਿੰਕ ਦੇ DNS ਸਰਵਰ 'ਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਡੋਮੇਨ ਛੋਟੇ ਨਾਮ ਦੀ ਖੋਜ ਪਿਛੇਤਰ ਵਜੋਂ ਨਹੀਂ ਜੋੜਿਆ ਜਾਂਦਾ। ਇਸ ਤੋਂ ਬਿਨਾਂ, portal ਟਾਈਪ ਕਰਨ 'ਤੇ portal.corp.example ਹੱਲ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਲਈ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਬਾਕੀ ਸਾਰਿਆਂ ਲਈ ਹੈਰਾਨੀਜਨਕ ਹੈ। ਟਿਲਡ ਨੂੰ ਹਵਾਲਾ ਚਿੰਨ੍ਹਾਂ ਦੇ ਅੰਦਰ ਰੱਖੋ, ਕਿਉਂਕਿ ਹਵਾਲੇ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਸ਼ੈਲ ਵਿਸਥਾਰ ਹੈ ਜੋ ਤੁਹਾਡੀ ਘਰ ਡਾਇਰੈਕਟਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ।

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

ਨਾਮ ਤੋਂ ਪਹਿਲਾਂ ਰਸਤਾ ਜਾਂਚੋ

ਕਲਾਇੰਟ ਤੋਂ ਨਾਮ ਪੁੱਛੋ ਅਤੇ ਜਵਾਬ ਤੇ ਉਸਨੂੰ ਪੈਦਾ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਦੋਵੇਂ ਪੁਸ਼ਟੀ ਕਰੋ:

resolvectl query portal.corp.example

ਜੇ ਇਹ 10.60.0.20 ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਤਾਂ DNS ਸਮਝੌਤਾ ਪੂਰਾ ਹੋਇਆ। ਜੇ ਸਮਾਂ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ 10.90.0.1 ਦਾ ਰਸਤਾ, ਫਿਰ ਫਾਇਰਵਾਲ ਨਿਯਮ, ਫਿਰ ਸਰਵਰ 'ਤੇ allow-query ਜਾਂਚੋ। ਇਸ ਸੈਟਅਪ ਵਿੱਚ ਨਾਮ ਹੱਲ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਲਗਭਗ ਹਮੇਸ਼ਾ ਪਹੁੰਚ ਜਾਂ ACL ਹੁੰਦੀਆਂ ਹਨ, ਜ਼ੋਨ ਫਾਈਲ ਨਹੀਂ। ਕਲਾਇੰਟ ਤੋਂ ਬਾਹਰ ਵੱਲ ਕੰਮ ਕਰੋ, ਕਿਉਂਕਿ ਸਰਵਰ ਤੁਹਾਨੂੰ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕੋਈ ਕਿਊਰੀ ਕਦੇ ਪਹੁੰਚੀ ਕਿਉਂ ਨਹੀਂ।

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

ਜੋ ਅਜੇ ਵੀ ਆਪਣੇ-ਆਪ ਨਹੀਂ

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

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

ਅਗਲਾ ਕਦਮ: ਜ਼ੋਨ ਦੀ ਸੀਰੀਅਲ ਵਾਧਾ ਅਤੇ ਜਾਂਚ ਕਮਾਂਡਾਂ ਆਪਣੀ ਤਬਦੀਲੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ, ਤਾਂ ਜੋ ਕੋਈ ਰਿਕਾਰਡ ਸੋਧ ਬਿਨਾਂ ਜਾਂਚ ਉਤਪਾਦਨ ਤੱਕ ਨਾ ਪਹੁੰਚ ਸਕੇ।