0

Basic setup

Using:

  • Fedora 30, fully upgraded (kernel 5.1.19)
  • Podman 1.4.4

I have this Dockerfile:

FROM fedora:30

ENV LANG C.UTF-8

RUN dnf upgrade -y \
    && dnf install -y \
        openssh-clients \
        openvpn \
        slirp4netns \
    && dnf clean all

CMD ["openvpn", "--config", "/vpn/ovpn.config", "--auth-user-pass", "/vpn/ovpn.auth"]

Which I build with:

podman build -t peque/vpn .

Now, in order to be able to run it successfully, I have to take care of some SELinux issues (see Connect to VPN with Podman).

Fixing SELinux permission issues

sudo dnf install udica

I define this ovpn_container.cil custom policy for the VPN container:

(block ovpn_container
    (blockinherit container)
    (blockinherit restricted_net_container)
    (allow process process (capability (chown dac_override fsetid fowner mknod net_raw setgid setuid setfcap setpcap net_bind_service sys_chroot kill audit_write net_admin)))

    (allow process default_t (dir (open read getattr lock search ioctl add_name remove_name write)))
    (allow process default_t (file (getattr read write append ioctl lock map open create)))
    (allow process default_t (sock_file (getattr read write append open)))

    (allow process tun_tap_device_t (chr_file (ioctl open read write)))
    (allow process self (netlink_route_socket (nlmsg_write)))
    (allow process unreserved_port_t (tcp_socket (name_connect)))
)

I apply the policy with:

sudo semodule -r ovpn_container
sudo semodule -i ovpn_container.cil /usr/share/udica/templates/{base_container.cil,net_container.cil}

Running the container

Now I can successfully run the container with:

podman run -v $(pwd):/vpn:Z --cap-add=NET_ADMIN --device=/dev/net/tun --security-opt label=type:ovpn_container.process -it peque/vpn

Issues

Once the container is running, I open a terminal, within the container, from which I want to ssh to remote servers:

podman exec -it container_name bash

From the container I am able to ssh to remote servers successfully, but only if they are not within the VPN.

When I try to ssh to servers in the VPN, it gets stuck for a while and then throws this error:

$ ssh server.domain.com
ssh: connect to host server.domain.com port 22: Connection refused 
kex_exchange_identification: Connection closed by remote host

What could I be missing?

Peque
  • 13,638
  • 11
  • 69
  • 105
  • Did you check if the ssh daemon listens on something specific? Openvpn in most cases creates a forced default route (0.0.0.0/1) through its TUN/TAP interface. This means that you might not be able to access SSH when it's running on this machine through its public IP, because the replies will be routed through a different interface (TAP/TUN) than the one you're using to access it (eg. ETH0). – Tomasz Kasperczyk Jul 24 '19 at 15:35
  • @TomaszKasperczyk The SSH daemons in the servers listen on port 22. Both the server I can SSH to (outside the VPN) and the one I cannot SSH to (inside the VPN). Was that your question? I have very little knowledge about this topic. ^^ – Peque Jul 24 '19 at 15:44
  • @TomaszKasperczyk I updated the question to clarify that, once openvpn is running in the container, I then try to SSH to remote servers from within the running container as well, not from the host. In case it was unclear. – Peque Jul 24 '19 at 15:53
  • Oh, I misunderstood the question, I thought you're trying to access the system running in the container through SSH. Here are a few ideas of what can prevent you from accessing remote SSH servers from within the container while connecting through OpenVPN: *1*: remove the` ~/.ssh/known_hosts` file. *2*: try to access that server by its IP address, not by the domain name (server.domain). *3* is the public address of your VPN network different than the public address of that system when its not connected through a VPN? If so, maybe the SSH server simply blocks your VPN IP address? – Tomasz Kasperczyk Jul 24 '19 at 16:49
  • 1
    Long story short: after some troubleshooting in chat we finally found that the the client config being used in the container is incorrect and is not sufficient for the desired SSH connection. The same config worked from the host, because the VPN connection was started by the `NetworkManager`, which overrided the configuration and handled tons of things separately, including setting up some routes, which was crucial for this SSH connection. The next step is to try using the `NetworkManager` in the container or, alternatively, tune the client configuration file. – Danila Kiver Jul 26 '19 at 09:01

0 Answers0