☰

Backup-Internetverbindung für bestimmte Prozesse

tag-icon • tag-icon linux networking
Backup-Internetverbindung für bestimmte Prozesse

Ich möchte meinem Linux-Server eine zweite Backup-Internetverbindung hinzufügen. Ich plane, zu diesem Zweck ein USB-LTE-Modem zu verwenden.

Da diese Mobilfunkverbindung gemessen wird, möchte ich die Datenmenge, die verbraucht werden kann, auf das absolut notwendige Minimum beschränken.

Ich habe eine benutzerdefinierte Serveranwendung, an der ich beliebige Änderungen vornehmen kann. Sie hat einige Aufgaben, bei denen eine unterbrechungsfreie Konnektivität entscheidend ist, und andere Aufgaben, bei denen Ausfallzeiten keine große Rolle spielen.

Ich stelle mir so etwas vor:

  • Der Server muss eine externe HTTP-API-Anforderung stellen. Der erste Versuch erfolgt über die Standardroute des Systems (d. h. eth0, die primäre Internetverbindung).
  • Wenn die Anforderung fehlschlägt oder eine Zeitüberschreitung auftritt, versuchen Sie es erneut über die LTE-Schnittstelle.

Nur der Datenverkehr, den mein Serverprozess ausdrücklich über LTE senden möchte, sollte über LTE gesendet werden. Kein anderer Datenverkehr aus irgendeinem Teil des Systems sollte über LTE laufen.

  • Konkret verwende ich Node'slocalAddressSocket-Option, um anzugeben, dass die Anforderung über LTE erfolgen soll.
  • Wie stelle ich sicher, dass anderer Datenverkehr nicht über die LTE-Schnittstelle geroutet wird (selbst wenn eth0 ausgefallen ist)?
  • Was ist mit der DNS-Auflösung?

Antwort1

Dies gelang mir durch die Konfiguration einesalternative Routentabelleund einRouting-Richtlinienregelfür die Quelladresse der Backup-Schnittstelle.

Mein USB-LTE-Modem präsentiert sich als NDIS-Gerät, es wird also einfach mit der IP-Adresse 192.168.0.190 angezeigt eth1und führt intern NAT-Routing durch. Ich habe es eth1mit einer statischen IP-Adresse und manuell konfigurierten Routen konfiguriert.

  1. Die Standardkonfiguration verwendet DHCP. Schalten Sie daher die Schnittstelle ab und stellen Sie sicher, dass alle automatisch hinzugefügten Routen gelöscht werden.

  2. Fügen Sie eine statische IP-Konfiguration für die Schnittstelle hinzu und rufen Sie sie auf.

  3. Fügen Sie einer alternativen Routing-Tabelle (ich habe ausgewählt 1) Einträge für das Subnetz und das Standard-Gateway hinzu.

    # ip route add 192.168.0.0/24 dev eth1 src 192.168.1.190 table 1
# ip route add default via 192.168.0.1 table 1

  4. Legen Sie Routing-Richtlinienregeln fest, sodass Apps, die explizit 192.168.1.190 als Quelladresse verwenden, die Routing-Tabelle 1 statt der Standardadresse verwenden.

    # ip rule add from 192.168.0.190/32 table 1
# ip rule add to 192.168.0.190/32 table 1

An diesem Punkt sollten Sie Ihre Konnektivität testen können.

$ curl https://wtfismyip.com/text
1.2.3.4  # primary ISP external IP
$ curl --interface 192.168.0.190 https://wtfismyip.com/text
5.6.7.8  # backup LTE external IP

Wenn alles gut aussieht, machen Sie die Konfiguration dauerhaft. Ich habe hinzugefügt /etc/network/interfaces:

iface eth1 inet static
        address 192.168.0.190
        netmask 255.255.255.0
        post-up ip route add 192.168.0.0/24 dev eth1 src 192.168.0.190 table 1
        post-up ip route add default via 192.168.0.1 table 1
        post-up ip rule add from 192.168.0.190/32 table 1
        post-up ip rule add to 192.168.0.190/32 table 1

Jetzt werden nur Apps, die bei ausgehenden Verbindungen explizit an 192.168.0.190 gebunden sind, über die Backup-Verbindung geleitet. Der gesamte übrige Datenverkehr wird über die Verbindung geleitet (oder über das, was in der [Standard-]Routingtabelle eth0konfiguriert ist ).main

Es istmöglichdass Sie etwas haben, das alle verfügbaren IPs auflistet und versucht, Datenverkehr von ihnen zu senden, was zu unerwartetem Datenverkehr über die Backup-Verbindung führen könnte, aber das ist unwahrscheinlich. Ich habe keinen solchen Datenverkehr beobachtet.

Beachten Sie, dass dies nicht die DNS-Auflösung betrifft. In einer Situation, in der die primäre Verbindung offline ist, haben Sie vielleicht Glück und können eine Abfrage aus dem Cache durchführen, aber darauf kann man sich nicht verlassen. Ich würde den systemweiten Resolver auch nicht so konfigurieren, dass er Anfragen über die LTE-Schnittstelle sendet. Stattdessen könnte Ihre App die DNS-Auflösung manuell handhaben, wenn sie Sicherungsanfragen stellt.

Mit node ist es ganz einfach, HTTP-Anfragen (oder eine beliebige TCP-Verbindung) von einer bestimmten Quelladresse aus zu stellen. Geben Sie einfach dielocalAddressMöglichkeit, z.B:

https.get('https://wtfismyip.com/text', { localAddress: '192.168.0.190' }, …);

Die Lösung des DNS-Lookups ist etwas kniffliger. lookupEs gibt auch eine Option, mit der Sie den Standard-DNS-Auflösungsprozess überschreiben können. Sie können eine benutzerdefiniertedns.Resolverum Lookups durchzuführen. Leider hatte Node keine Möglichkeit, die Quelladresse für DNS-Lookups anzugeben,also habe ich es hinzugefügt. Wenn das erledigt ist, können Sie die Teile zusammenfügen:

const resolver = new dns.Resolver();
resolver.setServers(['8.8.8.8']);
resolver.setLocalAddress('192.168.0.190'); // requires node > v15.0.0

https.get('https://wtfismyip.com/text', {
  localAddress: '192.168.0.190',
  lookup: function(hostname, opts, cb) {
    resolver.resolve(hostname, function(err, records) {
      if (err) cb(err);
      else if (!records[0]) cb(new Error('Missing DNS record'));
      else cb(null, records[0], 4);
    });
  }
}, function(res) { … });

verwandte Informationen