Hello Eugene Grosbein.
On Wed, 31 Jul 2019, 13:08, you wrote:
31.07.2019 16:34, Yaroslav Shvets пишет:
Hello All.
На сервере:
-----------
12.0-RELEASE-p8
$ifconfig em5
em5: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=81009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER>
ether 00:0c:29:6a:c0:b1
inet 10.10.0.8 netmask 0xffffff00 broadcast 10.10.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
firewall:
первой же строчкой
allow ip from any to any via em5
в него же и ловятся все пакеты через em5
Что значит "ловятся"?
Это значит, что пакеты, ходящие по этой сетевой карте em5, подпадают
под это правило и не подпадают под множество других нижележащих правил.
установлен mpd5-5.8_10 путем 'pkg install mpd5'
mpd.conf практически штатный из пакета
(изменена одна строчка: 'set pptp self 10.10.0.8'):
-- cut --
...
default:
load pptp_server
...
pptp_server:
set ippool add pool1 192.168.1.50 192.168.1.99
create bundle template B
set iface enable proxy-arp
set iface idle 1800
set iface enable tcpmssfix
set ipcp yes vjcomp
set ipcp ranges 192.168.1.1/32 ippool pool1
set ipcp dns 192.168.1.3
set ipcp nbns 192.168.1.4
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
create link template L pptp
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap
set link keep-alive 10 60
set link mtu 1460
set pptp self 10.10.0.8
set link enable incoming
-- cut --
Клиент:
-------
Windows 10. Находится в той же подсети 10.10.0.0/24, никакой маршрутизации
и промежуточных фаерволов нет.
Подключиться к pptp-серверу не удается.
cat /var/log/mpd.log:
-- cut --
Jul 31 11:57:35 gw mpd[571]: [L-1] Accepting PPTP connection
Протокол PPtP использует два типа пакетов: протокол TCP(6) по порту 1723
для управляющего соединения и протокол GRE (47) для туннелирования PPP.
Судя по последней строчке в квоте выше, пакеты TCP проходят нормально,
так как управляющее соединение устанавливатся и даже начинается согласование
PPP,
которое выполняется обменом пакетов GRE, несущих внутри себя туннелированные
фреймы PPP/LCP:
Jul 31 11:57:35 gw mpd[571]: [L-1] Link: OPEN event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Open event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Initial --> Starting
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: LayerStart
Jul 31 11:57:35 gw mpd[571]: [L-1] PPTP: attaching to peer's outgoing call
Jul 31 11:57:35 gw mpd[571]: [L-1] Link: UP event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: Up event
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: state change Starting --> Req-Sent
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigReq #1
Jul 31 11:57:35 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:35 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:35 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:35 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:35 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:35 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: rec'd Configure Request #0 (Req-Sent)
Jul 31 11:57:35 gw mpd[571]: [L-1] MRU 1400
Jul 31 11:57:35 gw mpd[571]: [L-1] MAGICNUM 0x09ec61cb
Jul 31 11:57:35 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:35 gw mpd[571]: [L-1] CALLBACK 6
Во время согласования параметров идёт параллельно два обмена опциями:
сервер отправляет свои, нумеруя из последовательно, а клиент отправляет свои.
Сервер отправил свой запрос LCP за номером 1 и получил запрос
LCP от клиента (от Windows) за номером 0, уже хорошо.
Jul 31 11:57:35 gw mpd[571]: [L-1] LCP: SendConfigRej #0
Jul 31 11:57:35 gw mpd[571]: [L-1] CALLBACK 6
Сервер отверг опцию CALLBACK в предложении клиента номер 0, теперь клиент
должен перепослать своё предложение за вычетом этой опции, если отказ сервера
до клиента дошел - или клиент перепошлет предложение в неизменном виде,
если фрейм с отказом не дошел.
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: SendConfigReq #2
За целых две секунды ничего не произошло и это плохо, так как клиент должен был
либо согласиться на предложение сервера за номером 1, либо прислать ConfigRej,
но ни того, ни другого не случилось (возможно, пакет потерялся) и сервер
перепосылает свой запрос повторно в неизменном виде за номером 2:
Jul 31 11:57:37 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:37 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:37 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:37 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:37 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:37 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
По прежнему от клиента нет ответа на запрос сервера, но хотя бы клиент
присылает собственный запрос:
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: rec'd Configure Request #2 (Req-Sent)
Jul 31 11:57:37 gw mpd[571]: [L-1] MRU 1400
Jul 31 11:57:37 gw mpd[571]: [L-1] MAGICNUM 0x09ec61cb
Jul 31 11:57:37 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: SendConfigAck #2
Jul 31 11:57:37 gw mpd[571]: [L-1] MRU 1400
Jul 31 11:57:37 gw mpd[571]: [L-1] MAGICNUM 0x09ec61cb
Jul 31 11:57:37 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:37 gw mpd[571]: [L-1] ACFCOMP
И сервер согласился с ним.
Jul 31 11:57:37 gw mpd[571]: [L-1] LCP: state change Req-Sent --> Ack-Sent
Jul 31 11:57:39 gw mpd[571]: [L-1] LCP: SendConfigReq #3
Прошло ещё две секудны и клиент так ничего и не прислал за запрос сервера,
так что сервер снова его дублирует, теперь за номером 3. А потом ещё и ещё:
Jul 31 11:57:39 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:39 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:39 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:39 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:39 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:39 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:39 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:39 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:41 gw mpd[571]: [L-1] LCP: SendConfigReq #4
Jul 31 11:57:41 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:41 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:41 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:41 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:41 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:41 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:41 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:41 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:43 gw mpd[571]: [L-1] LCP: SendConfigReq #5
Jul 31 11:57:43 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:43 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:43 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:43 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:43 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:43 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:43 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:43 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:45 gw mpd[571]: [L-1] LCP: SendConfigReq #6
Jul 31 11:57:45 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:45 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:45 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:45 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:45 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:45 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:45 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:45 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:47 gw mpd[571]: [L-1] LCP: SendConfigReq #7
Jul 31 11:57:47 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:47 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:47 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:47 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:47 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:47 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:47 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:47 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:49 gw mpd[571]: [L-1] LCP: SendConfigReq #8
Jul 31 11:57:49 gw mpd[571]: [L-1] ACFCOMP
Jul 31 11:57:49 gw mpd[571]: [L-1] PROTOCOMP
Jul 31 11:57:49 gw mpd[571]: [L-1] MRU 1500
Jul 31 11:57:49 gw mpd[571]: [L-1] MAGICNUM 0x0fde2eb7
Jul 31 11:57:49 gw mpd[571]: [L-1] AUTHPROTO CHAP MSOFTv2
Jul 31 11:57:49 gw mpd[571]: [L-1] MP MRRU 2048
Jul 31 11:57:49 gw mpd[571]: [L-1] MP SHORTSEQ
Jul 31 11:57:49 gw mpd[571]: [L-1] ENDPOINTDISC [802.1] 00 0c 29 6a c0 7f
Jul 31 11:57:50 gw mpd[571]: [L-1] LCP: rec'd Terminate Request #4 (Ack-Sent)
Вдруг от клиента приходит запрос на обрыв подключения - очевидно, на клиенте
сработал
какой-то таймаут.
Да, очень похоже, что клиент прекращает работу по таймауту.
tcpdump -n -i em5 -vvv 'port 1723 or proto gre'
лог во вложении
Лог подтверждает, что ядро не утаило от mpd5 никаких пакетов, то есть никакой
пакетный
фильтр на FreeBSD их не убил.
Из лога мне непонятно, что проходит не так.
Что удивительно: тот же клиентский хост на Windows 10
без проблем соединяется еще с пятком других mpd5-серверов в том числе
и таких же версий с одним и тем же конфигом под управлением от 11.x-releng до
12.0-releng.
Чем именно этот проблемный сервер отличается от тех, к которым удается
установить pptp-соединение не пойму.
Может есть у кого-то мысли, что нужно проверить?
Либо глючит PPtP-клиент в Windows, либо кто-то избирательно дропает пакеты GRE,
несущие фреймы от Windows к FreeBSD.
Если кто-то из двоих систем - виртуалка, то первый подозреваемый - гипервизор,
частенько их сетевой стек плохо пропускает что-то кроме TCP/UDP/ICMP из-за
глюков.
Очень интересная версия. Вполне может быть.
Сервер живет на VMware ESXi 5.5
В любом случае, пора ставить Wireshark на Windows и сравнивать его показания с
показаниями
tcpdump на фре. Если *все* исходящие пакеты GRE от Windows видны в выдаче
tcpdump -
значит, виновата сама Windows, не отправляющая нужные запросы. Может быть,
на Windows стоит излишне "интеллектуальный" антивирус, который вмешивается в
трафик.
Вряд ли. Но проверю.
Если же Windows их отправляет и Wireshark это подтвердит, но фрёвые tcpdump/mpd5
по-прежнему их не получают, значит их гробит промежуточная сеть - гипервизор
или даже излишне умный физический коммутатор, я с таким сталкивался на
L2-свичах D-Link,
у которых по дефолту бывают включены глупые фичи "anti-DoS". Помогает их
отключить.
Проверю. Спасибо за идею.
--
Yaroslav Shvets
_______________________________________________
freebsd mailing list
[email protected]
http://mailman.uafug.org.ua/mailman/listinfo/freebsd
