Назад | Перейти на главную страницу

PPTP VPN-соединения перестают работать по прошествии определенного периода времени

У меня есть клиент с сервером SBS 2011, который действует как сервер PPTP VPN, которому трудно поддерживать рабочие VPN-подключения к своему серверу для удаленных сотрудников.

Клиентские машины могут успешно подключаться к VPN и получать доступ к сетевым ресурсам, но через некоторое время кажется, что VPN игнорирует пакеты, поступающие через VPN. Кажется, что VPN-соединение установлено со стороны клиента, но доступ к сетевым ресурсам невозможен, включая серверы проверки связи и т. Д.

Время до остановки соединения не фиксировано. У меня соединения оставались работоспособными в течение ~ 40 часов и выходили из строя через такой короткий промежуток времени, как ~ 10 минут. Я не верю, что это проблема тайм-аута соединения на сервере или маршрутизаторах, поскольку сбой происходит, даже если я неоднократно пингую сервер на другом конце соединения или повторно запрашиваю веб-страницу через VPN.

Wireshark

Если после сбоя VPN я смотрю на сетевой трафик на сервере с помощью Wireshark, я вижу, что канал управления TCP-портом 1723 все еще открыт, а эхо-запросы / ответы происходят примерно каждую минуту.

Пакеты GRE принимаются сервером от клиента, но сервер не отвечает на них. Например, если я пингую сервер через VPN, я вижу, что инкапсулированный GRE эхо-запрос ICMP поступает на сервер, но эхо-ответ не отправляется.

Регистрация RRAS

Я включил ведение журнала в RRAS на сервере SBS. Я вижу несколько вещей в журналах, которые показывают, что сервер удалил маршрут к клиенту, но я не могу понять, почему. Вот выдержка из IPRouterManager.LOG:

[16724] 15:30:24: OnRouteChange: Route Deletion Notification
[16724] 15:30:24: INFO: Converted interface Luid 0x17000002000000 to Index 24. 
[16724] 15:30:24: ConvertRouteInfoToRtm:  pRouteInfo->Flags1   (0x0)  
[16724] 15:30:24: ConvertRouteInfoToRtm: Flags: pRouteInfo  (0x0),  dwRouteFlags  (0x0), pRtInfo  (0x0) 
[16772] 15:30:25: ChangeRouteWithForwarder: Deleting all routes to 10.0.0.24/255.255.255.255
[16772] 15:30:25: GetFirstRouteInfoForDestination returns with 0x0; Index = 0; Dest = 0x1800000a; nexthop = 0x58
[16772] 15:30:25: AllocateAndGetIpAddrTable returns with 0x0
[16772] 15:30:25: IsOnLinkRoute: 0
[16772] 15:30:25: DeleteIpForwardEntry returns with 0x2; Index = 0; Dest = 0x1800000a; nexthop = 0x58
[16772] 15:30:25: SetIpForwardEntry returns with 0x2

Практически одновременно с этим я вижу журналы в PPP.LOG файл, показывающий, что входящие эхо-запросы "молча отбрасываются" на сервере. Содержимое пакета предназначено для эхо-запроса ICMP от клиентского компьютера на 10.0.0.24 к серверу на 10.0.0.2:

[17292] 03-11 15:30:24:529: Packet received (62 bytes) for hPort 128
[15288] 03-11 15:30:24:529: >PPP packet received at 03/11/2013 05:00:24:529
[15288] 03-11 15:30:24:530: >Protocol = UNKNOWN, Type = UNKNOWN, Length = 0x3e, Id = 0x0, Port = 128
[15288] 15:30:24:530: >00 21 45 00 00 3C 04 52 00 00 80 01 22 56 0A 00 |.!E..<.R...."V..|
[15288] 15:30:24:530: >00 18 0A 00 00 02 08 00 D9 AA 00 03 73 AE 61 62 |............s.ab|
[15288] 15:30:24:530: >63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 |cdefghijklmnopqr|
[15288] 15:30:24:530: >73 74 75 76 77 61 62 63 64 65 66 67 68 69 00 00 |stuvwabcdefghi..|
[15288] 03-11 15:30:24:530:  
[15288] 03-11 15:30:24:530: Network-layer packet rcvd.
[15288] 03-11 15:30:24:530: Packet being silently discarded

Помогите!

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

Оказывается, это, скорее всего, проблема с программным обеспечением Backup Exec Continuous Protection Server (BECPS), установленным на машине.

Программное обеспечение BECPS при установке создает запланированную задачу «BECPS_AUTOGEN_ [backup_name]». К сожалению, когда эта задача выполняется, кажется, что она (необъяснимо) отбрасывает все маршруты для интерфейсов VPN, делая их нефункциональными.

Деинсталляции программного обеспечения BECPS было достаточно, чтобы позволить VPN-соединениям оставаться в рабочем состоянии более или менее неопределенно долго. Мы проводим дополнительные тесты, чтобы увидеть, сможем ли мы запустить программное обеспечение без побочных эффектов VPN.