ਤੁਹਾਡਾ ਸਪਲਿਟ ਟਨਲ ਐਪ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਪਰ ਇਸਦੇ DNS ਸਰਵਰ ਤੱਕ ਨਹੀਂ
ਸਪਲਿਟ ਟਨਲ ਐਪ ਦਾ ਸਬਨੈੱਟ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਨਾਲ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ ਛੱਡ ਸਕਦਾ ਹੈ। ਹੋਸਟ ਰੂਟ ਸ਼ਾਮਲ ਕਰੋ, ਫਿਰ ਜਾਂਚੋ ਕਿ Windows ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰਵਰ ਚੁਣਦਾ ਹੈ।
ਐਪ ਦਾ ਸਬਨੈੱਟ ਰੂਟ ਕਰਨਾ ਸਪਲਿਟ ਟਨਲ ਦਾ ਸਪਸ਼ਟ ਹਿੱਸਾ ਹੈ ਅਤੇ ਇਹ ਪੂਰਾ ਕੰਮ ਨਹੀਂ। ਰਿਜ਼ੌਲਵਰ ਅਕਸਰ ਉਸ ਐਪ ਤੋਂ ਵੱਖਰੇ ਪਤੇ ’ਤੇ ਬੈਠਦਾ ਹੈ ਜਿਸਦੀ ਉਹ ਸੇਵਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਟਨਲ ਵੀ ਖੋਜ ਨੂੰ ਇਸ ਤੋਂ ਬਾਹਰ ਛੱਡ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ 10.80.0.0/16 ਲੈ ਕੇ ਚੱਲਣ ਵਾਲਾ ਪ੍ਰੋਫ਼ਾਈਲ 10.90.0.53 ਲਈ ਕਵੈਰੀ ਸਥਾਨਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਭੇਜਦਾ ਹੈ, ਜਿੱਥੇ ਕੋਈ ਨਿੱਜੀ ਜ਼ੋਨ ਨਹੀਂ ਹੈ। ਰਿਜ਼ੌਲਵਰ ਦਾ ਰਾਹ ਸ਼ਾਮਲ ਕਰੋ, ਫਿਰ ਸਮੱਸਿਆ ਦਾ ਦੂਜਾ ਅੱਧ ਦੇਖੋ: ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰਵਰ ਚੁਣਦਾ ਹੈ।
ਮਿੱਥ: ਇੱਕ ਰੂਟ ਪੂਰੀ ਸੇਵਾ ਨੂੰ ਢਕਦਾ ਹੈ
ਸਪਲਿਟ ਟਨਲ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਜਾਣ ਵਾਲੀਆਂ ਮੰਜ਼ਿਲਾਂ ਦੀ ਸੂਚੀ ਹੈ, ਸੇਵਾ ਦਾ ਵੇਰਵਾ ਨਹੀਂ। ਐਪ ਦਾ ਸਬਨੈੱਟ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਦੋ ਮੰਜ਼ਿਲਾਂ ਹਨ, ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਲੈ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਐਪ ਪਤੇ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੁੰਦੀ ਹੈ ਪਰ ਇਸਦਾ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਜੋ ਰੂਟਿੰਗ ਖਾਲੀ ਥਾਂ ਨਾਲੋਂ DNS ਖਰਾਬੀ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।
ਰਿਜ਼ੌਲਵਰ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਸਬਨੈੱਟ ਵੀ ਆਪਣੇ ਆਪ ਨਹੀਂ ਢਕਿਆ ਜਾਂਦਾ। ਇੱਕ ਪਤੇ ਲਈ ਹੋਸਟ ਰੂਟ ਉਸ ਰਿਜ਼ੌਲਵਰ ਲਈ ਕਾਫ਼ੀ ਹੈ ਅਤੇ ਇਸਦੇ ਗੁਆਂਢੀਆਂ ਨੂੰ ਨਹੀਂ ਖੋਲ੍ਹਦਾ। ਹੋਸਟ ਰੂਟ ਦਾ ਅਰਥ ਇਹੀ ਹੈ: ਬਣਾਵਟ ਨਾਲ ਤੰਗ, ਅਤੇ ਅਗਲੀ ਸੇਵਾ ਉਸੇ ਸਬਨੈੱਟ ਵਿੱਚ ਆਉਣ ’ਤੇ ਭੁੱਲਣਾ ਸੌਖਾ।
ਖੋਜ ਦੇ ਕੰਮ ਕਰਨ ਲਈ ਤਿੰਨ ਗੱਲਾਂ ਸੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਕਲਾਇੰਟ ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਟਨਲ ਰਾਹੀਂ ਰੂਟ ਕਰਦਾ ਹੈ, ਗੇਟਵੇ ਉਹ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰਕੇ ਅੱਗੇ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਜੋ ਸਰੋਤ ਮਿਲਦਾ ਹੈ ਉਸਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਜਵਾਬ ਵੀ ਤੈਅ ਰਾਹ ਰਾਹੀਂ ਵਾਪਸ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਾ ਹੋਵੇ ਤਾਂ ਲੱਛਣ ਉਹੀ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਿਆਂ ਦੀ ਸਾਰਣੀ ਲਿਖ ਲੈਣਾ ਸਾਰਥਕ ਹੈ।
ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਕਿਹੜੇ ਪਤੇ ਲੈਣੇ ਚਾਹੀਦੇ ਹਨ
ਮੰਜ਼ਿਲਾਂ ਕ੍ਰਮ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕਰੋ: ਐਪ ਦਾ ਨੈੱਟਵਰਕ, ਰਿਜ਼ੌਲਵਰ ਦਾ ਪਤਾ ਅਤੇ ਟਨਲ ਨੂੰ ਹੀ ਖ਼ਤਮ ਕਰਨ ਵਾਲਾ ਜਨਤਕ ਅੰਤ ਬਿੰਦੂ। ਤੀਜੇ ਨੂੰ ਕਦੇ ਵੀ ਟਨਲ ਵਿੱਚ ਰੂਟ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ, ਕਿਉਂਕਿ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਉਹ ਰਾਹ ਚਾਹੀਦਾ ਹੈ ਜੋ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦ ਹੁੰਦਾ ਹੈ।
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
DNS ਲਈ UDP ਅਤੇ TCP ਦੋਵੇਂ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਲਾਗੂਆਂ ਤੋਂ UDP ਦੇ ਨਾਲ TCP ਦਾ ਸਮਰਥਨ ਆਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਰੋਕਿਆ TCP ਰਾਹ ਸਾਫ਼ ਫੇਲ੍ਹਤਾ ਦੀ ਥਾਂ ਹੌਲੀ, ਅੰਸ਼ਿਕ ਫੇਲ੍ਹਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਜੇ ਨਿੱਜੀ ਜ਼ੋਨ IPv6 ਰਾਹੀਂ ਵੀ ਸੇਵਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਬਰਾਬਰ ਦਾ ਹੋਸਟ ਅਪਵਾਦ IPv6 ਪਤਾ ਅਤੇ ਪ੍ਰੀਫਿਕਸ ਵਰਤਦਾ ਹੈ ਅਤੇ ਇਹ ਵੱਖਰੀ ਐਂਟਰੀ ਹੈ।
ਕੁਝ ਵੀ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਲਿਖੋ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਪਹਿਲਾਂ ਹੀ ਕੀ ਢਕਦਾ ਹੈ। ਦੋਹਰਾ ਰੂਟ ਹਾਨੀਕਾਰਕ ਨਹੀਂ, ਪਰ ਅਣਕਿਆਸਿਆ ਮੌਜੂਦ ਰੂਟ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਤੁਹਾਨੂੰ ਮਿਲੀ ਯੋਜਨਾ ਤੋਂ ਵੱਖਰੀ ਪਤਾ ਯੋਜਨਾ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ।
ਕਨੈਕਸ਼ਨ ਦੇ ਮਾਲਕ ਰਾਹੀਂ ਹੋਸਟ ਰੂਟ ਸ਼ਾਮਲ ਕਰੋ
ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਪ੍ਰਬੰਧਿਤ ਮੂਲ Windows ਪ੍ਰੋਫ਼ਾਈਲ ਲਈ, ਰੂਟ ਮਸ਼ੀਨ ਦੀ ਗਲੋਬਲ ਰੂਟਿੰਗ ਸਾਰਣੀ ਦੀ ਥਾਂ ਕਨੈਕਸ਼ਨ ਦਾ ਹੁੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਸ਼ਾਮਲ ਕਰਨ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਕਰੋ, ਫਿਰ ਪ੍ਰੋਫ਼ਾਈਲ ਵਰਤਦਾ ਉਹੀ ਦਾਇਰਾ ਵਰਤ ਕੇ ਲਾਗੂ ਕਰੋ।
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
ਪਹਿਲਾ ਕਮਾਂਡ ਕੁਝ ਵੀ ਸਥਾਪਿਤ ਕੀਤੇ ਬਿਨਾਂ ਬਦਲਾਅ ਦਾ ਪੂਰਵਦਰਸ਼ਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਲੋਂ ਇਸ ਸਮੇਂ ਲਏ ਜਾ ਰਹੇ ਰੂਟਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ। Microsoft ਦਾ Add-VpnConnectionRoute ਹਵਾਲਾ ਹਰ ਵਰਤੋਂਕਾਰ ਅਤੇ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਦਾਇਰਿਆਂ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ; ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਪ੍ਰੋਫ਼ਾਈਲ ਨੂੰ ਆਪਣਾ ਦਾਇਰਾ ਪੈਰਾਮੀਟਰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਾਰੇ ਵਰਤੋਂਕਾਰਾਂ ਦੇ ਪ੍ਰੋਫ਼ਾਈਲ ਵਿਰੁੱਧ ਹਰ ਵਰਤੋਂਕਾਰ ਦਾ ਕਮਾਂਡ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਜਾਂ ਗਲਤ ਥਾਂ ’ਤੇ ਪਹੁੰਚਦਾ ਹੈ।
ਜਦੋਂ ਪ੍ਰੋਫ਼ਾਈਲ ਪ੍ਰਬੰਧਿਤ ਹੋਵੇ ਜਾਂ ਵਿਕਰੇਤਾ ਦੇ ਕਲਾਇੰਟ ਤੋਂ ਆਵੇ, ਬਦਲਾਅ ਉਸ ਮਾਲਕ ਦਾ ਹੁੰਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਨੀਤੀ ਉੱਤੇ ਸਥਾਈ ਸਿਸਟਮ ਰੂਟ ਢੇਰੀ ਕਰਨਾ ਤਦ ਤੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਨੀਤੀ ਦੁਬਾਰਾ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਰੂਟ ਨਹੀਂ ਜਾਂਦਾ, ਜੋ ਆਮ ਤੌਰ ’ਤੇ ਜਾਂਚ ਵੇਲੇ ਨਹੀਂ ਬਲਕਿ ਸਹਾਇਤਾ ਕਾਲ ਵੇਲੇ ਹੁੰਦਾ ਹੈ। ਉਹ ਫੇਲ੍ਹਤਾ ਚੁੱਪ ਹੁੰਦੀ ਹੈ: ਰੂਟ ਗਾਇਬ ਹੁੰਦਾ ਹੈ, ਨਾਮ ਹੱਲ ਹੋਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਦੋ ਘਟਨਾਵਾਂ ਨੂੰ ਨਹੀਂ ਜੋੜਦਾ। ਬਦਲਾਅ ਨੂੰ ਮਾਲਕ ਦੇ ਆਪਣੇ ਰਿਕਾਰਡ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਅਗਲੀ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਨਾ ਇਸਨੂੰ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਲੈ ਕੇ ਚੱਲੇ।
ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਰੂਟ ਲਾਗੂ ਹੋਇਆ ਮੰਨਣ ਦੀ ਥਾਂ ਪ੍ਰੋਫ਼ਾਈਲ ਦੁਬਾਰਾ ਜੋੜੋ। ਜੀਵਤ ਕਨੈਕਸ਼ਨ ’ਤੇ ਰੂਟ ਬਦਲਾਅ ਹਮੇਸ਼ਾ ਨਹੀਂ ਉਠਾਏ ਜਾਂਦੇ, ਅਤੇ ਦੁਬਾਰਾ ਜੋੜਨਾ ਤੁਹਾਡੇ ਵਰਤੋਂਕਾਰਾਂ ਕੋਲ ਅਸਲ ਵਿੱਚ ਜੋ ਹਾਲਤ ਹੋਵੇਗੀ ਉਹ ਵੀ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।
ਜਾਂਚੋ ਕਿ ਕਲਾਇੰਟ ਨੇ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਿਜ਼ੌਲਵਰ ਵਰਤਿਆ
ਰੂਟ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਸੰਬੋਧਿਤ ਪੈਕਟਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਿਹੜੇ ਨਾਮ ਉੱਥੇ ਭੇਜਣੇ ਹਨ, ਅਤੇ ਉਹ ਚੋਣ ਵੱਖਰੀ ਵਿਧੀ ਹੈ। Windows ਵਿੱਚ ਪ੍ਰਭਾਵੀ ਨਾਮ ਥਾਂ ਨਿਯਮ ਹਰ ਡੋਮੇਨ ਲਈ ਰਿਜ਼ੌਲਵਰ ਚੁਣ ਸਕਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਦੀਆਂ DNS ਸੈਟਿੰਗਾਂ ਡਿਫ਼ਾਲਟ ਦਿੰਦੀਆਂ ਹਨ। ਇਹ ਦੋ ਪਰਤਾਂ ਕੋਈ ਵੀ ਗਲਤੀ ਪੈਦਾ ਕੀਤੇ ਬਿਨਾਂ ਵੱਖਰੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਸਿੱਧੀ ਕਵੈਰੀ ਅੱਧਾ ਸਬੂਤ ਹੀ ਹੈ।
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
ਪਹਿਲਾ ਕਮਾਂਡ ਲਾਗੂ ਨਾਮ ਥਾਂ ਨੀਤੀ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਨਿੱਜੀ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਸਿੱਧਾ ਐਪ ਦਾ ਨਾਮ ਪੁੱਛਦਾ ਹੈ। ਸਿੱਧਾ ਜਵਾਬ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰਾਹ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਕੰਮ ਕਰਦੇ ਹਨ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਐਪ ਦੀ ਆਪਣੀ ਖੋਜ ਨੇ ਉਹ ਸਰਵਰ ਚੁਣਿਆ। ਇਸਦੀ ਤੁਲਨਾ ਉਸੇ ਨਾਮ ਦੀ ਆਮ ਖੋਜ ਅਤੇ ਐਪ ਨੂੰ ਮਿਲਣ ਵਾਲੇ ਜਵਾਬ ਨਾਲ ਕਰੋ।
ਕੈਸ਼ ਅਤੇ ਬਰਾਊਜ਼ਰ-ਪੱਧਰੀ ਸੁਰੱਖਿਅਤ DNS ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ, ਜੋ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਟਾਈਪ ਕੀਤੇ ਨਾਮਾਂ ਲਈ ਸਿਸਟਮ ਰਿਜ਼ੌਲਵਰ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਾਈਪਾਸ ਕਰ ਸਕਦਾ ਹੈ। ਖੋਜ ਉਪਸਰਗ ਇੱਕ ਹੋਰ ਭਰਮਾਉਣ ਵਾਲਾ ਸੰਕੇਤ ਹੈ: ਇਹ ਛੋਟੇ ਨਾਮ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਨਾਮ ਵਿੱਚ ਫੈਲਾਉਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਸਰਵਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਹੀਂ।
ਅੰਤ ਵਿੱਚ ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਆਮ ਖੋਜ ਦੁਹਰਾਓ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਆਮ ਬਰਾਊਜ਼ਿੰਗ ਅਜੇ ਵੀ ਆਪਣੀ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ। ਬੇਸਬੰਧ ਨਾਮ ਹੱਲ ਹੋਣ ਲਈ ਨਿੱਜੀ ਰਿਜ਼ੌਲਵਰ ਦੀ ਥਾਂ ਜਨਤਕ ਰੱਖਣਾ ਸੁਧਾਰ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਨਿੱਜੀ ਕਵੈਰੀਆਂ ਨੂੰ ਚੁੱਪਚਾਪ ਉੱਥੇ ਲੈ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਉਹਨਾਂ ਨੂੰ ਕਦੇ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ।