hint000

Давайте по аналогии. Вы заходите в автобус или в вагон поезда. В этот момент вы - 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-порта.

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

и где обычно это все указывается?

В Linux есть справочный файл /etc/services, в котором перечислены порты tcp/udp, по умолчанию назначенные (но не привязанные намертво) различным протоколам прикладного уровня.
В Windows тоже есть аналогичный файл: C:\Windows\System32\drivers\etc\services.

add action=accept chain=forward connection-state=established

поставить в начале цепочки forward

Если меняете маску на 255.255.254.0, то ни о каком WAN на Zyxel 1 не должно идти речи.
Zyxel 1 остаётся в качестве свитча (порт WAN свободный).
DHCP собрать в одном месте
или взять управляемые свитчи, умеющие DHCP snooping, тогда можно оставить два независимых DHCP на двух ZyXEL'ях.

Получается, что существует некий "большой" маршрутизатор, принадлежащий провайдеру, который поддерживает NAT

Для этого даже отдельный термин придумали:
https://www.google.com/search?q=carrier+grade+nat
(в вольном переводе на русский: NAT, здоровенный, как авианосец)

запустите в одном окне sudo tcpdump host 8.8.8.8 и после этого в другом окне traceroute 8.8.8.8,
смотрите, что покажет tcpdump, будут ли там пакеты в сторону 10.128.0.4 (обязаны быть).

Я его пытаюсь включить командой"ip link set usb0 up".

Попробуйте назначить ipv4 вручную:
ip a add 192.168.x.y/24 dev usb0
А вообще я бы его прямо в конфиг netplan и прописал.

на каком-то аппаратном уровне (ниже уровня веб-сервера)

Ниже L3 (третьего уровня в модели OSI) только L2 может увидеть ваш провайдер (да и то не при любом способе подключения), и L2 не спалит вас перед вероятным противником, даже если бы тот видел L2 (к вопросу о бессмысленности затирания MAC-адресов на скриншотах).
Так что нет, ни на каком уровне ниже IP-протокола вы не спалитесь. Но можете спалиться на уровне браузера (вообще типично) или на утечке DNS (реже). Обе эти возможности не ниже уровнем, а выше.