ID
добрый вечер
коллеги, а поддержка EAP для IKEv2 сервера в RouterOS 7 бете еще не появилась?
коллеги, а поддержка EAP для IKEv2 сервера в RouterOS 7 бете еще не появилась?
Size: a a a
2020 June 14
VP
Куча лишнего. НАТ dst и src нужен только на первом микротике. На втором только фильтр фаерволла.
a
Про стриминг пакетов микротиковского снифера на вайршарк: в общем в вике микротика рассказали только часть правды, если использовать фильтр "udp port 37008" в вайршарке, то под него не попадает второй фрагмент полноразмерных пакетов (после добавления tzsp заголовка перестающих пролазить в MTU) и вайршарк не может их реассемблить.
Вместо этого, нужно использовать фильтр
udp dst port 37008 or ip[6:2] & 0x1fff != 0
он включает все UDP пришедшие на порт 37008 и все фрагменты. После этого вайршарк нормально все реассемблит. Далее уже в display фильтре вайршарка просто фильтрануть все по tzsp.
В файл это можно вот так писать:
tshark.exe -i интерфейс -n -p "-f udp dst port 37008 or ip[6:2] & 0x1fff != 0" -w cap-01.pcap
Если у вас по сети фрагменты летают, то не относящиеся к делу можно потом дочистить так:
tshark.exe -r cap-01.pcap -n -w cap-02.pcap -o ip.defragment:TRUE -2 -Y tzsp
В результате получаем pcap состоящий только из tzsp пакетов с микротика, но там они будут с фрагментами, но вайршарк их нормально зареассемблит.
Как это дело декапсулировать в нефрагментированные исходные пакеты (т.е. получить полный аналог pcap, как бы его микротик на локал у себя писал, без оборачивания в tzsp) - пока не придумал.
Вместо этого, нужно использовать фильтр
udp dst port 37008 or ip[6:2] & 0x1fff != 0
он включает все UDP пришедшие на порт 37008 и все фрагменты. После этого вайршарк нормально все реассемблит. Далее уже в display фильтре вайршарка просто фильтрануть все по tzsp.
В файл это можно вот так писать:
tshark.exe -i интерфейс -n -p "-f udp dst port 37008 or ip[6:2] & 0x1fff != 0" -w cap-01.pcap
Если у вас по сети фрагменты летают, то не относящиеся к делу можно потом дочистить так:
tshark.exe -r cap-01.pcap -n -w cap-02.pcap -o ip.defragment:TRUE -2 -Y tzsp
В результате получаем pcap состоящий только из tzsp пакетов с микротика, но там они будут с фрагментами, но вайршарк их нормально зареассемблит.
Как это дело декапсулировать в нефрагментированные исходные пакеты (т.е. получить полный аналог pcap, как бы его микротик на локал у себя писал, без оборачивания в tzsp) - пока не придумал.
ага. ясно понятно. буду знать, авось пригодится.
a
ты прям очень сильно заморочился этим делом
VP
Переслано от Grigoriy
я сделал 2 проброса, первый из chr на ip который присвоен туннелю между микротом и chr, и второй на микроте с этого туннеля на ип в локалке.
Нужен один проброс. dst-nat на СНR сразу на адрес нужного хоста. И src-nat на СHR к адресу интерфейса туннеля в сторону второго миротика.
С
и наличие работающей маршрутизации между двумя локалками )
G
и наличие работающей маршрутизации между двумя локалками )
а если мне маршрутизация не нужна?
С
тогда надо больше ната чем пишет дядя Володя или дропайте фаерволом все то что не нужно
K
Подскажите плиз, по опыту, сколько памяти займут 20'000 маршрутов? Хочу в map загнать базу антифильтра, вот думаю, вытянет или нет, в нем всего 64
G
и наличие работающей маршрутизации между двумя локалками )
тогда буду пробовать по той статье что вы дали :)
VP
а если мне маршрутизация не нужна?
А она и не нужна. Нужно только на СНR роут до нужного хоста. Обратный не нужен.
С
попробуйте оба варианта
MO
K
Подскажите плиз, по опыту, сколько памяти займут 20'000 маршрутов? Хочу в map загнать базу антифильтра, вот думаю, вытянет или нет, в нем всего 64
Мало, ас лайт влезало и казалось что всего пару мегабайт
G
хм этого оказалось достаточно. но при условии 2 пробросов. на chr и микроте. но меня это устраивает впринципе.
G
А она и не нужна. Нужно только на СНR роут до нужного хоста. Обратный не нужен.
если прописать на chr роут до нужного хоста то второй проброс не понадобиться?
G
если прописать на chr роут до нужного хоста то второй проброс не понадобиться?
это что то мне непозволяют мои познания реализовать :(.
G
хм этого оказалось достаточно. но при условии 2 пробросов. на chr и микроте. но меня это устраивает впринципе.
А этот вариант нормальный или у него есть какие-то минусы ?
G
попробуйте оба варианта
из статьи которую Вы дали. на клиентском микроте add action=src-nat chain=srcnat dst-address=<адрес получателя> dst-port=<порт получателя> protocol=<tcp|udp> to-addresses=<адрес МТ, шлюз сети 192.168.2.0>. у меня работает без этого. и вопрос не понимаю для чего оно? шлюз то и так дефолтный указан? или это для того случая когда нет маскарада?
С
в статье 2 дст ната, 1ый дст нат на микрот2 , 2ой на хост. и соответсвенно 2 сорс ната, дядя Володя предложил дст натить сразу на хост, если между локалками есть связность то достаточно одного дст ната и одного сурс ната на микроте1 чтобы ответ от хоста возвращался обратно
G
в статье 2 дст ната, 1ый дст нат на микрот2 , 2ой на хост. и соответсвенно 2 сорс ната, дядя Володя предложил дст натить сразу на хост, если между локалками есть связность то достаточно одного дст ната и одного сурс ната на микроте1 чтобы ответ от хоста возвращался обратно
я сделал по статье - 2 дст, и сорс на chr. сорт на клиенте не делал. у меня получается это делает маскарад на дефолтный шлюз. возможно я не прав, но работает без 2го сорса