Tag Archives: Linux

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

Установка и запуск 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 в Linux (IGMPv3 и IGMPv2)

В продолжение предыдущей заметки о статической маршрутизации multicast в Linux, это статья опишет возможности приложения mcproxy, которое управляет mroute-таблицей ядра Linux, исходя из IGMP-сигнализации. В отличии от всех остальных вариантов(igmpproxy с патчем и т.п.), mcproxy нормально работает с IGMPv3 (не падает). Использовалась версия из git (6638aa9), ОС Ubuntu Linux 14.04, ядро 3.13.0-32, iproute2 3.12.0-2

Если быть кратким, то смысл статьи в конфигурации из двух строчек (/etc/myproxy.conf):

protocol IGMPv3;
pinstance myProxy: ppp1 ==> eth0 tun0;

(В этом примере мультикаст принимается из ppp-тунеля и реплицируется (при наличии запросов снизу) в eth0 и тунельный интерфейс tun0)
И строки запуска:

# mcproxy -r -f /etc/mcproxy.conf

Continue reading

Linux Network Namespaces: Examples of Usage

Linux core starting from the version 2.6.29 has quite interesting and useful function – network namespaces(netns), nevertheless people either don’t know about it, or don’t understand what to do with it. This post reviews several possible usage examples of this functionality:

  • L3VPN monitoring with ovelapped address space using zabbix and zabbix-proxy
  • Automated testing of network software (dhcp, pppoe-servers etc.)
  • Providing L3VPN service with additional services (NAT, DHCP and others) and CPE virtualization as a special case of this task
  • Isolation of server controls from other services

The function is similar to Cisco VRF, but even more does it remind about Juniper logical-system. Besides, the above-stated tasks can be solved by creating a set of conventional virtual machines or OpenVZ containers. Traditional virtualization is not exactly practical when dealing with pure network “isolation” tasks, and anyway it has its expenses (including expenses for maintenance). OpenVZ is nearly perfect, though it isn’t commited to the upstream and therefore limits you in the choice of the core version and chains you with dependancy. Continue reading

Использование Source Specific Multicast (SSM) (IGMPv3)

Введение (можно пропустить)

Отличие Source Specific Multicast от “обычного”(Any Source Multicast(ASM)) в его сигнализации и фильтрации. Формально, существует 3 модели распространения multicast – ASM, SFM(source filtered multicast) и SSM. Но в действительности, с точки зрения запроса мультикаст-трафика со стороны клиента, SSM можно рассматривать как частный случай SFM. Модель SSM подразумевает, что мультикаст группы принадлежат к диапазону адресов 232.0.0.0/8, а IGMPv3 exclude mode запросы не отправляются клиентом и игнорируются свитчами и роутерами, их обрабатывающими.

В классическом варианте, внутри сети оператора используется протокол PIM для распространения мультикаста между роутерами, при этом задействуются RP(точка(и) рандеву) для регистрации источников (S,G) и получения информации о них роутерами, у которых клиенты запросили мультикаст. Использование IGMPv3 в режиме include mode и отказ от exclude mode позволяет избавиться от этих RP, что упрощает конфигурацию сети и, вообще говоря, повышает надёжность(за счёт понижения сложности). Использование адресов 232.0.0.0/8 позволяет роутерам понять что от них хотят, когда вещают или запрашивают мультикаст от них. Получая такой мультикаст(data-трафик), роутер знает, что его не надо регистрировать на RP (сеть может быть смешанная и использовать 1, 2 или 3 модели распространения multicast), а получая IGMPv3 запрос от клиента(include mode) на запрос канала из сети 232.0.0.0/8, роутер не пытается его интерпретировать как ASM с фильтром(т.е. SFM), а сразу шлёт PIM JOIN для построения SPT, если канал (S,G) ранее не был подключен. В терминологии SSM канал определён как (S,G). В общем случае(в зависимости от оборудования) можно изменить диапазон адресов, относящийся к SSM.

IGMPv3 клиент и генератор multicast

Рассмотрим IGMPv3 в контексте CE-устройства, т.е. как запросить SSM по IGMPv3 и как его обработать. Continue reading

VXLAN в Linux (unicast mode)

VXLAN это L2 over L3, некий аналог mpls псевдопровода и vpls, но поверх L3 сети, без использования mpls. В последнее время, всё больше и больше вендоров склоняются именно к этому варианту L2 поверх L3, многие реализуют vxlan на аппаратном уровне.

В классическом случае, vxlan использует multicast для передачи broadcast и unknown unicast, т.е. широковещательный трафик инкапсулируется в multicast и передаётся всем маршрутизаторам, участвующем в vxlan. Пример такой конфигурации для Cisco CSR1000V можно найти здесь.

Использование мультикаст влечёт за собой очевидную проблему – ограничение области применения. Если речь идёт про public internet, то про multicast можно забыть. Однако, существует вариация vxlan, не использующая multicast, при этом vxlan либо вырождается в псевдопровод, либо требуется сигнализация, чтобы участники vxlan знали друг о друге. В этой заметке речь пойдёт именно об использовании vxlan для организации L2 точка-точка поверх L3. При написании статьи использовалось ядро linux 3.15.3 и iproute2 3.15 Continue reading

QoS в Linux: tbf (token bucket filter)

TBF является классовой дисциплиной, предназначенной для шейпинга(shaping) трафика, т.е. подразумевается наличие буфера пакетов, в отличии от полисинга(policing). В Linux дисциплина tbf имеет следующие ключевые возможности: ограничение средней и максимальной скоростей, возможность задания другой дисциплины для управления очередью(буфером пакетов), что позволяет распределить трафик внутри заданной полосы, например с помощью абсолютной приоритезации или честного(fair) распределения потоков.

В самом простейшем случае, алгоритм работы tbf можно представить таким образом:

tbf token bucket
Continue reading