• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Linux Server mit VM

HoneyBadger

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #182
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]
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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 hier 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

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #184
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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #186
@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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #188
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 dieser Anleitung 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?
 
Zuletzt bearbeitet:

HoneyBadger

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #189
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

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #190
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 diese Ubuntu-Anleitung 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. :beer:
 

nik

肉まん

Registriert
19 Feb. 2017
Beiträge
962
Ort
deine Mülltonne
@HoneyBadger: 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

Aktiver NGBler

Registriert
7 Sep. 2015
Beiträge
1.956
  • Thread Starter Thread Starter
  • #192
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.
 

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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:
[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
 
Zuletzt bearbeitet:

nik

肉まん

Registriert
19 Feb. 2017
Beiträge
962
Ort
deine Mülltonne
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.
 

Arterial_Worm

Neu angemeldet

Registriert
24 Aug. 2017
Beiträge
2
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.
 
Zuletzt bearbeitet:

Metal_Warrior

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
@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

Neu angemeldet

Registriert
24 Aug. 2017
Beiträge
2
@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

Defender of Freedom
Teammitglied

Registriert
10 Aug. 2013
Beiträge
6.830
Ort
/dev/mapper/home
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.
 
Oben