Форум русскоязычного сообщества Ubuntu


Получить помощь и пообщаться с другими пользователями Ubuntu можно
на irc канале #ubuntu-ru в сети Freenode
и в Jabber конференции ubuntu@conference.jabber.ru

Автор Тема: Рвётся соединение L2TP из-за systemd-networkd  (Прочитано 1949 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
У меня дома Интернет от Билайна. Единственно возможный тип подключения - L2TP. До недавнего времени с этим провайдером использовался роутер. Сейчас появилась возможность/необходимость заменить роутер маленьким сервером. Остановился на Raspberry Pi 4 + Ubuntu Server 19.10. Всё, что было нужно, настроил. Но одну проблему побороть никак не получается. А именно, постоянные разрывы соединения раз в ~104,5 минуты. Не буду описывать какой путь я прошёл, чтобы выяснить из-за чего это происходит, но дело оказалось в systemd-networkd. А именно он пытается обновить IP по DHCP кратковременно роняя интерфейс. Таймер заряжен на 6300 секунд, что соответствует 105 минутам. Полминуты уходит на соединение и другие накладные расходы. В итоге через ~104,5 минуты соединение рвётся.

В логах это выглядит так:
Jan 31 13:57:17 localhost systemd-networkd[6347]: eth1: DHCP lease lost
Jan 31 13:57:17 localhost systemd-networkd[6347]: eth1: DHCPv4 address 10.16.193.24/21 via 10.16.192.1
Jan 31 13:57:17 localhost charon: 02[KNL] 10.16.193.24 disappeared from eth1
Jan 31 13:57:17 localhost systemd-networkd[6347]: eth1: IPv6 successfully disabled
Jan 31 13:57:17 localhost charon: 08[KNL] 10.16.193.24 appeared on eth1

И вот этого disappeared-appeared хватает, чтобы рухнул туннель L2TP, проложенный по этому интерфейсу:

Jan 31 13:58:10 localhost pppd[11318]: LCP terminated by peer
Jan 31 13:58:10 localhost xl2tpd[11317]: message_type_avp: message type 14 (Call-Disconnect-Notify)
Jan 31 13:58:10 localhost xl2tpd[11317]: result_code_avp: peer closing for reason 2 (General error--Error Code indicates the problem), error = 6 (Locally ge
Jan 31 13:58:10 localhost xl2tpd[11317]: assigned_call_avp: using peer's call 49373
Jan 31 13:58:10 localhost xl2tpd[11317]: handle_avps:  don't know how to handle attribute 46.
Jan 31 13:58:10 localhost xl2tpd[11317]: handle_avps:  don't know how to handle attribute 104.
Jan 31 13:58:10 localhost xl2tpd[11317]: control_finish: message type is Call-Disconnect-Notify(14).  Tunnel is 41473, call is 49373.
Jan 31 13:58:10 localhost xl2tpd[11317]: control_finish: Connection closed to 78.107.1.249, serial 1 (Locally generated disconnect)
Jan 31 13:58:10 localhost xl2tpd[11317]: Terminating pppd: sending TERM signal to pid 11318
Jan 31 13:58:10 localhost pppd[11318]: Connect time 104.5 minutes.

На всякий случай привожу содержимое файла /var/run/systemd/netif/leases/17:

# This is private data. Do not parse.
ADDRESS=10.16.193.24
NETMASK=255.255.248.0
ROUTER=10.16.192.1
SERVER_ADDRESS=78.107.63.106
MTU=576
T1=3600
T2=6300
LIFETIME=7200
DNS=213.234.192.8 85.21.192.3
DOMAINNAME=beeline
HOSTNAME=cityacee
ROUTES=85.0.0.0/8,10.16.192.1 194.67.1.0/24,10.16.192.1 85.0.0.0/8,10.16.192.1
CLIENTID=ff3d78606a00010000ab1181f811c1f3dcf832

Как видно срабатывает время, указанное в T2.

Первое, что приходит на ум - это прописать статичный адрес. Но это будет костылём, который со временем может отвалиться. Как можно решить проблему цивилизованным способом, чтобы DHCP просто обновлял таймер, если IP-адрес не поменялся, а не передёргивал интерфейс?
С уважением, Станислав.

Оффлайн Usermaster

  • СуперМодератор
  • Старожил
  • *
  • Сообщений: 2537
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #1 : 31 Января 2020, 14:37:33 »
А можно поинтересоваться почему Вы выбрали Raspberry pi ?
Почему не маршрутизатор?

WiFi покрытие маршрутизатора выше. У Raspberry pi от рассотяния в несколько метров сильно падает приём.
Геморрой с настройкой, маршрутизатор проще настроить.
Маршрутизатор дешевле если не брать сильно навороченный.
Умеет всё то же что и Raspberry.

Или это просто - Хочу, хочу, хочу?

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #2 : 31 Января 2020, 14:55:12 »
А можно поинтересоваться почему Вы выбрали Raspberry pi ?
Почему не маршрутизатор?
Потому, что на Ubuntu (не важно Raspberry Pi это, неттоп или что-то ещё) я могу настроить всё, что я захочу сейчас или в будущем. Я вообще ничем не ограничен. Вот, например, я настроил себе DDNS через Яндекс. На обычном маршрутизаторе, который у меня, безусловно, тоже имеется, это не представляется возможным. Опять же мне нужно ftp и www. Ещё мне нужны питоновские скрипты не сервере, запускаемые по cron'у. Да и всякое другое...
С уважением, Станислав.

Оффлайн Usermaster

  • СуперМодератор
  • Старожил
  • *
  • Сообщений: 2537
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #3 : 31 Января 2020, 15:08:05 »
Всё перечисленное можно было использовать (кроме DDNS) не засовывая его в голову а пробросить на него всё что надо.
Это так, рассуждения, можно не отвечать.

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #4 : 31 Января 2020, 16:01:32 »
Всё перечисленное можно было использовать (кроме DDNS) не засовывая его в голову а пробросить на него всё что надо.
Это так, рассуждения, можно не отвечать.
Это является аварийным вариантом (проброс в DMZ, я имею ввиду), на тот случай, если вдруг не удастся добиться стабильного коннекта. Я даже примерно представляю, как я смогу решить проблему с DDNS. Но всё же хочется сделать так, как я запланировал изначально.
С уважением, Станислав.

Оффлайн koshev

  • Старожил
  • *
  • Сообщений: 1709
  • חתול המדען
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #5 : 01 Февраля 2020, 12:35:31 »
Попробуйте с LCP timeout в pppd поиграться. Не факт конечно что поможет, но валится соединение из-за этого в том числе.
OpenWrt 19.07

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #6 : 01 Февраля 2020, 13:08:36 »
Потому, что на Ubuntu (не важно Raspberry Pi это, неттоп или что-то ещё) я могу настроить всё, что я захочу сейчас или в будущем.
https://openwrt.org/
Люди даже сайты с PHP на роутерах поднимают.

А с вашей проблемой я бы посоветовал сначала обратиться в техподдержку провайдера.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #7 : 01 Февраля 2020, 15:06:26 »
Продолжаю исследовать проблему далее.

Включил debug для systemd по такому методу:
Цитировать
The debug log can be generated by e.g. creating the following drop-in config:

# /etc/systemd/system/systemd-networkd.service.d/override.conf
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

И получил лог работы DHCP:

Feb  1 10:07:44 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): STARTED on ifindex 4
Feb  1 10:07:44 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): DISCOVER
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): OFFER
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (requesting)
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): ACK
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): lease expires in 1h 8min 12s
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T2 expires in 59min 40s
Feb  1 10:07:45 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T1 expires in 34min 5s
Feb  1 10:41:50 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 10:54:38 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 11:07:25 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (rebinding)
Feb  1 11:07:25 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): ACK
Feb  1 11:07:25 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): lease expires in 1h 59min 58s
Feb  1 11:07:25 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T2 expires in 1h 44min 59s
Feb  1 11:07:25 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T1 expires in 59min 59s
Feb  1 12:07:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 12:29:56 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 12:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (rebinding)
Feb  1 12:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): ACK
Feb  1 12:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): lease expires in 1h 59min 58s
Feb  1 12:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T2 expires in 1h 44min 58s
Feb  1 12:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T1 expires in 1h
Feb  1 13:52:24 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 14:14:55 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (renewing)
Feb  1 14:37:22 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): REQUEST (rebinding)
Feb  1 14:37:22 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): ACK
Feb  1 14:37:22 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): lease expires in 1h 59min 58s
Feb  1 14:37:22 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T2 expires in 1h 44min 58s
Feb  1 14:37:22 localhost systemd-networkd[2780]: DHCP CLIENT (0x5d7d7a5b): T1 expires in 59min 59s

По логу видно, что согласно счётчикам T1 и T2 вначале шлются два запроса на renewing, а потом rebinding. И вот как раз в процессе rebinding туннель падает. Насколько я понимаю логику работы DHCP, после назначения адреса в логах я должен видеть лишь череду запросов renewing, которые просто должны проделать время аренды и ничего более. Здесь же после двух неудачных (?) renewing, следует rebinding, который всё ломает. И непонятно, то ли у меня запросы некорректные идут, то ли ответ не обрабатывается, то ли ещё что-то.

Есть у кого-нибудь мысли?
« Последнее редактирование: 01 Февраля 2020, 15:12:50 от CityAceE »
С уважением, Станислав.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #8 : 01 Февраля 2020, 16:47:34 »
Продолжаю исследовать проблему далее.

Включил debug для systemd по такому методу:
...
Есть у кого-нибудь мысли?

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

Прямо с этим логом. Можно ещё сетевой лог DHCP снять для полного прояснения ситуации.
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн The Green Side

  • Старожил
  • *
  • Сообщений: 1178
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #9 : 01 Февраля 2020, 17:16:28 »
Техподдержка Билайна? Успехов с этим.
У меня по вечерам пятницы стабильно на 2-3 часа пропадал интернет.
Они заставили меня подключить ПК напрямую к сети, прежде чем занялись моей проблемой. Впрочем, проблему они не решили (хотя наврали по смс, что всё исправили), я просто сменил провайдера через месяц.
Как потом рассказал мне монтажник от другого провайдера, мы с соседом висели на одной витой паре. Я в этом не разбираюсь, по подтекст был негативный.
Debian 11, Debian 11 Server

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #10 : 02 Февраля 2020, 09:41:16 »
В общем, суть проблемы я уловил, но устранить её пока никак не получается.

Когда я включаю кабель в сеть, то я обращаюсь к серверу DHCP локальной сети провайдера (SERVER_ADDRESS=78.107.63.106). Далее я поднимаю интерфейс PPP и заворачиваю весь трафик на него, чтобы у меня появился Интернет. Очевидно трафик до DHCP-сервера тоже идёт через новый интерфейс и до сервера не доходит. systemd дважды пытается обновить время аренды и не может, после чего рвёт связь, PPP-интерфейс падает, трафик снова перенаправляется в локальную сеть и DHCP-сервер снова становится доступным. И всё повторяется заново.

Но проблема в том, что я пытался и маршрут к DHCP-серверу прокладывать через локалку, и даже целую подcеть. Но поведение DHCP-клиента всегда одинаковое. Я даже оставил на ночь сервер без Интернета, а только с локалкой, и всё равно это никак не помогает: после двух renewing непременно следует rebinding.

Пока я тупике.

Пользователь добавил сообщение 02 Февраля 2020, 12:56:44:
Решил посмотреть как должен выглядеть лог работы DHCP client в systemd, когда всё работает правильно. Для этого поднял аналогичную связку сервер-клинет в локальной сети. И вот что я получил:

Feb  2 12:48:55 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): REQUEST (renewing)
Feb  2 12:48:55 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): ACK
Feb  2 12:48:55 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): lease expires in 1min 57s
Feb  2 12:48:55 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T2 expires in 1min 44s
Feb  2 12:48:55 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T1 expires in 59s
Feb  2 12:49:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): REQUEST (renewing)
Feb  2 12:49:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): ACK
Feb  2 12:49:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): lease expires in 1min 58s
Feb  2 12:49:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T2 expires in 1min 43s
Feb  2 12:49:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T1 expires in 1min
Feb  2 12:50:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): REQUEST (renewing)
Feb  2 12:50:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): ACK
Feb  2 12:50:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): lease expires in 1min 58s
Feb  2 12:50:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T2 expires in 1min 43s
Feb  2 12:50:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T1 expires in 59s
Feb  2 12:51:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): REQUEST (renewing)
Feb  2 12:51:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): ACK
Feb  2 12:51:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): lease expires in 1min 58s
Feb  2 12:51:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T2 expires in 1min 43s
Feb  2 12:51:54 ubuntu systemd-networkd[1023]: DHCP CLIENT (0x2b0d5693): T1 expires in 59s

Отсюда видно, что на моём боевом сервере правильный ответ получается только после запроса requesting, а последующие запросы renewing остаются без ответов. Почему это происходит пока совершенно не понятно.

Пользователь добавил сообщение 02 Февраля 2020, 16:51:25:
Тот же сервер, на котором я проверял, как правильно должен работать DHCP-клиент я воткнул напрямую в сеть провайдера. И что же я увидел:

Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): STARTED on ifindex 2
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): DISCOVER
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): OFFER
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): REQUEST (requesting)
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): ACK
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): lease expires in 44min 41s
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): T2 expires in 39min 5s
Feb  2 13:57:21 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): T1 expires in 22min 20s
Feb  2 14:19:31 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): REQUEST (renewing)
Feb  2 14:27:56 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): REQUEST (renewing)
Feb  2 14:36:16 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): REQUEST (rebinding)
Feb  2 14:36:16 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): ACK
Feb  2 14:36:16 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): lease expires in 1h 59min 57s
Feb  2 14:36:16 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): T2 expires in 1h 44min 58s
Feb  2 14:36:16 ubuntu systemd-networkd[1026]: DHCP CLIENT (0xe7ae3129): T1 expires in 59min 58s

Никак не хочет провайдер правильно реагировать на запрос renewing!

Но вся соль в том, что подключенный роутер связь не рвал. Сейчас уже очевидно, что есть какая-то проблема на стороне у провайдера, но при этом роутер D-Link DIR-825AC связь не рвал. Значит, не смотря на проблемы, как-то можно заставить работать систему и с этой проблемой провайдера. Но как?
« Последнее редактирование: 02 Февраля 2020, 16:51:25 от CityAceE »
С уважением, Станислав.

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #11 : 04 Февраля 2020, 12:03:26 »
Вместо Ubuntu временно установил Raspbian. Там isc-dhcp-client, у которого логика работы слега отличается от встроенного в systemd клиента. И тут всё встало на свои места...

 Подключаемся к сети и шлём широковещательный (255.255.255.255) запрос о присвоении адреса, получении DNS, маршрутов и другой информации:

Feb  3 19:17:59 server dhclient[295]: Listening on LPF/eth1/1c:1e:1e:f2:0f:19
Feb  3 19:17:59 server dhclient[295]: Sending on   LPF/eth1/1c:1e:1e:f2:0f:19
Feb  3 19:17:59 server dhclient[295]: Sending on   Socket/fallback
Feb  3 19:17:59 server dhclient[295]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5
Feb  3 19:18:03 server dhclient[295]: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Feb  3 19:18:03 server dhclient[295]: DHCPOFFER of 10.16.192.220 from 10.16.192.1
Feb  3 19:18:03 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 255.255.255.255 port 67

Благополучно получаем все необходимые данные и устанавливаем время аренды:

Feb  3 19:18:03 server dhclient[295]: DHCPACK of 10.16.192.220 from 10.16.192.1
Feb  3 19:18:04 server dhclient[295]: bound to 10.16.192.220 -- renewal in 1579 seconds.

Через 1579 секунд, DHCP-клиент должен послать запрос на обновление аренды на адрес DHCP-сервера, который он получил на предыдущем шаге. Это и происходит:

Feb  3 19:44:23 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67

И вот тут клиент должен получить уведомление, что время аренды продлено. А что же происходит на самом деле? А на самом деле происходит вот что:

Feb  3 19:44:28 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb  3 19:44:41 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb  3 19:44:49 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
...
Feb  3 20:03:52 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb  3 20:04:00 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67
Feb  3 20:04:10 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 78.107.63.106 port 67

Вплоть до истечения счётчика T2 клиент будет отчаянно долбить по выданному адресу и не получать ответ потому, что ему выдали неправильный адрес DHPC-сервера.

Далее разные DHCP-клиенты могут вести себя по-разному. Вообще, не получив ответа, далее должен следовать широковещательный запрос на rebinding, а сам rebinding в итоге сопровождается разрывом соединения, так как время аренды истекло и клиент обязан освободить адрес. Но isc-dhcp-client, логи которого я здесь привожу, в качестве отчаянного шага, перед разрывом соединения всё-таки пытается сделать последнюю попытку продлить время аренды и посылает широковещательный запрос в сеть:

Feb  3 20:04:23 server dhclient[295]: DHCPREQUEST for 10.16.192.220 on eth1 to 255.255.255.255 port 67

И вот тут откуда-то из подсети снова откликается DHCP-сервер, который мы всё это время искали по адресу 78.107.63.106, но которого там нет, потому что админы неправильно настроили оборудование:

Feb  3 20:04:23 server dhclient[295]: DHCPACK of 10.16.192.220 from 10.16.192.1
Feb  3 20:04:23 server dhclient[295]: bound to 10.16.192.220 -- renewal in 3563 seconds.

И на 3563 секунды всё успокаивается. А потом всё начинается вновь.

Что-либо доказать службе техподдержки провайдера бесполезно. Они заладили, что они проверили линию и оборудование и с ними всё в порядке. И в доказательство говорят, что у всех остальных всё работает. Вот что с ними поделать?

Думаю теперь, как можно решить проблему по-другому. Нужно как-то заставить DHCP-клиент игнорировать подсунутый ему IP DHCP-сервера и вместо него подставлять 255.255.255.255.Вот только не уверен, что это возможно и что это вообще будет работать. Ещё лучше каким-то образом выяснить реальный адрес DHCP-сервера и подставлять его. Я пытался снять tcpdump в процессе широковещаетльного запроса, но там полезной информации не нашлось:

10:09:20.983078 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    10.16.192.220.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 1c:1e:1e:f2:0f:19 (oui Unknown), length 300, xid 0x3e9c0b18, secs 3319, Flags [none]
  Client-IP 10.16.192.220
  Client-Ethernet-Address 1c:1e:1e:f2:0f:19 (oui Unknown)
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Request
    Hostname Option 12, length 8: "cityacee"
    Parameter-Request Option 55, length 13:
      Subnet-Mask, BR, Time-Zone, Default-Gateway
      Domain-Name, Domain-Name-Server, Option 119, Hostname
      Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
      NTP
    Client-ID Option 61, length 19: hardware-type 255, 1e:f2:0f:19:00:01:00:01:25:cb:01:f9:1c:1e:1e:f2:0f:19

10:09:20.993471 IP (tos 0xc0, ttl 30, id 26946, offset 0, flags [DF], proto UDP (17), length 336)
    10.16.192.1.bootps > 10.16.192.220.bootpc: BOOTP/DHCP, Reply, length 308, hops 1, xid 0x3e9c0b18, Flags [none]
  Client-IP 10.16.192.220
  Your-IP 10.16.192.220
  Gateway-IP 10.16.192.1
  Client-Ethernet-Address 1c:1e:1e:f2:0f:19 (oui Unknown)
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: ACK
    Server-ID Option 54, length 4: cnr306-msk-virt.corbina.net
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.248.0
    BR Option 28, length 4: 255.255.255.255
    Default-Gateway Option 3, length 4: 10.16.192.1
    Domain-Name Option 15, length 7: "beeline"
    Domain-Name-Server Option 6, length 8: hdns1.corbina.net,hdns2.corbina.net
    MTU Option 26, length 2: 576
    Hostname Option 12, length 8: "cityacee"

А можно ли как-то средствами iptables или иным способом заменить обращение к адресу 78.107.63.106 на ширововещательный запрос?
« Последнее редактирование: 04 Февраля 2020, 12:20:41 от CityAceE »
С уважением, Станислав.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #12 : 04 Февраля 2020, 23:40:12 »
А можно ли как-то средствами iptables
У вас iptables головного мозга что ли?… Почему первый вопрос при проблемах с сетью - про iptables?

Просто пропишите маршрут на 78.107.63.106 через нужный интерфейс.

ip route replace 78.107.63.106/32 dev xxx
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

Оффлайн CityAceE

  • Автор темы
  • Активист
  • *
  • Сообщений: 483
  • Ubuntu 18.04 amd64
    • Просмотр профиля
    • Speccy - наш выбор!
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #13 : 05 Февраля 2020, 08:33:58 »
AnrDaemon, спасибо за совет! Опробовал замену, но, к сожалению, этот вариант не сработал. Пытаюсь как-то убедить Билайн настроить своё оборудование должным образом, но пока не очень получается. Основной аргумент: у всех всё работает, а у меня нестандартное оборудование, с которым я должен разбираться сам.

Почему первый вопрос при проблемах с сетью - про iptables?
Потому что чаще всего сетевые проблемы решаются именно с помощью iptables :) К тому же я сразу спросил: "средствами iptables или иным способом". Вот вы как раз и предложили иной способ :)
С уважением, Станислав.

Оффлайн AnrDaemon

  • Заслуженный пользователь
  • Старожил
  • *
  • Сообщений: 28358
    • Просмотр профиля
Re: Рвётся соединение L2TP из-за systemd-networkd
« Ответ #14 : 06 Февраля 2020, 22:12:57 »
этот вариант не сработал
Пакет сейчас отправляется на нужный интерфейс?
Хотите получить помощь? Потрудитесь представить запрошенную информацию в полном объёме.

Прежде чем [Отправить], нажми [Просмотр] и прочти собственное сообщение. Сам-то понял, что написал?…

 

Страница сгенерирована за 0.051 секунд. Запросов: 25.