Docker ਵਿੱਚ OpenVPN: ਘੱਟੋ-ਘੱਟ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜੀਂਦਾ ਰਨਟਾਈਮ ਸਮਝੌਤਾ

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

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

ਕੰਟੇਨਰ ਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

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

services:
  vpn:
    image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    volumes:
      - ./vpn:/vpn:ro
    working_dir: /vpn
    entrypoint: ["openvpn"]
    command: ["--config", "/vpn/client.ovpn"]

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

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

ਸਮਰੱਥਾਵਾਂ, entrypoint ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰਲਾ ਜਾਲ

ਦੋ ਸੈਟਿੰਗਾਂ ਲੋੜੀਂਦੀਆਂ ਹਨ ਅਤੇ ਉਹ ਅਸੰਬੰਧਿਤ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। NET_ADMIN ਕੰਟੇਨਰ ਦੇ ਨੇਮਸਪੇਸ ਅੰਦਰ ਇੰਟਰਫ਼ੇਸ ਅਤੇ ਰੂਟ ਦੀ ਹੇਰਫੇਰ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। /dev/net/tun ਡਿਵਾਈਸ ਐਂਟਰੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸੁਰੰਗ ਡਿਵਾਈਸ ਖੋਲ੍ਹਣ ਦੀ ਹੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਨੂੰ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਦੇਣ ਨਾਲ ਸਪਸ਼ਟ ਅਸਫਲਤਾ ਹੁੰਦੀ ਹੈ, ਜੋ ਸੁਵਿਧਾਜਨਕ ਹੈ: ਗੈਰਹਾਜ਼ਰ TUN ਡਿਵਾਈਸ ਖੋਲ੍ਹਣ ਵੇਲੇ ਅਸਫਲ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਗੈਰਹਾਜ਼ਰ ਸਮਰੱਥਾ ਤਦ ਅਸਫਲ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਇੰਟਰਫ਼ੇਸ ਸੰਰਚਿਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ privileged: true ਨੂੰ ਜਾਇਜ਼ ਨਹੀਂ ਠਹਿਰਾਉਂਦਾ। ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਕੰਟੇਨਰ ਨੂੰ ਹਰ ਸਮਰੱਥਾ ਅਤੇ ਡਿਵਾਈਸ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਕੰਮ ਦੇ ਭਾਰ ਨੂੰ ਲੋੜੀਂਦੇ ਨਾਲੋਂ ਕਿਤੇ ਵੱਡਾ ਅਨੁਦਾਨ ਹੈ। ਰਨਟਾਈਮ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਅਤੇ ਸਮਰੱਥਾ ਦਾ ਸੰਦਰਭ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਅਨੁਦਾਨ ਕਿੰਨੀ ਦੂਰ ਪਹੁੰਚਦਾ ਹੈ। ਜੇ ਕੋਈ chart ਜਾਂ ਬਲੌਗ ਪੋਸਟ ਇਸ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਲੋੜ ਅਸਲ ਵਿੱਚ ਗੈਰਹਾਜ਼ਰ ਡਿਵਾਈਸ ਮਾਰਗ ਸੀ ਜਾਂ ਗੈਰਹਾਜ਼ਰ ਸਮਰੱਥਾ।

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

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

ਨੇਮਸਪੇਸ ਦੇ ਅੰਦਰੋਂ ਜਾਂਚੋ, ਹੋਸਟ ਤੋਂ ਨਹੀਂ

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

docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route

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

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

ਡਿਸਕਨੈਕਟ ਹੋਈ ਅਵਸਥਾ ਸਮਝੌਤੇ ਦਾ ਹਿੱਸਾ ਹੈ

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

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

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