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". Помогает их отключить. _______________________________________________ freebsd mailing list [email protected] http://mailman.uafug.org.ua/mailman/listinfo/freebsd
