netfilter nat чем плох

Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением Linux, а также приведены некоторые уточнения по поводу распределения прерываний.

Прерывания

Раскидывание прерываний сетевых карт по разным ядрам — это самое первое, с чем сталкивается сисадмин при возрастании нагрузки на linux-маршрутизатор. В упомянутой статье тема освещена достаточно подробно — поэтому надолго останавливаться на этом вопросе мы не будем.

Хочу только отметить:

Маршрутизатор

В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно. Конечно, на небольших потоках тюнинг не играет большой роли. Однако, если у вас большая сеть и соответствующая нагрузка — то тюнингом сетевого стека вам придется заняться.

Прежде всего, если по вашей сети «гуляют» гигабиты, то имеет смысл обратить свое внимание на MTU на ваших серверах и коммутаторах. В двух словах, MTU — это объем пакета, который можно передать по сети, не прибегая к его фрагментации. Т.е. сколько информации ваш один маршрутизатор может передать другому без фрагментирования. При значительном увеличении объемов передаваемых по сети данных, гораздо эффективнее передавать пакеты большего объема реже, — чем часто-часто пересылать мелкие пакеты данных.

Увеличиваем MTU на linux

/sbin/ifconfig eth0 mtu 9000

Увеличиваем MTU на коммутаторах

На коммутационном оборудовании обычно это будет называться jumbo-frame. В частности, для Cisco Catalyst 3750

3750(config)# system mtu jumbo 9000
3750(config)# exit
3750# reload

Заметьте: коммутатор затем надо перезагрузить. Кстати, mtu jumbo касаются только гигабитных линков, — 100-мбит такая команда не затрагивает.

Увеличиваем очередь передачи на linux

/sbin/ifconfig eth0 txqueuelen 10000

По умолчанию значение стоит 1000. Для гигабитных линков рекомендуется ставить 10000. В двух словах, это размер буфера передачи. Когда буфер наполняется до этого граничного значения, данные передаются в сеть.

Имейте ввиду, что если вы меняете размер MTU на интерфейсе какой-то железки — вы должны сделать то же самое и на интерфейсе её «соседа». Т.е., если вы увеличили MTU до 9000 на интерфейсе linux-роутера, то вы должны включить jumbo-frame на порту коммутатора, в который данный роутер включен. В противном случае сеть работать будет, но очень плохо: пакеты ходить по сети будут «через одного».

Итоги

В результате всех этих изменений, в сети возрастут «пинги» — но общая пропускная способность заметно возрастет, а нагрузка на активное оборудование снизится.

Сервер NAT

Операция NAT (Network Address Translation) является одной из самых дорогостоящих (в смысле, ресурсоёмких). Поэтому, если у вас большая сеть, без тюнинга NAT-сервера вам не обойтись.

Увеличение кол-ва отслеживаемых соединений

Для осуществления своей задачи, NAT-серверу необходимо «помнить» обо всех соединениях, которые через него проходят. Будь то «пинг» или чья-то «аська» — все эти сессии NAT-сервер «помнит» и отслеживает у себя в памяти в специальной таблице. Когда сессия закрывается, информация о ней из таблицы удаляется. Размер этой таблицы фиксирован. Именно поэтому если трафика через сервер идет достаточно много, а размера таблицы нехватает, — то NAT-сервер начинает «дропать» пакеты, рвать сессии, интернет начинает работать с жуткими перебоями, а на сам NAT-сервер бывает даже попасть по SSH становится просто невозможно.

Чтобы таких ужасов не происходило, необходимо адекватно увеличивать размер таблицы — в соответствии с проходящим через NAT трафиком:

Настоятельно НЕ рекомендуется ставить такое большое значение, если у вас на NAT-сервере меньше 1 гигабайта оперативной памяти.

Посмотреть текущее значение можно вот так:

Посмотреть, насколько уже заполнена таблица отслеживания соединений, можно вот так:

Увеличение размера hash-таблицы

Пропорционально должная быть увеличена и хэш-таблица, в которой хранятся списки conntrack-записей.

echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

Правило простое: hashsize = nf_conntrack_max / 8

Уменьшение значений time-out

Как вы помниите, NAT-сервер отслеживает только «живые» сессии, которые через него проходят. Когда сессия закрывается — информация о ней удаляется, дабы таблица не переполнялась. Информация о сессиях удаляется так же по тайм-ауту. Т.е., если втечение долгого времени в рамках соединения обмена траифка нет — оно закрывается и информация о нем так же удаляется из памяти NAT-а.

Однако, по умолчанию значения тайм-аутов стоят достаточно большие. Поэтому, при больших потоках трафика даже если вы растянете nf_conntrack_max до предела — вы все равно рискуете быстро столкнуться с переполнением таблицы и разрывами соединений.

Чтобы такого не произошло, необходимо грамотно выставить тайм-ауты отслеживания соединений на NAT-сервере.

Текущие значения можно посмотреть, например, так:

В результате вы увидите что-то подобное:

net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15

Это значения тайм-аутов в секундах. Как вы видите, значение net.netfilter.nf_conntrack_generic_timeout равно 600 (10 минут). Т.е. NAT-сервер будет держать в памяти информацию о сессии до тех пор, пока по ней будет «пробегать» хоть что-то хотя бы раз в 10 минут.

На первый взгляд, ничего страшного — но на самом деле это очень и очень много.

Если вы посмотрите на net.netfilter.nf_conntrack_tcp_timeout_established — то вы увидите там значение 432000. Другими словами, простую TCP-сессию ваш NAT-сервер будет отслеживать до тех пор, пока по ней не пробегает какой-нибудь пакетик хотя бы раз в 5 дней(!).

Говоря еще более простым языком, за-DDOS’ить такой NAT-сервер становится проще простого: его NAT-таблица (параметр nf_conntrack_max) переполняется «на ура» простейшим флудом — вследствие чего он будет рвать соединения и в худшем варианте быстро превратится в черную дыру.

Значения тайм-аутов рекомендуется ставить в пределах 30-120 секунд. Этого вполне достаточно для нормальной работы абонентов, и этого вполне хватит для своевременной очистки NAT-таблицы, исключающей её переполнение.

И не забудьте вписать соответствующие изменения в /etc/rc.local и /etc/sysctl.conf

Итоги

После тюнинга вы получите вполне жизнеспособный и производительный NAT-сервер. Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей. Однако, в большинстве случаев даже таких простых действий будет достаточно для нормальной работы достаточно большой сети. Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.

Источник

Архитектура Iptables и Netfilter

Брандмауэры – важный инструмент, который может защитить ваш сервер и инфраструктуру. В экосистеме Linux iptables – широко используемый инструмент для настройки брандмауэра, который взаимодействует с базой фильтрации пакетов netfilter. Пользователи и администраторы, которые не понимают архитектуру этих систем, столкнутся при их настройке со многими трудностями, связанными со сложным синтаксисом и внутренними связями компонентов.

Данная статья расскажет вам об архитектуре iptables и поможет создать политику брандмауэра. Вы узнаете, как iptables взаимодействует с netfilter и как различные компоненты взаимодействуют, чтобы обеспечить комплексную систему фильтрации и обработки.

Что такое IPTables и Netfilter?

IPTables – это основное программное обеспечение брандмауэра, наиболее часто используемое в Linux. Брандмауэр iptables работает, взаимодействуя с хуками фильтрации пакетов в сетевом стеке ядра Linux. Эти хуки называются фреймворком netfilter.

Каждый пакет в сети (входящий или исходящий) будет запускать эти хуки по мере прохождения через стек, позволяя программам, которые регистрируют эти хуки, взаимодействовать с трафиком в ключевых точках. Модули ядра, связанные с iptables, регистрируют эти хуки, чтобы убедиться, что трафик соответствует условиям, установленным правилами брандмауэра.

Хуки netfilter

Программы могут регистрировать пять фильтров-хуков netfilter. По мере продвижения пакетов через стек, они будут запускать модули ядра, которые зарегистрировались в этих хуках. Хуки, которые запускает пакет, зависят от того, является ли пакет входящим или исходящим, был ли он отклонен в предыдущей точке, а также от места назначения пакета.

Следующие хуки представляют собой четко определенные точки в сетевом стеке:

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

Таблицы и цепочки iptables

Брандмауэр iptables использует таблицы для систематизации правил. Эти таблицы классифицируют правила в соответствии с типом решений, которые они принимают. Например, если правило касается преобразования сетевых адресов, оно будет помещено в таблицу nat. Если правило используется для принятия решения о том, пропустить ли пакет к его цели, оно, вероятно, будет добавлено в таблицу filter.

В каждой таблице iptables правила организованы в отдельные цепочки. Таблицы определяют общую цель правил, а встроенные цепочки представляют собой хуки netfilter, которые запускают их. Цепочки в основном определяют, когда будут использоваться те или иные правила.

Имена встроенных цепей зеркально отражают имена хуков netfilter, с которыми они связаны:

Цепочки позволяют администратору указать, где на пути доставки пакета будет оцениваться то или иное правило. Поскольку каждая таблица имеет несколько цепочек, она может влиять на пакет в нескольких точках обработки.

Существует только пять хуков ядра netfilter, поэтому на каждом из хуков регистрируются цепочки из нескольких таблиц. Например, в трех таблицах есть цепочки PREROUTING. Когда эти цепочки регистрируются на связанном хуке NF_IP_PRE_ROUTING, они задают свой приоритет – это определяет, в каком порядке вызываются цепочки PREROUTING из каждой таблицы. Сначала последовательно оцениваются все правила в цепочке PREROUTING с наивысшим приоритетом, а затем пакет может перейти к следующей цепочке PREROUTING.

Какие бывают таблицы iptables?

Давайте подробнее рассмотрим разные таблицы, которые предоставляет iptables. Эти таблицы представляют собой различные наборы правил, сгруппированные по цели.

Таблица filter

Таблица filter является одной из наиболее широко используемых таблиц в iptables. Она решает, следует ли передавать пакет в место назначения или следует отклонить его запрос. На языке брандмауэра это называется фильтрацией пакетов. Эта таблица обеспечивает основную функциональность брандмауэра.

Таблица NAT

Таблица nat используется для реализации правил преобразования сетевых адресов. Когда пакеты входят в сетевой стек, правила в этой таблице определяют, следует ли изменять исходные или целевые адреса пакета, чтобы повлиять на его маршрутизацию, и как это сделать. Эта таблица часто используется для маршрутизации пакетов в сети при отсутствии прямого доступа.

Таблица mangle

Таблица mangle используется для изменения IP-заголовков пакета. Например, вы можете настроить значение TTL (Time to Live) пакета, увеличивая или сокращая количество действительных сетевых переходов, которые может поддерживать пакет. Другие IP-заголовки можно изменить аналогичным образом.

Эта таблица также может маркировать пакет для дальнейшей обработки в других таблицах и других сетевых инструментах.

Таблица raw

Iptables – брандмауэр с отслеживанием состояний, то есть пакеты оцениваются в контексте их отношения к предыдущим пакетам. Функции отслеживания соединений, основанные на netfilter, позволяют iptables рассматривать пакеты как часть текущего соединения или сеанса, а не как поток дискретных несвязанных пакетов. Логика отслеживания соединений обычно применяется сразу после того, как пакет попадает в сетевой интерфейс.

Таблица raw имеет очень узкую функцию. Ее единственная цель – предоставить механизм для маркировки пакетов для отказа от отслеживания соединения.

Таблица security

Таблица security используется для установки внутренних меток безопасности SELinux на пакеты, что влияет на то, как SELinux (или другие системы, которые могут интерпретировать контексты безопасности SELinux) обрабатывает пакеты. Эти метки могут применяться для каждого пакета или для каждого соединения.

Какие цепочки реализуют таблицы?

Теперь давайте рассмотрим, какие цепочки доступны в каждой таблице и как определяется порядок оценки цепочек, зарегистрированных на тот же хук. Если цепочки PREROUTING встречаются в трех таблицах, в каком порядке они оцениваются?

В следующей таблице слева направо перечислены все цепочки, доступные в каждой таблице iptables. Например, в таблице raw есть цепочки PREROUTING и OUTPUT. При чтении сверху вниз нижеприведенная таблица отображает порядок, в котором вызывается каждая цепочка при срабатывании соответствующего хука.

Следует отметить несколько вещей. Ниже таблица nat была разделена между операциями DNAT (которые изменяют адрес назначения пакета) и операциями SNAT (которые изменяют исходный адрес), чтобы более четко отобразить их порядок. Также здесь представлены точки, в которых принимаются решения о маршрутизации и включается отслеживание соединений, чтобы дать более целостное представление о происходящих процессах.

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

Некоторые события приводят к тому, что цепочка таблицы во время обработки пропускается. Например, по правилам NAT будет оцениваться только первый пакет в соединении. Решение, принятое для первого пакета, будет применено ко всем последующим пакетам в соединении без дополнительной оценки.

Порядок обхода цепочек

При условии, что сервер знает, как маршрутизировать пакет, и что брандмауэр разрешил передавать его, возможны следующие пути:

Если объединить приведенную выше информацию с порядком, изложенным в предыдущей таблице, вы увидите, что входящий пакет, предназначенный для локальной системы, сначала будет оцениваться цепочками PREROUTING из таблиц raw, mangle и nat. Затем он будет перемещаться по цепочкам INPUT таблиц mangle, filter, security и nat, прежде чем будет доставлен на локальный сокет.

Правила IPTables

Правила размещаются в определенной цепочке определенной таблицы. Соответствующий пакет будет проверяться по каждому правилу в цепочке по порядку, по мере вызова каждой цепочки. Каждое правило состоит из критерия и действия.

Критерий

Критерий – это выражение, которому должен соответствовать пакет для выполнения связанного действия (или цели).

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

Действие

Действие, или цель – это описание действия, которое запускается, если пакет соответствует критериям. Действия обычно делятся на две категории:

Доступность каждого действия внутри правил будет зависеть от контекста (например, от типа таблицы и цепочки). Расширения, активированные в правиле, и соответствующие предложения могут также влиять на доступность действий.

Переход к пользовательским цепочкам

Следует упомянуть особый класс нетерминальных действий – действия перехода. Они передают оценивание пакета другой цепочке для дополнительной обработки. Мы довольно много говорили о встроенных цепочках, которые тесно связаны с хуками netfilter. Однако iptables также позволяет администраторам создавать свои собственные цепочки.

Правила можно поместить в пользовательские цепочки таким же образом, как и во встроенных цепочках. Разница в том, что пользовательские цепочки могут быть достигнуты только путем перехода к ним из правила (они не регистрируются самим хуком netfilter).

Пользовательские цепочки действуют как простые расширения той встроенной цепочки, которая их вызвала. Например, пользовательская цепочка вернет пакет вызывающей цепочке, если будет достигнут конец списка правил или если критерий активирует действие RETURN. Оценка пакета также может перейти к дополнительным пользовательским целям.

Отслеживание соединений

Мы упоминали систему отслеживания соединений, реализованную на основе netfilter, когда обсуждали таблицу raw и критерии соединения. Отслеживание соединений позволяет iptables работать с пакетами, просматриваемыми в контексте текущего соединения. Система отслеживания соединений предоставляет iptables функциональность, необходимую для выполнения операций с отслеживанием состояния.

Отслеживание соединений применяется сразу после того, как пакеты входят в сетевой стек.

Система сравнивает каждый пакет с набором существующих соединений. В случае необходимости она обновит состояние подключения в своем хранилище и добавит новые подключения. Пакеты, отмеченные целью NOTRACK в одной из цепочек raw, обходят процедуры отслеживания соединений.

Отслеживаемые соединения будут находиться в одном из следующих состояний:

Состояния в системе отслеживания соединений позволяют администраторам создавать правила, которые нацелены на определенные точки в жизненном цикле соединения. Это позволяет создавать более сложные и надежные правила.

Заключение

Система фильтрации netfilter и iptables являются основой большинства средств для настройки брандмауэра на серверах Linux. Хуки ядра netfilter обеспечивают контроль над пакетами. Брандмауэр iptables использует эти возможности для предоставления гибкого, расширяемого метода создания политики. Узнав больше о взаимодействии этих компонентов, вы можете лучше использовать их для управления и защиты своих серверных сред.

Источник

[iptables] Тонкости реализации NAT

Может кто-нибудь просветить о тонкостях реализации таблицы NAT в netfilter/iptables?

Интересует конкретная ситуация, как она будет обрабатываться.

В iptables задано два правила:

Почитал немного про разные реализации NAT и понял, что может быть по всякому, а как именно будет в iptables не знаю.

Первое: любое обращение хоста 192.168.1.4 куда-либо по протоколу udp, будь то dig @8.8.8.8 ya.ru или sip и т.д. будут направляться на хост 216.216.216.216 (на соот. порт, ессно). А будет это осуществляться благодаря второму правилу: немаршрутизируемые адреса меняются (source) на айпишнек eth1.

Это понятно. Пример так и был построен. Вопрос в том, будут ли приходить ответы? Я, к сожалению, не знаю, как проверить. Ну нет у меня под рукой ни роутера на Linux, ни сервера, который бы мне ответы усердно слал. Есть только ADSL-модем с встроенным NAT’ом да локальная машина, откуда я могу что-то отправить. Вот и спрашиваю. Так бы конечно и сам проверил и в логах посмотрел. Схема прохождения пакетов через роутер у меня на бумажке нарисована. На бумаге все замечательно выглядит, а как будет на самом деле? Я не нашел в сети информации о принципах работы nat в netfilter.

Попытаюсь еще раз объяснить. Я прекрасно понимаю, что nat в netfilter отлично работает и с DNAT, и с SNAT, и с MASQUERADE. Но по отдельности! А если пакет проходит по очереди два правила в таблице NAT, то ответный пает потом сможет найти путь до клиентской машины? Можно ли делать цепочки из правил в таблице NAT. Вот как-то так. Ведь легко может оказаться, что netfilter смотрит только первое или последнее преобразование. Или еще он может разрешать преобразования в таком же порядке, что и при отправке пакета изнутри сети (то есть опять сначала DNAT, потом MASQUERADE, а должен бы наоборот). Тогда он точно потеряет адрес назначения!

Если никто не знает ответа, придется видимо в исходниках ядра опять копаться. Хотя разбираться в дебрях кода netfilter, касающихся nat еще то удовольствие!

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

Маршрутизация ответных пакетов происходит сразу, одним действием или поэтапно, как шла маршрутизация первого пакета? Если поэтапно, то в каком порядке будут выполняться этапы? Сначала DNAT или MASQUERADE?

Как раз, схема очень хорошая. В ней явно видно, что сначала отрабатывает при входе пакета conntrack (разначинвание, по рабоче-крестьянски). А уже потом net PREROUTING с DNAT.

Источник

3 необычных кейса о сетевой подсистеме Linux

В этой статье представлены три небольшие истории, которые произошли в нашей практике: в разное время и в разных проектах. Объединяет их то, что они связаны с сетевой подсистемой Linux (Reverse Path Filter, TIME_WAIT, multicast) и иллюстрируют, как глубоко зачастую приходится анализировать инцидент, с которым сталкиваешься впервые, чтобы решить возникшую проблему… и, конечно, какую радость можно испытать в результате полученного решения.

История первая: о Reverse Path Filter

Клиент с большой корпоративной сетью решил пропускать часть своего интернет-трафика через единый корпоративный файрвол, расположенный за маршрутизатором центрального подразделения. С помощью iproute2 трафик, уходящий в интернет, был направлен в центральное подразделение, где уже было настроено несколько таблиц маршрутизации. Добавив дополнительную таблицу маршрутизации и настроив в ней маршруты перенаправления на файрвол, мы включили перенаправление трафика из других филиалов и… трафик не пошел.

Схема прохождения трафика через таблицы и цепочки Netfilter

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

Однако на исходящем интерфейсе пакетов не было. Стало ясно, что фильтруются они на маршрутизаторе, однако явно установленных правил отбрасывания пакетов в iptables не было. Поэтому мы начали последовательно, по мере прохождения трафика, устанавливать правила, отбрасывающие наши пакеты и после установки смотреть счетчики:

Проверили последовательно nat PREROUTING, mangle PREROUTING. В mangle FORWARD счетчик не увеличивался, а значит — пакеты теряются на этапе маршрутизации. Проверив снова маршруты и правила, начали изучать, что именно происходит на этом этапе.

В ядре Linux для каждого интерфейса по умолчанию включен параметр Reverse Path Filtering ( rp_filter ). В случае, когда вы используете сложную, асимметричную маршрутизацию и пакет с ответом будет возвращаться в источник не тем маршрутом, которым пришел пакет-запрос, Linux будет отфильтровывать такой трафик. Для решения этой задачи необходимо отключить Reverse Path Filtering для всех ваших сетевых устройств, принимающих участие в маршрутизации. Чуть ниже простой и быстрый способ сделать это для всех имеющихся у вас сетевых устройств:

Возвращаясь к кейсу, мы решили проблему, отключив Reverse Path Filter для интерфейса tap0 и теперь хорошим тоном на маршрутизаторах считаем отключение rp_filter для всех устройств, принимающих участие в асимметричном роутинге.

История вторая: о TIME_WAIT

В обслуживаемом нами высоконагруженном веб-проекте возникла необычная проблема: от 1 до 3 процентов пользователей не могли получить доступ к сайту. При изучении проблемы мы выяснили, что недоступность никак не коррелировала с загрузкой любых системных ресурсов (диск, память, сеть и т.д.), не зависела от местоположения пользователя или его оператора связи. Единственное, что объединяло всех пользователей, которые испытывали проблемы, — они выходили в интернет через NAT.

Механизм закрытия TCP-соединения

И выполните команду:

История третья: об OSPF и мультикастовом трафике

Обслуживаемая корпоративная сеть была построена на базе tinc VPN и прилегающими к ней лучами IPSec и OVPN-соединений. Для маршрутизации всего этого адресного пространства L3 мы использовали OSPF. На одном из узлов, куда агрегировалось большое количество каналов, мы обнаружили, что небольшая часть сетей, несмотря на верную конфигурацию OSPF, периодически пропадает из таблицы маршрутов на этом узле.

Упрощенное устройство VPN-сети, используемой в описываемом проекте

В первую очередь проверили связь с маршрутизаторами проблемных сетей. Связь была стабильной:

Продиагностировав OSPF, мы удивились еще больше. На узле, где наблюдались проблемы, маршрутизаторы проблемных сетей отсутствовали в списке соседей. На другой стороне проблемный маршрутизатор в списке соседей присутствовал:

Следующим этапом исключили возможные проблемы с доставкой ospf hello от 172.24.0.1. Запросы от него приходили, а вот ответы — не уходили:

Заключение

Какой бы сложной ни была проблема, она всегда решаема и зачастую — с помощью изучения документации. Буду рад увидеть в комментариях описание вашего опыта поиска решения сложных и необычных проблем.

Источник