iptables-Modul wird nach dem Upgrade von Ubuntu 14.04 auf 16.04 nicht geladen

iptables-Modul wird nach dem Upgrade von Ubuntu 14.04 auf 16.04 nicht geladen

Daher habe ich beschlossen, Ubuntu 16.04 trotz einer etwas ungünstigen Meinung zu systemd eine Chance zu geben.

Nach dem Upgrade funktioniert meine zuvor dauerhafte OpenVPN-Verbindung nicht mehr. Glücklicherweise ist das Systemprotokoll recht hilfreich, um die Grundursache zu ermitteln.

openvpn-up: + /sbin/iptables -t nat -D POSTROUTING -o tun0 -s 192.168.x.x -j SNAT --to-source 10.x.x.x
openvpn-up: modprobe: ERROR: could not insert 'ip_tables': Operation not permitted
openvpn-up: iptables v1.6.0: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
openvpn-up: Perhaps iptables or your kernel needs to be upgraded.
openvpn-up: + /sbin/iptables -t nat -A POSTROUTING -o tun0 -s 192.168.x.x -j SNAT --to-source 10.x.x.x
openvpn-up: modprobe: ERROR: could not insert 'ip_tables': Operation not permitted
openvpn-up: iptables v1.6.0: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
ovpn-conn[613]: WARNING: Failed running command (--up/--down): external program exited with error status: 3
openvpn-up: Perhaps iptables or your kernel needs to be upgraded.
ovpn-conn[613]: Exiting due to fatal error

Hinweis: Diese openvpn-upwurden durch das Auskommentieren der zweiten Zeile des /etc/openvpn/openvpn-up.shSkripts erstellt (Zeile lautet: exec &> >(logger -s -t openvpn-up) && set -x).

Hmm, aus irgendeinem Grund ip_tableskonnte das Modul nicht geladen werden. Nachdem ich sichergestellt hatte, dass alle Kernelmodule vorhanden waren apt-get install --reinstall linux-image-$(uname -r), versuchte ich es mit modprobe ip_tablesund sah tatsächlich, dass es jetzt mit geladen war, lsmodaber auch im Systemprotokoll:

kernel: [  446.293882] ip_tables: (C) 2000-2006 Netfilter Core Team

Und tatsächlich systemctl restart openvpnschien beim Ausführen nach diesem Punkt die Verbindung hergestellt zu werden und iptables-savedie Ausgabe bewies, dass die entsprechende SNAT-Regel hinzugefügt wurde.

Meinerratenist jetzt, dass die OpenVPN-Einheit mit einem Benutzerkontext ausgeführt wird, der nicht über genügend Berechtigungen zur Verwendung modprobeusw. verfügt.

Diesen Verdacht konnte ich jedoch nicht bestätigen. Und tatsächlich systemctl cat openvpnverwirrt mich die Ausgabe total:

# systemctl cat [email protected]
# /lib/systemd/system/[email protected]
[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn23ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
PrivateTmp=true
KillMode=mixed
Type=forking
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
PIDFile=/run/openvpn/%i.pid
ExecReload=/bin/kill -HUP $MAINPID
WorkingDirectory=/etc/openvpn
ProtectSystem=yes
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE
LimitNPROC=10
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw

[Install]
WantedBy=multi-user.target

Gibt es einFähigkeitwas ich brauche, damit die Skripte erfolgreich insmod/ aufrufen können modprobe? Ich möchte das Hinzufügen vermeiden, CAP_SYS_ADMINda dies ziemlich grob erscheint. Oder ist die einzige Möglichkeit, das ip_tablesModul zu laden, indem man ein .confin /etc/modprobe.d? einfügt?

Im Wesentlichen frage ich Folgendes: Wie funktioniert ein Standard-Ubuntu 16.04 (dasnichtwurde von 14.04 aktualisiert) diese Aufgabe erfüllen? Dh Was ist die kanonische (UndWie kann ich das (kanonische) Verfahren anwenden? Und nicht zuletzt: Wie kann ich feststellen, in welchem ​​Benutzerkontext eine bestimmte Einheit ausgeführt wird (oder genauer: mit welchen Fähigkeiten)?

Antwort1

Die Dokumentation zu jeder systemd-Direktive kann über nachgeschlagen werden man system.directives. Dort habe ich herausgefunden, dass sie CapabilityBoundingSet=in dokumentiert ist man systemd.exec.

Das führte mich dorthin, man 7 capabilitieswo die verschiedenen Fähigkeiten dokumentiert sind. Als ich dort nach „Modul“ suchte, fand ich Folgendes, was nach einer Fähigkeit klingt, die Sie benötigen:

CAP_SYS_MODULE Kernelmodule laden und entladen

Es ist unklar, warum diese Funktion nicht standardmäßig enthalten ist. Vielleicht ist sie in gängigen Anwendungsfällen von OpenVPN nicht erforderlich.

Die minimale Möglichkeit, diese Funktion zur systemd-Konfiguration eines Pakets hinzuzufügen, ist eine „Drop-in-Unit“. Erstellen Sie diese Datei:

/etc/systemd/system/[email protected]/add-module-loading.conf

Mit diesem Inhalt:

[Service]
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE CAP_SYS_MODULE

Dadurch wird der Dienst um die vorhandenen Funktionen erweitert und um weitere Funktionen erweitert CAP_SYS_MODULE.

Ich war auch skeptisch, systemdhabe aber viel gefunden, was mir gefällt. Das timerSystem ist ein willkommenes Update zum über 20 Jahre alten Cron-System.

verwandte Informationen