[Comm] Проблема с медленной VPN на pptpd - потеря/смена порядка пакетов

[Sergey Vlasov]

On Sun, Dec 09, 2007 at 04:47:24PM +0300, Michael A. Kangin wrote:
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 866 (expecting 863, lost or reordered)
> Dec  9 16:29:06 mak-home pptp[6090]: anon log[decaps_gre:pptp_gre.c:407]: 
> buffering packet 867 (expecting 863, lost or reordered)

1. Посмотреть, как ведёт себя ping -f -s1400 до другого конца туннеля;
   возможно, заняться поиском причин потерь пакетов (ещё более жёсткий
   тест: -s32000 или -s64000, но на такие запросы не всегда отвечают).
   В некоторых случаях ещё стоит посмотреть, как меняется картина при
   изменении содержимого пакетов (опция -p) - наблюдался случай, когда
   нормально проходили почти все пакеты, кроме заполненных 00 или ff.

2. У pptp есть опция --nobuffer, которая позволяет отключить проверку
   номеров пакетов; в этом случае убираются задержки, возникающие
   после потери пакета, и с этими потерями будет разбираться уже,
   например, TCP для соединения, проброшенного через VPN.  Есть также
   опция --timeout, позволяющая регулировать время ожидания при
   переупорядочении пакетов (хотя я подозреваю, что в реальности все
   эти меры бесполезны, поскольку обычно пакеты просто пропадают,
   поэтому ждать прихода старого пакета уже бессмысленно).

3. Ещё одна полезная опция для pptp - --sync (использовать совместно с
   опцией sync для pppd); в случае, если на другой стороне такой
   вариант поддерживается, можно уменьшить расход процессорного
   времени на обработку пакетов (что особенно заметно на слабом
   железе).  Хотя к потерям пакетов это уже не имеет отношения.

> в диких причем количествах. Попробовал гуглить - все свелось к советам 
> отключить дебаг-логи или покрутить mtu/mru. Покрутил, не помогло. 

Тем не менее указывать правильное значение MTU тоже нужно - обычно на
40 байт меньше, чем Path MTU между концами туннеля (если там 1500,
нужно писать mtu 1460).  В Windows XP по умолчанию используется 1400,
чтобы пакеты GRE передавались без фрагментации даже при наличии по
дороге ещё каких-то туннелей.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: Digital signature
Url     : <http://lists.altlinux.org/pipermail/community/attachments/20071209/73f8f2ea/attachment-0002.bin>