[freebsd] mpd5-сервер не устанавливается pptp соединение
Yaroslav Shvets
yaroslav at shvets.name
Wed Jul 31 23:38:09 EEST 2019
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
More information about the freebsd
mailing list