ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Протоколы группы FHRP (First Hop Redundancy Protocols)
Полный курс по Сетевым Технологиям
В курсе тебя ждет концентрат ТОП 15 навыков, которые обязан знать ведущий инженер или senior Network Operation Engineer
Итак начнём с HSRP
Протокол HSRP рассчитан на 2 роутера, 3 это уже лишний и с этим уже справиться протокол GLBP
Сам VPC должен получить следующие настройки: IP : 192.168.0.10/24 GW: 192.168.0.254
TRACKING
R1,R2,R0 будут настраиваться одинаково, принцип сохраняется.
А теперь нюансы HSRP
Поэтому рекомендуют использовать HSRP version 2(по умолчанию вкл 1 максимум 255 процессов,а во 2 их 4095) и использовать наилучший приоритет для того роутера, который сейчас в сети root primary за текущий VLAN. И хорошей практикой будет если номер VLAN будет совпадать с номером процесса HSRP. ( № HSRP = VLAN )
Диагностика
Онлайн курс по Кибербезопасности
Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии
Принцип работы протокола VRRP
FHRP (First Hop Redundancy Protocol) — семейство протоколов, предназначенных для создания избыточности шлюза по умолчанию. Общей идеей для данных протоколов является объединение нескольких маршрутизаторов в один виртуальный маршрутизатор с общим IP адресом. Этот IP адрес будет назначаться на хостах как адрес шлюза по умолчанию. Свободной реализацией данной идеи является протокол VRRP (Virtual Router Redundancy Protocol). В этой статье рассмотрим основы протокола VRRP.
VRRP-маршрутизаторы объединяются в один виртуальный маршрутизатор. Все маршрутизаторы в группе имеют общий виртуальный IP (VIP) адрес и общий номер группы или VRID (Virtual Router Identifier). Один маршрутизатор может состоять в нескольких группах, каждая из которых должна иметь свою уникальную пару VIP/VRID.
В случае с Cisco виртуальный маршрутизатор задается на интересующем нас интерфейсе командой:
Все маршрутизаторы делятся на два типа: VRRP Master и VRRP Backup.
VRRP Master — это маршрутизатор, который занимается пересылкой пакетов для данного виртуальной группы.
VRRP Backup — это маршрутизатор, который ожидает пакет от Master. Если пакеты от Master перестают приходить, Backup пытается перейти в состояние Master.
Маршрутизатор становится Master, если имеет наивысший приоритет. Master постоянно рассылает сообщения на широковещательный адрес 224.0.0.18, чтобы сообщить Backup маршрутизаторам, что он работает. Master отправляет сообщения согласно таймеру Adver Timer, равный по умолчанию 1 секунде.
При этом в качестве MAC адреса отправителя используется адрес группы 00:00:5E:00:01:xx, где xx — VRID в шестнадцатеричном формате. В данном примере используется первая группа.
Если Backup маршрутизаторы не получают сообщения в течении трех Adver Timer (Master Down Timer), то новым Master становится маршрутизатор с наибольшим приоритетом, либо маршрутизатор с наибольшим IP. При этом Backup маршрутизатор с более высоким приоритетом перехватит роль Master с более низким приоритетом. Однако, когда у Backup отключен режим preempt, Backup не станет перехватывать роль у Master.
Если VRRP-маршрутизатор является владельцем VIP адреса, то он всегда перехватывает роль Master.
VRRP приоритет задается в значениях от 1 до 254. Значение 0 зарезервировано для случаев, когда Master необходимо снять с себя ответственность за маршрутизацию. Значение 255 устанавливается маршрутизатору владельцу VIP. Приоритет по умолчанию равен 100, но может задаваться административно:
Здесь мы можем увидеть приоритет маршрутизатора, когда он задан административно:
А тут представлен случай, когда маршрутизатор является владельцем VIP:
VRRP маршрутизатор может иметь три состояния: Initialize, Backup, Master. Эти состояния маршрутизатор последовательное меняет.
В состоянии Initialize маршрутизатор ожидает начала работы. Если этот маршрутизатор является владельцем VIP адреса (приоритет равен 255), то маршрутизатор отправляет сообщения о том что становится Master. Он также отправляет gratuitous ARP-запрос, в котором MAC-адрес источника равен адресу виртуального маршрутизатора. Затем он переходит в состояние Master. Если маршрутизатор не является владельцем VIP, то он переходит в состояние Backup.
В состоянии Backup маршрутизатор ожидает пакеты от Master. Маршрутизатор в этом состоянии не отвечает на ARP-запросы от VIP-адреса. Также он не принимает пакеты, у которых в качестве адреса назначения стоит MAC-адрес виртуального маршрутизатора.
Если Backup не получает сообщения от Master в течение Master Down Timer, то он отправляет VRRP сообщение о том, что собирается стать Master. Затем отправляет широковещательное VRRP сообщение, в котором MAC-адрес источника равен адресу этого виртуального маршрутизатора. В данном сообщении маршрутизатор указывает свой приоритет.
В состоянии Master маршрутизатор обрабатывает пакеты, адресованные виртуальному маршрутизатору. Он так же отвечает на ARP-запросы к VIP. Master рассылает VRRP сообщения каждые Adver Timer, чтобы подтвердить что он работает.
VRRP также позволяет балансировать нагрузку между несколькими маршрутизаторами. Для этого на одном интерфейсе создается две VRRP группы. Одной группе назначается больший приоритет, чем другой. При этом на втором маршрутизаторе приоритет задается противоположным образом. Т.е. если на одном маршрутизаторе приоритет первой группы равно 100, а второй группы — 200, то на другом маршрутизаторе приоритет первой группы будет 200, а второй 100.
Как сказано ранее, в каждой группе должен быть свой уникальный VIP. В итоге, мы получаем два ip адреса, обслуживаемые двумя маршрутизаторами, каждый из которых может служить шлюзом по умолчанию.
Половине компьютеров назначается один адрес шлюза по умолчанию, половине другой. Таким образом половина трафика будет идти через один маршрутизатор, а половина через другой. При выходе из строя одного из маршрутизаторов, второй перехватывает на себя работу обеих VIP.
Введение в сети TCP/IP
Маршрутизация (routing) — процесс определения маршрута следования информации в сетях. Разбиение одной большой сети на несколько маленьких подсетей позволяет упростить маршрутизацию.
Компьютеры в подсетях объединяются общими начальными битами адреса. Количество этих бит, общее для данной подсети, называется маской подсети. В терминологии сетей TCP/IP маской подсети или маской сети называется битовая маска, определяющая, какая часть IP-адреса узла сети относится к адресу сети, а какая — к адресу самого узла в этой сети. Например, узел с IP-адресом 12.34.56.78 и маской подсети 255.255.0.0 находится в сети 12.34.0.0. Это бесклассовая адресация, т.е. адресация, основанная на переменной длине маски подсети. Чтобы получить адрес сети, зная IP-адрес и маску подсети, необходимо применить к ним операцию поразрядной конъюнкции (логическое И). Например, в случае более сложной маски:
Маску подсети иногда записывают вместе с IP-адресом в нотации CIDR (Classless InterDomain Routing), в формате «IP-адрес/количество бит в маске, установленных в единицу»). Для вышеприведённого примера это будет 12.34.56.78/19.
Например, пусть таблица маршрутизации некоего маршрутизатора содержит следующую запись:
Пусть теперь маршрутизатор получает пакет данных с адресом назначения 12.34.56.78. Обрабатывая построчно таблицу маршрутизации, он обнаруживает, что при наложении маски 255.255.0.0 на адрес 12.34.56.78 получается адрес сети 12.34.0.0. В таблице маршрутизации этой сети соответствует шлюз 11.22.3.4, которому и отправляется пакет. Примечание: шлюзом часто называют устройство, предоставляющее доступ к внешней сети.
Если в качестве узла назначения в IP-адресе стоят только единицы, то пакет, имеющий такой адрес, рассылается всем узлам сети с заданным номером сети. Например, в сети 192.190.21.0 пакет с адресом 192.190.21.255 доставляется всем узлам этой сети. Такая рассылка называется широковещательным сообщением (broadcast).
IP-адрес называют динамическим, если он назначается автоматически при подключении устройства к сети и используется в течение ограниченного промежутка времени (как правило, до завершения сеанса подключения). Для получения IP-адреса клиент может использовать протокол DHCP (Dynamic Host Configuration Protocol — протокол динамической конфигурации узла). Компьютер обращается к специальному серверу, называемому сервером DHCP. Сетевой администратор может задать диапазон адресов, распределяемых среди компьютеров. Это позволяет избежать ручной настройки компьютеров сети и уменьшает количество ошибок.
В Windows вы можете узнать настройку протокола IP для своего компьютера, введя команду:
Для корректной маршрутизации входящих и исходящих сигналов различных служб TCP/IP сопоставляет различным службам разные порты. Порт представляет собой число, обозначающее виртуальный электронный интерфейс. Например, протокол FTP связывается с портом 21, а серверы Web связываются с портом 80.
Протокол DHCP предоставляет три способа распределения IP-адресов:
Помимо IP-адреса, DHCP также может сообщать клиенту дополнительные параметры, необходимые для нормальной работы в сети (опции DHCP). Некоторыми из наиболее часто используемых опций являются IP-адрес маршрутизатора по умолчанию, маска подсети, адреса серверов DNS, имя домена DNS.
Процесс получения IP-адреса клиентом от сервера DHCP состоит из четырёх этапов:
Если после получения подтверждения от сервера DHCP клиент обнаруживает, что указанный сервером адрес уже используется в сети, он рассылает широковещательное сообщение отказа DHCP, после чего процедура получения IP-адреса повторяется. Если по каким-то причинам сервер не может предоставить клиенту запрошенный IP-адрес, или если аренда адреса удаляется администратором, сервер рассылает широковещательное сообщение отмены DHCP. При получении такого сообщения соответствующий клиент должен повторить процедуру получения адреса. Клиент может явным образом прекратить аренду IP-адреса; для этого он отправляет сообщение освобождения DHCP тому серверу, который предоставил ему адрес в аренду.
Компания Microsoft впервые включила сервер DHCP в поставку серверной версии Windows NT 3.5, выпущенной в 1994 году. Начиная с Windows 2000 Server реализация DHCP-сервера от Microsoft позволяет динамически обновлять записи DNS, что используется в Active Directory.
Имя хоста и IP-адрес не тождественны — хост с одним IP-адресом может иметь множество имён, что позволяет, например, поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное также справедливо.
Коммутатор (свитч) хранит в памяти специальную таблицу, в которой указывается соответствие MAC-адреса узла порту коммутатора. При включении коммутатора эта таблица пуста, и он работает в режиме обучения. В этом режиме поступающие на какой-либо порт данные передаются на все остальные порты коммутатора. При этом коммутатор анализирует пакеты данных, определяя MAC-адрес компьютера-отправителя, и заносит его в таблицу. Впоследствии, если на один из портов коммутатора поступит пакет, предназначенный для этого компьютера, этот пакет будет отправлен только на соответствующий порт. Со временем коммутатор строит полную таблицу для всех своих портов, и в результате трафик локализуется.
Чаще всего прокси-серверы применяются для следующих целей:
Инструменты командной строки в Windows
Вы можете получить подробную справку по каждой из нижеперечисленных команд, набрав в командной строке:
Команда NETSTAT отображает статистику протокола и текущих сетевых подключений TCP/IP.
Команда PING проверяет наличие связи с указанным узлом.
Команда TRACERT выводит имена и IP-адреса всех маршрутизаторов, через которые проходят пакеты от локального компьютера к указанному узлу.
Команда IPCONFIG выводит различные сведения о текущей конфигурации протокола IP и может осуществлять базовое конфигурирование этого протокола.
Команда NSLOOKUP обращается с запросом к DNS-серверу.
Команда NETSH показывает различные параметры настроек сети.
Протокол HTTP
HTTPS — расширение протокола HTTP, поддерживающее шифрование. Данные, передаваемые по протоколу HTTP, «упаковываются» в криптографический протокол SSL или TLS, и тем самым обеспечивается защита этих данных. В отличие от HTTP, для HTTPS по умолчанию используется порт 443.
Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI(URL). В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, т.к. к нему не предъявляются такие требования.
Стандарт HTTP 1.1 описан в официальном документе RFC 2068, который можно найти в Интернете.
Каждый запрос/ответ состоит из трёх частей:
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
Возможные методы (в основном используются методы GET и POST):
| OPTIONS | Возвращает методы HTTP, которые поддерживаются сервером. Этот метод может служить для определения возможностей веб-сервера. |
| GET | Запрашивает содержимое указанного ресурса. Запрашиваемый ресурс может принимать параметры (например, поисковая система может принимать в качестве параметра искомую строку). Они передаются в строке URI (например: http://www.example.net/resource?param1=value1¶m2=value2). Согласно стандарту HTTP, многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET. |
| HEAD | Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Это полезно для извлечения мета-информации, заданной в заголовках ответа, без пересылки всего содержимого. |
| POST | Передаёт пользовательские данные (например, из HTML-формы) заданному ресурсу. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. В отличие от метода GET, многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться одна копия этого комментария). |
| PUT | Загружает указанный ресурс на сервер. |
| DELETE | Удаляет указанный ресурс. |
| TRACE | Возвращает полученный запрос так, что клиент может увидеть, что промежуточные сервера добавляют или изменяют в запросе. |
| CONNECT | Для использования вместе с прокси-серверами, которые могут динамически переключаться в туннельный режим SSL. |
Стартовая строка ответа выглядит так:
Первая цифра кода статуса предназначена для определения класса ответа.
Отдельные значения кодов и описаний статуса:
| 100 | Continue | Клиент может продолжать запрос. |
| 101 | Switching Protocols | Сервер принял запрос клиента на переключение на модифицированный протокол. |
| 200 | Oк (НТТР_ОК) | Успешный запрос. |
| 201 | Created (HTTP_CREATED) | Запрос выполнен, в результате этого был создан новый запрос. |
| 202 | Accepted (HTTP_ACCEPTED) | Запрос был принят на обработку, но обработка не завершена. |
| 203 | Non-Authoritative Information (HTTP_NON_AUTHORITATIVE) | Возвращенная информация была собрана с копии третьей стороны. |
| 204 | No Content (HTTP_NO_CONTENT) | Сервер обработал запрос, но в результате данные не получены. |
| 205 | Reset Content | Пользовательский агент переустановит отображение документа. |
| 206 | Partial Content | Сервер выполнил частичный запрос GET к документу. |
| 300 | Multiple Choices (HTTP_MULTIPLE_CHOICES) | Этот заголовок используется для того, чтобы показать, что удовлетворять запрос может более чем один документ. |
| 301 | Moved Permanently (HTTP_MOVED_PERMANENTLY) | Запрошенный документ был перенесен на новый URI. |
| 302 | Found (HTTP_FOUND) | Запрошенный ресурс был временно перемещен на новый URI. |
| 303 | See Other (HTTP_SEE_OTHER) | Ответ на запрос можно найти под различными URI. Он может быть выбран с помощью запроса, сделанного методом GET к этому ресурсу. |
| 304 | Not Modified (HTTP_NOT_MODIFIED) | Сервер отвечает этим кодом, когда клиент выполнил условный запрос GET и запрос был разрешен, но документ не модифицирован. |
| 305 | Use Proxy (HTTP_USE_PROXY) | Доступ к запрошенному ресурсу должен производиться через proxy, заданный в поле Location. Поле Location задает URI для proxy. |
| 307 | Temporary Redirect (HTTP TEMPORARY REDIRECT) | Запрошенный ресурс временно находится под другими URI. Так как переадресация может быть отменена в любой удобный момент, для будущих запросов клиент должен использовать Request-URI. |
| 400 | Bad Request | Запрос не понят сервером из-за наличия синтаксической ошибки. |
| 401 | Unauthorized | Запрос требует идентификации пользователя. |
| 402 | Payment Required | Требуется оплата. |
| 403 | Forbidden | Сервер понял запрос, но он отказывается его выполнять. Запрещено. Идентификация тут не помогает. |
| 404 | Not Found | Сервер не нашел соответствия по запросу Request-URI. |
| 405 | Method Not Allowed | Метод, указанный в Request-Line, не соответствует ресурсу, заданному Request-URI. |
| 406 | Not Acceptable | Ресурс, определенный запросом, может генерировать только ответ, характеристики которого не соответствуют заголовкам, посланным в запросе. |
| 407 | Proxy Authentication Required | Этот код подобен коду 401 (unauthorized), но в этом случае клиент должен сначала идентифицировать себя с помощью proxy. |
| 408 | Request Time-out | На протяжении периода ожидания сервера клиент не сделал запроса. |
| 409 | Conflict | Запрос не будет завершен вследствие конфликта с текущим состоянием ресурса. |
| 410 | Gone | Запрошенный ресурс и адрес, по которому можно сделать пересылку, на сервере отсутствуют. |
| 411 | Length Required | Сервер отказывается принимать запрос без определенного Content-Length. |
| 412 | Precondition Failed | При проверке на сервере одного или более полей заголовка запроса обнаружено несоответствие. |
| 413 | Request Entity Too Large | Сервер отказывается обрабатывать запрос потому, что размер запроса больше того, что может обработать сервер. |
| 414 | Request-URI Too Large | Сервер отказывается обрабатывать запрос потому, что Request-URI превышает размеры, которые может обработать сервер. |
| 415 | Unsupported Media Type | Неподдерживаемый медиа тип. |
| 500 | Internal Server Error | Внутренняя ошибка сервера. |
| 501 | Not Implemented | Сервер не поддерживает возможностей, необходимых для обработки запроса. |
| 502 | Bad Gateway | Сервер, функционирующий как шлюз или proxy, получил ошибочный ответ от подчиненного сервера, к которому он попытался получить доступ для обработки запроса. |
| 503 | Service Unavailable | В данный момент сервер не в состоянии обработать запрос из-за того, что сервер перегружен или находится на профилактическом обслуживании. |
| 504 | Gateway Time-out | Работая в режиме шлюза или proxy, сервер не получил вовремя ответ от сервера верхнего уровня. |
| 505 | HTTP Version not supported | Сервер не поддерживает или отказывается поддерживать версию протокола HTTP, которая была использована в последнем запросе. |
Заголовки HTTP — это строки, каждая из которых состоит из имени параметра, за которым следует двоеточие и его значение. Они несут информацию для браузера или для серверных программ (таких, как CGI-приложения). Между заголовками и телом обязательно должна быть пустая строка.
Пример HTTP (запрос):
В цепочке запросов/ответов HTTP могут присутствовать один или несколько посредников. Существуют три основных разновидности посредников: прокси-сервера, шлюзы и туннели.
Любая сторона соединения, которая не действует как туннель, может использовать внутренний кэш для обработки запросов. Не все ответы полезно кэшировать, а некоторые запросы могут содержать модификаторы, которые включают специальные требования, управляющие поведением кэша.
Сокеты
Интерфейс сокетов впервые появился в Unix и в той или иной мере поддерживается всеми современными операционными системами.
Настраиваем отказоустойчивость Pi-Hole в связке с Mikrotik
В прошлой статье мы внедрили домашний сервер DoH с использованием Pi-Hole, чем не только пофильтровали большое количество рекламы, но и инкапсулировали наши DNS-запросы в HTTPS, что вывело их из поля фильтрации запросов оператором связи.
Настраиваем автоматическое переключение DNS-сервиса между Pi-Hole и Mikrotik, используя протокол VRRP в реализации демона keepalived.
Никаких волшебных know-how не открывается, простая пошаговая инструкция для тех, кому не хочется разбираться во всех хитросплетениях самому.
Что вам для этого потребуется
Исходные данные
IPv4-адрес нашего сервера Pi-Hole в домашней сети: 192.168.1.10 и он назначен как статический.
IPv4-адрес нашего маршрутизатора в домашней сети: 192.168.1.1 и он назначен как статический на интерфейсе bridge маршрутизатора.
Новый IPv4-адрес DNS: 192.168.1.9
Логика решения и немного теории
Чтобы не превращать статью в совсем уж деревянную инструкцию «нажмите третьим пальцем левой руки на кнопку W», расскажу самую базовую теорию того, что мы пытаемся сделать.
Итак, название протокола VRRP расшифровывается как Virtual Router Redundancy Protocol и он входит в группу протоколов NHRP (Next-Hop Resolution Protocol). Почему-то многие люди считают, что с использованием этих протоколов можно резервировать только адреса шлюзов по умолчанию, хотя, разумеется, это не так. Самому протоколу совершенно без разницы, какие сервисы с его помощью резервируются, он работает на третьем уровне модели ISO/OSI и фактически просто создает виртуальный IP-адрес, который будет перемещаться между устройствами, входящими в VRRP-группу, по определенным критериям. Очевидно, что такая логика подразумевает существование этого адреса только на одном устройстве, поэтому обеспечить, например, балансировку нагрузки между серверами с помощью стандартного VRRP нельзя (но в нашем случае этого и не требуется). Для тех кейсов, где это необходимо, существует, например, проприетарный протокол Cisco GLBP, где адрес активен одновременно на всех устройствах группы, а балансировка осуществляется за счет разных ARP-ответов. По подобной GLBP логике работает и протокол CARP.
Большим плюсом для нас является возможность изменять приоритет на ходу. У Cisco используемая для этого фича, например, называется Enhanced Object Tracking. Но она такая есть у любой известной мне имплементации протокола, в том числе и у линуксового демона.
На основе этой фичи вырисовывается логика всей нашей конструкции:
Настраиваем на нашем маршрутизаторе в качестве основных DNS сервера провайдера
Настраиваем между маршрутизатором и Pi-Hole VRRP с приоритетами 100 на маршрутизаторе и 90 на Pi-Hole
Создаем на Pi-Hole скрипт, проверяющий работоспособность DNS и при успешности повышающий приоритет на Pi-Hole до 110
Раздаем домашним клиентам по DHCP наш виртуальный IP-адрес как адрес DNS.
Настройка
1. Настройка DNS на Mikrotik
2. Настройка VRRP на Mikrotik
Создаем новый VRRP интерфейс с привязкой к интерфейсу Bridge и навязываем на него наш виртуальный адрес. Можно сделать в Winbox, но гораздо проще сделать это в терминале:
3. Настройка VRRP на Pi-Hole
Устанавливаем демон keepalived:
Создаем файл конфигурации демона /etc/keepalived/keepalived.conf:
Создаем скрипт проверки живости DNS /etc/keepalived/check_dns.sh:
и не забываем сделать его исполняемым:
Теперь достаточно перезапустить сервис:
и всё заработает. В логе Mikrotik можно будет увидеть запись, подобную этой:
4. Настройка DHCP на Mikrotik
Особо ответственные могут каким-либо образом сломать своему DNS-серверу резолвинг и проконтролировать, что по истечении таймаута виртуальный адрес переползет на Mikrotik. Но это уже зависит от вашей фантазии.
Заключение
Как обычно, никаких особых тайн не открыл, но для тех, кто не сталкивался с отказоустойчивостью сервисов, надеюсь, подсказал новый путь улучшения вашей домашней сети. Конечно, решение можно менять под себя в широком диапазоне вариантов, от него скорее можно отталкиваться при появлении каких-то близких по логике задач.
На вопросы, традиционно, отвечу и с настройками помогу.
