Russian Users MikroTik | Форум пользователей MikroTik

Доброе время суток, знатоки!
Недавно пришел на новое место работы, где сеть построена на микротиках. Ранее с ними(к сожалению) не сталкивался. Суть проблемы:
Имеем mikrotik rb951g(внутренний ip пусть будет 10.11.0.1) и rb2011uias(внутренний ip пусть будет 10.11.30.1). Через терминалы(winbox) они друг друга пингуют без проблем. Но если отправлять пинг с пк относящемуся к первому микротику на второй - пинга нет. Хотя с любого пк относящегося ко второму микротику пинг идет и до оборудования и до любого рабочего пк. Подскажите как сделать, что бы можно было ходить из одной сети в другую без проблем?
Заранее благодарен за отзывы!

Пробовали к администратору вашей сети обратиться?

Я за него)))) Тот что настраивал свалил и телефон не абонент

В IP/Routes на обоих микротиках есть пути в сети за ними?
У ПК дефол гейтвей кто?

Простой казалось бы вопрос, но нигде не могу найти ответ.
Допустим поднят туннель между двумя микротиками, пусть будет PPTP.

Сервер на белом IP.
Клиент на сером IP через модем сотового опереатора.

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

Единственно, что удалось нарыть команда keepalive timeout .
Суть вроде в следующем - после того как пакеты по туннелю перестанут ходить, MikroTik будет слать keepalive пакеты в туннель и если в течении указанных секунд не будет подтверждения, туннель будет считаться мёртвым, а дальше что?

Fedot1967 писал(а): ↑22 июл 2018, 06:54 Суть вроде в следующем - после того как пакеты по туннелю перестанут ходить, MikroTik будет слать keepalive пакеты в туннель и если в течении указанных секунд не будет подтверждения, туннель будет считаться мёртвым, а дальше что?

Я не совсем понимаю, что Вы хотите понять.

РРТР это сеансовый протокол, клиент "звонит" на сервер, поздоровались, авторизовались и работают.

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

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

Также, на сервере лучше такое подключение (рртр или л2тп или sstp) за-биндить, и уже к этому биндингу делать
привязки, маршруты и так далее, в этом случаи, даже когда сессия пере-подключится, сервер будет знать,
что это всё тот же клиент, и маршрутизация будет работать снова исправно в рамках этого клиента.

Собственно, главное, что я хочу понять, сколько раз клиент автоматически будет пытаться поднять сессию.
Не получится, к примеру так, что после 10 попыток канал ляжет намертво

Fedot1967 писал(а): ↑22 июл 2018, 17:27 Собственно, главное, что я хочу понять, сколько раз клиент автоматически будет пытаться поднять сессию.
Не получится, к примеру так, что после 10 попыток канал ляжет намертво

1) Такова не замечал.
2) Видимо Вы работали с другим каким-то оборудованием, в микротике всё более однозначно/прозрачно.
3) Сделайте тестовый рртр профиль, забейте фейковые данные и смотрите сколько будет попыток делать роутер!?

Fedot1967 писал(а): ↑22 июл 2018, 17:27 Не получится, к примеру так, что после 10 попыток канал ляжет намертво

Не должен, у меня в своё время провайдер давал подключение через pptp, так при обрыве роутер пытался подключиться сколь угодно долго. И не ложился ни разу...

Vlad-2 писал(а): ↑22 июл 2018, 13:07
если прохождение контрольных пакетов перестало, клиент считает сессию как утраченную и пытается заново её поднять.
В этом случаи (я даже видел), как на сервере ещё живёт "старая" сессия, но уже ломиться клиент с новой сессией,
и если в настройках сервера указана опция, "позволять создавать лишь одно подключение", то при таких моментах,
туннель не сразу заработает (сервер будет ждать когда по таймауту отвалиться у него старая сессия и пустит снова клиента).

Моя практика с микротиком показывает следующее.
Если эта галочка не стоит, то устанавливается еще одно (второе) соединение, со своим уникальным названием, другим IP адресом, и если даже первое (потерявшее работоспособность) было "сервер биндингом" для конкретного клиента, то все настройки, сделанные для этого интерфейса перестают работать, потому, что новое соединение - новый интерфейс.

А установка этой галочки наоборот, никак не мешает устанавливать соединение. Только при этом старое принудительно прекращается, а устанавливается новое, без задержек, с тем же именем.

Игрался даже, с разных устройств (телефона и бука) под одним логином ломился конкурентно. Подключалось всегда без проблем, отключая работающего до того.