Ru-Board.club
← Вернуться в раздел «В помощь системному администратору»

» MikroTik RouterOS (часть 3)

Автор: Chupaka
Дата сообщения: 21.11.2010 16:05
vlh
да, если по процу затыка нет - то тут и смысла городить огород в плане нагрузки на него особо не появляется
Автор: bigex2
Дата сообщения: 22.11.2010 08:40
помогите, с чем связано , RB750 , перестало показывать информацию о системе, то есть в health вообще ничего нету :
[admin@router] /system health> print

[admin@router] /system health>

как только купил, показывало, патом почему то перестало, обновил до 4.13 , все равно не показывает
Автор: Chupaka
Дата сообщения: 22.11.2010 10:14
bigex2
пакет routerboard установлен?
Автор: bigex2
Дата сообщения: 22.11.2010 10:27
да, конечно

Автор: dellby
Дата сообщения: 22.11.2010 11:40
Добрый день.
Установлен МК 3.30.
2 сетевых карты: wan/lan, соединение с интернет pppoe.
Внутри сети сервер 192.168.0.100. Из интернет и в сети к нему подключаются по RDP 3389 порт.
Сделал правило как в help /ip firewall nat add chain=dstnat dst-address=69.69.69.69 protocol=tcp dst-port=3389 \
action=dst-nat to-addresses=192.168.1.100 to-ports=3389

теперь порт прокинулся и к серверу стало возможным подключение.
Но у нас есть еще один сервер в другом городе и к нему подключение тоже по rdp по этому же порту. Теперь из сети невозможно подключится по этому порту к компьютеру в интернет.

Подскажите пожалуйста что тут нужно сделать (кроме смены на 2-м удаленном номера порта)?
Автор: Sergey Sosnovsky
Дата сообщения: 22.11.2010 12:11

Цитата:
Внутри сети сервер 192.168.0.100. Из интернет и в сети к нему подключаются по RDP 3389 порт.
Сделал правило как в help /ip firewall nat add chain=dstnat dst-address=69.69.69.69 protocol=tcp dst-port=3389 \
action=dst-nat to-addresses=192.168.1.100 to-ports=3389


Пробрасывать другой порт. И подключаться по нему.
mstsc /v:xxx:9999

/ip firewall nat add chain=dstnat dst-address=69.69.69.69 protocol=tcp dst-port=9999 \
action=dst-nat to-addresses=192.168.1.100 to-ports=3389
Автор: dellby
Дата сообщения: 22.11.2010 12:21
Sergey Sosnovsky
Спасибо, я такой вариант думал. Неудобно - много клиентов перенастроить нужно будет удаленных.
Странно все это kerio стоит и работает (решил его заменить так как конфиг компа под керио слишком слабый выбрал в свое время и комп убитый поставил, да и с базой там косяк возник , вот и решил попробовать микротик).
Автор: Chupaka
Дата сообщения: 22.11.2010 15:13
dellby
я что-то всё ещё не понимаю проблемы... у серверов в разных городах один внешний IP-адрес?..
Автор: bigex2
Дата сообщения: 22.11.2010 15:53
по моему вопросу нет идей? ;(
Автор: dellby
Дата сообщения: 22.11.2010 16:06
Chupaka

упрощенно так (в реале много внешних пользователей сети 1 и внешние к сети2):
1 сервер с mikrotik в одном городе
2 сервер в другом городе (тупо модем порт прокидывает)
использую правило такого вида :
/ip firewall nat add chain=dstnat dst-address=69.69.69.69 protocol=tcp dst-port=3389 \
action=dst-nat to-addresses=192.168.1.100 to-ports=3389

в результате пользователи сети где сервер 2 подключаются к сервер1,
пользователи сети сервер1 не могут подключится к сервер2 по rdp.

Спасибо за помощь
Вопрос снят (ошибся в правилах по неопытности)
Автор: emfs
Дата сообщения: 22.11.2010 16:14
Полный бэкап через Acronis или Clonezilla будет работоспособным на абсолютно другом железе с учётом донастройки сетёвок? Насколько критичен к смене железа?
Версия 3.20.

--
Добавлено:
Chupaka

Цитата:
эммм... DHCP Snooping - это не атака, это защита... что именно надо сделать?


ну да, ошибся, хотел спросить как настроить защиту от атак на сервер DHCP?
имеется в наличии LAN
192.168.1.0/24
192.168.1.1 - MikroTik 3.20
192.168.1.2 - DHCP сервер

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

Или лучше это сделать на коммутаторе?
Автор: vlh
Дата сообщения: 22.11.2010 17:59
Chupaka
спасибо, значит мне пока не грозит оптимизация правил
но скорее всего не избежать настройки PCC...
пока собираю данные...после того как я настрою PCC,
если конечно у меня получится, как мне про маркировать пакеты
для шейпера PCQ? я в данный момент мечу в форварде, выход
для группы на интерфейсе LAN, и вход на интерфейсе PABLIC-1...
теперь PABLIC интерфейсов будет два...что то никак не соображу...
про QoS пока и спрашивать боюсь
Автор: Chupaka
Дата сообщения: 22.11.2010 18:44

Цитата:
в результате пользователи сети где сервер 2 подключаются к сервер1,
пользователи сети сервер1 не могут подключится к сервер2 по rdp

схема всё ещё непонятна, но в целом: местонахождение пользователя не должно влиять на работу, пока он находится на внешнем интерфейсе роутера


Цитата:
Полный бэкап через Acronis или Clonezilla будет работоспособным на абсолютно другом железе с учётом донастройки сетёвок? Насколько критичен к смене железа?

SoftwareID привязывается к серийнику винта. новый винт = новая лицензия


Цитата:
при появлении второго DHCP естественно начинается бардак в сети

и этот бардак лечится только блокированием левых серверов, что делается только на коммутаторе - поскольку трафик между левым сервером и пользователем идёт только через него


Цитата:
как мне про маркировать пакеты
для шейпера PCQ? я в данный момент мечу в форварде, выход
для группы на интерфейсе LAN, и вход на интерфейсе PABLIC-1...
теперь PABLIC интерфейсов будет два...что то никак не соображу...

ну, либо по out-interface=LAN, либо два правила отдельных, по одному на каждый интерфейс =)


Цитата:
про QoS пока и спрашивать боюсь

и правильно - для каждого интерфейса отдельный QoS нужен
Автор: vlh
Дата сообщения: 22.11.2010 19:04

Цитата:
Chupaka
либо два правила отдельных, по одному на каждый интерфейс

то есть было так:

Код: 52 ;;; 3M
chain=forward action=mark-packet new-packet-mark=packet_3m_out passthrough=no
src-address-list=09.Unlimit-3072 in-interface=LAN
53 chain=forward action=mark-packet new-packet-mark=packet_3m_in passthrough=no
dst-address-list=09.Unlimit-3072 in-interface=PABLIC-3
Автор: Chupaka
Дата сообщения: 22.11.2010 19:05
vlh
поскольку используется address-list, я бы из правила 53 просто убрал in-interface =)
Автор: vlh
Дата сообщения: 22.11.2010 19:11

Цитата:
поскольку используется address-list, я бы из правила 53 просто убрал in-interface =)

тогда и из 54 можно тоже убрать?
предыдущее сообщение отредактировал, прокомментируешь...
Автор: Chupaka
Дата сообщения: 22.11.2010 19:13
vlh
я имел в виду первоначальные правила. вместо "а делаем так" - просто убрать
Автор: vlh
Дата сообщения: 22.11.2010 20:08

Цитата:
я имел в виду первоначальные правила. вместо "а делаем так" - просто убрать

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

Код: add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping
Автор: Chupaka
Дата сообщения: 23.11.2010 02:43

Цитата:
какой алгоритм срабатывания балансировки?
то есть как он делит трафик, одного пользователя на один канал другого
на другой или еще как...

всё зависит от реализации балансировки =) если речь о PCC - то всё зависит от, собственно, classifier
Автор: dea_appolo
Дата сообщения: 23.11.2010 21:47
Уважаемые пофессионалы, добрый день.
Chupaka, здравствуйте.

Помогите пожалуйста.

Схема такая:

/ Client1
/ - - DWL2100 - Switch - Client2
Internet - MT750 (192.168.10.0/24) - DWL2100
\ - - DWL2100 - Switch - Client3
\ Client4


Изначально на месте MT750 ничего не было и у клиентов были белые Ипы одного прова.
Теперь с Ипами проблема.
Ставим МТ750. Пров тот же.
Теперь Клиентам 1 и 3 выдается подсеть, а Клиентам 2 и 4 нужно оставить их же внешники но из-под МТ750.
Как пробросить внешники ?
Подсобите плиз.

С уважением, dea_appolo
Автор: faust72rus
Дата сообщения: 24.11.2010 08:33
dea_appolo
Netmap чем-то не устраивает?
Нужны именно белые адреса или нужно исходящий трафик маскировать от определённого адреса, а входящий на этот белый адрес направлять на определённого внутреннего клиента?
Автор: Chupaka
Дата сообщения: 24.11.2010 08:36
dea_appolo
а зачем вообще RB750 поставили?
подсеть выдаётся - белая или серая?
Автор: dea_appolo
Дата сообщения: 24.11.2010 19:28
Здравствуйте,

faust72rus,
Нужно чтобы часть клиентов стала работать в серой подсети, а часть как была так и осталась с обычными белыми адресами (ничего маскировать не надо).

Chupaka
Поставили для регуляции трафика, мониторинга (и в будущем возможно для объединения сетей).
Подсеть теперь выдается серая (и часть клиентов соответственно переводится на серые Ипы), а вот вторая часть клиентов требуют оставить им белые Ипы.
Вот и вопрос - как в МТ750 прописать эти белые Ипы?

С уважением, dea_appolo

Автор: Chupaka
Дата сообщения: 24.11.2010 19:35
dea_appolo
тогда - либо напрямую маршрутизировать на них белые адреса, либо дать им серый адрес и делать src+dst-NAT. можно ещё PPP-сервер поднять - и там давать нужный адрес
Автор: dea_appolo
Дата сообщения: 24.11.2010 19:43
Chupaka

1. напрямую маршрутизировать на них белые адреса
2. дать им серый адрес и делать src+dst-NAT
3. PPP-сервер поднять - и там давать нужный адрес

- а в каком из этих трех вариантое клиент вообще не заметит разницы между тем что было и тем что стало?
- если не сложно, объясните в трех словах принцип каждого варианта, пожалуйста .

С уважением
Автор: Chupaka
Дата сообщения: 24.11.2010 20:37

Цитата:
в каком из этих трех вариантое клиент вообще не заметит разницы между тем что было и тем что стало?

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

1. выдать маленькую подсеть каждому (например, /29) с его адресом, настроить один из адресов на маршрутизаторе в качестве шлюза клиента, остальные адреса клиент вешает себе на компьютер
2. делать /ip fi nat add chain=srcnat src-address=серый action=src-nat to-addresses=белый; /ip fi nat add chain=dstnat dst-address=белый action=dst-nat to-addresses=серый;
3. собсна, как и написано. при подключении VPN (например, PPTP) клиент получает белый адрес и с ним работает. прелесть в том, что, в отличие от 2. не теряются адреса на адрес сети и широковещательный адрес
Автор: dea_appolo
Дата сообщения: 24.11.2010 21:04
Chupaka


правильно ли я понял, что

в п.1. надо раздавать белые Ипы, и создавать назначать соответственно Ип сети, Ип бродкасту, и соответственно минимальное испольщование белых ипов - 6 штук.

в п.2. всё замечательно, и фактически будет приравнеивание серого ипа у клиента к отдельному белому ипу на роутере. и в чем тут могут быть "но" для клиента?

в. 3. всё вообще отлично, но надо каждый раз коннектиться к впн серверу для получения белого ипа? и будет ли роутер точно также управлять траффиком в этом случае (Qos)

?
Автор: AhtonITC
Дата сообщения: 25.11.2010 06:45
Уважаемые гуру микротика! Помогите написать скрипты для микротика пожалуйста. В общем что нужно: на микротике в /ip Firewall Address List в адресном листе itc_users есть IP адреса. Нужно чтобы скрипт брал оттуда адреса, генерил файл, в котором будет содержимое:

!
no access-list 150

с этой строки добавлял адреса, которые есть в адрес-листе

access-list 150 deny tcp 10.222.0.250 0.0.0.0 any
access-list 150 permit tcp any any
!
end

и ложил этот файлик через tftp на сервер, с которого этот файлик будет брать кошка.

И второе: скрипт, который бы через телнет или ссш заходил на адрес, авторизовывался и делать нажатие кливиши Enter.

Буду очень признателен! Заранее спасибо!
Автор: Demon
Дата сообщения: 25.11.2010 09:19
AhtonITC

А не проще ли со заходить чем угодно и откуда угодно на МК по ssh забирать Address List и творить уже с ним чего угодно.
Автор: AhtonITC
Дата сообщения: 25.11.2010 09:39
Не проще... мне просто надо на кошку ложить этот лист - а кошка не умеет по расписанию делать скрипты., вот в чем загвоздка Я почему говорю про микротик и тфтп - у микротика есть клиент тфтп - значит он может ложить файлы на машину, на которой заведен тфтп сервер а оттуда в свою очередь кошка может брать файлы.

Страницы: 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798

Предыдущая тема: Firewall *nix: iptables, ipfw, pf etc...


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.