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

Можно сделать это с FreeBSD (PFsense это поддерживает). Иногда полезно отключать отслеживание соединений для определённого трафика, особенно для маршрутизируемого VoIP-трафика, когда есть несколько шлюзов с резервированием. Это помогает избежать "призрачных" соединений, которые могут приводить к обрыву VoIP-канала. Без этой опции может потребоваться ручной сброс соединения (или сброс через скрипт). Из списка возможностей Pfsense: "Типы состояний — pfSense предлагает несколько вариантов обработки состояний. Сохранять состояние — работает со всеми протоколами. По умолчанию для всех правил. Модулировать состояние — работает только с TCP. pfSense будет генерировать надёжные начальные порядковые номера (ISN) от имени хоста. Состояние Synproxy — проксирует входящие TCP-соединения, чтобы защитить серверы от поддельных TCP SYN-floods. Эта опция включает функциональность "сохранять состояние" и "модулировать состояние" вместе. Ничего — не сохранять никаких записей состояния для этого трафика. Это крайне редко желательно, но доступно, поскольку может быть полезно в некоторых ограниченных случаях."

Судя по моему опыту с NAT, это всегда сложная проблема для VoIP, если у вас есть резервный шлюз для доступа в публичную сеть. Нужно вручную удалять (или используя скрипт) неправильные соединения после смены шлюза, иначе VoIP-трассы могут "задыхаться" при возвращении к основному шлюзу. Это касается и SIP, но такая же проблема может проявляться и с IAX. Думаю, что эта проблема может проявляться и для другого трафика, отправляющего пакеты практически непрерывно: соединение никогда не сбрасывается по таймауту и сохраняет неправильный адрес источника после смены шлюза. Иногда из-за NAT я даже видел, как Linux-боксы отправляют приватный IP в интернет через публичный интерфейс. Я видел это на старых OpenWRT-роутерах, которые я использовал раньше. Mikrotik действительно более мощный и проще настраивать все, особенно продвинутое маршрутизирование. Так что я использую только его сейчас, даже если NAT все еще не идеален. Linux-соединения не кажутся достаточно "умными", чтобы использовать NAT с несколькими шлюзами без помощи скрипта. Winbox и Dude – это мощнейшие инструменты для администрирования. Решение, если возможно, — использовать туннели и чистое маршрутизирование, а также добавить blackhole-маршрут к приватному подсегменту назначения (используя меньший префикс), чтобы избежать "призрачных" застрявших соединений во время переключения маршрутов. После переключения маршрутов blackhole-маршрут больше не будет использоваться, так как маршрут к подсегменту назначения будет иметь больший префикс. Это должно защитить от неправильного отслеживания соединений. Как правило, не используйте NAT, если хотите добиться высокой надежности или тщательно тестируйте его перед внедрением в продакшн.

Еще один вопрос: почему все соединения должны отслеживаться? Почему только natted соединения? Спасибо, L.

Попробуйте хотя бы версию RouterOS 6.0.

Полезная функция

Да, что-то вроде NOTRACK было бы просто замечательно. Как только отслеживание соединений выключено, максимальная пропускная способность маршрутизации увеличивается вдвое по сравнению с трафиком соединений. Есть ситуации, когда отслеживание соединений включено просто потому, что оно необходимо для src-nat. Например, несколько внутренних подсетей (RFC 1918 IP-адреса), подключенных к RB2011, который также является точкой выхода в интернет (NAT). В моей лаборатории я замерял на RB2011 разницу в 300 Мбит/с с conntrack и 600 Мбит/с без conntrack. Зачем отказываться от этих дополнительных 300 Мбит/с пропускной способности между внутренними сетями только потому, что у меня есть <100 Мбит/с канал, который нужно транслировать? Я твердо верю, что такие сценарии достаточно распространены, чтобы реализовать подобную функцию.

Расчет памяти – это просто великолепно!

Привет, Mikrotik, какие-нибудь новости по этому вопросу? Нам бы очень хотелось иметь возможность отключить отслеживание соединений для некоторых траффиков. Джулиан.