15.7. Решение проблемы с Path MTU Discovery путем настройки MSS.
Как уже говорилось выше, Path MTU Discovery не работает в Интернет должным образом. Если вам известны факты существования сегментов в вашей сети, где размер MTU ограничен, то вы уже не можете полагаться на безотказную работу Path MTU Discovery.
Однако, помимо MTU, есть еще один способ ограничения размера пакета — это, так называемый MSS (Maximum Segment Size — Максимальный Размер Сегмента). MSS — это поле в заголовке TCP-пакета SYN.
С недавних пор, ядра Linux и некоторые драйверы PPPoE, стали поддерживать такую особенность, как ‘clamp the MSS’ (ограничение размера MSS).
В этом есть свои плюсы и минусы. С одной стороны, устанавливая MSS, вы недвусмысленно извещаете удаленную сторону о том, что размер пакета не должен превышать заданную величину. Причем для этого не требуется передачи ICMP-сообщений.
С другой стороны — за атакущим сохраняется возможность нарушить связь путем модификации пакетов. Однако, следует заметить, что мы довольно часто используем эту возможность и это приносит свои положительные плоды.
Чтобы иметь возможность манипулировать размером сегмента, у вас должны быть установлены iptables , не ниже 1.2.1a и ядро Linux, не ниже 2.4.3. Основная команда iptables :
# iptables -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu
Она рассчитает правильный MSS для вашего соединения. Если вы достаточно уверены в себе и в своих знаниях, можете попробовать нечто подобное:
# iptables -A FORWARD -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —set-mss 128
Это правило устанавливает MSS равным 128. Очень полезно, если вы наблюдаете разрывы при передаче голосовых данных, когда поток небольших пакетов VoIP прерывается «огромными» http-пакетами.
| Назад | В начало документа | Вперед |
| Решение проблемы с Path MTU Discovery путем настройки MTU. | К началу раздела | Формирователь трафика: Низкая задержка, максимальная производительность. |
iptables clamp-mss-to-pmtu и выбор цепочки.
Где правильно применять clamp-mss-to-pmtu и —set-mss в iptables. В FORWARD, в mangle FORWARD или в POSTROUTING? Сколько не смотрел доков и статей, единства не нашел.
iptables -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380 или iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380 или iptables -t mangle -A POSTROUTING -o tun0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1381:1536 -j TCPMSS --set-mss 1380
akv_
28.03.19 08:42:06 MSK
Общий ответ в mangle. А forward или postrouting зависит от желаемого результата, через forward пройдут только транзитные пакеты, через postrouting и транзитные и локальные.
anc ★★★★★
( 28.03.19 08:58:29 MSK )
Ответ на: комментарий от anc 28.03.19 08:58:29 MSK
Благодарю! Еще вопрос о направлении трафика достаточно одного правила out или нужно еще in?
akv_
( 28.03.19 12:27:37 MSK ) автор топика
Ответ на: комментарий от akv_ 28.03.19 12:27:37 MSK
Вы имеете в виду входящие/исходящие? mss корректируют у исходящих пакетов. Входящий к Вам уже пришел.
funky ★
( 28.03.19 15:17:49 MSK )
Ответ на: комментарий от funky 28.03.19 15:17:49 MSK
Некоторые сайты не открываются через тунель.
Вот так не работает, с одним правилом.
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu а если добавить:
iptables -t mangle -A FORWARD -i tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu То начинает работать.
akv_
( 28.03.19 18:58:41 MSK ) автор топика
Ответ на: комментарий от akv_ 28.03.19 18:58:41 MSK
Как я уже писал «зависит от желаемого результата». В общем случае построутинга хватит всем 🙂
anc ★★★★★
( 28.03.19 21:19:38 MSK )
Ответ на: комментарий от anc 28.03.19 21:19:38 MSK
В вашем примере это два почти разных по поведению правила. В первом случае пакет «нового соединения» который улетит с tun0 и без разницы с какого интерфейса он прилетел включая тот же tun0. Во втором, пакет «нового соединения» который прилетел на tun0 и улетит с любого интерфейса включая тот же tun0. Одинаковое поведение у этих правил будет только в случае если у пакета входящий и исходящий интерфейсы tun0.
ЗЫ Простите, может невнятно написал, в первом моем ответе я не рассматривал указание интерфейса, подразумевал только таблицу mangle и цепочку FORWARD или POSTROUTING.
anc ★★★★★
( 28.03.19 21:37:59 MSK )
Последнее исправление: anc 28.03.19 21:41:15 MSK (всего исправлений: 1)
Ответ на: комментарий от akv_ 28.03.19 18:58:41 MSK
Во первых, что у Вас за tun0? И во вторых, —clamp-mss-to-pmtu делают на интерфейсе, смотрящем в провайдера, т.е. никак не tun0. Если у Вас tun0 — это openvpn, то в нем самом нужно фиксить mss. Там есть параметр в конфиге, нет под рукой — погуглите.
funky ★
( 29.03.19 11:15:46 MSK )
Ответ на: комментарий от funky 29.03.19 11:15:46 MSK
Схема следующая, туннель gre/ipsec на одном конце MikroTik на другом VPS Ubuntu. MTU на туннельном интерфейсе 1418 одинаков и на Linux и на Mikrotik. Со стороны Mikrotik есть несколько клиентов которые должны ходить через этот тунель. Возникла проблема с некоторым кол-вом сайтов, которые не открываются, видимо PMTUD по какой либо причине не может быть задействован. По этой причине возникла идея с MSS. Сейчас на Ubuntu:
iptables -t mangle -A FORWARD -i tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu C этим правилом все работает. Мне нужно менять MSS только на туннельном интерфейсе.
akv_
( 29.03.19 13:10:24 MSK ) автор топика
Ответ на: комментарий от anc 28.03.19 21:19:38 MSK
Ну вот у меня например wifi на мобилу раздаётся, мне как прописывать?
anonymous
( 29.03.19 13:20:25 MSK )
Ответ на: комментарий от anonymous 29.03.19 13:20:25 MSK
iptables -t mangle -A POSTROUTING -p tcp —tcp-flags SYN,RST SYN -j TCPMSS —clamp-mss-to-pmtu
anc ★★★★★
( 29.03.19 23:20:13 MSK )
Ответ на: комментарий от funky 29.03.19 11:15:46 MSK
И во вторых, —clamp-mss-to-pmtu делают на интерфейсе, смотрящем в провайдера, т.е. никак не tun0.
Да шо ви говорите? Ну вот интерфейс прова у меня eth1, но дэфроут улетает на tun15 через прова по udp, и как мне поможет в этом случае исправление mss на интерфейсе eth1 ?
А если нет? Что делааать, что делааать? Памагите.
Вы очень узко рассматриваете задачу, в виде один входящий, один исходящий и mss-to-pmtu. Но вот представьте вариант (не реальный, но описывающий саму проблему). У вас сервер на котором исходящих интерфейсов более одного, на котором:
1. сервер ovpn1, всем клиентам на исходящие новые соединения надо установить mss 1000, клиентов раскидываем по разным исходящим интерфейсам.
2. серер ovpn2, всем клиентам на исходящие новые соединения надо установить mss 1200, клиентов раскидываем по разным исходящим интерфейсам.
3. ipsec — клиентам устанавливаем mss 1380
4. локальный исходящий, mss не трогаем
Решение возможно только с указанием входящего интерфейса (в случае ipsec направления), но никак не исходящего.
RU2687217C1 — Способ предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов — Google Patents
Publication number RU2687217C1 RU2687217C1 RU2018122435A RU2018122435A RU2687217C1 RU 2687217 C1 RU2687217 C1 RU 2687217C1 RU 2018122435 A RU2018122435 A RU 2018122435A RU 2018122435 A RU2018122435 A RU 2018122435A RU 2687217 C1 RU2687217 C1 RU 2687217C1 Authority RU Russia Prior art keywords mss tcp frame packet value Prior art date 2018-06-20 Application number RU2018122435A Other languages English ( en ) Inventor Евгений Леонидович Вороков Александр Владимирович Щеглов Original Assignee Открытое Акционерное Общество «Информационные Технологии И Коммуникационные Системы» Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.) 2018-06-20 Filing date 2018-06-20 Publication date 2019-05-07 2018-06-20 Application filed by Открытое Акционерное Общество «Информационные Технологии И Коммуникационные Системы» filed Critical Открытое Акционерное Общество «Информационные Технологии И Коммуникационные Системы» 2018-06-20 Priority to RU2018122435A priority Critical patent/RU2687217C1/ru 2019-05-07 Application granted granted Critical 2019-05-07 Publication of RU2687217C1 publication Critical patent/RU2687217C1/ru
Links
Classifications
-
- H — ELECTRICITY
- H04 — ELECTRIC COMMUNICATION TECHNIQUE
- H04L — TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00 — Data switching networks
- H04L12/54 — Store-and-forward switching systems
- H04L12/56 — Packet switching systems
- H — ELECTRICITY
- H04 — ELECTRIC COMMUNICATION TECHNIQUE
- H04L — TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00 — Network arrangements, protocols or services for addressing or naming
- H — ELECTRICITY
- H04 — ELECTRIC COMMUNICATION TECHNIQUE
- H04W — WIRELESS COMMUNICATION NETWORKS
- H04W8/00 — Network data management
- H04W8/02 — Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
Abstract
Изобретение относится к цифровым сетям передачи данных с коммутацией пакетов (IP). Технический результат — повышение пропускной способности в сети с коммутацией пакетов. В состав сети входят клиентские сети (КС), каждая из которых содержит клиентские компьютеры (КК) и пограничный маршрутизатор (ПМ); внешнюю сеть, соединяющую все ПМ по технологии VPLS, причем каждый ПМ имеет внешний интерфейс, связанный с внешней сетью и имеющий установленное значение максимального размера полезного блока данных одного пакета, который может быть передан протоколом без фрагментации (MTU); имеет внутренний интерфейс, связанный со своей КС и имеющий установленное значение MTU; содержит средство обработки, выполненное с возможностью: сравнения IP-адресов, содержащихся в кадрах запроса; модификации кадра запроса путем изменения данных. В результате использования данного способа устанавливается TCP-соединение со значением максимального размера MSS, позволяющим осуществлять передачу пакетов без фрагментации, при этом минимизируются задержки при обработке пакетов и уменьшается нагрузка на сервис VPLS, полностью используется доступный канал передачи, а при автоматическом расчете значения максимального размера MSS не требуется дополнительных настроек.
Description
Область техники, к которой относится изобретение
Предполагаемое изобретение относится к цифровым сетям передачи данных с коммутацией пакетов (IP) и, в частности, к способам предотвращения фрагментации TCP/IP-пакетов при использовании VPLS (Virtual Private LAN Service).
Уровень техники
В современных цифровых сетях передачи данных, имеющих множество узлов, сложную распределенную топологию и отдельные участки (подсети или сегменты), которые содержат компьютеры конечных пользователей (клиентов) и которые могут быть территориально расположенными в разных географических регионах, большое значение имеет возможность использовать преимущества объединения в сеть с коммутацией пакетов на канальном уровне (с одним сегментом broadcast). В такой сети можно использовать простые сетевые устройства (принтеры, сканеры, IP-телефоны), устройства для конференц-связи и другие клиентские устройства с упрощенной настройкой. Это позволяет облегчить настройку и в дальнейшем снизить затраты на обслуживание сети в целом.
Для такого объединения удаленных сегментов сети часто используется технология VPLS [Lasserre М., Kompella V., Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling, 2007 (RFC 4762) — статья по адресу: https://tools.ietf.org/html/rfc4762; Kompella K., Rekhter Y., Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling, 2007 (RFC 4761) — статья по адресу: https://tools.ietf.org/html/rfc4761].
В области технологии VPLS используются следующие термины.
Клиентская сеть (КС; в английской терминологии Client Equipment, СЕ) — это сегмент сети, содержащий клиентские компьютеры (КК) и другое клиентское оборудование, объединенный с другими КС по технологии VPLS.
Пограничный маршрутизатор (ПМ; в английской терминологии Provider Edge, РЕ) — это маршрутизатор, который служит для подключения КС к другим сегментам сети по технологии VPLS.
Внешняя сеть — это участок сети, объединяющий ПМ.
Maximum transmission unit (MTU) — это максимальный размер полезного блока данных одного пакета, который может быть передан протоколом без фрагментации. Значение MTU определяется стандартом соответствующего протокола, но может быть переопределено автоматически для определенного потока (проколом PMTUD [Mogul J., Deering S., Path MTU Discovery, 1990 (RFC 1191) — статья по адресу: https://tools.ietf.org/html/rfc1191]) или вручную для нужного интерфейса. На некоторых интерфейсах MTU по умолчанию может быть установлено ниже максимально возможного. Значение MTU ограничено снизу, как правило, минимально допустимой длиной кадра.
Maximum segment size (MSS) — это максимальный размер полезного блока данных в байтах для TCP-пакета (сегмента). Этот параметр не учитывает длину заголовков TCP и IP. Для установления корректной TCP-сессии с удаленным хостом должно соблюдаться следующее условие:
MSS + заголовок TCP + заголовок IP≤MTU,
таким образом,максимальный размер MSS=MTU — размер заголовка IP — размер заголовка TCP [Borman D., TCP Options and Maximum Segment Size (MSS), 2012 (RFC 6691) — статья по адресу: https://tools.ietf.org/html/rfc6691].
Технология VPLS позволяет объединять несколько удаленных КС в одну локальную сеть с коммутацией пакетов на канальном уровне. Сетевые узлы в каждой КС при этом взаимодействуют с узлами в других КС, обмениваясь с ними кадрами канального уровня таким же образом, как если бы оба узла находились в одной и той же КС.
Для построения единой сети канального уровня на базе VPLS каждая КС подключается к своему ПМ. Несколько ПМ, каждый из которых подключен к одной из КС, соединяются между собой с помощью построения туннельных соединений между ними. Каждый ПМ должен быть связан туннелем с каждым из остальных ПМ, образующих данный сервис VPLS, для этого может использоваться один из известных туннельных протоколов канального или сетевого уровня (MPLS, EtherIP и др. [Rosen Е., Rekhter Y., BGP/MPLS IP Virtual Private Networks (VPNs), 2006 (RFC 4364) — статья по адресу: https://tools.ietf.org/html/rfc4364; Housley R., Hollenbeck S., EtherIP: Tunneling Ethernet Frames in IP Datagrams, 2002 (RFC 3378) — статья по адресу: https://tools.ietf.org/html/rfc3378]).
При поступлении кадров из КС и от других ПМ данный ПМ производит их коммутацию, для чего ведет таблицу адресов канального уровня, связывая каждый адрес с логическим портом (в качестве порта может выступать один из сетевых интерфейсов ПМ, подключенный к одной из КС, либо один из удаленных ПМ). При получении кадра из какого-либо логического порта производится поиск адреса получателя кадра, и кадр пересылается в логический порт, связанный с данным адресом. Если адрес получателя отсутствует в таблице, либо кадр широковещательный, то создается несколько копий кадра, которые рассылаются следующим образом: если исходный кадр поступил из своей КС, то копии рассылаются во все остальные КС, а также на все удаленные ПМ; если же исходный кадр поступил от удаленного ПМ, то копии рассылаются только в своей КС.
Каждый ПМ может, помимо функций VPLS, выполнять и другие функции: в нем может происходить маршрутизация пакетов из своей КС во внешнюю сеть и обратно, а также могут работать сетевые сервисы, доступные для своей КС. Для этого ПМ имеет отдельный логический порт, соответствующий его собственной сетевой подсистеме, и в такой логический порт коммутируются кадры из своей КС, адресованные самому ПМ на канальном уровне.
При использовании VPLS от КК из КС к своему ПМ и далее к связанному ПМ другой КС через внешний участок сети передается некоторый непрерывный поток данных. При этом на КК поток разбивается на пакеты, максимально большего размера, насколько это позволяет MTU его сетевого интерфейса. В результате на портах ПМ соединенным со своей КС принимается большое количество кадров максимально возможного для Ethernet размера (1514 байт при отсутствии тегов VLAN).
Когда ПМ коммутируется такой кадр в логический порт другого ПМ, он инкапсулируется в пакет протокола канального или сетевого уровня, обеспечивающего VPLS, что приводит к дальнейшему увеличению общего размера пакета на величину соответствующих заголовков. Как правило, при использовании Ethernet, MTU всех интерфейсов ПМ одинаковы, и полученный пакет не может быть отправлен другому ПМ без фрагментации. Фрагментация позволяет успешно доставить такой пакет, однако при этом резко понижается эффективность передачи из-за необходимости для приемной стороны дожидаться полного приема всех фрагментов, прежде чем начать обработку пакета, из-за чего фрагментация практически во всех случаях рассматривается как нежелательный эффект.
Для того чтобы избежать фрагментации, необходимо тем или иным образом сообщить узлу-отправителю, что необходимо разбивать данные на IP-пакеты меньшего размера.
В общем случае, решить эту проблему достаточно сложно, но в настоящее время для надежной передачи большого объема данных в основном используется протокол транспортного уровня TCP, работающий поверх протокола IP. Протокол TCP предполагает установление сессии передачи данных и периодические подтверждения сторонами факта передачи тех или иных порций данных. При установлении сессии участники TCP-соединения обмениваются опциями максимального размера сегмента (MSS), то есть максимального размера пакета, который готов принимать участник соединения, отправляющий опцию MSS. После установки соединения каждый участник должен посылать другому участнику пакеты не большего размера, чем было указано в опции MSS. Этот механизм предоставляет удобную возможность избежать фрагментации на промежуточных узлах (маршрутизаторах, коммутаторах) при передаче пакетов протокола TCP путем уменьшения значения MSS, относящегося к данному соединению.
Достичь такого эффекта можно путем ручной настройки максимально возможного размера MSS для макетов, маршрутизируемых в сети VPLS. Известен такой способ настройки VPLS на сетевом оборудовании компании Cisco, который характерен тем, что на каждом ПМ настраивается максимальный размер MSS [Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC, Cisco support docs, Updated march 25, 2016, Document ID: 25885 — статья по адресу: https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html].
В известном способе используются следующие шаги:
для каждого ПМ на внешнем интерфейсе, связанном с другими ПМ, задают размер MSS соответствующий MTU внешнего интерфейса ПМ минус размер заголовка протокола инкапсуляции VPLS;
для каждого ПМ на внутреннем интерфейсе, связанном с собственной КС задают размер MSS равный размеру MSS на внешнем интерфейсе ПМ.
В результате, при установлении соединения КК к своему ПМ будет согласован не максимально возможный MSS в КС, а меньший, максимально возможный между ПМ, что является недостатком способа.
Кроме того, значение MSS для каждого интерфейс приходится устанавливать вручную.
При изменении максимально возможного MSS между ПМ, например, при изменении значения MTU на внешнем интерфейсе ПМ, связанном с другими ПМ, необходимо перенастраивать значение на каждом интерфейсе также вручную.
Известен также способ автоматического изменения MSS в зависимости от размера MTU интерфейсов при маршрутизации в ядре Linux 4.2.3 и старше, под названием «Clamp the MSS» (ограничение размера MSS) [Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users) — статья по адресу: http://lartc.org/howto/lartc.cookbook.mtu-mss.html, а также по адресу: https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.cookbook.mtu-mss.html].
В известном способе используются следующие шаги:
определяется максимальные значения MTU на интересующем интерфейсе (обычно внешнем, т.к. преимущественно на нем выполняется дополнительная инкапсуляция);
определяется что проходящий пакет принадлежит протоколу TCP/IP, в заголовке TCP установлен флаг SYN и присутствует опция MSS;
значение MSS автоматически уменьшается до значения MTU минус 40 байт для протокола IPv4; MTU минус 60 байт для протокола IPv6.
Таким образом, достигается согласование MSS, для выбранных интерфейсов, позволяющее маршрутизировать IP-пакеты без их фрагментации.
Известный способ принят за прототип.
Тем не менее, известный способ имеет ряд недостатков.Способ применяется для маршрутизации IP-пакетов без возможности использования при коммутации кадров ПМ с использованием VPLS.
Значения MSS устанавливаются, основываясь на заранее заданных значениях, и не позволяют максимально эффективно использовать выделенный канал.
Раскрытие изобретения
Техническим результатом является1) снижение нагрузки ПМ при использовании VPLS благодаря предотвращению фрагментации для ТСР-соединений,
2) повышение пропускной способности ПМ при использовании VPLS благодаря точному расчету максимально возможных параметров MSS при коммутации кадров,
3) снижение сложности настройки ПМ при использовании VPLS благодаря полностью автоматическому расчету параметров MSS при коммутации кадров.
Указанный результат достигается за счет применения следующего способа предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов IP, причем в состав сети входят
клиентские сети (КС), каждая из которых содержит клиентские компьютеры (КК) и пограничный маршрутизатор (ПМ);
внешнюю сеть, соединяющую все ПМ по технологии VPLS;
причем каждый ПМимеет внешний интерфейс, связанный с внешней сетью и имеющий установленное значение максимального размера полезного блока данных одного пакета, который может быть передан протоколом без фрагментации (MTU);
имеет внутренний интерфейс, связанный со своей КС и имеющий установленное значение MTU;
содержит средство обработки, выполненное с возможностью:
сравнения IP-адресов, содержащихся в кадрах запроса;
модификации кадра запроса путем изменения данных;
способ заключается в том, чтопосылают запрос от компьютера (КК1), находящегося в своей сети (КС1) на установление TCP-соединения с компьютером (КК2), находящегося в другой сети (КС2), причем запрос на канальном уровне представляет собой кадр протокола канального уровня и содержит
IP адрес КК2, находящегося в КС2;
значение максимального размера полезного блока данных для ТСР-пакета (MSS), который установлен КК1 при согласовании значений MTU своего интерфейса и внутреннего интерфейса ПМ1;
получают запрос от КК1 в ПМ1;
обрабатывают полученный кадр с запросом на установление ТСР-соединения в средстве обработки ПМ1, выполняя следующие действия:
проверяют выполнение следующих условий:
кадр содержит пакет протокола IP;
в составе пакета IP содержится заголовок протокола TCP;
в заголовке TCP установлен флаг SYN;
в заголовке TCP присутствует опция MSS;если все условия выполнены, то вычисляют максимальный размер MSS для данного TCP-соединения, выполняя следующие действия:
вычисляют значение MSS для внутреннего интерфейса ПМ1, путем вычитания из установленного значения MTU общего размера заголовков IP и TCP;
вычисляют объем дополнительных заголовков инкапсуляции для связи ПМ1 с ПМ2 с учетом используемого протокола VPLS;
вычисляют максимальный размер MSS, вычитая из ранее вычисленного значения MSS объем дополнительных заголовков инкапсуляции;
если указанное в заголовке значение MSS больше вычисленного максимального значения MSS, то
записывают вычисленное значение MSS в кадр;
вычисляют новую контрольную сумму ТСР-пакета;
записывают новую контрольную сумму TCP-пакета в кадр;
передают кадр из средства в ПМ1;передают полученный из средства обработки ПМ1 кадр с запросом на установление TCP-соединения из ПМ1 в ПМ2;
получают кадр с запросом от ПМ1 в ПМ2;
обрабатывают полученный кадр с запросом на установление ТСР-соединения в средстве обработки ПМ2, выполняя следующие действия:
проверяют выполнение следующих условий:
кадр содержит пакет протокола IP;
в составе пакета IP содержится заголовок протокола TCP;
в заголовке TCP установлен флаг SYN;
в заголовке TCP присутствует опция MSS;если все условия выполнены, то вычисляют максимальный размер MSS для данного TCP-соединения, выполняя следующие действия:
вычисляют значение MSS для внешнего интерфейса ПМ2, путем вычитания из установленного значения MTU общего размера заголовков IP и TCP;
вычисляют объем дополнительных заголовков инкапсуляции для связи ПМ1 с ПМ2 с учетом используемого протокола VPLS;
вычисляют максимальный размер MSS, вычитая из ранее вычисленного значения MSS объем дополнительных заголовков инкапсуляции;
если указанное в заголовке значение MSS больше вычисленного максимального значения MSS, то
записывают вычисленное значение MSS в кадр;
вычисляют новую контрольную сумму ТСР-пакета;
записывают новую контрольную сумму TCP-пакета в кадр;
передают кадр из средства обработки в ПМ2;передают полученный из средства обработки ПМ2 кадр с запросом на установление TCP-соединения через внутренний интерфейс ПМ2 в КК2;
получают кадр с запросом в КК2;
формируют в КК2 ответ для КК1;
завершают установку TCP-соединения между КК1 и КК2.В реальной сети, например, корпоративной, компьютеры отдельных пользователей (клиентов) или КК, расположены в территориально удаленных сегментах сети (КС), имеют выход во внешнюю сеть, например, Интернет, через отдельный маршрутизатор (названный выше ПМ). Данные ПМ организуют сеть VPLS, а каждая КС подключается к своему ПМ. Несколько ПМ, каждый из которых подключен к одной из КС, соединяются между собой с помощью построения туннельных соединений между ними. Каждый ПМ должен быть связан туннелем с каждым из остальных ПМ, образующих данный сервис VPLS, для этого может использоваться один из известных туннельных протоколов канального или сетевого уровня (MPLS, GRE, EtherIP и др.)
Каждый ПМ, например, может представлять собой программно-аппаратный комплекс (ПАК) на базе какой-либо ОС (Linux).
Для реализации предложенного способа в состав комплекса включают средство обработки, реализованное в виде программного модуля.
В данном модуле обрабатываются все кадры (на втором уровне модели OSI), проходящие через ПМ. Для кадров, коммутируемых между удаленными ПМ и локальной КС, либо между локальной КС и удаленными ПМ, проверяется, что в кадре содержится пакет TCP с установленным флагом SYN, что указывает на первый этап «трехэтапного согласования» (англ. three way handshake) установки TCP соединения, и присутствует опция MSS. Кадры, удовлетворяющие таким условиям, подвергаются дальнейшей обработке.
Для таких кадров вычисляется размер MSS для сетевого интерфейса, через который получен кадр. Из значения MTU интерфейса вычитается размер заголовков IP 20 байт и TCP 20-60 байт. Далее вычисляется объем дополнительных заголовков инкапсуляции VPLS для связи с удаленным ПМ, в зависимости от реализации протокола инкапсуляции он может иметь разное значение, например, 2 байта при использовании etherip [Borman D., TCP Options and Maximum Segment Size (MSS), 2012 (RFC 6691) — статья по адресу: https://tools.ietf.org/html/rfc6691]. Объем дополнительных заголовков инкапсуляции VPLS также вычитается из ранее вычисленного размера MSS. Вычисленный максимальный размер MSS сравнивается с указанным в заголовке TCP. Если указанный в заголовке размер MSS больше вычисленного максимального, то MSS в заголовке TCP заменяется на вычисленный, контрольная сумма TCP-пакета пересчитывается и записывается в кадр.
После окончания процесса «трехэтапного согласования» устанавливается TCP-соединение со значением максимального размера MSS, позволяющего осуществлять передачу пакетов без фрагментации.
Таким образом, преимуществом предложенного способа, по сравнению с известными, состоит в том, что подсчет максимально допустимого значения MSS автоматизирован и не требует первоначальных и дополнительных настроек.
За счет этого также достигается:
1) снижение нагрузки ПМ при использовании VPLS благодаря предотвращению фрагментации для ТСР-соединений,
2) повышение пропускной способности ПМ при использовании VPLS благодаря точному расчету максимально возможных параметров MSS при коммутации кадров,
3) снижение сложности настройки ПМ при использовании VPLS благодаря полностью автоматическому расчету параметров MSS при коммутации кадров.
Осуществление изобретения
Рассмотрим осуществление предложенного способа в сети с коммутацией IP-пакетов. Это может быть корпоративная сеть, имеющая один основной сегмент — КС с установленным DHCP сервером и множеством сегментов сетей удаленных офисов — КС, подключенных через различных провайдеров сети Интернет по технологии VPLS, для создания сети с коммутацией пакетов на канальном уровне (с одним сегментом broadcast). В такой сети можно использовать простые сетевые устройства (принтеры, сканеры, IP-телефоны), устройства для конференцсвязи, использующие мультикаст-сообщения, и другие клиентские устройства.
В рассматриваемую сетевую конфигурацию входят:
КК, расположенные в КС,
ПМ, к которым подключается КС.Количество КК и КС может быть значительным, например, несколько сотен КС, в каждой из которых несколько десятков КК.
В качестве ПМ используется высокопроизводительный ПАК HW1000Q4 на базе Intel Celeron G1820 с тактовой частотой 2,7 ГГц, объемом оперативной памяти 2 Гб, объемом жесткого диска 500 Мб, с установленной ОС Linux Debian 7 (ядро 3.10.108). ПАК HW1000Q4 содержит несколько сетевых интерфейсов (4 проводных Ethernet) [9. ViPNet Coordinator HW1000 v3 — статья по адресу: https://infotecs.ru/product/vipnet-coordinator-hw1000-versiya-3.html].
В состав каждого ПАК входит специализированное ПО — программный модуль средства обработки.
Для реализации способа программный модуль необходимо сформировать и установить в ПАК. Разработку модуля может выполнить специалист по программированию (программист), например, на языке программирования С, зная выполняемые ПО функции:
сравнения IP-адресов, содержащихся в кадрах запроса,
модификации кадра запроса путем изменения данных.После установки программного модуля средства обработки во все ПМ можно непосредственно реализовать предложенный способ.
Для этого ПМ, к которым подключаются КС, запускаются в рабочем режиме. В нескольких КС запускаются КК. КК из одной КС пытается установить соединение с КК из другой КС:
посылают запрос от компьютера (КК1), находящегося в своей сети (КС1) на установление TCP-соединения с компьютером (КК2), находящегося в другой сети (КС2), причем запрос на канальном уровне представляет собой кадр протокола канального уровня и содержит
IP адрес КК2, находящегося в КС2;
значение максимального размера полезного блока данных для ТСР-пакета (MSS), который установлен КК1 при согласовании значений MTU своего интерфейса и внутреннего интерфейса ПМ1;
получают запрос от КК1 в ПМ1;
обрабатывают полученный кадр с запросом на установление ТСР-соединения в средстве обработки ПМ1, выполняя следующие действия:
проверяют выполнение следующих условий:
кадр содержит пакет протокола IP;
в составе пакета IP содержится заголовок протокола TCP;
в заголовке TCP установлен флаг SYN;
в заголовке TCP присутствует опция MSS;если все условия выполнены, то вычисляют максимальный размер MSS для данного TCP-соединения, выполняя следующие действия:
вычисляют значение MSS для внутреннего интерфейса ПМ1, путем вычитания из установленного значения MTU общего размера заголовков IP и TCP;
вычисляют объем дополнительных заголовков инкапсуляции для связи ПМ1 с ПМ2 с учетом используемого протокола VPLS;
вычисляют максимальный размер MSS, вычитая из ранее вычисленного значения MSS объем дополнительных заголовков инкапсуляции;
если указанное в заголовке значение MSS больше вычисленного максимального значения MSS, то
записывают вычисленное значение MSS в кадр;
вычисляют новую контрольную сумму ТСР-пакета;
записывают новую контрольную сумму TCP-пакета в кадр;
передают кадр из средства в ПМ1;передают полученный из средства обработки ПМ1 кадр с запросом на установление TCP-соединения из ПМ1 в ПМ2;
получают кадр с запросом от ПМ1 в ПМ2;
обрабатывают полученный кадр с запросом на установление ТСР-соединения в средстве обработки ПМ2, выполняя следующие действия:
проверяют выполнение следующих условий:
кадр содержит пакет протокола IP;
в составе пакета IP содержится заголовок протокола TCP;
в заголовке TCP установлен флаг SYN;
в заголовке TCP присутствует опция MSS;если все условия выполнены, то вычисляют максимальный размер MSS для данного TCP-соединения, выполняя следующие действия:
вычисляют значение MSS для внешнего интерфейса ПМ2, путем вычитания из установленного значения MTU общего размера заголовков IP и TCP;
вычисляют объем дополнительных заголовков инкапсуляции для связи ПМ1 с ПМ2 с учетом используемого протокола VPLS;
вычисляют максимальный размер MSS, вычитая из ранее вычисленного значения MSS объем дополнительных заголовков инкапсуляции;
если указанное в заголовке значение MSS больше вычисленного максимального значения MSS, то
записывают вычисленное значение MSS в кадр;
вычисляют новую контрольную сумму ТСР-пакета;
записывают новую контрольную сумму TCP-пакета в кадр;
передают кадр из средства обработки в ПМ2;передают полученный из средства обработки ПМ2 кадр с запросом на установление TCP-соединения через внутренний интерфейс ПМ2 в КК2;
получают кадр с запросом в КК2;
формируют в КК2 ответ для КК1;
завершают установку TCP-соединения между КК1 и КК2.В результате, устанавливается TCP-соединение со значением максимального размера MSS, позволяющем осуществлять передачу пакетов без фрагментации.
Таким образом, минимизируются задержки при обработке пакетов, и уменьшается нагрузка на сервис VPLS, при этом полностью использует доступный канал передачи, а благодаря автоматическому расчету значения максимального размера MSS не требуется дополнительных настроек, что упрощает администрирование сети.
Необходимо отметить, что возможны и другие варианты реализации предложенного способа, отличающиеся от описанного выше и зависящие от личных предпочтений при программировании отдельных действий и функций.
Claims ( 48 )
Способ предотвращения фрагментации TCP/IP-пакетов при использовании VPLS в сети с коммутацией пакетов, причем в состав сети входят
клиентские сети (КС), каждая из которых содержит клиентские компьютеры (КК) и пограничный маршрутизатор (ПМ);
внешняя сеть, соединяющая все ПМ по технологии VPLS;
причем каждый ПМимеет внешний интерфейс, связанный с внешней сетью и имеющий установленное значение максимального размера полезного блока данных одного пакета, который может быть передан протоколом без фрагментации (MTU);
имеет внутренний интерфейс, связанный со своей КС и имеющий установленное значение MTU;
содержит средство обработки, выполненное с возможностью:
сравнения IP-адресов, содержащихся в кадрах запроса;
модификации кадра запроса путем изменения данных;
заключающийся в том, чтопосылают запрос от компьютера (КК1), находящегося в своей сети (КС1), на установление TCP-соединения с компьютером (КК2), находящимся в другой сети (КС2), причем запрос на канальном уровне представляет собой кадр протокола канального уровня и содержит
IP адрес КК2, находящегося в КС2;
значение максимального размера полезного блока данных для ТСР-пакета (MSS), который установлен КК1 при согласовании значений MTU своего интерфейса и внутреннего интерфейса ПМ1;
получают запрос от КК1 в ПМ1;
обрабатывают полученный кадр с запросом на установление ТСР-соединения в средстве обработки ПМ1, выполняя следующие действия:
Описание работы файрвола в OpenWrt
Для пакетной фильтрации, NAT и изменения пакетов (mangling, манглинг) OpenWrt использует netfilter, такой же как в других Linux системах. UCI — это интерфейс настройки OpenWrt, поэтому мы будем использовать в дальнейшем это сокращение.
Файрвол UCI объединяет один и более интерфейсов в специальные зоны, которые используются для для описания правил по-умолчанию для данного интерфейса, правил пересылки пакетов между интерфейсами, а также дополнительные правила, которые не подпадают под первые два типа. В конфигурационном файле правила по-умолчанию идут первыми, но вступают в силу последними. Система netfilter является системой фильтрации с последовательной обработкой, в которой пакеты последовательно, по цепочке, обрабатываются различными правилами. Первое совпавшее правило выполняется, но оно часто выполняет переход на другую цепочку правил, по которой движется пакет пока не встретит команды ACCEPT или DROP/REJECT. Правила с такими командами выполняются последними в цепочке правил, поэтому правила по-умолчанию вступят в силу последними, а более конкретные правила будут проверяться в первую очередь.
Зоны также используются для конфигурации маскарадинга, также известного как S NAT , а также для конфигурации правил переадресации портов, более известных как редирект (port forwarding , DNAT).
Конфигурация файрвола находится в файле /etc/config/firewall . При применения настроек в силу роутер перезагружать не надо. Командой ifconfig можно посмотреть названия интерфейсов для использования в конфигурации.
Ключевые понятия файрвола iptables
iptables — это утилита для настройки межсетевого экрана linux, которая предустанавливается по умолчанию во все сборки Linux, начиная с версии 2.4. Есть она и в OpenWrt. Как и все файрволлы, iptables оперирует некими правилами (rules), на основании которых решается судьба пакета, который поступил на интерфейс сетевого устройства (роутера). Каждое правило в iptables состоит из критерия (условие, под которое должны подпадать параметры пакета или текущее соединение, чтобы сработало действие), действия (операция, которую нужно проделать с пакетом или соединением) и счётчика (считает сколько пакетов было подвержено действию правила).
Набор правил формируется в цепочки (chains) . Существует 5 базовых цепочек и различаются они в зависимости от того, какое назначение имеет пакет. Имена базовых цепочек записываются в верхнем регистре.
- PREROUTING — правила в этой цепочке применяются ко всем пакетам, которые поступают на сетевой интерфейс извне;
- INPUT — применяются к пакетам, которые предназначаются для самого хоста или для локального процесса, запущенного на данном хосте. То есть не являются транзитными;
- FORWARD — правила, которые применяются к транзитным пакетам, проходящими через хост, не задерживаясь;
- OUTPUT — применяются к пакетам, которые сгенерированы самим хостом;
- POSTROUTING — применяются к пакетам, которые должны покинуть сетевой интерфейс.
В базовых цепочках обязательно устанавливается политика по умолчанию, как правило – принимать (ACCEPT) или сбрасывать (DROP) пакеты. Действует она только в цепочках INPUT, FORWARD и OUTPUT.
Таблицы — это набор базовых и пользовательских цепочек. В зависимости от того, в какой таблице находится цепочка правил, с пакетом или соединением производятся определённые действия. Существует 5 таблиц, основные из которых:
- filter — таблица, выполняющая функции фильтрации пакетов по определённым параметрам. В большинстве случаев вы будете использовать именно её. Содержит следующие встроенные цепочки: FORWARD, INPUT, OUTPUT;
- nat — таблица, предназначенная целиком по функции трансляции сетевых адресов. Содержит следующие встроенные цепочки: PREROUTING, OUTPUT, POSTROUTING;
- mangle — таблица, предназначенная для изменения различных заголовков пакета. Можно, например, изменить TTL, количество hop’ов и другое. Содержит следующие встроенные цепочки: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING;
Этот рисунок дает довольно ясное представление о порядке прохождения пакетов через различные цепочки. В первой точке принятия решения о маршрутизации (routing decision) все пакеты, предназначенные данному хосту направляются в цепочку INPUT, остальные – в цепочку FORWARD.
Обратите внимание также на тот факт, что пакеты, с адресом назначения на брандмауэр, могут претерпеть трансляцию сетевого адреса (DNAT) в цепочке PREROUTING таблицы nat и соответственно дальнейшая маршрутизация в первой точке будет выполняться в зависимости от произведенных изменений.
Наиболее используемые действия :
- ACCEPT — разрешить прохождение пакета;
- DROP — тихо выбросить пакет, не сообщая причин;
- QUEUE — отправляет пакет за пределы логики iptables, в стороннее приложение. Это может понадобиться, когда нужно обработать пакет в рамках другого процесса в другой программе;
- RETURN — остановить обработку правила и вернуться на одно правило назад. Это действие подобно break’у в языке программирования.
Помимо этих четырех, есть ещё масса других действий, которые называются расширенными (extension modules):
- REJECT — выбрасывает пакет и возвращает причину в виде ошибки, например: icmp unreachable;
- LOG — просто делает запись в логе, если пакет соответствует критериям правила;
Есть действия, которые доступны только в определенной цепочке и таблицах, например, только в таблице nat и цепочках OUTPUT и PREROUTING доступно действие DNAT, которое используется в NAT’ировании и меняет Destination IP пакета. В той же таблице, только в цепочке POSTRUNNING доступно действие SNAT, меняющее Source IP пакета.
Отдельно остановимся на действии MASQUERADE, которое делает то же самое что SNAT, только применяется на выходном интерфейсе, когда IP адрес может меняться, например, когда назначается по DHCP.
Реализация iptables в OpenWrt
Ключевое отличие — это добавление понятия зон. Зоны не могут быть использованы для конкретных сетей (подсетей), но генерируемые правила iptables работают исключительно с пакетами на интерфейсах. Минимальная конфигурация файрвола состоит из одной из секций defaults, в котрой как минимум 2 зоны ( lan и wan ) и одно forwarding , что разрешить трафик из lan в wan .
Секция zone группирует один или несколько интерфейсов, или IP -диапазонов для использования как источник — source, или назначение — destination, для пересылки трафика между интерфейсами — forwardings, создания правил — rules, и перенаправлений — redirects. Трансляция сетей ( NAT — masquerading) для исходящего трафика также управляется на основе зон.
Внимание ! Маскирование задаётся на интерфейсе, из которого замаскированный трафик будет исходить.
Для зоны также есть правила:
правило INPUT для зоны описывает, что произойдёт с трафиком, входящим в роутер через интерфейсы этой зоны.
правило OUTPUT для зоны описывает, что произойдёт с трафиком, исходящим от самого роутера через интерфейсы этой зоны.
правило FORWARD для зоны описывает, что произойдёт с трафиком, проходящим между различными интерфейсами внутри этой зоны.
Цепочку FORWARD проходят ВСЕ пакеты, которые движутся через наш firewall/роутер. Не используйте цепочку INPUT для фильтрации транзитных пакетов, они туда просто не попадают! Через эту цепочку движутся только те пакеты, которые предназначены данному хосту.
Секция forwarding контролирует прохождение трафика между зонами и позволяет включить MSS clamping для отдельных адресов назначений (destination). В одном правиле forwarding можно указать только одно назначение. Чтобы разрешить трафик в обе стороны между зонами необходимо создать два forwardings с src и dest в каждом.
Именно поэтому в таблице Filter для зон присутствуют отдельные цепочки. Эти цепочки применяются при передачи трафика между зонами. Иначе говоря, обычный трафик от клиента в Интернет и обратно не попадает в эти цепочки, он виден только в базовой цепочке FORWARD, потому что хостом назначения не является ни интерфейс lan роутера, ни wan. При необходимости, цепочка FORWARD передает обработку в цепочки zone_lan_forward, zone_wan_forward, zone_uplink_forward.
Посмотрим на цепочки зон. Например, для lan имеются: Chain zone_lan_dest_ACCEPT, Chain zone_lan_forward, Chain zone_lan_input, Chain zone_lan_output, Chain zone_lan_src_ACCEPT. Такие же цепочки есть и для других зон, например, для wan. Как видно из скриншота, все, что попадает в цепочку по правилу input_lan_rule, пересылается в цепочку zone_lan_input, где принимается (ACCEPT). А маршрутизируемый трафик из цепочки zone_lan_forward передается в цепочки зон wan и uplink (это моя кастомная зона).
Зона zone_wan_dest — это те пакеты, которые адресованы непосредственно интерфейсу wan (10.54.192.1 в данном случае), а не в интернет.
Как трафик попадает в эти цепочки? Ну допустим, вы обращаетесь к роутеру самому или делаете трассировку трафика, когда на каждом хопе destination’ом у вас являются разные хосты. На скриншоте мы сначала попадаем в lan интерфейс (192.168.2.1) на первом хопе, а потом в wan (10.54.192.1) на втором:
Также в OpenWrt присутствуют и таблицы NAT с цепочками PREROUTING, POSTROUTING и цепочками пре- и построутинга между зонами. маскарадинг осуществляется непосредственно на цепочка построутинга зон.
Настройка файрвола OpenWrt
Общие настройки зон находятся в разделе UCI: Network -> Firewall -> General Settings:
Пересадресация портов (Port forwardings, DNAT) определяются в секции redirect . Весь входящий трафик в указанной source зоне, который подпадает под правила, будет направлен на указанный внутренний хост. Переадресация портов также известна как маппинг портов, port forwarding и virtual servers в других роутерах.
Настройка маппинга портов выпоняется в UCI в разделе Network -> Firewall -> Port Forward. По умолчанию там пусто.
Дополнительные правила вы можете посмотреть и добавить в Network -> Firewall -> Traffic Rules. Здесь, например, настраиваются правила для ICMP и IPSec трафика.
[Посещений: 7 664, из них сегодня: 1]