OpenVPN ਪਿੱਛੇ Docker ਅਤੇ VM ਟ੍ਰੈਫਿਕ: ਰੂਟ ਕਿ ਮੁੜ-ਨੰਬਰ?

OpenVPN ਕਲਾਇੰਟ ਚਲਾਉਂਦੇ ਹੋਸਟ ਉੱਤੇ ਕੰਟੇਨਰ ਅਤੇ ਮਹਿਮਾਨ ਜਾਂ ਤਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਗੁਆ ਲੈਂਦੇ ਹਨ ਜਾਂ ਟਨਲ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਟਕਰਾਉਂਦੇ ਹਨ। ਤਿੰਨ ਸਵਾਲ ਹੱਲ ਚੁਣਦੇ ਹਨ।

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

ਤਿੰਨ ਸਵਾਲ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਸਥਿਤੀ ਦੇਖ ਰਹੇ ਹੋ, ਅਤੇ ਇਸ ਵਿੱਚ ਲਗਭਗ ਇੱਕ ਮਿੰਟ ਲੱਗਦਾ ਹੈ।

ਇੱਕੋ ਜਿਹੇ ਦਿਸਣ ਵਾਲੇ ਦੋ ਨੁਕਸ

ਪਹਿਲਾ ਵਾਪਸੀ ਦੇ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਕੰਟੇਨਰ ਵਿੱਚ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ, ਬੇਨਤੀ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਹੋਸਟ ਦੇ ਡਿਫਾਲਟ ਰਾਹ ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ OpenVPN ਕਲਾਇੰਟ ਨੇ tun0 ਵੱਲ ਮੋੜਿਆ ਹੈ। ਜਵਾਬ ਅਜਿਹੇ ਪਤੇ ਤੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਿਸ ਦੀ ਦੂਰ ਦੇ ਸਾਥੀ ਨੂੰ ਉਮੀਦ ਨਹੀਂ, ਅਤੇ ਉਹ ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਦੂਜਾ ਪ੍ਰੀਫਿਕਸ ਟਕਰਾਅ ਹੈ: Docker ਦਾ ਡਿਫਾਲਟ ਬ੍ਰਿਜ 172.17.0.0/16 ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ ਕਾਰਪੋਰੇਟ ਟਨਲ ਉਹੀ ਰੇਂਜ ਧੱਕਦਾ ਹੈ।

ਇੱਕ ਰੂਟ ਟੇਬਲ ਨਾਲ ਠੀਕ ਹੁੰਦਾ ਹੈ, ਦੂਜਾ ਬ੍ਰਿਜ ਨੂੰ ਮੁੜ-ਨੰਬਰ ਕਰਕੇ। ਇਹ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ ਸੋਧ ਕਰਨਾ ਕਿ ਕਿਹੜਾ ਕਿਹੜਾ ਹੈ, ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਨੂੰ ਤੋੜਨ ਦਾ ਤਰੀਕਾ ਹੈ।

ਤਿੰਨ ਸਵਾਲਾਂ ਨਾਲ ਤੈਅ ਕਰੋ

ਸਵਾਲ ਇੱਕ: VPN ਬੰਦ ਕਰਨ 'ਤੇ ਨੁਕਸ ਮਿਟਦਾ ਹੈ? ਜੇ ਟਨਲ ਬੰਦ ਹੋਣ 'ਤੇ ਸਭ ਕੁਝ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਵਾਪਸੀ ਦੇ ਰਾਹ 'ਤੇ ਸ਼ੱਕ ਕਰੋ। ਸਵਾਲ ਦੋ: ਕੀ ip route show table all ਉਹੀ ਪ੍ਰੀਫਿਕਸ ਦੋ ਵਾਰ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ, ਇੱਕ ਵਾਰ ਬ੍ਰਿਜ 'ਤੇ ਅਤੇ ਇੱਕ ਵਾਰ tun0 'ਤੇ? ਇਹੀ ਟਕਰਾਅ ਹੈ। ਸਵਾਲ ਤਿੰਨ: ਪ੍ਰਭਾਵਿਤ ਪਤਾ ਕੰਟੇਨਰ ਹੈ, NAT ਮਹਿਮਾਨ ਹੈ ਜਾਂ ਬ੍ਰਿਜ ਕੀਤਾ ਮਹਿਮਾਨ?

ਤੀਜਾ ਸਵਾਲ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਦਾ ਵੱਖਰਾ ਸਹੀ ਹੱਲ ਹੈ, ਅਤੇ ਕੰਟੇਨਰ ਦਾ ਹੱਲ libvirt ਮਹਿਮਾਨ 'ਤੇ ਲਾਉਣਾ ਇੱਕ ਸ਼ਾਮ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

ਵਾਪਸੀ ਦਾ ਰਾਹ: ਇੱਕ ਸਰੋਤ ਪਤੇ ਲਈ ਟੇਬਲ

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

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

ਹਰ ਪੈਕੇਟ ਜਿਸ ਦਾ ਸਰੋਤ ਉਹ ਪਤਾ ਹੈ, ਪਹਿਲਾਂ ਟੇਬਲ 10 ਦੇਖਦਾ ਹੈ, ਅਤੇ ਟੇਬਲ 10 ਉਸ ਨੂੰ ਟਨਲ ਦੀ ਥਾਂ ਬ੍ਰਿਜ ਗੇਟਵੇ 'ਤੇ ਭੇਜਦਾ ਹੈ।

ਇਸ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ: ip route get 1.1.1.1 from 172.22.0.3. ਜਵਾਬ ਵਿੱਚ ਬ੍ਰਿਜ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, tun0 ਨਹੀਂ। ਇਸ ਤਰ੍ਹਾਂ ਜੋੜੇ ਨਿਯਮ ਰੀਬੂਟ 'ਤੇ ਮਿਟ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹਨਾਂ ਨੂੰ ਕੰਟੇਨਰ ਦੇ ਮਾਲਕ unit ਜਾਂ ਨੈੱਟਵਰਕ ਹੁੱਕ ਵਿੱਚ ਰੱਖੋ।

ਇਹੀ ਪੈਟਰਨ WireGuard ਕੰਟੇਨਰ ਲਈ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਜਵਾਬ ਦੇ ਰਾਹ ਨੂੰ ਵੀ ਸਪਸ਼ਟ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰੀਫਿਕਸ ਟਕਰਾਅ: ਬ੍ਰਿਜ ਨੂੰ ਮੁੜ-ਨੰਬਰ ਕਰੋ

ਰੂਟ ਟੇਬਲ ਇੱਕ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਇੱਕ ਥਾਂ ਭੇਜਦਾ ਹੈ। ਜੇ VPN 172.17.0.0/16 ਧੱਕਦਾ ਹੈ ਜਦਕਿ Docker ਦਾ ਬ੍ਰਿਜ ਪਹਿਲਾਂ ਹੀ ਉੱਥੇ ਹੈ, ਤਾਂ ਘੱਟ ਮੈਟ੍ਰਿਕ ਜਿੱਤਦੀ ਹੈ: Docker ਆਪਣਾ ਜੁੜਿਆ ਰੂਟ ਮੈਟ੍ਰਿਕ 0 'ਤੇ ਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਧੱਕਿਆ ਰੂਟ 50 'ਤੇ ਆਉਂਦਾ ਹੈ। ਫਿਰ Docker ਦੇ ਚੱਲਦੇ ਰਹਿਣ 'ਤੇ ਵੀ ਟਨਲ ਟੁੱਟਿਆ ਦਿਸਦਾ ਹੈ, ਜਾਂ ਉਲਟਾ, ਇੰਸਟਾਲੇਸ਼ਨ ਕ੍ਰਮ ਅਨੁਸਾਰ। ਮੈਟ੍ਰਿਕ ਨਾਲ ਲੜਨ ਦੀ ਥਾਂ ਬ੍ਰਿਜ ਨੂੰ ਮੁੜ-ਨੰਬਰ ਕਰੋ।

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

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

VM ਨੂੰ ਫਿਰ ਹੋਰ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ

ਡਿਫਾਲਟ NAT ਨੈੱਟਵਰਕ 'ਤੇ libvirt ਮਹਿਮਾਨ ਹੋਸਟ ਦੀ ਰੂਟਿੰਗ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦਾ ਹੈ ਅਤੇ ਹੋਸਟ ਦੇ ਟਨਲ ਦੇ ਡਿਫਾਲਟ ਰਾਹ ਦਾ ਮਾਲਕ ਬਣਦਿਆਂ ਹੀ ਬਾਹਰ ਪਹੁੰਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਮਹਿਮਾਨ ਨੂੰ ਬ੍ਰਿਜ ਜਾਂ macvtap ਡਿਵਾਈਸ 'ਤੇ ਲਿਜਾਣ ਨਾਲ ਉਸ ਨੂੰ ਭੌਤਿਕ ਨੈੱਟਵਰਕ 'ਤੇ ਆਪਣਾ ਰਾਹ ਮਿਲਦਾ ਹੈ। virt-manager ਵਿੱਚ ਹਾਰਡਵੇਅਰ ਜੋੜੋ, Network ਚੁਣੋ, ਸਰੋਤ macvtap ਹੋਸਟ ਡਿਵਾਈਸ 'ਤੇ ਸੈੱਟ ਕਰੋ, ਮਾਡਲ ਵਜੋਂ virtio ਰੱਖੋ, ਫਿਰ ਪੁਰਾਣਾ NAT ਇੰਟਰਫੇਸ ਅਕਿਰਿਆਸ਼ੀਲ ਕਰੋ।

macvtap ਮਹਿਮਾਨ ਆਮ ਤੌਰ 'ਤੇ ਆਪਣੇ ਹੋਸਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਇਹ ਨੁਕਸ ਨਹੀਂ ਸਗੋਂ ਉਮੀਦ ਕੀਤਾ ਵਿਵਹਾਰ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਛੱਡੇ ਨੋਟ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜਿਸ ਮਹਿਮਾਨ ਨੂੰ ਸਿਰਫ਼ ਹੋਸਟ ਦਾ LAN ਚਾਹੀਦਾ ਹੈ, ਲਈ ਵਿਕਰੇਤਾ ਦੇ ਕਲਾਇੰਟ ਵਿੱਚ ਗੁੰਮ ਸਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ: Mullvad ਨਾਲ mullvad lan set allow libvirt ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਸਥਾਨਕ ਪਹੁੰਚ ਮੁੜ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਅਤੇ ਜਦੋਂ ਕੰਟੇਨਰ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪ੍ਰਕਾਸ਼ਿਤ ਪੋਰਟ ਨੂੰ ਟਨਲ ਪਤੇ ਨਾਲ ਬੰਨ੍ਹੋ, -p 10.8.0.5:8080:8080, ਹਰ ਪਤੇ 'ਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਥਾਂ।

ਸੰਬੰਧਿਤ ਲੇਖ