Linux Server mit VM

[Metal_Warrior]

@HoneyBadger: Dafür wird ein zusätzlicher Nutzer angelegt. Dein persönlicher Benutzer hat sudo-Rechte, der hat auf keinen Fall irgendwelche Systemdienste auszuführen.

 

[HoneyBadger]

Bin gerade dabei mir den Systemdienst zu schreiben.
Habe mir dafür einen eigenen Nutzer "vpnuser" angelegt.
Bin dann entsprechend nach /etc/systemd/system navigiert.
Dort habe ich einen per vim einen vpn.service angelegt.
In der Anleitung bei Ubuntu-Users bin ich bereits beim lesen darüber gestolpert, dass dafür root Rechte benötigt werden. Als ich mit meinem vpnuser dann die Datei speichern wollte, passierte das, was ich zuvor schon ahnte. Geht natürlich nicht.

Nun bin ich etwas verunsichert. Meinen Nutzer mit sudo soll ich ja auf keinen Fall nehmen. Hätte ich dann im vpnuser die Service-Datei per su vim vpn.service erzeugen und später auch starten sollen?

Den Service selbst habe ich folgendermaßen aufgebaut:

[src=powershell][Unit]
Description=VPN Dienst


[Service]
Type=simple
ExecStart=openvpn /etc/openvpn/xyz.ovpn


[Install]
WantedBy=multi-year.target
[/src]

 

[Metal_Warrior]

@HoneyBadger: Warte, halt. Du verstehst den Unterschied zwischen anlegendem und ausführenden User nicht.

DU brauchst root-Rechte, wenn du den Service anlegen willst, also die Systemd-Datei, und zwar weil du etwas am System änderst. Das darf IMMER nur root.

Wer VPN am Ende ausführt, ist davon unberührt. Jeder User darf eine VPN-Verbindung aufbauen, dazu braucht man keine Systemberechtigung. Es kann sein, dass in deinem Fall (alle User müssen über die Verbindung geroutet werden) tatsächlich root die Verbindung erstellen muss, aber das hat nichts (bzw. nur über fünf Ecken was) mit der obigen Beschränkung zu tun. Und so, wie ich das

You do not have permission to view link please Anmelden or Registrieren

lese, ist der Weg über einen eigenen VPN-User (wie fast immer) der richtige.

P.S.: Dir fehlt ein User-Statement (weil der vpnuser diesen Befehl ausführen soll) und ein Execpoststart-Statement für die Routenumleitung nach obig verlinktem Artikel. Außerdem, was soll multi-year.target (du willst wohl multi-user.target) sein und deine Prerequisites fehlen, d. h. du willst VPN erst starten, wenn networking läuft...

 

[HoneyBadger]

Okay. Verstehe. Allerdings sagt die Anleitung von meinem VPN-Anbieter, dass der Tunnel per sudo openvpn /etc/openvpn/xyz.ovpn gestartet werden muss.

Da ich den Service dann aber mit root Rechten angelegt habe, reicht also
ExecStart=openvpn /etc/openvpn/xyz.ovpn, richtig?

Die Anleitung ist super! Danke! Damit hätte ich ja genau das, was ich erreichen möchte. Kein Traffic ohne vpn.

 

[Metal_Warrior]

@HoneyBadger: Wie gesagt, so wie es dein VPN-Provider schreibt, stimmt das eigentlich nicht. Dafür gibts den Userspace, den root aber natürlich auch allen zur Verfügung stellen kann. Und genau so solltest du es verwenden, also ohne root-Rechte.

 

[HoneyBadger]

@HoneyBadger:
P.S.: Dir fehlt ein User-Statement (weil der vpnuser diesen Befehl ausführen soll) und ein Execpoststart-Statement für die Routenumleitung nach obig verlinktem Artikel. Außerdem, was soll multi-year.target (du willst wohl multi-user.target) sein und deine Prerequisites fehlen, d. h. du willst VPN erst starten, wenn networking läuft...

Hab das eben mit dem Handy getippt. Year statt user kam von der autokorrektur. Hab ich nicht bemerkt.

Ich dachte erst, ich hätte erst verstanden.... :-/
Gut ich google besser noch einmal nach diesen Statements.

 

[Metal_Warrior]

Systemd startet alle Dienste gleichzeitig, es sei denn, sie hängen voneinander ab. Das unterscheidet es grundlegend vom SysInitV, das noch in Wheezy genutzt wurde. Selbst dort wurde aber die Startreihenfolge vom System bestimmt, und dazu war nötig, dass der Administrator den Diensten Voraussetzungen zuwies. Die genaue Einordnung übernimmt dann das System, du musst ihm nur sagen, was der Dienst schon am System funktionsfähig erwartet.

Zum Beispiel macht es keinen Sinn, die Firewall anzulegen, bevor das System die Netzwerkadapter gesucht hat. Und der Webserver wird definitiv nicht funktionieren, wenn das System noch kein TCP/IP versteht. Klingt logisch, oder? Also kannst du Firewall, Webserver und auch OpenVPN zwar zeitgleich starten (weil der Firewall es egal ist, ob der Webserver läuft und umgekehrt), aber nicht bevor das Netzwerk steht.

 

[HoneyBadger]

DHCP und Co. überfordern mich noch. Daher habe ich mich nun erst einmal mit Samba und Plex beschäftigt.
Plex bekomme ich nach Installation erfolgreich auf dem Windowsrechner im Browser angezeigt. Das klappt. Samba habe ich nach

You do not have permission to view link please Anmelden or Registrieren

eingerichtet und komme auch per Windows drauf. Abweichung zur Anleitung: Habe einen anderen Pfad (verschlüsselt) gewählt und meinen persönlichen User unter samba angelegt. Der hat aber ein anderes Passwort bekommen, als das eigentliche Nutzerpasswort. Die Dateifreigabe als Netzlaufwerk unter Windows passt auch. Ist das so richtig?

PS: Der Datentransfer geht mit gerade mal 10 MB/s. Ist das normal?

 

[HoneyBadger]

Um Plex zum Laufen zu bringen, musste ich dafür die Rechte in Samba entsprechend anpassen. Hatte eine ganz gute Anleitung dafür gefunden. Das passt. Dateizugriff mit Passwortschutz unter Windows läuft auch. Wäre das ein Problem das zu kombinieren?

Testweise habe ich das beides unter dem selben Verzeichnis (nacheinander) ausprobiert. Nun würde ich das Plexverzeichnis aber auch gerne vom Desktop aus verwalten. Wäre es ein Problem, wenn ich das dafür so einrichte:

/home/user/data/plex
Hier die Berechtigung, sodass Plex läuft

/home/user/data
Hier die Berechtigung, sodass ich per Desktop mit Kennwort drauf komme.

Oder würde sich das beißen?

 

[HoneyBadger]

Die letzte Zeit fehlte es etwas an Kapazitäten, den Server sinnvoll voranzubringen. Demnächst soll´s aber weiter gehen.
Im nächsten Schritt, will ich die DHCP/DNS/Firewall-Geschichte angehen.

Bin im Netz über

You do not have permission to view link please Anmelden or Registrieren

gestolpert. Die ließt sich für mich recht verdaulich. Kann ich die problemlos nehmen oder könnte es Probleme geben, da ich ja Debian nutze?

PS: Die Fragen aus dem Post davor sind immer noch aktuell.

 

[nik]

You do not have permission to view link please Anmelden or Registrieren

Da das Ubuntu in dem Beispiel fast 9Jahre alt ist, würde ich dir zu einer aktuellen Anleitung raten. Allgemein sind sich Debian und Ubuntu aber so ähnlich, dass du bis auf wenige Ausnahmen bedenkenlos Anleitungen von Ubuntu für Debian nutzen kannst.
Was den DNS-Server angeht, rate ich dir allerdings von bind ab. Nimm stattdessen lieber dnsmasq oder unbound. Die sind einfacher gehalten und leichter zu konfigurieren.

Was deine Fragen oben angeht, wüsste ich jetzt nicht, wieso du das nicht machen können solltest. Kannst auch beide Berechtigungen für den gleichen Ordner setzen, wenn du das willst.

 

[HoneyBadger]

Okay. Auf das Datum hatte ich gerade nicht geachtet. Suche halt eine Anleitung, die das als Gesamtpaket abarbeitet, damit ich weniger Stress bei Abhängigkeiten bekomme, die ich evtl. nicht richtig abschätzen kann. Habe da leider noch nichts besseres gefunden.

 

[nik]

Um Abhängigkeiten musst du dir so erst mal weniger Gedanken machen.

Hier kannst du dich schon mal einlesen, ist auch mit Anleitung, die übertragen kannst:

You do not have permission to view link please Anmelden or Registrieren

You do not have permission to view link please Anmelden or Registrieren

Damit hast du dann schon mal VPN, DNS, DHCP und NAT abgedeckt

 

[Metal_Warrior]

Die Dateifreigabe als Netzlaufwerk unter Windows passt auch. Ist das so richtig?

PS: Der Datentransfer geht mit gerade mal 10 MB/s. Ist das normal?

Ich sehe nicht, warum das ein Problem sein sollte. Und ja, leider ist Samba nicht sehr effizient, daher ist die Geschwindigkeit eher mager. 10 MBps sind zwar etwas wenig, aber dass du nicht auf Gbit-Geschwindigkeiten kommen wirst, ist sicher.

Wäre das ein Problem das zu kombinieren?

Nicht wirklich. Ich bin mir zwar nicht sicher, warum Plex, obwohl es lokalen Zugriff hat, Samba benötigt, aber gut. Alternative: Versuch doch mal, Plex direkt die Rechte auf den Ordner zu geben. Also Gruppe anpassen, Leserechte auf die Gruppe und auf gehts. Anders ist das hochgradig bescheuert - du schleifst erst die Daten durch den Flaschenhals Samba durch, um die dann selber nochmal bereitzustellen.

Oder würde sich das beißen?

Nein, zwei User, eine Freigabe - das ist völlig legitim.

Die ließt sich für mich recht verdaulich.

Verdaulich? Nicht wirklich. Abgesehen davon, dass sie 8 Jahre alt ist (gut, ist kein Problem für Debian, da funktioniert der älteste Scheiß normalerweise noch), ist sie hochgradig kompliziert.

1. Zwei getrennte Dienste für DHCP und DNS.
DHCP weist lokale IPs zu und weiß daher auch, welche Computer wie heißen (was man üblicherweise so als WINS oder NetBIOS kennt - Namensauflösung auf lokaler Ebene). DNS macht das auch, nur professioneller. Willst du, dass deine Computer sauber im Netzwerk aufgelöst werden, müsstest du beide Dienste miteinander koppeln. Das ist eher komplex. Oder zumindest komplizierter, als es gar nicht machen zu müssen, weil du einen Kombidienst nimmst: dnsmasq. Das macht standardmäßig beides, sofern man nicht eins davon ausschaltet. Und auch wenn die Default-Konfig ziemlich kompliziert aussieht (weil der Maintainer da einen großen Teil der Möglichkeiten von dnsmasq versucht zu erklären), eine Grundkonfig erstellt man üblicherweise mit ein paar wenigen Zeilen. Ich glaub, die hab ich hier auch mal gepostet... mal sehen, hier.

2. bind.
Ganz ehrlich: Ich hab mich echt ne Weile mit DNS beschäftigt, aber bind war mir immer zu komplex. Da muss man sich immer überschlagen, um irgendwas einrichten zu können. Klar, es kann halt dafür auch DNSSEC etc., aber das brauchst du sicher nicht.

3. Ubuntu
Normalerweise kann man das nehmen, aber für die Zukunft sei vorgewarnt, dass gerade Basisfunktionen teilweise etwas anders bereitgestellt werden (Canonical verlässt gern mal gut eingelaufene Pfade, um dann in der Wildnis auf die Schnauze zu fliegen - siehe Unity). Grundsätzlich hab ich das Gefühl, dass je näher du am Kernel und an den Grundfunktionen des Systems arbeitest, desto sinnvoller sind Arch-Anleitungen (man muss halt die Kompilierungsgeschichten überspringen und ein paar Pfade evtl. anpassen). Wenns Richtung Programme geht, sind Ubuntu-Anleitungen super.

Edit: iptables hab ich ja auch mal Anleitungen geschrieben, aber nicht mit Forwarding. Das mach ich dir grad mal:

Spoiler

[src=bash]#!/bin/bash
# Firewall setup


# ==== Pre-Setup ====

# Deleting existing rules
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X


# ==== Chain Setup ====

# Add new custom chains
iptables -N forward_drop
iptables -N forward_reject
iptables -N server_drop
iptables -N server_reject

# Feed forward_drop chain
iptables -A forward_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] FORWARD DROP: " --log-level 7
iptables -A forward_drop -j DROP

# Feed forward_reject chain
iptables -A forward_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] FORWARD REJECT: " --log-level 7
iptables -A forward_reject -j REJECT

# Feed server_drop chain
iptables -A server_drop -m limit --limit 10/day -j LOG --log-prefix "[IPTables] SERVER DROP: " --log-level 7
iptables -A server_drop -j DROP

# Feed server_reject chain
iptables -A server_reject -m limit --limit 10/day -j LOG --log-prefix "[IPTables] SERVER REJECT: " --log-level 7
iptables -A server_reject -j REJECT


# ==== Feed forward chain ====

# Snatch invalid traffic
iptables -A FORWARD -m state --state INVALID -j forward_drop

# Reject ISATAP traffic without logging (isatap ist ein Dienst, der IPv6-Anfragen über ein IPv4-Netz schicken kann)
iptables -A FORWARD -p 41 -j REJECT

# Allow established connections
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow HTTP (outgoing)
iptables -A FORWARD -o eth0 -p tcp --dport 80 -j ACCEPT

# Allow HTTPS (outgoing)
iptables -A FORWARD -o eth0 -p tcp --dport 443 -j ACCEPT

# Allow xyz (incoming)
iptables -A FORWARD -i eth0 -p tcp --dport ... -j ACCEPT

# Allow xyz (both directions)
iptables -A FORWARD -p tcp --dport ... -j ACCEPT

# Reject everything else with logging
iptables -A FORWARD -j forward_reject


# ==== Feed server chains ====

# Always accept loopback traffic
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Snatch invalid traffic
iptables -A INPUT -m state --state INVALID -j server_drop

# Reject ISATAP traffic without logging
iptables -A INPUT -p 41 -j REJECT

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow server to connect to external DNS servers (Google, FoeBud, CCC Berlin)
iptables -A OUTPUT -o eth0 -p tcp -d 8.8.8.8 -dport 53 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 85.214.20.141 -dport 53 -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -d 213.73.91.35 -dport 53 -j ACCEPT

# Allow server to connect to external HTTP servers (update)
iptables -A OUTPUT -p tcp -dport 80 -j ACCEPT

# Allow SSH
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow DNS (intern only)
iptables -A INPUT -i eth1 -p udp --dport 53 -j ACCEPT

# Allow DHCP (intern only)
iptables -A INPUT -i eth1 -p udp --dport 67 --sport 68 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --dport 68 --sport 67 -j ACCEPT

# Allow Samba
iptables -A INPUT -p tcp --dport 445 -j ACCEPT

# Reject everything else with logging
iptables -A INPUT -j server_reject


# ==== Enable Forwarding ====
echo 1 > /proc/sys/net/ipv4/ip_forward


# ==== This movie is over ====
exit 0[/src]
Die DNS-Server hier müssen natürlich in dnsmasq als Server definiert sein, sonst fragt dein Server nämlich ins Nichts (oder gar nicht).
Update-Server-IPs hab ich dir jetzt auch nicht rausgesucht, das kannst du ja selber mal für deine Update-Server machen und die Kommunikation entsprechend beschränken.

BTW: Ich hab das grad ausm Kopf runtergeschrieben - da fehlen natürlich Einträge und andere möchtest du vielleicht anders haben. Nur so als Warnung.

Der Firewall-Service, den du schreiben musst (systemd), ist hier: https://ngb.to/threads/28120-systemd-amp-if-up-d?p=766306#post766306

 

[nik]

Grundsätzlich hab ich das Gefühl, dass je näher du am Kernel und an den Grundfunktionen des Systems arbeitest, desto sinnvoller sind Arch-Anleitungen (man muss halt die Kompilierungsgeschichten überspringen und ein paar Pfade evtl. anpassen).

Verwechselt du Arch mit Gentoo? Arch ist auf die Nutzung von Binärpaketen ausgelegt. Normalerweise kompiliert man da gar nix.

 

[Metal_Warrior]

@nik: Stimmt, bei Arch muss man nix kompilieren - aber Gentoo-Anleitungen gehen auch

 

[Arterial_Worm]

PS: Der Datentransfer geht mit gerade mal 10 MB/s. Ist das normal?

Das ist definitiv nicht normal, samba ist nicht das schnellste Pferd im Stall, aber auf der Hardware sollte es nicht von den Schnecken aus meinem Garten überholt werden.

kannst du mal mit [highlight]ethtool $interface[/highlight] den link speed testen?
ggf vorher mit [highlight]ip addr [/highlight] nach gucken wie das Interface heisst, es müsste mit eth oder en anfangen.
Der output müsste ungefähr so ausschauen:
[src=text]Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Current message level: 0x000060e4 (24804)
link ifup rx_err tx_err hw wol
Link detected: yes[/src]
relevant ist "Speed" und sollte da nicht "1000Mb/s" stehen auch "Supported link modes" und "Advertised link modes"

1. Zwei getrennte Dienste für DHCP und DNS.
DHCP weist lokale IPs zu und weiß daher auch, welche Computer wie heißen (was man üblicherweise so als WINS oder NetBIOS kennt - Namensauflösung auf lokaler Ebene). DNS macht das auch, nur professioneller. Willst du, dass deine Computer sauber im Netzwerk aufgelöst werden, müsstest du beide Dienste miteinander koppeln. Das ist eher komplex. Oder zumindest komplizierter, als es gar nicht machen zu müssen, weil du einen Kombidienst nimmst: dnsmasq. Das macht standardmäßig beides, sofern man nicht eins davon ausschaltet. Und auch wenn die Default-Konfig ziemlich kompliziert aussieht (weil der Maintainer da einen großen Teil der Möglichkeiten von dnsmasq versucht zu erklären), eine Grundkonfig erstellt man üblicherweise mit ein paar wenigen Zeilen. Ich glaub, die hab ich hier auch mal gepostet... mal sehen, hier.

Dnsmasq kann allerdings nicht rekursiv auflösen, sondern braucht einen "richtigen" dns server im Hintergrund, was natürlich z.B. die Server des ISP sein können. Wenn man aber, aus welchen gründen auch immer, selber rekursiv auflösen möchte brauch man doch wieder einen 2. Server. Es kann also durchaus Sinn machen das von vorn herein zu trennen.
Zwei getrennte Dienste währen auch im sinne der Unix-Philosophie.

2. bind.
Ganz ehrlich: Ich hab mich echt ne Weile mit DNS beschäftigt, aber bind war mir immer zu komplex. Da muss man sich immer überschlagen, um irgendwas einrichten zu können. Klar, es kann halt dafür auch DNSSEC etc., aber das brauchst du sicher nicht.

bind ist bei weitem nicht der einzige DNS-Server der DNSSEC kann, sowohl dnsmasq als auch unbound auf Cache-Seite und powerdns auf Server-Seite können das.
Des weiteren würde ich nicht sagen das es jemanden gibt der DNSSEC nicht braucht, auch wenn es noch nicht flächendeckend angeboten ist sollte man es nicht vernachlässigen.

 

[Metal_Warrior]

@Arterial_Worm: Thread von Anfang an lesen bitte. Der gute Mann ist Anfänger.

-> rekursive DNS-Abfragen dürften für ein Netz mit 4 Nutzern reichlich Overkill sein. Das würde ich nichtmal für 100 User nutzen.
-> Getrennte Dienste Teil der Unix-Philosophie - da geb ich dir Recht. Manchmal weicht man diese Philosophie aber aus guten Gründen etwas auf (siehe z. B. SSH mit internem SFTP-Server etc.)
-> DNSSEC erfordert üblicherweise ne eigene Cryptochain, was wieder bei 4 Usern wenig Sinn macht. Wer außer dem einzigen DNS-Server auf der selbstverwalteten Hardware sollte denn die Resource Records der internen Zone faken?

Große Umgebungen - da hast du recht. Bei dem Projekt... naja, Kirche im Dorf lassen, würde ich mal sagen.

 

[Arterial_Worm]

@Arterial_Worm: Thread von Anfang an lesen bitte. Der gute Mann ist Anfänger.

Gerade Anfängern sollte man von Anfang an die richtigen Wege zeigen.

-> rekursive DNS-Abfragen dürften für ein Netz mit 4 Nutzern reichlich Overkill sein. Das würde ich nichtmal für 100 User nutzen.
…
-> DNSSEC erfordert üblicherweise ne eigene Cryptochain, was wieder bei 4 Usern wenig Sinn macht. Wer außer dem einzigen DNS-Server auf der selbstverwalteten Hardware sollte denn die Resource Records der internen Zone faken?

Von faken war nicht die rede.
Es gibt noch immer ISPs die unterstützen bis heute DNSSEC nicht in ihren cache servern und das obwohl sie eigentlich nur etwas durch reichen müssten, da verschafft ein eigener resolver Abhilfe.
Gibt auch kaum clients die die Verifizierung überhaupt machen, daher ist es eine sehr gute Idee das den dns cache machen zu lassen, wenn man eh schon einen hat.

 

[Metal_Warrior]

Gerade Anfängern sollte man von Anfang an die richtigen Wege zeigen.

Mit Verlaub - es gibt Gründe, warum ich Gentoo nicht empfehle (und es sind die gleichen Gründe, die dafür sorgen, dass Linux immer "das Nerdsystem" ist): Leute wollen vorwärts kommen, und nicht wochenlang tausende Sachen nachschlagen, bis sie das erste Mal den Browser starten können. Diese ganze "wenn du das schon machen willst, dann lies Quellcode und kompiliere selbst"-Mentalität ist Schwachsinn für 95% aller Anfänger, und das hier ist einer dieser 95%-Fälle.

Insofern: Ja, man kann alles toll selber machen. Wer aber schon Probleme hat, DHCP aufzusetzen, für den ist es NICHT empfehlenswert. Was nützt es denn, dass man jeden Schalter im Kernel kennt, aber am Ende daran scheitert, eine Netzwerkverbindung aufzubauen? Genau, gar nix. Komm in nem Jahr wieder, wenn das System halbwegs stabil läuft.

BTW: Deshalb nehmen wir übrigens ja nicht den DNS des ISPs.