hint000

Давайте разберём на примере шпионов. В городе N работают два глубоко законспирированных шпиона - Агент Икс и Агент Игрек. Каждый из них не знает, где живёт другой (серые адреса). Им и не полагается знать, чтобы если провалится один, он не смог выдать другого. Но для выполнения задания им нужно обменяться информацией. Для этого Агент Икс берёт свою рацию и связывается с Центром (сервер Hamachi, AnyDesk, AmmyyAdmin, TeamViewer и т.п., который имеет белый адрес и всегда готов к сеансу связи с любым агентом), передаёт (в зашифрованном виде, конечно), что у него такая-то информация для Агента Игрек. Через некоторое время Агент Игрек берёт свою рацию и связывается с Центром, ему говорят, что для него есть информация от агента Икс, он очень быстро обдумывает новые сведения (шпион должен быстро соображать) и передаёт (в зашифрованном виде, конечно), что у него такой-то ответ для Агента Икс. Через некоторое время Агент Икс берёт свою рацию... и т.д.
Вот так могут общаться через Центр, хотя Центр не может сам с ними связаться и они напрямую не могут друг с другом связаться.
А еще есть другой вариант. Агент Икс говорит Центру: назначаю рандеву Агенту Игрек в понедельник в час дня в цветочном магазине возле Эмпайр Стейт Билдинг; Агент Игрек выходит на связь, Центр передаёт ему место и время встречи и они встречаются напрямую, Центр уже не знает о чём они говорят или какими документами обмениваются. Это называется "пробитие NAT", для этого используются методы TURN или STUN и подобные, при которых Центр нужен только в момент установки связи, а дальше агенты общаются напрямую, пока не разорвут соединение. Как разорвали - им снова потребуется Центр для связи.

Давайте по аналогии. Вы заходите в автобус или в вагон поезда. В этот момент вы - NEW. К вам подходит кондуктор. В автобусе вы покупаете билет, а в поезде предъявляете ранее купленный билет. Кондуктор запоминает ваше лицо и больше к вам не пристаёт, потому что теперь вы - ESTABLISHED. А ещё у вас может быть с собой чемодан - это ваш RELATED.
Когда вы делаете ... --state RELATED,ESTABLISHED,NEW -j ACCEPT -это значит что кондуктор спит или бухает, вошедших NEW зайцев никто не проверяет, они спокойно едут.
Не забывайте, что после срабатывания -j ACCEPT или -j DROP дальнейшие правила в цепочке не применяются, так что не важно, что в следующей строчке вы хотите закрыть доступ по какому-то порту, если вы уже применили -j ACCEPT раньше.

Это называется исходящий порт или порт источника. Он часто не фиксированный, а меняется в широких пределах (от 1025 до 65535).
С какого порта был отправлен запрос, на тот порт и придёт ответ. Это обязательный принцип.

Прежде всего, неадекватный выбор операционной системы для NAS.Потом неадекватно использовать такое железо в роли свитча. Наверняка, в качестве роутера сейчас используется какая-нибудь "мыльница". В то время как можно на этом железе построить шикарнейший роутер + NAS на Linux.
А свитч стоит копейки, и выполняет свои функции лучше, чем программный велосипед, потому что там используется специальный чип, идеально заточенный только под функции свитча.

Режим WISP неуместен для решения задачи, если я эту задачу правильно понял. Тут нужен режим station (он же ещё может называться "wi-fi client", не знаю, есть ли на Кинетике и если есть, то как он там называется). В этом режиме беспроводной и проводной интерфейсы в бридже.

Роутинг между интерфейсами не работает, когда разные интерфейсы принадлежат одной сети. WISP - это роутинг.

По стандарту не может.
Разве что кто-то где-то реализовал сетевой стек не по стандарту.

11111111.11111111.11111000.00000000 в другой нотации записывают /21 (т.е. 21 единичных битов), а 11111011.11110011.11111111.00000000 невозможно так записать

Upd.
RFC 917, RFC 950, RFC 1219, RFC 1878, RFC 4632

что конкретно означает "стучится вниз/вверх"? Ищет службу, которая может обслужить подобный запрос, и связывается с ней через некоторый интерфейс межпроцессного взаимодействия?

Часть имплементации сетевого стека содержится в ядре операционной системы, часть - в драйвере сетевого адаптера, часть - в железе сетевого адаптера. Некоторые протоколы вынесены в службы\демоны (ppp, pptp, openvpn,..). Протоколы 6-го и 7-го уровня реализуются либо в службах, либо в прикладных программах.

Например, браузер. Вот мы ввели qna.habr.com, браузер хочет открыть HTTP соединение. Он формирует набор данных для передачи, затем стучится вниз, на уровень TCP, и говорит: "вот у меня пачка данных, передай их серверу на таком-то адресе".

Браузер сначала на уровне API операционной системы обращается к резолверу (клиенту DNS), резолвер (сперва проверив свой кэш) берёт адрес DNS-сервера из настроек ОС и стучится на порт 53/UDP с запросом, а не "ищет службу". Получает ответ и передаёт его браузеру. Браузер запоминает IP-адрес хоста qna.habr.com и снова через API операционной системы говорит "хочу установить соединение с хостом, адрес такой-то, порт 443/TCP". ОС устанавливает соединение, сообщает об этом браузеру и передаёт какой-то там хэндлер, через который можно использовать уже готовое TCP-соединение. Дальше браузер просто заливает свои данные в соединение, и читает оттуда же ответы. Более высокий уровень - протокол 7-го уровня http - браузер реализует самостоятельно, вот прямо самостоятельно, никого ни о чём не просит, когда дело в http. Более низкие уровни - как уже сказал, на совести ОС, драйвера, железа. Чтобы обеспечить высокую эффективность, там взаимодействие довольно низкоуровневое, такая каша, что не только в рамках ответа, а даже в рамках статьи не описать, целая книга нужна, а то и не одна. Причём для каждой ОС своя отдельная книга, в Linux сетевой стек будет отличаться от сетевого стека Windows, сетевого стека MacOS, сетевого стека BSD.

В пределах локальной сети задача анонса новой комнаты и задача поиска созданных комнат прекрасно решается широковещательными (broadcast) UDP-пакетами с заранее выбранным (фиксированным для вашего приложения) номером UDP-порта.

(насчёт тегов в вопросе: локальный сервер это совсем другое)