AWS Client VPN ਵਿੱਚ ਰੁਕ-ਰੁਕ ਕੇ ਪਹੁੰਚ: ਹਰ ਜੁੜੇ ਸਬਨੈੱਟ ਦਾ ਆਡਿਟ ਕਰੋ
ਕੁਝ AWS Client VPN ਸੈਸ਼ਨ ਐਪ ਦੇ VPC ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ ਅਤੇ ਕੁਝ ਸਮਾਂ-ਸਮਾਪਤ ਹੋ ਜਾਂਦੇ ਹਨ। ਪਹਿਲਾਂ ਹਰ ਸੰਸਥਾ ਦੇ VPC ਰੂਟ ਟੇਬਲ ਨਾਲ ਐਂਡਪੌਇੰਟ ਰੂਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।
ਇੱਕ ਵਰਤੋਂਕਾਰ ਕਨੈਕਟ ਹੁੰਦਾ ਹੈ, ਅੰਦਰੂਨੀ ਐਪ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਪਾਉਂਦਾ ਹੈ; ਉਸੇ ਐਂਡਪੌਇੰਟ ’ਤੇ ਇੱਕ ਸਹਿਕਰਮੀ ਨੂੰ ਉਸੇ Wi-Fi ’ਤੇ ਉਸੇ ਵਰਗੇ ਲੈਪਟਾਪ ਤੋਂ ਸਮਾਂ-ਸਮਾਪਤੀ ਮਿਲਦੀ ਹੈ। ਇਹ ਪੈਟਰਨ ਇੱਕ ਤੋਂ ਵੱਧ ਜੁੜੇ ਸਬਨੈੱਟ ਵਾਲੇ client VPN ਐਂਡਪੌਇੰਟ ਦੀ ਪਛਾਣ ਹੈ, ਜਿੱਥੇ ਰਾਹ ਬਰਾਬਰ ਨਹੀਂ ਹਨ। ਮੈਂ ਇਸ ਨੂੰ ਕੰਸੋਲ ਤੋਂ ਬਾਹਰ ਵੱਲ ਦੇਖਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਬਾਕੀ ਜਾਂਚ ਦੇ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਦੋ ਟੈਬ ਤੈਅ ਕਰਦੇ ਹਨ। ਕਲਾਇੰਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਇਸ ਦੀ ਕੋਈ ਵਿਆਖਿਆ ਨਹੀਂ ਹੈ।
ਐਂਡਪੌਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਸੰਸਥਾਵਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ
VPC ਕੰਸੋਲ ਵਿੱਚ Client VPN endpoints ਖੋਲ੍ਹੋ, ਐਂਡਪੌਇੰਟ ਚੁਣੋ ਅਤੇ Associations ਟੈਬ ਪੜ੍ਹੋ। ਹਰ ਸੰਸਥਾ ਉਪਲਬਧਤਾ ਜ਼ੋਨ ਵਿੱਚ ਇੱਕ ਸਬਨੈੱਟ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਬਣਨ ਵੇਲੇ ਸੇਵਾ ਜਿਸ ਨੂੰ ਚੁਣਦੀ ਹੈ ਉਸ ਸਬਨੈੱਟ ’ਤੇ ਕਲਾਇੰਟ ਉਤਰਦਾ ਹੈ। ਸਬਨੈੱਟ ID ਅਤੇ ਹਰ ਇੱਕ ਦੁਆਰਾ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰੂਟ ਟੇਬਲ ਲਿਖੋ, ਕਿਉਂਕਿ ਉਹ ਦੋ ਸੂਚੀਆਂ ਹੀ ਤੁਹਾਡੀ ਆਉਣ ਵਾਲੀ ਤੁਲਨਾ ਹਨ।
ਜੇ ਐਂਡਪੌਇੰਟ ਸਿਰਫ਼ ਇੱਕ ਸੰਸਥਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਿਧਾਂਤ ਗਲਤ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਵਧੀਆ ਸ਼ੱਕੀ ਹੈ।
ਐਂਡਪੌਇੰਟ ਰੂਟ ਟੇਬਲ ਦੀ ਹਰ ਸੰਸਥਾ ਨਾਲ ਤੁਲਨਾ ਕਰੋ
ਉਸੇ ਐਂਡਪੌਇੰਟ ’ਤੇ Route table ਟੈਬ ਖੋਲ੍ਹੋ। ਉੱਥੇ ਹਰ ਮੰਜ਼ਿਲ CIDR ਦਾ ਇੱਕ ਟਾਰਗਿਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ client VPN ਵਿੱਚ ਟਾਰਗਿਟ ਗੇਟਵੇ ਨਹੀਂ ਸਗੋਂ ਸੰਸਥਾ ਹੁੰਦੀ ਹੈ। AWS ਹਰ ਜੁੜੇ ਸਬਨੈੱਟ ਲਈ ਮੰਜ਼ਿਲ ਐਂਟਰੀ ਮੰਗਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਣ ਵਾਲਾ ਰੂਟ ਪਹੁੰਚ ਨੂੰ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਕਿੱਥੇ ਉਤਰਿਆ। ਜਿਸ ਮੰਜ਼ਿਲ ਦੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਲੋੜ ਹੈ ਉਸ ਦੀ ਜਾਂਚ ਕਰੋ, ਫਿਰ ਉਸ ਦਾ ਅਧਿਕਾਰ ਨਿਯਮ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਰੂਟ ਰਾਹ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨਿਯਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਵਰਤ ਸਕਦਾ ਹੈ।
ਦੋਵੇਂ ਪਰਤਾਂ ਨੂੰ ਟੇਬਲ ਵਿੱਚ ਲਿਆਉਣ ਤੋਂ ਬਾਅਦ ਖਰਾਬੀ ਖੁੰਝਾਉਣੀ ਔਖੀ ਹੈ।
| Associated subnet | Endpoint route to 10.200.0.0/16 | VPC route in that subnet |
|---|---|---|
| subnet-aaa | Targets the association | 10.200.0.0/16 to pcx-example |
| subnet-bbb | Targets the association | No matching entry |
ਬਹੁਤੀਆਂ ਟਿਕਟਾਂ ਵਿੱਚ ਦੂਜੀ ਕਤਾਰ ਹੀ ਪੂਰਾ ਬੱਗ ਹੈ। ਐਂਡਪੌਇੰਟ ਰੂਟ ਮੌਜੂਦ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਅੱਗੇ ਨਹੀਂ ਦੇਖਦਾ, ਅਤੇ ਪੈਕੇਟ ਇੱਕ ਹੌਪ ਬਾਅਦ VPC ਦੇ ਅੰਦਰ ਮਰ ਜਾਂਦਾ ਹੈ।
ਹਰ ਸਬਨੈੱਟ ਨੂੰ ਉਸ ਦੇ ਪ੍ਰਭਾਵੀ ਰੂਟ ਟੇਬਲ ਤੱਕ ਲੱਭੋ
ਜਿਸ ਸਬਨੈੱਟ ਦਾ ਸਪੱਸ਼ਟ ਰੂਟ ਟੇਬਲ ਸੰਸਥਾ ਨਹੀਂ ਹੈ ਉਹ VPC ਦਾ ਮੁੱਖ ਟੇਬਲ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ। ਉਹ ਟੇਬਲ ਪੜ੍ਹੋ ਜੋ ਅਸਲ ਵਿੱਚ ਲਾਗੂ ਹੈ, ਉਹ ਨਹੀਂ ਜਿਸ ਦਾ ਨਾਮ ਸਹੀ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਕਤਾਰ ਦੇ ਲੇਬਲ ਦੀ ਥਾਂ ਮੰਜ਼ਿਲ ਅਤੇ ਟਾਰਗਿਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।
AWS ਦੀ ਰੁਕ-ਰੁਕ ਕੇ ਪਹੁੰਚ ਗਾਈਡ ਇਸ ਨੂੰ ਸੰਸਥਾਵਾਂ ਭਰ ਵਿੱਚ ਰੂਟ ਕਵਰੇਜ ਵਜੋਂ ਪੇਸ਼ ਕਰਦੀ ਹੈ, ਜੋ ਸਹੀ ਮਾਡਲ ਹੈ। ਐਂਡਪੌਇੰਟ ਪੈਕੇਟ ਨੂੰ ਇੱਕ ਸਬਨੈੱਟ ਤੱਕ ਪਹੁੰਚਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਸਬਨੈੱਟ ਦੇ ਟੇਬਲ ਨੂੰ ਅਜੇ ਵੀ ਜਾਣਨਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੈੱਟਵਰਕ ਕਿੱਥੇ ਹੈ।
ਗੁੰਮ ਕਤਾਰ ਨੂੰ ਉਸ ਟੇਬਲ ਵਿੱਚ ਠੀਕ ਕਰੋ ਜੋ ਇਸ ਦੀ ਮਾਲਕ ਹੈ। ਕੰਮ ਕਰਦੇ ਸਬਨੈੱਟ ਤੋਂ ਪੂਰਾ ਰੂਟ ਟੇਬਲ ਕਾਪੀ ਕਰਨ ਨਾਲ ਇੰਟਰਨੈੱਟ, ਡਿਵਾਈਸ ਅਤੇ ਅਲੱਗਾਅ ਦੀਆਂ ਚੋਣਾਂ ਵੀ ਕਾਪੀ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਇਸ ਲਈ ਕਦੇ ਨਹੀਂ ਸੋਚੀਆਂ ਗਈਆਂ ਸਨ, ਅਤੇ ਇਹ ਬਦਲਾ ਆਮ ਤੌਰ ’ਤੇ ਤੁਹਾਡੇ ਸ਼ੁਰੂ ਕੀਤੇ ਰੁਕਾਵਟ ਨਾਲੋਂ ਬਦਤਰ ਹੁੰਦਾ ਹੈ।
ਅਧਿਕਾਰ ਨਿਯਮ ਜਾਂਚੋ, ਫਿਰ ਵਾਪਸੀ ਦਾ ਰਾਹ
ਅਧਿਕਾਰ ਨਿਯਮ ਹਰ ਮੰਜ਼ਿਲ ਅਤੇ ਹਰ ਸਮੂਹ ਲਈ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਰੂਟ ਤੋਂ ਵੱਖਰੇ ਮੁੱਲਾਂਕਣ ਹੁੰਦੇ ਹਨ। ਜਿਸ ਮੰਜ਼ਿਲ ਦੇ ਹਰ ਥਾਂ ਰੂਟ ਹਨ ਪਰ ਵਰਤੋਂਕਾਰ ਦੇ ਸਮੂਹ ਲਈ ਨਿਯਮ ਨਹੀਂ, ਉਹ ਸਿਹਤਮੰਦ ਦਿਖਣ ਵਾਲੇ ਰੂਟ ਟੇਬਲ ਨਾਲ ਕਾਲੇ ਛੇਕ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ।
ਵਾਪਸੀ ਦਾ ਰਾਹ ਵੀ ਉਨਾ ਹੀ ਧਿਆਨ ਮੰਗਦਾ ਹੈ। peering ਕਨੈਕਸ਼ਨ ਲਈ ਐਪਲੀਕੇਸ਼ਨ VPC ਵਿੱਚ ਕਲਾਇੰਟ CIDR ਵੱਲ ਵਾਪਸ ਜਾਣ ਵਾਲਾ ਰੂਟ, ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਟ੍ਰੈਫਿਕ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨਿਯਮ ਅਤੇ ਇਸ ਨੂੰ ਨਾ ਸੁੱਟਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ACL ਚਾਹੀਦੇ ਹਨ। ਇੱਕ-ਪਾਸੜ ਪਹੁੰਚ, ਜਿੱਥੇ ping ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ TCP ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ, ਆਮ ਤੌਰ ’ਤੇ VPN ਵੱਲ ਨਹੀਂ ਸਗੋਂ ACL ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੂਹ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।
ਐਂਡਪੌਇੰਟ ਦੇ ਆਪਣੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਸੰਸਥਾ ਦੇ ਲਚਕਦਾਰ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ ’ਤੇ ਬੈਠਦੇ ਹਨ, ਇਸ ਲਈ ਕਲਾਇੰਟ CIDR ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਪੋਰਟ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਸਿਰਫ਼ ਇੰਸਟੈਂਸ ਨਾਲ ਨਹੀਂ, ਸੰਸਥਾ ਨਾਲ ਵੀ ਜੋੜਨਾ ਪਵੇਗਾ।
ਇੱਕ ਖੁਸ਼ਕਿਸਮਤ ਬੇਨਤੀ ਨਾਲ ਨਹੀਂ, ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰੋ
split tunnel ਨਾਲ, ਕਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਹੋਣ ’ਤੇ ਐਂਡਪੌਇੰਟ ਰੂਟ ਭੇਜੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਬਦਲਿਆ ਰੂਟ ਸੈੱਟ ਕਨੈਕਟ ਰਹਿਣ ਵਾਲੇ ਕਲਾਇੰਟ ਤੱਕ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਰਾਹੀਂ ਡਿਸਕਨੈਕਟ ਕਰੋ ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਵੇਂ ਰੂਟ ਮਸ਼ੀਨ ’ਤੇ ਮੌਜੂਦ ਹਨ।
ਅੰਤ ਵਿੱਚ, ਕਨੈਕਸ਼ਨ ਲੌਗ ਨੂੰ ਉਸ ਪਤੇ ਨਾਲ ਸੰਬੰਧਿਤ ਕਰੋ ਜੋ ਕਲਾਇੰਟ ਨੂੰ ਮਿਲਿਆ, ਅਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸੰਸਥਾਵਾਂ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕਾਫ਼ੀ ਵਾਰ ਜਾਂਚ ਦੁਹਰਾਓ। ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਫਲ ਬੇਨਤੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਇੱਕ ਰਾਹ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਿਕਟ ਦੂਜੇ ਬਾਰੇ ਸੀ।