>> я вам отправил письмо на почтовый ящик в 16:21 МСК
> Уже смотрю его, как только появятся комментарии, я напишу их следующим сообщением. Некоторые записки по ходу, TCP MSS = 1460 байт, как Receive MSS, так и Send MSS:
TCP Option - Maximum segment size: 1460 bytes
Ваш узел успешно устанавливает TCP сессию с узлом linux.org.ru по порту 80:
113 0.000000 x.x.x.x 178.248.233.6 TCP 41942 → http(80) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704725 TSecr=0 WS=128
114 0.031953 178.248.233.6 x.x.x.x TCP http(80) → 41942 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174551 TSecr=1415704725 WS=512
115 0.000054 x.x.x.x 178.248.233.6 TCP 41942 → http(80) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704733 TSecr=3286174551
Результатом является следующий HTTP обмен:
GET / HTTP/1.1
Host: linux.org.ru
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
HTTP/1.1 302 Found
Server: QRATOR
Date: Tue, 26 Sep 2017 13:16:33 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=15
Location: https://www.linux.org.ru/
Как мы видим, узел при этом выполняет перенаправление вас на другой HTTP URI, на HTTPS версию.
Что автоматически приводит к инициализации новой TCP сессии с узлом linux.org.ru но уже по порту 443:
128 0.214430 x.x.x.x 178.248.233.6 TCP 51902 → https(443) [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1415704797 TSecr=0 WS=128
129 0.031019 178.248.233.6 x.x.x.x TCP https(443) → 51902 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 SACK_PERM=1 TSval=3286174871 TSecr=1415704797 WS=512
130 0.000030 x.x.x.x 178.248.233.6 TCP 51902 → https(443) [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=1415704805 TSecr=3286174871
Далее идёт TLS Client Hello:
131 0.000155 x.x.x.x 178.248.233.6 TLSv1 Client Hello
linux.org.ru подтверждает получение данного сегмента:
132 0.031161 178.248.233.6 x.x.x.x TCP https(443) → 51902 [ACK] Seq=1 Ack=194 Win=30720 Len=0 TSval=3286174905 TSecr=1415704805
После чего linux.org.ru отвечает нам уже в рамках защищённого соединения, но тут есть нюанс:
Обратите внимание, это TCP пакет номер 132, только развёрнутый, обратите внимание на Sequence number: 1 и Acknowledgment number: 194.
Internet Protocol Version 4, Src: 178.248.233.6, Dst: x.x.x.x
Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 1, Ack: 194, Len: 0
Source Port: https (443)
Destination Port: 51902 (51902)
Sequence number: 1 (relative sequence number)
Acknowledgment number: 194 (relative ack number)
1000 .... = Header Length: 32 bytes (8)
Flags: 0x010 (ACK)
Window size value: 60
Checksum: 0xe04f [unverified]
Urgent pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
А теперь следующий, пакет под номером 133:
133 0.000491 178.248.233.6 x.x.x.x SSL [TCP Previous segment not captured] , Continuation Data
Но самое интересно внутри, снова обратите внимание на Sequence number: 2897 и Acknowledgment number: 194.
Frame 133: 1268 bytes on wire (10144 bits), 1268 bytes captured (10144 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 178.248.233.6, Dst: 94.137.13.87
Transmission Control Protocol, Src Port: https (443), Dst Port: 51902 (51902), Seq: 2897, Ack: 194, Len: 1200
Source Port: https (443)
Destination Port: 51902 (51902)
Sequence number: 2897 (relative sequence number)
[Next sequence number: 4097 (relative sequence number)]
Acknowledgment number: 194 (relative ack number)
1000 .... = Header Length: 32 bytes (8)
Flags: 0x018 (PSH, ACK)
Window size value: 60
Checksum: 0x7518 [unverified]
Urgent pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
TCP payload (1200 bytes)
Secure Sockets Layer
При этом размер TCP Payload = 1200 байт! Но, Sequence number уже 2897, это значит, что мы потеряли 1697 байт где-то, при значение нашего Receive MSS = 1460 байт, это значит, что по меньшей мере два сегмента.
Дальше мы видим следующую картину, linux.org.ru сообщает нам о том, что он завершает свою часть соединения:
143 4.998799 178.248.233.6 x.x.x.x TCP https(443) → 51902 [FIN, PSH, ACK] Seq=4097 Ack=194 Win=30720 Len=646 TSval=3286179905 TSecr=1415704813
Ваш узел какое-то время отправляет тем не менее TCP keep-alive пакеты, поскольку он свою часть соединения не закрывал.
186 10.228250 x.x.x.x 178.248.233.6 TCP [TCP Keep-Alive] 51902 → https(443) [ACK] Seq=193 Ack=1 Win=33408 Len=0 TSval=1415708620 TSecr=3286174905 SLE=2897 SRE=4744
Но в итоге и он посылает пакет для завершения соединения, причём в виде быстрого завершения соединения, через RST флаг:
220 1.023881 x.x.x.x 178.248.233.6 TCP 51902 → https(443) [RST, ACK] Seq=194 Ack=1 Win=33408 Len=0 TSval=1415709644 TSecr=3286174905 SLE=2897 SRE=4744
И того мы имеем следующую картину, а именно потерю двух TCP сегментов, при этом linux.org.ru узел не получив ACK с подтверждением их получения, не осуществляет их повторную пересылку, а завершает соединение. Но, очевидно, что установить в таком случае полноценное TLS соединение вашему узлу не удаётся, поскольку он не получает полный набор байт, из которых может быть реконструирован Application Layer TLS пакет ядром.
По какой причине были потеряны два недостающих TCP сегмента, с точки зрения вашего узла установить не возможно. Можно, было бы установить Receive MSS скажем в 1400 байт, но, как мы выяснили ранее, linux.org.ru прекрасно получает и отправляет обратно ICMP пакеты с Layer 3 PDU размером 1492 байта. При размере Receive MSS равным 1460 байт, мы имеем Layer 3 PDU размером 1490 байт.
Отсюда я рекомендую вам открыть повторный кейс у вашего интернет провайдера, вы можете передать им сделанный вами дамп, для анализа или они могут выполнить тестирование собственными силами.
P/S/ Можно было бы конечно предположить, что по какой-то причине эти два TCP сегмента не были просто отражены в дампе, но увы, ваш узел подтвердил получение только данного набора байт TCP Option - SACK 2897-4744.
