IPsec ਦੇ ਅੰਦਰ IPsec: ਬਾਹਰੀ ਟਨਲ ਕਿਹੜੇ ਪਤੇ ਲੈ ਕੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ

ਨੈਸਟਡ IPsec ਬਾਰੇ ਸੋਚਣਾ ਸੌਖਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਪਰਤਾਂ ਵੱਖਰੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਖਤਮ ਹੁੰਦੀਆਂ ਹਨ। ਚਾਰ ਗੇਟਵੇ, ਦੋ ਟਨਲ ਅਤੇ ਇੱਕ ਸਵਾਲ ਜੋ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨ ਕੰਮ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ: ਅੰਦਰੂਨੀ ਟਨਲ ਪੈਕੇਟ ਨਾਲ ਨਿਪਟਣ ਤੋਂ ਬਾਅਦ ਬਾਹਰੀ ਟਨਲ ਅਸਲ ਵਿੱਚ ਕੀ ਦੇਖਦਾ ਹੈ? ਇਸਦਾ ਜਵਾਬ ਦਿਓ ਅਤੇ ਸਿਲੈਕਟਰ, ਰੂਟ ਅਤੇ ਸਮੱਸਿਆ ਹੱਲ ਕਰਨ ਦਾ ਕ੍ਰਮ ਆਪਣੇ ਆਪ ਆ ਜਾਂਦਾ ਹੈ। ਗਲਤੀ ਕੀਤੀ ਤਾਂ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਚਾਲੂ ਟਨਲ ਨੂੰ ਡੀਬੱਗ ਕਰਨ ਵਿੱਚ ਇੱਕ ਦਿਨ ਲੰਘਾਓਗੇ।

ਚਾਰ-ਗੇਟਵੇ ਮਾਡਲ

ਬਾਹਰੀ ਗੇਟਵੇ A ਅਤੇ B ਦੋ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਪਹਿਲਾ ਟਨਲ ਬਣਾਉਂਦੇ ਹਨ। A ਦੇ ਪਿੱਛੇ ਟਰਾਂਜ਼ਿਟ ਪਤੇ 10.60.0.2 ਵਾਲਾ ਅੰਦਰੂਨੀ ਗੇਟਵੇ C ਹੈ; B ਦੇ ਪਿੱਛੇ ਟਰਾਂਜ਼ਿਟ ਪਤੇ 10.70.0.2 ਵਾਲਾ ਅੰਦਰੂਨੀ ਗੇਟਵੇ D ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੈੱਟਵਰਕ C ਅਤੇ D ਦੇ ਪਿੱਛੇ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਉਦਾਹਰਨ ਦਾ ਹਰ ਪਤਾ ਜਾਣਬੁੱਝ ਕੇ ਓਵਰਲੈਪ ਨਹੀਂ ਕਰਦਾ।

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

ਪਰਤਾਂ ਨੂੰ ਚਾਰ ਹੋਸਟਾਂ ਵਿੱਚ ਵੰਡਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰ ਮਸ਼ੀਨ ਇੱਕ ਹੱਦ ਲਾਗੂ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਪਰਤਾਂ ਇੱਕੋ ਹੋਸਟ 'ਤੇ ਚਲਾਉਣ ਵੇਲੇ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਦੋ ਨੀਤੀ ਸਮੂਹ, ਦੋ ਰੂਟ ਟੇਬਲ ਅਤੇ ਦੋ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗ ਮਿਲਾਉਣੇ ਪੈਂਦੇ ਹਨ, ਜੋ ਸੰਭਵ ਹੈ ਪਰ ਦੇਖਣਾ ਬਹੁਤ ਔਖਾ ਹੈ।

ਹਰ ਪਰਤ ਸਿਰਫ਼ ਆਪਣੀ ਸੁਰੱਖਿਆ ਹਟਾਉਂਦੀ ਹੈ

C, D ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਪੈਕੇਟ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ C ਤੋਂ D ਤੱਕ ਪਤਾ-ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹੀ A ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਅੱਗੇ ਦਾ ਸਭ ਕੁਝ ਉਸੇ ਮੁੜ-ਲਿਖਤ 'ਤੇ ਨਿਰਭਰ ਹੈ।

A ਇਸਨੂੰ B ਲਈ ਦੁਬਾਰਾ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। B ਬਾਹਰੀ ਪਰਤ ਡੀਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ, C ਤੋਂ D ਜਾਂਦਾ ਪੈਕੇਟ ਦੇਖਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਹਾਲੇ ਵੀ ਐਨਕ੍ਰਿਪਟਿਡ ਹੀ ਅੱਗੇ ਭੇਜਦਾ ਹੈ। D ਅੰਦਰੂਨੀ ਸੁਰੱਖਿਆ ਹਟਾ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਪੈਕੇਟ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।

ਇਸ ਲਈ A ਅਤੇ B ਅੰਦਰੂਨੀ ਸਿਰਿਆਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਮੈਟਾਡੇਟਾ ਨੂੰ ਦੇਖਦੇ ਹਨ, ਪਰ ਐਪਲੀਕੇਸ਼ਨ ਪੇਲੋਡ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਵਾਲੇ ਧਿਰ ਨਹੀਂ ਹਨ। ਇਹ ਡਿਜ਼ਾਈਨ ਦਾ ਅਸਲ ਗੁਣ ਹੈ, C, D ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ ਹੋਸਟਾਂ ਦੇ ਭਰੋਸੇਯੋਗ ਹੋਣ ਦਾ ਦਾਅਵਾ ਨਹੀਂ।

ਬਾਹਰੀ ਸਿਲੈਕਟਰ ਅੰਦਰੂਨੀ ਗੇਟਵੇ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ

ਇੱਥੇ ਹੀ ਅਜਿਹੀਆਂ ਬਣਾਵਟਾਂ ਵਿੱਚੋਂ ਬਹੁਤੀਆਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ। ਨੀਤੀ-ਅਧਾਰਿਤ ਬਾਹਰੀ ਟਨਲ ਲਈ, ਤੁਸੀਂ ਜਿਨ੍ਹਾਂ ਸਿਲੈਕਟਰਾਂ 'ਤੇ ਗੱਲਬਾਤ ਕਰਦੇ ਹੋ ਉਨ੍ਹਾਂ ਵਿੱਚ A ਅਤੇ B ਅਸਲ ਵਿੱਚ ਜਿਹੜੇ ਪਤੇ ਸੰਭਾਲਦੇ ਹਨ ਉਹ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: 10.60.0.2/32 ਅਤੇ 10.70.0.2/32, ਸਹੀ ਸਥਾਨਕ ਅਤੇ ਦੂਰਸਥ ਕ੍ਰਮ ਵਿੱਚ।

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

ਬਾਹਰੀ ਇਜਾਜ਼ਤ ਨੂੰ UDP 500 ਤੱਕ ਵੀ ਸੰਕੁਚਿਤ ਨਾ ਕਰੋ। ਅੰਦਰੂਨੀ ਕਨੈਕਸ਼ਨ ਦਾ ਆਪਣਾ ਡੇਟਾ ਮਾਰਗ ਹੈ, ਜੋ ਗੱਲਬਾਤ ਅਨੁਸਾਰ ESP ਜਾਂ UDP ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਬਾਹਰੀ ਨੀਤੀ ਨੂੰ ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਮਨਜ਼ੂਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਹਰ ਗੇਟਵੇ 'ਤੇ swanctl --list-sas ਨਾਲ ਨਤੀਜਾ ਜਾਂਚੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਚਾਈਲਡ ਸੁਰੱਖਿਆ-ਸਬੰਧ ਤੁਹਾਡੇ ਇਰਾਦੇ ਵਾਲੇ ਪਤਿਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ, ਤੁਹਾਡੇ ਮੰਨੇ ਹੋਇਆਂ ਦੀ ਨਹੀਂ। ਜੇ ਸੂਚੀ ਐਪਲੀਕੇਸ਼ਨ ਸਬਨੈੱਟ ਦਿਖਾਉਂਦੀ ਹੈ, ਤਾਂ ਬਾਹਰੀ ਨੀਤੀ ਗਲਤ ਪਰਤ ਲਈ ਲਿਖੀ ਗਈ ਹੈ। ਰੂਟਿੰਗ ਡੀਬੱਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਿਲੈਕਟਰ ਠੀਕ ਕਰੋ, ਕਿਉਂਕਿ ਰੂਟਿੰਗ ਠੀਕ ਦਿਖੇਗੀ ਅਤੇ ਕਾਊਂਟਰ ਨਹੀਂ ਹਿਲਣਗੇ।

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਰੀਕਰਸ਼ਨ ਦਾ ਜਾਲ

ਸਿਲੈਕਟਰ ਰੂਟਿੰਗ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੇ। A ਅਤੇ B ਨੂੰ C ਅਤੇ D ਵਿਚਕਾਰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਫਾਰਵਰਡ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਭਾਵ IP ਫਾਰਵਰਡਿੰਗ ਚਾਲੂ, ਟਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਰੂਟ, ਅਤੇ ਦੂਜੇ ਪਾਸੇ ਮੌਜੂਦ ਵਾਪਸੀ ਮਾਰਗ।

ਜੇ ਬਾਹਰੀ ਟਨਲ XFRM ਇੰਟਰਫੇਸ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਰੂਟ ਇੰਟਰਫੇਸ ਚੁਣਦੇ ਹਨ ਜਦੋਂ ਕਿ ਗੱਲਬਾਤ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਹਾਲੇ ਵੀ ਸੀਮਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕੀ ਢੋਂਦਾ ਹੈ। ਇੰਟਰਫੇਸ ਸੁਰੱਖਿਅਤ ਖੇਤਰ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦਾ; ਇਹ ਸਿਰਫ਼ ਬਦਲਦਾ ਹੈ ਕਿ ਕਰਨਲ ਪੈਕੇਟ ਨੂੰ ਕਿਵੇਂ ਚੁੱਕਦਾ ਹੈ।

ਜਾਲ ਰੀਕਰਸ਼ਨ ਹੈ। A ਦਾ B ਦੇ ਬਾਹਰੀ ਸਿਰੇ ਤੱਕ ਰੂਟ A ਵੱਲੋਂ ਬਣਾਏ ਜਾ ਰਹੇ ਟਨਲ ਦੀ ਨਹੀਂ, ਹੇਠਲੇ ਨੈੱਟਵਰਕ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਹੀਂ ਤਾਂ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਆਪਣੇ ਅੰਦਰ ਹੀ ਸਫ਼ਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਕਨੈਕਸ਼ਨ ਕਦੇ ਪੂਰਾ ਨਹੀਂ ਹੁੰਦਾ।

ਪਰਤਾਂ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਵਾਦ ਜਾਂਚੋ

ਹੋਰ ਕੁਝ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ A ਅਤੇ B 'ਤੇ ਕੋਈ ਵੀ ਸਰੋਤ NAT ਵੇਖੋ। IPsec ਨੀਤੀ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ C ਦਾ ਪਤਾ ਮੁੜ ਲਿਖਣ ਵਾਲਾ ਨਿਯਮ ਸਹਿਮਤ ਸਿਲੈਕਟਰ ਤੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ D ਦੂਜੇ ਪਾਸੇ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਉਹ ਵੀ ਬਦਲ ਸਕਦਾ ਹੈ।

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

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

fail-closed ਸਾਬਤ ਕਰੋ ਅਤੇ MTU ਜਾਂਚੋ

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

ਤਿੰਨ ਹਾਲਤਾਂ ਜਾਂਚੋ: ਬਾਹਰੀ ਟਨਲ ਹੇਠਾਂ, ਅੰਦਰੂਨੀ ਟਨਲ ਹੇਠਾਂ, ਅਤੇ ਦੋਵੇਂ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ ਬਹਾਲੀ। ਹਰ ਗੇਟਵੇ 'ਤੇ ਨੀਤੀ ਕਾਊਂਟਰ ਵਰਤੋ, ਕਿਉਂਕਿ ਦੋ ਸਥਾਪਿਤ IKE ਸੈਸ਼ਨ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਕੰਟਰੋਲ ਤਲ ਦੀ ਗੱਲਬਾਤ ਸਫਲ ਹੋਈ।

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