CIS рвет VPN соединение при не активности серфи

International Comodo Forums По-русск
#1

CIS 5.8 и предыдущие версии, рвет соединение VPN через 5 минут и больше если не какая программа не использует интернет ( установлена Windows 7 x64). Если отключить фаервол, то соединение держится.
Что то блокируется, а что не пойму, ставил уже и логировать что блочится, ничего такого криминального там не увидел.
Приведу ниже свои правила, гляньте пожалуйста может что то лишнее, или наоборот не хватает.

http://i062.radikal.ru/1110/4a/b8918dad1b2dt.jpg


http://s017.radikal.ru/i420/1110/5f/a7e22a683d10t.jpg

5 и 6 правило в глобальных, это для торрента.

Установил уже Microsoft Network Monitor для проверки протокола, и при включенном фаерволе мне не нравются некоторые строчки в показаниях, они постоянны и очень часты, при отключенном фаерволе таких ошибок не наблюдается.
В самом конце на картинке произошел разрыв.

http://s017.radikal.ru/i416/1110/36/cbd04f4c739dt.jpg

Вот некоторые подозрительные строчки из протокола.

10.48.15.50 10.9.0.203 TCP TCP:[SynReTransmit #6834]Flags=…S., SrcPort=50398, DstPort=HTTP(80), PayloadLen=0, Seq=1801156756, Ack=0, Win=8192 ( Negotiating scale factor 0x2 ) = 8192 {TCP:115, IPv4:101, IPv4:1}
10.9.0.203 10.48.15.50 TCP TCP:[ReTransmit #7727]Flags=…AP…, SrcPort=HTTP(80), DstPort=50411, PayloadLen=158, Seq=2704516610 - 2704516768, Ack=2892052556, Win=74 (scale factor 0x9) = 37888 {TCP:144, IPv4:138, IPv4:1}
10.48.15.50 10.9.0.203 TCP TCP:[Dup Ack #7748]Flags=…A…, SrcPort=50411, DstPort=HTTP(80), PayloadLen=0, Seq=2892052556, Ack=2704516768, Win=16581 (scale factor 0x2) = 66324 {TCP:144, IPv4:138, IPv4:1}

10.9.0.203 10.48.15.50 TCP TCP:[Continuation to #11876]Flags=…A…, SrcPort=40110, DstPort=49858, PayloadLen=1360, Seq=1217813527 - 1217814887, Ack=2143794696, Win=195 {TCP:7, IPv4:6, IPv4:1}
10.9.0.203 10.48.15.50 TCP TCP:[Continuation to #11876]Flags=…A…, SrcPort=40110, DstPort=49858, PayloadLen=1360, Seq=1217814887 - 1217816247, Ack=2143794696, Win=195 {TCP:7, IPv4:6, IPv4:1}

10.48.15.50 10.9.0.203 TCP TCP:[Request Fast-Retransmit from Seq1217811483]Flags=…A…, SrcPort=49858, DstPort=40110, PayloadLen=0, Seq=2143794696, Ack=1217811483, Win=16379 {TCP:7, IPv4:6, IPv4:1}
10.48.15.50 10.9.0.203 TCP TCP:[Request Fast-Retransmit from Seq1217811483]Flags=…A…, SrcPort=49858, DstPort=40110, PayloadLen=0, Seq=2143794696, Ack=1217811483, Win=16379 {TCP:7, IPv4:6, IPv4:1}

10.48.15.50 - адрес сетевой карты, т.е. локальный.
10.9.0.2XX - адрес провайдера.

#2

Если В Файервол-Настройки файервола-Расширенные
[х] Блокировать фрагментированные IP датаграмы
[х] Анализировать протокол
включены, то выключите. Выключите там все и попробуйте.
Разорвать соединение через х минут если ни какая программа не использует интернет есть и в настройках системы, и может в настройках какой нибудь программы есть что то типа “разорвать соединение при неактивности в течение х минут”. Это не вяжется с “если отключить фаервол, то соединение держится”, но посмотрите на всякий случай.
P.S. И в глобальных входящие GRE от VPN разрешите. И логи для System посмотрите. В принципе раньше с VPN были у Comodo проблемы, но сейчас вроде бы как он и сам с ним прекрасно разбирается.

#3

zil968: Все галки в дополнительных опциях отключены. Фаервол и проактивка в безопасном режиме, песочница отключена. На Комодо со 2 или 3 версии еще сижу, и такое только с 5 версии вроде у меня началось.
В логах ничего нет по system, кроме IGMP на 224.0.0.52, но они не нужны, да и вообще лог чистый, пробывал уже все логировать что только в блок стоит, так в логе блокировка в 99% по WOS только идет.

В глобальных, а также в system, исправил на разрешение входящих и исходящих IP на 47 протокол.

Куда дальше копать не знаю. Разрыв в основном идет через 5-10 минут, а может и намного больше, и только если никто не дергает соединение, под нагрузкой все железно сутками работает.

#4

Если подключение через роутер можно посмотреть его настройки. Там тоже есть такое “как сбрасывать при неактивности”. Ну и “костыли” в виде ping через каждые 5 минут на планировщике попробовать можно. Хотя это не интересно и проблему желательно решить в корне и без костылей.
P.S. Впрочем какой там роутер.
Попробуйте открыть с логированием все входящие ICMP. Или даже не так. Попробуйте просто открыть все входящие - поможет или нет, т.е. посмотреть это тоже самое что и отключение файервола или нет.

#5

Solteks, очень может быть, что для VPN’а многое идёт как для WOS, а не только как для System.
Галку для “этот компьютер - интернет шлюз” Вы не пробовали туда-сюда? С размерами окна для VPN-адаптера не может это быть связано? Ещё перед отрывом идёт безответный ARP про 113-й адрес, это случайность в данном случае?

#6

Может WOS вообще выкинуть как думаете?, там блочится очень прилично входящих, но абсолютно левых адресов никак не связанных с моим провайдером.

Галки шлюза не стоит, размер в Семерке вроде автоматически подстраивается, но в сетевухе 1514 стоит.
Про ARP это просто последний кусок. По команде tracert 10.9.0.210 идет на сервак провайдера 10.48.15.1, мой соответственно 10.48.15.50. И я не пойму зачем он время от времени почти всю сетку 10.48.15.ХХХ начинает опрашивать.

#7

В смысле запрещающее правило для WOS? Я думаю, что стоит копнуть отсюда, разрешить всё для WOS и посмотреть за изменениями. Ну а потом уже подогнать как надо. По крайней мере разрешить всё локальное и “локальное”.

Это, видимо, MTU, а я имею в виду Window Size. Много скейлов в логе, хотя это просто гипотеза для уверенности.

В смысле ARP? Ну он так работает, время от времени обновляет свою таблицу.

P.S. И вот ещё, обратите внимание что рвёт соединение не CIS, а его закрывает именно сервер, причём закрывает “вежливо”. А перед этим от него идёт несколько echo-реквестов, но без соотв. ответов. И начинается закрытие сеанса вовсе не с VPN/PPTP, а с обычного LCP. Может быть у Вас вся проблема в неответе на ECHO серверу?

#8

Что то я в тупик зашел совсем, не понимаю уже как правила обрабатываются. Исправил как на скринах ниже, только в System еще не добавлял входящие и исходящие IP в локалке, так смотрю по протоколу он так весело побежал( и ICMP и много чего еще появилось), после этого дай думаю удалю разрешающие IP для локалки из глобальных тоже( это 3 и 4 правило), после этого протокол полупустой как и обычно стал и рвет.

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

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

Вот измененные правила, может опять что то не так:


http://s52.radikal.ru/i136/1110/6b/50e47e0afb0bt.jpg


http://s42.radikal.ru/i096/1110/a4/13387423e797t.jpg

А это полный протокол, от начала коннекта до разрыва.

http://s12.radikal.ru/i185/1110/36/cf7e7b4ff708t.jpg

Зашел вот на этот сайт: http://www.speedguide.net/analyzer.php он по анализу соединения, пишет не оптимизированное MTU и MSS, как на Windows 7 менять размер окна так и не понял, оно автоматическое вроде. Скачал ихнюю программу TCPOptimizer, но ничего не поменялось в плане этих параметров.

Вот показания:
MTU = 1400
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
MSS = 1360
MSS is not optimized for broadband. Consider increasing your MTU value.
Default TCP Receive Window (RWIN) = 66640
RWIN Scaling (RFC1323) = 2 bits (scale factor: 2^2=4)
Unscaled TCP Receive Window = 16660

RWIN is not fully optimized (even though it is a comparatively large number). The unscaled RWIN value is lower than it should be. Also, RWIN being close to and above 65535 does not justify the header overhead of enabling TCP 1323 Options. You might want to use one of the recommended RWIN values below.

RWIN is a multiple of MSS
Other RWIN values that might work well with your current MTU/MSS:
65280 (up to 2 Mbit lines, depending on latency. MSS * 48)
130560 (1-5 Mbit lines, depending on latency. MSS * 48 * 2)
261120 (2-14 Mbit lines, depending on latency. MSS * 48 * 2^2)
522240 (8-30 Mbit lines, depending on latency. MSS * 48 * 2^3)
1044480 (25-60 Mbit lines depending on latency. MSS * 48 * 2^4)

#9

Solteks, вот смотрите, как интересно получается. на 44-й секунде от сервера (кстати, у него что, каждый раз новый IP ???) приходит echo-запрос и на него тут же уходит echo-ответ, а дальше, на 104-й, на 134-й, 164-й, 194-й и на 224-й, т.е. через каждые 30 сек. эхи приходят, но ответов на них уже почему-то нет. и сервер с “чистой” совестью закрывает соединение. Хотя через туннель стабильно идёт, раз в минуту, пара echo-запрос-ответ. Т.е. тут, с одной стороны, какая-то странность у сервера, чего ему рвать основной линк, если туннель - живой? С другой стороны непонятно, что произошло с echo-ответами начиная со второй минуты. Попробуйте включить логирование всего обмена с сервером, надо же понять, что с этим несчастным эхом происходит, я так думаю… Того, что Вы разрешили обмен по ICMP мало, там же LCP-шный ECHO. По-моему проще вообще посмотреть вайршарком, что там происходит. И ещё не ясно, какие у Вас сейчас правила для WOS. MTU, пожалуй, стоит чуть увеличить, галка “блокировать фрагментированное…” у Вас сейчас выключена, так?

#10

ntoskrnl: 10.9.0.213 это ВПН сервер ( каждый раз новый при подключении, их 11 штук), 10.48.15.50 мой, а 10.48.15.1 -Default gateway.

Позвонил провайдеру с жалобой ;D, он выдал на тест роутер Длинк-615, подключили с теми же правилами что в предыдущем сообщении, ничего не рвется и протокол совсем другой, идут одни ICMP и ARP и частый опрос, в моем же случае( у меня встроенная сетевая Marwell 88E8053) там и ТСП и УДП и много чего еще в неактивном состоянии и эхо ответов нет ???

В реестре смотрел МТУ 1500 вписано, винда сама видать подстраивает на 1400 ???
Все галки в фаерволе в дополнительных опциях отключены, в общем там все отключено.
А правила для WOS в предыдущем сообщении на втором скрине снизу они.

Попробую теперь еще wireshark посмотреть.

#11

Не совсем понятно: правила вроде как для WOS, а имя приложения - “Системные приложения Windows”? :slight_smile:

#12

Да ошибка с WOS вышла, исправил как положено, но ничего не изменилось.

Как обычно в протоколе идет последнее LCP и на этом разрыв. В глобальных для локалки и VPN сервера уже разрешил любые ICMP и все IP, толку никакого, что еще ему нужно то. ???, уже и разрешать то больше нечего вроде.