Лабораторная работа 6. WireGuard и диагностика туннелей

Цель

Вы соедините две учебные площадки через WireGuard и проследите, как трафик передаётся внутри туннеля.

Задачи

Настройте внешнюю сеть двух VPN-шлюзов.
Создайте локальные ключи и настройте peers.
Свяжите две LAN через WireGuard.
Сопоставьте внутренний IP-пакет и внешний UDP-трафик.
Найдите ошибку в AllowedIPs и проверьте влияние MTU.

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

Потребуются ЛБ3–4 и Ubuntu-ВМ. Укажите в отчёте, сколько времени заняла работа. На ВМ:

cd ~/labs-mag/containerlab/lab6
sudo containerlab deploy -t lab6.clab.yml

a ─ eth1:gw1:eth2 ─ eth1:wan:eth2 ─ eth2:gw2:eth1 ─ b
      LAN A           внешняя сеть          LAN B

Узел	eth1	eth2	wg0
a	10.6.1.10/24	—	—
gw1	10.6.1.1/24	192.0.2.1/30	10.6.255.1/30
wan	192.0.2.2/30	198.51.100.2/30	—
gw2	10.6.2.1/24	198.51.100.1/30	10.6.255.2/30
b	10.6.2.10/24	—	—

Внешние адреса здесь тестовые и существуют только внутри ВМ. eth0 — management, маршрут через него удаляется стартовым сценарием. Все сетевые команды выполняйте в контейнере: на ВМ откройте, например, sudo docker exec -it clab-labs6-gw1 bash.

Задание 1. Базовая сеть

1. На узлах назначьте адреса eth1/eth2 по таблице, поднимите интерфейсы. На gw1, wan и gw2 включите sysctl -w net.ipv4.ip_forward=1.

2. Добавьте маршруты. На a: ip route add 10.6.2.0/24 via 10.6.1.1. На b: ip route add 10.6.1.0/24 via 10.6.2.1. На gw1: ip route add 198.51.100.0/30 via 192.0.2.2. На gw2: ip route add 192.0.2.0/30 via 198.51.100.2. На wan не добавляйте маршруты в клиентские LAN.

3. С gw1 проверьте ping -c 4 198.51.100.1. С a выполните ping -c 4 -W 2 10.6.2.10: ответов пока быть не должно. Сохраните таблицы маршрутов, объясните, на каком узле останавливается пакет и почему.

Задание 2. Ключи

На ВМ, в каталоге lab6, от своего пользователя:

umask 077
wg genkey > private/gw1/key
wg pubkey < private/gw1/key > private/gw1/public
wg genkey > private/gw2/key
wg pubkey < private/gw2/key > private/gw2/public
cat private/gw1/public private/gw2/public

Приватные ключи подключены к контейнерам как /run/keys/key только для чтения. Не выводите их в терминал, отчёт и журнал script. Каталог private/ исключён из Git. На каждом шлюзе в переменную PEER подставьте публичный ключ противоположного шлюза из вывода выше. Переменная нужна в оболочке контейнера.

Задание 3. Туннель

На gw1:

read -r -p 'Публичный ключ gw2: ' PEER
ip link add wg0 type wireguard
ip address add 10.6.255.1/30 dev wg0
ip link set wg0 mtu 1420
wg set wg0 private-key /run/keys/key listen-port 51820 peer "$PEER" endpoint 198.51.100.1:51820 allowed-ips 10.6.255.2/32,10.6.2.0/24
ip link set wg0 up
ip route add 10.6.2.0/24 dev wg0

На gw2:

read -r -p 'Публичный ключ gw1: ' PEER
ip link add wg0 type wireguard
ip address add 10.6.255.2/30 dev wg0
ip link set wg0 mtu 1420
wg set wg0 private-key /run/keys/key listen-port 51820 peer "$PEER" endpoint 192.0.2.1:51820 allowed-ips 10.6.255.1/32,10.6.1.0/24
ip link set wg0 up
ip route add 10.6.1.0/24 dev wg0

wg set задаёт AllowedIPs, но не создаёт Linux-маршруты автоматически. wg-quick в этой работе не используется. Адреса и маршруты основного компьютера не меняйте; 0.0.0.0/0 в AllowedIPs не нужен.

На a проверьте ping b, на b — обратное направление. После трафика на шлюзах посмотрите wg show wg0: latest handshake и счётчики transfer. Команда скрывает приватный ключ; wg showconf и wg show ... private-key в отчёт не включайте.

Задание 4. Захват и MTU

1. На gw1 в двух терминалах:

tcpdump -i wg0 -w /tmp/lab6-inner.pcap icmp

tcpdump -i eth2 -w /tmp/lab6-outer.pcap 'udp port 51820'

С a выполните ping b, остановите захваты. Сравните адреса пакетов на двух интерфейсах и проверьте, видно ли их содержимое. На wan виден внешний UDP, внутренний ICMP в открытом виде через wan не передаётся.

2. С a выполните:

ping -c 3 -M do -s 1392 10.6.2.10
ping -c 3 -M do -s 1450 10.6.2.10
tracepath -n 10.6.2.10

При wg0 MTU 1420 первый IPv4-пакет укладывается в MTU: 1392 + 20 + 8. Второй превышает его; зафиксируйте ICMP Fragmentation Needed или локальную ошибку размера. Объясните, где появляется служебный ICMP и что меняет DF.

Задание 5. Ошибка AllowedIPs

На gw2 переменная PEER должна содержать публичный ключ gw1. Временно оставьте для него только адрес туннеля:

wg set wg0 peer "$PEER" allowed-ips 10.6.255.1/32
wg show wg0

На gw1 ping 10.6.255.2 может проходить, а с a в LAN B — нет. Проверьте handshake, маршрут в LAN и обе стороны захвата. Наличие handshake не доказывает разрешения клиентского префикса. Восстановите:

wg set wg0 peer "$PEER" allowed-ips 10.6.255.1/32,10.6.1.0/24

Повторите ping клиентов.

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

Замените UDP-порт gw2 на 51821 и исправьте endpoint peer на gw1. До выполнения укажите, какие две настройки связаны. Проверьте связь и новый порт в захвате, затем верните 51820 для итоговой проверки.

Приложите схему, публичные ключи, маршруты, AllowedIPs, handshake и два PCAP. Ответьте:

Чем AllowedIPs отличается от таблицы маршрутизации?
Почему для ответа нужен клиентский префикс в peer на второй стороне?
Что означает успешный handshake при неработающем ping?
Почему MTU туннеля меньше MTU внешнего интерфейса?

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

В configs/*/startup.sh сохраните адреса и маршруты. В сценариях шлюзов запишите публичные ключи peer и команды wg set со ссылкой /run/keys/key, без приватного значения. read из примера замените присваиванием публичного ключа. Ключи оставьте в private/ только на ВМ. Скопируйте PCAP в отчёт через docker cp, затем на основную ОС.

На ВМ пересоздайте стенд, проверьте финальное состояние и удалите его:

sudo containerlab destroy -t lab6.clab.yml --cleanup
sudo containerlab deploy -t lab6.clab.yml
sudo bash verify.sh
sudo containerlab destroy -t lab6.clab.yml --cleanup

Для полного повтора удалите только два созданных файла key и два public в private/gw1/, private/gw2/, верните стартовые сценарии и создайте новые ключи. При обычном пересоздании ключи не генерируйте заново.