+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Изменение исходного IP-адреса для пакетов ICMP типа 11.

Изменение исходного IP-адреса для пакетов ICMP типа 11., RouterOS

zimage

Guest

13.10.2013 02:27:00

Чтобы сэкономить пространство адресов IP (поскольку в routeros нет поддержки /31 сетей), я подумал, что могу использовать адреса 10.x.x.x на своих точка-точка соединениях и использовать src-nat, чтобы трассировки выглядели так, будто они приходят с адреса loopback моего роутера. Запуская routeros 6.5rc1, я не смог заставить это работать, поэтому удалил все свои правила и просто создал правила логирования. /ip firewall filter
add action=log chain=output icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=filter protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=filter protocol=icmp
/ip firewall mangle
add action=log chain=postrouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=output icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=forward icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=prerouting icmp-options=11 log-prefix=mangle protocol=icmp
add action=log chain=input icmp-options=11 log-prefix=mangle protocol=icmp
/ip firewall nat
add action=log chain=srcnat icmp-options=11 log-prefix=nat protocol=icmp
add action=log chain=dstnat icmp-options=11 log-prefix=nat protocol=icmp Вот лог после трассировки через роутер. echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info filter output: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80
echo: firewall,info mangle postrouting: in:(none) out:ether1, proto ICMP (type 11, code 0), 172.16.19.1->172.16.19.18, len 80 Похоже, что пакет никогда не проходит через цепочку srcnat, хотя диаграмма потоков пакетов показывает, что src-nat происходит после mangle postrouting. Есть ли способ это сделать? Спасибо, Тим Новацк.

zimage Guest	#2 0 04.12.2013 05:07:00 Есть какие-нибудь новости по этому поводу?

zimage

Guest

27.02.2014 15:15:00

Я снова попытался с ROS 6.9 и получил то же самое. /ip firewall filter добавьте action=log chain=output icmp-options=11 log-prefix=filter protocol=icmp добавьте action=log chain=input icmp-options=11 log-prefix=filter protocol=icmp добавьте action=log chain=forward icmp-options=11 log-prefix=filter protocol=icmp /ip firewall mangle добавьте action=log chain=postrouting icmp-options=11 log-prefix=mangle protocol=icmp добавьте action=log chain=output icmp-options=11 log-prefix=mangle protocol=icmp добавьте action=log chain=forward icmp-options=11 log-prefix=mangle protocol=icmp добавьте action=log chain=prerouting icmp-options=11 log-prefix=mangle protocol=icmp добавьте action=log chain=input icmp-options=11 log-prefix=mangle protocol=icmp /ip firewall nat добавьте action=log chain=srcnat icmp-options=11 log-prefix=nat protocol=icmp добавьте action=log chain=dstnat icmp-options=11 log-prefix=nat protocol=icmp echo: firewall,info mangle output: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56 echo: firewall,info filter output: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56 echo: firewall,info mangle postrouting: in:(none) out:ether4, proto ICMP (type 11, code 0), 10.1.0.61->97.87.17.16, len 56

awball

Guest

12.03.2014 01:41:00

У меня тоже такая проблема. Использую адресное пространство RFC 1918 в качестве соединений на MPLS-сети. Эта проблема возникла в лабораторной сети, где около 9 RB750GL, а также в рабочей сети на CCR, которые все смело (и стабильно) работают на 6.10 сейчас.

awball

Guest

13.03.2014 15:41:00

Я получил это от поддержки MT: NAT работает только с пакетами connection-state=new, так что в случае ICMP это пакет запроса, а не ответ, который имеет connection-state=established. Это похоже на linux iptables. Это имеет смысл, учитывая, что я мог бы настроить трансляцию NAT, чтобы соответствовать ICMP из внешнего пространства RFC1918 по мере их поступления, вместо того чтобы натить на выходящих ответах. Настрою это в лаборатории и отпишусь здесь, как все пройдет, вероятно, на следующей неделе.

zimage Guest	#6 0 09.07.2014 18:04:00 Настрою это в лаборатории и сообщу здесь, как всё пройдет, возможно, на следующей неделе. Есть какие-то успехи или новости?

changeip Guest	#7 0 11.07.2014 20:05:00 Мне это тоже очень интересно. Я выбрал другой вариант, который вроде как работает — разве нельзя просто изменить предпочтительный адрес источника в таблице маршрутизации на адрес обратной петли, и тогда он будет отвечать с этим? Кажется, у меня это где-то на сети работает...

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры