defaultrouter in Jail

Columbo0815

Columbo0815

Kaffeemann
Teammitglied
Moin,

ich habe ein FreeBSD-8.1/i386 auf dem aktuell 2 Jails laufen. Gegeben sind auch 2 DSL-Anschlüsse (1x SDSL, 1x ADSL). Auf dem Host selbst habe ich als defaultrouter den SDSL-Anschluss eingestellt (über den Eintrag defaultrouter= in /etc/rc.conf).

In einer der Jails läuft nun ein squid, der allerdings den ADSL-Anschluss verwenden soll. Getestet habe ich einen Eintrag "defaultrouter=IPvomADSLRouter" in der rc.conf der Jail. Allerdings geht dieser Eintrag ins leere, die Jail verwendet den SDSL-Anschluss.

Gibt es eine Möglichkeit, das zB über einen rc.conf-Eintrag zu lösen? Der Host selbst soll dabei den SDSL-Anschluss weiterhin verwenden. Wenn nicht: Welche Möglichkeiten habe ich, das Vorhaben umzusetzen?

Gruß
 
Jails haben im FreeBSD GENERIC Kernel keinen eigenen IP Stack d.h. sie nutzen den des Hosts. Die Defaultroute wird in der Routingtabelle gespeichert. Diese existiert nur ein mal. Nur der Host kann schreibend auf sie zugreifen. Es gibt drei Lösungen für dein Problem.

Lösungsansatz 1:
Die pragmatische wäre mit ipfw zu matchen ob der Traffic aus der Jail kommt und ihn dann umzuleiten. Das funktioniert ist aber nicht die eleganteste Lösung. Fehler die dabei auftreten sind schlecht zu debuggen weil ipfw eine Aufgabe übernimmt für die es nicht wirklich gedacht ist (Routing statt Zugangskontrolle).

Lösungsansatz 2:
Etwas aufwändiger, aber flexibler wäre es einen Kernel mit Support für mehrere Routingtables im IP Stack des Hosts zu kompilieren. Mittels setfib(1) kannst du jetzt dem Elternprozess der Jail eine andere Routingtabelle zuweisen. Diese kann noch immer nur vom Host aus verändert werden. In der Routingtabelle der Jail musst du nun von Host aus die passende Defaultroute setzen.

Lösungsansatz 3:
FreeBSD 8.1 enthält den VIMAGE Code im Quelltext, wenn du damit experimentieren willst kannst du ihn aktivieren. Du erhälst ein System das für jede Jail einen eigenen IP Stack unterstützt. Dieser Code ist noch experimentell. Die Integration in die rc.d Scripte ist unvollständig. Die squid Jail könnte jetzt ihren eigenen IP Stack bekommen. Diese Jail kann entweder über ein epair Inteface mit dem Host verbunden sein und über dessen IP Stack routen oder sogar direkt das tun Interface der PPPoE Session erhalten.

Ansatz 1 hat den Vorteil mit dem GENRIC Kernel zu funktionieren. Ansatz 2 funktioniert ohne experimentelle Features und ist wartungsfreundlicher. Ansatz 3 ist am flexibelsten setzt aber experimentelle Features ein.

Zusätzlich gäbe es noch die Möglichkeit Statefull zu arbeiten und hässliche Tricks zu implementieren nach dem Schema mit 40% diese Verbindung auf die Defaultroute A, den Rest auf Defaultroute B. Die Wahrscheinlichkeiten könnte dann sogar noch jede Sekunde nen Script an die durchschnittliche Last der letzten paar Sekunden auf dem jeweiligen Interface anpassen. Wenn dir das jedoch explodiert wird glaube ich keiner dazu mehr sagen als: selbst Schuld.
 
Vielen Dank für die sehr ausführliche Antwort! Die erste Möglichkeit habe ich mir so in der Art gedacht (leider.. weil ich mich jetzt mit IPFW befassen darf). :)

Nur der Vollständigkeit halber: Ansatz 2 und 3 sind für mich keine Alternative, da ich den GENERIC-Kernel verwenden möchte. Die Verteilung der Last ist für mich auch keine Lösung, da der Traffic aus der Jail ausschließlich über die ADSL-Leitung soll. Bleibt also Variante 1. Ohne IPFW zu kennen denke ich aber, dass wenn die Regeln passen, es nicht so dramatisch sein sollte, dass das debuggen schwer ist, da ja wirklich der ganze Traffic aus der Jail umgeleitet werden soll.

Das wird knifflig, sollte aber irgendwie schaffbar sein. :-)

Vielen dank nochmal!
Gruß
 
Crest schrieb:
... ipfw eine Aufgabe übernimmt für die es nicht wirklich gedacht ist (Routing statt Zugangskontrolle)...
Zum Vergrößern anklicken....

Das würde ich jetzt nicht so unterstreichen. IPFW oder auch PF sind beide auch für Routing gedacht und gut zu gebrauchen. Ich würde das auch mit IPWF machen:
forward $routerIP ip from $JailIP to any


(dafür muss natürlich die Route zur $RouterIP in der Rountingtable des Hosts sein)

Grüße!
 
Man kann sich mit ipfw auch prima aussperren... *hust* Ich kann also erst morgen weitertesten ;)

Danke mal für die ausführlichen Erläuterungen. :)
 
Dafür als Tipp: Bevor du die Änderungen übernimmst, machst du ein screen oder tmux auf, schreibst dort "sleep 300 ; kldunload ipfw" hinein und legst das Ding in den Hintergrund. Wenn du dich aussperrst, wartest du die 5 Minuten und freust dich. Geht alles gut, holst du es wieder in den Vordergrund und drückst strg-c. :)
 
Yamagi schrieb:
Dafür als Tipp: Bevor du die Änderungen übernimmst, machst du ein screen oder tmux auf, schreibst dort "sleep 300 ; kldunload ipfw" hinein und legst das Ding in den Hintergrund. Wenn du dich aussperrst, wartest du die 5 Minuten und freust dich. Geht alles gut, holst du es wieder in den Vordergrund und drückst strg-c. :)
Zum Vergrößern anklicken....
Das mache ich mit einem 'ipfw disable firewall'-Cronjob, wenn in der Ferne experimentiert wird. Nützt aber nix, wenn man meint, das Fallback nicht einschalten zu müssen, weil man ja eh nur eine Kleinigkeit ändert, die doch gar nicht schiefgehen sollte und

/etc/natd:
redirect_port tcp 192.168.177.22:21 21
redirect_port tcp 192.168.177.22:64535-65535 64535-65535

kosmetisch aufräumen will hin zu

redirect_port tcp 192.168.177.22:21,64535-65535 21,64535-65535

und den Dienst dann neu startet.... Sowas kostet dann immer eine Fahrt ins Rechenzentrum (und erboste, wutschnaubende User), will man den Support vor Ort nicht an die Eingeweide des Systems ranlassen. :huth:
 
So. Ich konnte nun weiter testen... Scheitere jedoch aktuell daran, dass ipfw meint er würde forward nicht kennen: "fwd: not found" alternativ "forward: not found". Die manpage zu ipfw sagt mir:

To enable fwd a custom kernel needs to be compiled with the option options IPFIREWALL_FORWARD.
Zum Vergrößern anklicken....
Das scheidet definitiv aus. Jetzt werde ich mir mal pf ansehen.
 
ipfw fwd ist sowieso mit Vorsicht zu genießen. Es schreibt die Zieladresse des Pakets nicht um, was sehr interessante Nebenwirkungen haben kann.
 
Crest schrieb:
Columbo0815: Warum ist es dir so wichtig mit dem GENRIC Kernel zu arbeiten?
Zum Vergrößern anklicken....
Weil ich freebsd-update nutzen möchte und keine Lust auf rumbasteleien habe (vor allem dann wenn ich diese vermeiden kann indem ich einen anderen Weg gehe (hier pf)).

Ausserdem bin ich schon für Firewallregeln zu blöd (zumindest werfe ich mich schonmal mit pf nicht selbst raus). Wie soll das erst mit Kernelkonfigurationen aussehen ;)
 
Ist denn pf jetzt im GENERIC kernel enthalten ?
grep -i "pf" GENERIC

(dann klappts auch mit'm aussperren :ugly: )

Ausserdem bin ich schon für Firewallregeln zu blöd (zumindest werfe ich mich schonmal mit pf nicht selbst raus). Wie soll das erst mit Kernelkonfigurationen aussehen
Zum Vergrößern anklicken....

Kernel kompilieren ist leichter als pf/ipfw syntax ...
 
Zuletzt bearbeitet:
pf und pflog sind als Modul verfügbar. Laut Handbuch muss man pf wohl nur dann in den FreeBSD-Kernel kompilieren, wenn man zB pfsync braucht.

Ja, das ist mir (eigentlich) klar. Ich würde trotzdem gerne bei GENERIC bleiben. Sollte das pf-Modul das können, was ich brauche, ist es auch nicht wirklich notwendig umzusteigen. Ob ich nun am Syntax von pf oder ipfw scheitere... ist letzendlich egal :)
 
Gescheitert wird aber nicht !
Nur, je länger wir denken desto komplizierter wirds wohl.

Ist es so dass:
Am sdsl Anschluss hangt ein Jail/Server <==> Inet
Am adsl-Anschluss soll der Rest über den Kraken erst raus und auch über den squid wieder zurück ?

Wie wäre es denn , dann den Server (das Jail) via pf - binat direkt an die sdsl adresse zu hängen und den Rest via default-route über den adsl anschluss zu leiten ? Oder in anderen Worten, die Statische IP fest zu mappen und den Rest per System Route zu schicken ?
 
metro schrieb:
Gescheitert wird aber nicht !
Nur, je länger wir denken desto komplizierter wirds wohl.
Zum Vergrößern anklicken....
Das trifft es so ziemlich genau :)
Ist es so dass:
Am sdsl Anschluss hangt ein Jail/Server <==> Inet
Am adsl-Anschluss soll der Rest über den Kraken erst raus und auch über den squid wieder zurück ?
Zum Vergrößern anklicken....
Nein. Ich habe einen SDSL-Router und einen ADSL-Router mit jeweils einer eigenen IP. Im gleichen Netzwerk wie die Router steht ein FreeBSD-Rechner, auf dem Rechner läuft zum einen OpenVPN und zum anderen laufen 2 Jails darauf. Weil ich OpenVPN über SDSL nutzen möchte, hat der Server als defaultrouter den SDSL-Router eingetragen. OpenVPN ist auf dem Host selbst installiert (NICHT in einer Jail).

In einer Jail läuft Squid. Dieser Squid soll NICHT über den SDSL-Anschluss raus sondern über den ADSL-Anschluss. Der FreeBSD-Rechner hat nur eine Netzwerkkarte.

Wie wäre es denn , dann den Server (das Jail) via pf - binat direkt an die sdsl adresse zu hängen und den Rest via default-route über den adsl anschluss zu leiten ? Oder in anderen Worten, die Statische IP fest zu mappen und den Rest per System Route zu schicken ?
Zum Vergrößern anklicken....
Evtl. ist mir das grad zu hoch. Ich versuchs trotzdem: Du willst als defaultrouter auf dem Rechner selbst den ADSL-Anschluss nehmen, damit squid automatisch diesen benutzt. Ok, wäre in Ordnung. Ist ja quasi das gleiche nur andersrum. Wie gesagt.. OpenVPN MUSS über SDSL raus und rein. pf - binat? nie gehört. Ich rätzel hier die ganze Zeit mit pf route-to rum.
 
Also ohne binat, ist überflüssig.
Wenn ich das jetzt richtig verstanden habe, ist da sowas ähnliches wie ein VPN - Knoten, uber dessen squid Rechner aus den angeschlossenen (privaten ?) Netwerken sonstwohin gehen sollen.
Wenn, dann ist der Ansatz ein anderer, und der eingetragene defaultrouter nach $sdsl-router nicht richtig.

Ein VPN tunnelt (Ich nutze kein openvpn, aber das sollte genauso sein) normalerweise eine Verbindung zwischen verschiedenen Netwerkteilen durch das Internet, oder ein anderes Netzwerk, und schafft dazu Eingangs- und Ausgangspunkte. Diese haben eine (private ?) Ip und gleichzeitig wird eine Route gesetzt, die den Weg zu dem jeweils entfernten Netzwerkteil über die lokale Tunnelip (Eingang/Ausgang) bestimmt. Soweit, so gut.
Das bedeutet im Klartext, dass das VPN sich onhehin NICHT nach dem in rc.conf gesetzten defaultrouter richtet und auch nicht richten soll. Es hat ja seine Routen.

Der squid im Jail soll alle Verbindungen aus den lokalen Netzen ins INET über die default route schicken.
Dann sollten wir ihm das auch richtig sagen.

Vergiss pf und ipfw bis das steht, ansonsten gibts nur ein unendliches Gesuche danach. welcher der vielen einzelnen Bestandteile nun falsch ist. Setze erstmal die default route auf den adsl -router und lass das VPN tun , was es soll, nämlich tunneln ! ;)

Wenn's das nicht sein sollte ... schau mer mal
 
Zuletzt bearbeitet:
metro schrieb:
Also ohne binat, ist überflüssig.
Wenn ich das jetzt richtig verstanden habe, ist da sowas ähnliches wie ein VPN - Knoten, uber dessen squid Rechner aus den angeschlossenen (privaten ?) Netwerken sonstwohin gehen sollen.
Zum Vergrößern anklicken....
Nein. Der Rechner ist einfach nur für mehrere Dienste zuständig. OpenVPN ist für die "Einwahl" von extern. Weil SDSL den höheren Upstream hat, soll hierfür SDSL verwendet werden. Der Squid in der Jail regelt den Internetverkehr (wer darf wohin surfen). Hier ist ADSL ausreichend. Die beiden Dienste haben NICHTS miteinander zu tun und sind auch nicht voneinander abhängig.

Das bedeutet im Klartext, dass das VPN sich onhehin NICHT nach dem in rc.conf gesetzten defaultrouter richtet und auch nicht richten soll. Es hat ja seine Routen.
Zum Vergrößern anklicken....
Vollkommen richtig. Mein Denkfehler. Ich bin ein Pfosten! :huth: Oh weh... Ich fluch hier wegen pf rum, dabei brauch ich den gar nicht. Ich sage ja am SDSL-Router "OpenVPN geht zu Rechner XY"...

Der squid im Jail soll alle Verbindungen aus den lokalen Netzen ins INET über die default route schicken.
Dann sollten wir ihm das auch richtig sagen.
Zum Vergrößern anklicken....
Ja. Kann ich jetzt auch wieder über defaultrouter tun.

Sehr geil. Wie kompliziert man einen einfachen Sachverhalt machen kann. Danke für das Augen öffnen und die Geduld :ugly::)

Gruß
 
metro schrieb:
Ist denn pf jetzt im GENERIC kernel enthalten ?
grep -i "pf" GENERIC

(dann klappts auch mit'm aussperren :ugly: )

Kernel kompilieren ist leichter als pf/ipfw syntax ...
Zum Vergrößern anklicken....
ACK. Einen eigenen Kernel zu kompilieren ist bei FreeBSD wirklich gut dokumentiert und relativ leicht. Darüber sind FreeBSDler auch nicht so fanatisch wie OpenBSDler, wenn es um selbst kompilierte Kernel geht.

PF ist ebenso wie ipfw als Kernelmodul verfügbar. Mit beiden kann man sich aussperren. Nur ist PFs Standardeinstellung etwas freundlicher gegenüber Neulingen (sie erlaubt SSH und DNS).
 
Hm. Ganz so einfach, wie ich es dachte ist es dann doch nicht. Der OpenVPN-Traffic kommt jetzt zwar immer noch rein, versucht aber dank Standardgateway auf ADSL-Router die Antwortpakete darüber raus zu schicken.

Ich denke ohne pf werde ich hier nicht weiter kommen.
 
Kannst du bitte mal ein ifconfig $interface posten ?
(wenn du die IP's ändern möchtest, bitte so dass private noch von öffentlichen zu unterscheiden sind )
 
Zuletzt bearbeitet:
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3898<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:00:00:00:00 Anmerkung: geändert
inet 192.168.3.1 netmask 0xffffff00 broadcast 192.168.3.255 Anmerkung: Host
inet 192.168.3.2 netmask 0xffffffff broadcast 192.168.3.2 Anmerkung: squid-jail
inet 192.168.3.3 netmask 0xffffffff broadcast 192.168.3.3 Anmerkung: andere Jail
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
 
die Angaben hier und in der vBulletin Mail sind unteschiedlich... nun hast du das ja geändert, welche stimmen denn nun ?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben