Wi-CAT LLC

Wireless Comprehensive Advanced Technology. Build your network now.

Wi-CAT LLC
Навигация Форума
Вы должны войти, чтобы создавать сообщения и темы.

(решено) Hardware UDP offload не совместим с kerio vpn дисконнекты

подключен через kerio к сети на работе. несколько раз в день отваливается соединение. с такими логами.

Это у меня соединение не стабильное?

Jul 21 12:45:55 nginx: 2020/07/21 12:45:55 [info] 4444#0: *820 client 192.168.1.13 closed keepalive connection
Jul 21 12:45:55 nginx: 2020/07/21 12:45:55 [info] 4444#0: *821 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:00 kernel: device br0 entered promiscuous mode
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *822 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *823 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *824 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *825 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *826 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:01 nginx: 2020/07/21 12:46:01 [info] 4444#0: *827 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:04 kernel: device br0 left promiscuous mode
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *828 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *831 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *832 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *833 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *829 client 192.168.1.13 closed keepalive connection
Jul 21 12:46:31 nginx: 2020/07/21 12:46:31 [info] 4444#0: *830 client 192.168.1.13 closed keepalive connection

на стороне сервера такие сообщения

21/Jul/2020 12:45:55] VPN client '****' disconnected, connection time 00:42:30
[21/Jul/2020 12:46:27] VPN client '****' connected from 95.66.252.104
[21/Jul/2020 12:46:30] VPN client '****' connected from 95.66.252.104
[21/Jul/2020 12:46:37] VPN client '****' disconnected, connection time 00:00:10

 

Это просто информационные сообщения о завершении подключения, они не связаны с какими-то ошибками. Вот обсуждение на форуме nginx: https://forum.nginx.org/read.php?2,1680,1680

а почему именно в эти моменты у меня подключение по kerio обрывается?

Конечно, если соединение обрывается, то сессии nginx тоже будут отваливаться, но сообщения такие могут появляться и при исправном соединении, так что сами по себе мало о чём говорят. "entered promiscuous mode" может быть связано с переходом на страницу "диагностика сети", в таком случае это тоже нормальное поведение.

Хорошо, а в каком направлении мне тогда копать, чтобы уменьшить обрывы. сегодня у меня 6 раз kerio обрывалось. у жены при таком же подключении, но она сидит ближе к роутеру, обрывов не было судя по логам, т.к. в них только мой ip.

Спойлер
Извините, только авторизованные пользователи могут видеть спойлеры.

  1. используйте вставку code для цитирования логов
  2. у вас какая-то ерунда с фрагментацией твориться, судя по матам dnsmasq ipv6 через тонналь испольузте?

P.S. Конфиги прикладвать полезно + что там за соеидение с керио и какой оно протокол юзает поверьте знают не все. В т.ч. я не в курсе.

Приложил конфиг. Подключение к интернет у меня PPPoE.

Про Kerio - не в курсе особо. у меня рабочий ноутбук, на нем установлен Kerio VPN Client. (ГИП: 8.0.1.609, Служба: 8.0.1 build 609, Драйвер: 7.4.0.4517). Приложил сведения о подключении Kerio.  что еще можно сообщить?

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

За сегодня не было сообщений "client closed keepalive connection" , но в логе теперь много таких сообщений - это критично?

Jul 22 07:19:51 udhcpd[22796]: sending ACK to 192.168.1.54
Jul 22 08:02:43 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:02:43 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-3) from a8:6d:aa:7d:1f:cc, reason=1
Jul 22 08:02:44 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:02:44 udhcpd[22796]: sending ACK to 192.168.1.13
Jul 22 08:03:52 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-10) from a8:6d:aa:7d:1f:cc, reason=1
Jul 22 08:04:00 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=4 to 5GHz AP a8:6d:aa:7d:1f:cc, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:04:00 udhcpd[22796]: sending ACK to 192.168.1.13
Jul 22 08:46:35 kernel: ReASSOC - Assign VHT STA MODE=VHT, MCS=25, BW=80M, AID=5 to 5GHz AP a8:6d:aa:76:cc:e4, WNM supported, PMF connect (WPA2PSK/AES)
Jul 22 08:46:35 udhcpd[22796]: sending ACK to 192.168.1.86
Jul 22 10:01:12 udhcpd[22796]: sending ACK to 192.168.1.93
Jul 22 10:17:06 udhcpd[22796]: sending ACK to 192.168.1.199
Jul 22 10:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:24:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:25:45 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:27:34 udhcpd[22796]: sending ACK to 192.168.1.220
Jul 22 11:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:49:47 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 11:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:24:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 12:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 13:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:03:17 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:04:51 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:34:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:50:29 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:51:43 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 14:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:04:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 15:57:29 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:04:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:44:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 16:54:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280
Jul 22 17:12:54 nginx: 2020/07/22 17:12:54 [info] 4444#0: *1097 Authentication successful: user=Admin , client: 192.168.1.13, server: localhost, request: "POST /goform/auth HTTP/1.1", host: "192.168.1.1", referrer: "http://192.168.1.1/login.asp"
Jul 22 17:14:40 dnsmasq[12804]: reducing DNS packet size for nameserver 95.66.188.11 to 1280

 

Извините за назойливость. просмотрел логи Kerio с ошибками,  c 17.07 когда поставил роутер появилось больше ошибок, до этого был Keenetic, ошибки были, но не так часто. что мне можно настроить для более стабильного соединения.

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Обратитесь в ТП керио, я по их логам не понимаю что именно ему не нравиться и кто виноват. И врятли роутер. Вижу что он долбится до DNS и регулярно не может что-то отрезолвить.

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

Но судя по логам с роутера керио генерит кривые запросы к DNS и dnsmasq в роутере их дропает.

В любом случае это вопрос к керио, а не к нам.

Т.е. keenetic'y нравились запросы kerio, а вашему перестали нравится. с такого провайдера не я один сижу, у других пользователей обрывов не бывает. к kerio подключены около 100 пользователей с разных провайдеров, а обрывы стабильные только у меня после смены роутера.

Запросто. А ещё запросто так же завтра кинетику перестанут нравиться эти запросы т.к. обновят например DNSMASQ и получат ту же валидацию.

Оно не просто так ругается именно на kerio и ни на что больше. Так что завтра проблему могут получить все у кого сейчас всё нормально, просто по мере обновления dnsmasq другими вендорами.

Точнее тут даже не так.

Судя по:

reducing DNS packet size for nameserver 95.66.188.11 to 1280

На стороне этого сервера проблемы с фрагментацией пакетов (режим медиума ON) поэтому встроенный у нас DNSMASQ после кучи попыток уменьшает размер пакета до 1280 и тогда что-то проходит.

Это на правах куцих логов проприретарщины от керио и сопоставление с руганью dnsmasq в логе роутера.

И разбираться тут надо не на стороне роутера. Хотя можно и на стороне роутера накостылить попробовав уменьшив MTU. Но судя по ругани только на этот сервер проблема на его стороне. В керио или ещё в чём я ХЗ. Может на транзите где-то.

Это всё сильно выходит за рамки ТП роутера (разборы со сторонними сервисами).

95.66.188.11, я так понимаю, это dns сервер провайдера, попробую им написать. 

мои знания не позволяют вести с вами разговор на одном уровне. сегодня было всего 2 разрыва связи, с этим можно жить.

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Сделайте следующее, в настройках VPN уменьшите MTU до 1280 или чуть ниже. Возможно проблема вообще не в DNS и не в kerio а в настройках браса провайдера. Я правда уже лет 10ть не видел что бы брас отдавал неверное значение MTU при подъёме PPPOE. Но чую вот что-то где-то оно тут зарыто. Потому часть запросов жирных к DNS от kerio по просту не пролазиет.

Надеюсь это не DSL ? А то там потери наплывами могут быть из-за ошибок на DSL интерфейсе. Даже от дождика в итоге будет зависеть сколько их и проблемы абсолютно непредсказуемо могут возникать.

А что бы говорить со мной на одном языке достаточно предоставлять всю инфу от того кто провайдер, как именно подключены и т.д. и т.п.

В данном случае по сути играем в угадайку. Керио ругается что не может отрезолвить адреса какие-то, dnsmasq ругается что ему пришлось ограничить размер пакетов в сторону одного из серверов.

Не ну можно в настройках DNS в Upstream DNS Servers забить например гугловские 8.8.8.8 и 8.8.4.4 и посмотреть что будет. Если глючит один из провайдерских DNS проблема тоже уйдёт.

Однако остаётся таки вариант, что это керио что-то левое формирует такое что dnsmasq или провайдерский dns сервер переварить не может. Вот тоже запросто.

В любом случае тут дебаг должен быть не на стороне роутера, у него всё хорошо, а на стороне провайдера или kerio и разбираться что происходит. Я тут кроме как карты раскинуть (см выше) предложить особо ничего не смогу.

Сидеть дебажить керио или вместо спецов вашего провайдера разбирать дампы обращений к их DNS в моменте затыка, ну наверное всё же не моя работа.

Провайдер местный, Район называется. не думаю, что это как-то поможет. В поддержке провайдера сказали не обращать внимание на такие сообщения. в настройках dns вбил гугловские сервера. сообщения не пропали

Jul 25 17:06:24 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 17:52:58 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 18:22:58 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 19:23:04 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=3 to 5GHz AP 00:0a:f5:44:6f:6c, WNM supported (WPA2PSK/AES)
Jul 25 19:23:05 udhcpd[2997]: sending OFFER to 192.168.1.54
Jul 25 19:23:05 udhcpd[2997]: sending ACK to 192.168.1.54
Jul 25 19:44:08 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:02:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:12:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 20:39:31 udhcpd[2997]: sending ACK to 192.168.1.93
Jul 25 21:02:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:08:17 udhcpd[2997]: sending ACK to 192.168.1.220
Jul 25 21:09:08 udhcpd[2997]: sending ACK to 192.168.1.13
Jul 25 21:16:20 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:42:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 21:52:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 22:22:57 dnsmasq[3497]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Jul 25 23:20:42 kernel: 5GHz AP AUTH - receive DE-AUTH(seq-50) from a8:6d:aa:7d:1f:cc, reason=1

Уменьшил mtu до 1280. разрывы с kerio каждые 10-15 минут стали. в 12-06 установил этот параметр.

Jul 26 12:06:56 dnsserver: Starting DNSMASQ.
Jul 26 12:06:56 adblock: Next adblock update after 24h.
Jul 26 12:06:56 dnsmasq[6718]: started, version 2.81 cachesize 4096
Jul 26 12:06:56 dnsmasq[6718]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN no-DHCP no-scripts no-TFTP no-conntrack no-ipset no-auth DNSSEC loop-detect inotify no-dumpfile
Jul 26 12:06:56 dnsmasq[6718]: warning: ignoring resolv-file flag because no-resolv is set
Jul 26 12:06:56 dnsmasq[6718]: using nameserver 8.8.4.4#53
Jul 26 12:06:56 dnsmasq[6718]: using nameserver 8.8.8.8#53
Jul 26 12:06:56 dnsmasq[6718]: read /etc/hosts - 5 addresses
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *29 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *30 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *31 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *32 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *34 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:06 nginx: 2020/07/26 12:07:06 [info] 4707#0: *33 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:12 nginx: 2020/07/26 12:07:12 [info] 4707#0: *35 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *36 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *37 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *38 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *39 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *40 client 192.168.1.13 closed keepalive connection
Jul 26 12:07:49 nginx: 2020/07/26 12:07:49 [info] 4707#0: *41 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *42 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *43 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *44 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *45 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *46 client 192.168.1.13 closed keepalive connection
Jul 26 12:10:44 nginx: 2020/07/26 12:10:44 [info] 4707#0: *47 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *48 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *49 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *50 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *52 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *51 client 192.168.1.13 closed keepalive connection
Jul 26 12:14:32 nginx: 2020/07/26 12:14:32 [info] 4707#0: *53 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *60 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *61 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *62 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *63 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *64 client 192.168.1.13 closed keepalive connection
Jul 26 12:28:22 nginx: 2020/07/26 12:28:22 [info] 4707#0: *65 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *66 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *71 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *70 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *67 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *68 client 192.168.1.13 closed keepalive connection
Jul 26 12:33:42 nginx: 2020/07/26 12:33:42 [info] 4707#0: *69 client 192.168.1.13 closed keepalive connection
Jul 26 12:45:38 nginx: 2020/07/26 12:45:38 [info] 4707#0: *76 client 192.168.1.13 closed keepalive connection
Jul 26 12:45:45 nginx: 2020/07/26 12:45:45 [info] 4707#0: *78 client 192.168.1.13 closed keepalive connection

какой то замкнутый круг получился. попробую еще наших IT поспрашивать про настройки kerio.

Уменьшил mtu до 1280. разрывы с kerio каждые 10-15 минут стали. в 12-06 установил этот параметр.

Однако ругань из логов пропала. Т.е. таки какие-то проблемы с MTU имеют место быть.

какой то замкнутый круг получился. попробую еще наших IT поспрашивать про настройки kerio.

Как последняя мысль. Если керио впн использует UDP то возможно тот редкий случай когда себя проявила древняя болячка PPE. Увы полноценно она не лечиться, правда и вариант наступить на неё один на миллион.

В качестве проверки догадки можно в Services->Miscellaneous->NAT offload mode выставить в Hardware (для PPPOE/IPOE софт оффлоад бесполезен практически всё равно). Там же UDP hardware nat offload в disable.

Если я прально помню у кинетиков UDP оффлоад по дефолту вырублен.

Ну и крайне рекомендую взять (win)mtr  и натравить его на адрес сервера kerio и dns сервера и пусть он щёлкает. После отвала глянуть не было ли потерь. Сразу до кучи будет видно где потери.

Ругань та же самая до гугловских DNS (и отсутствие оной при уменьшении MTU туннеля руками) прямой и жирный намёк на таки проблемы с MTU у провайдера. По нормальному MTU/MRU для PPPOE равен 1492 т.к. 8 байт уходит на инкапсуляцию в PPPOE. Если используется другое значение на стороне браса то брас его должен корректно отдать в LCP на стадии подключения. Иначе придётся задавать руками.

Другое дело, что это могут быть и не связанные между собой проблемы.

Цитата: sfstudio от 26/07/2020, 16:33

В качестве проверки догадки можно в Services->Miscellaneous->NAT offload mode выставить в Hardware (для PPPOE/IPOE софт оффлоад бесполезен практически всё равно). Там же UDP hardware nat offload в disable.

Если я прально помню у кинетиков UDP оффлоад по дефолту вырублен.

после этих настроек разрывов kerio два дня вообще не было. огромное спасибо.

в логах роутера всё теже сообщения остались, но обрывы пропали.

  1. раз в логах есть записи то стоит таки уменьшить mtu, т.е. у вас 2 проблемы в итоге. Не ну можете и так жить если ретрансмиты жирных пакетов и лишние задержки не напрягают.
  2. теперь по правильному стоит написать товарищам из kerio что их vpn работающий по UDP триггерит аппаратную проблему в блоке оффлоада и у всех Ralink/MTK. А т.к. на большинстве роутеров его отлючить не реально (особенно отдельно оффлоад UDP) то было бы не плохо если бы они пофиксили это дело на своей стороне.

Крайне рекомендую выполнить оба пункта. Т.к. первый ведёт к подземным стукам, второй  к необходимости отключения UDP offload т.е. заметным увеличением нагрузки на cpu роутера при использовании например торрентов с uTP да и производительность UDP туннелей так же будет ограничена CPU роутера т.к. такой трафик будет обрабатываться полностью программно.

Благо керио vpn единственная бяка на которой на текущий момент проблема всё ещё повторяется (ну как выяснилось), остальные из встреченных мной и зарепорченных пофиксили на своей стороне.

С нашей стороны поправить тут увы особо не чего, ибо проблема в реализации самого PPE в железной логике, не в софте. ;(

Уменьшил mtu до 1200, а в логах сообщения так и остались. или я не там уменьшил?

Jul 29 20:45:40 dnsmasq[14267]: reducing DNS packet size for nameserver 8.8.8.8 to 1280

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Странный коро у вас провайдер, что-то он по пути с пакетами такое делает. Для PPPOE выставьте 1492 от греха по дальше и пусть живёт раз проблем нет. Надо глубже разбираться чего там провайдер творит что dnsmasq ругается раз не в MTU дело... Хотя странно.

Месяц назад перешёл с ME1 на DUO-G и сейчас заглянув в лог также увидел сообщения от dnsmasq. MTU уже лет 5 как зафиксировано в 1500(IPoE, InterZet). Просто на всякий случай сообщаю. Потом ещё у товарища гляну.

Я записал в туду глянуть эту логику в dnsmasq, возможно что-то там поменялось и оно стало срабатывать когда не надо, или же наоборот стало срабатывать когда надо. =)

В любом случае автору оного виднее.

Цитата: sfstudio от 26/07/2020, 16:33

Ну и крайне рекомендую взять (win)mtr  и натравить его на адрес сервера kerio и dns сервера и пусть он щёлкает. После отвала глянуть не было ли потерь. Сразу до кучи будет видно где потери.

Не знаю правильно ли сделал. в Host прописал 8.8.8.8 , т.к. у меня сейчас dns гугла в настройках роутера. получил такую картину. я, честно говоря, не знаю как ее понимать, потери 24% и 56%, как я понял, это сервера гугла. в логах роутера в это время так было.

Aug  1 16:28:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 16:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *349 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *350 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *351 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *352 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *353 client 192.168.1.13 closed keepalive connection
Aug  1 16:48:11 nginx: 2020/08/01 16:48:11 [info] 4707#0: *354 client 192.168.1.13 closed keepalive connection
Aug  1 17:08:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 17:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 17:52:06 kernel: 5GHz AP ageout 00:0a:f5:44:6f:6c after 480-sec silence
Aug  1 18:46:10 kernel: ASSOC - Assign HT STA MODE=HTMIX, MCS=7, BW=40M, AID=3 to 5GHz AP 00:0a:f5:44:6f:6c, WNM supported (WPA2PSK/AES)
Aug  1 18:46:11 udhcpd[9334]: sending OFFER to 192.168.1.54
Aug  1 18:46:11 udhcpd[9334]: sending ACK to 192.168.1.54
Aug  1 19:18:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 19:28:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *357 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *360 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *355 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *356 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *359 client 192.168.1.13 closed keepalive connection
Aug  1 19:28:48 nginx: 2020/08/01 19:28:48 [info] 4707#0: *358 client 192.168.1.13 closed keepalive connection
Aug  1 20:14:48 udhcpd[9334]: sending ACK to 192.168.1.199
Aug  1 20:18:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 20:38:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 20:54:41 udhcpd[9334]: sending ACK to 192.168.1.13
Aug  1 21:08:08 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:10:51 udhcpd[9334]: sending ACK to 192.168.1.220
Aug  1 21:25:58 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:38:09 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280
Aug  1 21:57:42 udhcpd[9334]: sending ACK to 192.168.1.93
Aug  1 21:58:09 dnsmasq[15754]: reducing DNS packet size for nameserver 8.8.8.8 to 1280

 

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

С такми потерями будет Ж... И это мелкими пакетами. Ругань ДНС маскарада понятна.

Почитайте как читать репорты MTR например тут и до своего VPN сервера проверьте. Потери >5% это не норма. В идеале их быть вообще не должно тем более на мелких пакетах.

Сделал до VPN сервера. На работе интернет от такого-же провайдера, что и у меня дома, поэтому всё внутри сети провайдера проходит, как я понял.

а по поводу вчерашней картинки с потерями - это мне к поддержке провайдера обращаться?

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Это за какой интервал времени? Потери <=1% как бы не криминал. Однако вижу что теряются прям до роутера в т.ч. Кабель отходит? Помехи? Т.е. вот это место бы я бы проверил.

Иногда (на например сетёвках от RTL) при включенных в настройках их драйверов оффлоадах время от времени лезут потери. Жить обычно не мешает т.к. процент потерь несущественный, но кого напрягает отключают оффлоады в настройках драйверов.

Как бы какого-то прям криминала тут нет.

Для полноты картинки неплохо бы сделать обратную трассировку с VPN сервера до вас таким же макаром и посмотреть что будет.

Цитата: sfstudio от 02/08/2020, 14:47

Это за какой интервал времени? Потери <=1% как бы не криминал. Однако вижу что теряются прям до роутера в т.ч. Кабель отходит? Помехи? Т.е. вот это место бы я бы проверил.

Т.к. опрос раз в секунду идет, то значит 1ч 40мин примерно. но я с ноута по wi-fi, качество сигнала далеко от 100%, может из-за этого потери до роутера?

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Ну тады точно криминала не вижу.

я ping'ом прогнал 8.8.8.8, отобразилось 0% потерь. почему winmtr так много потерь показывало? или это разные вещи?

Загруженные файлы:
  • Вам нужно войти, чтобы просматривать прикрепленные файлы..

Ну вообще да и вещи разные и даже разные протоколы могут быть использованы для пинга и трассировки. Что конкретно у WINmtr по дефолту настроено я фиг знает, винды нет под рукой.

По ругани dnsmasq глянул (заодно обновил до текущего стэйбла), оно терь таким образом будет ругаться на любые потери пакетов до DNS. Т.е. как бы не смертельно (ну сделает резолв ещё раз), но вообще потери до ключевых сервисов нужных для функционирования сети эт не гуд.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: