Владимир

Вам стоит понимать что когда будет происходить переключение между провайдерами то соединения - в первую очередь tcp они всеравно будут разорваны и установлены заново, так как у вашего сервера смениться ип адрес и маршрут, как на это будут реагирывать программы/сервисы работающие на вашем сервере - вам виднее.

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

Так как вы не указали ОС на сервере то нет возможноти вам советывать реализацию переключения между провайдерами.

Давайте угадаю, 300мб комп с SSD, а 60мб - комп с HDD

Вы можете использовать сервисы типа Cloudflare для маскировки вашего домашнего сервера.

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

Чтобы сервер мог принимать соединения из интернета через любой из провайдеров одновременно:
нужно настроить правила машрутизации под каждого провайдера, почитать это можно тут LARTC в пункте 4.2.1.

Я бы попробывал решить проблему через настройку трафик шейпинга внутри тогоже дебиана в сторону каждого отдельного клиента (например если поток 10МБит - ограничить до 15Мбит) при помощи например https://lartc.org/howto/lartc.qdisc.html (начало документации) Если же прям внутри нет такой возможности то между сетью с потребителями железкой поставить чтото что будет шейпить трафик.

Если у всех стоит одинаковый priority и state BACKUP - никто ип не поднимет тк как все ноды думаю что они бекап, а мастера нет. Одна нода должна быть с "state MASTER" и большим priority чем у остальных

Настройка L2TP/IPsec может оказатся весьма не тривиальной задачей на linux - я вам не советую, на windows поидее все проще. Инструкций в интернете достаточно.
PPTP настраивается легко в обоих ОС и легко гуглятся инструкции но он весьма устарел и не рекомендуется к использованию.
Еще как вариант поставить на сервер чтото типа vyos (бесплатный програмный роутер настройка схожа на настройки cisco/juniper)
З.Ы. микротик ивправду бы вам сэкономил изрядно времени.

Для себя в блокноте напишете:
1 - какие проблемы сейчас есть
2 - какие проблемы вероятны в будущем
3 - как каждое устройство эти проблемы решает
Пройдитесь по списку того что хотите покупать и тд, после уже в таком виде выкладывайте тут - это повзолит посоветывать вам лучше и точнее. Так как сейчас информации не достаточно.

Проверить нат(маскарадинг)
Проверить что wan порт не в бридже с lan портами

Проблема в том что если "не основной шлюз" имеет обычный nat и порт форвардинг то на ваш хост с slackware просто приходит пакет от внешнего ип и нет возможности определить через какой шлюз он пришол, поэтому вам придется настраивать еще 1 нат на "не основной шлюзе" чтобы он обращался к хосту с slackware от cвоего локального ип при порт форвардинге.
Это скорее всего еще больше усложнит ваш бардак, завести второй ип на хосте с slackware и чтобы "не основной шлюз" форвардил пакеты только туда - будет рациональнее.

Никто не знает что ему пригодится, тут ничего не поделаеш.
Модель нигде не используется но позволяет понять как именно работает сеть от аппратной части до програмной, понять то что сеть это не просто "воткнул шнур и работает".
Я бы сказал что это основа понимания работы сети которая обязательно пригодится сисадминам, также будет полезна програмистам которые пишут приложения использующие сеть.

Eсли у вас несколько офисов\филиалов то вам их нужно связать VPN туннелем через интернет, настраивается это на маршрутизаторах офисов. туннель выбирайте изходя из возможностей ваших маршрутизаторов.

Оч критично, примеры:
1 - Соседи за стеной начали греть сосиски в микроволновке и у вас был пинг 60 а стал 350
2 - Дед Василий во дворе электросваркой варит свой старый москвич - у вас потери пакетов 30%
и так далее.
Для FPS шутеров - только провод.

Если входящие соединения не к шлюзу непосредственно а к какимто сервисам в локальной сети (на шлюзе просто проброшены порты) то такие соединения можно ограничивать на выходе из шлюза в сторону локальной сети.

Возможно проблема в том что роутер имеет уже настроенный проброс портов с внешнего ип на ип виндовс где находится web-сервер, и в случае если запрос (по доменному имени) с телефона приходит на внейшний ип то он проходит через NAT кторый сохраняет ип источника запроса и этот ип локальный и винда где находится вебсервер видя что запрос пришол с адреса из своей подсети ответит напрямую а не через роутер, хотя телефон то отправлял запрос на внейшний ип и ждет ответ от негоже.
Краткая схема:
192.168.0.1 и 178.248.232.5 - адреса роутера (внутренний и внешний)
192.168.0.2 - вебсервер
192.168.0.3 - телефон
что происходит: пакет от 192.168.0.3 идет на 178.248.232.5 проходит NAT и попадает к 192.168.0.2
192.168.0.2 видя что источник запроса из тойже сети согласно своей таблице маршрутизации отвечает напрямую 192.168.0.3
но 192.168.0.3 не ждет пакетов от 192.168.0.2 и поэтому его отбрасывает и дальше ждет ответа от 178.248.232.5
в итоге ничего не работает.
Как починить:
1 если есть возможность настроить статик днс внутри роутера чтобы адрес домена внутри сети резолвился в вебсерер
2 настроить hairpin nat, но врядли это можно сделать на обычной прошике TPlink (например на микротике это весьма не просто настраивается)