EC2 'ਤੇ strongSwan: VPC ਨੂੰ ਕੰਮ ਦਾ ਭਾਰ ਰੂਟ ਕਰਨ ਦਿਓ

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

ਪਹਿਲਾਂ ਚਾਰੋਂ ਪਤੇ ਲਿਖ ਲਓ

ਹੇਠਾਂ ਦਿੱਤਾ ਹਰ ਕਦਮ ਇਨ੍ਹਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਰੂਟਿੰਗ ਟੇਬਲ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਆਪਣੇ ਖਾਤੇ ਲਈ ਭਰੋ।

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

ਉਦਾਹਰਨ ਇੱਕ ਮਨਜ਼ੂਰਸ਼ੁਦਾ, ਕਾਰਜਸ਼ੀਲ ਨੀਤੀ-ਆਧਾਰਿਤ IPsec ਕਨੈਕਸ਼ਨ ਅਤੇ ਸਰੋਤ ਬਚਾਉਣ ਵਾਲੇ ਪ੍ਰਵਾਹ ਦੀ ਧਾਰਨਾ ਲੈਂਦੀ ਹੈ। ਇਹ NAT ਵਾਲਾ ਦੂਰਸਥ ਪਹੁੰਚ ਕਲਾਇੰਟ ਨਹੀਂ ਹੈ ਜੋ ਇੱਕ ਨਿਰਧਾਰਿਤ ਪਤਾ ਉਧਾਰ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਸਿਲੈਕਟਰ ਬਦਲਣੇ ਹਨ ਜਾਂ ਨਹੀਂ।

ਕਦਮ 1: ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਸਬਨੈੱਟ ਨੂੰ ਰੂਟ ਦਿਓ

ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਸਬਨੈੱਟ ਨਾਲ ਅਸਲ ਵਿੱਚ ਜੁੜੀ ਰੂਟਿੰਗ ਟੇਬਲ ਨੂੰ ਦੂਰ ਦੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਅਜਿਹਾ ਰਾਹ ਚਾਹੀਦਾ ਹੈ ਜੋ ਗੇਟਵੇ ਦੇ ਨੈੱਟਵਰਕ ਇੰਟਰਫ਼ੇਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ। ਇੰਸਟੈਂਸ ਦੇ ਅੰਦਰ ਸਥਾਪਿਤ ਮਹਿਮਾਨ ਰੂਟ ਉਸ AWS ਰੂਟਿੰਗ ਟੇਬਲ ਵਿੱਚ ਐਂਟਰੀ ਨਹੀਂ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਮਾਤਰਾ strongSwan ਸੰਰਚਨਾ ਦੀ ਉਹ ਨਹੀਂ ਬਣਾਏਗੀ।

AWS ਦੀ ਡਿਵਾਈਸ ਰਾਹੀਂ ਰੂਟਿੰਗ ਦੀ ਅਗਵਾਈ ਨੈੱਟਵਰਕ ਇੰਟਰਫ਼ੇਸ ਦੇ ਟੀਚਿਆਂ ਅਤੇ ਫ਼ਾਰਵਰਡ ਕਰਨ ਵਾਲੇ ਇੰਸਟੈਂਸ ਦੀ ਸਰੋਤ/ਮੰਜ਼ਿਲ ਜਾਂਚ ਦੀ ਲੋੜ ਦੱਸਦੀ ਹੈ। ਉਸ ਜਾਂਚ ਬਦਲਾਅ ਨੂੰ ਗੇਟਵੇ ਦੀ ਭੂਮਿਕਾ ਤੱਕ ਸੀਮਤ ਰੱਖੋ, ਅਤੇ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਇੰਸਟੈਂਸਾਂ ਨੂੰ ਸ਼ਾਂਤ ਰਹਿਣ ਦਿਓ।

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

ਕਦਮ 2: ਮਹਿਮਾਨ 'ਤੇ ਫ਼ਾਰਵਰਡਿੰਗ ਚਾਲੂ ਕਰੋ

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

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

ਸੁਰੱਖਿਆ ਸਮੂਹ ਉਹ ਥਾਂ ਹਨ ਜਿੱਥੇ ਇਹ ਕਦਮ ਆਮ ਤੌਰ 'ਤੇ ਅਟਕਦਾ ਹੈ। ਵਿਚਕਾਰਲਾ ਯੰਤਰ ਸਿੱਧੇ ਇੰਸਟੈਂਸ ਸੰਚਾਰ ਦੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਹਵਾਲਾ ਵਿਵਹਾਰ ਦਾ ਵਿਰਾਸਤ ਨਹੀਂ ਲੈਂਦਾ, ਇਸ ਲਈ ਪ੍ਰਬੰਧਿਤ Client VPN ਉਦਾਹਰਨ ਤੋਂ ਨਕਲ ਕੀਤਾ ਨਿਯਮ ਕਦੇ ਨਹੀਂ ਮਿਲ ਸਕਦਾ। ਅਸਲ ਰਾਹ 'ਤੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਸੁਰੱਖਿਆ ਸਮੂਹ ਅਤੇ ਸਬਨੈੱਟ ACL ਜਾਂਚੋ।

ਕਦਮ 3: ਸਿਲੈਕਟਰ ਨੂੰ ਅਸਲ ਸਰੋਤਾਂ ਤੱਕ ਫੈਲਾਓ

AWS ਪਾਸੇ ਸਿਰਫ਼ 10.60.1.10/32 ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ਨੀਤੀ 10.60.2.20 ਨੂੰ ਕਵਰ ਕੀਤੇ ਬਿਨਾਂ ਗੇਟਵੇ ਤੋਂ ਸ਼ੁਰੂ ਹੋਈ ਸਫਲਤਾ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਦੂਰ ਦੀ ਮੰਜ਼ਿਲ ਵੱਲ ਰੂਟ ਕਿਸੇ ਟ੍ਰੈਫ਼ਿਕ ਸਿਲੈਕਟਰ ਨੂੰ ਨਹੀਂ ਫੈਲਾਉਂਦਾ, ਅਤੇ ਇਹੀ ਉਸੇ ਹੈਰਾਨੀ ਦਾ ਦੂਜਾ ਅੱਧ ਹੈ।

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

ਜੇ ਸਹਿਮਤ ਡਿਜ਼ਾਈਨ ਪੂਰੇ VPC ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਤਾਂ ਦੋਵੇਂ ਧਿਰਾਂ ਨੂੰ 10.60.0.0/16 ਅਤੇ 10.90.0.0/24 ਮਨਜ਼ੂਰ ਕਰਨੇ ਪੈਣਗੇ। ਜੇ ਇਹ ਇੱਕ ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ, ਤਾਂ ਜਾਣਬੁੱਝ ਕੇ ਉਹੀ ਤੰਗ ਪ੍ਰੀਫਿਕਸ ਵਰਤੋ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਸਥਾਪਿਤ CHILD-SA ਨੀਤੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਸੰਪਾਦਿਤ ਸੰਰਚਨਾ ਅਤੇ ਜਿਸ ਧਿਰ ਨੇ ਇਸ ਨੂੰ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਤੰਗ ਕੀਤਾ, ਉਹ ਇੱਕੋ ਸਮਝੌਤਾ ਨਹੀਂ ਹਨ।

ਦੂਰ ਦੀ ਸਾਈਟ ਨੂੰ ਵੀ ਸੰਭਾਲੇ VPC ਸਰੋਤਾਂ ਦੇ ਜਵਾਬ ਲੋੜੀਂਦੇ IPsec ਗੇਟਵੇ ਰਾਹੀਂ ਵਾਪਸ ਰੂਟ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਜਿੱਥੇ ਹੋਰ ਸਰੋਤ NAT ਨਿਯਮ ਹਨ ਉੱਥੇ ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫ਼ਿਕ ਲਈ ਸਮਰਥਿਤ NAT ਛੋਟ ਬਣਾਈ ਰੱਖੋ; ਕਿਸੇ ਨਾ-ਮਨਜ਼ੂਰ ਕੰਮ ਦੇ ਭਾਰ ਨੂੰ ਮਨਜ਼ੂਰ ਹੋਸਟ ਪਤੇ ਵਿੱਚ ਬਦਲਣਾ ਇੱਕ ਹੋਰ ਪਛਾਣ ਸਮਝੌਤਾ ਹੈ, ਤੁਹਾਡੀ ਚਾਹੀ ਪਹੁੰਚ ਦਾ ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ।

ਕਦਮ 4: ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਲੋੜ ਪਵੇ ਤਾਂ ਵਾਪਸ ਕਰੋ

ਕੰਮ ਦੇ ਭਾਰ ਤੋਂ ਹੀ ਨਵੀਂ ਮਨਜ਼ੂਰ ਐਪਲੀਕੇਸ਼ਨ ਕਾਰਵਾਈ ਨਾਲ ਜਾਂਚੋ, ਫਿਰ ਅਜਿਹੀ ਮੰਜ਼ਿਲ ਨਾਲ ਦੁਹਰਾਓ ਜੋ ਬਾਹਰ ਰੱਖੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੂਰ ਦੀ ਸੇਵਾ ਜੋ ਸਰੋਤ ਪਤਾ ਵੇਖਦੀ ਹੈ ਅਤੇ ਜੋ ਵਾਪਸੀ ਰਾਹ ਵਰਤਦੀ ਹੈ, ਉਹ ਲਿਖੋ। ਗੇਟਵੇ ਨੂੰ ਪਿੰਗ ਜਾਂ ਹਰੀ IKE ਸਥਿਤੀ ਉਹ ਜਾਂਚ ਨਹੀਂ ਹੈ।

ਜੇ ਗੇਟਵੇ ਦੇ ਚੱਲਦਿਆਂ ਵੀ ਕੰਮ ਦਾ ਭਾਰ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਕਦਮਾਂ ਵਿੱਚ ਕ੍ਰਮ ਨਾਲ ਪਿੱਛੇ ਜਾਓ: ਸਿਲੈਕਟਰ, ਫਿਰ ਫ਼ਾਰਵਰਡਿੰਗ ਅਤੇ ਸੁਰੱਖਿਆ ਸਮੂਹ, ਫਿਰ ਜੁੜੀ ਰੂਟਿੰਗ ਟੇਬਲ। ਹਰ ਇੱਕ ਦਾ ਵੱਖਰਾ ਲੱਛਣ ਹੈ, ਅਤੇ ਅੰਦਾਜ਼ਾ ਸੱਚਮੁੱਚ ਗਲਤ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਵਾਪਸ ਕਰਨਾ ਉਹੀ ਕ੍ਰਮ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਕੰਮ ਦੇ ਭਾਰ ਦੀ ਸਬਨੈੱਟ ਦਾ ਰੂਟ ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ ਹਟਾਓ, ਪਿਛਲੇ ਸਿਲੈਕਟਰ ਬਹਾਲ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤਾਂ ਜੋ ਅਜਿਹੀ ਸਬਨੈੱਟ ਨਾ ਛੱਡੋ ਜੋ ਉਸ ਗੇਟਵੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ ਜੋ ਹੁਣ ਉਸ ਦੇ ਸਰੋਤਾਂ ਦੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦਾ। ਜਦੋਂ ਇਹ ਸਮਝੌਤੇ ਟਿਕਦੇ ਹਨ ਤਾਂ ਸਵੈ-ਹੋਸਟਿੰਗ ਗੇਟਵੇ ਹੋਸਟ ਤੋਂ ਵੱਧ ਸੇਵਾ ਦੇ ਸਕਦੀ ਹੈ, ਅਤੇ AWS-ਪ੍ਰਬੰਧਿਤ Site-to-Site VPN ਇੱਕ ਵੱਖਰਾ ਸੰਚਾਲਨ ਮਾਡਲ ਹੈ ਜਿੱਥੇ strongSwan ਗਾਹਕ ਗੇਟਵੇ ਦੇ ਸਿਰੇ 'ਤੇ ਬੈਠ ਸਕਦਾ ਹੈ।