sol Опубликовано 20 июля, 2021 · Жалоба Коллег, занесла меня нелёгкая в командировку. Тут есть неплохой интернет. Роутером выступает микротик какой-то мелкий. Возникла задача подтянуть для удобства всю мою инфраструктуру путём поднятия VPN. С моей стороны linux Fedora 32 и OpenVPN В микроте я дуб. Начитался мануалов, сгенерил центр сертификации, загрузил сертификаты в микрот. Соединение поднимается, микрот адреса получает какие нужно. Т.е. с OpenVPN сервером он "разговаривает". А вот пакетики не ходят. Пробовал и 6-ю ветку и 7-ю. И TCP и UDP.. Итог один. Вот настройки сервера: [root@dserver server]# cat sov7.conf ca /etc/openvpn/easy-rsa/pki/ca.crt cert /etc/openvpn/easy-rsa/pki/issued/myserver.crt key /etc/openvpn/easy-rsa/pki/private/myserver.key dh /etc/openvpn/easy-rsa/pki/dh.pem crl-verify /etc/openvpn/easy-rsa/pki/crl.pem proto udp dev tun2 # ifconfig 10.173.123.29 10.173.123.30 topology subnet mode server server 10.173.110.0 255.255.255.0 client-config-dir /etc/openvpn/server/ccd client-to-client port 5577 daemon no-replay ping 10 ping-restart 30 # cipher AES-256-CBC cipher AES-128-CBC # cipher BF-CBC auth SHA1 # tun-ipv6 tls-server local XX.XX.XX.XX user nobody group nobody root@dserver server]# ifconfig tun2 tun2: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.173.110.1 netmask 255.255.255.0 destination 10.173.110.1 inet6 fe80::8a3f:27a7:7da0:7808 prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 61 bytes 5092 (4.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 При этом микрот показывает, что он отвечает. Причём, отвечает каким-то левым адресам. Должен отвечать на пинги 10.173.110.1, а отвечает каким-то левым 8.0.х.х Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 20 июля, 2021 · Жалоба 2 часа назад, sol сказал: Должен отвечать на пинги 10.173.110.1, а отвечает каким-то левым 8.0.х.х Значит трафик улетает в Интернет. Проверить правило NAT - в нем должно быть исключение для трафика локальной сети. Проверить маршрутизацию - мб. маршрут на туннель не поднялся. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 20 июля, 2021 · Жалоба Ответ неверный. Дамп трафика на OpenVPN интерфейсе приложен. Третья картинка если считать сверху вниз. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 21 июля, 2021 · Жалоба 10 часов назад, jffulcrum сказал: Проверить правило NAT - в нем должно быть исключение для трафика локальной сети. Оно одно и маскарадит то, что улетает через WAN интерфейс оптом. 10 часов назад, jffulcrum сказал: Проверить маршрутизацию - мб. маршрут на туннель не поднялся. Пока нет никакой маршрутизации. У микрота есть только дефолт. Беда в том, что тоннель не пингуется с его концов. Микрот не пингует линукс-сервер, а сервер в свою очередь не пингует микрот. При этом на микроте в торче возникает этот странный трафик на странные IP. На линуксе вообще нет принятых пакетов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 21 июля, 2021 · Жалоба В правиле маршрутизации укажите не IP в качестве шлюза, а сам интерфейс Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 21 июля, 2021 · Жалоба В "правиле" маршрутизации ЧЕГО? Во всём микроте один роут: дефолт. Других нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 24 июля, 2021 · Жалоба Пощелкал переключателями в профиле PPP и случилось странное: При переустановлении соединения пинги начинают ходить. И ходят несколько часов, пока не происходит что-то непонятное и всё умирает до ап/даун соединения... В целом, полный глюкодром без возможности дебага. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
msdt Опубликовано 26 июля, 2021 · Жалоба Это на RouterOS 7? Так вроде никто пока не обещал, что в ней что-то будет работать стабильно и безглючно. В RouterOS 6 OpenVPN работает стабильно, но только по TCP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 27 июля, 2021 · Жалоба 15 часов назад, msdt сказал: Это на RouterOS 7? В 20.07.2021 в 20:51, sol сказал: А вот пакетики не ходят. Пробовал и 6-ю ветку и 7-ю. И TCP и UDP.. Итог один. Пока всё заработало на WireGuard. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...