OpenVPN ਰੂਟ strongSwan XFRM ਨੀਤੀ ਤੋਂ ਕਿਉਂ ਹਾਰਦਾ ਹੈ

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

ਦੋ ਫੈਸਲੇ, ਇੱਕ ਨਹੀਂ

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

ਚੌੜਾ IPsec ਚੋਣਕਰਤਾ ਆਮ ਕਾਰਨ ਹੈ। 172.16.0.0/12 ਦੀ ਸੁਰੱਖਿਆ ਕਰਨ ਵਾਲੀ ਨੀਤੀ 172.20.8.0/24 ਨੂੰ ਵੀ ਢਕਦੀ ਹੈ, ਜਿੱਥੇ ਪ੍ਰਬੰਧਕ ਸ਼ਾਇਦ OpenVPN ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਇਰਾਦਾ ਸਿਰਫ਼ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਹੈ, ਅਤੇ ਨੀਤੀ ਡੇਟਾਬੇਸ ਨੂੰ ਇਸ ਦੀ ਕਦੇ ਜਾਣਕਾਰੀ ਨਹੀਂ ਹੋਈ।

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

ਉਹ ਰੂਟ ਪੜ੍ਹੋ ਜੋ ਕਰਨਲ ਅਸਲ ਵਿੱਚ ਚੁਣਦਾ ਹੈ

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

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

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

ਜੋ ਨੀਤੀ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਉਹ ਪੜ੍ਹੋ

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

ip -s xfrm policy
swanctl --list-sas

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

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

ਜਦੋਂ ਦੋਵੇਂ ਰਾਹ ਜਾਇਜ਼ ਹੋਣ ਤਦ ਤਿੰਨ ਵਿਕਲਪ

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

ਜਦੋਂ ਚੌੜਾ ਚੋਣਕਰਤਾ ਰਹਿਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ ਤਦ ਪਾਸਥਰੂ ਛੋਟ ਸਰਜੀਕਲ ਵਿਕਲਪ ਹੈ। strongSwan ਉਸ ਵੱਖਰੇ ਜੋੜ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਜਿਸਦਾ child pass ਮੋਡ ਵਰਤਦਾ ਹੈ, ਜੋ ਕਰਨਲ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਮਿਲਦੇ ਟ੍ਰੈਫਿਕ ਨੂੰ IPsec ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ। ਲੂਪਬੈਕ ਦੂਰ ਪਤਾ ਉਸ ਜੋੜ ਨੂੰ ਆਉਂਦੇ ਸਾਥੀਆਂ ਲਈ ਚੁਣੇ ਜਾਣ ਤੋਂ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਚੋਣਕਰਤਿਆਂ ਨੂੰ ਸਭ ਕੁਝ ਨਹੀਂ ਸਗੋਂ ਅਸਲ ਅਧਿਕ੍ਰਿਤ ਜੋੜੀ ਦੱਸਣੀ ਚਾਹੀਦੀ ਹੈ।

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

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

ਬਾਕੀ ਨੂੰ ਕਮਜ਼ੋਰ ਕੀਤੇ ਬਿਨਾਂ ਛੋਟ ਸਿੱਧ ਕਰੋ

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

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