ਵੰਡਿਆ DNS ਅਤੇ VPN: ਡੋਮੇਨ ਨਿਯਮ IP ਰੂਟ ਨਹੀਂ ਹਨ
ਵੰਡਿਆ DNS ਨਾਮ ਅਨੁਸਾਰ ਰਿਜ਼ੋਲਵਰ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਨੂੰ ਅਜੇ ਵੀ ਰੂਟ ਚਾਹੀਦਾ ਹੈ। ਡੋਮੇਨ ਨਿਯਮ ਅਤੇ ਰਾਹ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਪਰਖੋ, ਉਸੇ ਪਲੇਟਫਾਰਮ ਤੇ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ।
ਤੁਹਾਡਾ ਲੈਪਟਾਪ intranet.corp ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਿ gitlab.com ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੇ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਜਾਂਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਵਿਵਸਥਾ ਹੈ ਜੋ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੀ ਹੈ। ਦੋ ਵੱਖਰੇ ਫੈਸਲਿਆਂ ਨੇ ਇਹ ਬਣਾਇਆ: ਨਾਮ ਮਿਲਾਨ ਨਿਯਮ ਨੇ ਰਿਜ਼ੋਲਵਰ ਚੁਣਿਆ, ਅਤੇ ਰੂਟ ਨੇ ਜਵਾਬ ਵਾਪਸ ਲਿਆਂਦਾ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਤੋੜੋ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਬਾਹਰੋਂ ਇੱਕੋ ਜਿਹੀ ਦਿਸਣ ਵਾਲੀ ਅਸਫਲਤਾ ਦਿਖਾਉਂਦਾ ਹੈ। ਵੰਡੇ DNS ਬਾਰੇ ਜ਼ਿਆਦਾਤਰ ਰਿਪੋਰਟਾਂ ਦੂਜੀ ਅਸਫਲਤਾ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਨਾਲ ਪਹਿਲੀ ਬਾਰੇ ਸਬੂਤ ਦਿੰਦੀਆਂ ਹਨ।
ਦੋਵੇਂ ਅੱਧੇ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਤੇ ਰਹਿੰਦੇ ਹਨ ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਵੱਖਰੇ ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਦੇ ਹਨ। ਇੱਕ VPN ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਜੁੜੀ DNS ਨੀਤੀ ਹੈ, ਦੂਜਾ ਉਹ ਰੂਟ ਹੈ ਜੋ ਟਨਲ ਲਗਾਉਂਦਾ ਜਾਂ ਰੋਕਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਤੈਅ ਨਹੀਂ ਕਰਦਾ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਅੱਧਾ ਹਿੱਲਿਆ, ਡੀਬੱਗਿੰਗ ਰੁਕ ਜਾਂਦੀ ਹੈ।
ਇੱਕ ਬੇਨਤੀ ਵਿੱਚ ਲੁਕੇ ਦੋ ਫੈਸਲੇ
ਨਾਮ ਵਾਲਾ ਅੱਧਾ ਨੀਤੀ ਵਸਤੂ ਹੈ, ਰੂਟ ਨਹੀਂ। Windows ਤੇ ਇਹ VPN ਪ੍ਰੋਫਾਈਲ ਤੇ ਨਾਮ-ਹੱਲ ਨੀਤੀ ਹੈ; Apple ਪਲੇਟਫਾਰਮਾਂ ਤੇ DNS ਸੈਟਿੰਗਾਂ ਵਸਤੂ ਤੇ ਮਿਲਦੇ ਡੋਮੇਨਾਂ ਦਾ ਸਮੂਹ; Linux ਤੇ ਰੂਟਿੰਗ ਡੋਮੇਨ, ਵੰਡੀ ਰਿਜ਼ੋਲਵਰ ਲਾਈਨ ਜਾਂ ਨਾਮ ਸੇਵਾ ਸਵਿੱਚ ਦਾ ਕ੍ਰਮ। ਰਾਹ ਵਾਲਾ ਅੱਧਾ ਆਮ ਰੂਟਿੰਗ ਹੈ, ਟਨਲ ਜਾਂ ਹੱਥ ਨਾਲ ਲਗਾਇਆ, ਅਤੇ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਹੋਸਟਨਾਮ ਕੀ ਹੈ। ਜੋ ਪ੍ਰੋਫਾਈਲ ਪਿਛੇਤਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਉਹ ਸਿਰਫ਼ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਜਵਾਬ ਦੇਵੇਗਾ; ਇਹ ਜਵਾਬ ਨੂੰ ਕਦੇ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਤੇਜ਼ ਲੱਛਣ ਪਰਖ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀ ਹੈ: ਨਾਮ ਦੀ ਥਾਂ ਪਤਾ ਰੱਖੋ। ਜੇ ਪਤਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਰਾਹ ਠੀਕ ਹੈ ਅਤੇ ਨਿਯਮ ਗਲਤ ਹੈ। ਜੇ ਪਤਾ ਵੀ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਨਿਯਮ ਸਹੀ ਅਤੇ ਰਾਹ ਗੁੰਮ ਹੋ ਸਕਦਾ ਹੈ।
ਹਰ ਪਲੇਟਫਾਰਮ ਉਹੀ ਨਾਮ ਨਿਯਮ ਕਿਵੇਂ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ
ਮਕਸਦ ਇੱਕੋ ਹੈ ਅਤੇ ਖੇਤਰਾਂ ਦੇ ਨਾਮ ਨਹੀਂ। ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਦੂਜੇ ਤੇ ਨਕਲ ਕੀਤੀ ਉਦਾਹਰਨ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਪਾਰਸ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਦੇ ਨਹੀਂ ਮਿਲਦੀ। ਤਿੰਨ ਰੂਪ ਇੰਝ ਦਿਸਦੇ ਹਨ:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
ਮਿਲਾਨ ਜਾਂ ਰੂਟਿੰਗ ਡੋਮੇਨ ਪਿਛੇਤਰ ਪਰਖ ਹੈ, ਇਸ ਲਈ intranet.corp git.intranet.corp ਨੂੰ ਢਕਦਾ ਹੈ ਅਤੇ corp.intranet ਨੂੰ ਨਹੀਂ ਢਕਦਾ, ਅਤੇ ਇਸਨੂੰ ਉਲਟਾਉਣਾ ਪੂਰੀ ਸੈਟਿੰਗ ਦੀ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀ ਹੈ। Windows ਮੈਪਿੰਗ ਨੂੰ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਜੁੜੀ ਨਾਮ-ਹੱਲ ਨੀਤੀ ਵਜੋਂ ਰੱਖਦਾ ਹੈ, ਇੰਟਰਫ਼ੇਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਕਿਸੇ ਵੀ ਪਿਛੇਤਰ ਸੂਚੀ ਦੇ ਮੁਕਾਬਲੇ ਆਪਣੇ ਤਰਜੀਹ ਕ੍ਰਮ ਨਾਲ। Apple ਪਲੇਟਫਾਰਮ ਮਿਲਦੇ ਡੋਮੇਨਾਂ ਨੂੰ ਨੈੱਟਵਰਕ ਐਕਸਟੈਂਸ਼ਨ ਦੀ DNS ਸੈਟਿੰਗਾਂ ਵਸਤੂ ਨਾਲ ਜੋੜਦੇ ਹਨ, ਅਤੇ ਸਿਸਟਮ ਉਨ੍ਹਾਂ ਨੂੰ ਹਰ ਸੀਮਤ ਰਿਜ਼ੋਲਵਰ ਲਈ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰੂਪ ਰੂਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਨਾ-ਪਹੁੰਚਯੋਗ ਪਤੇ ਨੂੰ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। Windows ਨਾਮ-ਹੱਲ ਨੀਤੀ ਹਵਾਲਾ ਉਸ ਪਲੇਟਫਾਰਮ ਦੇ ਖੇਤਰ ਨਾਮ ਅਤੇ ਤਰਜੀਹ ਨਿਯਮ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਉਹ ਨਿਯਮ ਨਹੀਂ ਜੋ Apple ਜਾਂ systemd ਦਸਤਾਵੇਜ਼ ਵਰਤਦੇ ਹਨ।
ਸਹੀ ਜਵਾਬ ਨੂੰ ਅਜੇ ਵੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ
ਰਿਜ਼ੋਲਵਰ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਇੱਕ ਪਤਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਜੇ ਵੀ ਉੱਥੇ ਪਹੁੰਚਣਾ ਹੈ। ਵੰਡਿਆ ਟਨਲ ਡਿਜ਼ਾਈਨ ਅਕਸਰ 10.20.0.0/16 ਧੱਕਦਾ ਹੈ ਅਤੇ ਮੂਲ ਰੂਟ ਰੋਕ ਲੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕਨੈਕਸ਼ਨ ਲਟਕ ਜਾਂਦਾ ਹੈ। ਉਲਟ ਮਾਮਲਾ ਵੀ ਓਨਾ ਹੀ ਆਮ ਹੈ: ਰੂਟ ਮੌਜੂਦ ਹੈ, ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਨਿੱਜੀ ਨਾਮ ਨੂੰ NXDOMAIN ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਵਜੋਂ ਦਰਜ ਹੁੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਰਾਹ ਪਰਖਣ ਨਾਲ ਤੁਸੀਂ ਉਸ ਨਾਮ ਲਈ ਰੂਟ ਵੱਲ ਵੇਖਦੇ ਰਹਿੰਦੇ ਹੋ ਜੋ ਕਦੇ ਹੱਲ ਹੋਣਾ ਹੀ ਨਹੀਂ ਸੀ।
ਤੀਜਾ ਦਰਵਾਜ਼ਾ ਵੀ ਹੈ ਜੋ ਕੋਈ ਅੱਧਾ ਨਹੀਂ ਢਕਦਾ। ਗੇਟਵੇ ਤੇ ACL, ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ ਕਲਾਇੰਟ-ਪਾਸੇ ਨੀਤੀ ਦੋਵੇਂ ਫੈਸਲੇ ਸਹੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਕਨੈਕਸ਼ਨ ਡੇਗ ਸਕਦੀ ਹੈ। ਜਦੋਂ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਰੂਟ ਮੌਜੂਦ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਫਿਰ ਵੀ ਸਮਾਂ ਖਤਮ ਕਰਦਾ ਹੈ, ਤਾਂ DNS ਪਰਖਣਾ ਬੰਦ ਕਰੋ।
ਨਾਮ ਅਤੇ ਰਾਹ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਪਰਖਣਾ
ਇੱਕ ਕ੍ਰਮ ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਫੜੀ ਰੱਖੋ, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਉਸ ਕਦਮ ਪਿੱਛੇ ਭੱਜੋਗੇ ਜੋ ਸਭ ਤੋਂ ਬਾਅਦ ਅਸਫਲ ਹੋਇਆ। ਦਸਤਾਵੇਜ਼ੀ ਪੂਰਾ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਕਰੋ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਉਹ ਪਤਾ ਹੈ ਜੋ ਰੂਟ ਸਾਰਣੀ ਚੁੱਕ ਸਕਦੀ ਹੈ, ਫਿਰ ਜਨਤਕ ਨਾਮ ਨਾਲ ਦੁਹਰਾਓ ਤਾਂ ਜੋ ਸਾਬਤ ਹੋਵੇ ਕਿ ਟਨਲ ਨੇ ਸਭ ਕੁਝ ਨਹੀਂ ਫੜਿਆ। systemd ਹੋਸਟ ਤੇ ਕੁਇਰੀ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਦਾ ਰੂਟਿੰਗ ਡੋਮੇਨ ਇੱਕ ਕਮਾਂਡ ਦੀ ਦੂਰੀ ਤੇ ਹਨ:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows ਕਲਾਇੰਟ ਉਹੀ ਦੋ ਸਵਾਲ ਵੱਖਰੇ cmdlet ਨਾਲ ਪੁੱਛਦਾ ਹੈ। ਦੂਜਾ ਉਹ ਇੰਟਰਫ਼ੇਸ ਦੱਸਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਅਸਲ ਵਿੱਚ ਵਰਤੇਗਾ:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10ਜੇ ਖੋਜ ਪਤਾ ਦਿੰਦੀ ਹੈ ਅਤੇ ਰਾਹ ਪਰਖ ਭੌਤਿਕ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਤਾਂ ਨਾਮ ਨਿਯਮ ਕੰਮ ਕਰ ਗਿਆ ਅਤੇ ਰੂਟ ਨਹੀਂ। ਜੇ ਛੋਟਾ ਨਾਮ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਪੂਰਾ ਨਾਮ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਿਛੇਤਰ ਸੂਚੀ ਗਲਤ ਹੈ, ਰਿਜ਼ੋਲਵਰ ਨਹੀਂ।
ਤੁਲਨਾ ਆਮ ਤੌਰ ਤੇ ਕਿੱਥੇ ਗਲਤ ਹੁੰਦੀ ਹੈ
ਪਹਿਲੀ ਗਲਤੀ ਹੈ ਅਸੰਬੰਧਿਤ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਨਿੱਜੀ ਨਾਮ ਬਾਰੇ ਪੁੱਛਣਾ ਅਤੇ ਇਨਕਾਰ ਨੂੰ VPN ਬਾਰੇ ਸਬੂਤ ਵਜੋਂ ਪੜ੍ਹਨਾ। ਦੂਜੀ ਹੈ ਇਹ ਮੰਨਣਾ ਕਿ ਕੰਮ ਕਰਦੀ ਜਨਤਕ ਖੋਜ ਟਨਲ ਦਾ ਰਿਜ਼ੋਲਵਰ ਰਾਹ ਸਾਬਤ ਕਰਦੀ ਹੈ। ਤੀਜੀ ਹੈ ਵੰਡੀ ਟਨਲਿੰਗ ਅਤੇ ਵੰਡੇ DNS ਨੂੰ ਇੱਕੋ ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਮੰਨਣਾ, ਜਦੋਂ ਕਿ ਤੈਨਾਤੀ ਇੱਕ ਵਿੱਚ ਸਹੀ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਟੁੱਟੀ ਹੋ ਸਕਦੀ ਹੈ। ਹਰ ਗਲਤੀ ਦੋਸ਼ੀ ਹਿੱਸੇ ਦੀ ਕਦੇ ਪਰਖ ਨਾ ਕੀਤੀ ਗਈ ਪਰਖ ਤੋਂ ਆਤਮਵਿਸ਼ਵਾਸੀ ਸਿੱਟੇ ਦਿੰਦੀ ਹੈ।
ਆਪਣਾ ਸੁਰੱਖਿਅਤ DNS ਰੱਖਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਵੀ ਸਿਸਟਮ ਨਿਯਮ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਅਸਫਲ ਹੋਣਾ ਜਦੋਂ ਕਿ ਦੂਜਾ ਸਫਲ ਹੁੰਦਾ ਹੈ ਕੋਈ ਵਿਰੋਧਾਭਾਸ ਨਹੀਂ। ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਰਿਜ਼ੋਲਵਰ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਸ਼ਿਕਾਇਤ ਕਰਨ ਵਾਲੇ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਨਹੀਂ।
ਇੱਕ ਵਾਰ ਦੋਵੇਂ ਅੱਧੇ ਦਿਸਣ ਲੱਗਣ, ਤਾਂ ਬਚਿਆ ਸਵਾਲ ਤਕਨੀਕੀ ਨਹੀਂ ਸਗੋਂ ਨੀਤੀ ਦਾ ਹੈ: ਕਿਹੜੇ ਨਾਮ-ਖੇਤਰ ਸੰਸਥਾ ਦੇ ਹਨ, ਹਰ ਜਵਾਬ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜੇ ਮਸ਼ੀਨ ਛੱਡਣੇ ਚਾਹੀਦੇ ਹਨ। ਇਹ ਪ੍ਰੋਫਾਈਲ ਦੇ ਕੋਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਨਿਯਮ ਨੂੰ ਛੂਹਣ ਵਾਲੇ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਇਸਦੀ ਲੋੜ ਪਵੇਗੀ।