ਇੱਕ ਅਡੈਪਟਰ 'ਤੇ ਦੋ DNS ਸਰਵਰ ਨੇਮਸਪੇਸ ਨਹੀਂ ਵੰਡਦੇ

ਇੱਕ ਅਡੈਪਟਰ 'ਤੇ ਦੋ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀਬੱਧ ਕਰਨਾ ਇੱਕ ਡੋਮੇਨ ਨੂੰ ਇੱਕ ਸਰਵਰ 'ਤੇ ਅਤੇ ਦੂਜੇ ਡੋਮੇਨ ਨੂੰ ਦੂਜੇ 'ਤੇ ਭੇਜਣ ਦਾ ਤਰੀਕਾ ਜਾਪਦਾ ਹੈ, ਪਰ ਰਿਜ਼ੌਲਵਰ ਸੂਚੀ ਵਿੱਚ ਕੁਝ ਵੀ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰਦਾ। Windows ਨਾਮ ਨਾਲ ਹੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਸਰਵਰ ਨੂੰ ਪੁੱਛਣਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕ੍ਰਮਬੱਧ ਪਤਾ ਸੂਚੀ ਤੋਂ ਨਹੀਂ, ਨੀਤੀ ਵਸਤੂਆਂ ਤੋਂ ਆਉਂਦਾ ਹੈ। ਬਦਲਣ ਵਾਲਾ ਮਾਨਸਿਕ ਮਾਡਲ ਕਤਾਰ ਹੈ: ਡੋਮੇਨ A ਲਈ ਪਹਿਲਾ ਸਰਵਰ ਅਤੇ ਡੋਮੇਨ B ਲਈ ਦੂਜਾ ਸਰਵਰ ਵਰਗਾ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਹਰ ਨੇਮਸਪੇਸ ਲਈ ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਹੈ ਜੋ ਸਰਵਰਾਂ ਦੇ ਨਾਮ ਸਪੱਸ਼ਟ ਦੱਸਦਾ ਹੈ, ਅਤੇ ਉਹ ਨਿਯਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਡੈਪਟਰ ਦੀ ਸੂਚੀ ਦਿਲਚਸਪ ਨਹੀਂ ਰਹਿੰਦੀ।

ਮਿੱਥ: ਦੋ ਪਤੇ ਦੋ ਡੋਮੇਨ ਵੰਡਦੇ ਹਨ

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

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

Windows ਚੋਣ ਲਈ ਅਸਲ ਵਿੱਚ ਕੀ ਵਰਤਦਾ ਹੈ

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

Get-DnsClientNrptRule
Get-DnsClientNrptPolicy -Effective

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

ਹਰ ਨੇਮਸਪੇਸ ਲਈ ਇੱਕ ਨਿਯਮ, ਵਸਤੂ ਰੱਖੋ

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

$svcRule = Add-DnsClientNrptRule -Namespace ".svc.internal.example" -NameServers "10.60.0.53" -DisplayName "VPN lab services" -PassThru
$resRule = Add-DnsClientNrptRule -Namespace ".research.internal.example" -NameServers "10.61.0.53" -DisplayName "VPN lab research" -PassThru
$svcRule | Select-Object Name, Namespace, NameServers
$resRule | Select-Object Name, Namespace, NameServers

ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਪ੍ਰਤਿਅ ਦਾ ਮੇਲ ਦਰਸਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ app.svc.internal.example ਅਤੇ ਉਸ ਹੇਠਾਂ ਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। ਇੱਥੇ ਦੇ ਦੋਵੇਂ ਪਤੇ ਇਸ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦੀ ਆਪਣੀ ਰੂਟਿੰਗ ਯੋਜਨਾ ਦੇ ਹਨ; ਨਿਯਮ ਜ਼ੋਨ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਰੂਟ ਨਹੀਂ ਲਾਉਂਦਾ ਅਤੇ ਅੰਤ ਵਿੱਚ ਜੁੜਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਧਿਕਾਰ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ Add-DnsClientNrptRule ਹਵਾਲਾ ਬਿਲਕੁਲ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੈਰਾਮੀਟਰ ਕੀ ਕਰਦਾ ਹੈ।

ਧਿਆਨ ਦਿਓ ਇਹ ਕਮਾਂਡ ਕੀ ਨਹੀਂ ਕਰਦੀਆਂ: ਇਹ ਪੂਰੀ ਮਸ਼ੀਨ ਲਈ ਹਨ, VPN ਸੈਸ਼ਨ ਤੱਕ ਸੀਮਤ ਨਹੀਂ, ਅਤੇ ਵਿੰਡੋ ਬੰਦ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿੰਦੀਆਂ ਹਨ। ਜੋ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਇਹ ਭੁੱਲ ਜਾਂਦੀ ਹੈ ਉਹ ਸੁਰੰਗ ਜਾਣ ਤੋਂ ਬਾਅਦ ਨੀਤੀ ਛੱਡ ਦਿੰਦੀ ਹੈ।

ਸਾਬਤ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਸਰਵਰ ਚੁਣਿਆ

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

Resolve-DnsName app.svc.internal.example
Resolve-DnsName build.research.internal.example
Resolve-DnsName app.svc.internal.example -DnsOnly -NoHostsFile

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

ਤੁਸੀਂ ਜੋ ਬਣਾਇਆ ਬਿਲਕੁਲ ਉਹੀ ਹਟਾਓ

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

Remove-DnsClientNrptRule -Name $svcRule.Name -Force
Remove-DnsClientNrptRule -Name $resRule.Name -Force
Get-DnsClientNrptPolicy -Effective

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