Цей посібник описує процес налаштування IPv6-маршрутизації та NAT66 між роутером (MikroTik) та VPS на базі Arch Linux із використанням WireGuard та брандмауера UFW.
Особливу увагу приділено підводним каменям, з якими доводиться стикатися на практиці (конфлікти AllowedIPs, налаштування маршрутизації, правила UFW FORWARD та NAT66).
1. Архітектура рішення
- VPS (Шлюз): Має зовнішній мережевий інтерфейс enp1s0 та виділену підмережу IPv6 від хостера.
- MikroTik (Клієнт): Підключається через WireGuard-тунель wgIPv6.
- NAT66 (MASQUERADE): Оскільки хостер зазвичай маршрутизує на VPS лише одну конкретну адресу або підмережу і не знає про внутрішній тунель, використовується маскарадинг для виходу в публічний IPv6-простір.
2. Налаштування на стороні VPS
Крок 1. Конфігурація WireGuard (/etc/wireguard/wgIPv6.conf)
У секції [Interface] обов'язково налаштовуємо автоматичне додавання та видалення правила NAT66 за допомогою PostUp / PostDown.
[Interface]
PrivateKey = <PRIVATE_KEY_VPS>
Address = 10.50.0.1/24, 2a00:7a60:0:3885:2000::1/127
ListenPort = 52820
# Автоматичне увімкнення та вимкнення NAT66 при піднятті/опусканні тунелю
PostUp = /usr/bin/ip6tables -t nat -A POSTROUTING -o enp1s0 -j MASQUERADE
PostDown = /usr/bin/ip6tables -t nat -D POSTROUTING -o enp1s0 -j MASQUERADE
# Peer: MikroTik (Офіс / Роутер)
[Peer]
PublicKey = <PUBLIC_KEY_MIKROTIK>
AllowedIPs = 10.0.50.2/32, 2a00:7a60:0:3885::/68, 2a00:7a60:0:3885:2000::2/128
Розбір проблеми (AllowedIPs): На початку пінг не проходив, бо в AllowedIPs була вказана лише загальна підмережа 2a00:7a60:0:3885::/68. Адреса самого тунелю 2a00:7a60:0:3885:2000::2 виявилася поза цим діапазоном, через що ядро Linux на VPS відкидало пакет ще на вході. Вирішення: додати точну адресу піра через /128 у AllowedIPs.
Крок 2. Увімкнення IPv6 у системі та UFW
- Переконайтеся, що в системному ядрі увімкнено пересилання пакетів:
sysctl -w net.ipv6.conf.all.forwarding=1 - У конфігураційному файлі UFW (
/etc/default/ufw) обов'язково активуйте підтримку IPv6:IPV6=yes DEFAULT_FORWARD_POLICY="ACCEPT"Розбір проблеми (IPV6=no): Без значення IPV6=yes у UFW, демон повністю ігнорує будь-які IPv6-правила та блокує весь транзитний IPv6-трафік.
Крок 3. Налаштування правил UFW для транзиту (FORWARD)
UFW за замовчуванням блокує транзитний трафік між мережевими інтерфейсами. Щоб пакети могли вільно проходити з тунелю в інтернет і повертатися назад, потрібно дозволити маршрутизацію:
# Дозвіл транзиту між тунельним інтерфейсом та WAN
ufw route allow in on wgIPv6 out on enp1s0
ufw route allow in on enp1s0 out on wgIPv6
Перезавантаження фаєрвола
ufw reload
Розбір проблеми (Блокування
UFWFORWARD): Навіть за наявності правильногоMASQUERADEуiptables,UFWна рівні ланцюжкаFORWARDвідкидав пакети між різними інтерфейсами (wgIPv6таenp1s0). Явне правилоufw route allowусуває це блокування.
3. Налаштування на стороні MikroTik
На роутері MikroTik необхідно налаштувати відповідні IP-адреси на інтерфейсі WireGuard та додати дефолтний маршрут.
-
Створення інтерфейсу WireGuard та додавання IP:
/interface wireguard add name=wgIPv6 listen-port=52820 /ip address add address=2a00:7a60:0:3885:2000::2/127 interface=wgIPv6Розбір проблеми (Призначення IP): Адреса ...:2000::2 належить MikroTik, а ...:2000::1 належить VPS. При виконанні пінгу з MikroTik важливо, щоб джерелом пакета (src-address) була саме його тунельна адреса (::2), а не внутрішні LAN-адреси.
-
Додавання піра (VPS):
/interface wireguard peers add interface=wgIPv6 public-key="<PUBLIC_KEY_VPS>" endpoint-address=<VPS_IP> endpoint-port=52820 allowed-address=::/0 -
Маршрутизація за замовчуванням через тунель:
/ipv6 route add dst-address=::/0 gateway=wgIPv6
4. Перевірка працездатності
Виконайте перевірку пінгів з командного рядка MikroTik:
# Перевірка з самого роутера
/ping 2001:4860:4860::8888 count=3
# Перевірка з виділенням конкретної локальної IP-адреси як джерела (src-address)
/ping 2001:4860:4860::8888 src-address=2a00:7a60:0:3885::1 count=3
Якщо packet-loss=0%, тунель і трансляція адрес (NAT66) налаштовані правильно.