Docker ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ VPN ਸਰੋਤ: ਦੋ ਮੇਲ ਜੋ ਤੁਸੀਂ ਖੁੰਝਾਉਂਦੇ ਹੋ

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

ਕਥਾ: VPN ਸਰਵਰ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰੋ ਅਤੇ ਕੰਮ ਖ਼ਤਮ

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

ਇਸ ਲਈ VPN ਸਰਵਰ IP ਵਾਕਾਂਸ਼ ਇੱਕ ਅਨੁਮਾਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਨਿਰੀਖਣ ਦਾ ਨਹੀਂ। ਜਦ ਤੱਕ ਤੁਸੀਂ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਹੈ, ਨਿਯਮ ਇੱਕ ਅੰਦਾਜ਼ਾ ਹੈ।

ਸਰੋਤ: ਕਲਾਇੰਟ ਪੂਲ ਜਾਂ ਅਨੁਵਾਦਿਤ ਗੇਟਵੇ

ਚਾਰ ਗੱਲਾਂ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ। ਪਹਿਲੀ, ਕਲਾਇੰਟ ਪਤਾ ਪੂਲ, ਉਦਾਹਰਨ ਲਈ 10.90.0.0/24। ਦੂਜੀ, ਕੀ ਗੇਟਵੇ ਉਸ ਪੂਲ ਦਾ ਅਨੁਵਾਦ ਹੋਸਟ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਕਰਦਾ ਹੈ। ਤੀਜੀ, ਉਹ ਸਰੋਤ ਜੋ ਹੋਸਟ ਇੱਕ ਨਵੇਂ ਕਨੈਕਸ਼ਨ ਲਈ ਅਸਲ ਵਿੱਚ ਦੇਖਦਾ ਹੈ। ਚੌਥੀ, ਕੀ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿਅਕਤੀਗਤ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਵੱਖਰਾ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਸਾਂਝਾ ਅਨੁਵਾਦਿਤ ਪਤਾ ਇਹ ਨਹੀਂ ਕਰ ਸਕਦਾ।

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

ਪੋਰਟ: DNAT ਉਹ ਸੰਖਿਆ ਬਦਲਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਮਿਲਾਉਂਦੇ ਹੋ

Docker iptables ਨਾਲ ਆਮ Linux ਬ੍ਰਿਜ ਪ੍ਰਕਾਸ਼ਨ ਵਿੱਚ, 8443 ਤੋਂ ਕੰਟੇਨਰ ਪੋਰਟ 443 ਤੱਕ ਹੋਸਟ ਮੈਪਿੰਗ ਫਾਰਵਰਡਿੰਗ ਫਿਲਟਰ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਵਾਦ ਹੋ ਜਾਂਦੀ ਹੈ। ਪੈਕੇਟ ਫਿਲਟਰ ਕੋਲ ਗੰਤਵ ਪੋਰਟ 443 ਨਾਲ ਪਹੁੰਚਦਾ ਹੈ। ਉਸ ਬਿੰਦੂ ’ਤੇ 8443 ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਨਿਯਮ ਕਦੇ ਸਰਗਰਮ ਨਹੀਂ ਹੁੰਦਾ, ਭਾਵੇਂ ਕਲਾਇੰਟ ਨੇ 8443 ਲਿਖਿਆ ਹੋਵੇ।

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

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

ਚੇਨ: INPUT ਨਹੀਂ, DOCKER-USER

Docker ਦੀ iptables ਗਾਈਡ ਵਰਤੋਂਕਾਰ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ DOCKER-USER ਚੇਨ ਵਿੱਚ ਰੱਖਦੀ ਹੈ, ਜੋ Docker ਦੇ ਆਪਣੇ ਫਾਰਵਰਡਿੰਗ ਨਿਯਮਾਂ ਤੋਂ ਪਹਿਲਾਂ ਮੁਲਾਂਕਣ ਹੁੰਦੀ ਹੈ। ਹੋਸਟ ਸੇਵਾ ਤੋਂ INPUT ਚੇਨ ਵਿੱਚ ਨਕਲ ਕੀਤਾ ਨਿਯਮ ਹੋਸਟ ਵੱਲ ਭੇਜੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ, ਕੰਟੇਨਰ ਵੱਲ ਫਾਰਵਰਡ ਹੋਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਨਹੀਂ। ਇਹ ਗਲਤੀ ਅਜਿਹਾ ਨਿਯਮ ਬਣਾਉਂਦੀ ਹੈ ਜੋ ਸਹੀ ਦਿਸਦਾ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਦੇ ਰਾਹ ’ਤੇ ਕੋਈ ਅਸਰ ਨਹੀਂ ਪਾਉਂਦਾ।

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

ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

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

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