UniFi Site-to-Site VPN через WireGuard між двома локаціями

UniFi Site-to-Site VPN через WireGuard – це міжсайтовий VPN для маршрутизації трафіку між двома LAN без NAT усередині тунелю. Схема підходить для зв’язку між будинком, офісом, серверною або backup-локацією, коли потрібен прямий доступ до серверів, NAS, камер чи VLAN з іншого майданчика. Критичні умови тут дві: різні підмережі на обох боках і коректний AllowedIPs.

Якщо адресація перетинається, тунель може піднятися, але пакети підуть у локальний сегмент замість VPN. Якщо один бік сидить за CGNAT, а другий теж недоступний ззовні, handshake часто не з’являється взагалі.

Для невеликого homelab або двох офісів це один із найпростіших варіантів. Коли сегментів стає багато, а маршрути йдуть через кілька WAN, сам тунель налаштовується швидко, а от підтримка схеми починає забирати основний час.

Коли цей тунель справді має сенс

UniFi Site-to-Site VPN через WireGuard підходить для постійного доступу між двома локаціями, а не для підключення окремих користувачів. Найкраще схема працює там, де є стабільний інтернет, різні LAN-мережі і короткий список підмереж, які треба маршрутизувати.

Типовий сценарій – будинок і віддалений офіс, дві квартири, офіс і стійка в дата-центрі, основний майданчик і backup-сайт. Для доступу до Proxmox, NAS, камер або внутрішнього DNS цього зазвичай достатньо.

До певного масштабу рішення лишається прозорим. Якщо між сайтами треба передати 2-5 підмереж і кілька десятків пристроїв, плутанини майже немає. Після десяти VLAN і окремих правил для кожного сегмента UniFi Site-to-Site VPN через WireGuard уже вимагає уважної перевірки маршрутів і firewall policy.

Яку адресацію підготувати до створення VPN

Перед налаштуванням треба визначити WAN-адресу або DDNS на кожному боці, LAN-підмережі обох локацій, окрему тунельну підмережу і список мереж для маршрутизації. Якщо хоча б один пункт лишається невизначеним, проблеми починаються ще до першого тесту.

Що має бути визначено до кліку в UniFi

Мінімальна схема проста: перша локація має LAN 192.168.10.0/24, друга – 192.168.20.0/24. Для тунелю зручно взяти окрему підмережу, наприклад 10.100.100.0/30, яка ніде локально не використовується.

Зовнішня адреса має бути статичною або доступною через DDNS. Коли провайдер часто змінює IP, але hostname оновлюється швидко, цього зазвичай вистачає. Приватна WAN-адреса від провайдера вже ускладнює схему.

Які мережі вносити в маршрути

У маршрутну логіку треба вносити тільки ті підмережі, які справді мають бути доступні між сайтами. Якщо на першій локації є 192.168.10.0/24 і 192.168.30.0/24, а на другій лише 192.168.20.0/24, не варто додавати в AllowedIPs весь приватний простір.

Так ламають локальний вихід в інтернет або тягнуть у тунель трафік, який там не потрібен. IoT і guest VLAN часто краще взагалі не включати в VPN, якщо між локаціями потрібен лише доступ до серверного чи management-сегмента.

Як заповнити параметри на обох UniFi-шлюзах

UniFi Site-to-Site VPN через WireGuard будується як пара peers з публічним endpoint, тунельними адресами і списком віддалених мереж. Якщо ключі, endpoint і AllowedIPs збігаються зі схемою, ручне редагування конфігів не потрібне.

Базова схема для двох локацій

Нехай перший шлюз має WAN site-a.example.com, другий – site-b.example.com. Тунельна мережа – 10.100.100.0/30. На першому боці адреса WireGuard буде 10.100.100.1/30, на другому – 10.100.100.2/30.

LAN мережі:

• Site A: 192.168.10.0/24
• Site B: 192.168.20.0/24

Що вносити на Site A

1. Створити новий Site-to-Site VPN через WireGuard.
2. Задати локальну тунельну адресу 10.100.100.1/30.
3. Згенерувати або вставити private/public key для цього шлюзу.
4. У полі peer endpoint вказати site-b.example.com:51820.
5. Внести public key другого шлюзу.
6. У AllowedIPs для peer вказати 10.100.100.2/32,192.168.20.0/24.
7. Переконатися, що UDP-порт WireGuard дозволений на WAN.

Що вносити на Site B

1. Створити дзеркальний тунель.
2. Задати локальну адресу 10.100.100.2/30.
3. Вказати endpoint site-a.example.com:51820.
4. Внести public key першого шлюзу.
5. У AllowedIPs записати 10.100.100.1/32,192.168.10.0/24.

Найчастіше ламається одна дрібниця: у AllowedIPs додають тільки тунельну адресу peer і забувають LAN віддаленої локації. Handshake при цьому є, інтерфейс активний, а трафік до цільової мережі нікуди не маршрутизується.

Як працює маршрутизація через WireGuard і чому AllowedIPs часто ламає доступ

AllowedIPs у WireGuard визначає, які адреси приймаються від peer і які маршрути відправляються через нього. Для site-to-site це ключовий параметр. Немає віддаленої LAN у списку – немає нормального доступу до неї.

Що має бути в AllowedIPs для site-to-site

Для кожної сторони треба додати тунельну адресу peer і віддалені LAN-підмережі. У простій схемі з одним сегментом це виглядає так:

Site A peer AllowedIPs:
10.100.100.2/32
192.168.20.0/24

Site B peer AllowedIPs:
10.100.100.1/32
192.168.10.0/24

Якщо на віддаленому боці кілька VLAN, додаються тільки потрібні, наприклад 192.168.20.0/24 і 192.168.21.0/24. Вказувати 192.168.0.0/16 без жорсткої причини – погана ідея. Частина локальних мереж тоді може поїхати в тунель.

Де схема ламається найчастіше

Перша поломка – однакові підмережі на обох локаціях, наприклад двічі 192.168.1.0/24. У такій схемі вузол вважає адресат локальним і не відправляє пакет у VPN. Лікується це лише зміною адресації.

Друга проблема – запис 0.0.0.0/0 у site-to-site peer. Для road warrior це нормальний сценарій, але тут він часто затягує default route в іншу локацію. Після цього з’являються дивні симптоми: повільний інтернет, недоступний принтер або DNS через не той шлюз.

Третій збій – немає зворотного маршруту на другому боці. Пінг до тунельної адреси іноді проходить, а доступу між LAN все одно немає.

Як перевірити handshake, маршрути і реальний трафік між LAN

Перевірка йде в три етапи: handshake, маршрути і трафік між хостами. Статус connected сам по собі мало що доводить. UniFi Site-to-Site VPN через WireGuard часто виглядає піднятим навіть тоді, коли корисний трафік не ходить.

Що перевірити одразу після запуску

1. Статус тунелю в UniFi: peer має бути активним, з актуальним handshake.
2. Лічильники трафіку: байти в обидва боки повинні зростати.
3. Наявність маршруту до віддаленої LAN через WireGuard interface.

За наявності handshake і нульового RX/TX причину зазвичай шукають у AllowedIPs, firewall rule або джерелі тестового трафіку. Якщо handshake немає, спочатку перевіряють endpoint, порт і доступність WAN.

Набір тестів без зайвих кроків

Починати краще з адрес самих шлюзів, а не з сервера десь усередині мережі. Послідовність така:

1. Пінг з Site A на тунельну адресу 10.100.100.2.
2. Пінг з Site A на LAN-адресу шлюзу Site B, наприклад 192.168.20.1.
3. Пінг з хоста 192.168.10.x на хост 192.168.20.x.
4. Трасування маршруту, якщо пінг не проходить.

Коли потрібен доступ лише до окремого сервісу, повний міжсайтовий тунель може бути зайвим. Для SSH чи вебпанелі іноді простіше дати доступ через Cloudflare Tunnel, без маршрутизації цілої підмережі.

Чому тунель не стартує за NAT, CGNAT або змінною адресою

Site-to-site через WireGuard потребує, щоб хоча б один бік був досяжний ззовні по UDP-порту. Якщо обидва шлюзи за NAT без пробросу, а тим більше за CGNAT, вхідний трафік до peer не доходить. Тоді handshake не з’являється або пропадає після зміни адреси.

Що працює зі звичайним NAT

Коли провайдер видає реальну зовнішню адресу, але UniFi стоїть за ще одним роутером, зазвичай достатньо пробросити UDP-порт WireGuard на шлюз. DDNS у такій схемі теж працює нормально, якщо endpoint вказаний як hostname.

Що робити з CGNAT

За CGNAT відкрити вхідний порт часто неможливо. Якщо один майданчик має публічний IP, ініціатором можна зробити бік за CGNAT, а другий лишити приймальною стороною. Якщо обидва сидять за CGNAT, прямий тунель між двома UniFi-шлюзами зазвичай заходить у глухий кут.

Тут уже логічніше дивитися на overlay-рішення, побудовані поверх WireGuard, наприклад Tailscale. Для кількох вузлів за NAT воно часто дає менше клопоту, ніж спроби втримати прямий site-to-site.

Де UniFi Site-to-Site VPN між локаціями ламається найчастіше

Основні проблеми тут чотири: конфлікт підмереж, помилка в AllowedIPs, firewall rules між VLAN і відсутній зворотний маршрут. MTU теж трапляється, але рідше. Якщо handshake є, а хости недоступні, перевірку варто починати саме з цих пунктів.

Конфлікт LAN-підмереж

Два сайти з 192.168.1.0/24 – класичний випадок. Тунель може виглядати справним, але нормально маршрутизувати трафік не вийде. Найшвидший спосіб виправити схему – перенумерувати одну локацію.

Firewall блокує міжсайтовий трафік

UniFi може підняти VPN, але трафік між VLAN або між LAN і VPN зупиниться на policy rules. Часто це видно там, де management, servers і users рознесені по окремих мережах. Якщо доступ потрібен лише до одного сегмента, правило має явно дозволяти трафік з віддаленої підмережі до локальної цільової VLAN.

MTU і обриви великих пакетів

Якщо ping проходить, а копіювання файлів, RDP або вебінтерфейси працюють ривками, варто перевірити MTU. Дрібні пакети в такій ситуації йдуть, великі фрагментуються або губляться. Частіше це спливає на PPPoE або інших схемах з додатковою інкапсуляцією.

Маршрут є лише в один бік

Шлюз A знає, де мережа B, а шлюз B не знає, як повернутися в A. Тоді видно тунельний IP, але не хости за ним. У багатовланових схемах така помилка ховається часто: один сегмент додали в peer, інший пропустили.

Коли краще перейти на IPsec, Tailscale або іншу схему

WireGuard на UniFi варто міняти, коли проблему створює не сам тунель, а контекст мережі: CGNAT з обох боків, mesh із багатьох майданчиків або вимога сумісності з чужими шлюзами. У таких сценаріях інший підхід часто простіший в обслуговуванні.

IPsec має сенс там, де друга сторона не на UniFi або потрібна міжвендорна сумісність. Tailscale виграє в мережах за NAT. Якщо ж завдання вузьке, повний site-to-site тунель часто додає більше точок відмови, ніж користі.

UniFi Site-to-Site VPN через WireGuard працює добре, доки адресація чиста, список маршрутів короткий, а WAN досяжний. Якщо вже на старті доводиться обходити CGNAT, маскувати конфліктні підмережі й розбирати policy routing, краще одразу вибрати інший інструмент.

Офіційні сторінки: Ubiquiti UniFi, WireGuard, Tailscale, Cloudflare Tunnel.

Коментарі

Коментарів ще немає. Обговорення - у Telegram.

Коментувати в Telegram