strongSwan trap ਮੋਡ: IPsec ਟਨਲ ਟ੍ਰੈਫਿਕ ਦੀ ਉਡੀਕ ਕਿਉਂ ਕਰਦੀ ਹੈ

ਸਥਿਤੀ ਆਉਟਪੁੱਟ ਵਿੱਚ ਕੋਈ CHILD SA ਨਹੀਂ ਦਿਖਦਾ, ਟਨਲ ਮਰੀ ਹੋਈ ਲੱਗਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਦੂਰ ਦੇ ਸਬਨੈੱਟ ਲਈ ਇੱਕ ping ਇਸਨੂੰ ਉੱਪਰ ਲੈ ਆਉਂਦੀ ਹੈ। ਆਨ-ਡਿਮਾਂਡ IPsec ਸੈੱਟਅੱਪ ਵਿੱਚ ਇਹ ਕ੍ਰਮ ਹੀ ਡਿਜ਼ਾਈਨ ਹੈ, ਖਰਾਬੀ ਨਹੀਂ। trap ਨੀਤੀ ਇੱਕ ਸਿਲੈਕਟਰ ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ ਅਤੇ ਉਡੀਕ ਕਰਦੀ ਹੈ, ਅਤੇ ਇਸ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਪਹਿਲਾ ਪੈਕਟ ਹੀ IKE ਅਤੇ CHILD SA ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਉਲਝਣ ਦਾ ਇੱਕ ਹਿੱਸਾ ਸ਼ਬਦਾਵਲੀ ਹੈ: “up” ਦੋ ਵੱਖਰੀਆਂ ਸਥਿਤੀਆਂ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਕਨਫਿਗਰੇਸ਼ਨ ਲੋਡ ਹੋ ਚੁੱਕੀ ਹੈ ਅਤੇ ਕਰਨਲ ਨੀਤੀ ਮੌਜੂਦ ਹੈ, ਪਰ ਡੇਟਾ ਐਸੋਸੀਏਸ਼ਨ ਨਹੀਂ। ਸਿਰਫ਼ ਸਰਗਰਮ SA ਗਿਣਨ ਵਾਲਾ ਮਾਨੀਟਰ ਸਿਹਤਮੰਦ ਸਾਈਟ ਨੂੰ ਡਾਊਨ ਦੱਸੇਗਾ ਜਦ ਤੱਕ ਕੋਈ ਉੱਥੇ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਭੇਜਦਾ।

ਨਿਸ਼ਕਿਰਿਆ ਆਨ-ਡਿਮਾਂਡ ਟਨਲ ਕੋਲ ਦਿਖਾਉਣ ਲਈ ਕੋਈ CHILD SA ਨਹੀਂ

trap ਐਂਟਰੀ ਆਪਣੇ ਆਪ ਕੁਝ ਵੀ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰਦੀ। ਇਹ ਕਰਨਲ ਨੂੰ ਚੁਣੇ ਗਏ ਟ੍ਰੈਫਿਕ ਲਈ ਨੀਤੀ ਰੱਖਣ ਅਤੇ ਜਦੋਂ ਪੈਕਟ ਨੂੰ ਉਹ ਨੀਤੀ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ acquisition ਚੁੱਕਣ ਲਈ ਕਹਿੰਦੀ ਹੈ। ਡੀਮਨ acquisition ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਇਸਨੂੰ child ਪਰਿਭਾਸ਼ਾ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ ਅਤੇ ਉੱਥੋਂ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਉਸ ਪਲ ਤੱਕ ਦਿਖਾਉਣ ਲਈ IKE SA ਵੀ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਦੋਵੇਂ ਸੂਚੀਆਂ ਇੱਕੋ ਸਮੇਂ ਖਾਲੀ ਹੋ ਸਕਦੀਆਂ ਹਨ।

ਇਹੀ ਕ੍ਰਮ ਲੌਗਾਂ ਨੂੰ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਪਹਿਲਾਂ acquisition ਆਉਂਦੀ ਹੈ, ਫਿਰ IKE_SA_INIT ਅਤੇ IKE_AUTH, ਫਿਰ CHILD SA। ਜੇ ਲੌਗ acquisition ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਟ੍ਰਿਗਰ ਕੰਮ ਕਰ ਗਿਆ। ਗੱਲਬਾਤ ਫੇਲ੍ਹ ਹੋਈ, ਅਤੇ ਅਗਲਾ ਸਵਾਲ trap ਬਾਰੇ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਪ੍ਰਸਤਾਵ ਜਾਂ ਪਹੁੰਚ ਬਾਰੇ ਹੈ।

Linux ਕਰਨਲ ਬੈਕਐਂਡ ਨਾਲ ਤੁਸੀਂ ਕਿਸੇ ਵੀ SA ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ ਦੇਖ ਸਕਦੇ ਹੋ। ਇਹ ਚਲਾਓ ip xfrm policy ਅਤੇ out ਦਿਸ਼ਾ ਅਤੇ ਕਨੈਕਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਟੈਂਪਲੇਟ ਵਾਲਾ ਸਿਲੈਕਟਰ ਲੱਭੋ। ਉਹੀ ਐਂਟਰੀ ਆਨ-ਡਿਮਾਂਡ ਸਥਿਤੀ ਹੈ, ਅਤੇ ਇਸਦੀ ਮੌਜੂਦਗੀ ਪਹਿਲੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਾਲੀ ਗੱਲ ਹੈ।

start_action ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੁਝ ਵੀ ਉਡੀਕ ਕਰੇਗਾ ਜਾਂ ਨਹੀਂ

ਹਰ child swanctl.conf ਵਿੱਚ start_action. start ਕਨਫਿਗਰੇਸ਼ਨ ਲੋਡ ਹੋਣ ਵੇਲੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, trap ਨੀਤੀ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ none ਸ਼ੁਰੂਆਤ ਕਿਸੇ ਹੋਰ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਸਿਰਫ਼ trap ਹੀ ਉੱਪਰ ਦੱਸਿਆ “ping ਅਤੇ ਇਹ ਉੱਪਰ ਆ ਜਾਂਦੀ ਹੈ” ਵਿਵਹਾਰ ਪੈਦਾ ਕਰਦਾ ਹੈ।

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

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

ਇੱਥੇ swanctl.conf ਸੰਦਰਭ ਸਵੀਕਾਰਯੋਗ ਮੁੱਲਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਹੀ ਵੱਖਰੀਆਂ close ਅਤੇ DPD ਕਿਰਿਆਵਾਂ ਜੋ SA ਬਣਨ ਤੋਂ ਬਾਅਦ ਕੀ ਹੁੰਦਾ ਹੈ ਨਿਯੰਤਰਿਤ ਕਰਦੀਆਂ ਹਨ।

ਪਤਾ ਕਰੋ ਕਿ ਟ੍ਰਿਗਰ ਆਖਿਰ ਚੱਲਿਆ ਜਾਂ ਨਹੀਂ

ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: swanctl --list-conns ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ child ਤੁਹਾਡੀ ਇੱਛਤ ਕਿਰਿਆ ਨਾਲ ਲੋਡ ਹੋਇਆ ਹੈ। ਫਿਰ local_ts ਅੰਦਰਲੇ ਹੋਸਟ ਤੋਂ remote_ts ਅੰਦਰਲੇ ਪਤੇ 'ਤੇ ਇੱਕ ਪੈਕਟ ਭੇਜੋ ਅਤੇ swanctl --list-sas ਦੇਖੋ। ਜੇ ਆਉਟਪੁੱਟ ਨਹੀਂ ਬਦਲਦਾ, ਤਾਂ ਕੋਈ acquisition ਡੀਮਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚੀ।

ਸ਼ਾਂਤ trap ਦੇ ਦੋ ਆਮ ਕਾਰਨ: ਪੈਕਟ ਨੀਤੀ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ source-NAT ਹੋ ਗਿਆ ਅਤੇ ਹੁਣ local_ts ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ, ਜਾਂ ਸਿੰਟੈਕਸ ਜਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਦੀ ਗਲਤੀ ਕਾਰਨ ਕਨੈਕਸ਼ਨ ਕਦੇ ਲੋਡ ਨਹੀਂ ਹੋਇਆ। ਸਿਲੈਕਟਰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ swanctl --load-all ਦੁਬਾਰਾ ਚਲਾਓ ਅਤੇ ਇਸਦੀ ਆਉਟਪੁੱਟ ਪੜ੍ਹੋ। ਜੋ ਕਨੈਕਸ਼ਨ ਲੋਡ ਨਹੀਂ ਹੋਇਆ ਉਹ ਕੋਈ ਨੀਤੀ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਟ੍ਰੈਫਿਕ ਕੋਲ ਛੇੜਨ ਲਈ ਕੁਝ ਨਹੀਂ।

ਦਿਸ਼ਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਲਈ ਸਥਾਪਿਤ trap ਅੰਦਰ ਆਉਂਦੇ ਪੈਕਟ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਦੂਰ ਵਾਲਾ ਪਾਸਾ ਟਨਲ ਉੱਪਰ ਲਿਆਉਣਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਆਪਣਾ trap ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਇਸ ਪਾਸੇ ਨੂੰ start.

ਪਹਿਲੇ ਪੈਕਟ ਦੀ ਉਡੀਕ ਕਰਨਾ ਹਮੇਸ਼ਾ ਸਹੀ ਸੌਦਾ ਨਹੀਂ

ਇੰਟਰੈਕਟਿਵ ਸੈਸ਼ਨ ਸੈੱਟਅੱਪ ਦੀ ਲਾਗਤ ਮਹਿਸੂਸ ਕਰਦੇ ਹਨ। ਪਹਿਲੀ ਬੇਨਤੀ IKE ਅਦਲ-ਬਦਲ ਅਤੇ CHILD ਗੱਲਬਾਤ ਦੀ ਕੀਮਤ ਭਰਦੀ ਹੈ, ਅਤੇ ਘੱਟ ਸਮਾਂ-ਸੀਮਾ ਵਾਲਾ ਕਲਾਇੰਟ SA ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਹਾਰ ਮੰਨ ਸਕਦਾ ਹੈ। ਸਰਗਰਮ start ਉਸ ਪਹਿਲੇ-ਪੈਕਟ ਦੇਰੀ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ। ਪਰ ਇਹ ਉਸ ਟ੍ਰੈਫਿਕ ਲਈ ਟਨਲ ਖੁੱਲ੍ਹੀ ਰੱਖਦਾ ਹੈ ਜੋ ਸ਼ਾਇਦ ਕਦੇ ਨਾ ਆਵੇ।

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

ਸਥਾਪਿਤ ਨੀਤੀ ਵੀ ਲੀਕ-ਪਰੂਫ਼ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ। ਜੇ ਲੋੜ fail-closed ਹੈ, ਤਾਂ ਫਾਇਰਵਾਲ ਨੂੰ SA ਤੋਂ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਸੁੱਟਣਾ ਪਵੇਗਾ, ਅਤੇ ਉਹ ਨਿਯਮ child ਪਰਿਭਾਸ਼ਾ ਤੋਂ ਬਾਹਰ ਰਹਿੰਦਾ ਹੈ।

ਅਗਲੀ ਬਹਿਸ ਖਤਮ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਲਾਈਨਾਂ ਲਿਖੋ

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

ਉਸ ਹੋਸਟ ਤੋਂ ਪਰਖੋ ਜੋ ਸੱਚਮੁੱਚ ਸਿਲੈਕਟਰ ਦੇ ਅੰਦਰ ਹੈ। ਰਾਊਟਰ ਤੋਂ ਹੀ ਕੀਤੀ ping ਅਕਸਰ ਵੱਖਰਾ ਰਾਹ ਲੈਂਦੀ ਹੈ ਅਤੇ ਇਸਦੇ ਪਿੱਛੇ ਦੇ ਸਬਨੈੱਟ ਦੀ ਰੱਖਿਆ ਕਰਨ ਵਾਲੀ ਨੀਤੀ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।