Skip to content

Handling issues on OVH cloud VPS exit node

snider edited this page Oct 2, 2021 · 1 revision

I had some issues on OVH VPS which use something called cloud-config to setup debian Linux. So it behaves a bit different than a standard debian Linux installation. This article describes how I made workarounds for these issues. The issues arised when I was trying the "Full Lethean exit node install guide".

Change the host name (optional)

This issue arised here.

There is an article describing hos to do this here.

You can use nano instead of vim as editor if you prefer that:

$ sudo nano /etc/cloud/cloud.cfg

See the article how to edit the files.

Setting up firewall with iptables

The issue arised here.

When using iptables-persistent on debian together with iptables rules generated by the firewall example script I got an issue that caused problems to connect to the VPS with ssh. It also caused the cloud-config.service on the VPS to fail at startup.

The problem is caused by startup order problem of services. When no iptables are applied everything works. If iptables are applied manually after boot everything works. But when iptables are applied with iptables-persistent then it breaks ssh login and breaks cloud.config.service. A working solution is to make sure iptables is autostarted after cloud-config is completed. After some investigation I found that netfilter.persistent.service is the one that controls iptables-persistent setup.

$ systemctl status netfilter-persistent.service
● netfilter-persistent.service - netfilter persistent configuration
   Loaded: loaded (/lib/systemd/system/netfilter-persistent.service; enabled; vendor preset: enabled)
   Active: active (exited) since Fri 2019-06-14 12:34:23 CEST; 1h 35min ago
  Process: 490 ExecStart=/usr/sbin/netfilter-persistent start (code=exited, status=0/SUCCESS)
 Main PID: 490 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/netfilter-persistent.service

Take a look at the unit file

$ cat /lib/systemd/system/netfilter-persistent.service
[Unit]
Description=netfilter persistent configuration
DefaultDependencies=no

Before=network-pre.target
Wants=network-pre.target

Wants=systemd-modules-load.service local-fs.target
After=systemd-modules-load.service local-fs.target

Conflicts=shutdown.target
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/netfilter-persistent start
ExecStop=/usr/sbin/netfilter-persistent stop

[Install]
WantedBy=multi-user.target

And we also take a look at cloud-config.service

$ cat /lib/systemd/system/cloud-config.service
[Unit]
Description=Apply the settings specified in cloud-config
After=network-online.target cloud-config.target
Wants=network-online.target cloud-config.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cloud-init modules --mode=config
RemainAfterExit=yes
TimeoutSec=0

# Output needs to appear in instance console output
StandardOutput=journal+console

[Install]
WantedBy=cloud-init.target

network-pre.target is before network-online.target so netfilter-persistent.service is started before cloud-config.service. We can make a customized netfilter-persistent service and configure it to start after cloud-config.service.

$ sudo cp /lib/systemd/system/netfilter-persistent.service /etc/systemd/system/custom-netfilter-persistent.service
$ sudo systemctl disable netfilter-persistent.service
$ sudo nano /etc/systemd/system/custom-netfilter-persistent.service

Make it look like this:

[Unit]
Description=customized netfilter persistent configuration
DefaultDependencies=no

Wants=cloud-config.service
After=cloud-config.service

Conflicts=shutdown.target
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/netfilter-persistent start
ExecStop=/usr/sbin/netfilter-persistent stop

[Install]
WantedBy=multi-user.target

Enable custom-netfilter-persistent.service

$ sudo systemctl enable custom-netfilter-persistent.service

Run iptables.sh, save to make persistent. Then reboot.

$ sudo ./iptables.sh
$ sudo iptables-save > rules.v4
$ sudo cp rules.v4 /etc/iptables/rules.v4
$ sudo reboot

After this reboot I was able to login with ssh again without problems and the rules in /etc/iptables/rules.v4 were applied. Problem solved!

Install a DNS cache (optional but recommended)

The issue arised here.

After reboot the drill command told me it was using server 213.186.33.39 instead of 127.0.0.1 I told it to use before. This could be if exit node have resolvconf package installed or if it is using dhcp client to get DNS server address. In my case it was DHCP that cause it.

There was a networking.service in use when I checked with systemctl status. This looks like some special kind of setup and chanses are big that your server is using something else. I found that it is the cloud-config that is doing this here too...

$ cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp

So I had to create /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg and add a line network: {config: disabled}

And then:

$ sudo nano /etc/network/interfaces.d/50-cloud-init.cfg

In this particular case I changed it to

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
        address 147.135.208.118/32
        gateway 147.135.208.1

Then I had to edit /etc/resolf.conf again to set nameserver to 127.0.0.1