ਇੱਕ ਨਿੱਜੀ ਨਾਮ EC2 ਇੰਸਟੈਂਸ ਤੋਂ ਹੱਲ ਹੁੰਦਾ ਹੈ ਪਰ VPN ਨਾਲ ਜੁੜੇ ਲੈਪਟਾਪ ਤੋਂ ਨਹੀਂ, ਅਤੇ ਜ਼ੋਨ ਕੰਸੋਲ ਵਿੱਚ ਸਹੀ ਦਿਸਦਾ ਹੈ। ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਰਿਕਾਰਡ ਸੋਧਣ ਦੀ ਹੁੰਦੀ ਹੈ, ਜੋ ਲਗਭਗ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਹੁੰਦੀ। ਰਿਕਾਰਡ ਕਿਸੇ ਨੂੰ ਜਵਾਬ ਦੇ ਰਿਹਾ ਹੈ; ਬੱਸ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਿਹਾ। ਦੋਵਾਂ ਕਾਲਰਾਂ ਵਿੱਚ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਉਹ ਕਿਹੜੇ resolver ਨੂੰ ਪੁੱਛਦੇ ਹਨ ਅਤੇ ਕੀ ਉਸ resolver ਦਾ VPC ਦੇ DNS ਦ੍ਰਿਸ਼ ਤੱਕ ਸਮਰਥਿਤ ਮਾਰਗ ਹੈ।

ਮੈਂ ਰਿਕਾਰਡ ਦੇ ਹੋਣ ਦਾ ਸਬੂਤ ਦੇ ਕੇ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ, ਫਿਰ ਬਾਕੀ ਸਮਾਂ ਕੁਐਰੀ ਮਾਰਗ ਉੱਤੇ ਲਾਉਂਦਾ ਹਾਂ। ਇਹ ਵੱਖਰੇ ਸਿਸਟਮ ਹਨ ਅਤੇ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਸ਼ਕਲ ਪੜ੍ਹੋ

ਤਿੰਨ ਨਤੀਜੇ ਤਿੰਨ ਵੱਖਰੀਆਂ ਗੱਲਾਂ ਦਰਸਾਉਂਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਕੁਐਰੀ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦੀ ਹੈ: ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਜਿਹੜਾ resolver ਵਰਤ ਰਿਹਾ ਹੈ ਉਸ ਵਿਰੁੱਧ ਨਾਮ ਲਈ dig ਚਲਾਓ।

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

ਸਮਾਂ ਖ਼ਤਮ ਹੋਣਾ ਨੈੱਟਵਰਕ ਬਾਰੇ ਇੱਕ ਬਿਆਨ ਹੈ। NXDOMAIN DNS ਦ੍ਰਿਸ਼ ਬਾਰੇ ਬਿਆਨ ਹੈ। ਜਨਤਕ ਜਵਾਬ ਨੀਤੀ ਬਾਰੇ ਬਿਆਨ ਹੈ। ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦੇ ਸਮੇਂ ਜ਼ੋਨ ਰਿਕਾਰਡ ਸੋਧਣਾ ਕੇਸ ਦਾ ਇੱਕੋ ਇੱਕ ਲਾਹੇਵੰਦ ਸਬੂਤ ਸੁੱਟ ਦਿੰਦਾ ਹੈ।

VPC ਦਾ ਪਲੱਸ-ਦੋ ਪਤਾ ਦੂਰ ਦਾ resolver ਕਿਉਂ ਨਹੀਂ

CIDR ਪਲੱਸ-ਦੋ ਪਤਾ VPC ਦੇ ਅੰਦਰਲੇ ਸਰੋਤਾਂ ਲਈ ਸਥਾਨਕ ਸੇਵਾ ਹੈ। AWS ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਕਿ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਤੋਂ, ਜਾਂ ਕਿਸੇ ਹੋਰ VPC ਦੇ DNS ਸਰਵਰ ਤੋਂ, ਕੁਐਰੀ ਸਿੱਧੀ ਉਸ ਪਤੇ ਉੱਤੇ ਭੇਜਣਾ ਸਮਰਥਿਤ ਨਹੀਂ ਅਤੇ ਅਸਥਿਰ ਨਤੀਜੇ ਦੇ ਸਕਦਾ ਹੈ।

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

ਮਾਰਗ ਉਸ ਕ੍ਰਮ ਵਿੱਚ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਇਹ ਸਾਫ਼ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ

ਤਿੰਨ ਹੌਪ ਹੋਣੇ ਲਾਜ਼ਮੀ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦਾ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਆਪਣਾ ਤਰੀਕਾ ਹੈ।

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

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

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

ਆਊਟਬਾਊਂਡ ਐਂਡਪੌਇੰਟ ਉਲਟ ਦਿਸ਼ਾ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਤੋਂ ਆਉਣ ਵਾਲੀ ਕੁਐਰੀ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇਵੇਗਾ।

ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ

ਕਲਾਇੰਟ ਤੋਂ ਫਾਰਵਰਡਰ ਵਿਰੁੱਧ ਕੁਐਰੀ ਕਰੋ, ਫਿਰ ਫਾਰਵਰਡਰ ਤੋਂ ਐਂਡਪੌਇੰਟ ਵਿਰੁੱਧ। ਜੇ ਕਲਾਇੰਟ ਫੇਲ੍ਹ ਹੋਵੇ ਤੇ ਫਾਰਵਰਡਰ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਪਾੜਾ ਉਨ੍ਹਾਂ ਦੋਵਾਂ ਵਿਚਕਾਰ ਹੈ।

ਜੇ ਦੋਵੇਂ ਫੇਲ੍ਹ ਹੋਣ, ਤਾਂ ਐਂਡਪੌਇੰਟ ਉੱਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਅਤੇ ਉਹ ਸਰੋਤ ਪਤਾ ਦੇਖੋ ਜੋ ਇਹ ਅਸਲ ਵਿੱਚ ਦੇਖਦਾ ਹੈ। NAT ਪਿੱਛੇ ਦਾ ਫਾਰਵਰਡਰ ਲੈਪਟਾਪ ਦੇ VPN ਪਤੇ ਦੀ ਥਾਂ NAT ਪਤਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕੁਐਰੀ ਸੁੱਟਣ ਲਈ ਕਾਫ਼ੀ ਹੈ। ਜੇ ਦੋਵੇਂ ਸਫਲ ਹੋਣ ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਤਾਂ ਹੋ ਸਕਦਾ ਹੈ ਐਪਲੀਕੇਸ਼ਨ ਤੁਹਾਡੇ ਵੱਲੋਂ ਜਾਂਚੇ ਗਏ ਨਾਲੋਂ ਵੱਖਰਾ resolver ਵਰਤ ਰਹੀ ਹੋਵੇ।

ਜਨਤਕ ਅਤੇ ਨਿੱਜੀ ਨਾਮ-ਥਾਂਵਾਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਵੱਖ ਰੱਖੋ। Split DNS ਉਹ ਨੀਤੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਕਰਦੇ ਹੋ, ਇੱਕ ਖੋਜ ਦੇ ਸੰਜੋਗ ਨਾਲ ਡੇਟਾ ਵਾਪਸ ਕਰਨ ਦਾ ਪਾਸ਼ਵ-ਪ੍ਰਭਾਵ ਨਹੀਂ।

ਜੋ ਮੈਂ ਨਹੀਂ ਕਰਾਂਗਾ

ਅਜਿਹਾ NAT ਨਿਯਮ ਨਹੀਂ ਜੋੜਾਂਗਾ ਜਿਸ ਨੇ ਇੱਕ ਖੋਜ ਚਲਾਈ ਅਤੇ ਉਸ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਹਾਂ।

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

ਸੰਬੰਧਿਤ ਲੇਖ