ਕਈ ਸਬਨੈੱਟਾਂ ਵਾਲਾ IPsec ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਗੁਆ ਰਿਹਾ ਹੈ? reqid ਗਿਣੋ

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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲੱਛਣ ਨੂੰ ਵੱਖ ਕਰੋ

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

MTU ਨਾਲ ਸ਼ੁਰੂ ਨਾ ਕਰੋ। ਗਲਤ MTU ਰੁਕਾਵਟਾਂ ਅਤੇ ਟੁਕੜੇ ਹੋਣ ਦੇ ਲੱਛਣ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਵਧਦੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਾਊਂਟਰਾਂ ਨਾਲ ਸਾਫ਼ ਦਿਸ਼ਾ ਵੰਡ ਨਹੀਂ।

ਨੀਤੀ ਡੇਟਾਬੇਸ ਅਤੇ ਸਥਿਤੀ ਡੇਟਾਬੇਸ ਪੜ੍ਹੋ

ਲੀਨਕਸ ਵਿੱਚ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦਾ ਫ਼ੈਸਲਾ ਨੀਤੀ ਐਂਟਰੀਆਂ ਕਰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਮਿਲਦੀ ਨੀਤੀ, ਰੂਟ ਨਹੀਂ, ਪੈਕਟ ਨੂੰ ਟਨਲ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ। ip xfrm policy ਚਲਾਓ ਤਾਂ ਜੋ ਹਰ ਐਂਟਰੀ ਦੇ ਚੋਣਕਾਰ, ਦਿਸ਼ਾ, ਤਰਜੀਹ ਅਤੇ ਟੈਂਪਲੇਟ ਵੇਖ ਸਕੋ, ਅਤੇ ip xfrm state ਤਾਂ ਜੋ ਸਥਾਪਿਤ ਸੰਬੰਧ ਉਨ੍ਹਾਂ ਦੇ reqid ਨਾਲ ਵੇਖ ਸਕੋ। ਨੀਤੀ ਅਤੇ ਸੰਬੰਧ ਉਸੇ reqid ਨਾਲ ਜੁੜਦੇ ਹਨ।

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

ਕਲਾਸਿਕ ਅਸਮਾਨਤਾ: ਕਈ ਸਬਨੈੱਟਾਂ ਲਈ ਇੱਕ reqid

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

ਸੁਧਾਰ ਇੱਕ ਸੰਰਚਨਾ ਬਦਲਾਅ ਹੈ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਨਹੀਂ: generate_policy unique; ਹਰ ਨੀਤੀ ਨੂੰ ਉਸਦਾ ਆਪਣਾ reqid ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਾਥੀ ਦੇ ਪ੍ਰਤੀ-ਨੀਤੀ ਸੰਬੰਧਾਂ ਦੇ ਮਿਲਦੇ ਸਾਥੀ ਹੋਣ। ਇਸਨੂੰ ਲਾਗੂ ਕਰੋ, ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਕਰੋ, ਅਤੇ ਸਫਲਤਾ ਦਾ ਐਲਾਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਮੀਦ ਕੀਤੇ ਸਬਨੈੱਟਾਂ ਦੇ ਵੱਖਰੇ reqid ਗਿਣੋ।

ਜੇ ਦੋ ਸਬਨੈੱਟ ਅਜੇ ਵੀ ਇੱਕ reqid ਸਾਂਝਾ ਕਰਦੇ ਹਨ ਜਦੋਂ ਕਿ ਦੂਜਾ ਪਾਸਾ ਦੋ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਅਸਮਾਨਤਾ ਲੱਭ ਲਈ ਹੈ। ਮੈਪਿੰਗ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਸਬੂਤ ਹੈ ਕਿ ਅਗਲੇ ਬਦਲਾਅ ਨੇ ਇਸਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਂ ਕਾਇਮ ਰੱਖਿਆ।

ਚੋਣਕਾਰ ਗੱਲਬਾਤ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਤੋਂ ਨਹੀਂ

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

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

ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਜਾਣੋ ਕਿ ਕਿਵੇਂ ਪਿੱਛੇ ਹਟਣਾ ਹੈ

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

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