[freebsd] mpd5-сервер не устанавливается pptp соединение
Eugene Grosbein
eugen at grosbein.net
Wed Jul 31 13:08:47 EEST 2019
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
Что значит "ловятся"?
> установлен 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 из-за глюков.
В любом случае, пора ставить Wireshark на Windows и сравнивать его показания с показаниями
tcpdump на фре. Если *все* исходящие пакеты GRE от Windows видны в выдаче tcpdump -
значит, виновата сама Windows, не отправляющая нужные запросы. Может быть,
на Windows стоит излишне "интеллектуальный" антивирус, который вмешивается в трафик.
Если же Windows их отправляет и Wireshark это подтвердит, но фрёвые tcpdump/mpd5
по-прежнему их не получают, значит их гробит промежуточная сеть - гипервизор
или даже излишне умный физический коммутатор, я с таким сталкивался на L2-свичах D-Link,
у которых по дефолту бывают включены глупые фичи "anti-DoS". Помогает их отключить.
More information about the freebsd
mailing list