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 (локальний брандмауер):

# 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
@kasperd Я додав усі відповідні правила
— icmp
@ j.kaspar Це результат, який ip6tables-saveя хотів побачити. Ця команда видасть усі правила.
— kasperd

Відповіді:

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 таким, що при наступних запитах йому не доведеться повторювати цей крок відкриття.

Можливим поясненням усього цього є те, що у вас неправильно налаштований брандмауер, який видаляє всі повідомлення про помилки, повідомляючи вашому серверу, що він потребує повторної передачі даних у менших пакетах.

— касперд
джерело
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; наприклад, пакети DNS UDP все одно будуть зламані, або
  • (краще) зменшіть свій інтерфейс MTU (наприклад ifconfig eth0 mtu 1200). Це має працювати для всіх пакетів. Проблема полягає в тому, що якщо щось на шляху має навіть менший MTU, ви не зможете спілкуватися з ними. А зниження MTU призведе до дещо нижчих показників (не така вже й велика справа, якщо зазвичай ви не великий сайт)
  • (найкраще) спробуйте, якщо допоможе видалення брандмауера IPv6 (як у вашому, так і в самому верхньому плані); і коли ви дізнаєтесь, що це робиться, спробуйте скласти це разом крок за кроком, не порушуючи відкриття PMTU, поки не знайдете проблемну лінію. Проблема полягає в тому, що він вимагає більше роботи та співпраці від вашого провайдера (і відкриття брандмауера може зробити вас вразливим на час).
— Матія Наліс
джерело
Зменшення MSS на типовому маршруті не є поганою пропозицією. Я щось робив у виробничих середовищах, щоб вирішити проблеми MTU в інших мережах. Я не хожу так низько, як 1000. 1220 є достатньо малим, щоб утримувати повний пакет у межах 1280 байтів, що IPv6 гарантує роботу від кінця до кінця. Однак проблему, яку слід розглядати, не було б усунено шляхом зменшення MSS на маршруті за замовчуванням, оскільки це впливає лише на розміри пакетів в одному напрямку.
— kasperd
Можна керувати MSS під час транзиту (має бути можливо ip6tables). Ви цього не повинні робити, але виявляється, що затискання MSS в дорозі до максимуму 1220 - це дуже ефективне вирішення проблем MTU. І це можна зробити в будь-якій кінцевій точці або будь-якому між маршрутизатором, і це зменшить проблеми MTU для TCP в обох напрямках.
— kasperd
Зниження MTU на кінцевій точці вплине на MSS, що відходить, і також обмежить передачу пакетів, навіть якщо ви отримали більш високу MSS. Таким чином, нижня MTU в кінцевій точці може пом'якшити проблеми MTU для TCP в обох напрямках. Однак це допомагає для UDP лише в одному напрямку. А зменшення MTU на маршрутизаторах між ними може пом'якшити проблему MTU або ввести нові проблеми MTU залежно від обставин. Таким чином, зменшення MSS - це одне пом’якшення, яке може допомогти без потенційного впровадження нових проблем MTU.
— kasperd
@kasperd не повинен знижувати MSS на одній стороні для руху трафіку обома способами, оскільки він узгоджується (як нижчий MSS) протягом усього сеансу TCP під час 3-х рукостискань? Що стосується зниження MTU і розбиття вхідних UDP, хоча це правда, що це не вирішить проблему, воно не повинно створювати додаткових проблем, оскільки ті занадто великі UDP так і не працюватимуть (оскільки його розбитий вище за течією все одно викине їх) .
— Matija Nalis
1
Ні. MSS узгоджується незалежно для двох напрямків. Кожна сторона знає максимум, який вони готові надіслати, і іншим кінцем повідомляє максимум, який вони готові отримати. Встановлюючи, advmssви впливаєте лише на розмір сегментів, які ви будете отримувати, а не сегменти, які ви будете надсилати. Максимум, який ви готові надіслати, не повідомляється - тому що в цьому немає потреби. Обидва отримують своє значення за замовчуванням з MTU, одне з двох може бути замінено advmss. Я не знаю способу для маршрутизації запису, щоб замінити інший, але якщо є спосіб, я хотів би дізнатися.
— kasperd
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.