VPN ਰਾਹੀਂ Azure ਦਾ ਨਿੱਜੀ DNS: ਰਿਜ਼ੋਲਵਰ ਐਂਡਪੁਆਇੰਟ ਜਾਂ ਫਾਰਵਰਡਰ
ਦੋਵੇਂ ਡਿਜ਼ਾਈਨ ਸੁਰੰਗ ਰਾਹੀਂ ਨਿੱਜੀ ਜ਼ੋਨਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਪ੍ਰਬੰਧਿਤ ਇਨਬਾਊਂਡ ਐਂਡਪੁਆਇੰਟ ਦੀ ਫਾਰਵਰਡਰ VM ਨਾਲ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਦੋਵਾਂ ਹਾਲਤਾਂ ਵਿੱਚ ਹੋਣ ਵਾਲਾ ਰਾਹ ਜਾਂਚੋ।
ਆਨ-ਪ੍ਰੈਮਿਸ ਦਾ ਸਰਵਰ ਨਿੱਜੀ ਪਤੇ ਰਾਹੀਂ Azure VM ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਉਸਦਾ ਨਿੱਜੀ ਹੋਸਟਨਾਮ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਜਿਸ ਕਰਕੇ ਲੋਕ ਟੁੱਟੀ ਸੁਰੰਗ ਲੱਭਣ ਲੱਗਦੇ ਹਨ। ਸੁਰੰਗ ਠੀਕ ਹੈ। ਜੋ ਘੱਟ ਹੈ ਉਹ DNS ਸੀਮਾ ਹੈ: ਆਨ-ਪ੍ਰੈਮਿਸ ਪਾਸੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਕਿਸੇ ਖਾਸ Azure ਨਿੱਜੀ ਜ਼ੋਨ ਦਾ ਜਵਾਬ VNet ਦੇ ਅੰਦਰਲੇ ਰਿਜ਼ੋਲਵਰ ਨੇ ਦੇਣਾ ਹੈ। ਦੋ ਡਿਜ਼ਾਈਨ ਇਹ ਖੱਪਾ ਭਰਦੇ ਹਨ, ਅਤੇ ਉਹ ਇਸ ਗੱਲ ਵਿੱਚ ਵੱਖਰੇ ਹਨ ਕਿ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਕੀ ਚਲਾਉਂਦੇ ਹੋ, ਇਸ ਗੱਲ ਵਿੱਚ ਨਹੀਂ ਕਿ ਕਵੈਰੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਨਹੀਂ।
ਸੁਰੰਗ ਕਵੈਰੀਆਂ ਲਿਜਾਂਦੀ ਹੈ, ਜ਼ੋਨ ਦਾ ਗਿਆਨ ਨਹੀਂ
ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਪੈਕਟਾਂ ਨੂੰ ਦੋ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਰਾਹ ਦਿੰਦਾ ਹੈ। ਇਹ ਆਨ-ਪ੍ਰੈਮਿਸ DNS ਸਰਵਰ ਨੂੰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਨਾਮ-ਥਾਂ Azure ਦਾ ਹੈ ਜਾਂ ਕਿਹੜਾ ਪਤਾ ਜਵਾਬ ਦੇਵੇਗਾ, ਇਸ ਲਈ ਕਵੈਰੀ ਜਾਂ ਤਾਂ ਇੰਟਰਨੈੱਟ ਤੇ ਜਾਂਦੀ ਹੈ ਅਤੇ ਖਾਲੀ ਵਾਪਸ ਆਉਂਦੀ ਹੈ, ਜਾਂ ਸਥਾਨਕ ਰਿਜ਼ੋਲਵਰ ਤੋਂ ਕਦੇ ਬਾਹਰ ਨਹੀਂ ਜਾਂਦੀ।
ਹੱਲ ਦੇ ਦੋ ਅੱਧ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਸੌਖਿਆਂ ਵੱਖ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਅੱਧ ਸੁਰੰਗ ਰਾਹੀਂ ਆਉਣ ਵਾਲੀਆਂ ਕਵੈਰੀਆਂ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ VNet ਦੇ ਅੰਦਰਲਾ ਰਿਜ਼ੋਲਵਰ ਹੈ। ਦੂਜਾ ਅੱਧ ਆਨ-ਪ੍ਰੈਮਿਸ ਪਾਸੇ ਦਾ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਹੈ ਜੋ ਠੀਕ ਇੱਕ ਨਾਮ-ਥਾਂ ਉਸ ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਕੋਈ ਵੀ ਅੱਧ ਇਕੱਲਾ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।
ਇਸ ਪੂਰੇ ਵਰਣਨ ਲਈ ਮੰਨ ਲਓ ਕਿ ਜ਼ੋਨ cloud.corp.example ਹੈ, ਅਤੇ ਹਰ ਪਤੇ ਨੂੰ ਉਦਾਹਰਨ ਮੰਨੋ।
ਵਿਕਲਪ A: ਪ੍ਰਬੰਧਿਤ ਇਨਬਾਊਂਡ ਐਂਡਪੁਆਇੰਟ
Azure DNS Private Resolver ਇੱਕ ਇਨਬਾਊਂਡ ਐਂਡਪੁਆਇੰਟ ਦਿੰਦਾ ਹੈ ਜੋ VNet ਤੋਂ ਬਾਹਰ ਤੋਂ DNS ਕਵੈਰੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸਮਰਪਿਤ ਪ੍ਰਤੀਨਿਧ ਸਬਨੈੱਟ ਵਿੱਚ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਨਿੱਜੀ ਜ਼ੋਨ ਨੂੰ ਉਸ VNet ਨਾਲ ਲਿੰਕ ਕਰਦੇ ਹੋ, ਅਤੇ ਸੇਵਾ ਵੱਲੋਂ ਦਿੱਤਾ ਇਨਬਾਊਂਡ ਪਤਾ ਨੋਟ ਕਰਦੇ ਹੋ।
ਫਿਰ ਆਨ-ਪ੍ਰੈਮਿਸ DNS ਸਰਵਰ ਤੇ ਤੁਸੀਂ ਠੀਕ ਨਾਮ-ਥਾਂ ਲਈ ਉਸ ਪਤੇ ਵੱਲ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਬਣਾਉਂਦੇ ਹੋ:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Microsoft ਦੀ ਹਾਈਬ੍ਰਿਡ DNS ਪ੍ਰਕਿਰਿਆ ਜ਼ੋਨ ਲਿੰਕ ਅਤੇ ਫਾਰਵਰਡਰ ਕਦਮ ਦੋਵੇਂ ਦਸਤਾਵੇਜ਼ ਕਰਦੀ ਹੈ। ਪ੍ਰਬੰਧਿਤ ਰਾਹ ਤੁਹਾਨੂੰ ਪੈਚ ਕਰਨ ਲਈ ਕੋਈ DNS ਸਾਫਟਵੇਅਰ ਨਹੀਂ ਛੱਡਦਾ, ਅਤੇ ਐਂਡਪੁਆਇੰਟ ਪਤਾ ਸਰੋਤ ਦੀ ਪੂਰੀ ਉਮਰ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ।
ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਰਿਜ਼ੋਲਵਰ ਸਰੋਤ, ਉਸਦਾ ਸਬਨੈੱਟ ਪ੍ਰਤੀਨਿਧਤਵ ਅਤੇ ਉਸਦਾ ਖਰਚ ਹੈ, ਜੋ ਕਵੈਰੀਆਂ ਦੀ ਮਾਤਰਾ ਬਹੁਤ ਘੱਟ ਹੋਣ ਤੇ ਵੀ ਅਸਲੀ ਹੈ।
ਵਿਕਲਪ B: VNet ਦੇ ਅੰਦਰ ਫਾਰਵਰਡਰ VM
ਪੁਰਾਣਾ ਡਿਜ਼ਾਈਨ VNet ਵਿੱਚ ਆਮ VM ਤੇ DNS ਸਾਫਟਵੇਅਰ ਚਲਾਉਂਦਾ ਹੈ: Windows DNS, BIND ਜਾਂ dnsmasq, ਅਤੇ ਨਿੱਜੀ ਜ਼ੋਨ ਜਾਂ ਤਾਂ ਸਥਾਨਕ ਤੌਰ ਤੇ ਹੋਸਟ ਹੁੰਦਾ ਹੈ ਜਾਂ 168.63.129.16 ਤੇ Azure ਰਿਜ਼ੋਲਵਰ ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਆਨ-ਪ੍ਰੈਮਿਸ ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਉਸ VM ਦੇ ਨਿੱਜੀ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ।
ਇਹ ਵਿਕਲਪ ਉਨ੍ਹਾਂ ਟੀਮਾਂ ਲਈ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ DNS ਸਰਵਰ ਚਲਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਲਾਗਿੰਗ ਜਾਂ ਸਪਲਿਟ-ਹੋਰਾਈਜ਼ਨ ਜਵਾਬਾਂ ਵਰਗਾ ਵਾਧੂ ਤਰਕ ਲੈ ਸਕਦਾ ਹੈ। ਇਹ DNS ਸਰਵਰ ਦੀ ਹਰ ਕਾਰਜਸ਼ੀਲ ਜ਼ਿੰਮੇਵਾਰੀ ਵੀ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ: ਪੈਚਿੰਗ, ਉਪਲਬਧਤਾ ਲਈ ਦੂਜਾ ਇੰਸਟੈਂਸ, ਨਿਗਰਾਨੀ, ਅਤੇ VM ਬਦਲਣ ਤੇ ਉਸਦਾ ਪਤਾ ਬਦਲਣ ਵੇਲੇ ਮੁੜ ਨਿਰਮਾਣ ਦਾ ਰਾਹ।
ਆਮ VNet ਹੋਸਟ DNS ਪ੍ਰਾਕਸੀ ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤੱਕ ਸੇਵਾ ਸਥਾਪਿਤ ਨਾ ਹੋਵੇ ਅਤੇ ਉਨ੍ਹਾਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਜਵਾਬ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਮਿਲੇ, ਅਤੇ VM ਕਲੋਨ ਕਰਦਿਆਂ ਲੋਕ ਇਹੀ ਕਦਮ ਛੱਡ ਦਿੰਦੇ ਹਨ।
ਕਿਹੜਾ ਤੁਹਾਡੇ ਸੰਚਾਲਨ ਲਈ ਢੁੱਕਦਾ ਹੈ
ਤੁਲਨਾ ਇਸ ਬਾਰੇ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਤੇਜ਼ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ DNS ਸਾਫਟਵੇਅਰ ਚਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਕੀ ਕਵੈਰੀਆਂ ਦੀ ਮਾਤਰਾ ਐਂਡਪੁਆਇੰਟ ਅਤੇ ਕਵੈਰੀ ਅਨੁਸਾਰ ਬਿੱਲ ਕਰਨ ਵਾਲੇ ਪ੍ਰਬੰਧਿਤ ਸਰੋਤ ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦੀ ਹੈ।
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
ਕੋਈ ਵੀ ਕਤਾਰ ਫੈਸਲਾ ਕਰੇ, ਆਨ-ਪ੍ਰੈਮਿਸ ਫਾਰਵਰਡਰ ਨਿਯਮ ਇੱਕੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ। ਇਹੀ ਹਿੱਸਾ ਦੋਵੇਂ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਹਿੱਸਾ ਸਭ ਤੋਂ ਵੱਧ ਗੁੰਮ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਦੱਸਦਾ ਹੈ ਕਿ ਰਿਜ਼ੋਲਿਊਸ਼ਨ Azure ਦੇ ਅੰਦਰੋਂ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਦਫ਼ਤਰ ਤੋਂ ਨਹੀਂ।
ਰਾਹ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ
ਪੱਕਾ ਕਰੋ ਕਿ ਜ਼ੋਨ ਰਿਜ਼ੋਲਵਰ ਵਾਲੇ VNet ਨਾਲ ਲਿੰਕ ਹੈ, ਅਤੇ ਆਨ-ਪ੍ਰੈਮਿਸ ਫਾਰਵਰਡਰ ਮੂਲ ਡੋਮੇਨ ਨਹੀਂ ਸਗੋਂ ਨਾਮ-ਥਾਂ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ। corp.example ਲਈ ਫਾਰਵਰਡਰ cloud.corp.example ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਏਗਾ ਜਦ ਤੱਕ ਰਿਜ਼ੋਲਵਰ ਖੁਦ ਪ੍ਰਤੀਨਿਧਤਾ ਨਾ ਕਰੇ, ਅਤੇ ਇਹ ਅਸੰਗਤੀ ਇੱਕ ਸਾਫ਼ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜੋ ਗੁੰਮ ਰਿਕਾਰਡ ਵਰਗਾ ਦਿਸਦਾ ਹੈ।
ਫਿਰ ਜਾਂਚੋ ਕਿ ਕਵੈਰੀ ਐਂਡਪੁਆਇੰਟ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ: ਆਨ-ਪ੍ਰੈਮਿਸ ਸਰੋਤ ਨੂੰ ਰਿਜ਼ੋਲਵਰ ਪਤੇ ਤੱਕ ਰਾਹ ਅਤੇ ਵਾਪਸੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਿੱਥੇ ਨੀਤੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਉੱਥੇ UDP ਅਤੇ TCP ਦੋਵਾਂ ਲਈ ਪੋਰਟ 53 ਖੁੱਲ੍ਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। NSG ਗੁੰਮ ਜ਼ੋਨ ਰਿਕਾਰਡ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਅਤੇ ਸਹੀ ਜ਼ੋਨ ਕਦੇ ਨਾ ਆਉਣ ਵਾਲੀ ਕਵੈਰੀ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ।
ਨਿਦਾਨ ਕਰਦਿਆਂ ਮੰਗਿਆ FQDN ਚੁਣੇ ਰਿਜ਼ੋਲਵਰ ਦੇ ਕੋਲ ਰੱਖੋ, ਅਤੇ ਟਾਈਮਆਊਟ ਨੂੰ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਤੋਂ ਵੱਖ ਕਰੋ। ਟਾਈਮਆਊਟ ਰਾਹ ਜਾਂ ਨੀਤੀ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਦਾ ਅਰਥ ਹੈ ਕਿ ਕਵੈਰੀ ਪਹੁੰਚੀ ਅਤੇ ਨਾਮ-ਥਾਂ ਮੇਲ ਨਹੀਂ ਖਾਇਆ। ਕੰਮ ਦਾ ਕ੍ਰਮ: ਜ਼ੋਨ ਲਿੰਕ ਕਰੋ, ਸ਼ਰਤੀ ਫਾਰਵਰਡਰ ਸ਼ਾਮਲ ਕਰੋ, ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੋਰਟ 53 ਖੋਲ੍ਹੋ, ਆਨ-ਪ੍ਰੈਮਿਸ ਤੋਂ ਇੱਕ ਨਾਮ ਜਾਂਚੋ, ਅਤੇ ਫਿਰ ਹੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਅਧਿਕਾਰਤਾ ਵੇਖੋ।