Не стабильное подключение VPN

[dormidont3]

У меня проблема с VPN подключением. Связь пропадает с завидной регулярностью. При чем если зайти в веб-интерфейс то пишет, что pptp соединение установлено, но при этом ни одна страница не открывается и 100% пакетов при пинге потеряно. Стоит только перезапустить подключение и всё становится отлично до поры до времени.

Попытался найти логи подключения, но не понял, где они лежат...

[dormidont3]

Проблема до сих пор актуальна, особенно активна в последние дни, по этому прошу помощи снова... Симптомы те же. Переподключать приходжится чуть ли не каждые полчаса.

Звонил провайдеру. В момент когда у меня пинги не уходят ни куда с сервера я пингуюсь вполне себе отлично, без потерь. То есть вход есть, а вот выйти я никуда не могу.
перезагрузил сервак, потом посмотрел /var/log/messages

Код: [Выделить]

Dec 23 10:41:30 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: signer "ddns-key" denied
Dec 23 10:41:30 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: update 'localdomain/IN' denied
Dec 23 10:41:30 server58 dhcpd: DHCPREQUEST for 192.168.1.100 from 70:72:0d:bc:80:dd (android-b42484bc6b7af4f8) via enp1s1
Dec 23 10:41:30 server58 dhcpd: DHCPACK on 192.168.1.100 to 70:72:0d:bc:80:dd (android-b42484bc6b7af4f8) via enp1s1
Dec 23 10:41:30 server58 dhcpd: Unable to add forward map from android-b42484bc6b7af4f8.localdomain to 192.168.1.100: REFUSED
Dec 23 10:41:31 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: signer "ddns-key" denied
Dec 23 10:41:31 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: update 'localdomain/IN' denied
Dec 23 10:41:31 server58 dhcpd: DHCPREQUEST for 192.168.1.228 from 64:27:37:30:c2:60 (Hostname Unsuitable for Printing) via enp1s1
Dec 23 10:41:31 server58 dhcpd: DHCPACK on 192.168.1.228 to 64:27:37:30:c2:60 (Hostname Unsuitable for Printing) via enp1s1
Dec 23 10:41:31 server58 dhcpd: Unable to add forward map from \214\201\216\223\221\216\23058-\217\212.localdomain to 192.168.1.228: REFUSED


[dormidont3]

Как только пропадает связь начинается вот такая беда

/var/log/messages

Код: [Выделить]

Dec 23 10:00:00 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 17749 (expecting 15516)и таких строк по несколько пара десятков в секунду дописывается

[asy]

Как-то всё это странно. Если icmp echo снаружи ходит, нет причин, чтобы не ходило изнутри. echo request и reply имеют разные типы и их можно фильтровать по-разному, но сомневаюсь, что дело в этом.

Началу проблем всегда предшествует dhcp-активность ?

[dormidont3]

Очень сложно отследить, но вот нашел момент начала

Код: [Выделить]

Dec 23 09:57:43 server58 dhcpd: DHCPACK on 192.168.1.154 to b0:45:19:13:85:4c (android-aca300e21e4f8e81) via enp1s1
Dec 23 09:57:43 server58 dhcpd: Unable to add forward map from android-aca300e21e4f8e81.localdomain to 192.168.1.154: REFUSED
Dec 23 09:57:46 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: signer "ddns-key" denied
Dec 23 09:57:46 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: update 'localdomain/IN' denied
Dec 23 09:57:46 server58 dhcpd: DHCPREQUEST for 192.168.1.155 (192.168.1.1) from 3c:df:bd:44:b4:21 (android-fba8a3775216359b) via enp1s1
Dec 23 09:57:46 server58 dhcpd: DHCPACK on 192.168.1.155 to 3c:df:bd:44:b4:21 (android-fba8a3775216359b) via enp1s1
Dec 23 09:57:46 server58 dhcpd: Unable to add forward map from android-fba8a3775216359b.localdomain to 192.168.1.155: REFUSED
Dec 23 09:57:48 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: signer "ddns-key" denied
Dec 23 09:57:48 server58 named[5233]: client 127.0.0.1#58750/key ddns-key: update 'localdomain/IN' denied
Dec 23 09:57:48 server58 dhcpd: DHCPREQUEST for 192.168.1.154 from b0:45:19:13:85:4c (android-aca300e21e4f8e81) via enp1s1
Dec 23 09:57:48 server58 dhcpd: DHCPACK on 192.168.1.154 to b0:45:19:13:85:4c (android-aca300e21e4f8e81) via enp1s1
Dec 23 09:57:48 server58 dhcpd: Unable to add forward map from android-aca300e21e4f8e81.localdomain to 192.168.1.154: REFUSED
Dec 23 09:57:50 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 434525 (expecting 434524, lost or reordered)
Dec 23 09:57:50 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 434843 (expecting 434842, lost or reordered)
Dec 23 09:57:50 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 434845 (expecting 434844, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437035 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437036 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437037 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437038 (expecting 437021, lost or reordered)

Если нужно, могу больший кусок захватить

[dormidont3]

Вот, нашел ещё оин кусок в логах. Вид ошибки периодически меняется

Код: [Выделить]

Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437309 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437310 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437311 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437312 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437313 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437314 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437315 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437316 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437317 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437318 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 437319 (expecting 437021, lost or reordered)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437320 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437321 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437322 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437323 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437324 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437325 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437326 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437327 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437328 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437329 (expecting 437021)
Dec 23 09:57:51 server58 pptp[10358]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 437330 (expecting 437021)

[asy]

Если нужно, могу больший кусок захватить

На месте проще анализировать. Как-то так предполагается, что выделяется непонятное, а не "вот всё, вообще ничего не знаю". Сравнивать до, искать что-то общее, когда проблема возникает.

Что, вообще, проверялось в момент наличия проблемы, кроме попыток что-то попингать ? Снаружи и изнутри ? Скажем, посмотреть tcpdump-ом, уходят ли пакеты, и через какой интерфейс. Таблицы маршрутизации, какой-нибудь полиси роутинг... Нормального объяснения в разнице в поведении icmp echo снаружи и изнутри нет. Каналов подключения сколько ? Один, или больше ?

[asy]

Это из man pptp:

Код: [Выделить]

       --timeout <secs>
              Time to wait for reordered packets (0.01 to 10 secs)
Можно попробовать поставить побольше. Ещё можно включить keepalive (это из pppd уже). Это если связать проблему именно с pppd/pptp

То есть, это поиск уже по второму направлению, отличному от разбора проблемы с icmp echo. Может быть, с этой стороны дойти быстрее выйдет.

[dormidont3]

А не подскажете, как это все сделать?

[dormidont3]

Если нужно, могу больший кусок захватить

На месте проще анализировать. Как-то так предполагается, что выделяется непонятное, а не "вот всё, вообще ничего не знаю". Сравнивать до, искать что-то общее, когда проблема возникает.

Что, вообще, проверялось в момент наличия проблемы, кроме попыток что-то попингать ? Снаружи и изнутри ? Скажем, посмотреть tcpdump-ом, уходят ли пакеты, и через какой интерфейс. Таблицы маршрутизации, какой-нибудь полиси роутинг... Нормального объяснения в разнице в поведении icmp echo снаружи и изнутри нет. Каналов подключения сколько ? Один, или больше ?

Запускал mtr с рабочей станции. Пакеты встали на сервере и дальше не пошли. Пробовал traserout то же самое. Смотрел ifconfig ip на сетевой прописан внешний, так что он от провайдера получен и на месте. Что сделать ещё я не знаю...

[asy]

А не подскажете, как это все сделать?

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

Попробовать с параметрами pppd/pptp - я не знаю, как и где это настроено. Сейчас существует более одного варианта настройки. В любом случае, надо смотреть, как и откуда запускается pppd, и откуда задаются опции.

[dormidont3]

Заметил такую закономерность. Вечером связь нормальная, проблемы только днем, когда много народу подключено к сети. Щас вот уже часа 2 спокойно работаю, ни одного обрыва, а днем мрак какой то.

Ну и до кучи. Проблемы начались когда провайдер изменил тариф и вместо 16mb/s стало 40...

Может есть связь?

[yaleks]

http://forum.altlinux.org/index.php/topic,1948.15.html

[asy]

Может есть связь?

Можно нафантазировать такой вариант: в какие-то моменты у провайдера забивается какой-то внешний канал. В результате растут задержки в прохождении пакетов. При этом, из той точки, откуда работает pptp-клиент, пакеты идут попеременно разными каналами, в итоге получается то самое lost or reordered. Значит, на удачу, можно начать копать в сторону опции --timeout.

Что касается пинга, вероятно, в pptp-тонель уходит маршрут по-умолчанию, а в системе настроен какой-то полиси-роутинг, который обеспечивает хождение pptp-трафика мимо тонеля. Что, в общем-то, правильно.

[dormidont3]

Почитал похожу ветку... Плюнул и купил роутер за 400р. Если верить гуглу я далеко не один такой и вариантов борьбы с этим я так и не нашел... Какая то беда с pptp в линуксе...