Ну, это уже проще (для понимания). "Постоянный IP" будет на проводном интерфейсе АР, поэтому проброс портов делать на АР (т.к. она в этой схеме роутер) -- см. прекрасные сообщения этой же темы (например, №3, №11).
Если клиенты этой АР тоже роутеры, то просто цепочку "пробросов" организовываем до нужного оконечного узла (IP-камера, сервер видеонаблюдения...): в CL "принимаем" перенаправленный с АР пакет на определённый порт и передаём (пробрасываем) далее на узел, расположенный позади CL (на IP-адрес и порт этого узла).
Вообще, это азы IP-маршрутизации и работы NAT'а и слабо связано с тематикой раздела. Если совсем уже на пальцах показывать, то:
Например, у нас есть RDP-сервер (терминальный сервер) в небольшой локальной сети, которая подключена к И-нету через свой роутер (например, тот же Keenetic), который в свою очередь подключён к радиооборудованию, которое по странному стечению обстоятельств работает в режиме не моста, а как два роутера. Т.е. так: (провайдер) -> (AP router) -> (CL router) -> (Keenetic router) -> ЛВС (проводная и/или WiFi). Да, вот такой чудесный изврат.
Внешний "белый" IP-адрес будет получать проводной (ethernet) порт AP (неважно по DHCP или мы там его статически пропишем). Беспроводная сеть между АР и CL (клиентов 1 или больше) будет с "серыми" IP-адресам, ну пусть с теми же из сети 192.168.77.0/24 , а именно: AP -- 192.168.77.1 , СL -- 192.168.77.2 (шлюз по-умолчанию для CL в таком случае должен быть записан как 192.168.77.1)
RDP работает по порту TCP 3389, но мы не хотим, чтобы снаружи этот порт откликался (много будет ботов, сканирущих И-нет по "известным" портам, туда ломиться). Откроем тогда порт 33890, например.
В АР в пробросе портов запишем public port: 33890 , private IP: 192.168.77.2 , private port: 3389 , тип: TCP -- это для проброса на RDP
Заодно сделаем и проброс на web-интерфейс CL: c внешнего 4432 на 192.168.77.2 ТСР-порт 443 (и если будет ещё CL2 и больше, то просто допишем проброс с внешнего 4433 на 192.168.77.3 порт 443 и т.д.)
На CL "внешним" будет адрес 192.168.77.2. Этот адрес будет на беспроводном интерфейсе. На проводном же у CL своя "серая" сетка -- между ним и Keenetic'ом. Например, пусть будет 192.168.88.0/24 и тогда CL пусть будет с адресом 192.168.88.1 , а keenetic (его WAN-порт) с адресом 192.168.88.2. Шлюзом по-умолчанию для keenetic'а будет в таком случае 192.168.88.1
На CL пробрасываем приходящие на него "снаружи" (т.е. от АР) на порт 3389 пакета внутрь на адрес 192.168.88.2 на TCP-порт 3389.
В keenetic'е делаем "окончательный" проброс порта 3389 на IP-адрес во внутренней сети keenetic'а (обычно что-то типа 192.168.1.0/24). Например, пусть термсервер крутится на компьютере (сервере)с адресом 192.168.1.10 -- вот туда и направляем через LAN-интерфейс (через lan-bridge или как там в терминологии keenetic'а). На терм.сервере, естественно, шлюз по-умолчанию это IP-адрес keenetic'а -- 192.168.1.1
Чтобы подключиться к такому терм.серверу мы, находясь где-то далеко и "снаружи", запускаем программу "клиент сервера терминалов", в строке адреса (подключения) пишем: внешнийIP:33890 , подключаемся, работаем.
Для того, чтобы попасть на web-интерфейс CL запусаем браузер и в строке адреса пишем https://внешнийIP:4432'>https://внешнийIP:4432 (ну, а у AP останется https://внешнийIP:443 , если в настройках самой АР не поменять/сдвинуть номер HTTPS-порта).
Доступ на остальные сервисы (настройка "проброса") -- по аналогии.
Но "рецепт" не универсальный: некоторые вещи могут не заработать или работать странно/нестабильно -- например, IP-телефония, FTP. Из-за особенностей реализации и/или фундаментальных ограничений.
