strongSwan ਤੋਂ AWS Site-to-Site ਤੱਕ: Child SA ਕੁਝ ਵੀ ਕਿਉਂ ਨਹੀਂ ਚੁਣਦਾ

ਕੰਸੋਲ up ਦਿਖਾਉਂਦਾ ਹੈ, strongSwan ਸਥਾਪਿਤ IKE ਐਸੋਸੀਏਸ਼ਨ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੈਕੇਟ ਫਿਰ ਵੀ ਨਹੀਂ ਪਹੁੰਚਦੇ। ਅਗਲੀ ਤੁਲਨਾ ਵਾਲੀ ਚੀਜ਼ ਪ੍ਰੀ-ਸ਼ੇਅਰਡ ਕੁੰਜੀ ਨਹੀਂ, ਸਗੋਂ ਉਹਨਾਂ ਪ੍ਰੀਫਿਕਸਾਂ ਦੀ ਜੋੜੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਹਰ ਪਾਸਾ ਮੰਨਦਾ ਹੈ ਕਿ ਟਨਲ ਉਹਨਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ, ਕਿਉਂਕਿ ਪਹਿਲੀਆਂ ਦੋ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਟਨਲ ਤੁਹਾਡਾ ਟਰੈਫਿਕ ਬਿਲਕੁਲ ਲੈ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ।

AWS ਦੇ ਨਾਵਾਂ ਨੂੰ strongSwan ਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਬਦਲੋ

AWS ਗਾਹਕ ਪਾਸਿਓਂ ਕਨੈਕਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ: ਗਾਹਕ ਗੇਟਵੇ ਦਾ ਪਤਾ ਅਤੇ ਲੋਕਲ CIDR ਤੁਹਾਡੇ ਹਨ, ਅਤੇ ਰਿਮੋਟ CIDR VPC ਦਾ ਹੈ। strongSwan ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ left ਅਤੇ right ਕਹਿੰਦਾ ਹੈ, ਤੁਹਾਡਾ ਪ੍ਰੀਫਿਕਸ leftsubnet ਵਿੱਚ ਅਤੇ VPC ਦਾ ਪ੍ਰੀਫਿਕਸ rightsubnet ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਜੋੜੀ ਉਲਟਣ ਨਾਲ ਅਜਿਹੀ ਟਨਲ ਬਣਦੀ ਹੈ ਜੋ ਗਲਤ ਟਰੈਫਿਕ ਨਾਲ ਗੱਲਬਾਤ ਕਰਦੀ ਹੈ ਅਤੇ ਉਸਨੂੰ ਚੁਣਦੀ ਹੈ।

AWS ਕਨੈਕਸ਼ਨ ਲਈ ਜੋ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਟਨਲ ਦੇ ਪਤਿਆਂ ਤੇ ਪ੍ਰੀਫਿਕਸਾਂ ਸਮੇਤ ਉਸਨੂੰ ਉਸੇ ਕਨੈਕਸ਼ਨ ਦਾ ਹਵਾਲਾ ਮੰਨੋ। ਬਣਾਉਂਦੇ ਸਮੇਂ ਦੋਵੇਂ CIDR ਖੇਤਰ ਖਾਲੀ ਛੱਡਣ ਤੇ ਸੇਵਾ ਹਰ ਪਾਸੇ 0.0.0.0/0 ਡਿਫਾਲਟ ਵਰਤਦੀ ਹੈ। ਤੰਗ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਸੈੱਟ ਰਾਊਟਰ ਫਿਰ ਕਦੇ ਨਹੀਂ ਮਿਲੇਗਾ, ਇਸ ਲਈ ਖੇਤਰ ਭਰੋ ਜਾਂ ਚੋਣਕਰਤਾ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੌੜਾ ਕਰੋ।

ਇੱਥੇ ਦਾ ਅੰਤਰ ਰਾਊਟਿੰਗ ਫੇਲ੍ਹ ਵਾਂਗ ਦਿਸਦਾ ਹੈ ਅਤੇ ਹੈ ਨਹੀਂ।

AWS ਜੋ ਪਤਾ ਅਸਲ ਵਿੱਚ ਵੇਖਦਾ ਹੈ ਉਹ ਸਥਿਰ ਕਰੋ

NAT ਪਿੱਛੇ ਦਾ ਰਾਊਟਰ IKE ਉਸ ਇੰਟਰਫੇਸ ਤੋਂ ਭੇਜ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਸਾਹਮਣੇ ਵਾਲੇ ਪਾਸੇ ਨੇ ਕਦੇ ਨਹੀਂ ਜਾਣਿਆ। AWS ਵਿੱਚ ਦਰਜ ਗੇਟਵੇ ਪਤਾ ਉਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ AWS ਨੈੱਟਵਰਕ ਤੇ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਰਾਊਟਰ ਨੂੰ ਆਪਣੇ ਡਿਫਾਲਟ ਰਸਤੇ ਦੀ ਥਾਂ ਉਸੇ ਲੋਕਲ ਪਤੇ ਤੇ ਸਥਿਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

conn %default
    local_addrs = 203.0.113.10

strongSwan ਵਿੱਚ local_addrs IKE ਲਈ ਸਰੋਤ ਪਤਾ ਚੁਣਦਾ ਹੈ, ਅਤੇ ਪੁਰਾਣੀਆਂ OpenSwan ਕਨਫਿਗਰੇਸ਼ਨਾਂ ਉਹੀ ਵਿਚਾਰ left ਵਜੋਂ ਲਿਖਦੀਆਂ ਹਨ। ਇਸਨੂੰ ਜਨਤਕ ਪਤਾ ਵਾਲੇ ਇੰਟਰਫੇਸ ਵੱਲ ਨਿਰਦੇਸ਼ਤ ਕਰੋ, ਫਿਰ NAT ਡਿਵਾਈਸ ਤੇ ਹੀ ਜਾਂਚੋ ਕਿ UDP 500 ਅਤੇ 4500 ਉਸ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, ਕਿਉਂਕਿ ਪਿਛਲੇ ਰਾਊਟਰ ਤੋਂ ਬਚਿਆ ਨਿਯਮ ਉਹਨਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਸੁੱਟ ਦਿੰਦਾ ਹੈ। ਸਹੀ ਚੋਣਕਰਤਾ ਜੋੜੀ ਗਲਤ ਸਰੋਤ ਪਤੇ ਨਾਲ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਲਾਗ ਦੋਸ਼ ਪ੍ਰਸਤਾਵ ਤੇ ਪਾਉਂਦਾ ਹੈ। ਇਹੀ ਭੁਲੇਖਾ ਕਾਰਨ ਹੈ ਕਿ ਸਰੋਤ ਪਤੇ ਦੀ ਆਪਣੀ ਜਾਂਚ ਲੋੜੀਂਦੀ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਨੂੰ ਮੰਨਣ ਦੀ ਥਾਂ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ ਪਿਛਲੇ ਰਾਊਟਰ ਲਈ ਸਹੀ ਰਿਹਾ ਨਿਯਮ ਅਕਸਰ ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ।

ਪੜਾਅ 1 ਅਤੇ ਪੜਾਅ 2 ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਸੰਭਾਲੋ

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

ਸਿੰਟੈਕਸ ਲਾਗੂਕਰਨਾਂ ਵਿਚਕਾਰ ਨਹੀਂ ਜਾਂਦਾ। OpenSwan ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੀ ਜੋੜੀ, ਜਿਵੇਂ phase2alg=aes_gcm ਨਾਲ ike=aes256-sha1;modp1024, ਨੂੰ strongSwan ਦੇ esp= ਅਤੇ ike= ਰੂਪ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਐਲਗੋਰਿਦਮ ਦੇ ਨਾਮ ਵੱਖਰੇ ਹਨ। GCM ਐਨਕ੍ਰਿਪਟ ਕਰਦਿਆਂ ਹੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ SHA ਨਾਲ ਜੋੜੀ CBC ਸੈੱਟ ਦੇ ਉਲਟ ਵੱਖਰਾ ਇਕਸਾਰਤਾ ਰੂਪਾਂਤਰਨ ਲੋੜੀਂਦਾ ਨਹੀਂ। ਇੱਕ ਡੈਮਨ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਅਨੁਵਾਦ ਬਿਨਾਂ ਚਿਪਕਾਈ ਪੜਾਅ 2 ਦੀ ਲਾਈਨ ਚੋਣਕਰਤਾ ਅੰਤਰ ਵਰਗਾ ਪੜ੍ਹਿਆ ਜਾਣ ਵਾਲਾ ਇਨਕਾਰ ਪੈਦਾ ਕਰਦੀ ਹੈ।

ਟਨਲ ਸੂਚਕ ਨਹੀਂ, ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਜਾਂਚੋ

ਜੇ ਕਨੈਕਸ਼ਨ ਲੋਡ ਹੁੰਦਾ ਹੈ ਪਰ ਕੋਈ ਚਾਈਲਡ ਐਸੋਸੀਏਸ਼ਨ ਨਹੀਂ ਉੱਠਦੀ, ਤਾਂ ਜਾਂ ਪ੍ਰਸਤਾਵ ਜਾਂ ਚੋਣਕਰਤਾ ਰੱਦ ਹੋਏ ਹਨ। ਜੇ ਚਾਈਲਡ ਉੱਠਦੀ ਹੈ ਅਤੇ ਉਸਦੇ ਚੋਣਕਰਤਾ ਤੁਹਾਡੇ ਪ੍ਰੀਫਿਕਸ ਬਾਹਰ ਰੱਖਦੇ ਹਨ, ਤਾਂ ਪੈਕੇਟ ਟਨਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਫਿਲਟਰ ਹੋ ਜਾਂਦੇ ਹਨ। ਕੰਸੋਲ ਦਾ ਸੂਚਕ ਸਿਰਫ IKE ਪੱਧਰ ਕਵਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੀ ਹੋਇਆ ਇਹ ਨਹੀਂ ਦੱਸ ਸਕਦਾ।

ipsec statusall

ਚਾਈਲਡ ਸੁਰੱਖਿਆ ਐਸੋਸੀਏਸ਼ਨ ਲੱਭੋ ਅਤੇ ਉਸਦੇ ਕੋਲ ਛਾਪੇ ਟਰੈਫਿਕ ਚੋਣਕਰਤਾ ਪੜ੍ਹੋ, ਫਿਰ ਉਹਨਾਂ ਦੀ ਬਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਪ੍ਰੀਫਿਕਸਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।

ਲੋਕਲ ਪ੍ਰੀਫਿਕਸ ਅੰਦਰਲੇ ਹੋਸਟ ਤੋਂ VPC ਪ੍ਰੀਫਿਕਸ ਅੰਦਰਲੇ ਹੋਸਟ ਤੱਕ ਪਰਖ ਕਰੋ ਅਤੇ ਵਾਪਸੀ ਰਸਤਾ ਤੇ AWS ਪਾਸੇ ਦਾ ਕੋਈ ਵੀ ਸੁਰੱਖਿਆ ਸਮੂਹ ਜਾਂ ਨੈੱਟਵਰਕ ACL ਜਾਂਚੋ। ਸਹੀ ਚੋਣਕਰਤਾ ਪੈਕੇਟ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸੁੱਟੇ ਜਾਣ ਤੋਂ ਨਹੀਂ ਬਚਾਉਂਦੇ।

ਚੋਣਕਰਤਾ ਮਿਲਣ ਤੋਂ ਬਾਅਦ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ ਤਾਂ

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

ਹੋਰ ਪ੍ਰਸਤਾਵ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਪਾਸੇ ਇੱਕ ਆਉਂਦਾ ਤੇ ਇੱਕ ਜਾਂਦਾ ਪੈਕੇਟ ਲਾਗ ਕਰੋ।

ਟਿਕਟ ਵਿੱਚ ਚੋਣਕਰਤਾ, ਪੜਾਅ 1 ਤੇ ਪੜਾਅ 2 ਦੇ ਪ੍ਰਸਤਾਵ ਅਤੇ ਸਰੋਤ ਪਤਾ ਲਿਖੋ। ਇਹ ਚਾਰ ਮੁੱਲ ਕਾਲ ਤੋਂ ਬਿਨਾਂ ਹੀ ਜ਼ਿਆਦਾਤਰ site-to-site ਫੇਲ੍ਹਤਾ ਸਮਝਾ ਦਿੰਦੇ ਹਨ।