ToFoIn v 1. Reservierung von Gateways und Umschalten zwischen externen Kanälen in FreeBSD

Anmerkung

In einem früheren Artikel wurde die Organisation der Redundanz für LAN-Gateways betrachtet. Als Lösung wurde ein Skript vorgeschlagen, das zu diesem Zeitpunkt das Problem löste, jedoch eine Reihe von Nachteilen aufwies. Nach einiger Zeit stellte sich heraus, dass diese Mängel beseitigt wurden, der Code teilweise neu geschrieben wurde und an der Ausgabe etwas Akzeptables erzielt wurde. Jetzt können wir sagen, dass die Skripte genug getestet wurden, um als stabil bezeichnet zu werden. Um das Verständnis des gesamten Systems zu vereinfachen, werden die wichtigsten Punkte für die Einrichtung von Sekundärdiensten (in Bezug auf das Thema des Artikels) im Folgenden teilweise dupliziert. Der Grund ist einfach: Während dieser Zeit wurden auch die ipfw-Regeln überarbeitet, DNS wurde in AD auf Samba4 mit einem Bind-Frontend und sicher aktualisierten Datensätzen von isc-dhcpd unter Verwendung von Kerberos sowie sekundären DNS-Servern als Bindung an die Gateways in Betrieb genommen. konfiguriertes CARP ... Im Allgemeinen ist es viel interessanter geworden, aber weiter unten erfahren Sie, was und wie es funktioniert. Alles, was mit Verweisen auf die Quelle angegeben werden kann, wird so gestaltet, dass keine Essenz entsteht. Was von anderen Orten genommen wurde, aber nicht mehr verfügbar ist, wird hier mit relevanten Kommentaren angegeben.

Einführung

Es gibt also zwei Möglichkeiten, um die Störfestigkeit des Kommunikationskanals mit der Außenwelt seitens des Verbrauchers zu erhöhen: Sicherung des Gateways und Reservierung des Verbindungspunkts. Mit anderen Worten, im ersten Fall wird ein zweites Gateway eingerichtet, das aktiviert wird, wenn das erste ausfällt. Im zweiten Fall wird ein Backup-Internetkanal organisiert, falls Probleme mit dem Hauptkanal auftreten. Je weiter sie sich kreuzen, desto besser. Wenn CARP die erste Aufgabe für FreeBSD löst, kann die zweite nach dem Organisieren des zweiten externen Kanals wieder auf verschiedene Arten gelöst werden. Zumindest können Sie den Verkehrsausgleich oder das Umschalten zwischen Kanälen organisieren. Aufgrund des großen Unterschieds in der Bandbreite externer Kanäle passte die erste Option nicht zu mir, daher wurde der Hauptschuldige der Veröffentlichung geschrieben: ToFoIn - eine Reihe von Bash-Skripten, die darauf abzielen, Diagnoseprobleme zu lösen und zu einem funktionierenden externen Kanal zu wechseln. Nach der Verfeinerung kann es auf n Gateways und m Kanäle angewendet werden. Die Situation ist schwach, wo n und m mehr als 2 sind, aber die folgenden Skripte sollten bis zu großen Werten von n und m funktionieren, weil Logischerweise ist das Limit nicht festgelegt. Im Allgemeinen vermute ich, dass es mit diesen Skripten möglich ist, eine ziemlich breite Palette von Aufgaben zu lösen, abhängig vom Status der Verbindung, die möglicherweise nur durch Vorstellungskraft begrenzt ist.


Ungefähr diese Netzwerktopologie setzt in ihrer einfachsten Form die Verwendung einer Reihe von ToFoIn-Skripten voraus. Natürlich sollten die Skripte bei einem einzelnen Router funktionieren, aber in diesem Fall müssen Sie das Daemon-Modul stark ändern, um die Abhängigkeit der Reihenfolge der Aktionen vom CARP-Status zu beseitigen, die im System einfach nicht vorhanden sind. Eine weitere Reservierung dieser und anderer Knoten hängt nur vom Grad der Wichtigkeit der entsprechenden Dienste ab.

Ziele und Vorgaben

Ziel des Projekts ist es nach wie vor, ein universelles und leicht skalierbares Softwarepaket zu erstellen, das sich darauf konzentriert, Probleme bei externen und internen Verbindungen zu identifizieren und automatisch auf funktionsfähige Verbindungen umzuschalten. Im Allgemeinen lautet die Logik wie folgt:

• Es gibt n "Router" mit jeweils m externen Kanälen. Darüber hinaus befinden sich alle n „Router“ in einer strengen Hierarchie und sind über CARP an allen erforderlichen Schnittstellen miteinander verbunden.
• Ein Agent arbeitet unabhängig auf jedem Computer, dessen Aufgabe auf dem aktuellen CARP-Status seines Computers basiert:
  
  • Bei Sicherung - Erkennen und konfigurieren Sie den Computer auf einem Router, der derzeit der Master ist.
  • Wenn Master - Überprüfen Sie den Status der Verbindungen zum aktuellen Zeitpunkt und wechseln Sie gegebenenfalls zwischen externen Kanälen.

Lösung

Das interne Netzwerk verfügt über CARP, das Backup-Gateways bereitstellt und es Ihnen ermöglicht, die Einstellungen anderer Netzwerkgeräte im internen Netzwerk beim Kanalwechsel nicht zu ändern.

Dhcpd arbeitet im primären - sekundären Modus und im Allgemeinen spielt es keine Rolle, welche anderen Rollen sein Computer spielt - die Verbindung zwischen dhcpd erfolgt im internen Netzwerk, das Router immer betrachten.

Die Masterbindung wird in AD entfernt, das im lokalen Netzwerk verborgen ist, während sekundäre Bindungsserver auf den Gateway-Routern gleichberechtigt arbeiten.

Die ipfw-Regeln unterscheiden sich je nachdem, welcher Kanal zu einem bestimmten Zeitpunkt als Hauptkanal betrachtet wird, und werden vom Daemon-Modul beim Rollenwechsel neu gestartet.

Zum Schluss noch zu den Skripten. Jetzt befinden sich die Dateien in den entsprechenden Verzeichnissen, arbeiten von ihrem Benutzer aus und haben ein Startskript in rc.d. Aufgaben, die Root-Zugriff erfordern, werden von sudo gelöst. Es gibt ein Installationsskript, das das mögliche Vorhandensein einer installierten Version berücksichtigt, sowie eine ziemlich detaillierte Einstellungsdatei. Die Module sind mit geringfügigen Änderungen identisch, einige haben sich in der Funktionalität fast nicht geändert:

Daemon ist - wie der Name schon sagt - der Hauptprozess, der die Test- und Switch-Module auf einem Timer ausführt und auch CARP überwacht.
Tester - testet weiterhin auf externe Kommunikation mit dem Befehl ping. (Wenn es ausgeführt wird, wird davon ausgegangen, dass sich auf der Maschine CARP im Master-Status befindet.)
Beurteilung - Bestimmt anhand der Testergebnisse, welcher externe Kanal funktioniert und ob eine Umschaltung erforderlich ist, führt eine Umschaltung durch (wenn sie ausgeführt wird, wird davon ausgegangen, dass die Maschine CARP im Master-Status hat).
Scout ist ein neues Modul. Es beginnt, wenn sich CARP im Sicherungsstatus befindet. Es muss ermittelt werden, welcher der verbleibenden Router derzeit der Hauptrouter ist.
Logger - verantwortlich für die Ereignisprotokollierung. Es ist notwendig, dass Informationen über Ereignisse nicht dupliziert werden und das Magazin leichter zu lesen ist.
Watchdog - läuft planmäßig von crontab aus. Es ermittelt das „Einfrieren“ aller Module und versucht (wann immer möglich), die aufgetretenen Probleme zu lösen. Das heißt, Nagel alle, einfach ausgedrückt.

Zusätzlich zu den Skripten selbst sollten einige wichtigere Dateien berücksichtigt werden:

Tofoin.conf - eine einzelne Einstellungsdatei.
Tofoin.log - eine einzelne Ereignisprotokolldatei.
Ergebnis_ <interne Kanalnummer> ist die Arbeitsdatei. Die Testergebnisse werden hier hinzugefügt und in / tmp neben .pid und anderen Arbeitsdateien erstellt.

Gerne beantworte ich die Fragen zum Betrieb der Module und erkläre die Lösungen in den Kommentaren.

Technischer Teil

Ausrüstung

Im Vergleich zur vorherigen Zeit wurden die Gateways auf P4 verschoben, erhielten 1536 MB RAM und drei 40-GB-Festplatten (Spiegel + Ersatz). Netzwerkkarten sind immer noch PCI, Netzteile sind normal, natürlich in Gegenwart einer USV.
Die Erhöhung der Kapazität ist mit dem freigesetzten Eisen und der übermäßig mühsamen Aktualisierung von der Quelle verbunden, meistens jedoch mit der ersten. OS FreeBSD 11.1, FS zfs.

Systemkomponenteneinstellungen

Software von Drittanbietern

Ein bisschen über ToFoIn

Der gesamte Projekttext zusammen mit dem Installationsskript ist auf gitlab verfügbar.

Zusammenfassung

Es stellte sich heraus, dass es sich um einen voll funktionsfähigen und zuverlässigen Satz von Skripten handelt, der die Aufgabe des Wechsels zum Arbeitskanal bei 2 Routern mit 2 externen Kommunikationskanälen gut bewältigt.

Pläne

Meine Pläne für dieses Projekt beziehen sich vielleicht darauf, von Bash auf Pure Sh umzuschreiben, um unnötige Software auf dem Server loszuwerden. Auf der anderen Seite funktioniert jetzt alles erstaunlich und ich habe wirklich keine Lust, mich in diesen Prozess einzumischen. Außerdem ist der Wechsel zu sh mit schrecklicheren Sprachkonstrukten behaftet, die notwendig sind, um das gleiche Ergebnis zu erzielen.
Im Übrigen lohnt es sich wahrscheinlich, die beste Implementierung von Testmodulen in Betracht zu ziehen.

Referenzen:

← Vorheriger Artikel
→ ToFoIn-Projektseite auf gitlab