Category Archives: Lab

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

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

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

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

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

Схема подключения устройств для этой статьи выполнена следующим образом:
ssl_bump_scheme
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

PPPoE BRAS на MikroTik RouterOS (c radius-сервером)

Не смотря на то, что продукция MikroTik не является оборудованием операторского класса, его активно применяют на начальном этапе строительства небольших сетей в странах СНГ и некоторых других ввиду его очень низкой цены и заявленного функционала(который не всегда работает как хочется).

В этой заметке рассматривается использование MikroTik RouterOS 6.19 в качестве PPPoE BRAS и его интеграция с радиус-сервером (в примере используется FreeRadius 2.1, но точно также могут быть использованы radius-серверы, интегрированные в различные биллинговые системы). Схема описываемой конфигурации:

Mikrotik PPPoE Bras with radius server
Continue reading

Утилизация аппаратных ресурсов на коммутаторах Huawei S-серии

У коммутаторов Huawei S-серии имеется возможность просмотра используемых аппаратных ресурсов (в частности, утилизации tcam) и перераспределения (для некоторых конфигураций модульных коммутаторов).

ACL

Ресурс ACL это в самом деле ресурс, используемый для traffic-policy (и прочих вариаций traffic-*) и, в некоторых случая, Selective QinQ (когда является особым traffic-policy). Имеется три типа ресурсов ACL – rule(классикация трафика), counter(подсчёт трафика), meter(ограничение скорости)
В случае с S9300 это выглядит следующим образом:

[Quidway]display acl resource slot 2
Slot  2  
                     Vlan-ACL    Inbound-ACL  Outbound-ACL                   
----------------------------------------------------------------------------
  Rule Used               10          373            6                
  Rule Free             2038         7819         1018                
  Rule Total            2048         8192         1024                

  Meter Used               0           78            2                
  Meter Free               0         8114         1022                
  Meter Total              0         8192         1024                

  Counter Used             0           96            2                
  Counter Free             0         8096         1022                
  Counter Total            0         8192         1024                
----------------------------------------------------------------------------

Continue reading

Резервирование точки терминирования /30 с помощью VRRP/HSRP

Существует несколько способов зарезервировать точку терминирования сети /30 – cluster/virtual-chassis (самый простой, но не всегда самый дешёвый), mpls pw termination с active/standby проводами на ближайшей PE (актуально для mpls-сетей с количеством PE больше одной-двух, но решается несколько иная задача, а именно уход от децентрализованного терминирования) и VRRP/HSRP (и аналоги). Если с cluster/virtual-chassis всё более-менее просто (MC-LAG в сторону нижестоящего устройства и создание L3 сабынтерфейса в нём), то с vrrp/hsrp несколько сложнее. В классическом варианте VRRP настраивается таким образом:

interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address 192.0.2.6 255.255.255.248
 vrrp 1 ip 192.0.2.1

На втором роутере настраивается адрес 192.0.2.5/29, абоненту остаются адреса 192.0.2.2-4. Однако возникает вопрос что делать, если у вас есть 2 роутера без поддержки кластеризации (например, Cisco ASR1K, 7200 и подобные) и есть абоненты, включенные по схеме /30, для которых хочется сделать резервную точку терминирования? Continue reading

Cisco + non-Cisco или проблема проприетарных протоколов

gns3-cisco-problem

Казалось бы, тривиальная схема включения. С коммутатора(R1) абоненту отдаётся транком 2 влана, он принимает их свитчом(SW1), один отдаёт в роутер(vlan 3), другой в cisco свитч(R2), который выступает в роли power-инжектора для подключения видеокамеры(изображено в виде компьютера C1). vlan 3 работает нормально (абонентский роутер, который не изображён на картинке), vlan 2 нет (видеокамера, подключенная к свитчу). При этом, если подключить камеру напрямую в SW1, то она работает нормально. 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