Routing mit Gentoo

[Mister.Sax]

Hi,

ich hab hier ne Aufgabenstellung, zu der ich im Forum keine Lösung finden konnte oder aber sie übersehen hab. Und zwar hab ich einen Gentoo Router, der zum einen eine 2MBit-Standleitung für´s Internet bedient. Zum anderen hängt an einem weiteren Interface ein LanCom DSL-Teil, welches der Default Gateway ins Web ist via DSL.

Es ist nun so, daß über die 2MBit-Leitung von Extern Aufrufe an unser Intranet erfolgen. Diese laufen nun ins Leere. Ich kann und darf als Default Gateway nicht den Router an der 2MBit nutzen, er muß das Lancom bleiben. Das ist ne spezielle Konstellation.

Ist nun Source Routing die Lösung? Pakete, die von der 2MBit für´s Intranet hereinkommen, sollen auf der gleichen Leitung wieder rausgehen. Wie ist das unter Gentoo zu bewerkstelligen? iproute2? extended routing? Oder was gibt es da?

Ich bitte dringend um Hilfe.

[flammenflitzer]

Kenne mich in der Materie überhaupt nicht aus, würde aber mal nachsehen, ob man vielleicht Shorewall nutzten kann. Ich nutze Shorewall auf meinem Rechner, der als Router für 2xLan fungiert.

[Mister.Sax]

Hmm, da geht es Dir wie mir. Ich versuch mich, so schnell wie möglich in die Thematik einzuarbeiten. Hier allerdings etwas Neues zu installieren, ist problematisch. Dieser Server steht an ner heiklen Stelle. Und routet viele Wege. Hat ne Menge Interfaces.

[flammenflitzer]

Shorewall kann bis drei Interfaces verwalten.

[Mister.Sax]

ich hab deren fünf. Und die sind noch unterteilt.

[think4urs11]

Klingt irgendwie verdächtig nach lartc

HTH
T.
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself

[makenoob]

[Mister.Sax]

Ich schaus mir mal an. So nach dem ersten Überfliegen könntest Du recht haben.

[Mister.Sax]

ich skizzier dir das morgen mal genauer.

[Mister.Sax]

Es soll anhand der Quelladresse/-anfrage entschieden werden, welchen Weg das Datenpaket zurück ins WWW nimmt. Also der allgemeine Traffic über das Default Gateway, die Replies auf Anfragen an den Intranet-Server den Weg über die 2 MBit-Leitung.

[think4urs11]

wie schon gesagt das ist ziemlich genau http://lartc.org/howto/lartc.rpdb.multiple-links.html
_________________
Nothing is secure / Security is always a trade-off with usability / Do not assume anything / Trust no-one, nothing / Paranoia is your friend / Think for yourself

[Mister.Sax]

Muß ich mich doch mal draufstürzen.

[kurt]

hallo,

mach doch einfach zwei interne subnetze, und apache etc. läst du einfach doppelt laufen und bindest sie an die jeweiligen ports.

gruss

kurt

[Mister.Sax]

Ganz so einfach geht das nicht. Unser Netz ist wesentlich komplexer. Die Aufgabenstellung bezieht sich nur auf einen ganz kleinen Teil des Netzes. Kennst Du Dich mit Advanced Routing aus?

[kurt]

hallo,

dir bleibt warscheinlich nichts anderes übrig als in den nächsten bücher laden zu gehen und ein entsprechendes handbuch zuzulegen.

zb. TCP/IP NetzwerkAdministration von Oreilly
meins ist übrigens aus dem jahre 1995 und der grossteil darin hat immer noch gültigkeit, ok in dem alten buch ist iproute2 noch nicht enthalten
aber in einer neueren ausgabe warscheinlich schon. es ist auch mit dem alten iproute lössbar.

gruss

kurt

[Mister.Sax]

Ist mit Sicherheit nicht die schlechteste Idee. Mal sehen, was wir hier im Bücherschrank haben.

[Freiburg]

Wie wäre es denn mit Connection marking, du kannst per iptables jeder Verbindung eine Nummer geben, also z.B. eine Webseiten Aufruf bekommt immer die Nummer 8. Mit iproute2 kannst du dann alle Packete die eine bestimmte Nummer haben in einen Table schieben und dort kannst du dann bestimmen über welches Interface sie raus gehen...

[Mister.Sax]

Hallo Freiburg,
kannst Du mir das mal etwas näher erklären? Bin noch nicht so fit, daß ich das in allen Einzelheiten durchschau.

[Freiburg]

per iptables kannst du packete und Verbindungen manipulieren (stichwort statefull firewall) eine funktion ist das man Packete und Verbindungen anhand von Regeln mit Nummern versehen kann, das braucht man z.B. auch beim Traffic shaping um den Traffic in die Richtige Klasse einzuordnen.

Unter ip kannst du eigene Routen angeben da gibts als

[Mister.Sax]

Es müssen gar nicht alle Pakete markiert werden. Nur die, die auf eth5 hereinkommen und mittels https auf unser Intranet zugreifen. Und diese sollten den Weg, auf dem sie hereinkommen, auch wieder nach aussen nehmen. Plus Pakete, die aus einem bestimmten Teil unserer Firma kommen. Der Rest geht über eth0 und einen im Netz dahinter befindlichen Lancom-Router.

Also wenn ich Dich richtig verstanden hab, ist das nicht nur iproute2, sondern auch iptables.

[Freiburg]

richtig die iptables regel müßte so in der Art aussehen:

[Mister.Sax]

Hm, die externe IP, von der das Paket kommt, dürfte schwer zu filtern sein, sie ist ja ne Variable. Ausser ich betrachte die IP von eth5 (ist ne offizielle), die dem Alias unseres Intranetservers zugeordnet ist, als die solche. Und das interne Netz, hm, ich denk das müßte dann das Netz sein, in dem sich der Intranet-Server bewegt. Oder kann es sein, daß ich diese Regel mehrfach für alle internen Netze, die den Intranet-Server ansprechen, hinterlegen muß? Die Abteilung, die ohnehin über diese Leitung Uploads macht, kann ich die in der Betrachtung aussen vor lassen?

Und was ist mit dem restlichen Netztraffic? Der sollte unberührt weiterlaufen. Bislang ist auf der Gentoo-Kiste keine Firewall-Funktionalität implementiert. Nicht daß ich da dann was aussperre.

[schmutzfinger]

Der Link der hier schon ein paar mal gepostet wurde ist schon genau richtig. Man kann das Problem mit advanced routing über iproute2 lösen. Ich habe das schon mal gemacht und zwar nach diesem Howto http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.squid.html.

Bei mir werden http(s) Anfragen unter bestimmten Umständen nicht aus dem LAN rausgelassen. Die Nutzer sehen dann auf ihrem Rechner ne Webseite, die ihnen sagt warum sie nicht ins Netz kommen. Dieses Umbiegen auf einen Webserver im LAN wird vom Router mit NAT gemacht. Dummerweise hat der Webserver immer direkt geantwortet weil er ja im selben LAN steht. Und wenn die Antwort des Webservers nicht wieder rückwärts über den Router geht dann kann dieser die Absenderadresse nicht umschreiben und der Client wird die Webseite nicht sehen, weil er ja keine Pakete vom Webserver im LAN sondern von dem Webserver erwartet den er eigentlich aufrufen wollte.

So sieht das ganze ohne advanced routing aus:

192.168.0.10 (www.google.de:80) -> router -> 192.168.0.1:8081 (mein http Server der so tut als wäre er www.google.de)
192.168.0.1:8081 -> 192.168.0.10

wie schon gesagt wird der Client das gefälschte google.de nicht anzeigen weil die Antwort von der falschen IP kommt. Wenn mein Webserver allerdings über den Router antwortet dann kann der Router die IP "fälschen" und der Client sieht das falsche google.de.

Das ganze passiert mit advanced routing. Auf dem Webserver wird alles von port 8081 ins LAN soll nicht direkt verschickt sondern eben nochmal durch die Firewall geschoben.

192.168.0.1:8081 -> router (www.google.de:80 -> 192.168.0.10) -> 192.168.0.10

Bei mir hat das keineswegs auf Anhieb geklappt, besondere Probleme haben mir icmp_redirects bereitet, weil ich das HowTo nicht richtig gelesen hatte . Ich habe das im laufenden Betrieb gemacht, weil ein kurzer Ausfall nicht schlimm gewesen wäre und die Route eh nur eine relativ unkritische Sache betrifft. Aber wenn du sowas noch nie gemacht hast und nicht weißt wie du solche Routen zB mit tcpdump debuggen kannst dann übe es auf einem kleinen Netz bevor du das große kaputt machst .
Ach ja, die IP's in meinem Post stimmen nicht mit den echten überein. Ich habe ein echtes Klasse C Subnetz, also nix mit 192.168... .

[schmutzfinger]

Ach ja, vielleicht sollte ich noch ein wenig code mitgeben.

[Freiburg]