Имеется сервер с pptpd и pppoed.
Copyright (c) 1992-2007 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-BETA2 #0: Fri Nov 16 10:49:31 EET 2007
user@vpn.host.ru:/usr/obj/usr/src/sys/VPN
Timecounter «i8254» frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU E5310 @ 1.60GHz (1595.93-MHz K8-class CPU)
Origin = «GenuineIntel» Id = 0×6f7 Stepping = 7
Features=0xbfebfbff
Features2=0×4e33d
AMD Features=0×20100800
AMD Features2=0×1
Cores per package: 4
usable memory = 1065545728 (1016 MB)
avail memory = 1027014656 (979 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP): APIC ID: 3
bge0: flags=8843 metric 0 mtu 1500
options=9b
ether 00:xx:xx:xx:xx:xx
media: Ethernet autoselect (100baseTX )
status: active
vlan100: flags=8843 metric 0 mtu 1500
options=3
ether 00:уу:уу:уу:уу:уу
inet 123.123.123.69 netmask 0xfffffff8 broadcast 123.123.123.71
media: Ethernet autoselect (100baseTX )
status: active
vlan: 100 parent interface: bge0
pppoed слушает остальные vlan’ы и там проблем нет.
pptpd слушает vlan100 (он внешний + к нему и подключаются пользователи)
пользователей несколько сотен.
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
В 80% случаев соединение проходит нормально, в 20 — на этапе подключения возникают ошибки (Windows трактовка) :
800 — практически сразу (в самом начале)
629 — в конце = на этапе проверки сетевых протоколов
Вот как это примерно выглядит:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
629 ошибка
20:49:39.339145 IP vpn > 192.168.131.8: GREv1, call 2188, seq 24, ack 17, length 40: IPCP, Conf-Ack (0×02), id 10, length 24
20:49:39.339158 IP vpn > 192.168.131.8: GREv1, call 2188, seq 25, length 18: IPCP, Term-Request (0×05), id 3, length 6
20:49:39.339174 IP vpn > 192.168.131.8: GREv1, call 2188, seq 26, length 56: LCP, Ident (0×0c), id 7, length 42
20:49:39.411743 IP 192.168.131.8 > vpn: GREv1, call 49408, ack 26, no-payload, length 12
20:49:39.414958 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 18, length 53: IP 123.123.123.53 > IGMP.MCAST.NET: [|igmp]
20:49:39.442733 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 19, length 341: IP 123.123.123.53 > 255.255.255.255: [|udp]
20:49:39.451852 IP 192.168.131.8 > vpn: GREv1, call 49408, seq 20, length 18: IPCP, Term-Ack (0×06), id 3, length 6
20:49:39.452858 IP vpn > 192.168.131.8: GREv1, call 2188, seq 27, ack 20, length 24: LCP, Term-Request (0×05), id 3, length 6
20:49:39.456240 IP 192.168.131.8.2188 > vpn.pptp: P 373:389(16) ack 189 win 65347: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) [|pptp]
20:49:39.456311 IP vpn.pptp > 192.168.131.8.2188: F 189:189(0) ack 389 win 65535
20:49:39.464025 IP 192.168.131.8.2188 > vpn.pptp: F 389:389(0) ack 190 win 65347
20:49:39.464050 IP vpn.pptp > 192.168.131.8.2188: . ack 390 win 65534
XXXXXXX—тут дисконект
Нормальное соединение
20:48:09.592272 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 16, ack 21, length 28: IPCP, Conf-Ack (0×02), id 2, length 12
20:48:09.611547 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 17, ack 23, length 40: IPCP, Conf-Request (0×01), id 10, length 24
20:48:09.623383 IP vpn > 192.168.131.8: GREv1, call 2145, seq 24, ack 17, length 40: IPCP, Conf-Ack (0×02), id 10, length 24
20:48:09.665972 IP 192.168.131.8 > vpn: GREv1, call 47872, ack 24, no-payload, length 12
20:48:09.721225 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 18, length 53: IP 123.123.123.228 > IGMP.MCAST.NET: [|igmp]
20:48:09.771601 IP vpn > 192.168.131.8: GREv1, call 2145, ack 18, no-payload, length 12
20:48:09.804380 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 19, length 341: IP 123.123.123.228 > 255.255.255.255: [|udp]
20:48:09.809781 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 20, length 174: IP 123.123.123.228 > 239.255.255.250: [|udp]
20:48:09.860637 IP vpn > 192.168.131.8: GREv1, call 2145, ack 20, no-payload, length 12
20:48:10.647033 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 21, length 53: IP 123.123.123.228 > IGMP.MCAST.NET: [|igmp]
20:48:10.677224 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 22, length 83: IP 123.123.123.228 > irc.host.ru: [|udp]
20:48:10.686758 IP vpn > 192.168.131.8: GREv1, call 2145, seq 25, ack 22, length 322: IP [|ip]
20:48:10.703409 IP 192.168.131.8 > vpn: GREv1, call 47872, seq 23, ack 25, length 65: IP [|ip]
20:48:10.753638 IP vpn > 192.168.131.8: GREv1, call 2145, ack 23, no-payload, length 12
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
800 ошибка
17:01:36.512238 IP 10.7.0.2.gandalf-lm > vpn.pptp: S 886674397:886674397(0) win 65535
17:01:36.512268 IP vpn.pptp > 10.7.0.2.gandalf-lm: S 3727705929:3727705929(0) ack 886674398 win 65535
17:01:36.526061 IP 10.7.0.2.gandalf-lm > vpn.pptp: P 1:157(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) [|pptp]
17:01:36.527748 IP vpn.pptp > 10.7.0.2.gandalf-lm: F 1:1(0) ack 157 win 65535
17:01:36.539267 IP 10.7.0.2.gandalf-lm > vpn.pptp: F 157:157(0) ack 2 win 65535
17:01:36.539287 IP vpn.pptp > 10.7.0.2.gandalf-lm: . ack 158 win 65534
XXXXXXX—тут дисконект
Нормальное соединение
17:02:04.560230 IP 10.7.0.2.blueberry-lm > vpn.pptp: S 2054453977:2054453977(0) win 65535
17:02:04.560258 IP vpn.pptp > 10.7.0.2.blueberry-lm: S 3856560329:3856560329(0) ack 2054453978 win 65535
17:02:04.573731 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 1:157(156) ack 1 win 65535: pptp CTRL_MSGTYPE=SCCRQ PROTO_VER(1.0) [|pptp]
17:02:04.575561 IP vpn.pptp > 10.7.0.2.blueberry-lm: P 1:157(156) ack 157 win 65535: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) [|pptp]
17:02:04.591256 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 157:325(168) ack 157 win 65379: pptp CTRL_MSGTYPE=OCRQ CALL_ID(0) [|pptp]
17:02:04.592095 IP vpn.pptp > 10.7.0.2.blueberry-lm: P 157:189(32) ack 325 win 65535: pptp CTRL_MSGTYPE=OCRP CALL_ID(14720) [|pptp]
17:02:04.607229 IP 10.7.0.2.blueberry-lm > vpn.pptp: P 325:349(24) ack 189 win 65347: pptp CTRL_MSGTYPE=SLI PEER_CALL_ID(14720) [|pptp]
17:02:04.613105 IP 10.7.0.2 > vpn: GREv1, call 14720, seq 0, length 37: LCP, Conf-Request (0×01), id 0, length 23
17:02:04.663761 IP vpn > 10.7.0.2: GREv1, call 0, ack 0, no-payload, length 12
17:02:04.702037 IP vpn > 10.7.0.2: GREv1, call 0, seq 0, length 53: LCP, Conf-Request (0×01), id 1, length 39
17:02:04.702047 IP vpn > 10.7.0.2: GREv1, call 0, seq 1, length 23: LCP, Conf-Reject (0×04), id 0, length 9
17:02:04.702056 IP vpn > 10.7.0.2: GREv1, call 0, seq 2, length 56: LCP, Ident (0×0c), id 0, length 42
17:02:04.706733 IP vpn.pptp > 10.7.0.2.blueberry-lm: . ack 349 win 65535
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
в логе проскакивают ошибки (может они и не имеют отношения к проблеме)
Nov 19 22:15:01 vpn pptpd[19800]: GRE: read(fd=7,buffer=510be0,len=8196) from PTY failed: status = 0 error = No error
Nov 19 22:15:01 vpn pptpd[19800]: CTRL: PTY read or GRE write failed (pty,gre)=(7,6)
Nov 19 22:15:07 vpn pptpd[20051]: GRE: read(fd=7,buffer=510be0,len=8196) from PTY failed: status = 0 error = No error
Nov 19 22:15:07 vpn pptpd[20051]: CTRL: PTY read or GRE write failed (pty,gre)=(7,6)
сервер особо не загружен — ресурсов хватает
на bge0 траффик 50% в пике.
Пул ip достаточно большой, максимальное количество соединений (connections в pptpd.conf) тоже.
увеличил также
#define CONNECTIONS_DEFAULT
#define MAX_CALLS
но картина таже
В чем причина, и какие есть варианты решения данной проблемы?
Причина как оказалось в mtu/mru.
Но всеравно окончательного понимания нет — и следовательно оптимально настроить не получается.
Просто выставил в настройках демонов 1400 — стало лучше, но всеравно появляются ошибки.
Слишком низкий MTU будет неэфективен для канала, слишком высокий будет вызывать лаги.
В данном случае MTU есть у
- Ethernet он фиксирован = 1500 (+ там есть VLAN_MTU, который насколько я понял передается дочерним VLAN’ам)
- VLAN’а на этом интерфейсе
- демоноа pptpd
- демона pppoed
- настройках ppp для pptp
- настройках ppp для pppoe
По идее у второго должно быть меньше чем у первого, у последних четырех меньше чем у второго?
Объясните как их подобрать для оптимальной работы по ADSL?