Docker ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਨ ਬਨਾਮ VPN: ਜਵਾਬ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

ਪੂਰੀ ਟਨਲ VPN ਚੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਵੀ ਹੋਸਟ SSH ਨੂੰ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ, ਪਰ ਉਸੇ ਮਸ਼ੀਨ ਉੱਤੇ Docker ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਸੇਵਾ ਚੁੱਪ ਹੋ ਜਾਂਦੀ ਹੈ। ਸੁਣਨ ਵਾਲੇ ਵਿੱਚ ਕੋਈ ਨੁਕਸ ਨਹੀਂ: ਕੰਟੇਨਰ ਚੱਲ ਰਿਹਾ ਹੈ, ਪੋਰਟ ਮੈਪਿੰਗ ਮੌਜੂਦ ਹੈ, ਅਤੇ ਪੈਕੇਟ ਆਉਂਦਾ ਹੈ। ਕੰਟੇਨਰ ਤੰਦਰੁਸਤ ਹੈ ਅਤੇ ਬੇਨਤੀ ਸੱਚਮੁੱਚ ਉਸ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ Linux ਆਪਣਾ ਰਾਹ ਚੁਣਦਿਆਂ ਜਵਾਬ ਕਿੱਥੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਫ਼ਰਕ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚੋਂ ਤੁਹਾਨੂੰ ਕਿਹੜਾ ਚਾਹੀਦਾ ਹੈ।

ਮੰਤਵ NAT ਰਾਹੀਂ ਟਿਊਪਲ ਦਾ ਪਿੱਛਾ ਕਰੋ

ਇੱਕ ਹੋਸਟ ਲਓ 192.0.2.10 ਉੱਤੇ, ਜੋ TCP 2222 ਨੂੰ 172.30.240.5:22 ਉੱਤੇ ਕੰਟੇਨਰ ਤੱਕ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। 198.51.100.25 ਤੋਂ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਕੰਟੇਨਰ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਵਾਦ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਆਪਣੇ ਆਪ ਵਜੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

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

ਸਿਰਫ਼ ਹੋਸਟ ਲਈ ਬਣਿਆ ਨਿਯਮ ਇਹ ਕਿਉਂ ਖੁੰਝ ਜਾਂਦਾ ਹੈ

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

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

DNAT ਤੋਂ ਬਾਅਦ ਦੀ ਮਿਲਾਨ ਇੱਕ ਹੋਰ ਹੁੱਕ ਹੈ

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

ਇਹ ਹੁੱਕ ਉਲਝਣ ਅਜਿਹੇ ਨਿਯਮ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦੇ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ ਮਿਲਦੇ। ਨੀਤੀ ਮੁੜ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਉੱਤੇ ਹੀ ਕਾਊਂਟਰ ਵੇਖੋ। ਜ਼ੀਰੋ ਹਿੱਟ ਵਾਲਾ ਨਿਯਮ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਉਸ ਥਾਂ ਮੁਲਾਂਕਣ ਹੋ ਰਿਹਾ ਹੈ ਜਿੱਥੇ ਪੈਕੇਟ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ।

ਡਿਜ਼ਾਈਨ A: ਫ਼ੈਸਲੇ ਨੂੰ ਕਨੈਕਸ਼ਨ ਅਵਸਥਾ ਵਜੋਂ ਲੈ ਕੇ ਚੱਲੋ

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

1. Docker, VPN ਜਾਂ ਹੋਰ ਨੀਤੀ-ਮਾਲਕ ਨਾਲ ਟਕਰਾਉਂਦੇ ਨਾ ਹੋਣ ਵਾਲਾ ਮਾਰਕ ਖੇਤਰ ਅਤੇ ਨਿਯਮ ਤਰਜੀਹ ਰਾਖਵੇਂ ਰੱਖੋ।
2. ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ ਉਪਲਬਧ ਹੋਣ ਵਾਲੇ DNAT-ਪੂਰਵ ਬਿੰਦੂ ਉੱਤੇ ਸਿਰਫ਼ ਲੋੜੀਂਦਾ ਨਵਾਂ WAN ਕਨੈਕਸ਼ਨ ਪਛਾਣੋ।
3. ਮੂਲ ਬੇਨਤੀ ਨੂੰ ਆਪ WAN ਟੇਬਲ ਵਿੱਚ ਧੱਕੇ ਬਿਨਾਂ ਫ਼ੈਸਲੇ ਨੂੰ ਕਨੈਕਸ਼ਨ ਮਾਰਕ ਉੱਤੇ ਦਰਜ ਕਰੋ।
4. ਜਵਾਬ ਦੀ ਦਿਸ਼ਾ ਵਿੱਚ, ਰੂਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਪੈਕੇਟ ਉੱਤੇ ਸਿਰਫ਼ ਆਪਣੇ ਮਾਰਕ ਬਿੱਟ ਬਹਾਲ ਕਰੋ।
5. VPN ਨਿਯਮ ਪਹਿਲਾਂ ਨਾ ਜਿੱਤ ਸਕੇ ਇਸ ਲਈ ਪੂਰਾ WAN ਟੇਬਲ ਕਾਫ਼ੀ ਜਲਦੀ ਚੁਣੋ।

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

ਡਿਜ਼ਾਈਨ B: ਹੋਸਟ ਉੱਤੇ ਖ਼ਤਮ ਕਰੋ

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

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

ਬਦਲਾਅ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਇਰਾਦੇ ਦੀ ਨਹੀਂ

ਜਨਤਕ ਪਾਸੇ ਤੋਂ ਨਵਾਂ ਅਧਿਕ੍ਰਿਤ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਲੋੜੀਂਦੇ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਫਿਰ ਵੇਖੋ ਕਿ ਕੰਟੇਨਰ ਵੱਲੋਂ ਸ਼ੁਰੂ ਕੀਤੀ ਗਈ ਗੈਰ-ਸੰਬੰਧਿਤ ਬੇਨਤੀ ਅਜੇ ਵੀ VPN ਦੀ ਪਾਲਣਾ ਕਰਦੀ ਹੈ।

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