VPN ਦੇ ਸਮਰਪਿਤ ਪਤੇ 'ਤੇ ਅਸਲ ਵਿੱਚ ਕੌਣ ਜਵਾਬ ਦਿੰਦਾ ਹੈ?

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

ਪਤੇ ਪਿੱਛੇ ਦਾ ਪੈਕਟ ਰਾਹ

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

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

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

ਮਾਡਲ A: ਗੇਟਵੇ ਪਤੇ ਦਾ ਮਾਲਕ ਹੈ

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

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

ਮਾਡਲ B: ਅੱਪਸਟ੍ਰੀਮ ਡਿਵਾਈਸ ਇਸ ਦਾ ਅਨੁਵਾਦ ਕਰਦੀ ਹੈ

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

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

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

ਪਛਾਣ ਬਾਹਰੀ ਪਤਾ ਨਹੀਂ ਹੈ

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

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

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

ਇੱਕ ਕਨੈਕਸ਼ਨ ਵੇਖ ਕੇ ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰ ਕਰੋ

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

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

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