Лабораторная работа 9. SDN: политики доступа и зеркалирование

Цель

Вы настроите правила доступа на SDN-коммутаторах и зеркалирование трафика на отдельный анализатор.

Задачи

Проверьте исходную связность независимого сегментированного стенда.
Разрешите HTTP и запретите административный порт через Faucet ACL.
Настройте зеркалирование HTTP на отдельный анализатор.
Найдите ошибку порядка правил и подтвердите исправление счётчиками и PCAP.

Рабочее окружение

Потребуются ЛБ7–8 и Ubuntu-ВМ. Укажите в отчёте, сколько времени заняла работа. Стенд независим: файлы и работающее состояние ЛБ8 не требуются. Адреса, две VLAN и маршрутизация уже заданы; задача этой работы — политика доступа. На ВМ:

cd ~/labs-mag/containerlab/lab9
sudo bash up.sh
CTRL=$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' clab-labs9-controller)
sudo ovs-vsctl set-controller l9s1 "tcp:$CTRL:6653"
sudo ovs-vsctl set-controller l9s2 "tcp:$CTRL:6653"
sudo ovs-vsctl list Controller

 a ─ 1:l9s1:3 ═════════ 3:l9s2:1 ─ c
 b ─ 2  │                        2 ─ d
        4 ─ server
        5 ─ sniffer (output only)
          Faucet управляет обоими OVS

Узел	VLAN	Адрес eth1	Порт OVS
a / c	red, 100	10.9.100.10 / .20, /24	l9s1:1 / l9s2:1
b / d	blue, 200	10.9.200.10 / .20, /24	l9s1:2 / l9s2:2
server	blue, 200	10.9.200.100/24	l9s1:4
sniffer	без IP	—	l9s1:5

Шлюзы: 10.9.100.1, 10.9.200.1. Между мостами — trunk red/blue на портах 3. DPID — 0x0901 и 0x0902. Порт анализатора имеет output_only: true: принятые от него кадры не участвуют в обычной коммутации.

Задание 1. Сервис и исходная матрица

1. На ВМ откройте sudo docker exec -it clab-labs9-server bash. В server:

mkdir -p /tmp/www
printf 'lab9 service\n' > /tmp/www/index.html
python3 -m http.server 80 --bind 10.9.200.100 --directory /tmp/www >/tmp/http.log 2>&1 &
python3 -m http.server 8000 --bind 10.9.200.100 --directory /tmp/www >/tmp/admin.log 2>&1 &
ss -lnt

Порт 8000 — учебная модель административного сервиса.

2. В каждом клиенте a/b/c/d проверьте новые HTTP-соединения:

curl -f --max-time 5 http://10.9.200.100/
curl -f --max-time 5 http://10.9.200.100:8000/

Все восемь проверок должны проходить. На ВМ: sudo bash verify.sh baseline. Не вводите запрет, пока исходный сервис и маршрутизация не работают.

Источник	TCP 80 до ACL	TCP 8000 до ACL	TCP 80 после ACL	TCP 8000 после ACL
a, b, c, d	разрешён	разрешён	разрешён	запрещён

Задание 2. Политика доступа

На ВМ откройте configs/faucet/faucet.yaml, добавьте раздел верхнего уровня:

acls:
  client-policy:
    - rule:
        dl_type: 0x0800
        ip_proto: 6
        ipv4_dst: 10.9.200.100/32
        tcp_dst: 80
        actions:
          allow: 1
    - rule:
        dl_type: 0x0800
        ip_proto: 6
        ipv4_dst: 10.9.200.100/32
        tcp_dst: 8000
        actions:
          allow: 0
    - rule:
        actions:
          allow: 1

В интерфейсах l9s1 добавьте acls_in: [client-policy] на порты 1, 2 и 3. Порты 4 и 5 не меняйте, на l9s2 эту ACL не назначайте. Так политика охватывает локальных клиентов и пришедших по trunk c/d перед доставкой на сервер. Последнее правило allow пропускает ARP, ответы и прочий трафик; эта учебная политика запрещает конкретный административный порт и не является общим deny-all.

Проверьте и примените на ВМ:

sudo docker exec clab-labs9-controller check_faucet_config /etc/faucet/faucet.yaml
sudo docker kill --signal=HUP clab-labs9-controller
sudo docker logs --tail 40 clab-labs9-controller
sudo ovs-ofctl -O OpenFlow13 dump-flows l9s1
sudo bash verify.sh policy

В запросах, которые должны завершиться отказом, задан тайм-аут. Проверьте также, что сервер продолжает слушать 8000, иначе ошибка запуска сервиса будет похожа на запрет. Найдите правила ACL по in_port, TCP-порту и приоритету, сравните счётчики до и после новых запросов. Потоки вручную через ovs-ofctl add-flow не правьте.

Задание 3. Зеркалирование

1. В первом правиле ACL для TCP 80 добавьте к allow: 1 действие:

          mirror: 5

Сохраните YAML, проверьте и примените конфигурацию. Номер 5 — OpenFlow-порт анализатора того же l9s1, где применяется ACL.

2. В sniffer, открытом через docker exec, запустите:

tcpdump -i eth1 -w /tmp/lab9-mirror.pcap

С a и c отправьте по новому HTTP-запросу на порт 80. Пока захват работает, на a выполните curl --max-time 5 http://10.9.200.100:8000/. После обоих опытов остановите захват и прочитайте tcpdump -enn -r /tmp/lab9-mirror.pcap.

Это ingress mirror запросов, поэтому полной двусторонней TCP-сессии на анализаторе может не быть. Кадр c приходит на l9s1 с тегом trunk; кадр a — через access-порт. Сопоставьте IP/порты запроса, VLAN и счётчик ACL. В PCAP не должно быть копии запроса на 8000: mirror назначен только разрешающему HTTP-правилу.

Задание 4. Неисправность порядка правил

1. Сохраните копию рабочего YAML вне каталога конфигурации. Перенесите последнее безусловное allow: 1 в начало client-policy. Примените через контроллер и проверьте порт 8000 новым соединением. Он станет доступен: первое подходящее правило разрешает пакет до специального запрета.

2. Найдите в flows правило большего приоритета и рост его счётчика. Верните безусловное правило в конец, проверьте конфигурацию, примените и повторите sudo bash verify.sh policy. Ненулевой код возврата curl сам по себе не доказывает, что сработал запрет. Сверьте его со счётчиком drop и убедитесь, что сервис запущен.

Самостоятельное задание и отчёт

Перед запрещающим правилом временно разрешите TCP 8000 только от a через ipv4_src: 10.9.100.10/32. До изменения заполните новую матрицу для a/b/c/d, затем проверьте каждый клиент. Верните общий запрет для итоговой проверки.

Приложите все три версии политики, матрицы, выбранные OpenFlow-правила со счётчиками и PCAP анализатора. Ответьте:

Почему ACL назначена на порты 1, 2 и 3 l9s1?
Почему номер mirror-порта должен относиться к тому же datapath?
Почему ingress mirror не гарантирует захват ответов сервера?
Как отличить ACL drop от остановленного сервиса и ошибки маршрута?

Дополнительно после проверки поддержки выбранных версий можно исследовать meters. Ограничение скорости не входит в обязательную часть.

Сохранение и завершение

Добавьте запуск сервисов в configs/server/startup.sh, сохраните YAML и PCAP через docker cp в отчёт. На ВМ выполните sudo bash down.sh, затем sudo bash up.sh, заново подключите оба моста к адресу контроллера и повторите sudo bash verify.sh policy. После сохранения результатов снова выполните sudo bash down.sh. Для полного повтора верните YAML без ACL; адреса и сегментацию стартового стенда сохраните.