ਦਫ਼ਤਰ ਦੇ VPN ਨਾਲ ਜੁੜੋ ਅਤੇ ਅਚਾਨਕ ਹਰ ਨਾਮ ਲੁੱਕਅਪ ਕਾਰਪੋਰੇਟ ਰਿਜ਼ਾਲਵਰ ਕੋਲ ਜਾਂਦਾ ਹੈ। ਜਨਤਕ ਨਾਮ ਅਜੇ ਵੀ ਹੱਲ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ ਦਿਸਦਾ ਜਦ ਤੱਕ ਕਿਸੇ ਸਥਾਨਕ ਪ੍ਰਿੰਟਰ ਦਾ ਨਾਮ ਫੇਲ੍ਹ ਨਹੀਂ ਹੁੰਦਾ ਜਾਂ split-horizon ਰਿਕਾਰਡ ਦਫ਼ਤਰ ਦਾ ਪਤਾ ਵਾਪਸ ਨਹੀਂ ਦਿੰਦਾ। ਕੁਝ Fedora ਸੈੱਟਅਪ ਵਿੱਚ ਉਲਟਾ ਹੁੰਦਾ ਹੈ: ਟਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ ਵੀ ISP ਰਿਜ਼ਾਲਵਰ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਇੱਕੋ ਸਵਾਲ ਹਨ — ਇਹ ਕੁਇਰੀ ਕਿਸ ਰਿਜ਼ਾਲਵਰ ਦੀ ਮਲਕੀਅਤ ਹੈ — ਅਤੇ NetworkManager ਸਿਸਟਮਾਂ ਵਿੱਚ ਜਵਾਬ ਹਰ ਕਨੈਕਸ਼ਨ ਦੇ DNS ਗੁਣਾਂ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।

ਦੋ ਕਨੈਕਸ਼ਨ, ਇੱਕ ਜਿੱਤਣ ਵਾਲਾ ਰਿਜ਼ਾਲਵਰ

ਹਰ ਕਨੈਕਸ਼ਨ ਇੱਕ DNS ਤਰਜੀਹ ਐਲਾਨਦਾ ਹੈ। ਆਮ ਕਨੈਕਸ਼ਨ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ 50 'ਤੇ ਅਤੇ VPN ਕਨੈਕਸ਼ਨ 0 'ਤੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਘੱਟ ਮੁੱਲ ਜਿੱਤਦਾ ਹੈ। ਇਹੀ ਡਿਫ਼ਾਲਟ ਕਾਰਨ ਹੈ ਕਿ VPN ਕਨੈਕਸ਼ਨ ਦਾਅਵਾ ਕੀਤੇ ਹਰ ਡੋਮੇਨ ਲਈ ਤਾਰ ਵਾਲੀ ਲਿੰਕ ਨੂੰ ਚੁੱਪਚਾਪ ਪਿੱਛੇ ਛੱਡਦਾ ਹੈ: ਕਿਸੇ ਦੇ ਚੁਣੇ ਬਿਨਾਂ ਹੀ ਸਿਫ਼ਰ ਪੰਜਾਹ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ।

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

ਤਰਜੀਹ ਕ੍ਰਮ ਤੈਅ ਕਰਦੀ ਹੈ, ਖੋਜ ਸੂਚੀ ਮਲਕੀਅਤ ਤੈਅ ਕਰਦੀ ਹੈ

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

ਖੋਜ ਸੂਚੀ ਮਲਕੀਅਤ ਦਾ ਐਲਾਨ ਹੈ। corp.example ਵਰਗਾ ਨੰਗਾ ਡੋਮੇਨ ਖੋਜ ਪਿਛੇਤਰ ਅਤੇ ਰਾਊਟਿੰਗ ਡੋਮੇਨ ਬਣ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼-ਰਾਊਟਿੰਗ ਰੂਪ ~corp.example ਉਸ ਪਿਛੇਤਰ ਹੇਠਲੇ ਲੁੱਕਅਪ ਡੋਮੇਨ ਨੂੰ ਛੋਟੇ ਨਾਮਾਂ ਵਿੱਚ ਜੋੜੇ ਬਿਨਾਂ ਇਸ ਕਨੈਕਸ਼ਨ 'ਤੇ ਭੇਜਦਾ ਹੈ। ਉਹ ਟਿਲਡਾ «ਇਸ ਸਰਵਰ ਨੂੰ ਪੁੱਛੋ» ਅਤੇ «ਇਸ ਸਰਵਰ ਨੂੰ ਪੁੱਛੋ ਅਤੇ ਮੇਰੀ ਟਾਈਪਿੰਗ ਪੂਰੀ ਕਰੋ» ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਹੈ।

ਦੋਵੇਂ ਰੂਪ ਵਰਤੋ ਜਦੋਂ ਵਰਤੋਂਕਾਰ ਛੋਟੇ ਹੋਸਟਨਾਮ ਟਾਈਪ ਕਰਦੇ ਹਨ ਅਤੇ ਰਿਕਾਰਡ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮਾਂ ਨਾਲ ਵੀ ਸੰਬੋਧਿਤ ਹੁੰਦੇ ਹਨ। ਸਿਰਫ਼ ਰਾਊਟਿੰਗ ਰੂਪ ਵਰਤੋ ਜਦੋਂ ਵੰਡ ਚਾਹੀਦੀ ਹੈ ਪਰ ਰਿਜ਼ਾਲਵਰ ਨੰਗੇ ਨਾਮ ਨੂੰ ਕਿਵੇਂ ਪੂਰਾ ਕਰਦਾ ਹੈ ਇਹ ਨਹੀਂ ਬਦਲਣਾ।

ਫਿਰ ਤਰਜੀਹ ਸਪੱਸ਼ਟ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਸਰਗਰਮ ਕਰੋ:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

ਰਿਣਾਤਮਕ ਤਰਜੀਹ «ਇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ» ਕਹਿਣ ਦਾ ਦਸਤਾਵੇਜ਼ੀ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਸੈੱਟ ਕਰਨ ਨਾਲ IPv6 ਕਨੈਕਟੀਵਿਟੀ ਵਾਲੇ ਹੋਸਟ 'ਤੇ ਵਿਵਹਾਰ ਇਕਸਾਰ ਰਹਿੰਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਸਰਗਰਮ ਕੀਤੇ ਬਿਨਾਂ ਗੁਣ ਬਦਲਣ ਨਾਲ ਹੁਣ ਚੱਲ ਰਹੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਵਿੱਚ ਬਦਲਾਅ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਲਈ ਕ੍ਰਮ ਸਪੱਸ਼ਟ up 'ਤੇ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ।

ਵੰਡ systemd-resolved ਕੋਲ ਰਹਿਣ ਦਿਓ

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

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

ਇਸ ਤੋਂ ਬਾਅਦ ਕਾਰਪੋਰੇਟ ਲਿੰਕ corp.example ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ ਅਤੇ ਜਨਤਕ ਰਿਜ਼ਾਲਵਰ ਬਾਕੀ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਕੁਇਰੀ ਗ਼ਲਤ ਲਿੰਕ 'ਤੇ ਪਹੁੰਚਦੀ ਹੈ, ਕਮਾਂਡ ਉਸ ਲਿੰਕ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ ਜਿਸ ਨੇ ਇਸ ਨੂੰ ਜਵਾਬ ਦਿੱਤਾ, ਅਤੇ ਇਹ ਜਾਣਨਾ ਸਿਰਫ਼ ਪਤਾ ਜਾਣਨ ਤੋਂ ਬਿਹਤਰ ਹੈ।

DNS ਡਿਜ਼ਾਈਨ ਨੂੰ ਟਨਲ ਕਿਸਮ ਨਾਲ ਮਿਲਾਓ

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

ਫਿਰ ਉਹ kill switch ਹੈ ਜੋ ਟਨਲ ਤੋਂ ਬਾਹਰ DNS ਰੋਕਦਾ ਹੈ। ਟਨਲ ਦੇ ਜ਼ੋਨਾਂ ਲਈ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਹਰ ਥਾਂ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਕਨੈਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਹੈ। ਕਾਰਗਰ ਜਵਾਬ LAN ਰਿਜ਼ਾਲਵਰ ਲਈ ਸਪੱਸ਼ਟ ਇਜਾਜ਼ਤ ਜਾਂ ਅਜਿਹਾ ਸਥਾਨਕ ਕੈਸ਼ ਹਨ ਜੋ ਸਿਰਫ਼ ਕਾਰਪੋਰੇਟ ਜ਼ੋਨ ਫਾਰਵਰਡ ਕਰੇ, ਅਤੇ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟਨਲ ਵਿੱਚ ਖਰਾਬੀ ਨਹੀਂ ਸਗੋਂ ਮਾਲਕ ਵਾਲਾ ਅਪਵਾਦ ਹੈ।

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

ਹਰ ਲਿੰਕ 'ਤੇ ਜਾਂਚੋ, ਫਿਰ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਫਿਰ ਜਾਂਚੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ