AWS Client VPN ਦਾ ਕਲਾਇੰਟ CIDR VPC ਰੇਂਜ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਹੋ ਸਕਦਾ

AWS Client VPN ਐਂਡਪੌਇੰਟ ਤੁਹਾਡੇ ਚੁਣੇ ਪੂਲ ਤੋਂ ਕਲਾਇੰਟ ਪਤੇ ਵੰਡਦਾ ਹੈ, ਅਤੇ AWS ਐਂਡਪੌਇੰਟ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਪੂਲ ਨੂੰ ਟਾਰਗਿਟ ਨੈੱਟਵਰਕ ਨਾਲ ਜਾਂਚਦਾ ਹੈ। ਜਾਂਚ ਇਹ ਨਹੀਂ ਕਿ ਸਬਨੈੱਟ ਖਾਲੀ ਦਿਸਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਹੈ ਕਿ ਪੂਲ VPC ਰੇਂਜ ਨਾਲ ਓਵਰਲੈਪ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਅੱਜ ਕੋਈ EC2 ਇੰਸਟੈਂਸ ਉਹ ਪਤੇ ਵਰਤਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਜਵਾਬ ਉਹੀ ਰਹਿੰਦਾ ਹੈ। ਓਵਰਲੈਪ ਰੇਂਜਾਂ ਦਾ ਸਵਾਲ ਹੈ, ਅਲਾਟਮੈਂਟਾਂ ਦਾ ਨਹੀਂ।

ਪੰਜ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ। ਪਹਿਲੀ ਅਸਫਲ ਜਾਂਚ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਬਾਅਦ ਦਾ ਕੋਈ ਵੀ ਕਦਮ ਪਿਛਲੇ ਫੈਸਲੇ ਨੂੰ ਸੁਧਾਰ ਨਹੀਂ ਸਕਦਾ।

ਓਵਰਲੈਪ ਰੇਂਜਾਂ ਦੀ ਪਰਖ ਹੈ, ਖਾਲੀ ਪਤਿਆਂ ਦੀ ਨਹੀਂ

ਤੁਸੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਸਬਨੈੱਟ ਤੋਂ ਨਹੀਂ, VPC ਦੇ CIDR ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। 172.20.0.0/22 ਦਾ ਪੂਲ 172.20.0.0/16 ਦੇ VPC ਦੇ ਅੰਦਰ ਹੈ ਅਤੇ ਕੋਈ ਸਬਨੈੱਟ ਉਸ ਨੂੰ ਨਾ ਰੋਕੇ ਤਾਂ ਵੀ ਰੱਦ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਓਵਰਲੈਪ ਰੇਂਜਾਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਮੌਜੂਦਾ ਅਲਾਟਮੈਂਟਾਂ ਦੀ ਨਹੀਂ। ਫਿਰ ਉਹ ਮੰਜ਼ਿਲਾਂ ਜੋੜੋ ਜਿੱਥੇ ਐਂਡਪੌਇੰਟ ਰੂਟ ਕਰਦਾ ਹੈ: ਪੀਅਰ VPC, ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ ਅਤੇ ਸਾਈਟ-ਟੂ-ਸਾਈਟ ਕਨੈਕਸ਼ਨ ਰਾਹੀਂ ਆਨ-ਪ੍ਰੀਮਾਈਸਿਜ਼ ਰੇਂਜਾਂ। ਕਲਾਇੰਟ ਨੂੰ ਜਿਸ ਵੀ ਰੇਂਜ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ, ਉਹ ਸੂਚੀ ਵਿੱਚ ਆਉਂਦੀ ਹੈ।

ਉਹ ਯਾਦ ਤੋਂ ਨਹੀਂ, ਖਾਤੇ ਤੋਂ ਇਕੱਠੇ ਕਰੋ: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", ਨਾਲ ਹੀ ਤੁਸੀਂ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ ਉਸ ਸਬਨੈੱਟ ਦੀਆਂ ਰੂਟ ਟੇਬਲ ਐਂਟਰੀਆਂ।

ਪੂਲ ਦਾ ਆਕਾਰ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਹੁੰਦਾ ਹੈ

AWS Client VPN 'ਤੇ /22 ਤੋਂ /12 ਦਰਮਿਆਨ IPv4 ਕਲਾਇੰਟ ਪੂਲ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। /24 ਬਹੁਤ ਛੋਟਾ ਹੈ, /8 ਦਸਤਾਵੇਜ਼ੀ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਹੈ, ਅਤੇ ਦੋਵੇਂ ਗਲਤੀਆਂ ਪੂਲ ਨੂੰ ਵਰਕਲੋਡ ਸਬਨੈੱਟ ਵਾਂਗ ਮਾਪਣ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਸੰਭਾਵਿਤ ਸਮਕਾਲੀ ਕਲਾਇੰਟ ਅਤੇ ਮਾਰਜਿਨ ਨਾਲ ਇਸ ਨੂੰ ਮਾਪੋ, ਫਿਰ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫਿਕਸ ਤੱਕ ਗੋਲ ਕਰੋ।

ਕੰਸੋਲ ਵਿੱਚ ਟਾਈਪ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗਣਿਤ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਗਲਤ ਟਾਈਪ ਕੀਤਾ ਪ੍ਰੀਫਿਕਸ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ ਪੂਲ ਦਾ ਆਕਾਰ ਬਦਲ ਦਿੰਦਾ ਹੈ:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

ਇਹ ਪਤਿਆਂ ਦੀ ਗਿਣਤੀ, ਪ੍ਰੀਫਿਕਸ ਦੀ ਲੰਬਾਈ ਅਤੇ ਇਹ ਛਾਪਦਾ ਹੈ ਕਿ ਉਮੀਦਵਾਰ VPC ਰੇਂਜ ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਜੋ ਤਬਦੀਲੀ ਵਿੰਡੋ ਦੇ ਅੰਤ ਵਿੱਚ ਨੈੱਟਮਾਸਕ ਬਾਰੇ ਸੋਚਣ ਨਾਲੋਂ ਤੇਜ਼ ਹੈ।

ਰਿਜ਼ੋਲਵਰ ਦੀ ਆਪਣੀ ਪਤਾ ਭੂਮਿਕਾ ਹੈ

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

ਰਿਜ਼ੋਲਵਰ, ਕਲਾਇੰਟ ਪੂਲ ਅਤੇ ਜੁੜਿਆ ਸਬਨੈੱਟ ਪਤਾ ਯੋਜਨਾ ਵਿੱਚ ਤਿੰਨ ਵੱਖਰੀਆਂ ਮਦਾਂ ਵਜੋਂ ਦਰਜ ਕਰੋ। ਇਹ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਦਾ ਸਹੀ ਹੋਣਾ ਬਾਕੀ ਦੋ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।

ਬਣਾਉਣ ਵੇਲੇ ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਚਾਰ ਫੀਲਡਾਂ ਲਈ ਵਚਨਬੱਧ ਹੁੰਦੇ ਹੋ

ਕਲਾਇੰਟ IPv4 CIDR ਬਣਾਉਣ ਵੇਲੇ ਸਥਿਰ ਹੁੰਦਾ ਹੈ। DNS ਸਰਵਰ ਬਦਲਣਾ, ਸੰਬੰਧ ਜੋੜਨਾ, ਸੁਰੱਖਿਆ ਸਮੂਹ ਬਦਲਣਾ, ਅਧਿਕਾਰ ਨਿਯਮ ਸੰਪਾਦਿਤ ਕਰਨਾ ਜਾਂ split-tunnel ਰੂਟ ਬਦਲਣਾ ਸਭ ਆਮ ਸੰਪਾਦਨ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੂਲ ਦਾ ਨਾਮ ਨਹੀਂ ਬਦਲਦਾ। ਇਹੀ ਅਸਮਾਨਤਾ ਇਸ ਨੂੰ ਸਮੀਖਿਆ ਦੇ ਯੋਗ ਬਣਾਉਂਦੀ ਹੈ: ਸਸਤੀਆਂ ਸੈਟਿੰਗਾਂ ਬਾਅਦ ਵਿੱਚ ਬਦਲਣ ਵਾਲੀਆਂ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਮਹਿੰਗੀ ਉਹ ਹੈ ਜਿਸ ਲਈ ਤੁਸੀਂ ਪਹਿਲਾਂ ਵਚਨਬੱਧ ਹੁੰਦੇ ਹੋ। ਤਬਦੀਲੀ ਵਿੰਡੋ ਦੀ ਯੋਜਨਾ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਐਂਡਪੌਇੰਟ ਦਾ ਵੇਰਵਾ ਪੜ੍ਹੋ।

ਮੁੜ ਨਿਰਮਾਣ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਤਾਇਨਾਤ ਐਂਡਪੌਇੰਟ ਦੀ ਜਾਂਚ ਕਰੋ। aws ec2 describe-client-vpn-endpoints ਪੂਲ, DNS, split-tunnel ਫਲੈਗ ਅਤੇ ਸੰਬੰਧ ਇੱਕ ਹੀ ਜਵਾਬ ਵਿੱਚ ਮੋੜਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਮੁੜ ਨਿਰਮਾਣ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ ਕਾਫ਼ੀ ਹੁੰਦਾ ਹੈ।

ਐਂਡਪੌਇੰਟ ਨੂੰ ਪੈਚ ਕਰਨ ਦੀ ਬਜਾਏ ਬਦਲੋ

ਨਵਾਂ ਐਂਡਪੌਇੰਟ ਨਵਾਂ ਐਂਡਪੌਇੰਟ ਹੈ, ਸਥਾਨਾਂਤਰਣ ਨਹੀਂ। ਮੌਜੂਦਾ ਸੈਸ਼ਨ ਉਸ 'ਤੇ ਨਹੀਂ ਜਾਂਦੇ, ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਕਿਸੇ ਹੋਰ ਨਾਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਤੁਸੀਂ ਜੋ ਵੀ ਸੈਟਿੰਗ ਸੁਭਾਵਿਕ ਮੰਨੀ ਸੀ ਉਹ ਦੁਬਾਰਾ ਬਣਾਉਣੀ ਪੈਂਦੀ ਹੈ: ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ, ਪ੍ਰਮਾਣੀਕਰਨ, ਸੰਬੰਧ, ਰੂਟ, ਅਧਿਕਾਰ ਸਮੂਹ, ਲੌਗਿੰਗ। ਲਾਜ਼ਮੀ ਨਿੱਜੀ ਸੇਵਾ ਅਤੇ ਰੱਦ ਹੋਣ ਵਾਲੀ ਮੰਜ਼ਿਲ ਦੇ ਸਾਮ੍ਹਣੇ ਇੱਕ ਕਲਾਇੰਟ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਕਰੋ, ਫਿਰ ਪਹੁੰਚ ਵਧਾਓ। ਜੋ ਛੱਡੋਗੇ ਉਹ ਬਾਅਦ ਵਿੱਚ ਸਹਾਇਤਾ ਟਿਕਟ ਬਣ ਜਾਵੇਗਾ।

ਉਹ ਪ੍ਰਮਾਣੀਕਰਨ ਪਾਸ ਹੋਣ ਤੱਕ ਪੁਰਾਣਾ ਐਂਡਪੌਇੰਟ ਚੱਲਦਾ ਰਹਿਣ ਦਿਓ, ਅਤੇ ਨਵੇਂ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲਾ ਪ੍ਰਬੰਧਕੀ ਰਾਹ ਰੱਖੋ।

ਇੱਕ ਸੀਮਾ ਜ਼ਿਕਰਯੋਗ ਹੈ: ਇਹ IPv4 ਕਲਾਇੰਟ ਪੂਲ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ। Client VPN 'ਤੇ dual-stack ਅਤੇ IPv6 ਟ੍ਰੈਫਿਕ ਸੈਟਿੰਗਾਂ ਆਪਣਾ ਵੱਖਰਾ ਐਡਰੈਸਿੰਗ ਮਾਡਲ ਮੰਨਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਸ ਮੋਡ ਦੇ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੇ ਬਿਨਾਂ ਇਸ ਸੂਚੀ ਦੀ ਨਕਲ ਨਾ ਕਰੋ।