NGINX SSL не отвечает через IPv6

10

На сервере Debian с nginx я не получаю ответа от веб-сервера через HTTPS и IPv6. HTTP работает нормально.

  • netstat сообщает, что порт 443 прослушивает IPv6-адрес
  • брандмауэр открыт, ipv6scanner.com сообщает, что порт 443 открыт
  • локально (через терминал) wget и curl получают правильный ответ, поэтому конфигурация nginx в порядке
  • нет никаких признаков ошибки из nginx error.log
  • нет никакой записи в access.log, когда это терпит неудачу, таким образом, связь, вероятно, не достигает веб-сервера
  • DNS в порядке. Перевод работает, и соединение не работает, даже если к IP-адресу обращаются напрямую

Любая попытка подключения извне (то есть вне сети, из Интернета) терпит неудачу (веб-браузер, telnet, ipv6-test.com, curl ...). Там нет никакого ответа вообще.

Это можно проверить на www.ekasparova.eu. Я невежественен. Что еще я могу проверить?

редактировать:

вывод traceroute6 --mtu www.google.comвыглядит следующим образом:

traceroute to www.google.com (2a00:1450:4014:800::2004), 30 hops max, 65000 byte packets
1  * F=1500 * *
2  * * *
~
30  * * *

Так что это никогда не доходит до конца ...

edit2:

Мой вывод ip6tables-save (локальный брандмауэр):

# Generated by ip6tables-save v1.6.0 on Wed Oct 17 06:25:40 2018
*filter
:INPUT DROP [32:9320]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:ufw6-after-forward - [0:0]
:ufw6-after-input - [0:0]
:ufw6-after-logging-forward - [0:0]
:ufw6-after-logging-input - [0:0]
:ufw6-after-logging-output - [0:0]
:ufw6-after-output - [0:0]
:ufw6-before-forward - [0:0]
:ufw6-before-input - [0:0]
:ufw6-before-logging-forward - [0:0]
:ufw6-before-logging-input - [0:0]
:ufw6-before-logging-output - [0:0]
:ufw6-before-output - [0:0]
:ufw6-logging-allow - [0:0]
:ufw6-logging-deny - [0:0]
:ufw6-reject-forward - [0:0]
:ufw6-reject-input - [0:0]
:ufw6-reject-output - [0:0]
:ufw6-skip-to-policy-forward - [0:0]
:ufw6-skip-to-policy-input - [0:0]
:ufw6-skip-to-policy-output - [0:0]
:ufw6-track-forward - [0:0]
:ufw6-track-input - [0:0]
:ufw6-track-output - [0:0]
:ufw6-user-forward - [0:0]
:ufw6-user-input - [0:0]
:ufw6-user-limit - [0:0]
:ufw6-user-limit-accept - [0:0]
:ufw6-user-logging-forward - [0:0]
:ufw6-user-logging-input - [0:0]
:ufw6-user-logging-output - [0:0]
:ufw6-user-output - [0:0]
-A INPUT -j ufw6-before-logging-input
-A INPUT -j ufw6-before-input
-A INPUT -j ufw6-after-input
-A INPUT -j ufw6-after-logging-input
-A INPUT -j ufw6-reject-input
-A INPUT -j ufw6-track-input
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A INPUT -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j ufw6-before-logging-forward
-A FORWARD -j ufw6-before-forward
-A FORWARD -j ufw6-after-forward
-A FORWARD -j ufw6-after-logging-forward
-A FORWARD -j ufw6-reject-forward
-A FORWARD -j ufw6-track-forward
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A FORWARD -j LOG --log-prefix "[IPTABLES] " --log-tcp-options
-A OUTPUT -j ufw6-before-logging-output
-A OUTPUT -j ufw6-before-output
-A OUTPUT -j ufw6-after-output
-A OUTPUT -j ufw6-after-logging-output
-A OUTPUT -j ufw6-reject-output
-A OUTPUT -j ufw6-track-output
-A ufw6-after-input -p udp -m udp --dport 137 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 138 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 139 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p tcp -m tcp --dport 445 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 546 -j ufw6-skip-to-policy-input
-A ufw6-after-input -p udp -m udp --dport 547 -j ufw6-skip-to-policy-input
-A ufw6-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-before-forward -m rt --rt-type 0 -j DROP
-A ufw6-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-forward -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-forward -j ufw6-user-forward
-A ufw6-before-input -i lo -j ACCEPT
-A ufw6-before-input -m rt --rt-type 0 -j DROP
-A ufw6-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-input -m conntrack --ctstate INVALID -j ufw6-logging-deny
-A ufw6-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 144 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 145 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 146 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 147 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -d fe80::/10 -p udp -m udp --sport 547 --dport 546 -j ACCEPT
-A ufw6-before-input -d ff02::fb/128 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw6-before-input -d ff02::f/128 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw6-before-input -j ufw6-user-input
-A ufw6-before-output -o lo -j ACCEPT
-A ufw6-before-output -m rt --rt-type 0 -j DROP
-A ufw6-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 130 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 131 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 132 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 143 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 151 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 152 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 153 -m hl --hl-eq 1 -j ACCEPT
-A ufw6-before-output -j ufw6-user-output
-A ufw6-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw6-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw6-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw6-skip-to-policy-forward -j DROP
-A ufw6-skip-to-policy-input -j DROP
-A ufw6-skip-to-policy-output -j ACCEPT
-A ufw6-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 20 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 21 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 80 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 110 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 143 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 587 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 993 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 995 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8080 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8081 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 10000 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 53 -j ACCEPT
-A ufw6-user-input -p tcp -m multiport --dports 29799:29899 -j ACCEPT
-A ufw6-user-input -p udp -m udp --dport 25 -j ACCEPT
-A ufw6-user-input -p tcp -m tcp --dport 8082 -j ACCEPT
-A ufw6-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw6-user-limit -j REJECT --reject-with icmp6-port-unreachable
-A ufw6-user-limit-accept -j ACCEPT
COMMIT
# Completed on Wed Oct 17 06:25:40 2018

Edit3:

Благодаря помощи каждого я смог убедить оператора центра обработки данных, что проблема в его инфраструктуре. Проблема действительно была в настройке MTU на виртуальном роутере на пути к интернету.

nginx  ssl  ipv6 
— j.kaspar
источник
Снаружи = вне сети в отдельном сегменте локальной сети или с компьютера, расположенного в том же сегменте локальной сети?
— IceMage
1
@IceMage Внешние средства из Интернета. Вне сети. Я собираюсь отредактировать вопрос, чтобы уточнить
— j.kaspar
Вы настроили брандмауэр на сервере? Если сервер работает под управлением Linux, вывод ip6table-saveбудет релевантным.
— Касперд
@kasperd Я добавил все вопросы, связанные с icmp, к этому вопросу
— j.kaspar
@ j.kaspar Это вывод, который ip6tables-saveя хотел увидеть. Эта команда выведет полные правила.
— Касперд

Ответы:

19

У вас проблема с MTU.

Я проверял wget -O /dev/null https://www.ekasparova.eu, наблюдая за трафиком с tcpdump. Вот что я увидел:

19:56:57.048361 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [S], seq 262121609, win 28800, options [mss 1440,sackOK,TS val 298423713 ecr 0,nop,wscale 7], length 0
19:56:57.087457 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [S.], seq 2396216876, ack 262121610, win 28560, options [mss 1440,sackOK,TS val 82836580 ecr 298423713,nop,wscale 7], length 0
19:56:57.087490 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 0
19:56:57.087692 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [P.], seq 1:322, ack 1, win 225, options [nop,nop,TS val 298423723 ecr 82836580], length 321
19:56:57.126190 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [.], ack 322, win 232, options [nop,nop,TS val 82836590 ecr 298423723], length 0
19:56:57.141224 IP6 2a04:f310:100:3:f816:3eff:fea3:4553.443 > 2001:db8::1.47386: Flags [P.], seq 2857:3678, ack 322, win 232, options [nop,nop,TS val 82836594 ecr 298423723], length 821
19:56:57.141301 IP6 2001:db8::1.47386 > 2a04:f310:100:3:f816:3eff:fea3:4553.443: Flags [.], ack 1, win 248, options [nop,nop,TS val 298423736 ecr 82836590,nop,nop,sack 1 {2857:3678}], length 0

Первые 3 пакета - это рукопожатие. Оба конца объявляют, mss 1440что означает, что они способны принимать пакеты с 1440 байтами полезной нагрузки TCP, считая заголовки, а также он составляет 1500 байтов IP-трафика, что Ethernet обычно поддерживает.

Следующие 2 пакета - это привет клиента и подтверждение, что он был получен сервером.

Последние 2 пакета - вот что становится интересным. По умолчанию tcpdumpотображаются относительные порядковые номера, которые в этом случае облегчают чтение записи. В пакете с сервера это интересная часть seq 2857:3678. Мы видим скачок, из которого 1следует, 2857что существует разрыв в 2856 байтов, который клиент еще не получил. 2856 байт соответствует двум пакетам по 1428 байт. Разница между 1440 и 1428 заключается в размере опции метки времени.

Итак, сервер отправил серверу привет, разделенный на 3 пакета. Но первые два были слишком большими для сети и не были доставлены клиенту.

В конечном пакете от клиента к серверу мы видим это sack 1 {2857:3678}. Это выборочное подтверждение, отправленное клиентом, информирующее сервер о наличии пробела в данных, которые он получил до этого момента.

Вероятно, сервер продолжает отправлять два потерянных пакета снова и снова. Но независимо от того, сколько раз он передает те же два пакета, они остаются слишком большими для сети. И, вероятно, маршрутизатор на пути отправляет сообщение об ошибке обратно на сервер, информируя его о том, что пакеты слишком велики и должны быть повторно переданы в меньших пакетах.

Если сервер получит эти сообщения об ошибках, он будет при необходимости повторно передавать пакеты меньшего размера. И он запомнит меньший PMTU, так что при последующих запросах ему не придется повторять этот шаг обнаружения.

Возможное объяснение всего этого заключается в том, что у вас неправильно настроен межсетевой экран, который удаляет все сообщения об ошибках, информирующие ваш сервер о необходимости повторной передачи данных в меньших пакетах.

— kasperd
источник
1
Интересно. Спасибо! Эти сообщения об ошибках - я думаю, что это протокол ICMP ... Есть ли способ проверить это? Брандмауэр на сервере и брандмауэр между сервером и Интернетом должны быть открыты для всех соединений ICMP.
— j.kaspar
@ j.kaspar Какие брандмауэры? Как они настроены? Как вы их тестировали?
— Майкл Хэмптон
@MichaelHampton есть брандмауэр iptables, установленный непосредственно на сервере. Второй принадлежит центру обработки данных, и я могу управлять его правилами. Я действительно не знаю, как проверить ICMP. Но правила для обоих установлены где угодно <-> где угодно для ICMP
— j.kaspar
1
@ j.kaspar На сервере Linux попробуйте traceroute6 --mtu www.google.comнайти F=####вставленные в выходные строки или выходные строки, где ответ не возвращается вообще. Если подумать, просто запустите его и отредактируйте свой вопрос с помощью вывода.
— Майкл Хэмптон
@MichaelHampton Готово. Однако я не уверен, как интерпретировать результат. Значит ли это, что общение вообще не проходит второй прыжок?
— j.kaspar
1

Я согласен с @kasperd, что это проблема MTU. Например, по умолчанию wget -6 -O/dev/null http://www.ekasparova.euне будет работать (он получит короткое перенаправление https://www.babysoul.cz/на тот же IP-адрес, но затем будет зависать на следующем более крупном пакете). Тогда я принудительно уменьшил MSS для вашего хоста:

ip -6 ro add 2a04:f310:100:3:f816:3eff:fea3:4553 advmss 1000 via $MY_GW

и после этого wgetработает нормально. Итак, это проблема MTU. Сравнение вывода mtr -6 -n --psize 1410 www.ekasparova.eu(который работает) с mtr -6 -n --psize 1411 www.ekasparova.euуказанием указывает, что проблема либо на вашем хосте, 2a04:f310:100:3:f816:3eff:fea3:4553либо на входе в2a04:f310:100::125

Что вы могли бы сделать в качестве обходного пути (помимо обращения к вашему верхнему течению):

Проверьте, при каком размере пакета он разбивается (то есть, wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1500.datвероятно, он не будет работать для вас, хотя должен, но wget -6 -O/dev/null http://v6.testmyipv6.com/MTUtest/1000.datбудет работать нормально), а затем либо:

  • (что еще хуже) зажмите вашу MSS для маршрута по умолчанию IPv6 (как я делал выше). Обратите внимание, что это будет работать только для TCP; например, UDP-пакеты DNS будут по-прежнему повреждены, или
  • (лучше) уменьшить MTU вашего интерфейса (например ifconfig eth0 mtu 1200). Это должно работать для всех пакетов. Проблема в том, что если что-то в пути имеет еще более низкий MTU, вы не сможете общаться с ними. А снижение MTU приведет к несколько более низкой производительности (обычно это не имеет большого значения, если вы не большой сайт)
  • (лучше) попробуйте, если удаление брандмауэра IPv6 (вашего и вашего upsteam) поможет; и когда вы обнаружите, что это так, попробуйте собрать его шаг за шагом, не прерывая обнаружение PMTU, пока не найдете проблемную линию. Проблема в том, что от вашего интернет-провайдера требуется больше работы и сотрудничества (а открытие брандмауэра может сделать вас уязвимым на время).
— Матия Налис
источник
Сокращение MSS на маршруте по умолчанию не является плохим предложением. Это то, что я делал в производственных средах, чтобы обойти проблемы MTU в сетях других людей. Я не так низко, как 1000, хотя. 1220 достаточно мал, чтобы сохранить полный пакет в 1280 байтах, которые IPv6 гарантирует сквозную работу. Однако рассматриваемая проблема не была бы смягчена путем уменьшения MSS на маршруте по умолчанию, поскольку это влияет только на размеры пакетов в одном направлении.
— Касперд
Можно перемещаться по MSS при перевозке (это должно быть возможно ip6tables). Вы не должны этого делать, но оказывается, что ограничение MSS в пути до максимума 1220 - очень эффективный обходной путь для проблем MTU. И это может быть сделано в любой конечной точке или любом промежуточном маршрутизаторе, и это уменьшит проблемы MTU для TCP в обоих направлениях.
— Касперд
Снижение MTU на конечной точке повлияет на исходящую MSS, а также ограничит отправку пакетов, даже если вы получили более высокую MSS. Таким образом, более низкий MTU в конечной точке может смягчить проблемы MTU для TCP в обоих направлениях. Однако это помогает только для UDP в одном направлении. А уменьшение MTU на промежуточных маршрутизаторах может смягчить проблему MTU или создать новые проблемы MTU в зависимости от обстоятельств. Таким образом, снижение MSS - это единственное смягчение, которое может помочь без потенциального появления новых проблем MTU.
— Касперд
@ kasperd не должно ли понижение MSS с одной стороны работать для трафика, проходящего в обоих направлениях, так как это согласовано (как более низкая MSS) для всего сеанса TCP во время трехстороннего рукопожатия? Что касается понижения MTU и его разрушения входящих UDP, хотя это правда, это не решит проблему, это не должно создавать дополнительных проблем, так как эти слишком большие UDP не будут работать в любом случае (так как его сломанный восходящий поток все равно их отбросит) ,
— Матия Налис
1
Нет. MSS оговаривается независимо по двум направлениям. Каждая сторона знает максимум, который они готовы отправить, и сообщает другому концу максимум, который они хотят получить. Когда вы устанавливаете, advmssвы влияете только на размер сегментов, которые вы собираетесь получать, а не сегментов, которые вы собираетесь отправлять. Максимум, что вы готовы отправить, не сообщается - потому что в этом нет необходимости. Оба получают свое значение по умолчанию из MTU, один из двух может быть переопределен advmss. Я не знаю способ, чтобы запись маршрутизации перекрывала другую, но если есть способ, я бы хотел узнать.
— Касперд
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.