OpenVPN: обратный маршрут только после ping или tracert

Обсуждение настройки и работы сервисов, резервирования, сетевых настроек и вопросов безопасности ОС для молодых и начинающих системных администраторов.

Модератор: SLEDopit

vkapas
Сообщения: 188
ОС: Ubuntu 14.04, 16.04

OpenVPN: обратный маршрут только после ping или tracert

Сообщение vkapas » 05.11.2018 20:33

Столкнулся со странным поведением OpenVPN-сервера: он отдаёт обратный маршрут (прошу прощения за терминологию, могу неправильно назвать этот процесс) до части хостов только после того, как на этот хост отправлен пинг или трассировка.

Поясню. Есть две сети.

Сеть 1 выходит в интернет через Keenetic 4G. За роутером — хост №1, который подключён к OpenVPN-серверу из сети 2 (IP хоста — 10.8.0.5), ОС — Windows 7, Outlook 2010.
Сеть 2 выходит в интернет через Zyxel Keenetic Giga III (IP 192.168.100.1). За роутером стоит Ubuntu Server с OpenVPN-сервером (IP 192.168.100.34 и 10.8.0.1), а также CardDAV-сервер — он же хост №2 (IP 192.168.100.16), к OpenVPN-серверу не подключён.

Задача состоит в том, чтобы хост №1 смог подключиться к хосту №2 по его локальному IP 192.168.100.16 на порт 5232.

Проблема заключается в том, что успешный коннект происходит только в том случае, если с хоста №1 перед попыткой подключения к хосту №2 отправить пинг или трассировку до этого второго хоста — после этого в течение нескольких минут все попытки соединения заканчиваются успешно.

Я запустил на хосте №2 Wireshark, и вот как выглядит попытка неуспешного коннекта (начиная с п.4):

Код: Выделить всё

2	6.489890	10.8.0.5	192.168.100.1	DNS	87	Standard query 0x6381 A radicale.local.company.ru
3	6.501412	192.168.100.1	10.8.0.5	DNS	103	Standard query response 0x6381 A radicale.local.company.ru A 192.168.100.16
4	6.510978	10.8.0.5	192.168.100.16	TCP	66	49326 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
5	9.514644	10.8.0.5	192.168.100.16	TCP	66	[TCP Retransmission] 49326 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
6	15.514442	10.8.0.5	192.168.100.16	TCP	62	[TCP Retransmission] 49326 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 SACK_PERM=1
7	36.842318	00:ff:b8:**:**:**	Broadcast	ARP	42	Who has 10.8.0.6? Tell 10.8.0.5
8	36.842342	00:ff:b9:**:**:**	00:ff:b8:**:**:**	ARP	42	10.8.0.6 is at 00:ff:b9:**:**:**
9	36.842363	10.8.0.5	10.8.0.1	NBNS	110	Refresh NB USER-PC<00>
10	36.854866	10.8.0.1	10.8.0.5	NBNS	104	Registration response NB 10.8.0.5
11	37.503446	10.8.0.5	192.168.100.1	DNS	86	Standard query 0xfc8c A cescollector.cwatchapi.com
12	37.595638	192.168.100.1	10.8.0.5	DNS	320	Standard query response 0xfc8c A cescollector.cwatchapi.com CNAME cwnlogcollectorendp-env.us-east-1.elasticbeanstalk.com A 52.86.211.88 A 34.224.132.77 NS ns-1011.awsdns-62.net NS ns-1219.awsdns-24.org NS ns-1846.awsdns-38.co.uk NS ns-59.awsdns-07.com
13	52.217476	10.8.0.5	10.8.0.7	NBNS	92	Name query NB USER-PC<1c>
...
17	54.477961	10.8.0.1	10.8.0.5	NBNS	98	Name query response, Requested name does not exist Unknown
Так выглядит пинг и запущенный сразу после него успешный коннект (коннект — с п.29):

Код: Выделить всё

27	60.294699	10.8.0.5	192.168.100.16	ICMP	74	Echo (ping) request  id=0x0001, seq=16/4096, ttl=128 (reply in 28)
28	60.306524	192.168.100.16	10.8.0.5	ICMP	74	Echo (ping) reply    id=0x0001, seq=16/4096, ttl=63 (request in 27)
29	67.552374	10.8.0.5	192.168.100.16	TCP	66	49329 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
30	67.563843	192.168.100.16	10.8.0.5	TCP	66	5232 → 49329 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1352 SACK_PERM=1 WS=32
31	67.563911	10.8.0.5	192.168.100.16	TCP	54	49329 → 5232 [ACK] Seq=1 Ack=1 Win=66048 Len=0
32	67.564297	10.8.0.5	192.168.100.16	TCP	348	49329 → 5232 [PSH, ACK] Seq=1 Ack=1 Win=66048 Len=294 [TCP segment of a reassembled PDU]
33	67.575282	192.168.100.16	10.8.0.5	TCP	54	5232 → 49329 [ACK] Seq=1 Ack=295 Win=30272 Len=0
Со стороны роутера сервера неуспешная попытка, затем пинг и сразу после него — успешный коннект выглядят так:

Код: Выделить всё

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:43:34.319326 IP test.59768 > 10.8.0.1.domain: 47277+ A? radicale.local.company.ru. (45)
19:43:34.319495 IP 10.8.0.1.domain > test.59768: 47277 1/0/0 A 192.168.100.16 (61)
19:43:34.330784 IP test.49511 > 192.168.100.16.5232: Flags [S], seq 2979227019, win 8192, options [mss 1352,nop,wscale 8,nop,nop,sackOK], length 0
19:44:03.376044 IP test > 192.168.100.16: ICMP echo request, id 1, seq 91, length 40
19:44:03.376398 IP 192.168.100.16 > test: ICMP echo reply, id 1, seq 91, length 40
19:44:04.400784 IP test.49512 > 192.168.100.16.5232: Flags [S], seq 92164152, win 8192, options [mss 1352,nop,wscale 8,nop,nop,sackOK], length 0
19:44:04.401097 IP 192.168.100.16.5232 > test.49512: Flags [S.], seq 3726147706, ack 92164153, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
19:44:04.411816 IP test.49512 > 192.168.100.16.5232: Flags [.], ack 1, win 258, length 0
19:44:04.411933 IP test.49512 > 192.168.100.16.5232: Flags [P.], seq 1:295, ack 1, win 258, length 294
19:44:04.413335 IP 192.168.100.16.5232 > test.49512: Flags [.], ack 295, win 946, length 0
19:44:04.423763 IP test.49512 > 192.168.100.16.5232: Flags [P.], seq 295:551, ack 1, win 258, length 256
19:44:04.424114 IP 192.168.100.16.5232 > test.49512: Flags [.], ack 551, win 980, length 0
19:44:04.434723 IP 192.168.100.16.5232 > test.49512: Flags [P.], seq 1:551, ack 551, win 980, length 550
19:44:04.435074 IP 192.168.100.16.5232 > test.49512: Flags [F.], seq 551, ack 551, win 980, length 0
19:44:04.445374 IP test.49512 > 192.168.100.16.5232: Flags [.], ack 552, win 256, length 0
19:44:04.445506 IP test.49512 > 192.168.100.16.5232: Flags [F.], seq 551, ack 552, win 256, length 0
19:44:04.445632 IP 192.168.100.16.5232 > test.49512: Flags [.], ack 552, win 980, length 0
19:44:04.446859 IP test.49513 > 192.168.100.16.5232: Flags [S], seq 496510681, win 8192, options [mss 1352,nop,wscale 8,nop,nop,sackOK], length 0
19:44:04.447097 IP 192.168.100.16.5232 > test.49513: Flags [S.], seq 666817675, ack 496510682, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
Конфиг OpenVPN-сервера:
Spoiler
local 192.168.100.34
port 1194
proto udp
dev tun
ca keys/ca.crt
cert keys/server.crt
key keys/server.key # This file should be kept secret
dh keys/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.100.0 255.255.255.0"
client-config-dir ccd
learn-address /var/lib/openvpn/ovpn-learnaddress.sh
push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DNS 192.168.100.1"
push "dhcp-option WINS 10.8.0.1"
push "dhcp-option NBT 4"
client-to-client
keepalive 10 120
tls-auth easy-rsa/keys/ta.key 0 # This file is secret
cipher AES-128-CBC # AES
comp-lzo
max-clients 50
persist-key
persist-tun
crl-verify keys/crl.pem
В какую сторону копать, чтобы выяснить причину проблемы?

P.S. В начале поста написал, что проблема воспроизводится для части хостов, поясню. За OpenVPN-сервером, в его сети есть ещё одна машина, к которой подключаются клиенты, она на Windows 7. Так вот к ней коннект идёт успешно и без предварительных пингов с трассировками.
Последний раз редактировалось vkapas 08.11.2018 20:21, всего редактировалось 1 раз.
Спасибо сказали:

Аватара пользователя
s.xbatob
Сообщения: 605
ОС: RfRemix

Re: OpenVPN: обратный маршрут только после ping или tracert

Сообщение s.xbatob » 05.11.2018 22:48

А с протоколом TCP?
У меня с UDP тоже были проблемы, если по пути NAT
Спасибо сказали:

vkapas
Сообщения: 188
ОС: Ubuntu 14.04, 16.04

Re: OpenVPN: обратный маршрут только после ping или tracert

Сообщение vkapas » 08.11.2018 20:40

Спасибо за совет, попробовал с tcp. Но, увы, поведение в этом случае абсолютно то же, что с udp.

Лог на клиенте:

Код: Выделить всё

23	5.525585	10.8.0.5	192.168.100.1	DNS	87	Standard query 0x3693 A radicale.local.company.ru
24	5.539691	192.168.100.1	10.8.0.5	DNS	103	Standard query response 0x3693 A radicale.local.company.ru A 192.168.100.16
25	5.547645	10.8.0.5	10.8.0.7	NBNS	110	Registration NB WORKGROUP<1d>
26	5.550193	10.8.0.5	192.168.100.16	TCP	66	51204 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
27	5.879627	10.8.0.5	224.0.0.252	LLMNR	66	Standard query 0x1511 A isatap
28	5.985260	10.8.0.5	224.0.0.252	LLMNR	66	Standard query 0x1511 A isatap
29	6.188941	10.8.0.5	10.8.0.7	NBNS	92	Name query NB ISATAP<00>
30	6.296854	10.8.0.5	10.8.0.7	NBNS	110	Registration NB WORKGROUP<1d>
...
35	7.813714	10.8.0.5	239.255.255.250	SSDP	175	M-SEARCH * HTTP/1.1 
36	8.437734	10.8.0.5	10.8.0.1	NBNS	92	Name query NB ISATAP<00>
37	8.449301	10.8.0.1	10.8.0.5	NBNS	98	Name query response, Requested name does not exist Unknown
38	8.469827	10.8.0.5	224.0.0.252	LLMNR	66	Standard query 0xe019 A isatap
39	8.546635	10.8.0.5	10.8.0.1	NBNS	110	Multi-homed registration NB WORKGROUP<1d>
40	8.558044	10.8.0.1	10.8.0.5	NBNS	104	Registration response NB 10.8.0.5
41	8.558190	10.8.0.5	10.8.0.7	NBNS	110	Registration NB <01><02>__MSBROWSE__<02><01>
42	8.562099	10.8.0.5	192.168.100.16	TCP	66	[TCP Retransmission] 51204 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
43	8.577874	10.8.0.5	224.0.0.252	LLMNR	66	Standard query 0xe019 A isatap
44	8.781987	10.8.0.5	10.8.0.7	NBNS	92	Name query NB ISATAP<00>
45	9.296629	10.8.0.5	10.8.0.7	NBNS	110	Registration NB <01><02>__MSBROWSE__<02><01>
...
50	10.856877	10.8.0.5	239.255.255.250	SSDP	175	M-SEARCH * HTTP/1.1 
51	11.031483	10.8.0.5	10.8.0.1	NBNS	92	Name query NB ISATAP<00>
52	11.043814	10.8.0.1	10.8.0.5	NBNS	98	Name query response, Requested name does not exist Unknown
После пинга:

Код: Выделить всё

130	32.165007	10.8.0.5	192.168.100.16	TCP	66	51205 → 5232 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
131	32.178600	192.168.100.16	10.8.0.5	TCP	66	5232 → 51205 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1350 SACK_PERM=1 WS=32
132	32.178752	10.8.0.5	192.168.100.16	TCP	54	51205 → 5232 [ACK] Seq=1 Ack=1 Win=66048 Len=0
133	32.179037	10.8.0.5	192.168.100.16	TCP	348	51205 → 5232 [PSH, ACK] Seq=1 Ack=1 Win=66048 Len=294 [TCP segment of a reassembled PDU]
134	32.243921	192.168.100.16	10.8.0.5	TCP	54	5232 → 51205 [ACK] Seq=1 Ack=295 Win=30272 Len=0
Лог на сервере (лог в первом сообщении — тоже со стороны сервера, а не роутера, опечатался):

Код: Выделить всё

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
20:12:10.859584 IP test.55459 > 192.168.100.1.domain: 13971+ A? radicale.local.company.ru. (45)
20:12:10.860116 IP 192.168.100.1.domain > test.55459: 13971 1/0/0 A 192.168.100.16 (61)
20:12:10.885266 IP test.51204 > 192.168.100.16.5232: Flags [S], seq 3803885609, win 8192, options [mss 1350,nop,wscale 8,nop,nop,sackOK], length 0
20:12:13.770122 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:13.770236 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
20:12:13.878938 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): MULTIHOMED REGISTRATION; REQUEST; UNICAST
20:12:13.879041 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): REGISTRATION; POSITIVE; RESPONSE; UNICAST
20:12:16.364231 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:16.364346 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
20:12:21.537809 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:26.723672 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:26.723770 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
...
20:12:33.870338 IP test > 192.168.100.16: ICMP echo request, id 1, seq 219, length 40
20:12:33.870918 IP 192.168.100.16 > test: ICMP echo reply, id 1, seq 219, length 40
20:12:34.507423 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:34.507550 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
20:12:34.882152 IP test > 192.168.100.16: ICMP echo request, id 1, seq 220, length 40
20:12:34.882466 IP 192.168.100.16 > test: ICMP echo reply, id 1, seq 220, length 40
...
20:12:37.098589 IP test.netbios-ns > 10.8.0.1.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
20:12:37.099026 IP 10.8.0.1.netbios-ns > test.netbios-ns: NBT UDP PACKET(137): QUERY; NEGATIVE; RESPONSE; UNICAST
20:12:37.500034 IP test.51205 > 192.168.100.16.5232: Flags [S], seq 1914035655, win 8192, options [mss 1350,nop,wscale 8,nop,nop,sackOK], length 0
20:12:37.500332 IP 192.168.100.16.5232 > test.51205: Flags [S.], seq 945924026, ack 1914035656, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 5], length 0
20:12:37.513545 IP test.51205 > 192.168.100.16.5232: Flags [.], ack 1, win 258, length 0
20:12:37.564091 IP test.51205 > 192.168.100.16.5232: Flags [P.], seq 1:295, ack 1, win 258, length 294
20:12:37.564461 IP 192.168.100.16.5232 > test.51205: Flags [.], ack 295, win 946, length 0
20:12:37.579272 IP test.51205 > 192.168.100.16.5232: Flags [P.], seq 295:551, ack 1, win 258, length 256
20:12:37.579625 IP 192.168.100.16.5232 > test.51205: Flags [.], ack 551, win 980, length 0
20:12:37.586832 IP 192.168.100.16.5232 > test.51205: Flags [P.], seq 1:551, ack 551, win 980, length 550
20:12:37.587090 IP 192.168.100.16.5232 > test.51205: Flags [F.], seq 551, ack 551, win 980, length 0
20:12:37.616967 IP 192.168.100.16.5232 > test.51205: Flags [F.], seq 551, ack 551, win 980, length 0
20:12:37.641367 IP test.51205 > 192.168.100.16.5232: Flags [.], ack 552, win 256, length 0
20:12:37.696579 IP test.51205 > 192.168.100.16.5232: Flags [.], ack 552, win 256, length 0
20:12:37.696621 IP test.51205 > 192.168.100.16.5232: Flags [F.], seq 551, ack 552, win 256, length 0
Спасибо сказали:

Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 7721
Статус: Маньяк
ОС: Android, GNU/Linux, Windows

Re: OpenVPN: обратный маршрут только после ping или tracert

Сообщение serzh-z » 08.11.2018 21:30

vkapas
А что в ovpn-learnaddress.sh и как изменяются серверные правила Netfilter в промежутке 19:43:34.330784-19:44:04.411816?
Scio me nihil scire.
Спасибо сказали:

vkapas
Сообщения: 188
ОС: Ubuntu 14.04, 16.04

Re: OpenVPN: обратный маршрут только после ping или tracert

Сообщение vkapas » 11.11.2018 13:11

1. ovpn-learnaddress.sh — небольшой скрипт для ресолвинга ovpn-клиентов (на сервере стоит также dnsmasq). Я попробовал воспроизвести ситуацию, убрав его из конфига — ничего не изменилось, то есть он здесь ни при чём.
Spoiler
#!/bin/bash
# openvpn learn-address script to manage a hosts-like file
# - intended to allow dnsmasq to resolve openvpn clients
# addn-hosts=/etc/hosts.openvpn-clients
# - written for openwrt (busybox), but should work most anywhere
#
# Changelog
# 2006-10-13 BDL original
# 2013-21-10 - Do not use absolute paths, to be more cross compatible
# - Add support for flock locking

PATH=$PATH:/bin:/usr/bin

# replace with a sub-domain of your domain, use a sub-domain to prevent VPN clients from stealing existing names
DOMAIN=${DOMAIN:-"company"}
HOSTS=${HOSTS:-"/etc/hosts.openvpn-clients"}
LOCKFILE=${LOCKFILE:-"/var/run/$(basename "$HOSTS").lock"}
DNSMASQ=${DNSMASQ:-"/var/run/dnsmasq/dnsmasq.pid"}

IP="$2"
CN="$3"

case "$1" in
add|update)
if [ -z "$IP" -o -z "$CN" ]; then
echo "$0: IP and/or Common Name not provided" >&2
exit 0
fi
;;
delete)
if [ -z "$IP" ]; then
echo "$0: IP not provided" >&2
exit 0
fi
;;
*)
echo "$0: unknown operation [$1]" >&2
exit 1
;;
esac


# clean up IP if we can
command -v ipcalc >/dev/null 2>&1 && eval $(ipcalc "$IP")

#FQDN="$CN.$DOMAIN"
FQDN="$CN"

(
# Busybox uses lock instead of flock so choose the correct implementation
(command -v flock >/dev/null 2>&1 && (flock -x 200)) ||
(command -v lock >/dev/null 2>&1 && (lock "$LOCKFILE"))

# busybox mktemp must have exactly six X's
t=$(mktemp "/tmp/$h.XXXXXX")
if [ $? -ne 0 ]; then
echo "$0: mktemp failed" >&2
exit 1
fi

# Try to create hosts file if it does not exist yet
[ ! -f $HOSTS ] && touch $HOSTS

case "$1" in

add|update)
awk '
# update/uncomment address|FQDN with new record, drop any duplicates:
$2 == "'"$FQDN"'" \
{ if (!m) print "'"$IP"'\t'"$FQDN"'"; m=1; next }
{ print }
END { if (!m) print "'"$IP"'\t'"$FQDN"'" } # add new address to end
' "$HOSTS" > "$t" && cat "$t" > "$HOSTS"
;;

delete)
awk '
# no FQDN, comment out all matching addresses (should only be one)
$1 == "'"$IP"'" { print "#" $0; next }
{ print }
' "$HOSTS" > "$t" && cat "$t" > "$HOSTS"
;;

esac

rm "$t"

# Busybox uses lock instead of flock so choose the correct implementation
(command -v flock >/dev/null 2>&1 && false) ||
(command -v lock >/dev/null 2>&1 && (lock -u "$LOCKFILE"))
) 200>$((command -v flock >/dev/null 2>&1 && (echo $LOCKFILE)) ||
(command -v lock >/dev/null 2>&1 && (echo "/dev/null")))

# signal dnsmasq to reread hosts file
[ -f $DNSMASQ ] && kill -HUP $(cat $DNSMASQ)
2. В iptables сервера — только стандартные правила fail2ban, и, насколько я понимаю, они не меняются во время работы openvpn.

Код: Выделить всё

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere         
Спасибо сказали:

Аватара пользователя
serzh-z
Бывший модератор
Сообщения: 7721
Статус: Маньяк
ОС: Android, GNU/Linux, Windows

Re: OpenVPN: обратный маршрут только после ping или tracert

Сообщение serzh-z » 11.11.2018 20:47

vkapas писал:
11.11.2018 13:11
они не меняются
Подумалось, что используется хитрый learn-address-скрипт, который с большей задержкой настраивает файрвол.

Возможно, что PMTUD не срабатывает. Что в выводе `tracepath` или `traceroute --mtu`? Так же можно поиграться с `ping -S ... -M dont ...`. Можно посмотреть марсианский лог на сервере (включается с помощью sysctl - martian-что-то там, либо в /proc).

P.S.: вообще, выглядит так, что в первом случае сервер просто дропает пакеты с MSS > 1350 байт, а после пинга клиент начинает слать пакеты меньшего размера, а другом логе сервер начинает отвечать уменьшенным MSS.
Scio me nihil scire.
Спасибо сказали: