Windows ’ਤੇ OpenConnect ਦੀਆਂ DNS ਸੈਟਿੰਗਾਂ ਅਸਲ ਵਿੱਚ ਕੌਣ ਲਾਗੂ ਕਰਦਾ ਹੈ?
Windows ਰਿਜ਼ੌਲਵਰ ਦੀ ਸਥਿਤੀ ਤਿੰਨ ਥਾਵਾਂ ’ਤੇ ਰੱਖਦਾ ਹੈ। ਐਡਾਪਟਰ DNS ਨੂੰ ਹੱਥ ਨਾਲ ਸੋਧਣ ਜਾਂ ਨੇਮਸਪੇਸ ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਸਹਾਇਕ ਲੱਭੋ ਜਿਸ ਕੋਲ ਕਨੈਕਸ਼ਨ ਹੈ।
ਟਨਲ ਚੁੱਕਣਾ ਇਸ ਦੇ DNS ਮੁੱਲ ਸਥਾਪਿਤ ਕਰਨਾ ਨਹੀਂ ਹੈ। OpenConnect ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ਅਤੇ Windows ਪਾਸੇ ਦਾ ਇੱਕ ਸਹਾਇਕ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਦੋ ਕਦਮਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਇਸ ਕਲਾਇਟ ’ਤੇ ਬਹੁਤੀਆਂ ਨਿੱਜੀ-ਨਾਮ ਅਸਫਲਤਾਵਾਂ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਹਾਇਕ ਲਗਭਗ ਕਦੇ ਵੀ Windows VPN ਸੈਟਿੰਗਾਂ ਪੰਨਾ ਨਹੀਂ ਹੁੰਦਾ।
ਗੇਟਵੇ ਨੇ ਜੋ ਪੇਸ਼ ਕੀਤਾ ਅਤੇ Windows ਨੇ ਜੋ ਸਥਾਪਿਤ ਕੀਤਾ, ਉਹਨਾਂ ਨੂੰ ਵੱਖ ਕਰੋ
ਕਲਾਇਟ ਕਨੈਕਸ਼ਨ ਡੇਟਾ ਇੱਕ ਸਕ੍ਰਿਪਟ ਇੰਟਰਫੇਸ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਅਤੇ Unix ਤੇ Windows ਸੰਸਕਰਣ ਵੱਖਰੇ ਪ੍ਰੋਗਰਾਮ ਹਨ। Windows ’ਤੇ ਲਾਗੂਕਰਨ ਆਮ ਤੌਰ ’ਤੇ ਇੱਕ JavaScript ਸਹਾਇਕ ਹੁੰਦਾ ਹੈ ਜੋ ਅੰਦਰੂਨੀ DNS ਸਰਵਰ ਅਤੇ ਅੰਦਰੂਨੀ ਡੋਮੇਨ ਵਰਗੇ ਵੇਰੀਏਬਲ ਕਿਸੇ ਵੀ ਐਡਾਪਟਰ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪੜ੍ਹਦਾ ਹੈ। ਟਨਲ ਵਿੱਚ ਆਪ ਕੁਝ ਵੀ ਰਿਜ਼ੌਲਵਰ ਸਥਿਤੀ ਨਹੀਂ ਲਿਖਦਾ।
ਇਹ ਵੰਡ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਮੁੱਲ ਗੱਲਬਾਤ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਐਡਾਪਟਰ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਗੁੰਮ, ਅੱਧ ਵਿਚਕਾਰ ਅਸਫਲ ਹੋਣ ਵਾਲਾ, ਜਾਂ GUI ਆਵਰਣ ਵਿੱਚ ਬੰਨ੍ਹੀ ਪੁਰਾਣੀ ਕਾਪੀ ਵਾਲਾ ਸਹਾਇਕ Windows ਨੂੰ ਬਿਲਕੁਲ ਉਹੀ ਛੱਡਦਾ ਹੈ ਜੋ ਇਹ ਸੀ। ਸੈਸ਼ਨ ਜੁੜਿਆ ਦਿਸਦਾ ਹੈ, ਨਿੱਜੀ ਨਾਮ ਅਜੇ ਵੀ ਸਥਾਨਕ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇਟ ਵਿੰਡੋ ਵਿੱਚ ਕੁਝ ਵੀ ਫ਼ਰਕ ਵੱਲ ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰਦਾ। ਸਹਾਇਕ ਦਾ ਆਪਣਾ ਆਉਟਪੁੱਟ ਪੜ੍ਹਨਾ ਹੀ ਇਹ ਜਾਣਨ ਦਾ ਇੱਕੋ ਭਰੋਸੇਯੋਗ ਤਰੀਕਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪੜਾਅ ਟੁੱਟਿਆ।
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI ਆਵਰਣ ਕਲਾਇਟ ਅਤੇ ਸਹਾਇਕ ਦੀ ਆਪਣੀ ਕਾਪੀ ਲਿਆ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਡਿਸਕ ’ਤੇ ਕਿਤੇ ਹੋਰ ਦੂਜਾ openconnect.exe ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਲੱਭੋ ਜਿਸ ਨੇ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ।
ਰਿਜ਼ੌਲਵਰ ਸਥਿਤੀ ਨੂੰ ਬਦਲੇ ਬਿਨਾਂ ਪੜ੍ਹੋ
ਤਿੰਨ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀਆਂ ਕਵੈਰੀਆਂ ਆਮ ਉਲਝਣ ਨੂੰ ਕਵਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effectiveਐਡਾਪਟਰ-ਪੱਧਰ ਦਾ ਸਰਵਰ ਉਹ ਹੈ ਜਿਸਨੂੰ ਬਹੁਤੇ ਲੋਕ VPN DNS ਕਹਿੰਦੇ ਹਨ। ਕਨੈਕਸ਼ਨ-ਵਿਸ਼ੇਸ਼ ਪਿਛੇਤਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਛੋਟਾ ਨਾਮ ਬਿਲਕੁਲ ਵੀ ਫੈਲੇਗਾ ਜਾਂ ਨਹੀਂ। ਨੇਮਸਪੇਸ ਨੀਤੀ ਸੂਚੀ ਐਡਾਪਟਰ ਕ੍ਰਮ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਮੇਲ ਖਾਂਦੇ ਨਾਵਾਂ ’ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਉੱਥੇ ਖਾਲੀ ਨਤੀਜਾ ਕਮੀ ਨਹੀਂ ਹੈ ਜਦੋਂ ਸਹਾਇਕ ਨੇ ਕਦੇ ਇੱਕ ਬਣਾਉਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਸੀ ਕੀਤਾ। ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨੇ ਪੜ੍ਹਨਾ ਹੀ ਅਜਿਹਾ ਸੁਧਾਰ ਰੋਕਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਲੱਛਣ ਨੂੰ ਕਿਤੇ ਹੋਰ ਭੇਜਦਾ ਹੈ।
ਪੂਰਨ ਯੋਗ ਨਾਮ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ FQDN ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਛੋਟਾ ਨਾਮ ਨਹੀਂ, ਤਾਂ ਫ਼ਰਕ ਪਿਛੇਤਰ ਜਾਂ ਖੋਜ ਸੂਚੀ ਹੈ, ਸਰਵਰ ਪਤਾ ਨਹੀਂ।
ਦੂਜੇ ਕਦਮ ਵਜੋਂ ਇੱਛਤ ਸਰਵਰ ਤੋਂ ਸਿੱਧਾ ਪੁੱਛੋ, ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਕਿਸੇ ਵੀ ਰਿਜ਼ੌਲਵਰ ਸਾਧਨ ਨਾਲ। ਸਿੱਧਾ ਜਵਾਬ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰਵਰ ਪਹੁੰਚਯੋਗ ਅਤੇ ਜ਼ੋਨ ਲਈ ਅਧਿਕਾਰਤ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਕਿਹੜੇ ਸਰਵਰ ਨੂੰ ਪੁੱਛਦੀ ਹੈ।
ਕਨੈਕਸ਼ਨ ਵਾਲੇ ਹਿੱਸੇ ਦਾ ਨਾਮ ਦਿਓ
ਦੋ ਵਿਵਸਥਾਵਾਂ ਆਮ ਹਨ। ਟਰਮੀਨਲ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਕਲਾਇਟ ਆਪਣਾ ਸਕ੍ਰਿਪਟ ਮਾਰਗ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਮਾਲਕ ਚਲਾਏ ਗਏ ਕਮਾਂਡ ਵਿੱਚ ਦਿਸਦਾ ਹੈ। ਪੈਕੇਜ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਤੁਹਾਡੇ ਲਈ ਕਲਾਇਟ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਅਤੇ ਸਹਾਇਕ ਨੂੰ ਆਪਣੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਰੱਖਦੀ ਹੈ, ਭਾਵ ਇਹ ਕਦੋਂ ਬਦਲੇਗਾ ਇਹ ਵਿਕਰੇਤਾ ਤੈਅ ਕਰਦਾ ਹੈ।
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਾਪਨਾਵਾਂ ਵਿਚਕਾਰ ਸਹਾਇਕ ਸੰਸਕਰਣਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਫਾਈਲ ਦਾ ਨਾਮ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਲੱਗਦਾ ਹੈ ਇਸ ਲਈ ਸ਼ੀਸ਼ੇ ਤੋਂ ਲਿਆਂਦੇ ਸਹਾਇਕ ਨੂੰ ਉੱਚੇ ਅਧਿਕਾਰਾਂ ਨਾਲ ਚਲਾਉਣਾ DNS ਦੇ ਫ਼ਰਕ ਨੂੰ ਸੁਰੱਖਿਆ ਘਟਨਾ ਬਣਾ ਦਿੰਦਾ ਹੈ।
ਮਾਲਕ ਪਤਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਮੁਰੰਮਤ ਦਾ ਟੀਚਾ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ: ਲਾਂਚਰ ਵਿੱਚ ਸਮਰਥਿਤ ਸਕ੍ਰਿਪਟ ਮਾਰਗ, ਪੈਕੇਜ ਅਪਡੇਟ, ਜਾਂ ਗੇਟਵੇ ’ਤੇ ਸੋਧੀ ਪਰੋਫਾਈਲ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਲਈ ਵੀ ਐਡਾਪਟਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੱਥ ਨਾਲ ਸੋਧਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਮਾਲਕ ਠੀਕ ਕਰੋ, ਐਡਾਪਟਰ ਨਹੀਂ
ਐਡਾਪਟਰ ’ਤੇ ਹੱਥ ਨਾਲ ਸੈੱਟ ਕੀਤਾ DNS ਅਕਸਰ ਡਿਸਕਨੈਕਟ ਤੋਂ ਬਾਅਦ ਵੀ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਕੰਮ ਕਰਦਾ ਦਿਸਦਾ ਹੈ ਅਤੇ ਫਿਰ ਅਗਲੇ ਨੈੱਟਵਰਕ ’ਤੇ ਮੁਸ਼ਕਲ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਹਰ ਇੰਟਰਫੇਸ ’ਤੇ ਬੋਲਟ ਕੀਤਾ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਨਿੱਜੀ ਨੇਮਸਪੇਸ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਬਜਾਏ ਲੁਕਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਸਹਾਇਕ ਨੂੰ ਕਦੇ DNS ਮੁੱਲ ਨਹੀਂ ਮਿਲਿਆ, ਤਾਂ ਗੇਟਵੇ ਪਰੋਫਾਈਲ ਵੇਖਣ ਦੀ ਥਾਂ ਹੈ। ਜਦੋਂ ਇਸਨੂੰ ਮਿਲਿਆ ਅਤੇ ਐਡਾਪਟਰ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਸਰਵਰ ਦਿਖਾਉਂਦਾ ਹੈ, ਸਹਾਇਕ ਕਨੈਕਟ ਦੌਰਾਨ ਅਸਫਲ ਹੋਇਆ ਅਤੇ ਕਲਾਇਟ ਲੌਗ ਆਮ ਤੌਰ ’ਤੇ ਇਸਨੂੰ ਟਨਲ ਸੈੱਟਅਪ ਲਾਈਨਾਂ ਨੇੜੇ ਦਰਜ ਕਰਦਾ ਹੈ।
ਸਮਰਥਿਤ ਮਾਰਗ ਰਾਹੀਂ ਸਥਿਤੀ ਦੁਬਾਰਾ ਬਣਾਓ, ਫਿਰ ਪੂਰਾ ਚੱਕਰ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਕਨੈਕਟ ਕਰੋ, ਨਿੱਜੀ FQDN ਹੱਲ ਕਰੋ, ਸੇਵਾ ਖੋਲ੍ਹੋ, ਡਿਸਕਨੈਕਟ ਕਰੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਡਾਪਟਰ ਆਪਣੇ ਪਿਛਲੇ ਸਰਵਰਾਂ ਨਾਲ ਵਾਪਸ ਆਇਆ।
ਅਸਲ ਵਿੱਚ ਅਸਫਲ ਹੋਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰੋ
ਆਪਣੀ ਐਨਕ੍ਰਿਪਟਿਡ-DNS ਸੈਟਿੰਗ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਉੱਪਰ ਦੱਸੀ ਹਰ ਗੱਲ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ। ਟਨਲ ਚੁੱਕਣ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਕੈਸ਼ ਕੀਤਾ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਰੱਖਣ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ। ਰਿਜ਼ੌਲਵਰ ਪਤੇ ਦੁਬਾਰਾ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਉਸੇ ਮਸ਼ੀਨ ’ਤੇ ਸਧਾਰਨ ਸਿਸਟਮ ਕਵੈਰੀ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਜੇ ਸਿਸਟਮ ਕਵੈਰੀ ਸਹੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਗਲਤ ਹੈ, ਤਾਂ ਬਾਕੀ ਕਮੀ ਉਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ DNS ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੈ, VPN ਮਾਰਗ ਵਿੱਚ ਨਹੀਂ।