Копирование трафика между приложениями одного сервера (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

Top-10 ошибок настройки/дизайна СПД в ISP

1. Вся сеть (или большие сегменты) в одном VLAN. Аналогично и с управлением оборудованием. Совсем печальный случай, когда и управление и data-трафик находятся в одном единственном default VLAN. Такие схемы нормально не работают, проблемы практически не поддаются траблшутингу. Совсем хорошо, когда между абонентами нет L2-взаимодейтсвия, а в идеале, когда они не могут влиять друг на друга по мак-таблице.

2. Анонс своей сети, не имея её в таблице маршрутизации (популярные в небольших ISP Quagga и Mikrotik RouterOS это позволяют). Эффект этого очевиден для любого грамотного инженера – петля маршрутизации. Обычно такое происходит при совмещении ASBR и BRAS в одной железке, про роут сети в NULL0/blackhole забывают.

3. Использование слишком сложных схем резервирования на L2. Кольца доступа+кольца агрегационных свитчей, да ещё и замыканией колец доступа на различных узлах агрегации и всё это с использованием какой-либо вариации STP или его аналога ни к чему хорошему не приводят. Аварий из-за слишком сложной топологии становится больше, чем пользы от такого резервирования.
Continue reading

Установка и запуск Debian 8.0 (Jessie) ARM64 в QEMU

Уже сейчас можно купить(архив) сервер enterprise класса с ARM64(AArch64) CPU. Вероятно в будущем, arm64 составит реальную конкуренцию x86_64 в серверном сегменте, а пока далеко не у всех есть железо, на котором можно потестировать работоспособность приложений под arm64. В этой заметке будет представлена пошаговая инструкция как установить и запустить Debian 8.0 (Jessie) ARM64 в QEMU, при этом на хост-машине используется x86_64 Ubuntu 14.04.1. Continue reading

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

Практически любой сетевой инженер, занимающийся эксплуатацией очень не любит десятичную форму записи маски сети. На устройствах под управлением 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

Удалённое администрирование с помощью ssh socks tunnel, socks proxifier и ssh port forwarding

Этот пост не имеет прямого отношения к тематике ISP и сетям в целом, однако, современные реалии таковы, что чаще всего оборудование, которое вам нужно администрировать недоступно напрямую с рабочей машины или с одного терминального сервера и требуется зайти на 1-2-3 сервера, прежде чем залогиниться на целевой хост. Для начала, рассмотрим наиболее простой случай, когда целевые хосты доступны с терминального сервера, а сам терминальный сервер доступен с рабочего места:

ssh-socks-proxy

Целевыми хостами здесь являются Router1(управление по протоколам telnet/ssh), Windows Server rdesktop1(управление по протоколу RDP) и Application Server webserv1(управление по протоколам http/https). Предполагается, что на терминальном сервере запущен ssh-сервер OpenSSH, а рабочее место это PC, работающий на Windows, OS X или Linux. Кроме того, предполагается, что терминальный сервер доступен только по протоколу ssh с рабочего места, поэтому прочие способы добраться до целевых хостов недоступны (например, запуск vnc- или прокси-сервера на терминальном сервере) Continue reading

Неоднозначность преобразования multicast IP-группы в mac-адрес и L2 свитч

Не так давно меня попросили разобраться в проблеме появления лишнего трафика на порту свитча Cisco 4924, к которому подключен преобразователь из IP-мультикаст в DVB-C или аналоговый сигнал (проще говоря, некая железка для организации услуги кабельного телевидения, не знаю точно чем она занимается). Схема включения включения выглядит так:

L2-multicast-scheme

Устройства MR1, MR2, MR3 – преобразователи IP multicast в КТВ-сигнал, далее просто потребители мультикаста. На порту Gi1/1 свитча sw1 по графику утилизации было примерно 110Мбит/с, а инженер, ответственный за оборудование MR1 утверждал, что он запрашивает мультикаста всего на 70Мбит/с, тем самым возник вопрос откуда взялось ещё 40Мбит/с трафика. Порты свитча Te1/29, Gi1/1, Gi1/2 включены в vlan 10, в vlan 10 igmp-snooping включен, таблица igmp-snooping содержит записи, ничего подозрительно замечено не было. Continue reading