+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Подключение в качестве клиента L2TP/IPSEC

Подключение в качестве клиента L2TP/IPSEC, RouterOS

szabi

Guest

15.01.2021 15:47:00

Привет! У меня есть VPN-сервер L2TP/IPSEC на публичном IP. Я могу подключаться к нему с любых своих устройств, как и ожидал. Вот моя рабочая Windows-настройка:

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

Буду признателен за любую помощь, заранее большое спасибо!

sindy

Guest

29.01.2021 21:27:00

Я полагаю, что с вашей стороны вообще нельзя достучаться до чего-либо в LAN-сети сервера с любой точки LAN-сети Mikrotik. Зато вы должны иметь возможность достучаться до него с самого Mikrotik. В /ip firewall nat есть правило: add action=masquerade chain=srcnat out-interface=pptp-out1. Нужно заменить out-interface в этом правиле на l2tp-out1 или добавить новое правило командой /ip firewall nat add copy-from=[find out-interface~“pptp-out1”] out-interface=l2tp-out1, если вы хотите продолжать использовать pptp-out1. После этого всё должно заработать.

szabi Guest	#3 0 30.01.2021 13:02:00 Нет, я даже не могу подключиться к нему через терминал Mikrotik.

sindy

Guest

30.01.2021 13:20:00

По умолчанию Windows использует туннель в качестве основного шлюза, как только он поднимается, если только сервер не отвечает на сообщение DHCPINFORM, отправленное через туннель, с ответом, который содержит таблицу маршрутизации в Опции 249. Mikrotik этого не поддерживает; можно включить add-default-route=yes в строке /interface l2tp-client, но это, скорее всего, не то, что вам нужно. Поэтому все необходимые маршруты нужно добавлять вручную через l2tp-out1. Как и с правилом src-nat, у вас есть несколько маршрутов с gateway=pptp-out1, но ни одного с gateway=l2tp-out1.

szabi

Guest

30.01.2021 18:03:00

Mikrotik не поддерживает описанное выше; можно настроить > add-default-route=yes > в строке > /interface l2tp-client > , но это, скорее всего, не то, что вам нужно. Поэтому необходимо вручную добавить нужные маршруты через l2tp-out1. Как и с правилом src-nat, у вас есть несколько маршрутов с > gateway=pptp-out1 > , но ни одного с > gateway=l2tp-out1 > . Я уже пробовал так делать — безуспешно. По какой-то причине шлюз l2tp показывает недоступным

Я выяснил, что всё же могу пинговать устройства в удалённой LAN, но нужно указать интерфейс.
[admin@MikroTik] > ping 192.168.10.50 interface=l2tp-out1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.10.50 56 63 5ms
1 192.168.10.50 56 63 7ms
sent=2 received=2 packet-loss=0% min-rtt=5ms avg-rtt=6ms max-rtt=7ms

sindy Guest	#6 0 30.01.2021 18:19:00 Что показывает команда /ip route print detail, где gateway содержит «l2tp»?

szabi

Guest

30.01.2021 20:07:00

Флаги: X - отключено, A - активно, D - динамическое, C - соединение, S - статическое, r - rip, b - bgp, o - ospf, m - mme,
B - черная дыра, U - недоступно, P - запрещено
0 X S dst-address=172.16.10.0/24 gateway=pptp-out1,l2tp-out1 gateway-status=pptp-out1 неактивен, l2tp-out1 неактивен distance=1
scope=30 target-scope=10

1 S dst-address=172.16.10.101/32 gateway=l2tp-out1 gateway-status=l2tp-out1 недоступно distance=1 scope=30 target-scope=10

sindy

Guest

30.01.2021 20:52:00

…и интерфейс l2tp-out1 был активен ( R ) в момент, когда вы делали этот вывод, и команда ping 172.16.10.101 interface=l2tp-out1 сработала? Потому что когда интерфейс активен, должна быть ещё одна маршрутная запись: n ADC dst-address=x.x.x.x/32 pref-src=y.y.y.y gateway=l2tp-out1 gateway-status=l2tp-out1 reachable distance=0 scope=10

szabi

Guest

30.01.2021 21:45:00

[/quote] …и интерфейс l2tp-out1 был активен ( R ) в момент, когда вы сделали этот вывод, и команда ping 172.16.10.101 interface=l2tp-out1 сработала? Потому что при поднятом интерфейсе должна быть и другая маршрутная запись: n ADC dst-address=x.x.x.x/32 pref-src=y.y.y.y gateway=l2tp-out1 gateway-status=l2tp-out1 reachable distance=0 scope=10 [/quote] Да, был. Я ещё раз дважды проверил.

sindy

Guest

#10

31.01.2021 09:16:00

Лог показывает успешное установление управляющего соединения:
09:14:47 l2tp,debug,packet отправлено управляющее сообщение на my.remote.server.ip:1701 с my.public.ip:1701 …
09:14:47 l2tp,debug,packet (M) Message-Type= SCCRQ …
09:14:47 l2tp,debug,packet получено управляющее сообщение от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:47 l2tp,debug,packet (M) Message-Type= SCCRP …
09:14:47 l2tp,debug tunnel 11 переходит в состояние: established
09:14:47 l2tp,debug,packet отправлено управляющее сообщение на my.remote.server.ip:1701 с my.public.ip:1701 …
09:14:47 l2tp,debug,packet (M) Message-Type= SCCCN
09:14:47 l2tp,debug сессия 1 переходит в состояние: wait-reply
09:14:47 l2tp,debug,packet получено управляющее сообщение (ack) от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:47 l2tp,debug,packet отправлено управляющее сообщение на my.remote.server.ip:1701 с my.public.ip:1701 …
09:14:47 l2tp,debug,packet (M) Message-Type= ICRQ …
09:14:47 l2tp,debug,packet получено управляющее сообщение от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:47 l2tp,debug,packet (M) Message-Type= ICRP …
09:14:47 l2tp,debug сессия 1 переходит в состояние: established

Далее IPCP устанавливает IP-туннель. Стоит отметить, что сервер указывает адрес, по которому он ожидает входящие L2TP-соединения, также как адрес своей стороны туннеля:
09:14:47 l2tp,ppp,debug,packet l2tp-out1: получен IPCP ConfReq id=0x2
09:14:47 l2tp,ppp,debug,packet
09:14:47 l2tp,ppp,debug,packet l2tp-out1: отправлен IPCP ConfAck id=0x2
09:14:47 l2tp,ppp,debug,packet

Это заставляет RouterOS сгенерировать случайный адрес 10.x.x.x как сетевой в элементе /ip address, но обычно это не причина, по которой всё ломается:
/interface l2tp-client add connect-to=192.168.227.47 disabled=no name=l2tp-out1 profile=my-l2tp use-ipsec=yes user=chr-1

23:29:16 l2tp,ppp,debug,packet l2tp-out1: получен IPCP ConfReq id=0x1
23:29:16 l2tp,ppp,debug,packet <addr 192.168.227.47 >
23:29:16 l2tp,ppp,debug,packet l2tp-out1: отправлен IPCP ConfAck id=0x1
23:29:16 l2tp,ppp,debug,packet <addr 192.168.227.47 >

[me@myTik] > ip address print
Flags: X - отключен, I - недействителен, D - динамический
ADDRESS NETWORK INTERFACE
…
8 D 192.168.224.19/32 10.113.185.224 l2tp-out1

(если адрес, предложенный в ConfReq, отличается от connect-to, он используется как значение network в /ip address буквально).

За 3 секунды после установления IPCP стек xelerance отправляет SCCRP, которого RouterOS не ожидает, но он относится к другому Tunnel-ID, так что это выглядит либо как «доф» (след от предыдущей попытки соединения), либо вы одновременно подключаете несколько сессий L2TP/IPsec к одному серверу с одного публичного IP, что в сочетании с использованием режима транспортного IPsec SA вызывает разные сбои, в зависимости от того, как ответчик (сервер) обрабатывает динамическое создание IPsec политик.

Но поскольку вы можете пинговать через туннель, указав интерфейс в ping, это всё равно не объясняет, что у вас происходит. И поскольку неожиданный SCCRP для другого tunnel-id, он не должен влиять на уже установленный туннель. Правда, вопрос: действительно ли он не влияет.

Так что стоит попробовать отключить l2tp-out1, разорвать подключение любых других клиентов к тому же серверу, которые могут быть в LAN MikroTik, и попробовать включить l2tp-out1 снова через 10 минут с включённым логированием (ipsec логировать не обязательно, достаточно l2tp).

Перед этим – есть ли у вас в /ip address элемент с флагом D и интерфейсом l2tp-out1 при поднятом соединении? Если есть, какой адрес в колонке network?

09:14:47 l2tp,ppp,debug l2tp-out1: IPCP открыт
09:14:47 l2tp,ppp,info l2tp-out1: подключено …
09:14:50 l2tp,debug,packet получено управляющее сообщение от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:50 l2tp,debug,packet (M) Message-Type=SCCRP …
09:14:50 l2tp,debug получен SCCRP раньше SCCRQ, отклонено
09:14:50 l2tp,debug,packet отправлено управляющее сообщение на my.remote.server.ip:1701 с my.public.ip:1701 …
09:14:50 l2tp,debug,packet (M) Message-Type=StopCCN …
09:14:50 l2tp,debug,packet получено управляющее сообщение (ack) от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:50 l2tp,debug,packet получено управляющее сообщение от my.remote.server.ip:1701 на my.public.ip:1701 …
09:14:50 l2tp,debug,packet (M) Message-Type=StopCCN …
09:14:50 l2tp,debug,packet (M) Result-Code=2
09:14:50 l2tp,debug,packet Error-Code=2
09:14:50 l2tp,debug,packet Error-Message=“Result Code: expected at least 10, got 8”

DarkNate Guest	#11 0 31.01.2021 09:28:00 Возможно, это вам поможет: http://forum.mikrotik.com/t/force-lt2p-ipsec-tunnel-over-specific-wan-interface/145614/9

szabi Guest	#12 0 31.01.2021 12:59:00 Перед тем как это делать — есть ли у тебя пункт типа > D > в > /ip address > с > l2tp-out1 > как интерфейс, когда соединение активно? Если да, то какой адрес указан в колонке > network >? Других L2TP-клиентов, подключённых к серверу, нет. Также нет никаких других L2TP-сессий ни на Mikrotik, ни где-либо ещё за моим публичным IP. Да, пункт D создан, у него IP 172.16.17.2 — это IP, присвоенный респондером. Сетевой адрес — 10.112.113.88, откуда он вообще взялся?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры