Комментарии 21
Зачем такой изврат с endpoint и портом. Все работает и можна з веб интерфейса/winboxа натикать.
Правда перформанс так себе пока-что. У меня hAP ac и l2tp+ipsec дает ровно в 2 раза большую скорость по сравнению с wireguard на этом же роутере. Скорей всего сирая бета сказывается
##### RouterOS 7.1b2: create Wireguard server
# create the server
/interface wireguard add listen-port=51820 mtu=1420 name=wireguard1
# get server's public key
/interface wireguard print
# add IP-address to the interface
/ip address add address=10.0.0.1/24 interface=wireguard1 network=10.0.0.0
# allow from firewall
/ip firewall filter add action=accept chain=input comment=«Accept WireGuard» dst-port=51820 log=yes log-prefix=WG: protocol=udp
# configure client and get the client's public key
[Interface]
PrivateKey = CLIENT-PRIVATEKEY
Address = 10.0.0.2/24
DNS = 192.168.88.1
[Peer]
PublicKey = ROUTER-PUBLICKEY
AllowedIPs = 0.0.0.0/0
Endpoint = serverhostname.com:51820
PersistentKeepalive = 20
# add client to the configuration
/interface wireguard peers add allowed-address=10.0.0.2/32 interface=wireguard1 persistent-keepalive=20 public-key=«CLIENT-PUBLICKEY»
##### End of Wireguard
Правда перформанс так себе пока-что. У меня hAP ac и l2tp+ipsec дает ровно в 2 раза большую скорость по сравнению с wireguard на этом же роутере. Скорей всего сирая бета сказывается
Мопед не мой, ссылка-источник картинки с производительностью прямо под ней…
С другими данными (transfer time больше для UDP) тоже согласуется.
В принципе даже графики не просто картинки, а реальный набор, визуализированный через внешний сервис: vpn-test.entrostat.com/public/question/6ad737cb-900d-4349-a4e1-8f8936de0511
На вид достаточно подробно и методика описана, так что вызывает доверие.
Хотя по идее на UDP накладные расходы должны быть меньше, а производительность выше. Т.е. для меня тоже несколько удивительно, согласен.
С другими данными (transfer time больше для UDP) тоже согласуется.
В принципе даже графики не просто картинки, а реальный набор, визуализированный через внешний сервис: vpn-test.entrostat.com/public/question/6ad737cb-900d-4349-a4e1-8f8936de0511
На вид достаточно подробно и методика описана, так что вызывает доверие.
Хотя по идее на UDP накладные расходы должны быть меньше, а производительность выше. Т.е. для меня тоже несколько удивительно, согласен.
В текущих версиях RouterOS 6.**.* нет поддержки WireGuard, появилось в RouterOS 7.1beta2 (2020-Aug-21 12:29)
А у кого-нибудь получилось добавить wireguard интерфейс в bridge? Или связывать его с сеткой реально только через фаервол?
Можно сценарий?
Например:
— Дом. 192.168.1.10
— Хочу подключиться к 192.168.1.20
— Кидаю ARP запрос
— В локалке домашней адреса нет, но от Wireguard прихолит ответ, что этот IP за ним
— пакет улетает далеко-далеко в зашифрованом виде.
Т.е. зашифрованый Layer 2 нужен?
Или все-таки маршрутизация допустима?
Типа
— Я 192.168.1.10
— Удаленная машина 192.168.68.20
— 192.168.1.1 у меня маршрут по умолчанию
— И есть доп маршрут «192.168.68.0/24 за 192.168.1.254», где 192.168.1.254 — как раз адрес интефрейса Wireguard
Например:
— Дом. 192.168.1.10
— Хочу подключиться к 192.168.1.20
— Кидаю ARP запрос
— В локалке домашней адреса нет, но от Wireguard прихолит ответ, что этот IP за ним
— пакет улетает далеко-далеко в зашифрованом виде.
Т.е. зашифрованый Layer 2 нужен?
Или все-таки маршрутизация допустима?
Типа
— Я 192.168.1.10
— Удаленная машина 192.168.68.20
— 192.168.1.1 у меня маршрут по умолчанию
— И есть доп маршрут «192.168.68.0/24 за 192.168.1.254», где 192.168.1.254 — как раз адрес интефрейса Wireguard
Задача — соединить wg сетку и локальную. Маршрутизация допустима.
— Домашняя сеть 192.168.1.0/24
— Удаленная машина 192.168.68.20
— WG сервер 192.168.1.254, WG сетка 192.168.68.0/24
— прописан маршрут 192.168.68.0/24 через 192.168.68.254 и он не думает работать
— Домашняя сеть 192.168.1.0/24
— Удаленная машина 192.168.68.20
— WG сервер 192.168.1.254, WG сетка 192.168.68.0/24
— прописан маршрут 192.168.68.0/24 через 192.168.68.254 и он не думает работать
Самое правильное — идти по шагам/хопам и проверять, на каком из этапов теряется пинг. Лучше через отслеживание пакетов — так можно узнать, потерялись ответы или запросы.
Дополнительно — проверьте, что удалённая машина получила все нужные маршруты для общения с сетью 192.168.1.0/24. И в вашей ситуации не понятно — WG сервер поднят на маршрутизаторе или где-то ещё? Кто у вас default gateway?
Упс, не в ту ветку вот этот коммент написал:
Wireguard это всегда L3, поэтому добавить его в бридж не получится. Можно попробовать поверх Wireguard поднять какой-нибудь gretap/eiop, и уже его засунуть в бридж. Как обычно, в таких схемах нужно следить за MTU, иначе потом дебажить это будет совсем не весело.
Пробовал обновить у родителей роутер Miktotik до 7 версии. Wireguard не завелся. Ко всему прочму и routing поломан. BGP, который нужен был просто отсутствует. Так что не раньше релиза стоит ждать чуда.
Выглдяит, как совершенно стандартная конфигурация.
> 192.168.68.0/24 через 192.168.68.254
Наверное все-таки на 192.168.1.20 знает «192.168.68.0/24 через 192.168.1.254»
Я бы проверял в такой последовательности:
— wg show — а вообще поднят ли VPN туннель
— ping удаленного адреса туннеля (условно 192.168.66.253) с машинки с wireguard (192.168.1.254). При этом пинг пойдет с адреса туннеля (192.168.66.254 или какой у вас настроен)
— Если ОК — тот же ping, находясь так же на 192.168.1.254, но указав source IP локального интерфейса. Чтобы пинг пошел с 192.168.1.254
— Проверить такой же пинг на 192.168.66.253, но уже с реальной машины 192.168.1.20
Чаще всего я ошибался AllowedIPs или маршрутах.
Недостаточно прописать «дома» маршрут «192.168.68.0/24 через 192.168.1.254»
В удаленной сети должно быть аналогично (192.168.1.0/24 через 192.168.68.253)
Т.е., чтобы удаленная машина 192.168.68.20 достуачалась до 192.168.1.0 нужно
— 192.168.68.20 слала 192.168.1.0/24 на LAN wireguard'а (192.168.68.253 или какой там)
— Тот «дальний» wirguard 192.168.1.0 отправил в туннель (причем именно этот, на 192.168.66.254)
— и обратно аналогично
В промежутках смотреть tcpdump. Может где-то NAT включен и нарушает AllowedIPs. Или наоборот не включен.
> 192.168.68.0/24 через 192.168.68.254
Наверное все-таки на 192.168.1.20 знает «192.168.68.0/24 через 192.168.1.254»
Я бы проверял в такой последовательности:
— wg show — а вообще поднят ли VPN туннель
— ping удаленного адреса туннеля (условно 192.168.66.253) с машинки с wireguard (192.168.1.254). При этом пинг пойдет с адреса туннеля (192.168.66.254 или какой у вас настроен)
— Если ОК — тот же ping, находясь так же на 192.168.1.254, но указав source IP локального интерфейса. Чтобы пинг пошел с 192.168.1.254
— Проверить такой же пинг на 192.168.66.253, но уже с реальной машины 192.168.1.20
Чаще всего я ошибался AllowedIPs или маршрутах.
Недостаточно прописать «дома» маршрут «192.168.68.0/24 через 192.168.1.254»
В удаленной сети должно быть аналогично (192.168.1.0/24 через 192.168.68.253)
Т.е., чтобы удаленная машина 192.168.68.20 достуачалась до 192.168.1.0 нужно
— 192.168.68.20 слала 192.168.1.0/24 на LAN wireguard'а (192.168.68.253 или какой там)
— Тот «дальний» wirguard 192.168.1.0 отправил в туннель (причем именно этот, на 192.168.66.254)
— и обратно аналогично
В промежутках смотреть tcpdump. Может где-то NAT включен и нарушает AllowedIPs. Или наоборот не включен.
Наверное все-таки на 192.168.1.20 знает «192.168.68.0/24 через 192.168.1.254»
Да, опечатался. Ясное дело, у меня ж сетки совсем иначе называются.
Чаще всего я ошибался AllowedIPs или маршрутах.
Недостаточно прописать «дома» маршрут «192.168.68.0/24 через 192.168.1.254»
Итого, проблема оказалась именно тут — в AllowedIPs на сервере должен быть адрес сети клиента, которая хочет работать с этим интерфейсом.
Ну отлично.
Хоть у кого-то заработало :) А то вон пугают, что и не завелся, и BGP исчез…
Хоть у кого-то заработало :) А то вон пугают, что и не завелся, и BGP исчез…
Он у меня завелся еще N времени назад, но приходилось прописывать NAT для доступа к ресурсам сервера, а это откровенно ненормально. А как сделать двусторонний NAT (точнее, Transparent Firewall) я так и не разобрался.
В целом, из ненормального тут только настройка endpoint и allowed-address на Mikrotik, за счет того, что конфиг WG хранится в текстовом виде и редактируется через текстовый редактор, доступный только по SSH.
А, ну еще на старом RB750UP все настроилось, но не заработало и сильно-сильно кушало процессор. Видимо, не по нему эта задача.
В целом, из ненормального тут только настройка endpoint и allowed-address на Mikrotik, за счет того, что конфиг WG хранится в текстовом виде и редактируется через текстовый редактор, доступный только по SSH.
А, ну еще на старом RB750UP все настроилось, но не заработало и сильно-сильно кушало процессор. Видимо, не по нему эта задача.
BGP и MPLS отсутствуют в бете, чтобы народ не тестировал на рабочей магистрали сейчас. Будут добавлены позже, если верить им.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mikrotik (RouterOS) + Wireguard