How to update non-template qubes over qrexec while using apt-cahcer-ng as netVM & everything in policies talk about cacher

User Support
11

I think you are confused between the processes for using the caching
proxy over qrexec, (as for templates), and using it over normal
networking.

Looking at your extensive notes, I see that you have adopted a
scattergun approach, trying many different things and changing your
targets and configuration. It’s much better to identify a specific aim,
and focus on solving that specific problem. To do this, break down your
major task in to small steps and solve each step at a time.
Don’t mix in bind-dirs at this stage - don’t switch the target - take
small steps.

Access using normal networking.

  1. To access the proxy using normal Qubes networking, you specify the
    actual IP address of the proxy in the 10_Proxy file.
    To be processed by apt processes, this file should be in
    /etc/apt/apt.conf.d
    Write that file (the contents you show look right to me.)

  2. Set the caching proxy as the netvm of your debian-11-test qube.

  3. sudo apt update

  4. This should work - if it doesn’t, check the IP address you specified
    is correct.

  5. If apt update still does not work, see if you can access
    http://10.y.y.y:8082 in a browser. You should see a configuration
    window. If you don’t, it suggests that either apt-cacher-ng is not running,
    access is blocked via nftables, the IP address is incorrect, or you have
    not set the proxy as netvm.

  6. Solve that problem: the sensible place to start would be to work in the proxy
    qube. You can check the status using systemctl status apt-cacher-ng,
    and check availability by pointing a browser at the same address.
    If the service is running, make sure that you have a rule in the INPUT
    chain giving access to tcp port 8082, by specifying ACCEPT tcp dpt:8082
    You can check this by running sudo iptables -L -nv.
    If you do not have such a rule, add one:
    sudo iptables -I INPUT -p tcp --dport 8082 -j ACCEPT

  7. Test again from the proxy

  8. Test again from debian-11-test

Access using normal networking, where the proxy is not direct netvm.

  1. Once you have the first case working, create a new qube with
    provides_network set, and the proxy as netvm.
  2. Set this qube as the netvm for debian-11-test.
  3. Confirm you can access the proxy from this new qube. (Steps as
    above.)
  4. Confirm you can access the proxy from debian-11-test.

N.B

This configuration will work provided that the intermediate qube is not
encrypting the traffic or routing it elsewhere - a VPN or Tor proxy
will do this, so don’t put them in the netvm chain.

You can use apt-cacher-ng as a drop in replacement for tinyproxy,
so you can run it on e.g. sys-firewall.
If you want to do this, make sure that you have disabled the tinyproxy
service, and that the caching proxy service is able to start and run.

Access using qrexec

This is the method used by templates, but you can apply it to any qube.
updates-proxy-setup creates a listening service at 127.0.0.1:8082,
which forwards traffic over qrexec to the target.
The target is specified in dom0, in 4.0 using /etc/qubes-rpc/policy/qubes.UpdatesProxy,
and in 4.1 by a policy file in /etc/qubes/policy.d

To make this work in a qube:

  1. Begin with a clean qube.
  2. Enable the updates-proxy-setup service
  3. Start the qube.
  4. Confirm that the service is running:
    systemctl status qubes-updates-proxy-forwarder.socket
  5. The service should show “active(listening)” - if it does not, solve
    that problem. Attempt to manually start the service, and check the
    status again.
  6. Confirm that the file has been created at /etc/apt/apt.conf.d/01qubes-proxy specifying the proxy at http://127.0.0.1:8082/
  7. Make sure that you have an entry in the relevant policy file for this
    new qube, pointing to the caching proxy. (In 4.1 it’s recommended that
    you create a new policy file in the same location with a lower number _
    e.g 30_user.policy - to hold custom changes to the policy.)
    The syntax is slightly different between 4.0 and 4.1, so make sure you
    sue the right form.
    In 4.1 it would look like TEST @default allow target=CACHING_PROXY -
    change the uppercase to match you setup.
  8. sudo apt update

Don’t have TWO proxy specifications in /etc/apt/apt.conf.d/ - that’s
confusing for you and for your qubes.

Summary

Break down your target in to small steps.
Keep the specification of the target and of each step as minimal as
possible.
Focus on solving each small step in order.
Once you have solved one, move on to the next.

When you have reached the target, you may want to add more steps - e.g.
in this case adding bind-dirs. That is not necessary to start with.

It takes some time to learn how to do this, particularly in Qubes,
where there may be many confounding factors.
It also takes time to learn what steps are needed
to reach a certain target: this can lead to XY problems.
That’s fine - everyone starts somewhere.
If you need help ask - it’s helpful for people to say how the system is
configured, what they want to achieve, what steps they have taken so
far, and where they are stuck.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
3 Likes