macvlan ਕੰਟੇਨਰ VPN ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਕਿਉਂ ਨਹੀਂ ਦੇ ਸਕਦਾ

VPN ਖ਼ਤਮ ਕਰਨ ਵਾਲੇ ਅਤੇ ਉਸੇ ਸਮੇਂ macvlan ਨੈੱਟਵਰਕ 'ਤੇ ਕੰਟੇਨਰ ਚਲਾਉਣ ਵਾਲੇ Linux ਹੋਸਟ ਦੀ ਕਲਪਨਾ ਕਰੋ। LAN 192.168.60.0/24 ਹੈ, ਕੰਟੇਨਰ ਕੋਲ 192.168.60.210 ਹੈ, ਅਤੇ VPN ਕਲਾਇੰਟ 10.95.0.0/24 ਤੋਂ ਆਉਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਜਵਾਬ ਕਦੇ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ, ਅਤੇ ਹੋਸਟ 'ਤੇ ਹਰ ਫਾਇਰਵਾਲ ਨਿਯਮ ਸਹੀ ਦਿਸਦਾ ਹੈ। ਦੋ ਵੱਖਰੀਆਂ ਸੀਮਾਵਾਂ ਇਹ ਲੱਛਣ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇੱਕ ਨੂੰ ਠੀਕ ਕਰਨ ਨਾਲ ਦੂਜੀ ਆਪਣੀ ਥਾਂ 'ਤੇ ਰਹਿੰਦੀ ਹੈ।

ਦੋ ਸੀਮਾਵਾਂ, ਇੱਕ ਲੱਛਣ

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

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

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

ਹੋਸਟ ਵੱਲ ਦਾ shim ਤੰਗ ਰੂਪ ਵਿੱਚ ਬਣਾਓ

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

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

ਪਹਿਲਾ ਹੁਕਮ ਇੰਟਰਫੇਸ ਨੂੰ ਬ੍ਰਿਜ ਮੋਡ ਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ, ਜੋ ਇਸ ਡਰਾਈਵਰ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਡਿਫ਼ਾਲਟ ਹੈ ਅਤੇ ਹੋਸਟ-ਕੰਟੇਨਰ ਟ੍ਰੈਫਿਕ ਲਈ ਤੁਹਾਡਾ ਚਾਹਿਆ ਮੋਡ ਹੈ। ਦੂਜਾ /32 ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਪਤਾ LAN ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਟਕਰਾਏ ਨਾ, ਅਤੇ ਚੌਥਾ shim ਰਾਹੀਂ ਸਿਰਫ਼ ਕੰਟੇਨਰ ਦਾ ਪਤਾ ਭੇਜਦਾ ਹੈ।

ਪੂਰੇ LAN ਨੂੰ ਨਵੇਂ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਮੋੜੋ ਨਾ। ਆਮ ਜੁੜਿਆ ਰੂਟ ਜਿਵੇਂ ਹੈ ਤਿਵੇਂ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਹੋਸਟ ਦਾ ਰੂਟ ਜਾਣ-ਬੁੱਝ ਕੇ ਤੰਗ ਹੈ ਤਾਂ ਜੋ ਇੱਕ ਕੰਟੇਨਰ ਨੂੰ ਰਾਹ ਮਿਲੇ ਪਰ ਹਿੱਸੇ ਦੇ ਬਾਕੀ ਭਾਗ ਦਾ ਵਿਵਹਾਰ ਨਾ ਬਦਲੇ। shim ਵੱਲ ਦਿਸਦਾ ਡਿਫ਼ਾਲਟ ਰੂਟ ਵੱਖਰੇ ਨਤੀਜਿਆਂ ਵਾਲਾ ਵੱਖਰਾ ਡਿਜ਼ਾਈਨ ਹੋਵੇਗਾ। ਇਸ ਨੂੰ ਖ਼ਾਸ ਰੱਖੋ ਅਤੇ ਨੁਕਸਾਨ ਦਾ ਘੇਰਾ ਛੋਟਾ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਇਹ ਹੁਕਮ ਚੱਲ ਰਹੇ ਹੋਸਟ 'ਤੇ ਨੈੱਟਵਰਕ ਸੈਟਿੰਗਾਂ ਬਦਲਦੇ ਹਨ। ਜੰਤਰ ਜਾਂ ਪ੍ਰਬੰਧਿਤ ਪਲੇਟਫ਼ਾਰਮ 'ਤੇ ਉਸ ਪਲੇਟਫ਼ਾਰਮ ਦੀ ਸਮਰਥਿਤ ਸੰਰਚਨਾ ਵਿਧੀ ਵਰਤੋ, ਕਿਉਂਕਿ root-shell ਵਿੱਚ ਕੀਤਾ ਇੰਟਰਐਕਟਿਵ ਬਦਲਾਅ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਨਾ ਰਹਿ ਸਕੇ।

ਤੈਅ ਕਰੋ ਕਿ ਸਰੋਤ ਕਿਵੇਂ ਸੰਭਾਲਿਆ ਜਾਵੇਗਾ

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

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

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

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

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

ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚੋ, ਹੋਸਟ ਤੋਂ ਨਹੀਂ

ਹੋਸਟ ਆਪਣੇ ਆਪ ਤੋਂ shim ਦੇ ਪਤੇ 'ਤੇ ਬੱਝੀ ਬੇਨਤੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ shim ਕੰਟੇਨਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕੰਟੇਨਰ ਸੰਭਾਲੇ 10.95.0.x ਸਰੋਤ ਵੱਲ ਟ੍ਰੈਫਿਕ ਵਾਪਸ ਭੇਜ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸ ਟੈਸਟ ਵਿੱਚ ਸਰੋਤ ਪਤਾ shim ਦਾ ਆਪਣਾ ਹੈ।

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

ਪਹਿਲਾ ਹੁਕਮ ਹੋਸਟ ਤੋਂ ਕੰਟੇਨਰ ਤੱਕ ਦੇ ਹਿੱਸੇ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ, ਅਤੇ ਦੂਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸਲ VPN ਕਲਾਇੰਟ ਬੇਨਤੀ ਕਰਦਿਆਂ shim ਵਿੱਚੋਂ ਅਸਲ ਵਿੱਚ ਕੀ ਲੰਘਦਾ ਹੈ। ਆਉਣ ਵਾਲੇ ਰਾਹ 'ਤੇ ਸਰੋਤ ਪਤਾ ਅਤੇ ਉਸੇ ਪ੍ਰਵਾਹ ਨਾਲ ਜਵਾਬ ਦਿਸਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਦੇਖੋ।

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

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