» MikroTik RouterOS (часть 3)

Цитата:

это сейчас о чём было?.. что сломалось?.

Chupaka

Цитата:

Загрузка с локального тфтп в 5.5 точно работает

BigElectricCat

проект wtware.ru тонкий клиент на версиях 4.х нормально грузиться, а после обновления на 5.х по тайм ауту отваливается.

Цитата:

BigElectricCat
Ориентировочная нагрузка 100—600 Мбит

даже страшно предположить, что эти железки смогут такое, в данный момент используется Firewall, QoS, NAT и она (1200) при трафике в 100Мбит\с имеет загрузку CPU 100%, если у вас без этого всего будут только туннели, то возможно и протянет.
imxo, смотрите в сторону само-сборный роутер на базе ПК.

Dimsoft:

Цитата:

проект wtware.ru

ВТВарей не пользуюсь. С того микротика грузится это: хттп://nixts.org/doku.php?id=downloads «Thinstation-2.2-140611-pxe.zip»

Грузится с нандфлеша 493ж микротика долговато (в основном затык когда ожидает файлов конфигурации которых нет), но стабильно. Для 10-ка машинок хватает. Загрузка проца микротика в этот момент поднимается на 10—15% (а поскольку она обычно не превышает 10% то не актуально что-то ещё тулить.)

vlh, да, только впн.

BigElectricCat
Извиняюсь, перезалил картинку на другой хостинг



Код: /ip firewall mangle add chain=prerouting src-address-list=local dst-address-list=!local action=mark-routing new-routing-mark=route_to_proxy in-interface=!ether9
/ip route add dst-address=0.0.0.0/0 gateway=10.1.1.2 routing-mark=route_to_proxy
/ip firewall address-list add address=10.0.0.0/8 list=local
/ip firewall address-list add address=172.16.0.0/12 list=local
/ip firewall address-list add address=192.168.0.0/16 list=local

Цитата:

ВТВарей не пользуюсь. С того микротика грузится

BigElectricCat

сейчас попробовал новую версию и она (5.0.2) нормально загрузилась на mikrotik 5.7

Ребята подскажите скрипт
В определенный интервал открывает доступ к сайту , запрещенному в WebProxy

sumyst, вот последовательность шагов, как бы я делал сеть с твоей схемы:
1. Настроил бы ИП адрес и шлюз в Интренет (условно отмечаю что адрес в Интернет X.X.X.X/30 и есть два ип — твой и шлюз провайдера — х.х.х.х-1)

2. Поднял бы срц-нат для исходящего интерфейса (10-го) для ип с адресным диапазоном 172.24.2.0/30 (т.е в этом сегменте есть действительные адреса 172.24.2.1 и 172.24.2.2) — для того, чтобы никто, окромя прокси и 1200 железки, не выходил в интернет через этот нат.

3. Проверил бы с компа с прокси доступ в интренет:
[more=наш трасроуте на 8.8.8.8]C:\Users\BigElectricCat>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms r1200-я.железка [172.24.2.1]
2 <1 ms <1 ms <1 ms гейт.провайдера [х.х.х.х-1]
…
…… 4 ms 4 ms 4 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.

[/more]

4. Настроил бы простые роутигни для всех сетей: типа для 10.100.103.0/24 искать через 192.168.168.2 (вообще правильно бы использовать что-то более верное для такого случая… ОСПФ к примеру)

5. Для остальных используемых интерфейсов разрешил бы верную маршрутизацию (у меня в базовых парвилах всё лишнее дропается). Естественно надо проверить, чтобы пакеты ихз одной сети в другую ходили так как надо.
______
На этом этапе все кто у себя в ИЕ/Опере (или что там у них) поставят в настройках проксисерверов адрес твоего прокси (172.24.2.2) смогут ходить в инет и без заковыристой маршрутизации на твоей железке.
______


6. Настроил бы маршрутизацию пока только для входящего ин-са ВПН-1:
/ip firewall mangle
chain=prerouting action=mark-routing new-routing-mark=LAN-2-Web passthrough=no src-address-list=LAN dst-address-list=!gray-adress in-interface=VPN-1

(адресные листы LAN — списки локалок, gray-adress — «серые» адреса не маршрутизируемые в интернет — это все допустимые локалки и адреса широковещательной рассылки)

7. Добавил бы маршрут с моей пометкой:
/ip route
add check-gateway=ping comment="" disabled=no distance=50 dst-address=\
0.0.0.0/0 gateway=172.24.2.2 routing-mark=LAN-2-Web scope=30 \
target-scope=10

8. Проверил бы выход в интернет из сети 10.100.103.0/24 (твоя ВПН-1)
[more=наш трасроуте на 8.8.8.8]C:\Users\BigElectricCat>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.100.103.1
2 <1 ms <1 ms <1 ms r1200-я.железка.ВПН-1-шлюз [192.168.168.1]
3 <1 ms <1 ms <1 ms твой.проксик [172.24.2.2]
3 <1 ms <1 ms <1 ms r1200-я.железка [172.24.2.1]
5 <1 ms <1 ms <1 ms гейт.провайдера [х.х.х.(х-1)]
…
… 4 ms 4 ms 4 ms google-public-dns-a.google.com [8.8.8.8]

Trace complete.
[/more]

9. Копированием создал бы под все остальные нужные интерфейсы правила пометки маршрутов из п.6.
(Может так и не столь красиво, но лучше видно)

10. Проверил бы работу правил из остальных сетей.

Добавлено:
rosalin, с 0:9 до 0:9:25 (т.е. на 25 секунд в 9 минут первого) во все дни недели доступ к 80 порту микротика (т.е. http://адрес_микротика):

/ip firewall filter>
chain=input action=accept protocol=tcp dst-port=80 time=9m-9m25s,sun,mon,tue,wed,thu,fri,sat

Цитата:

rosalin, с 0:9 до 0:9:25 (т.е. на 25 секунд в 9 минут первого) во все дни недели доступ к 80 порту микротика (т.е. http://адрес_микротика):

/ip firewall filter>
chain=input action=accept protocol=tcp dst-port=80 time=9m-9m25s,sun,mon,tue,wed,thu,fri,sat

Это не то

rosalin
оо… точно, протупил. замаяли сегодня(((

BigElectricCat
Все дело в том, что я так и делал, начал со сложной схемы с ОСПФ, ВПН итд, думая что все просто.

Оказался затык в правиле мангл.
Теперь я схему упросил до минимума.
В качестве прокси сейчас стоит freebsd со включенным роутингом между интерфейсами.
Сниффером я вижу что пакеты с клиента тестБ до 8.8.8.8 приходят на ЛАН интерфейс и уходят через ВАН интерфейс. Тоесть все правильно.

Все лишние правила фаервола на роутерА я отключал последовательно проверяя где проблема.
Как оказалось проблема в самом первом правиле.
/ip firewall mangle add chain=prerouting src-address-list=local dst-address-list=!local action=mark-routing new-routing-mark=route_to_proxy in-interface=!ether9

Написал в суппорт микротика, наши прибалтийские товарищи попросили таблицу маршрутизации с роутерА и замолчали.

Складывается ощущение что директива in-interface= отрабатывает не верно.
Мне кажется что она маркирует пакет двумя метками route_to_proxy и main

Цитата:

Мне кажется что она маркирует пакет двумя метками route_to_proxy и main

такое, к сожалению или к счастью, невозможно - у пакета может быть одна и только одна мерка маршрута

Chupaka
Знаю, не правильно выразился.
"помещает сразу в 2 таблицы" так наверное правильнее будет.

А вообще есть версии почему такое происходит?

я тут попробовал поднять ваши посты, картинки выдают ХТТП/403, и всё плохо %)

пробовали совсем ручками проследить "тестовый" пакет по всему маршруту? навскидку - любой возвращающийся к пользователю пакет не заворачивается ли обратно на прокси, вне зависимости от того, откуда пришёл?..

з.ы. для src-NAT использовать предварительную маркировку маршрута - шикуете? сделайте out-interface=WAN action=masquerade - и будет вам счастье...

Chupaka
Последний урл работает, вот прямой линк:
http://imglink.ru/pictures/07-11-11/a2245b16b22527498d865540d185dede.jpg

"пробовали совсем ручками проследить "тестовый" пакет по всему маршруту? навскидку - любой возвращающийся к пользователю пакет не заворачивается ли обратно на прокси, вне зависимости от того, откуда пришёл?.. "

Нет не заворачивается, я вместо прокси временно воткнул машинку с фрей и роутингом меж интерфейсами и смотрел тцпдампом.

Да и судя по логу форвардинга самого микротика все проходит как надо.

"з.ы. для src-NAT использовать предварительную маркировку маршрута - шикуете? сделайте out-interface=WAN action=masquerade - и будет вам счастье..."

В таком случае при падении прокси пользователи пойдут через нат и будет не учтенный трафик, а этого не хотелось бы.

Цитата:

оо… точно, протупил. замаяли сегодня(((

разобрался

помогло
скрипт
/ip proxy access disable [/ip proxy access find comment="scheduled based on time"]
/ip proxy access enable [/ip proxy access find comment="scheduled based on time"]

и в шедулер на влючение

sumyst

Цитата:

Нет не заворачивается, я вместо прокси временно воткнул машинку с фрей и роутингом меж интерфейсами и смотрел тцпдампом.

Да и судя по логу форвардинга самого микротика все проходит как надо.

но ведь куда-то же пакет не туда уходит, где-то же теряется...

Chupaka
Пакет уходит куда нужно. Смотрел сниффером на интерфейсах прокси.

Вот откуда берется этот хоп я так и не понял
3 192.168.168.1 1ms 1ms 1ms

(сдается мне происходит следующее: пакет форвардится в соответствии с правилом на прокси, форвардится проксей, попадает на 9й интерфейс и там почему-то попадает сразу в 2 таблицы маршрутизации)
Других объяснения я все равно не придумал.

Кстати, как только включаешь НАТ на проксе, все начинает работать так, как надо.
Но двойной нат не самое красивое решение.

sumyst

Цитата:

Вот откуда берется этот хоп я так и не понял

это адрес роутера - ведь пакет два раза проходит через роутер, до и после прокси


Цитата:

Кстати, как только включаешь НАТ на проксе, все начинает работать так, как надо.

видимо, у вас обратный пакет всё же не маркируется для перебрасывания на ван прокси (чтобы через проксю вернуться), поэтому при натировании пакеты имеют адрес прокси, маршрут на который прописан в таблице main (как connected); а при отключенном на прокси натировании пакеты возвращаются напрямую к пользователю, минуя проксю. дальше - по обстоятельствам (правила фильтра, етц)...

Это адрес транзитной сети до роутерБ каким образом пакет с назначением 8.8.8.8 может 2 раза пройти этот интерфейс?

При трассировке адрес хопа это адрес интерфейс на который пришел пакет и через который он был смаршрутизирован.
Тоесть следующим хопом после ЛАН прокси, должен быть IP микротика в транзитной сети ВАН прокси.
Тоесть 172.24.2.1.

Вот на всякий случай таблица маршрутизации с роутера А


>> 0 A S dst-address=0.0.0.0/0 gateway=10.1.1.2
>> gateway-status=10.1.1.2 reachable ether8 distance=1
>> scope=30
>> target-scope=10 routing-mark=route_to_proxy
>>
>> 1 X S dst-address=0.0.0.0/0 gateway=172.24.2.2
>> gateway-status=172.24.2.2 inactive distance=1 scope=30
>> target-scope=10 routing-mark=From_NAT
>>
>> 2 ADS dst-address=0.0.0.0/0 gateway=10.0.3.1
>> gateway-status=10.0.3.1 reachable ether10 distance=0
>> scope=30
>> target-scope=10 vrf-interface=ether10
>>
>> 3 ADC dst-address=10.0.3.0/24 pref-src=10.0.3.107
>> gateway=ether10 (Это линк до Провайдера.)
>> gateway-status=ether10 reachable distance=0 scope=10
>>
>> 4 ADC dst-address=10.1.1.0/24 pref-src=10.1.1.1 gateway=ether8
>> gateway-status=ether8 reachable distance=0 scope=10
>>
>> 5 A S dst-address=10.100.103.0/24 gateway=192.168.168
>> gateway-status=192.168.168.2 reachable ether6 d
>> target-scope=10
>>
>> 6 ADC dst-address=172.24.2.0/24 pref-src=172.24.2.1 g
>> gateway-status=ether9 reachable distance=0 scop
>>
>> 7 ADC dst-address=192.168.168.0/24 pref-src=192.168.1
>> gateway-status=ether6 reachable distance=0 scop

Обратите внимание, никаким образом таблица маршрутизации не ведет пакет 8.8.8.8 обратно к роутеруБ

"видимо, у вас обратный пакет всё же не маркируется для перебрасывания на ван прокси (чтобы через проксю вернуться), поэтому при натировании пакеты имеют адрес прокси, маршрут на который прописан в таблице main (как connected); а при отключенном на прокси натировании пакеты возвращаются напрямую к пользователю, минуя проксю. дальше - по обстоятельствам (правила фильтра, етц)..."

А вот это уже более похоже на правду, НО и в таком случае трассировка должна проходить.
Логика такая:
1) клиент с src 10.100.103.254 отправил пакет на dst 8.8.8.8
2) пакет отправляется на гейт клиента 10.100.103.1 (роутерБ)
3) гейт клиента в соответствии с дефолтным маршрутом отправляет пакет на 192.168.168.1 (роутерА)
4) роутерА в промаркировав пакет форвардит его на IP прокси 172.24.1.2
5) прокси роутит пакет меж интерфейсами и отправляет на свой дефолт 172.24.2.1
6) Пакет на ether9 маркируется, отправляется на НАТ и затем во вне.
7) Обратный пакет пройдя нат с src 8.8.8.8 и dst 10.100.103.254 раутится обратно.

Даже в таком случае все должно работать если обратный пакет ушел минуя прокси.
И опять же совершенно непонятно откуда взялся второй хоп 192.168.168.1

Цитата:

Это адрес транзитной сети до роутерБ каким образом пакет с назначением 8.8.8.8 может 2 раза пройти этот интерфейс?

в этом плане всё предельно просто: маршрутизатор получает пакет с TTL=1, уменьшает, получает ноль, отбрасывает. дальше посылает ICMP-сообщение об этом. в качестве src-address выбирается pref-src конечного маршрута для dst-address


Цитата:

Логика такая:

вот я про седьмой пункт и говорю... первые шесть - да, всё вроде правильно

Chupaka
Дык про то и речь, дважды на пути пакета до 8.8.8.8 адрес 192.168.168.1 ну никак не может встретится.
С учетом того что при трассировке каждый раз ттл увеличивается на 1.

"вот я про седьмой пункт и говорю... первые шесть - да, всё вроде правильно"

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

sumyst

Цитата:

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

ну, правил фильтра файрвола я не видел, а об их отсутствии никто не упоминал


Цитата:

Дык про то и речь, дважды на пути пакета до 8.8.8.8 адрес 192.168.168.1 ну никак не может встретится.

что вы называете словом "встретиться"? роутер два раза отправляет клиенту пакет "TTL Exceeded", два раза на один и тот же адрес - адрес клиента. почему он первый раз должен выбрать один адрес, второй - другой?.. ведь в маршруте на клиента pref-src не меняется

Chupaka
правил кроме ната и мангла нет

"что вы называете словом "встретиться"? роутер два раза отправляет клиенту пакет "TTL Exceeded", два раза на один и тот же адрес - адрес клиента. почему он первый раз должен выбрать один адрес, второй - другой?.. ведь в маршруте на клиента pref-src не меняется"

Коллега, может мы друг друга недопонимаем?

Рисую схему:

Клиент 10.100.103.254 отправляет трассировку до 8.8.8.8
1) первый пакет с ттл = 1 прилетает на 10.100.103.1 (роутерБ) который отвечает ICMP Time Exceeded
2) второй пакет с ттл = 2 прилетает на 192.168.168.1 (роутерА) который отвечает ICMP Time Exceeded
3) пакет с ттл = 3 форвардится на 172.24.1.2 (лан прокси) который отвечает ICMP Time Exceeded
4) пакет с ттл = 4.... и куда (и как) он должен прилететь чтоб ICMP Time Exceeded ответил 192.168.168.1
? ( и это с учетом того, что этот пакет я вижу сниффером исходящим с ВАН интерфейса прокси сервера)

Вот у меня в голове не сростается никак. Может я заработался, но механизм данного действа я понять не могу.

Спасибо за ответы кстати.

И кстати, TTL Exceeded всетаки отправляется не с pref-src, а с интерфейса на который пришел пакет. Так во всяком случае должно быть.

Цитата:

4) пакет с ттл = 4.... и куда (и как) он должен прилететь чтоб ICMP Time Exceeded ответил 192.168.168.1

он должен прилететь на роутер, через ether9, если не ошибаюсь. у роутера в сторону юзера смотрит всё ещё 192.168.168.1 - поэтому он с этого адреса и отвечает


Цитата:

TTL Exceeded всетаки отправляется не с pref-src, а с интерфейса на который пришел пакет. Так во всяком случае должно быть

когда говорите "должно" - подкрепляйте слова ссылками на RFC =) здесь мы видим так, как оно есть. и именно так оно работает

"когда говорите "должно" - подкрепляйте слова ссылками на RFC =) здесь мы видим так, как оно есть. и именно так оно работает"

Ну так это Вы начали утверждать что роутер для ответа выберет preferred source.

На деле современные маршрутизаторы сейчас далеко не всегда соблюдают rfc 1812 (и микротик кстати тоже), и это правильно я считаю. Позволяет строить более точную карту маршрута.

А вообще мы уклонились от темы. Почему тогда сам прокси, IP ВАН интерфейса которого тоже находится в листе local вполне нормально натится, а транзитные пакеты - нет?

Уточнил проблему.
Удалось поставить в разрыв между провайдером и роутеромА сниффер.

Оказывается что пакеты из локальных сетей уходят "неотначенные"

Правила такие:

chain=prerouting action=mark-routing new-routing-mark=To_NAT src-address-list=local dst-address-list=!local passthrough=yes in-interface=ether9

chain=srcnat action=masquerade routing-mark=To_NAT src-address-list=local dst-address-list=!local out-interface=ether10

Вроде все просто и правильно. Ан нет.
Что может быть не так?

PS пожалуйста обратите внимание на маленький ньюанс.
В такой конфигурации пакеты инициированные самим прокси сервером натятся без проблем.
Не натятся ТОЛЬКО транзитные пакеты.

Спасибо.

Объясните может быть, чтобы из кэша прокси качалось медленнее чем из интернета.

Поднят прокси указан cache-on-disk: yes.
Качал файл Оперой - 50 мегабайт. Скорость что-то около 500к (наверное 4 мегабита канал).
Второй раз этот же файл (специально посмотрел лежит в кэше, канал не использует) -- скорость около 400к.
Винт 80Gb старенький.

Вообще такое возможно, или что-то в шейпере?

sumyst

Цитата:

passthrough=yes

попробуйте на no сменить или вообще натировать всё, что идёт на ether10. а касательно необходимости неработоспособности конфига без прокси - так в фильтре заблокируйте прямые пакеты из юзера в ether10

Chupaka
Пробовал, менял.

ether10 это WAN порт до провайдера. Не совсем понятно что значит " натировать всё, что идёт на ether10."
У меня сейчас такое правило
chain=srcnat action=masquerade routing-mark=To_NAT src-address-list=local dst-address-list=!local out-interface=ether10

Пробовал без routing-mark=To_NAT. Ситуация не моенялась.

sumyst
chain=srcnat out-interface=ether10 action=masquerade