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

Функционал UTM (Unified Threat Management) на Juniper vSRX (Firefly Perimeter)

Начиная с версии 12.1X47-D10.4 (junos-vsrx-12.1X47-D10.4-domestic.ova) на виртуальном роутере-фаевроле Juniper Firefly Perimeter доступен функционал Unified Threat Management (контент-фильтрация, сетевой антивирус и антиспам). Функционал не требует наличия лицензии (пробный период 60 дней), что позволяет выполнить лабораторные работы по функционалу UTM при подготовке к экзаменам JNCI*-SEC, а также опробовать возможности UTM тем, тем кто собирается использовать его на реальной сети. В этой статье будет приведён пример использования сетевого антивируса Касперский на виртуальном фаерволе Juniper по следующей схеме:
junos-vsrx-utm
Хост, подключенный к порту ge-0/0/2 натится в IP-адрес интерфейса ge-0/0/1.

Включение антивируса Касперский:

set security utm feature-profile anti-virus type kaspersky-lab-engine

После чего проверяем статус:

root@utm1# run show security utm anti-virus status    
 UTM anti-virus status: 
 
    Anti-virus key expire date: 2014-11-12 12:41:43
    Update server: http://update.juniper-updates.net/AV/JSR/
           Interval: 60 minutes
           Pattern update status: N/A
           Last result: N/A
    Anti-virus signature version: not loaded
    Anti-virus signature compiler version: N/A
    Scan engine type: kaspersky-lab-engine
    Scan engine information: last action result: Engine not ready

Как видно из вывода, не хватает антивирусных баз. Continue reading

Виртуальные CPE с помощью Cisco IOS, VRF, DHCP и NAT

vCPE-scheme

В последнее время не редко можно встретить упоминание концепции vCPE – виртуальной CPE на стороне оператора, технически это означает L2 до оператора (т.е оператор терминирует все абонентские устройства). Причины такого подхода могут быть разные – от персонифицированного родительского контроля до нежелания/неспособности абонента настраивать свою CPE (пробрасывать порты, вешать ACL-и т.п). В этой заметке рассматривается следующий сценарий: каждому абоненту выделяется статический внешний IP, локальная сеть пробрасывается отдельным вланом до устройства vCPEs, в локальной сети используется адресация 192.168.1.0/24 (по желанию абонента может быть изменена), абоненту предоставляются сервисы DHCP, source NAT и NAT port forwarding. В примере используется оборудование Cisco 7200 с ПО “c7200-advipservicesk9-mz.152-4.S5.bin”, но аналогичная конфигурация может быть применена и на современном оборудовании Cisco с ПО IOS или IOS-XE.
Continue reading

NAT(NAPT) и CG-NAT на оборудовании Cisco ASR1000 / CSR1000V

Задача: имея внешний пул IP-адресов (например, два префикса /24), организовать трансляцию приватных адресов на имеющиеся реальные адреса. В этой статье приватными адресами будут 100.64.0.0/16, а реальными 198.51.100.0/24 и 203.0.113.0/24.

Обычный NAPT

Cisco ASR1k / CSR1000V network scheme

При написании этой заметки использовался виртуальный маршрутизатор CSR1000V (IOS-XE 3.13.01.S), программный эквивалент оборудования Cisco ASR 1000 Series. Минимальная конфигурация для реализации этой схемы:

interface GigabitEthernet1
 ip address 192.0.2.1 255.255.255.252
 ip nat outside
!
interface GigabitEthernet2
 ip address 100.64.0.1 255.255.255.252
 ip nat inside
!
ip route 0.0.0.0 0.0.0.0 192.0.2.2
ip route 100.64.0.0 255.255.0.0 100.64.0.2
ip route 198.51.100.0 255.255.255.0 Null0
ip route 203.0.113.0 255.255.255.0 Null0
!
ip access-list extended nat-cust
 permit ip 100.64.0.0 0.0.255.255 any
!
ip nat translation syn-timeout 10000 //исключительно для удобства тестирования
ip nat translation max-entries 512000 //лимит по умолчанию всего 128к
ip nat pool nat-pool prefix-length 24
 address 198.51.100.0 198.51.100.255
 address 203.0.113.0 203.0.113.255
ip nat inside source list nat-cust pool nat-pool overload //задаёт какие серые адреса в какие белые NAT-ить

Далее возникает вопрос, каким образом будут распределяться реальные адреса, будет ли постоянна связки customer source ip и external source ip, каким образом логировать трансляции и сопутствующие вопросы.
Continue reading