strongSwan ESP-in-UDP: ਜਦੋਂ ਲੱਭਣ ਲਈ ਕੋਈ NAT ਨਾ ਹੋਵੇ

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

ਖੋਜ ਪਤਿਆਂ ਉੱਤੇ ਗਣਿਤ ਹੈ, ਫਾਇਰਵਾਲ ਪਰਖ ਨਹੀਂ

IKEv2 NAT ਖੋਜ ਪੇਲੋਡ ਢੋਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਪਤਿਆਂ ਤੇ ਪੋਰਟਾਂ ਦੇ ਹੈਸ਼ ਹੁੰਦੇ ਹਨ। ਹਰ ਧਿਰ ਮਿਲੇ ਹੋਏ ਦੀ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਦਿਸਦੇ ਨਾਲ ਤੁਲਨਾ ਕਰਦੀ ਹੈ, ਅਤੇ ਅੰਤਰ ਹੋਣ 'ਤੇ ਉਸਨੂੰ ਪਤਾ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਨੇ ਪੈਕਟ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ। ਉਸ ਵਟਾਂਦਰੇ ਵਿੱਚ ਕੁਝ ਵੀ ਇਹ ਨਹੀਂ ਪਰਖਦਾ ਕਿ ਵਿਚਕਾਰਲਾ ਰਾਊਟਰ ਪ੍ਰੋਟੋਕੋਲ 50 ਅੱਗੇ ਭੇਜਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

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

ਇਸ ਲਈ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਤੁਹਾਡੇ ਵੱਲੋਂ ਸੰਰਚਿਤ ਕਨੈਕਸ਼ਨ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਨੈੱਟਵਰਕ ਦੇ ਵਿਵਹਾਰ ਤੋਂ ਧਿਰਾਂ ਦੁਆਰਾ ਗੱਲਬਾਤ ਕੀਤਾ ਨਤੀਜਾ ਨਹੀਂ।

encap ਵਟਾਂਦਰੇ ਨੂੰ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ

ਆਧੁਨਿਕ strongSwan ਤੈਨਾਤੀ ਵਿੱਚ, ਜੋ swanctl.conf ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਹੁੰਦੀ ਹੈ, ਕਨੈਕਸ਼ਨ 'ਤੇ encap = yes ਸੈਟਿੰਗ NAT ਖੋਜ ਵਟਾਂਦਰੇ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀ ਹੈ ਤਾਂ ਜੋ ਦੋਵੇਂ ਧਿਰਾਂ ESP ਲਈ UDP ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਵਰਤਣ। ਸੁਰੱਖਿਅਤ ਪੈਕਟ ਫਿਰ UDP ਅੰਦਰ, ਆਮ ਤੌਰ 'ਤੇ ਪੋਰਟ 4500 'ਤੇ ਸਫਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਇਸ ਪ੍ਰਬੰਧ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਪੈਂਦਾ ਹੈ।

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

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

strongSwan ਦੀ NAT-traversal ਗਾਈਡ ਇਸ ਵਿਵਹਾਰ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, MOBIKE ਵਰਤਣ ਸਮੇਂ ਪੋਰਟ ਫਲੋਟਿੰਗ ਨਾਲ ਸੰਬੰਧ ਸਮੇਤ।

ਆਪਣੇ ਬੈਕਐਂਡ ਦੀ ਆਪਣੀ ਸੈਟਿੰਗ ਵਰਤੋ

strongSwan ਵਿੱਚ ਦੋ ਸੰਰਚਨਾ ਬੈਕਐਂਡ ਹਨ, ਅਤੇ ਚਾਬੀ ਉਨ੍ਹਾਂ ਵਿੱਚ ਵੱਖਰੀ ਹੈ। swanctl.conf ਕਨੈਕਸ਼ਨ encap ਲੈਂਦਾ ਹੈ, ਜਦਕਿ ਪੁਰਾਣਾ ipsec.conf ਕਨੈਕਸ਼ਨ forceencaps ਲੈਂਦਾ ਹੈ। ਇੱਕ ਬੈਕਐਂਡ ਦਾ ਕੀਵਰਡ ਦੂਜੇ ਵਿੱਚ ਪਾਉਣ ਨਾਲ ਅਜਿਹੀ ਸੰਰਚਨਾ ਬਣਦੀ ਹੈ ਜੋ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਲੋਡ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦੀ, ਜੋ ਗਲਤੀ ਤੋਂ ਵੀ ਮਾੜੀ ਹੈ।

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

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

ਲਪੇਟੇ ਡੇਟਾ ਦੀ ਪੜਤਾਲ ਕਰੋ, ਸਿਰਫ ਪੋਰਟ ਦੀ ਨਹੀਂ

ਸੁਰੱਖਿਅਤ ਟ੍ਰੈਫਿਕ ਵਹਿਣ ਸਮੇਂ ਗੇਟਵੇ 'ਤੇ ਕੈਪਚਰ ਕਰੋ, ਫਿਰ ਉਸਦੀ strongSwan ਦੇ ਆਪਣੇ ਦ੍ਰਿਸ਼ ਨਾਲ ਤੁਲਨਾ ਕਰੋ:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

native ESP IP ਪ੍ਰੋਟੋਕੋਲ 50 ਵਜੋਂ ਦਿਸਦਾ ਹੈ ਅਤੇ UDP ਵਰਗਾ ਬਿਲਕੁਲ ਨਹੀਂ ਲੱਗਦਾ। ਲਪੇਟਿਆ ESP 4500 'ਤੇ UDP ਡੇਟਾਗ੍ਰਾਮ ਵਜੋਂ ਦਿਸਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਪੇਲੋਡ IKE ਨਹੀਂ। ਉਸੇ ਪੋਰਟ 'ਤੇ IKE ਟ੍ਰੈਫਿਕ ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ MOBIKE IKE ਨੂੰ ਉੱਥੇ ਲੈ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਮਾਰਗ native ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਪੋਰਟ ਨੰਬਰ ਨਹੀਂ, ਪੇਲੋਡ ਪੜ੍ਹੋ।

ਮਾਰਗ ਦਾ MTU ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ। ਆਵਰਣ ਵਾਧੂ ਖਰਚ ਜੋੜਦਾ ਹੈ, ਅਤੇ native ESP ਢੋਣ ਵਾਲੇ ਮਾਰਗ ਨੂੰ ਪੈਕਟ ਵੱਡੇ ਹੋਣ 'ਤੇ ਸਮਾਯੋਜਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਲੋੜੀਂਦਾ ICMP ਪ੍ਰਬੰਧਨ ਪਹਿਲਾਂ ਹੀ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਇਨਕੈਪਸੂਲੇਸ਼ਨ ਉਹ ਨਿਰਭਰਤਾ ਨਹੀਂ ਹਟਾਉਂਦਾ।

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