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 передавались без фрагментации даже при наличии по дороге ещё каких-то туннелей.