AWS NAT ਗੇਟਵੇ ਰਾਹੀਂ GRE ਅਤੇ ESP ਕਿਉਂ ਫੇਲ ਹੁੰਦੇ ਹਨ

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

ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦਾ ਸਮੂਹ ਨਹੀਂ ਹੈ

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

AWS ਦਾ NAT ਗੇਟਵੇ ਪ੍ਰੋਟੋਕੋਲ ਵਿਸ਼ੇਸ਼ਣ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾ ਲਈ TCP, UDP ਅਤੇ ICMP ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ। ਇਹੀ ਪੂਰਾ ਸਮਰਥਿਤ ਸਮੂਹ ਹੈ। ਕਿਸੇ ਹੋਰ IP ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਇਜਾਜ਼ਤ ਨਿਯਮ ਇਸਨੂੰ ਵਧਾ ਨਹੀਂ ਸਕਦਾ, ਕਿਉਂਕਿ ਨਿਯਮ ਦਾ ਮੁਲਾਂਕਣ ਗੇਟਵੇ ਦੇ ਅੱਗੇ ਭੇਜਣ ਮਾਰਗ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ।

ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਦੋਵੇਂ ਫੇਲ੍ਹ ਕਲਾਇੰਟ ਵੱਲੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਸੁਧਾਰ ਬਿਲਕੁਲ ਵੱਖਰੇ ਹਨ।

PPTP ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਪੋਰਟ ਟੈਸਟ ਕਿਉਂ ਝੂਠ ਬੋਲਦਾ ਹੈ

ਕੁਝ ਵੀ ਸਾਬਤ ਨਾ ਕਰਨ ਵਾਲੀ ਪੋਰਟ ਜਾਂਚ ਦੀ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਪੁਰਾਣੀ ਉਦਾਹਰਨ PPTP ਹੈ। ਇਹ ਪੋਰਟ 1723 ਉੱਤੇ TCP ਨਿਯੰਤਰਣ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਫਿਰ ਟਨਲ ਡੇਟਾ GRE ਉੱਤੇ ਲੈ ਜਾਂਦਾ ਹੈ, ਜੋ IP ਪ੍ਰੋਟੋਕੋਲ 47 ਹੈ। ਪ੍ਰੋਟੋਕੋਲ 47 TCP ਪੋਰਟ 47 ਨਹੀਂ ਹੈ, ਅਤੇ ਇਨ੍ਹਾਂ ਦੋ ਸੰਖਿਆਵਾਂ ਦਾ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਅੰਕ ਸਾਂਝੇ ਕਰਨ ਤੋਂ ਬਿਨਾਂ ਕੋਈ ਸੰਬੰਧ ਨਹੀਂ।

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

ਇਹੀ ਤਰਕ ਕਿਸੇ ਵੀ ਅਜਿਹੇ ਪ੍ਰੋਟੋਕੋਲ ਉੱਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਜਿਸਦਾ ਨਿਯੰਤਰਣ ਚੈਨਲ TCP ਜਾਂ UDP ਹੈ ਜਦੋਂ ਕਿ ਇਸਦਾ ਡੇਟਾ ਮਾਰਗ ਅਜਿਹਾ ਨਹੀਂ।

IPsec ਸਿਰਫ਼ UDP ਵਜੋਂ ਬਚਦਾ ਹੈ

IPsec ਉਹ ਮਾਮਲਾ ਹੈ ਜਿੱਥੇ ਜਵਾਬ ਸਿੱਧਾ ਨਾਂ ਨਹੀਂ ਬਲਕਿ ਸ਼ਰਤੀ ਹੈ। NAT ਗੇਟਵੇ ਰਾਹੀਂ IPsec ਲਈ NAT ਟ੍ਰਾਵਰਸਲ ਨੂੰ AWS ਸਮਰਥਿਤ ਪ੍ਰਬੰਧ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ। NAT-T ਦੀ ਗੱਲਬਾਤ ਹੋਣ ਤੇ ESP UDP ਦੇ ਅੰਦਰ ਐਨਕੈਪਸੁਲੇਟ ਹੁੰਦਾ ਹੈ ਅਤੇ ਗੇਟਵੇ ਪ੍ਰੋਟੋਕੋਲ 50 ਦੀ ਥਾਂ ਆਮ UDP ਦੇਖਦਾ ਹੈ।

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

TCP ਜਾਂ UDP ਅਧਾਰਿਤ VPN ਦਸਤਾਵੇਜ਼ੀ ਢੋਆ ਸਮੂਹ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਰੂਟਿੰਗ, ਫਿਲਟਰਿੰਗ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕਾਰਨ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ। ਸਮੂਹ ਵਿੱਚ ਫਿੱਟ ਬੈਠਣਾ ਜ਼ਰੂਰੀ ਹੈ, ਕਾਫ਼ੀ ਨਹੀਂ।

ਨੀਤੀ ਵਧਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਰਗ ਜਾਂਚੋ

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

ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕੀਤੇ ਐਂਡਪੌਇੰਟ, ਪਤਾ ਪਰਿਵਾਰ, ਬਾਹਰੀ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ ਜਿੱਥੇ ਪ੍ਰੋਟੋਕੋਲ ਕੋਲ ਪੋਰਟ ਹੈ, ਦਰਜ ਕਰੋ। ਸਫਲ ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੇ ਡਾਇਗਨੋਸਟਿਕਸ ਅਤੇ ਨੈੱਟਵਰਕ ਮਾਲਕ ਦੇ ਪ੍ਰਵਾਹ ਨਿਰੀਖਣ ਵਰਤੋ, ਕਿਉਂਕਿ ਇਹ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ TCP ਅਤੇ UDP ਕੰਮ ਕਰਦੇ ਹਨ। ਇਸ ਤੋਂ ਬਾਅਦ, ਪ੍ਰਵਾਹ ਦੇ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਲਈ ਸੁਰੱਖਿਆ ਗਰੁੱਪ, ਸਬਨੈੱਟ ACL, ਮਹਿਮਾਨ ਫਾਇਰਵਾਲ ਅਤੇ ਸੇਵਾ ਨੀਤੀ ਦੀ ਸਮੀਖਿਆ ਕਰੋ।

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

ਜਦੋਂ ਢੋਆ ਫਿੱਟ ਨਾ ਬੈਠੇ

ਜੇ ਬਾਹਰੀ ਪ੍ਰੋਟੋਕੋਲ ਸਮਰਥਿਤ ਸਮੂਹ ਤੋਂ ਬਾਹਰ ਹੈ, ਤਾਂ ਹੱਲ ਆਰਕੀਟੈਕਚਰਲ ਹੈ: ਉਹ ਢੋਆ ਚੁਣੋ ਜੋ ਮਾਰਗ ਲੈ ਜਾ ਸਕੇ, ਜਾਂ ਈਗ੍ਰੈਸ ਨੂੰ ਉਸ ਚੀਜ਼ ਵੱਲ ਲੈ ਜਾਓ ਜੋ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦਾ ਢੋਂਦੀ ਹੈ। OpenVPN UDP ਉੱਤੇ, WireGuard UDP ਉੱਤੇ ਅਤੇ TLS ਅਧਾਰਿਤ ਟਨਲ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ੀ ਸਮੂਹ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦੇ ਹਨ। ਗਾਹਕ-ਪ੍ਰਬੰਧਿਤ NAT ਇੰਸਟੈਂਸ ਉਹ ਵਿਕਲਪ ਹੈ ਜਦੋਂ ਕੋਈ ਖਾਸ ਪ੍ਰੋਟੋਕੋਲ ਲੰਘਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਚਲਾਉਣ ਦੀ ਸੰਚਾਲਨ ਲਾਗਤ ਸਵੀਕਾਰਯੋਗ ਹੈ।

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

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