-
Notifications
You must be signed in to change notification settings - Fork 0
Handling issues on OVH cloud VPS exit node
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".
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.
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!
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