AWS Client VPN DNS: subnet ਨਹੀਂ, VPC resolver ਵਰਤੋ

endpoint 10.0.8.0/24 ਵਿੱਚ ਹੈ, ਇਸ ਲਈ resolver 10.0.8.2 ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਸੁਣਿਆ ਤਰਕ ਹੈ ਅਤੇ ਇਹ ਦੋ ਵਾਰ ਗਲਤ ਹੈ। Route 53 Resolver ਪ੍ਰਾਇਮਰੀ VPC IPv4 ਰੇਂਜ ਪਲੱਸ ਦੋ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ 10.0.0.0/16 ਦੇ VPC ਲਈ 10.0.0.2 ਹੈ, endpoint ਕੋਈ ਵੀ subnet ਵਰਤੇ। ਦੂਜੀ ਗਲਤੀ ਵਧੇਰੇ ਚੁੱਪ ਹੈ: endpoint ਵਿੱਚ ਸਹੀ ਪਤਾ ਰੱਖਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ client ਦਾ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕਦੇ ਇਸ ਤੋਂ ਕੁਝ ਪੁੱਛੇ। ਦੋਵੇਂ ਗਲਤੀਆਂ ਇੱਕੋ ਲੱਛਣ ਦਿੰਦੀਆਂ ਹਨ: ਨਾਮ ਹੱਲ ਕੁਝ clientਾਂ ’ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਹੋਰਾਂ ’ਤੇ ਫੇਲ ਹੁੰਦਾ ਹੈ।

ਭਰਮ subnet ਸੰਬੰਧ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

ਸੰਬੰਧ ਇਸ ਗੱਲ ਦਾ ਹੈ ਕਿ client ਕਨੈਕਸ਼ਨਾਂ ਲਈ elastic network interfaces ਕਿੱਥੇ ਰਹਿੰਦੇ ਹਨ, ਇਹ ਨਹੀਂ ਕਿ ਕਿਹੜਾ resolver ਪਤਾ ਮੌਜੂਦ ਹੈ। endpoint ਦੇ subnet clientਾਂ ਨੂੰ VPC ਅੰਦਰ ਪਤਾ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਆਪਣਾ resolver ਨਹੀਂ ਰੱਖਦਾ।

ਜਦੋਂ ਤੁਸੀਂ ਇਹ ਦੋ ਵਿਚਾਰ ਵੱਖ ਕਰਦੇ ਹੋ, ਗਣਿਤ ਰਹੱਸਮਈ ਰਹਿਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ client ਵੱਲ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਕੇਸ ਅਸਲ ਵਿੱਚ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ।

ਪ੍ਰਾਇਮਰੀ VPC ਰੇਂਜ ਤੋਂ ਪਤਾ ਗਿਣੋ

VPC ਦਾ ਪ੍ਰਾਇਮਰੀ IPv4 CIDR ਲਓ ਅਤੇ ਨੈੱਟਵਰਕ ਪਤੇ ਵਿੱਚ ਦੋ ਜੋੜੋ। 10.0.0.0/16 10.0.0.2 ਦਿੰਦਾ ਹੈ, 172.31.0.0/16 172.31.0.2 ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸੈਕੰਡਰੀ ਰੇਂਜ ਵਾਲਾ VPC resolver ਨੂੰ ਪ੍ਰਾਇਮਰੀ ’ਤੇ ਹੀ ਰੱਖਦਾ ਹੈ। ਉਸ VPC ਅੰਦਰ 10.0.8.0/24 ਦਾ subnet ਇਸਨੂੰ ਹਿਲਾਉਂਦਾ ਨਹੀਂ। endpoint ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ VPC ID ਦੇ ਕੋਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਇਹ ਸੰਖਿਆ VPC ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਕਨੈਕਸ਼ਨ ਦੀ ਨਹੀਂ।

VPC link-local ਪਤੇ 169.254.169.253 ’ਤੇ ਵੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਤਾ VPC ਅੰਦਰੋਂ ਪਹੁੰਚਯੋਗ ਹੈ, ਪਰ ਸੁਰੰਗ ਦੇ ਦੂਜੇ ਸਿਰੇ ’ਤੇ ਰੱਖੇ ਲੈਪਟਾਪ ਲਈ ਇਹ ਆਮ ਰੂਟ ਹੋਇਆ ਮੰਜ਼ਿਲ ਨਹੀਂ ਹੈ।

ਇਸ ਲਈ ਦੋ ਵੈਧ resolver ਪਤੇ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ subnet ਪਲੱਸ ਦੋ ਨਹੀਂ ਹੈ।

endpoint ਸੈਟਿੰਗ ਕੀ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

Client VPN endpoint ਵਿੱਚ DNS ਸਰਵਰ ਫੀਲਡ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਿੱਥੇ console VPC resolver ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ ਉੱਥੇ ਉਹੀ ਵਿਚਾਰ ਭਰ ਦਿੰਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਨਾਲ ਕਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਹੋਣ ਵੇਲੇ ਸੇਵਾ clientਾਂ ਨੂੰ ਕੀ ਦਿੰਦੀ ਹੈ ਉਹ ਬਦਲਦਾ ਹੈ। ਇਹ ਨਹੀਂ ਬਦਲਦਾ ਕਿ ਅਣ-ਪ੍ਰਬੰਧਿਤ OpenVPN client ਉਸ ਮੁੱਲ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ client ਨੂੰ ਇਸਨੂੰ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ’ਤੇ ਲਾਗੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। «ਮੇਰੇ Mac ’ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ Linux ਬਾਕਸ ’ਤੇ ਨਹੀਂ» ਇਸੇ ਖਾਲੀ ਥਾਂ ਤੋਂ ਆਉਂਦਾ ਹੈ।

Linux ਵਿੱਚ resolver ਏਕੀਕਰਨ ਕਨੈਕਸ਼ਨ ਮੈਨੇਜਰ ਦੀ ਮਲਕੀਅਤ ਹੈ, ਵਰਤੋਂਕਾਰ ਦੀ ਨਹੀਂ। /etc/resolv.conf ਨੂੰ ਹੱਥ ਨਾਲ ਸੋਧਣਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਪਤਾ ਇੱਕ ਸੈਸ਼ਨ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਮੁੜ ਜੁੜਨ ’ਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ — ਇਸੇ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸੁਧਾਰੇ ਕੇਸ ਅਗਲੀ ਸਵੇਰ ਮੁੜ ਆ ਜਾਂਦੇ ਹਨ।

ਜੁੜਨ ਤੋਂ ਬਾਅਦ client ’ਤੇ ਸਰਗਰਮ resolver ਜਾਂਚੋ, endpoint ਦਾ ਸੰਰਚਨਾ ਪੰਨਾ ਨਹੀਂ।

split tunneling ਸਹੀ resolver ਨੂੰ ਹਰਾ ਸਕਦਾ ਹੈ

split tunneling ਵਿੱਚ ਸਿਰਫ਼ ਸੁਰੰਗ ਵਿੱਚ ਧੱਕੇ ਗਏ ਰਾਹ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਜੇ resolver ਪਤਾ ਕਿਸੇ ਰਾਹ ਨਾਲ ਢਕਿਆ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੁਇਰੀ ਸਥਾਨਕ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀ ਹੈ ਅਤੇ ਤੁਹਾਡਾ ਘਰ ਦਾ ਰਾਊਟਰ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। endpoint ਵਿੱਚ ਪਤਾ ਅਜੇ ਵੀ ਸਹੀ ਹੈ ਅਤੇ ਖੋਜ ਅਜੇ ਵੀ ਫੇਲ ਹੁੰਦੀ ਹੈ। resolver ਲਈ ਰਾਹ ਜੋੜੋ, ਫਿਰ ਦੁਬਾਰਾ ਟੈਸਟ ਕਰੋ।

ਇੱਕ-ਦੂਜੇ ’ਤੇ ਚੜ੍ਹਦੀਆਂ ਸਥਾਨਕ ਰੇਂਜਾਂ ਉਹੀ ਨਤੀਜਾ ਵਧੇਰੇ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੇ ਢੰਗ ਨਾਲ ਦਿੰਦੀਆਂ ਹਨ: ਕੁਇਰੀ ਦਾ ਜਵਾਬ ਆਉਂਦਾ ਹੈ, ਬੱਸ ਗਲਤ ਸਰਵਰ ਤੋਂ।

Amazon DNS ਪਤੇ ਲਈ security groups ਨਾ ਖੋਲ੍ਹੋ

ਖੋਜਾਂ ਦਾ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ’ਤੇ ਸੁਭਾਵਿਕ ਪ੍ਰਵਿਰਤੀ resolver ਪਤੇ ’ਤੇ UDP 53 ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਜੋੜਨਾ ਹੈ। security groups ਅਤੇ network ACL Amazon DNS ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਛਾਂਦੇ ਜਿਵੇਂ ਆਪਣੇ DNS ਇੰਸਟੈਂਸ ਵੱਲ ਦੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਛਾਂਦੇ ਹਨ, ਅਜਿਹਾ AWS ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। ਉਹ ਨਿਯਮ ਖੋਲ੍ਹਣ ਨਾਲ VPC resolver ਲਈ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ ਅਤੇ ਸੀਮਾ ਬਿਨਾਂ ਕਾਰਨ ਚੌੜੀ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਆਪ ਚਲਾਉਂਦੇ resolver ਲਈ ਇਹ ਵੱਖਰਾ ਕੇਸ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸੱਚਮੁੱਚ ਆਪਣੇ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ।

ਜੇ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਦੋਵੇਂ ਹਨ, ਤਾਂ ਕੋਈ ਵੀ ਨਿਯਮ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ client ਅਸਲ ਵਿੱਚ ਕਿਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੈ।

ਰਾਹ ਪਰਖੋ, ਫਿਰ ਕੁਝ ਹੋਰ ਮਾਪੋ

ਇੱਕ ਜਨਤਕ ਨਾਮ ਹੱਲ ਕਰੋ, VPC ਨਾਲ ਜੁੜੇ ਨਿੱਜੀ ਹੋਸਟਿਡ ਜ਼ੋਨ ਵਿੱਚ ਦਰਜ ਨਿੱਜੀ ਨਾਮ ਹੱਲ ਕਰੋ, ਅਤੇ ਦੋਵਾਂ ਵਿਚਕਾਰ client ਦਾ ਸਰਗਰਮ resolver ਪੜ੍ਹੋ। ਇਹ ਕ੍ਰਮ «resolver ਪਤਾ ਗਲਤ ਹੈ» ਨੂੰ «ਜ਼ੋਨ ਜੁੜਿਆ ਨਹੀਂ» ਅਤੇ «client ਨੇ ਸੈਟਿੰਗ ਨਜ਼ਰਅੰਦਾਜ਼ ਕੀਤੀ» ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ। ਹਰੇਕ ਦਾ ਵੱਖਰਾ ਹੱਲ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ throughput ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

ਸਫਲ ਖੋਜ ਨਿਰੰਤਰ ਟ੍ਰਾਂਸਫਰ ਗਤੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਇਸ ਲਈ ਰਿਪੋਰਟ ਕਰਦੇ ਸਮੇਂ ਇਹ ਦੋ ਗੱਲਾਂ ਵੱਖ ਰੱਖੋ।