EC2 ਤੁਹਾਡੇ AWS Client VPN ਲੈਪਟਾਪ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ
Client VPN IPv4 ਕਲਾਇੰਟ ਸਰੋਤਾਂ ਨੂੰ endpoint ਦੇ ਇੰਟਰਫ਼ੇਸ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ। ਇਸੇ ਲਈ ਜਵਾਬ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ EC2 ਤੋਂ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਨਹੀਂ।
AWS Client VPN ਰਾਹੀਂ ਜੁੜਿਆ ਲੈਪਟਾਪ ਬਿਨਾਂ ਕਿਸੇ ਦਿੱਕਤ ਦੇ EC2 ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਤੁਸੀਂ ਉਲਟਾ ਯਤਨ ਕਰਦੇ ਹੋ, EC2 ਤੋਂ ਕਲਾਇੰਟ ਨੂੰ ਦਿੱਤੇ ਪਤੇ ਤੱਕ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਅਟਕ ਜਾਂਦਾ ਹੈ ਜਾਂ ਅਸਵੀਕਾਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਹ ਅਸਮਾਨਤਾ ਘੱਟ ਹੀ ਕਿਸੇ ਗੁੰਮ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨਿਯਮ ਕਰਕੇ ਹੁੰਦੀ ਹੈ। VPC ਸਬਨੈੱਟਾਂ ਨਾਲ ਜੁੜੇ Client VPN endpoint ਉੱਤੇ AWS IPv4 ਕਲਾਇੰਟ ਸਰੋਤਾਂ ਨੂੰ endpoint ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫ਼ੇਸ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਨ ਵਾਲਾ ਕੋਈ ਇਨਬਾਊਂਡ VPC ਪਤਾ ਨਹੀਂ ਹੈ।
ਕੈਪਚਰ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ
ਕਲਾਇੰਟ ਜੁੜਦੇ ਸਮੇਂ EC2 ਹੋਸਟ ਉੱਤੇ ਕੈਪਚਰ ਲਓ ਅਤੇ ਉਹ ਸਰੋਤ ਪਤਾ ਪੜ੍ਹੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਵੇਖਦਾ ਹੈ। ਜੇ ਉਹ ਕਲਾਇੰਟ ਪੂਲ ਦਾ ਪਤਾ ਨਹੀਂ ਸਗੋਂ VPC ਪਾਸੇ ਦਾ endpoint ਇੰਟਰਫ਼ੇਸ ਹੈ, ਤਾਂ ਇੱਕ ਵੀ ਨਿਯਮ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਵਾਦ ਪੁਸ਼ਟ ਹੋ ਚੁੱਕਾ ਹੈ।
ਕਲਾਇੰਟ ਪੂਲ ਇੱਕ ਅਲਾਟਮੈਂਟ ਰੇਂਜ ਹੈ, ਵਾਪਸੀ ਰਸਤੇ ਵਾਲਾ ਸਬਨੈੱਟ ਨਹੀਂ। ਇਸੇ ਫ਼ਰਕ ਉੱਤੇ ਅਜਿਹੀਆਂ ਜਾਂਚਾਂ ਦਾ ਬਹੁਤਾ ਹਿੱਸਾ ਗ਼ਲਤ ਹੁੰਦਾ ਹੈ।
ਅਸਮਾਨਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਨ ਵਾਲਾ ਅਨੁਵਾਦ
ਤਿੰਨ ਪ੍ਰਵਾਹ ਆਪਸ ਵਿੱਚ ਉਲਝਾਏ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਉਹ ਹੈ ਜੋ ਲੋਕ ਪਰਖਦੇ ਹਨ।
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN ਕੰਪੋਨੈਂਟਾਂ ਦਾ ਵੇਰਵਾ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ ਕਿ IPv4 ਕਲਾਇੰਟ ਸਰੋਤ endpoint ਇੰਟਰਫ਼ੇਸ ਵਿੱਚ ਅਨੁਵਾਦ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਵੇਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ ਕਿ ਵਿਚਕਾਰਲੀ ਕਤਾਰ ਕੋਲ ਮਿਲਾਉਣ ਲਈ ਕੁਝ ਕਿਉਂ ਨਹੀਂ।
ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਨੂੰ ਰਸਤਾ, ਪਤੇ ਦੇ ਹੱਲ ਦਾ ਕਦਮ ਅਤੇ ਅਧਿਕਾਰ ਦਾ ਫ਼ੈਸਲਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਦੇ ਸੈਸ਼ਨ ਤੋਂ ਅਨੁਵਾਦ ਦੀ ਸਥਿਤੀ ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਹੀਂ ਦਿੰਦੀ।
ਜਵਾਬ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਕਿਉਂ ਨਹੀਂ
TCP ਜਵਾਬ ਮੌਜੂਦਾ ਐਂਟਰੀ ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਸੇ ਲਈ ਕੋਈ ਵੀ ਇਨਬਾਊਂਡ ਨਿਯਮ ਨਾ ਹੋਣ 'ਤੇ ਵੀ ਵਾਪਸੀ ਦਾ ਰਸਤਾ ਕੰਮ ਕਰਦਾ ਹੈ। EC2 ਹੋਸਟ ਤੋਂ ਆਇਆ ਨਵਾਂ SYN ਮਿਲਾਉਣ ਲਈ ਐਂਟਰੀ ਨਹੀਂ ਲੱਭਦਾ, ਇਸ ਲਈ ਉਹ VPC ਨੂੰ ਪਹੁੰਚਣ ਦਾ ਤਰੀਕਾ ਨਾ ਆਉਣ ਵਾਲੇ ਮੰਜ਼ਿਲ ਵੱਲ ਆਮ ਆਊਟਬਾਊਂਡ ਯਤਨ ਬਣ ਜਾਂਦਾ ਹੈ।
ਇਸੇ ਲਈ ਇਸਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਪਾਸੇ ਜਾਣ ਵਾਲੀ ਟ੍ਰੈਫ਼ਿਕ ਕਹਿਣਾ ਭਰਮਾਊ ਹੈ। ਇਨ੍ਹਾਂ ਸੈਸ਼ਨਾਂ ਵਿੱਚ ਵਾਪਸੀ ਟ੍ਰੈਫ਼ਿਕ ਲਗਾਤਾਰ ਵਹਿੰਦੀ ਹੈ। ਰਸਤੇ ਤੋਂ ਬਿਨਾਂ ਹਿੱਸਾ ਸ਼ੁਰੂਆਤ ਹੈ।
ਜਿਸ ਸੈਸ਼ਨ ਨੂੰ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਉਸਨੂੰ ਹਾਲੇ ਵੀ ਕੀ ਤੋੜਦਾ ਹੈ
ਸੁਰੱਖਿਆ ਸਮੂਹ, ਨੈੱਟਵਰਕ ACL ਅਤੇ ਲੈਪਟਾਪ ਦਾ ਆਪਣਾ ਫਾਇਰਵਾਲ — ਜਿਹੜੇ ਕਨੈਕਸ਼ਨ ਸਫਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਉਨ੍ਹਾਂ ਲਈ ਇਹ ਸਭ ਮਹੱਤਵਪੂਰਨ ਹਨ। ਅਸਫਲ ping ਸਭ ਤੋਂ ਘੱਟ ਦੱਸਦਾ ਹੈ, ਕਿਉਂਕਿ ICMP ਨੀਤੀ ਅਕਸਰ ਤੁਹਾਡੀ ਲੋੜ ਵਾਲੀ TCP ਨੀਤੀ ਤੋਂ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ।
ਇਹ ਨਿਯਮ ਅਨੁਵਾਦਿਤ ਸਰੋਤ ਦੇ ਆਧਾਰ 'ਤੇ ਲਿਖੋ, ਕਲਾਇੰਟ ਪਤੇ ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ। ਨੈੱਟਵਰਕ 'ਤੇ ਕਦੇ ਨਾ ਦਿਸਣ ਵਾਲੇ ਪਤੇ ਨਾਲ ਬੱਝੇ ਨਿਯਮ ਇਸ ਡਿਜ਼ਾਇਨ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਆਪਣੇ ਆਪ ਪੈਦਾ ਕੀਤੀ ਖ਼ਰਾਬੀ ਹਨ।
ਜਦੋਂ VPC ਨੂੰ ਸੱਚਮੁੱਚ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰਨੀ ਪਵੇ
ਜੇ ਕਿਸੇ ਸੇਵਾ ਨੂੰ ਕਿਸੇ ਵਰਕਸਟੇਸ਼ਨ ਨੂੰ ਦੱਸਣਾ ਪਵੇ, ਤਾਂ ਦਿਸ਼ਾ ਉਲਟੋ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਸਥਾਈ ਆਊਟਬਾਊਂਡ ਚੈਨਲ ਰੱਖਣ ਦਿਓ ਜਿਸ 'ਤੇ ਸੇਵਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਜੇ ਪੂਰਾ ਦੂਰਸਥ ਨੈੱਟਵਰਕ VPC ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ Client VPN ਪਹਿਲਾਂ ਹੀ ਇਹ ਕਰਦਾ ਹੈ ਮੰਨਣ ਦੀ ਥਾਂ ਅਜਿਹੀ ਆਰਕੀਟੈਕਚਰ ਚੁਣੋ ਜੋ ਆਪਣੇ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਪਹੁੰਚ ਨੀਤੀ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇ। ਕਲਾਇੰਟ-ਤੋਂ-ਕਲਾਇੰਟ ਪਹੁੰਚ ਤੀਜਾ, ਹੋਰ ਤੰਗ ਕੇਸ ਹੈ, ਜਿਸਦੇ ਆਪਣੇ ਰਸਤਾ ਅਤੇ ਅਧਿਕਾਰ ਆਬਜੈਕਟ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਮੌਜੂਦਾ endpoint 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਚੈਕਬਾਕਸ ਨਹੀਂ।
IPv4 ਵਿਆਖਿਆ ਦਾ ਦਾਇਰਾ ਵੀ ਇਮਾਨਦਾਰ ਰੱਖੋ। ਮੌਜੂਦਾ AWS ਦਸਤਾਵੇਜ਼ IPv6 ਨੂੰ ਵੱਖਰਾ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਉਹ ਅਨੁਵਾਦ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਹੋਰ ਕਨੈਕਸ਼ਨ ਮਾਡਲ ਵੀ ਜੋ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਰਸਤਾ ਦਿੰਦੇ ਹਨ।
ਤਿੰਨ ਲੇਬਲ ਕੀਤੇ ਕਦਮਾਂ ਵਿੱਚ ਪਰਖੋ: ਕਲਾਇੰਟ ਪ੍ਰਵਾਨਿਤ ਸੈਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, VPC ਸੇਵਾ ਉਸ ਸੈਸ਼ਨ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਅਤੇ VPC ਹੋਸਟ ਕਲਾਇੰਟ ਵੱਲ ਨਵਾਂ ਸੈਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ। ਪਹਿਲੇ ਦੋ ਸਫਲ ਹੋਣ ਅਤੇ ਤੀਜਾ ਅਸਫਲ ਹੋਣਾ ਇਸ ਡਿਜ਼ਾਇਨ ਦਾ ਉਮੀਦ ਕੀਤਾ ਰੂਪ ਹੈ, ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਨਾਲ ਪਿੱਛਾ ਕਰਨ ਵਾਲੀ ਖ਼ਰਾਬੀ ਨਹੀਂ।