Прикладная дебианавтика

06.09.2010

В версии Shorewall 4.4.6 появился новый способ управления трафиком. Очень подходит для шлюза, поскольку прост в настройке и даёт моментальный эффект. В частности, я могу быть уверен, что траффик bittorrent изнутри сети не займёт наглухо весь канал. Я так же могу быть уверен, что голосовая связь будет работать вне зависимости от того насколько канал нагружен. Всё это имеет свои ограничения. Больше, чем канал может пропустить он, разумеется, пропускать не станет. Но утилизация канала в единицу времени однозначно повысится.

Вот здесь можно ознакомиться с подробным мануалом на английском. Я же обрисую конфигурацию в двух словах.

16.06.2010

Нужно запомнить раз и навсегда, а лучше вытатуировать это себе на указательном пальце. При подключении через pppoe, pptp, l2tp и вообще при любой инкапсуляции ppp, шлюзу требуется фича TCP Clamp MSS to PMTU. В Shorewall 4.4 (а скорее всего и раньше) она включается установкой параметра CLAMPMSS в значение Yes (смотреть в /etc/shorewall/shorewall.conf).

О приятном. Теперь у меня толстенный по местным меркам канал в 5 мегабит от Билайн. О способе настройки когда-то писал. Актуально, за минусом того, что xl2tpd теперь подойдёт из стабильного репозитария.

Update

Вникал в суть проблемы. У явления её обуславливающего есть название: Path MTU Discovery Black Hole и оно описано в RFC 2923. Суть его в том, что какой-то из маршрутизаторов между моим шлюзом и целевым хостом не пропускает ICMP-пакеты. Подробности здесь.

27.12.2007

Я уже писал про двух провайдеров, которые разделили рынок в моём городе. За прошедшее время ситуация резко изменилась в лучшую сторону. В моём районе начал обслуживание Спарк. А ЦТС был благополучно перекуплен «Комстаром». Есть мнение, что со временем потребитель от этого сильно выиграет. Потому как более отвратительного провайдера мир не знал. Эти люди исхитрились даже получить судебный иск от своих клиентов.

Но история, которую я хочу вам поведать сегодня имеет отношение к другому провайдеру. Это ЮТК.

19.10.2007

Есть vpn-сервер. К vpn подключается несколько клиентов. Подключения в течение рабочего времени висят практически постоянно. На том же самом канале, к которому подцеплен vpn-сервер висит десяток пользователей. Всё бы ничего, но один из этих пользователей иногда делает рассылки на несколько сотен адресов (он не спамер, адреса получены вполне легально из опросников клиентов). Мзт-сервер так же является маршрутизатором (что логично) и почтовым сервером (что не очень логично, но так уж получилось). Для пользователя отправка происходит в один момент. Но после этого вся ширина канала забивается smtp-соединениями. Это почтовый сервер спешит доставить почту. Разумеется, по vpn пользователи работать какое-то время не могут.