AmpliFi решение от компании которая делает пожалуй лучше wifi сети в относительно бюджетном сегменте, лучше них будут уже всякие ruckus.
Именно эта серия специально сделана под ваш сценарий использования.
Из плюсов:
Управляемость ( но это вероятно вам не нужно )
Лучше работа при большом кол-ве клиентов
Вероятно будет чуть меньше задержка и немного выше скорость
Вероятность получить сложно решаемые "глюки" ниже( но в любом случае не нулевая ).
По своему опыту, частот приходят к ampliFi наевшись проблем с остальными вариантами, в то числе с mikrotik ( железо очень хорошее, но wifi не их конек, если не говорить о шинах точка точка ).
Но ключевой момент именно в том, что эти комплекты сделаны изначально под ваш сценарий.
И зачем у вас вообще в данном случае src-nat?
Без очень хитры конструкции вы не сможете сделать правило тип drop all между этими сетями.
Вам нужно dst-nat.
Дальше правило разрешающее трафик между этими сетями по 80 порту.
Дальше правило разрешающее обратный трафик для уже установленных соединений( если необходимо его можно еще сузить по портам, адресу веб сервера и nat признаку ).
После чего drop all. Которое сделает drop для остального трафика.
В общем случае веб сервер вообще лучше вынести в dmz зону отдельно от всех сетей.
Richard Querman, вы уверены, что это те самые пакеты доходят до веб сервиса?
По идее они не должны доходить совсем и должны отбрасываться на роутере с ответом в виде icmp unreachable.
src-nat обрабатывается уже в цепочек out, по идее до этой цепочки пакет вообще добраться на должен.
Diman89, но в 8.8.8.8 у вас записей для данной зоны нет. При обращении клиента к 8.8.8.8 он будет получать ошибку.
Что интересно, браузер и nslookup с днс запросами работает несколько различно, в чем именно различие я не знаю, но не однократно наблюдал картину когда nslookup отрабатывает корректно, а в браузере твориться различная дичь, вплоть до полной неработоспособности резолва днс адресов, особенно когда один из dns серверов не отвечает.
Сказать, что-то более конкретно без схемы сети и конфигов оборудования вряд ли возможно.
Судя по всему интерфейсы падают не все, а вполне конкретные.
Какая железка? Что на других концах этих интерфейсов( может быть одно помещение или одна патч панель, может быть кабели идут в одной косе, а от других в этой косе нет кабелей )?
Попробуйте по очереди интерфейсы по отключать.
Владимир Баранов, собрал стенд и проверил. Между mikrotik и win 10 ( vpn l2tp/ipsec ) ходит ESP трафик по 4500 порту.
Если смотреть packet flow diagram, то в случае инкапсуляции ipsec трафика в l2tp, мы бы работали с ipsec трафиком на l2tp интерфейсе, чего не происходит, ipsec трафик обрабатывает на wan интерфейсе, а из l2tp интерфейса выходит уже исходный трафик.
Но возможно, я действительно, где-то не понимаю как это работает, будут рад если вы дадите ссылки подтверждающие вашу позицию.
Факты по openvpn не пугающие, но зачем? Особенно по TCP( это касается только конфигурации с mikrotik ).
OpenVPN TCP имеет сложно решаемые проблем с VoIP трафиком.
Если mikrotik уже есть, поднимать рядном еще openvpn сервер, это лишние телодвижения, а разворачивать openvpn на mikrotik и возможно иметь хронически проблемы с VoIP, зачем. Еще и на клиентов ставить какой-то софт.
Единственная причина зачем, это можно сделать, маршрутизация, которая через openvpn "пушится", но я не уверен, требует ли она прав локального администратора. В других vpn с mikrotik это проблема, приходится или делать скрипт на клиенте, который требует локального админа, или использовать шлюз по умолчанию в vpn сети, или использовать классовую маршрутизацию. В этом плане конечно удобнее vpn сервера с полноценным dhcp, которые позволяют на клиента отправить маршруты, например почивший TMG.
Владимир Баранов, openvpn отсутствует из коробки в большинстве распространённых клиентских ОС( в отличии от других vpn протоколов ), требует установки и прав администратора, mikrotik в текущем релизе не поддерживает OpenVPN UDP.
Насколько я помню( но вот тут могу с актуальным состоянием заблуждается ), настройки версиозависимы.
Аналогично, раньше opnevpn был на одном ядре и работал в userspace, что вызвало некоторые проблемы с производительностью( актуально состояние не уверен ).
L2TP и ipSec это безусловно разные "технологии", но вы утверждаете:
" а не ipsec, т.к. ipsec уже внутри l2tp", - насколько я помню это не так, сначала формируется l2tp пакет, а потом он уже, при условии реализации ipsec, инкапсулируется в esp.
Т.е. это l2tp внутри ipsec, а не ipsec внутри l2tp, и по публичной сети бежит ipsec трафик, после чего на роутере он уже разворачивается в l2tp.
MaxKozlov, да, судя по всему mikrotik сравнивает email( вероятно, это дефолтное поведение которое можно изменить, но было проще сменить email ). При одинаковых полях email наблюдается именно такое поведение, клиенты друг друга выкидывают с советующей записью в логе.
Это не совсем так. Политики завязаны на ip адреса клиентов, но это не обязательно "внешние" адреса. Mikrotik корректно работает с nat-t. У меня работает схема в которой строится три ipsec туннеля через одни серый адрес( к одному публичному три устройства выходящие в wan через одного из них ). Я сталкивался с этой проблемой в двух конфигурациях, первая чистый IPsec, и там проблема была в id клиента( два сертификата с идентичными полями email ) и именно в ipsec+l2tp и nat. Как в таком случае решать проблему я не подскажу.
Что именно вы хотите сделать?
По динамическим ip обычно подразумевают ip получаемый по dhcp от внешнего источника.
Для этого достаточно поднять dhcp клиент на каждом из указанных портов и исключить их из bridge.
Но судя по комментариям вам нужно что-то другое. В чем именно состоит задача и что вы подразумеваете под динамическим ip?
А оно вам надо? Почтовик внутри организации, это или на коленке, работает хоть как-то и славу богу, или дорого, сложно, кластеры и постоянное обслуживание.
Реально дешевле иметь почтовик по подписке или даже бесплатный на яндексе.
https://www.mikrotik-trainings.com/trainings_files...
Output пакеты не попадают в mangle prerouting.