 Policy-Based-Rooting. Bisher haben wir gelernt, von morgens bis abends und zwei Tage lang die Routing-Entscheidung passiert, abhängig von der Zieladresse eines Pakets. Das stimmt auch weiterhin, aber manchmal reicht es nicht aus, nur auf das Ziel zu gucken. Wenn das ausreicht, brauche ich klassisches Rooting und diesen ganzen Zauber, über den ich jetzt rede, braucht dann keinen Mensch. Manchmal reicht das zum Beispiel nicht aus. Im Freifunkumfeld haben wir das Problem, zum Beispiel, dass wir es nutzen müssen. Ein Beispiel kommt gleich noch. Szenarien, wo ich das brauche, wenn abhängig davon, wo meine Daten herkommen, ich andere Ziele haben möchte, muss ich also auch auf die Quelle gucken. Entweder von einem Ziel-Prefix, also wegen welchen Quell-IPs, oder davon abhängig über welches Interface meine Pakete reinkommen. Kann ja auch sein, wenn ich das nicht an IP-Adressen abhängig machen möchte, oder wenn es einfacher ist, es über Interface zu machen. Wenn das Paket grün angemalt ist, das ganze zu Port 80, soll von Port 1, 2, 3, 4, 5 kommt oder ähnlichen Dingen, die ich zum Beispiel per Netfilter-Framebook feststellen kann. Linux hat ja einen relativ mächtigen Fireball-Stack, aspektive Paketfilter-Stack. Darüber kann ich auch feststellen, dass irgendein Paket irgendeine Eigenschaft hat, die mich gerade interessiert und auf die ich matchen möchte, kann dann Kleberaufkleber drauf machen, denn sich FW mag und kann in der Rooting-Policy gucken, das Ding behandle ich so ein bisschen anders. Wie macht man das? Man fummelt in den Linux-Körnel mehrere Rooting-Tabellen rein. Bisher haben wir uns nur die Standard-Rooting-Tabelle angeguckt, die nennt sich Standardmäßig Main, die ist immer da, eigentlich sind drei Stück da, aber die gibt es immer. Wir können aber noch mehrere daneben legen und können eine Policy davor kleben, die entscheidet, in welche Rooting-Tabelle guckt unser Körnel denn rein. Das heißt, wir haben mehrere FIPS, wie man sagen würde, Forward Information Base, anhand derer geguckt wird, wo soll das Paket nachher hin. Die Policy entscheidet, welche davon genutzt wird. Und wenn es feststeht, in welche Tabelle wir reingehen sollen, gibt es die klassische Rooting-Entscheidung, wie wir das die ganze Zeit in zwei Tagen gemacht haben. Wird keine passende Route gefunden in der Tabelle, springen wir zurück in die Policy-Liste. Das Ganze gibt es nicht nur auf Linux, das gibt es auch auf irgendwelchen Hardware-Kisten. Wir benutzen das zum Beispiel im Datacenter, haben das im Datacenter benutzt auf Nexus 7000-Kisten, also auf diesen zwei, die so teuer sind wie zwei Wohnhäuser, die können dann auch. Linux unterstützt theoretisch einen ganzen Sackvoll-Tabellen, zwei auch 32, wird kein Mensch, der bei Verstand ist, brauchen oder benutzen. Üblicherweise brauchen wir dann eine Handvoll. IP Route haben wir uns ja schon mal angeguckt, das Ding kennen wir. Ich habe jetzt mal hier Fett hervorgehoben, das Zauberwort. Ich kann bei vielen Dingen angeben, um welche Table es gehen soll. Also IP Route Add, hier unten, wir lesen das Ding mal, gibt es das Zauberwort Route. Das Ding hat irgendwann eine Note-Spec und da kann ich sagen, in welche Tabelle ich diese Route einfügen, löschen sonst was möchte. Hier unten sieht man, wie die Table-ID aussehen kann. Entweder man nimmt eine von den drei Vorhandenen, standardmäßig nimmt man Main oder man gibt eine Nummer an oder irgendeinen Namen. Die Local-Tabelle enthält automatisch, da kümmert sich das Betriebssystem drum, alle Routen zu Dingen, die lokal angeschlossen sind. IP-Adressen, die lokal konfiguriert sind oder Broadcast-Adressen. Default enthält noch mal gar nix, ist quasi so ein Fallback. Die Policy, wo wird reingeguckt, setzt sich mit IP-Rule fest. Das sind die Regeln. Da kann ich sagen, wenn irgendein Paket aus einem bestimmten IP-Bereich kommt, irgendwo hin soll, irgendein Aufkleber hat von der Fireball, über irgendein Interface raus reinkommt, Entschuldigung, dann können wir in eine bestimmte Tabelle springen. Unten halt wieder genau dasselbe. Die Tabelle gebe ich an als numerischen Wert oder einen der bestehenden Namen. Thomas souffliert noch Preference, also genau, da kommen wir jetzt gleich zu. Das sind die Standardregeln, die jedes Linux mitbringt, wenn ich nichts dafür getan habe. Als erstes guckt er in der Local-Tabelle. Ist das Ziel für irgendwas, was lokal angeschlossen ist. Wenn ich mit mir selber rede, muss ich nicht weiter groß drüber nachdenken, deswegen gibt es diese Tabelle. Wenn nicht, ich muss also irgendwie raus, gucken wir in der Standard-Routing-Tabelle nach. Möglicherweise haben wir da Routen drin für die Netzwerke, mit denen wir verbunden sind, und eine Default-Route, so im Standard-Heimnetzfall, möglicherweise ein paar mehr. Das ist so der übliche. Die Default-Tabelle ist quasi der doppelte Boden. Wenn hier nix drin ist, gucken wir da nochmal rein. Im Standard-Set-Up steht da nix drin. Die Zahl hier vorne ist die Preference. Die kleiner, desto wichtiger. Also das Ding wird von oben nach unten abgearbeitet. Achtung, wenn man damit rum spielt, kann man sich relativ subtil in die Füße schießen, bis man das findet, das dauert ein bisschen. Der Handle-with-Care-Aufkleber von vorhin bleibt bestehen. Beispiel. IP-Route-Show, Table Main, das da hinten nettig weglassen können, steht jetzt der Vollständigkeit halber hier. Mein Laptop hatte eine Route ins lokale Netzwerk, per WLAN. Und in der Table Default steht eine Default-Route drin. Wenn ich mir das Ding nur angucke, habe ich augenscheinlich keine Default-Route. Mein Laptop konnte trotzdem aus Internet zugreifen. Wie erinnern uns, es ist nicht lokal. Hier drin steht keine Default-Route. Er geht weiter, guckt in der Default-Table. Die greift dann. Warum ist das gefährlich? Wenn ich zum Beispiel so ein Set-Up habe, das ist von einem unserer Freifunkrouter. Alles, was über irgendeinen WLAN reinkommt, das möchte ich gerne in Tabelle 42 schubsen. Alles, was aus unserem Freifunknetz in Paderborn kommt, möchte ich auch in die Tabelle schubsen. In dieser Tabelle, IP Route Show, Table 42, habe ich eine Default-Route drin, die geht über ein Rheinland-Bergborn raus, so wie das gedacht ist. Fliegt mir jetzt die BGP-Session um die Ohren, weil diese Kiste hier hoch geht oder weil Düsseldorf abbrennt oder ähnlich ist. Und ich habe eine zweite, die nach Frankfurt geht, der ist schon tot, habe ich keine mehr. Das heißt, diese Route ist aber mal weg. Es gibt dafür keinen Ersatz. Ich habe eine andere Tabelle, meine Default-Route, die das System lokal hat. Irgendwie muss ich ja diese ganze Kiste erreichen können. Sprich, die Dinger greifen nicht mehr. Er würde hier hingehen und würde es über mein lokales Netzwerk raus schicken. Das wollen wir ja gerade nicht. Stichwort Störerhaftung und so. Deswegen haben wir diesen ganzen Zauber ja gebaut. Aufpassen. Was tun wir dagegen? Wir haben vorhin schon mal mit Unreachable-Routen gearbeitet. Ich habe das vorhin gemacht, um diese Routing-Tabelle einzutragen für den Bereich, den ihr grundsätzlich habt, damit Dinge nicht ins Internet rausgehen, die eigentlich für lokal gedacht sind. Es gibt hier noch so einen Trick. Man kann da hinten eine Metrik dran setzen. Je höher die Zahl, desto schlechter die Route. Die tragen wir einmal statisch ein. Tun das in der Haupttabelle, bzw. können das auch hier tun, tun das in der Tabelle, wo wir sonst eine Default-Route rein haben wollen, eine andere, Entschuldigung. Sollte die per BGP da reinkommende wegfallen, das heißt, das ist jetzt die nächste Default-Route, die greift. Was passiert? Derjenige, der ins Internet möchte, kriegt ein ICMP-Network an Weachable zurück, gibt es nicht. Damit haben wir einen doppelten Boden geschaffen. Und wenn wir uns jetzt an das Regelwerk hier zurück erinnern, wird, wenn eine von den beiden Regeln greift, geguckt, ob wir ins Internet kommen, die gibt es nicht. Es gibt aber diese Route hier. Also gibt es keinen Fallback in die Standard Main Table. Wichtiger Mechanismus. Wie machen wir das mit BERT? Wir wollen das zu Fuß machen. In BERT gibt es auch mehrere Tabellen. Standardmäßig benutzt man da die Table Master. Also innerhalb von BERT gibt es auch die Default-Table, die heißt nicht Main wie bei Linux, sondern Master. Also BERTing ist aber wirklich nur BERT spezifisch. Die wird immer benutzt, wenn ich bei Protokollen nichts gesondertes angebe. Das heißt, die muss ich nicht explizit anlegen, die ist einfach da. Und alle Protokolle nutzen die. Wenn ich mehrere Tabellen haben möchte, die ich mit Table und irgendein Stück Text angeben, damit habe ich BERT intern eine weitere Routing-Tabelle geschaffen. Die wird noch nicht in den Kernel exportiert. Die ist nur in BERT. Das heißt, da kann ich auch ganz viele Schweine rein mitmachen. Möchte ich irgendein Protokoll dran nageln, schreibe ich an das Protokoll genauso dran, Table und dann den Namen. Kleiner Exkurs. Alle Namen, die man hier benutzt, oder bei Protokollen Namen, kommen aus dem selben Namensraum. Das heißt, wenn ich einen Namen nicht doppelt vergeben. Jetzt haben wir das Problem, wenn wir das so machen. Und alles, was per BGP kommt, nur in Tabelle 42 rein, unter anderem IC, VPN und andere Dinge, kann ich von der Maschine, auf der das läuft, darauf nicht mehr zugreifen. Das ist ja nicht mehr in meiner Haupttabelle. Das heißt, wenn ich ein Trace-Root mache, von meinem Router, der nach außen angebunden ist, geht das über die normale Default-Route, raus ins Internet, das will ich aber nicht. Der Trick ist, ich kann in BERT Tabellen synchronisieren, natürlich mit Filtern. Dafür gibt es dieses schöne Pie-Protokoll. Wenn wir uns daran erinnern, an die Ausgabe der Protokolle stand hier immer dabei Master. Das ist die Table. Das ist Blödsinn. Das war eine Frage, ob ihr aufpasst. Das ist offensichtlich Blödsinn. Ich will eine Unreachable-Route haben, die geht nicht irgendwo lang. Das ist Quatsch. Danke. Wir waren bei den Protokollen. Hier wird überall Master stehen. Daran sehe ich das, wo das seine Routen reintut. Mit dem Befehl kann ich mir auch verschiedene Tabellen dann angucken. Also Show-Root-Table-Freifunk zum Beispiel, gibt es. Die können das alle. Wenn ich so ein Pie-Protokoll baue, hier unten sehe ich das, was es ist, sehe ich das aus der Table-Master. Das ist überfallschrumpf. Das macht keinen Sinn. Das ist die Daten von hier mit hier synchronisiert. Die Anzeigerichtung irritiert mich gerade ein bisschen. Genau. Wie möchte man das tun? Wir nutzen das zum Beispiel in Paderborn so, dass wir per BGP Dinge von außen kriegen. Default-Route, die ganzen Sachen aus dem IC VPN, die kommen alle in Table 42 an. Landen bei mir im OSPF, also das, wie man es nicht machen sollte. Das sollte man weiß, was man tut. Und die Routing-Policy auf sämtlichen Systemen sorgt dafür, dass alles, was aus dem Freifunknetz kommt, über Table 42 geroutet wird, in die ich das exportiere, mit meinem eigenen Kernel-Protokoll dafür. Damit man das ganze Debugging kann, schmeißen wir das einmal in die zweite Tabelle. Das sieht ungefähr so aus. Ich sage aus, in ein Indie-Table-Master möchte ich aus der Tabelle Freifunk die Sachen importieren. In diesem Fall möchte ich die Default-Route nicht haben. Hat das System ja. Ich kann ja relativ schlecht das Host-System, auf dem ich irgendwelche Gret-Tunnel nach außen habe, dem kann ich ja schlecht seine Default-Route wegnehmen. Dann habe ich ein Henna-Eye-Problem. Wenn es zum Rheinland-Backbond will, um den Gret-Tunnel zu nutzen, hat es keine Default-Route mehr, sondern möchte über den Gret-Tunnel. Damit würde ich mich abschießen, das will ich nicht. Aber alles andere, was nicht die Default-Route ist, das kann ich schon in die normale Routing-Tabelle übernehmen. Dann kann ich mit den Standard-Tools, Ping, MTR, Trace-Route, Eye-Perf, was auch immer, ganz normal debuggen, wie ich das gewohnt bin. Ich habe also eine Doppelung der Informationen mit Ausnahme der Default-Route, wenn ich das so mache. Ich mache das Leben relativ einfach. Wie kann ich einen doppelten Boden mit Bird bauen? Ich baue mir ein Static-Protokoll, schreibe hier noch dran, in welche Table da soll, das habe ich vergessen, setze die Route und setze eine Preference da drauf. Das haben wir bisher auch verschwiegen. Es gibt neben den Parkkosten in OSPF oder Kosten, per BGP kann ich nur ein Local-Pref setzen, gibt es noch die sogenannte Administrative Distance, würde man das bei Cisco nennen, oder eine Preference von Protokollen. Es gibt eine Hierarchie, welche Routen präferiert werden. Wenn ich dieselbe Route statisch eintrage, sie im OSPF oder BGP habe, bewinnt meines Wissens die Statische. Die weiß Route, wenn es angeschlossen ist, eine Statische, dann kommt ein IGP, also zum Beispiel OSPF, dann würde BGP kommen. Jetzt möchte ich dafür sorgen, dass das Ding nicht so gewinnt, also es sollte schlechter sein als BGP, sollte nur dann genutzt werden, wenn das Ding nicht so gut kommt. Deswegen setze ich die Preference. Eine Standardmetrik, wie wir das vorhin gesehen haben, mit dem statischen Befehl, kann ich in Bird leider nicht setzen, könnte mal wer reinpatschen, wer jetzt hier kann. Wie gesagt, Lab wird es dazu nicht geben, aber die Doku von dem ganzen Zeug ist relativ gut. Die Grundprinzipien von Routing habt ihr verstanden, hoffe ich, wir haben es zumindest versucht. Die Man-Pages von IP Route sind relativ gut, die sind auch relativ ausführlich, aber die Man-Pages von IP Route ist auch ziemlich gut, da stehen auch ein paar Warnungen drin, macht das nicht, denkt darüber nach, zum Beispiel die Geschichte mit dem doppelten Boden. Darin gibt es auch relativ viele Beispiele, wie man das macht. Und die Bird-Doku sei euch auch an der Stelle ans Herz gelegt, da kann man dann nachlesen, wie man den Pipes umgeht, wie man mit Preferences umgeht und so weiter. Die Bird-Doku ist manchmal ein bisschen gewöhnungsbedürftig, aber üblicherweise findet man die Dinge, ansonsten Google hilft. Also die fertige Config mit diesen Tricks in dem Policy-Routing, die ihr im Betrieb habt, gibt es die oder ein Beispiel dafür irgendwo zum Nachlesen und Verstehen? Noch nicht. Ich managere meine ganze Architektur in Paderborn mit Salt, quasi ein Software-defined Networking. Der Plan ist, das ganze Salt geht mal auf GitHub zu packen. Ich kann aber auch die Config mal direkt auf dieses T-Systems-Ding legen gleich. Irgendwo war noch eine Anmerkung. Kurzer Hinweis für die User im Stream. Hackint, Route, Routing Days für Fragen? Ja, also du hast das schön erklärt, wie man das baut. Das kriegen wir in der Regel auch hin. Du hast auch gesagt, man kann sich da schön Bock schießen. Wie debagge ich den? Also wie kann ich gucken? Also ich sehe ja, was passieren soll anhand der Regeln, IP-Rule und solche Sachen. Ich sehe aber effektiv nicht, ob es passiert und wann es passiert. Das ist leider ein relativ trauriges Kapitel. Habe ich gemerkt. Der Grund, warum ich diesen Stand mit der Pipe mache, ist ja, weil ich nicht, wie zum Beispiel bei irgendwelchen Cisco-Kisten oder Ähnliches sagen kann, kommen immer die Tabelle oder an dem mal die und die IPs. Gut, ich kann eine Source-IP setzen bei Ping zum Beispiel, weil ich kann nicht sagen, nehm die Routing-Tabelle und spiele mal damit rum, deswegen nehme ich die Pipe. Was das Unterlinungs-Ergibt ist IP-Route-Get, das haben wir schon benutzt. Den Ding kann ich leider auch nicht sagen, nehm bitte die Tabelle. Den Ding kann ich sagen, laut Dokumentation, das hat bei meinen Tests zur Vorbereitung hier aber überhaupt nicht funktioniert. Wie debugge ich das? TCP-Dump und von einem System, was quasi davor hängt, was also von den Rules betroffen sein sollte, davon ausgeht, Ping oder Ähnliches. Der Herr Herms hat eine Idee. Der Herr Herms hat eine Idee. Man kann beim Ping ein Type-of-Service setzen und man kann auf Type-of-Service matchen und das dann mit bestimmte Tabellen reinschmeißen. Vielleicht möchte man das einfach mal implementieren. Wenn der Type-of-Service 5 dran hängt, dann geht das bitte in diese Routing-Tabelle und dann kann ich beim Ping-Type-of-Service 5 setzen und dann geht der in die Routing-Tabelle, die ich da haben möchte. Das wäre quasi eine weitere Rule mehr während valider Testkäs. Das habe ich noch nie ausprobiert. Ich habe mich da immer behäufen, dadurch, dass ich im Setup ein paar Daboren Core-Router habe und da auch drunter Gateways, das heißt, wenn ich es vom Gateway aus probiere, greifen meine Regeln, sollten sie zumindest und kann es dadurch testen. Thomas? Wenn ich IPv6 habe, dass ich dann auch auf der IPv6-Adresse den Router von außen, also von meinem privaten Anschluss zum Beispiel pingen kann, weil die Antwort würde ja dann über die Default-IPv6 auf dem Ether0 verschickt werden. Kannst du noch ein bisschen präziser spezifizieren, was du willst? Ich kann gar nicht ganz folgen. Also sagen wir mal, ich mache irgendwie ein Trace-Route von außen auf irgendeinen Router in meinem Freifunknet, also auf so ein Plastik-Router. Dann geht das ja irgendwie durchs Freifunk-Backbone, durch mein Gateway bis runter zu dem Router und die Antwort wird ja dann quasi über das Ether0-Interface meines Gateways verschickt und hat dann eigentlich ja quasi eine falsche absender IP-Adresse. Du willst von außen auf den Router zugreifen mit einer Public-V6-Adresse, die zum Beispiel von Rheinland kommt? Das heißt, der Hinweg ist relativ klar, und war aber bis zu dem Router durch durch das ganze Batman. Genau, und wenn ich jetzt schon Trace-Route mache, dann muss ja an irgendeiner Stelle mein Gateway jetzt mal so ein Paket zurückschicken, damit ich weiß, wo es lang geht. Wenn die TTL bei ihm gerade abläuft. Dann solltest du dafür Policy-Routing haben, wenn das eine Source-Adresse ist aus dem Netz, also from, wo ist es? Zeile 3 32, 7, 6, 4. Das gibt es für V6 genauso. Das muss man für beide Protokolle bauen. Ich habe das auch eine Weile verpennt, um das für IPv6 zu machen und wunderte mich, warum ULA-Adressen auf meinen externen Interfaces rausgehen. Wenn du das auch baust auf deinen Gateway für IPv6, dann sollte das Ganze auch über Rheinland zurückgehen. Okay, danke. Achso, IP-6-Route und IP-6-Route hilft natürlich ungemein, wenn man das Ganze mit IPv6 machen möchte.