Tag Archives: iptables

Копирование трафика между приложениями одного сервера (RADIUS и СОРМ)

Если вдруг у вас на одном сервере оказались BRAS и RADIUS-сервер, а вам надо скопировать RADIUS-аккаунтинг, то первое что приходит в голову – разнести эти сервисы по серверам и традиционным SPAN-ом скопировать нужный трафик. Однако, существует более простое решение в виде iptables TEE, а именно:

vconfig add eth1 2
ifconfig eth1.2 192.0.2.1/24 up
arp -s 192.0.2.2 00:11:22:33:44:55
iptables -t mangle -A PREROUTING -i lo -p udp --dport 1813 -j TEE --gateway 192.0.2.2

Таким образом, трафик между BRAS-ом и RADIUS-сервером, расположенных на одном сервере будет копироваться в eth1.2 Continue reading

Advertisements

Использование не непрерывных масок сети для классификации и балансировки трафика

Практически любой сетевой инженер, занимающийся эксплуатацией очень не любит десятичную форму записи маски сети. На устройствах под управлением Cisco IOS, каждый раз вводить 255.255.255.252 вместо лаконичного 30 или /30 немного раздражает. К счастью, современные сетевые ОС (Cisco IOS-XR, JunOS, Huawei VRP) позволяют использовать prefix-length вместо десятичной маски хотя бы при конфигурировании IP-адреса на интерфейсе.

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

# iptables -I INPUT -s 0.0.0.0/0.0.0.1 -m comment --comment even -j ACCEPT
# iptables -I INPUT -s 0.0.0.1/0.0.0.1 -m comment --comment odd -j ACCEPT

С помощью таких правил можно посчитать количество трафика, приходящих с чётных и нечётных IP. Для этого использована маска 0.0.0.1 (это не wildcard, это именно маска сети), которая накладывает ограничение на один единственный бит, последний. Первое правило требуется, чтобы последний бит классифицируемого IP-адреса был строго равен нулю, а второе правило, чтобы последние бит IP-адреса был равен 1.

У таких масок есть практическое применение – классификация трафика для его дальнешей балансировки. Рассмотрим пример с NAT-ом. Continue reading

Использование squid ssl_bump для просмотра содержимого https-трафика

Эта заметка является пошаговой инструкцией для осуществления расшифровки https-трафика и повторного шифрования с целью просмотра (и, при необходимости, фильтрации или изменения) его содержания при условии установки дополнительно корневого(CA) сертификата на конечное устройство. Перехват https-трафика может быть применён в следующих целях:

  1. анализ действий и высокоуровневая отладка приложений, взаимодействующих с другими хостами(серверами) по https
  2. реверс-инжиниринг протоколов, работающих поверх https
  3. фильтрация контента (например, рекламы) на сетевом шлюзе
  4. отслеживание и ограничение действий пользователей в корпоративных сетях (предотвращение утечек конфиденциальных данных)
  5. различная незаконная деятельность (кража конфиденциальная данных и т.п.) в условиях, когда конечному пользователю неизвестно об установке дополнительного корневого сертификата на его устройство

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

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

Маршрутизация multicast в Linux

В современных реалиях, скорее всего, нет смысла заниматься маршрутизацией(репликацией) multicast-трафика с помощью софтроутеров(будь то ядро Linux или что-то иное). Причина довольно простая – даже дешёвые свитчи умеют L2/L3-multicast(хоть и с ограничениями по количеству групп/маршрутов, но всё же это делается в asic-ах). Однако, существует ряд задач, которые могут быть не решены в “железе” (нет поддержки со стороны ПО/невозможно реализовать ввиду возможностей asic), например ренамберинг(изменение destination ip), внесение случайных задержек(перемешивание), отправка multicast в тунель, резервирование источника по произвольному критерию.

Зачем может потребоваться ренамберинг мультикаст группы? Во-первых, маппинг IP-mac неодназначен(например, группам 238.1.1.1 и 239.1.1.1 соответствует один и тот же mac-адрес), что может вызвать проблемы в L2-сегменте. Конечно, такая коллизия маловероятна, однако возможна, когда вы берёте multicast из разных внешних источников(в принципе, IP-адреса могут даже полностью совпасть). Во-вторых, вы можете захотеть скрыть свой источник, изменив и destination и source адрес. В destination может быть “спрятан” номер AS источника(RFC3180), по source тоже можно догадаться об источнике, если он не серый. В третьих, перенумеровать группу может потребоваться для избежания коллизии на оборудовании, где заканчивается TCAM под multicast (как временное решение до замены оборудования/изменения схемы сети). И наконец, вы решили зарезервировать ТВ-каналы путём их получения из разных источников(т.е. вливать на сервер 2 разных группы(но одинаковых по контенту) и забирать из него одну, результирующую(работающую))

Внести случайную задержку(reordering) или потери может потребоваться для проверки поведения используемых STB/soft-плееров. Например, вам интересно, как будет выглядеть картинка, если где-то на сети мультикаст пройдёт через per-packet балансировку и не зависнет ли плеер при наличии потери пакетов, будут ли издаваться неприятные скрипящие звуки или же просто квадратики и тишина. Continue reading