L2TP/IPsec ਨੂੰ IPsec ਦੇ ਨਾਲ UDP 1701 ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ

ਜੋ ਫਾਇਰਵਾਲ IKE ਅਤੇ ESP ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ ਪਰ UDP 1701 ਦੀ ਨਹੀਂ, ਉਹ L2TP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਤੋੜਦੇ ਹਨ ਜੋ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। ਕਾਰਨ ਇਹ ਹੈ ਕਿ L2TP ਪਹਿਲੇ ਦੇ ਅੰਦਰ ਚੱਲਣ ਵਾਲਾ ਦੂਜਾ ਪ੍ਰੋਟੋਕੋਲ ਹੈ। IPsec ਇਸ ਅਦਲ-ਬਦਲ ਨੂੰ ਢੋਂਦਾ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ L2TP UDP 1701 ਉੱਤੇ ਆਪਣੀ ਸੁਰੰਗ ਚਲਾਉਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਸਥਾਨਕ ਸਟੈਕ ਨੇ ਅਜੇ ਵੀ ਪਹੁੰਚਾਉਣਾ ਹੁੰਦਾ ਹੈ। ਹਰ ਹੈਡਰ ਕਿੱਥੇ ਦਿਸਦਾ ਹੈ ਇਹ ਜਾਣਨਾ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਸ ਡਿਵਾਈਸ ਨੂੰ ਕਿਹੜਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ।

ਦੋ ਪ੍ਰੋਟੋਕੋਲ, ਦੋ ਪੋਰਟ ਸੈਟ

L2TP/IPsec ਕਨੈਕਸ਼ਨ UDP 500 ਉੱਤੇ IKE, ਜਿੱਥੇ ਅਨੁਵਾਦ ਹੈ ਉੱਥੇ UDP 4500 ਉੱਤੇ NAT ਟ੍ਰਾਵਰਸਲ, ਅਤੇ ਜਿੱਥੇ ਨਹੀਂ ਉੱਥੇ IP ਪ੍ਰੋਟੋਕੋਲ 50 ਵਜੋਂ ESP ਵਰਤਦਾ ਹੈ। L2TP ਆਪ UDP 1701 ਉੱਤੇ ਸੁਰੰਗ ਪ੍ਰੋਟੋਕੋਲ ਹੈ, ਅਤੇ ਇਹ IPsec ਵੱਲੋਂ ਸਾਥੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਚੱਲਦਾ ਹੈ। ਦੋਵੇਂ ਅੱਧ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਬਾਰੇ ਦੱਸਣ ਵਾਲੀਆਂ ਲਾਗ ਲਾਈਨਾਂ ਵੱਖਰੇ ਹਿੱਸਿਆਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਸਿਰਫ਼ ਪਹਿਲੇ ਅੱਧ ਨੂੰ ਢਕਣ ਵਾਲਾ ਨਿਯਮ ਸੈਟ ਅਜਿਹਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਗੱਲਬਾਤ ਕਰਕੇ ਫਿਰ ਸੁਰੰਗ ਪੜਾਅ ਉੱਤੇ ਮਰ ਜਾਂਦਾ ਹੈ।

ਪੋਰਟ ਨੰਬਰ ਆਵਾਜਾਈ ਦੇ ਸਿਰਿਆਂ ਦਾ ਵਰਨਣ ਕਰਦੇ ਹਨ, ਅਤੇ ESP ਬਿਲਕੁਲ ਪੋਰਟ ਨਹੀਂ ਹੈ। ਇਸੇ ਲਈ ਸਿਰਫ਼ TCP ਅਤੇ UDP ਨਿਯਮ ਦੇਣ ਵਾਲਾ ਫਾਇਰਵਾਲ ਇੰਟਰਫੇਸ ਪੂਰੀ IPsec ਨੀਤੀ ਨਹੀਂ ਬਿਆਨ ਕਰ ਸਕਦਾ। ਪ੍ਰੋਟੋਕੋਲ 50 ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਆਗਿਆ ਦੇਣੀ ਪਵੇਗੀ, ਅਤੇ ਸਿਰਫ਼ UDP ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਕਦੇ ਇਸ ਨਾਲ ਨਹੀਂ ਮਿਲੇਗਾ।

ਲਿਫ਼ਾਫ਼ਾ ਹੀ ਪੋਰਟ ਦੀ ਵਿਆਖਿਆ ਕਰਦਾ ਹੈ

ਤਾਰ ਉੱਤੇ, L2TP/IPsec ਕਨੈਕਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ 500 ਉੱਤੇ IKE ਅਤੇ 4500 ਉੱਤੇ ਲਿਪਟਿਆ ESP ਦਿਖਾਉਂਦਾ ਹੈ। UDP 1701 ਹੈਡਰ ਸੁਰੱਖਿਅਤ ਪੇਲੋਡ ਦੇ ਅੰਦਰ ਬੈਠਦਾ ਹੈ, ਇਸੇ ਲਈ ਬਾਹਰਲੇ ਇੰਟਰਫੇਸ ਉੱਤੇ ਕੈਪਚਰ ਇਸ ਨੂੰ ਨਹੀਂ ਦਿਖਾਉਂਦਾ। ਸਥਾਨਕ ਹੋਸਟ ਨੇ ਉਹ ਡੇਟਾਗ੍ਰਾਮ L2TP ਡੈਮਨ ਤੱਕ ਅਜੇ ਵੀ ਪਹੁੰਚਾਉਣਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਪਹੁੰਚਾਉਣਾ ਡੀਕੈਪਸੂਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ 1701 ਨਿਯਮ ਐਂਡਪੁਆਇੰਟ ਦੇ ਆਪਣੇ ਫਾਇਰਵਾਲ ਦਾ ਹੈ, ਭਾਵੇਂ ਕੋਈ ਵੀ ਵਿਚਕਾਰਲਾ ਡੱਬਾ ਉਹ ਪੋਰਟ ਕਦੇ ਨਾ ਵੇਖੇ।

ਪ੍ਰੋਸੈਸਿੰਗ ਦਾ ਕ੍ਰਮ ਬਹੁਤਾ ਉਲਝਣ ਸਮਝਾਉਂਦਾ ਹੈ। ਜੇ ਸਟੈਕ ਹੋਸਟ ਫਿਲਟਰ ਤੋਂ ਪਹਿਲਾਂ IPsec ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਤਾਂ ਡੀਕੈਪਸੂਲੇਟ ਹੋਇਆ L2TP ਪੈਕਟ UDP 1701 ਵਜੋਂ ਮਿਲਦਾ ਹੈ; ਜੇ ਕ੍ਰਮ ਉਲਟਾ ਹੈ, ਤਾਂ ਨਿਯਮ ਸੈਟ ਬਾਹਰਲੇ ਪੋਰਟ ਵੇਖਦਾ ਹੈ। ਦੋਵੇਂ ਵਰਤਾਵ ਵਿਵਹਾਰ ਵਿੱਚ ਮੌਜੂਦ ਹਨ, ਇਸੇ ਲਈ ਉਹੀ ਨਿਯਮ ਸੈਟ ਇੱਕ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਚੱਲਦਾ ਅਤੇ ਦੂਜੇ ਉੱਤੇ ਅਸਫਲ ਹੁੰਦਾ ਦਿਸਦਾ ਹੈ।

ਕ੍ਰਮ ਅਨੁਸਾਰ ਰਾਹ ਜਾਂਚੋ

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

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

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

ਪੋਰਟ ਸਕੈਨ ਕੀ ਨਹੀਂ ਦਿਖਾ ਸਕਦਾ

ਸਹੀ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਸਰਵਰ ਵਿਰੁੱਧ UDP 1701 ਦਾ ਬਾਹਰਲਾ ਸਕੈਨ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ, ਅਤੇ ਇਹੀ ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ ਹੈ। ਪੋਰਟ ਇੰਟਰਨੈੱਟ ਉੱਤੇ ਖੁੱਲ੍ਹਾ ਨਹੀਂ ਹੈ; ਇਸ ਤੱਕ ਸਿਰਫ਼ IPsec ਵੱਲੋਂ ਸਾਥੀ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਹੀ ਪਹੁੰਚਿਆ ਜਾਂਦਾ ਹੈ। ਬੰਦ ਨਤੀਜੇ ਨੂੰ ਖਰਾਬੀ ਮੰਨਣ ਨਾਲ ਉਹ ਪੋਰਟ ਖੁੱਲ੍ਹ ਜਾਂਦਾ ਹੈ ਜੋ ਬੰਦ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਕੈਨ ਸੁਰੰਗ ਦੇ ਅੰਦਰ ਓਨਾ ਹੀ ਨਹੀਂ ਵੇਖ ਸਕਦਾ, ਜਿੰਨਾ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਵੇਖ ਸਕਦਾ।

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