Резервное интернет-соединение для конкретного процесса

Я хотел бы добавить вторичное резервное интернет-подключение к своему серверу на Linux. Я планирую использовать для этой цели USB LTE модем.

Поскольку это сотовое соединение будет с ограничением по трафику, я хочу сократить количество данных, которые могут потребляться, до абсолютного минимума, необходимого для работы.

У меня есть собственное серверное приложение, в которое я могу вносить любые изменения. Оно выполняет несколько задач, для которых критически важна непрерывная связь, и другие задачи, где время простоя не имеет большого значения.

Я представляю это примерно так:

• Серверу нужно сделать внешний HTTP API запрос. Первая попытка осуществляется по умолчанию системы (например, eth0, основное интернет-подключение).
• Если запрос не удался или время ожидания истекло, повторить запрос через интерфейс LTE.

Только трафик, который мой серверный процесс явно хочет отправить через LTE, должен отправляться через LTE. Никакой другой трафик из любой части системы не должен идти через LTE.

• В частности, я буду использовать опцию сокета localAddress в Node.js, чтобы указать, что запрос должен быть сделан через LTE.
• Как мне гарантировать, что другой трафик не будет маршрутизироваться через интерфейс LTE (даже если eth0 не работает)?
• Что насчет разрешения DNS?

В итоге я реализовал это, настроив альтернативную таблицу маршрутов и правило политики маршрутизации для исходного адреса резервного интерфейса.

Мой USB LTE модем представлен как устройство NDIS, поэтому он просто отображается как eth1 с IP-адресом 192.168.0.190 и выполняет NAT-маршрутизацию внутри. Я настроил eth1 с постоянным IP-адресом и вручную настроил маршруты.

1. Стандартная конфигурация использует DHCP, поэтому отключите интерфейс и убедитесь, что все автоматически добавленные маршруты удалены.

2. Добавьте статическую конфигурацию IP для интерфейса и подключите его.

3. Добавьте записи в альтернативную таблицу маршрутов (я выбрал 1) для подсети и шлюза по умолчанию.

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

4. Установите правила политики маршрутизации так, чтобы приложения, которые явно используют 192.168.0.190 в качестве своего исходного адреса, использовали таблицу маршрутов 1 вместо стандартной.

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

На этом этапе вы должны иметь возможность протестировать ваше соединение.

$ curl https://wtfismyip.com/text
1.2.3.4  # Внешний IP основного провайдера
$ curl --interface 192.168.0.190 https://wtfismyip.com/text
5.6.7.8  # Внешний IP резервного LTE соединения

Если все в порядке, сделайте конфигурацию постоянной. Я добавил следующее в /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

Теперь только приложения, которые явно связываются с 192.168.0.190 при установлении исходящих подключений, будут маршрутизироваться через резервное соединение. Весь остальной трафик будет маршрутизироваться через eth0 (или что-либо, что настроено в main [таблице маршрутов по умолчанию]).

Возможно, у вас есть что-то, что перечисляет все доступные IP-адреса и пытается отправить трафик с них, что может привести к неожиданному трафику через резервное соединение, но это маловероятно. Я не наблюдал такого трафика.

Обратите внимание, что это не решает проблему разрешения DNS. В ситуации, когда основное соединение отключено, вы можете повезти и получить результат поиска из кэша, но на это не стоит полагаться. Я бы не стал настраивать системный резольвер для отправки запросов через интерфейс LTE. Вместо этого ваше приложение может вручную обрабатывать разрешение DNS при осуществлении резервных запросов.

В Node.js выполнение HTTP-запросов (или любого TCP-соединения) из определенного исходного адреса просто. Просто укажите опцию localAddress option, например:

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

Решить вопрос с DNS немного сложнее. Также доступна опция lookup, которая позволяет переопределить процесс разрешения DNS по умолчанию. Вы можете использовать пользовательский dns.Resolver для выполнения разрешения. К сожалению, в Node.js не было способа указать исходный адрес для запросов DNS, поэтому я добавил его. С этим вы можете объединить все элементы воедино:

const resolver = new dns.Resolver();
resolver.setServers(['8.8.8.8']);
resolver.setLocalAddress('192.168.0.190'); // требуется 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) { … });