Werld

Ну вы понаблюдайте, чтоб не выплыли неизвестные побочные эффекты). Этой командой вы включили для пакетов из этой сети при переходе их в ЛЮБОЙ другой интерфейс маскарад на адрес этого интерфейса.

Попробовать ip nat 172.30.30.0 255.255.255.224 - включить глобальный нат для всех пакетов от указаной сети, идущих через маршрутизатор

Не, перезагружать не обязательно, применяется все так. Значит этого не достаточно, надо дальше думать.

Ну так если Vlan222 не сомтрит никуда еще кроме малины, ну поставьте вы на нем смело security-level private. И тогда проброс будет работать и автоматом все трансляции выполнятся.

на Wan порту trunk с vlan222 и vlan888? Есть ли возможность сделать на интерфейс GigabitEthernet0/Vlan222 security-level private? Сдается мне, что после этого проброс заработает корректно.

ip static - Создать правило трансляции локальных IP-адресов в глобальные или наоборот. Если interface или network соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса назначения (DNAT). Если to-address соответствует интерфейсу c уровнем безопасности public, то будет выполняться трансляция адреса источника (SNAT). У вас оба интерфейса public, как я уже написал. Какие в таком случае создаются правила при ip static не понятно. Скорее всего оба и dnat и snat. Я предлагаю не мутить тут проброс, а настроить МСЭ для доступа из одного интерфейса в другой, и обращаться по оригинальному адресу малины.

У вас и PC и RPi находятся, судя по конфигу, за public интерфейсами. Между public интерфейсами связь закрыта. Вам нужно в МСЭ для начала разрешать доступы нужные

Проблема известная. Достаточно обновить прошивку, сбрасывать не обязательно.

Возможно. Не совсем понятно из описания при чем здесь туннель, если вы пишете "на роутере настроены две под сети 192.168.1.1 и 192.168.2.1." Для доступа между сетями на одном роутере - добавляете правила межсетевого экрана. Если все же доступ нужен через туннель из сети одного роутера в сеть другого, то еще и маршруты понадобятся.

Сейчас посмотрел с помощью show netfilter в cli. Не смотря на то что в правилах вида как ваше первое указан входной интерфейс, в реальности под капотом в iptables создается правило без указания входного интерфейса. Правило создается просто с указанием destination ip, который определяется как адрес выбранного входного интерфейса. Т.е. создавая правило вида: ip static udp ISP 59876 192.168.1.33 В реальности создается правило вида: -A _NDM_STATIC_DNAT -d 172.25.25.15/32 -p udp -m udp --dport 59876 -j DNAT --to-destination 192.168.1.33:59876 - 172.25.25.15 это как раз ip адрес на интерфейсе ISP у меня. Почему правило интерпретируется и создается именно так, а не с указанием входного интерфейса типа так: -A PREROUTING -i ens3 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.55.25, это вопрос к разработчикам. Получается что при создании правила берется ip адрес указанного интерфейса, но, видимо, не берется alias. К слову, даже если бы правило создавалось c указанием входного интерфейса, ваше первое правило все равно не работало бы для пакетов внутри сети, т.к. пакет из внутренней сети приходит на роутер не на указанный вами интерфейс FastEthernet0/Vlan2, а на интерфейс Bridg0, к примеру. Так что, конкретно в вашем случае, остается создавать два правила, видимо.

Ну для R1 эти ПК в другой сети. Чтобы он их видел должна быть L2 связность, насколько я понимаю. Смотря что умеет R2, можно сделать из него не маршрутизатор а бридж.

Заглянул сейчас в cli manual, вы правы, наверное в вашей ситуации можно и ip nat использовать. ip nat 192.168.80.0/24 По идее в таком варианте, упомянутая мной проблема вас не коснется.

ip nat про другое. Подробнее в cli manual Вместе с правилом snat будет создано еще и правило dnat. Будет ли оно мешать нужно проверять, я не смотрел из каких цепочек есть прыжок на созданные таким образом правила dnat. Поэтому и предлагаю вам попробовать, команду я написал, если не заработает, команду отмены я тоже написал.

Навеяно проблемой, известной еще с 2017 года: Насколько я могу судить,проблема в том, что ip static пытается реализовать сразу две функции: snat и dnat.. Команда слишком разрослась (достаточно взглянуть на ее описание в cli manual) в попытке быть универсальной, видимо это и привело к упомянутой выше проблеме. Функция трансляции адресов одна из важнейших в работе роутера, наряду с фаерволлом и маршрутизацией, и совсем не понятно, почему этой проблеме с течением времени так и не уделили времени. Как один из вариантов переработки могу предложить ввести две отдельные сущности, например ip snat и ip dnat. В этом случае команды будут не так перегружены функциями. Так как разработчики любят, чтобы приводили реальные ситуации, когда запрашиваемые фичи были бы полезны, вот две темы на форуме из недавних: раз, два.

Можете попробовать на Кинетике в cli выполнить: ip static 192.168.80.0/24 PPPoE0 - это как раз должно сделать то, что вам нужно. Но в реальности имеет место быть: Поэтому, команда для отмены этого: no ip static 192.168.80.0/24 PPPoE0

Что вы подразумеваете под "Натить с кинетика в подсеть 192.168.80.0/24?" Как вы себе это представляете? Может все-таки имеется в виду натить пакеты из 192.168.80.0/24 проходящие через кинетик в сторону pppoe соединения с интернетом, чтобы на ПК в сети 192.168.80.0/24 работал интернет?

Извините, а что вас смущает, работает же? Сделано верно. Более того, имхо в рамках возможностей прошивки, такой способ единственный в данной ситуации.

Security-level какой у впн интерфейса на роутере впн-клиенте? Если public, то нужно разрешающее правило в межсетевом экране. По идее ip global никак не влияет на security-level, хотя возможно его установка выставила интерфейсу уровень public.

На Старте стоит МТ7628 там аппаратно ускоряется не полностью весь ipsec, а только шифрование AES.

Не совсем понял, нет доступа из сети сервера в сеть клиента? И что значит "в таком случае"? Без признака ip global доступ из второй сети есть?

Чтобы клиентов впн-сервера кинетика пускало по маршруту в исходящее с этого роутера впн-соединение, нужно чтобы на этом исходящем впн-интерфейсе был признак ip global (в веб-интерфейсе галочка "Использовать для выхода в интернет") Только убедитесь, что приоритет ip global на этом интерфейсе ниже основного соединения к провайдеру, чтобы через впн не шел весь трафик. У вас аналогично, убедитесь в наличие признака ip global на wg интерфейсе. Есть альтернативный способ, не требующий ip global, т.е. не требующий выставления галочки "Использовать для выхода в интернет". Этот способ заключается в навешивании ACL с разрешающими правилами на исходящий впн-интерфейс на out. Но делается это через cli, поэтому вам проще поставить одну галочку и все.

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

Если убрать правила разрешающие всё для 172.16.203.67 и 172.16.212.115, они продолжают беспроблемно подключаться с запрещающим правилом внизу?

crypto map l2tp-server mtu - Установить значение MTU, которое будет передано L2TP серверу Для Virtual IP VPN-сервера по идее: crypto ipsec mtu