117471
17.05.2020, aktualisiert am 15.12.2023
29124
21
7
Ubuntu Linux als Router verwenden
Hallo,
im Ubuntu Ubuntu Wiki findet man eine Anleitung, wie man einen Linux-PC als Router verwendet. Diese enthält ein paar Fallstricke. Da man bei der Fehlersuche auf diverse "Wahnsinnsvorschläge" (resolved deinstallieren, Upstream-DNS in resolv.conf eintragen, DNSStubListener deaktivieren usw.) stößt, erklärt diese auf das Wesentliche reduzierte Anleitung die "Best practice".
In meinem Beispiel hat der Linux-PC zwei Schnittstellen:
Zur Vorbereitung bekommt eth1 eine statische IP-Adresse zugewiesen. In meinem Beispiel habe ich, dem Ubuntu-Wiki entsprechend, die 192.168.3.1/24 gewählt.
Konfiguration Server
Zuerst installiert man dnsmasq:
In der Datei /etc/dnsmasqd.conf werden folgende Einstellungen vorgenommen:
Als DHCP-Range verwenden wir 192.168.3.2 bis 192.168.3.254:
Ganz wichtig: Mit dieser Konfiguration kann der dnsmasq noch nicht starten, da er versucht, sich an Port 53 vom localhost zu klemmen. Dort residiert aber schon der resolved und der Port kann nur einmal belegt werden. "Best practice" ist hier, folgende zusätzliche Option in der /etc/dnsmasqd.conf zu setzen:
Damit wird erreicht, dass der Service nur an Schnittstellen gebunden wird, die wir explizit angegeben haben. In unserem Beispiel also nur an eth1.
Zum Testen starten wir den dnsmasq manuell:
Ob er läuft bzw. warum er nicht startet, verrät uns folgender Befehl:
Wenn das funktioniert, möchten wir, dass dnsmasq bei jedem Systemstart automatisch geladen wird:
Ganz wichtig: Hier lautet der zweite Fallstrick, da die benötigten Schnittstellen beim Systemstart u.U. noch nicht aktiv sind. Wir holen uns die Startdatei wie folgt in den Editor:
Hier finden wir den Abschnitt [Unit], dort ergänzen wir folgende Beiträge:
Nach dem Speichern können wir das Ergebnis dieser Änderung in /etc/systemd/system/dnsmasq.service überprüfen.
Portweiterleitung
IP-Forwarding aktivieren:
Das Forwarding funktioniert nur bis zum nächsten Neustart. Möchte man es dauerhaft etablieren, entfernt man die Auskommentierung in der /etc/sysctl.conf
Wir benötigen Regeln für die iptables:
NAT aktivieren:
Zum (dauerhaften) Speichern der Regeln installieren wir das folgende Paket:
Während der Installation (und nur dann!) werden wir gefragt, ob wir die Regeln dauerhaft speichern sollen. Dies bejahen wird für IPv4.
Die Regeln werden übrigens in /etc/iptables/rules.v4 gespeichert. Das Format entspricht dem von iptables-save bzw. iptables-restore. D.h., wenn wir die Regeln irgendwann einmal erweitern, können wir sie wie folgt dauerhaft etablieren:
Liebe Grüße,
Jörg
im Ubuntu Ubuntu Wiki findet man eine Anleitung, wie man einen Linux-PC als Router verwendet. Diese enthält ein paar Fallstricke. Da man bei der Fehlersuche auf diverse "Wahnsinnsvorschläge" (resolved deinstallieren, Upstream-DNS in resolv.conf eintragen, DNSStubListener deaktivieren usw.) stößt, erklärt diese auf das Wesentliche reduzierte Anleitung die "Best practice".
In meinem Beispiel hat der Linux-PC zwei Schnittstellen:
- eth0: Internetanbindung
- eth1: Hier hängen die Geräte, die den Rechner als Router nutzen sollen
Zur Vorbereitung bekommt eth1 eine statische IP-Adresse zugewiesen. In meinem Beispiel habe ich, dem Ubuntu-Wiki entsprechend, die 192.168.3.1/24 gewählt.
Konfiguration Server
Zuerst installiert man dnsmasq:
sudo apt-get install dnsmasq
In der Datei /etc/dnsmasqd.conf werden folgende Einstellungen vorgenommen:
# DHCP-Server aktiv für Interface
interface=eth1
# DHCP-Server nicht aktiv für Interface
no-dhcp-interface=eth0
Als DHCP-Range verwenden wir 192.168.3.2 bis 192.168.3.254:
dhcp-range=192.168.3.2,192.168.3.254,12h
Ganz wichtig: Mit dieser Konfiguration kann der dnsmasq noch nicht starten, da er versucht, sich an Port 53 vom localhost zu klemmen. Dort residiert aber schon der resolved und der Port kann nur einmal belegt werden. "Best practice" ist hier, folgende zusätzliche Option in der /etc/dnsmasqd.conf zu setzen:
bind-interfaces
Damit wird erreicht, dass der Service nur an Schnittstellen gebunden wird, die wir explizit angegeben haben. In unserem Beispiel also nur an eth1.
Zum Testen starten wir den dnsmasq manuell:
systemctl start dnsmasq
Ob er läuft bzw. warum er nicht startet, verrät uns folgender Befehl:
systemctl status dnsmasq -l
Wenn das funktioniert, möchten wir, dass dnsmasq bei jedem Systemstart automatisch geladen wird:
systemctl enable dnsmasq
Ganz wichtig: Hier lautet der zweite Fallstrick, da die benötigten Schnittstellen beim Systemstart u.U. noch nicht aktiv sind. Wir holen uns die Startdatei wie folgt in den Editor:
systemctl edit --full dnsmasq.service
Hier finden wir den Abschnitt [Unit], dort ergänzen wir folgende Beiträge:
After=network-online.target
Wants=network-online.target
Nach dem Speichern können wir das Ergebnis dieser Änderung in /etc/systemd/system/dnsmasq.service überprüfen.
Portweiterleitung
IP-Forwarding aktivieren:
sudo sysctl -w net.ipv4.ip_forward=1
Das Forwarding funktioniert nur bis zum nächsten Neustart. Möchte man es dauerhaft etablieren, entfernt man die Auskommentierung in der /etc/sysctl.conf
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1
Wir benötigen Regeln für die iptables:
sudo iptables -A FORWARD -o eth0 -i eth1 -s 192.168.3.0/24 -m conntrack --ctstate NEW -j ACCEPT
sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
NAT aktivieren:
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Zum (dauerhaften) Speichern der Regeln installieren wir das folgende Paket:
apt-get install iptables-persistent
Während der Installation (und nur dann!) werden wir gefragt, ob wir die Regeln dauerhaft speichern sollen. Dies bejahen wird für IPv4.
Die Regeln werden übrigens in /etc/iptables/rules.v4 gespeichert. Das Format entspricht dem von iptables-save bzw. iptables-restore. D.h., wenn wir die Regeln irgendwann einmal erweitern, können wir sie wie folgt dauerhaft etablieren:
sudo iptables-save > /etc/iptables/rules.v4
Liebe Grüße,
Jörg
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 572675
Url: https://administrator.de/contentid/572675
Ausgedruckt am: 08.11.2024 um 05:11 Uhr
21 Kommentare
Neuester Kommentar
Also "Ubuntu als Router", das nenn ich sportlich!
Vor allen Dingen, weil der Netzwerkteil von Ubuntu dermassen vermasselt ist, dass schon ein normaler Betrieb meist auf Probleme stösst.
(und das Teil in vielen Dingen gegen diverse RFCs arbeitet).
Wer wirklich einen soliden, planbaren und wartungsfreien Router (bzw. Layer 3 Switch) will, wendet sich dem BSD Lager zu. Da funktioniert das Netzwerk so, wie es soll, nicht bei jeder Version ändert sich die Konfiguration um 100% (ich sag nur: "heute interfaces, morgen netplan, übermorgen?").
Vor allen Dingen, weil der Netzwerkteil von Ubuntu dermassen vermasselt ist, dass schon ein normaler Betrieb meist auf Probleme stösst.
(und das Teil in vielen Dingen gegen diverse RFCs arbeitet).
Wer wirklich einen soliden, planbaren und wartungsfreien Router (bzw. Layer 3 Switch) will, wendet sich dem BSD Lager zu. Da funktioniert das Netzwerk so, wie es soll, nicht bei jeder Version ändert sich die Konfiguration um 100% (ich sag nur: "heute interfaces, morgen netplan, übermorgen?").
Zitat von @142139:
Also "Ubuntu als Router", das nenn ich sportlich!
Vor allen Dingen, weil der Netzwerkteil von Ubuntu dermassen vermasselt ist, dass schon ein normaler Betrieb meist auf Probleme stösst.
(und das Teil in vielen Dingen gegen diverse RFCs arbeitet).
Wer wirklich einen soliden, planbaren und wartungsfreien Router (bzw. Layer 3 Switch) will, wendet sich dem BSD Lager zu. Da funktioniert das Netzwerk so, wie es soll, nicht bei jeder Version ändert sich die Konfiguration um 100% (ich sag nur: "heute interfaces, morgen netplan, übermorgen?").
Also "Ubuntu als Router", das nenn ich sportlich!
Vor allen Dingen, weil der Netzwerkteil von Ubuntu dermassen vermasselt ist, dass schon ein normaler Betrieb meist auf Probleme stösst.
(und das Teil in vielen Dingen gegen diverse RFCs arbeitet).
Wer wirklich einen soliden, planbaren und wartungsfreien Router (bzw. Layer 3 Switch) will, wendet sich dem BSD Lager zu. Da funktioniert das Netzwerk so, wie es soll, nicht bei jeder Version ändert sich die Konfiguration um 100% (ich sag nur: "heute interfaces, morgen netplan, übermorgen?").
Aber wenn schon, dann NetBSD natürlich. Open- und Free-BSD sind da "nicht so stabil".
lks
PS: Man kann auch mit debian ordentliche Router "bauen".
ich will gar nicht diskutieren, ich will die Leute nur davor warnen.
(allerdings ist in diesem Falle ja weder Performance, noch hohe Sicherheit benötigt, als schnöder Router fürs Heimnetz mag Ubuntu vielleicht sogar ausreichen. Aber wehe, wenns etwas stressiger wird!)
(allerdings ist in diesem Falle ja weder Performance, noch hohe Sicherheit benötigt, als schnöder Router fürs Heimnetz mag Ubuntu vielleicht sogar ausreichen. Aber wehe, wenns etwas stressiger wird!)
Können wir mit Kritik schlecht leben?
Ich "sabbel" hier nicht rum, ich fordere die Leute nur auf, die hier kundgetanen "Wahrheiten" zu hinterfragen und ggf. eine deutlich sinnvollere Lösung zu suchen (ich propagiere ja noch nichtmal WELCHE oder WO, wie neutraler hätten wir es gerne?)
Fakt ist, einen "Router" wie hier beschrieben, könnte man auch mit Windows-Bordmitteln aufsetzen. Tut aber niemand. Warum? Weil der Wasserkopf von Windows dafür viel zu groß ist. Und genau dasselbe trifft auf Ubuntu zu, ein großer, fetter Elefant, der mehr Arbeit macht, als die Funktion hergibt.
Ich "sabbel" hier nicht rum, ich fordere die Leute nur auf, die hier kundgetanen "Wahrheiten" zu hinterfragen und ggf. eine deutlich sinnvollere Lösung zu suchen (ich propagiere ja noch nichtmal WELCHE oder WO, wie neutraler hätten wir es gerne?)
Fakt ist, einen "Router" wie hier beschrieben, könnte man auch mit Windows-Bordmitteln aufsetzen. Tut aber niemand. Warum? Weil der Wasserkopf von Windows dafür viel zu groß ist. Und genau dasselbe trifft auf Ubuntu zu, ein großer, fetter Elefant, der mehr Arbeit macht, als die Funktion hergibt.
Zitat von @142139:
Weil der Wasserkopf von Windows dafür viel zu groß ist. Und genau dasselbe trifft auf Ubuntu zu, ein großer, fetter Elefant, der mehr Arbeit macht, als die Funktion hergibt.
Weil der Wasserkopf von Windows dafür viel zu groß ist. Und genau dasselbe trifft auf Ubuntu zu, ein großer, fetter Elefant, der mehr Arbeit macht, als die Funktion hergibt.
Naja, fast jeder denkt bei Ubuntu an den großen fetten Desktop. Aber Ubuntu gibt es auch als ein Minimalsystem, entweder per debootstrap oder als Minimalserver installiert, bei dem man nur das notwendigste installiert. Damit kann man schon was anfangen. Auch als "quick'n-dirty"-Router. Insbesondere wenn man mit Ubuntu firm ist aber sich in NetBSD erstmal einarbeiten müßte, ist Ubuntu dann in diesem speziellen Fall die bessere Wahl.
lks
Also, ich muss euch beiden wieder enttäuschen. Weder bin ich der Gefrustete, noch habe ich Netplan nicht verstanden, noch weis ich nicht um die "Server"version von Ubuntu (de facto weiss ich nichts über irgendwelche Desktopversionen, sowas gibts hier nicht).
Es sind einfach 35 Jahre Adminerfahrung im etwas größeren Umfeld. Da merkt man schnell, welche Kiste andauernd Ärger machen und Arbeit bereiten, und welche einfach still vor sich hinlaufen und sogar sich selbst überwachen und dem Admin freundlich auf einen potentiellen Fehler hinweisen.
Und da hat sich Ubuntu (warum auch immer) in den letzten Jahren in die total falsche Richtung entwickelt, inzwischen haben die "Entwickler" auch wohl teilweise den Überblick verloren, was da denn wirklich abgeht. Netplan war nur so ein Beispiel. Total krumpelige Konfiguration (das Sensibelchen erfordert schon fast ein eigenes Tool um die Konfiguration zu generieren, schon ein falsches Leerzeichen kann das AUS bedeuten), und sinnlos (es tut ja nix mehr / besser also die vorige Version). Das zieht sich überall durch.
Ubuntu will Geld mit Support verdienen, verstehe ich. Aber ich schicke meine Leute nicht alle 2 Jahre zu einer neuen Schulung, weil das Wissen der vorigen Version inzwischen so veraltert ist, dass sie von Grund auf neu lernen müssen.
Ist mir zu teuer. Es ist mir auch zu teuer, nach jedem Update mit neuen Problemen konfrontiert zu werden und erstmal die große Suchaktion starten zu müssen.
Das es auch deutlich anders geht, zeigen BSD Betriebssysteme seit 40 Jahren. Die Grundstrukturen sind gleich geblieben, die Konfiguration geht immer noch so, wie "damals" und die Kisten müllen sich nicht selber voll.
Das sind die Grundvorraussetzungen um sich SERVER nennen zu dürfen.
Wenn Du natürlich nur eine Kiste auf dem Schreibtisch vor Dir hast, ist es egal, wenn es ein paar hundert werden, lernst Du schnell, womit man besser schläft.
Es sind einfach 35 Jahre Adminerfahrung im etwas größeren Umfeld. Da merkt man schnell, welche Kiste andauernd Ärger machen und Arbeit bereiten, und welche einfach still vor sich hinlaufen und sogar sich selbst überwachen und dem Admin freundlich auf einen potentiellen Fehler hinweisen.
Und da hat sich Ubuntu (warum auch immer) in den letzten Jahren in die total falsche Richtung entwickelt, inzwischen haben die "Entwickler" auch wohl teilweise den Überblick verloren, was da denn wirklich abgeht. Netplan war nur so ein Beispiel. Total krumpelige Konfiguration (das Sensibelchen erfordert schon fast ein eigenes Tool um die Konfiguration zu generieren, schon ein falsches Leerzeichen kann das AUS bedeuten), und sinnlos (es tut ja nix mehr / besser also die vorige Version). Das zieht sich überall durch.
Ubuntu will Geld mit Support verdienen, verstehe ich. Aber ich schicke meine Leute nicht alle 2 Jahre zu einer neuen Schulung, weil das Wissen der vorigen Version inzwischen so veraltert ist, dass sie von Grund auf neu lernen müssen.
Ist mir zu teuer. Es ist mir auch zu teuer, nach jedem Update mit neuen Problemen konfrontiert zu werden und erstmal die große Suchaktion starten zu müssen.
Das es auch deutlich anders geht, zeigen BSD Betriebssysteme seit 40 Jahren. Die Grundstrukturen sind gleich geblieben, die Konfiguration geht immer noch so, wie "damals" und die Kisten müllen sich nicht selber voll.
Das sind die Grundvorraussetzungen um sich SERVER nennen zu dürfen.
Wenn Du natürlich nur eine Kiste auf dem Schreibtisch vor Dir hast, ist es egal, wenn es ein paar hundert werden, lernst Du schnell, womit man besser schläft.
Wenn du wirklich 35 Jahre Admin-Erfahrung hast dann tust du mir mit deinen Kommentaren ehrlich gesagt eher leid. Denn die Zeit hat wohl nicht ausgereicht um zu lernen das es ANFORDERUNGEN gibt. Ist Ubuntu das beste System? Nein - genauswowenig wie Windows, BSD, Unix oder was auch immer. Es gibt nicht das beste System - sondern nur das was zu meinen Anforderungen passt. Aber scheinbar haben deine 35 Jahre nicht gereicht um sowas zu verstehen - sondern du bist irgendwo auf dem Level „Linux ist besser als Windows“, „Mac besser als PC“ usw. hängen geblieben... Schade eigentlich, aber du kannst die nächsten Jahre ja noch schauen ob du was lernen kannst..
Und übrigens: Nur weil etwas gleich bleibt ist es nicht immer automatisch BESSER. Ich arbeite übrigens mittlerweile auch einige Jahre mit Linux und schaffe es problemlos auch noch ohne Schulungen - und das sind nicht nur einfache Router die da stehen...
Und übrigens: Nur weil etwas gleich bleibt ist es nicht immer automatisch BESSER. Ich arbeite übrigens mittlerweile auch einige Jahre mit Linux und schaffe es problemlos auch noch ohne Schulungen - und das sind nicht nur einfache Router die da stehen...
Ob man nun Ubuntu oder NetBSD auf dem Schreibtisch stehen hat, ist wohl eine Frage der Anforderung. Ich habe vor 15 Jahren mal ein Suse Rechner verwendet, um die 60 Leased-Lines zu routen. Hat nie ärger gemacht und lief ca. 7 Jahre tadellos.
Heute würde ich es so nicht mehr verwenden, weil es viel bessere Lösungen und mit Redundanz gibt.
Die Frage würde ich erstmal mit "JA-EIN" beantworten wollen. Ja, weil Linux diese Aufgabe lösen kann. Nein, wenn man SLA zu erfüllen hat. Ja, wenn man einen Ausfall tolerieren kann.
Die Langzeitstabilität hängt in hohem Maß von der verwendeten Hardware ab. Ein einfacher Tisch-PC ist für Dauerbetrieb eher ungeeignet. Ihm fehlt es an Redundanzen und Kühlung.
Will man nur etwas Erfahrung sammeln oder etwas ausprobieren, warum nicht?
Die Frage ob man Linux oder NetBSD einsetzt, finde ich akademisch. Man nimmt dass Betriebssystem, mit dem man am besten umgehen kann, denn den Support dafür leistet niemand anders als Du.
Die 35 Jahre Admin-Erfahrung des Users "142139" und sein daraus resultierender Einwand ist für mich durchaus nachvollziehbar.
Gleich wohl finde ich den Einwand provokant formuliert, denn sie ruft sofort und mit Ansage, die pro/Kontra Debatte auf den Plan - mit den bekannten Verläufen. Davon niemand etwas.
Die permanenten Änderungen an der Unix-Struktur nerven auch mich, denn sie mindern die administrative Effizienz.
Dies macht aber Linux nicht schlechter und BSD nicht besser. Es ist ein Merkmal, welches sich zur Entscheidung pro/kontra nutzen lässt. Wer die Wahl hat, hat die Qual.
Was die Stabilität angeht, würde ich eher auf einen diskreten Layer-3 Switch setzten. Sie sind geeigneter für den Dauerbetrieb und bieten oft weitgehende Redundanzen und lassen sich gut in ihrem Stromverbrauch konfigurieren.
Zu Spielen und Testen spielen all diese Kritikpunkte gar keine Rolle. Man nimmt was man am besten bedienen kann.
Heute würde ich es so nicht mehr verwenden, weil es viel bessere Lösungen und mit Redundanz gibt.
Die Frage würde ich erstmal mit "JA-EIN" beantworten wollen. Ja, weil Linux diese Aufgabe lösen kann. Nein, wenn man SLA zu erfüllen hat. Ja, wenn man einen Ausfall tolerieren kann.
Die Langzeitstabilität hängt in hohem Maß von der verwendeten Hardware ab. Ein einfacher Tisch-PC ist für Dauerbetrieb eher ungeeignet. Ihm fehlt es an Redundanzen und Kühlung.
Will man nur etwas Erfahrung sammeln oder etwas ausprobieren, warum nicht?
Die Frage ob man Linux oder NetBSD einsetzt, finde ich akademisch. Man nimmt dass Betriebssystem, mit dem man am besten umgehen kann, denn den Support dafür leistet niemand anders als Du.
Die 35 Jahre Admin-Erfahrung des Users "142139" und sein daraus resultierender Einwand ist für mich durchaus nachvollziehbar.
Gleich wohl finde ich den Einwand provokant formuliert, denn sie ruft sofort und mit Ansage, die pro/Kontra Debatte auf den Plan - mit den bekannten Verläufen. Davon niemand etwas.
Die permanenten Änderungen an der Unix-Struktur nerven auch mich, denn sie mindern die administrative Effizienz.
Dies macht aber Linux nicht schlechter und BSD nicht besser. Es ist ein Merkmal, welches sich zur Entscheidung pro/kontra nutzen lässt. Wer die Wahl hat, hat die Qual.
Was die Stabilität angeht, würde ich eher auf einen diskreten Layer-3 Switch setzten. Sie sind geeigneter für den Dauerbetrieb und bieten oft weitgehende Redundanzen und lassen sich gut in ihrem Stromverbrauch konfigurieren.
Zu Spielen und Testen spielen all diese Kritikpunkte gar keine Rolle. Man nimmt was man am besten bedienen kann.
Hallo @fa-jka,
schau dir dazu mal die Doku zu "systemctl edit <unitfileName>" bzw. "systemctl edit --full <unitfileName>" an.
Damit kannst du drop-in units erstellen. die landen automatisch dann beim ersteren in /etc/systemd/system/<unitfileName>.service.d/
bzw. beim letzteren in /etc/systemd/system/<unitfileName>.service
Grüße
bloody
schau dir dazu mal die Doku zu "systemctl edit <unitfileName>" bzw. "systemctl edit --full <unitfileName>" an.
Damit kannst du drop-in units erstellen. die landen automatisch dann beim ersteren in /etc/systemd/system/<unitfileName>.service.d/
bzw. beim letzteren in /etc/systemd/system/<unitfileName>.service
Grüße
bloody