Как мне настроить 6to4 на MikroTik и настроить MTU для исправления сбоев соединения и обновления guix?

Я настроил SIT-туннель 6to4 на MikroTik по примеру Hurricane Electric в файлах справки MikroTik.

Это работало, но соединение с некоторыми ресурсами было очень медленным и часто истекало время ожидания. Например, скорость загрузки с серверов по умолчанию во время обновления и реконфигурации guix оставалась на уровне 50 КиБ/с и обычно в конечном итоге терпела неудачу при загрузке ядра, вероятно, потому, что это большой пакет.

В техподдержке туннельного брокера подсказали, что MTU 1280 слишком мал и вместо него следует использовать 1480. Действительно, если я изменю MTU туннельного интерфейса на это значение, скорость соединения станет нормальной и будет рассчитываться в МиБ. Я не знаю, почему это работает, но, вероятно, потому, что в какой-то момент сетевому оборудованию не нужно разбивать более крупные пакеты на более мелкие фрагменты, что потребует некоторых накладных расходов.

Но столкнулся с другой проблемой: зависают соединения с некоторыми серверами.guix pullвисит. Бегcurl -vпротив проблемного URL-адреса приводит к тайм-ауту согласования TLS (curl: (28) SSL connection timeout) или сбой библиотеки шифрования (curl: (35) gnutls_handshake() failed: Помилка у функції pull.).

Пинг сервера работает, но пинг с сообщением размером MTUping6 -sза которым следует количество октетов) получает ответPacket too bigдля первого пинга, а затем сбрасывает остальные. TCP-соединение установлено успешно, но время согласования TLS истекло. MTU слишком велик для подключения к этому серверу.

RFC 4213 обеспечивает:

Узел, использующий статический туннельный MTU, рассматривает туннельный интерфейс как имеющий фиксированный MTU. По умолчанию MTU ДОЛЖЕН находиться в диапазоне от 1280 до 1480 байт (включительно), но ДОЛЖЕН составлять 1280 байт.

В RFC 6343 есть раздел «Ошибка PMTUD», который ссылается на RFC 2923 , предлагающий вернуться к MTU 1280 для IPv6, если только невозможно исправить «черную дыру ICMP».

В примере конфигурации MikroTik предлагается использовать 1280, чтобы избежать необходимости согласования MTU. А также естьclamp-tcp-mssнастройка, которая включена по умолчанию:

Определяет, следует ли изменять размер MSS для полученных пакетов TCP SYN. Если этот параметр включен, маршрутизатор будет изменять размер MSS для полученных пакетов TCP SYN, если текущий размер MSS превышает MTU туннельного интерфейса (с учетом служебных данных TCP/IP). Полученный инкапсулированный пакет по-прежнему будет содержать исходный MSS, и только после декапсуляции MSS будет изменен.

Это может объяснить, почему ping иногда позволяет мне успешно отправлять по туннелю огромные сообщения до 65527 (вероятно, 65535 минус 8). Однако это пытается сопоставить MTU туннеля, в то время как мне нужно определить MTU для каждого соединения, который может быть меньше MTU туннеля. Как мне это сделать, чтобы не нужно было понижать MTU туннеля?

1 ответ

Похоже, что в конфигурации MikroTik по умолчанию для IPv6 отсутствует обнаружение MTU пути . Добавление этого правила в брандмауэр IPv6 помогло (источник ):

      /ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

Смысл опций :

Change-mss — изменить значение поля «Максимальный размер сегмента» пакета на значение, указанное параметром new-mss.

Бит набора функций Clamp-to-pmtu (DF) в заголовке IP для динамического обнаружения PMTU пути. Хост отправляет все датаграммы по этому пути с установленным битом DF до тех пор, пока не получит сообщение ICMP Destination Unreachable с кодом, означающим «необходима фрагментация и установлен DF». При получении такого сообщения хост-источник уменьшает предполагаемый PMTU для пути.

син - новое соединение

Таким образом, правило пытается определить MTU для каждого нового соединения. (Приведенное выше описание, очевидно, относится к IPv4. Спецификация IPv6 предполагает отсутствие фрагментации, поэтому бит DF нельзя использовать.)

Другие вопросы по тегам