Mikrotik интернет пользователей через vpn туннель?
Коллеги подскажите советом по правильной маршрутизации, стоит mikrotik ac2, 7.8 версия ОС.
поднят l2tp\ipsec туннель до vps сервера (когда у роутера появиться белый ip он будет заменен на GRE туннель с IPSec)
до этого нужно было, чтобы только 5-6 машин смотрели в интернет через этот vps сервер, поэтому я настроил им доступ по следующей схеме
/ip route rule
add action=lookup src-address=192.168.0.121/32 table=l2tp-vps
/ip route
add gateway=192.168.42.1 routing-mark=l2tp-vps
/ip firewall
nat add chain=srcnat action=masquerade out-interface=l2tp-vpn
в данном решение, к сожалению, нельзя указать диапазон IP-адресов или AdressList, поэтому для каждого клиента прописал route rule, пока их было 5-6 было пофиг. Но сейчас начальство дало указание, что завернуть внутрь туннеля нужно еще 20 сотрудников, а в последствие вообще всех 50-60, создавать 50-60 route rules явно будет не правильно.
нашел один из вариантов через mangle
chain=prerouting
src-adress-list=UsersToVps
action=mark routing
route mark=vps-internet
IP-routes
0.0.0.0/0
gateway=192.168.42.1
routing-table=vps-internet
ну и маскарадинг Adress-list на интерфейс этого туннеля l2tp
но при такой настройке в итоге то интернет работает, НО скорость просто адская, лишь только результат поиска яндекса может открываться 30-60 секунд.
Отсюда возник вопрос, подскажите как правильнее всего завернуть AdressList ходить в интернет через туннель до vps?
Нужен вариант самый менее напряжый для железки.
Если новая схема с Mangle в целом правильная, то что я упустил в настройках. Из-за чего она так медленно работает?
Схема то нормальная. Возможно железка напрягается из-за Address List. Попробуй в правиле Mangle убрать это поле, а в поле src-adress просто указать нужный диапазон адресов.
Valentin Barbolin, хотел чуть позже глянуть его тоже, но по старой схеме все летает а тут через mangle и address list тормозит. Причем tracert показывает нормальное время отклика на всех шагах, а в браузере все висит как будто захлёбывается с временем отклика в секундах или десятках секунд... И вот хз куда смотреть
AlexVWill, по процу вообще нагрузки нет, по идее не должна напрягаться, попробовал без address list, тоже самое.
tracert по времени отклика выдает отличные значения на каждом шаге, а в браузере висяк загрузки адский. Причем подгрузка идёт долгими шагами страница сама потом через 5-10 секунд одна часть баннеров, потом через 5-10 секунд часть картинок, как будто он спотыкается на откликах всех запросов
А зачем тут gre? Насколько я знаю, gre используется pptp для передачи собственно туннеля :) Почему не ipsec и шван на втором конце (ведь там же линух?)
Нужно заруливать весь трафик с определенных машин или же только некоторый (веб, например)?
CityCat4, задача в том, чтоб выжать максимум скорости, когда будет белый IP от провайдера дадут 300 мбит, и соответственно нужно что бы туннель от микрота до впс мог прокачать максимум из него, так как практически все люди уйдут в этот туннель.
Какой именно туннель поднимать вообще не принципиально, нужно что бы он был шифрован, и без перегруза роутера качал предоставленные 200-300 мбит. GRE предполагается просто потому что, начальству кто то сказал что gre туннель c ipsec шифрованием поверх (да, там будет линукс и шван) будет самым быстрым, но само собой перед введением мне придется тестировать все решения и выбрать (сам пока хз, пока новичок именно в этом вопросе)
Valentin Barbolin, AlexVWill, коллеги спасибо за наводящие советы, после них с чтением мануалов был найден виновник. правило fasttrack connection которое шло с самого начала, которое не мешало старой схеме роутинга, но мешает через мангл, как только его вырубил сразу интернет через туннель стал работать нормально
trovix, Как же в итоге решил? Выключил fasttrack ? Просто fasttrack существенно снижает нагрузку на CPU.
Может лучше попробовать написать для него отдельное правило?
Valentin Barbolin, да, пока нагрузка небольшая будет, его просто отключил. Так как нужно было быстрее пустить пользователей через ВПН, вопрос стоял остро им. И буду наблюдать за нагрузкой железки.
Но да, буду изучать тему фасттрека, можно ли как то его настроить более тонко, спасибо за ссылку, почитаю
trovix, ни 50, ни 30, ни даже десяток юзеров с шифрованием железка не потащит. hAP AC2 - относительно недорогая соховская точка доступа плюс роутер 4 уровня лицензии. rb750 например уже на одном шифрованном туннеле иногда под 100% загрузки показывает. В соховском железе все шифрование на проце.
Для 30-50 юзеров нужно брать железку с аппаратным шифрованием типа rb4011 а то и CCR (вот сейчас у меня на CCR1016 сидит два устройства в других городах и два человека на выезде, всего четыре шифрованных туннеля, а загрузка 2%)
CityCat4, хм, а я заявлено до 300-400, в ipsec.... А какой тунель тогда на ac2 можно поднять менее затратный на ближайшее время?
Пока вряд ли одобрят быстро замену железки, если на 20-30 пользунах начнет захлёбываться тогда только смогу поставить перед фактом что нужно чтоб нибудь более основательное, и то хз в какие сроки (P.s. на другом этаже 40 пользунов вообще сидят у них на ТП Линке домашнего уровня... Хорошо хоть тунель не просят там поднять )
trovix, Честно говоря не знаю. ac2 - соховская точка, она не рассчитана на такое количество народу. rb2011 - один туннель - 2 - 7% загрузки, rb450g - один туннель вообще даже не чухает, выше 2% не заходит.
Захлебываться железка начнет гораздо раньше, на 10 туннелях, а то и ранее.
Опять же нагрузка зависит от того, какой по ней трафик. Если там разраб сидит, которому нужен рабочий стол в конторе - одно, если там тяжелый файлообмен (например база магазинная полезла цены обновлять) - это совсем другое.
CityCat4, значит будем наблюдать, тунель там будет один только, вопрос трафика вот тут уже хз, в основном продажники, но сейчас погуглил, фактически пишут что l2tp/IPsec не шибко много на ас2 выдаст, всего 100 +/- что пичально, и ниже чем заявлено. Надо будет искать вариант туннеля без шифрования видимо, пока будет обсуждаться вопрос новой железки
trovix, понаблюдать - это лучший вариант. Можно попробовать pptp - старый, давно поломатый, блокируемый провайдерами вовсю, но вроде как еще живой. А при обсуждении новой железки стоит сразу упираться в аппаратное шифрование. Оно точно есть у RB1100, RB4011 и CCR
CityCat4, пптп был первым что поднимал, даже без сжатия и шифрования, но почему то скорость скакала и не очень высокая была, так и не понял почему, iperf и спидтест выдавали на 30-40% ниже внутри тунеля чем без, l2tp/IPsec сейчас стабильно показывает на тестах скорости сопоставимые с каналом без тунеля до той же vps, 90-110, но это в папугаях и хз на сколько будет по факту.
По железкам я уже пульнул на самый большой этаж rb4011 в план, так как там нужен вайфай на много людей и хороший рутовый роутер, а сюда на место ac2 предложил как один из вариантов rb750 с аппаратным шифрованием, так как тут ничего кроме провода нет. А ас2 пристроить есть куда :) этаж большой компаньон rb4011 для расширения покрытия тоже нужен будет... В общем теперь вопрос только согласятся или нет...
trovix, У этой модели есть пренеприятнейшее свойство обнулять содержимое внутреннего накопителя. Заходишь ты такой через месяц - а там в разделе Files МПХ ночевал :) это не считая того, что он (накопитель) просто по уродски маленький. Если их использовать, то нужно быть готовым постоянно восстанавливать конфиг и бэкапы иметь после каждого обновления.
маршрутизация через найденный вариант Mangle оказалось хорошим вариантом, а виновник тормозов было стандартное правило fasttrack connections, которое не мешало старой схеме маршрутизации, но мешает гибко роутить трафик через маркировку. Как только отключил его интернет на клиентах заработал нормально.
Так себе решение, вернее костыль. плодить сущности для такого, если это можно настроить на роутере без участия клиента, и так уже один овпн сервер есть, который используется сотрудниками для доступа к своим рабочим компам из дома.
Drno, так я это же и написал в тексте вопроса. Вы текст весь прочитали? При данной схеме у меня скорость открытия интернет страниц просто адская. Один из вопросов был если схема правильная то, что нужно исправить/проверить/донастроить чтоб интернет работал с нормальной скоростью у клиента
Простой
